RT Filter
Last updated
Last updated
Load vpnv4.rt.filter.init.cfg
Currently, each PE is receiving VPNv4 routes reflected from the RRs for which the PE does not have a VRF importing the RT. This wastes bandwidth and processing on the PEs.
Configure the network so that PEs signal to the RR the RTs they are locally importing, so that the RRs can dynamically filter outbound VPNv4 routes that each PE is not locally importing.
First let’s examine the issue before we configure the RT filter. When XR1 sends an update for VPN_B, both R2 and R5 must receive this route, process it, determine that they are not importing the RT locally, and discard the route.
Likewise, XR1 must reject VPNv4 routes for VPN_A from R2 or R5.
Note the last line, DENIED RT extended community is not imported locally
We’ll now activate the ipv4/RT-filter BGP address-family. Each PE simply activates the AFI/SAFI.
So far, no filtering is taking place because we haven’t activated the address-family on the RRs. We’ll do that now. We do not need to use route reflection, because we are negotiating the VPNv4 routes that are sent between the RR and its own clients. We don’t need to reflect client routes to each other.
When we look at the BGP table for ipv4/rt-filter on the RRs, we can see that each PE sends an Update for each RT it is importing locally. The format is <ASN>:2:<RT>. (2 is the extcommunity type code). We also see a 100:258:<Lo0>:0 Update, but I’m not sure what that is for. These updates are automatically generated once you active the RT-filter address-family.
Currently, routes are not being reflected at all! This is because the RRs are not originating any RT-filter updates of their own, because they import no RTs at all locally. So each PE is filtering its own locally originated VPNv4 routes outbound to the RRs. To prevent this we need to originate a default route on the RRs to each client. This means “send me all RTs.”
We now have routes again, thanks to the default that each RR originates towards each PE. This prevents each PE from filtering any VPNv4 routes outbound towards the RRs.
Even though one PE is choosen as the “bestpath” above, R2 still knows that it should send unfiltered VPNv4 updates to both R3 and R6.
If we generate VPNv4 routes on one PE while debugging updates on a RR, we can see the filtering in action:
Above we see that the update is denied towards R4 and XR1, but permitted towards R2 and (back to) R5.
RT-filter is similar to an ORR (outbound route filter) for VPNv4 unicast routes. This provides some scalability because each router will only receive routes for which it will import locally into a VRF. There is no reason for an RR to send routes towards a PE that the PE will just discard anyways.
You must be careful to generate a default route for the RT-filter/unicast address-family on the RRs. PEs must not filter VPNv4 routes at all towards the RRs.
Each PE will automatically generate one RT-filter Update per RT that is locally imported into a VRF. You don’t need to configure anything for this to take place.
