# RT Filter Load **vpnv4.rt.filter.init.cfg** ``` #IOS-XE config replace flash:vpnv4.rt.filter.init.cfg #IOS-XR configure load bootflash:vpnv4.rt.filter.init.cfg commit replace y ```
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. ## Answer ``` #R2, R4, R5 router bgp 100 address-family rtfilter unicast nei 3.3.3.3 act nei 6.6.6.6 act #XR1 router bgp 100 address-family ipv4 rt-filter ! neighbor 3.3.3.3 address-family ipv4 rt-filter ! neighbor 6.6.6.6 address-family ipv4 rt-filter #R3, R6 router bgp 100 template peer-policy IBGP_RT_FILTER default-originate exit ! address-family rtfilter unicast nei 2.2.2.2 activate nei 4.4.4.4 activate nei 5.5.5.5 activate nei 19.19.19.19 activate nei 2.2.2.2 inherit peer-policy IBGP_RT_FILTER nei 4.4.4.4 inherit peer-policy IBGP_RT_FILTER nei 5.5.5.5 inherit peer-policy IBGP_RT_FILTER nei 19.19.19.19 inherit peer-policy IBGP_RT_FILTER ``` ## Explanation 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. ``` #R5 debug bgp vpnv4 uni update in ```
Likewise, XR1 must reject VPNv4 routes for VPN\_A from R2 or R5. ``` #XR1 debug bgp update in ``` {% code overflow="wrap" %} ``` RP/0/0/CPU0:Sep 20 11:57:25.458 : bgp[1051]: [default-rtr] (vpn4u): Received UPDATE from 6.6.6.6 with attributes: RP/0/0/CPU0:Sep 20 11:57:25.458 : bgp[1051]: [default-rtr] (vpn4u): nexthop 5.5.5.5/32, origin i, localpref 100, metric 0, originator 5.5.5.5, clusterlist 6.6.6.6, path 65000, extended community RT:100:1 RP/0/0/CPU0:Sep 20 11:57:25.458 : bgp[1051]: [default-rtr] (vpn4u): Received prefix 2ASN:100:1:8.8.8.8/32 (path ID: none) with MPLS label 27 from neighbor 6.6.6.6 RP/0/0/CPU0:Sep 20 11:57:25.458 : bgp[1051]: [default-rtr] (vpn4u): Prefix 2ASN:100:1:8.8.8.8/32 (path ID: none) received from 6.6.6.6 DENIED RT extended community is not imported locally ``` {% endcode %} * 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. ``` #R2, R4, R5 router bgp 100 address-family rtfilter unicast nei 3.3.3.3 act nei 6.6.6.6 act #XR1 router bgp 100 address-family ipv4 rt-filter ! neighbor 3.3.3.3 address-family ipv4 rt-filter ! ! neighbor 6.6.6.6 address-family ipv4 rt-filter ``` 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. ``` #R3, R6 router bgp 100 address-family rtfilter unicast nei 2.2.2.2 act nei 4.4.4.4 act nei 5.5.5.5 act nei 19.19.19.19 act ``` 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 \:2:\. (2 is the extcommunity type code). We also see a 100:258:\: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.” ``` #R3, R6 router bgp 100 template peer-policy IBGP_RT_FILTER default-originate exit ! address-family rtfilter unicast nei 2.2.2.2 inherit peer-policy IBGP_RT_FILTER nei 4.4.4.4 inherit peer-policy IBGP_RT_FILTER nei 5.5.5.5 inherit peer-policy IBGP_RT_FILTER nei 19.19.19.19 inherit peer-policy IBGP_RT_FILTER ``` 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: ``` #R3 debug bgp vpnv4 uni updates #R8 clear ip bgp * ```
Above we see that the update is denied towards R4 and XR1, but permitted towards R2 and (back to) R5. ## Summary 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://ccie-sp.gitbook.io/ccie-spv5.1-labs/labs/intra-as-l3vpn/rt-filter.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.