One of the common problem with MPLS based L3 VPN services from Service Provider perspective is PE Scalability. Specially If the Implementation in the Core is using VPNv4 Route Reflector (VPNv4 RR).
When VPNv4 RR receives routes from PEs, It's job is to reflect all different customer routes to another PEs without considering the fact that particular Customer VRF might not exist on specific PE. Which is most likely the case in Real world. Which is certainly a problem from PE Perspective.
One of the way PE get rid of this problem itself is that by Default Automatic Route Filtering (ARF) is enabled on all PEs which suggest a rule that if routes are received for particular VRF and that particular VRF doesn't exist on PE locally, it's gonna filter out those routes automatically. However this logic or rule doesn't apply to VPNv4 Route Reflector itself since it doesn't make sense to put it in Data/Forward Plane. And if it's not in Data Plane than creating and mapping VRFs locally doesn't make any sense.
On the flip side , however ARF is good tool to have in pocket from PE perspective. But problem is that routes are still getting received from Route Reflector (RR) and getting filtering after that which means wastage of local resources and bandwidth.
So the question is, How Do We Fix This ?
The Answer lies in something called Route Target Contrain as defined in RFC-4684. I'll talk about AFI and SAFI in next post. But lets assume that this feature signals the RR from PE perspective about which all VRFs locally exist on that particular PE, resulting RR not Reflecting unnecessary routes towards that PE for VRF that doesn't exist locally on it.
Here is a quick example :
In This Particular Example PE-2 doesn't have VRF-B configured locally. So It doesn't need to receive Reflected Routes from RR for VRF-B.
Before RTC: RR Sending All Routes for All VRFs to PE-2
After RTC: RR Sending Only Routes For VRF-A to PE-2
Configuration:
Further Verification:
Pitfall :
From Planning Perspective, you need to understand that this feature is not only IOS dependent but also would require to be enabled not only on VPNv4 RR but also on PE under consideration.
HTH...
Deepak Arora
Evil CCIE
When VPNv4 RR receives routes from PEs, It's job is to reflect all different customer routes to another PEs without considering the fact that particular Customer VRF might not exist on specific PE. Which is most likely the case in Real world. Which is certainly a problem from PE Perspective.
One of the way PE get rid of this problem itself is that by Default Automatic Route Filtering (ARF) is enabled on all PEs which suggest a rule that if routes are received for particular VRF and that particular VRF doesn't exist on PE locally, it's gonna filter out those routes automatically. However this logic or rule doesn't apply to VPNv4 Route Reflector itself since it doesn't make sense to put it in Data/Forward Plane. And if it's not in Data Plane than creating and mapping VRFs locally doesn't make any sense.
On the flip side , however ARF is good tool to have in pocket from PE perspective. But problem is that routes are still getting received from Route Reflector (RR) and getting filtering after that which means wastage of local resources and bandwidth.
So the question is, How Do We Fix This ?
The Answer lies in something called Route Target Contrain as defined in RFC-4684. I'll talk about AFI and SAFI in next post. But lets assume that this feature signals the RR from PE perspective about which all VRFs locally exist on that particular PE, resulting RR not Reflecting unnecessary routes towards that PE for VRF that doesn't exist locally on it.
Here is a quick example :
In This Particular Example PE-2 doesn't have VRF-B configured locally. So It doesn't need to receive Reflected Routes from RR for VRF-B.
Before RTC: RR Sending All Routes for All VRFs to PE-2
Configuration:
Further Verification:
Pitfall :
From Planning Perspective, you need to understand that this feature is not only IOS dependent but also would require to be enabled not only on VPNv4 RR but also on PE under consideration.
HTH...
Deepak Arora
Evil CCIE
1 comment:
hello Deepak,
Nice post but i think you need to add the below command:
address-family rt-filter unicat
neighbor 4.4.4.4 route-reflector-client
Best
sofiane
Post a Comment