roles are just conventions meaning that nobody prevent you from using a router for P role for some flows and PE for others. Same for ASBR.
So even if this is not ideal you can go for that.
thank you, actually we have a network with two core routers,12000 (P's) and around 14 (PE) in different Cities (7206VXR), Currently the two P's is the route reflector in same cluster and both of them in the same city. there will be new POP in new city so i want to have like two 7600 as P/PE/ASBR and also play the role of Route reflectors,for this new RR's has to be in same cluster as the other RR's in the other city, because some of the PE's will be physicaly connected to the different cities for redundancy so may they need to peer with the RR's in the two cities.please can you advise what is the best for RR config here and the cluster id.
MPLS VPN Best Pratices dictate that the RR's should be kept out of the forwarding path altogheter. It is not recommended that a PE or a P also has the RR role has that can impact performances and stabilities.
yah, but i read many books of Cisco they mentioning that the P can be a RR reflector also i see many of the implementation they use the Core (P) since it is powerful device as the RR,can you provide any document saying what you mention that should be kept out of the forwarding path and what is the resason behind it.
and can be work if the P/PE device is the RR, or what is the concern here.
in other way when i should start to consider a dedicated RR's instead using the P/PE as RR,
A Best Practice is not a must but it is something which is recommended. You can use a P as a RR but you need to be aware of the possible consequences.
RRs should be kept out of forwarding path to make sure that a single router uses all its resources for this vital task. If your RR's pair go down your entire MPLS VPN infrastructure goes down.
If a router does only RR task you can easily predict its memory and CPU utilization (plus you can tune TCP on this device only to allow better BGP scalability). If a router shares it with other tasks, mainly traffic forwarding, it becomes more susceptible to unexpected problems. I.E. if all of a sudden your P/RR (7600 as you mentioned) starts processing traffic in software by the CPU for any reason (TCAM depleted, traffic not handled in hardware, PFC/DFC failure, IOS bug etc.) your control plane is impacted. BGP sessions might start flapping and your routing goes banana.
If you do a quick search on google about MPLS VPN Best Practices you will find many.
For instance I found this old Networker presentation
not sure you are allowed to see it though.
PS please rate this thread if helpful
hi, if the P is in the path for the PE and it is RR, does not make difference for the PE because if the P down the PE out of reach ,
also what model do you recommened as a dedicated RR, and if we have many countries how is the design of the RR will be,since we have some PE's will peer with different countries. are you align with me.
how is the cluster id here need to be design if we will have three countries as a main countries,where many of the regional PE's will peer with different countries for redundancy. where we suppose to have RR and how is the cluster id here need to be
just i forget to tell you that one of the reason for using the P as RR is the utilization is not exceed 2 to 3 % also we are using the RR for just VPNv4 route not for IPv4 because we are not running internet on this mpls network just for global customer connectivity.