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

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

• 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 <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.”

#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.