Partitioned RRs

Load vpnv4.partitioned.rr.init.cfg

#IOS-XE
config replace flash:vpnv4.partitioned.rr.init.cfg 

#IOS-XR
configure
load bootflash:vpnv4.partitioned.rr.init.cfg 
commit replace
y

L3VPN is fully setup, except for iBGP within the core. All PEs are already configured to peer with both RRs.

R3 should only reflect routes for VPN_A, and R6 should only reflect routes for VPN_B. When you look at the VPNv4 table on each RR, you should only see VPN_A routes on R3, and VPN_B routes on R6. Achieve this by only configuring the RRs.

Answer

#R3
ip extcommunity-list standard PERMITTED_VPNv4 permit rt 100:1

#R6
ip extcommunity-list standard PERMITTED_VPNv4 permit rt 100:2

#R3 & R6
router bgp 100
 template peer-session IBGP
  remote-as 100
  update-so lo0
 exit-peer-session
 !
 template peer-policy IBGP
  route-reflector-client
 exit-peer-policy
 !
 neighbor 2.2.2.2 inherit peer-session IBGP
 neighbor 4.4.4.4 inherit peer-session IBGP
 neighbor 5.5.5.5 inherit peer-session IBGP
 neighbor 19.19.19.19 inherit peer-session IBGP
 !
 add vpnv4
  bgp rr-group PERMITTED_VPNv4
  neighbor 2.2.2.2 activate
  neighbor 2.2.2.2 inherit peer-policy IBGP
  neighbor 4.4.4.4 activate
  neighbor 4.4.4.4 inherit peer-policy IBGP
  neighbor 5.5.5.5 activate
  neighbor 5.5.5.5 inherit peer-policy IBGP
  neighbor 19.19.19.19 activate
  neighbor 19.19.19.19 inherit peer-policy IBGP

Explanation

By default, a RR disables its local RT filter, which allows it to reflect VPNv4 routes for which it does not locally have a VRF importing the matching RT. We can control this using the bgp rr-group command. This takes a named extcommunity-list as a sort of RT ACL. Any received routes with RTs not permitted in the extcommunity-list are discarded.

In our lab, we specified the individual VPN RTs that each RR will permit.

#R3
ip extcommunity-list standard PERMITTED_VPNv4 permit rt 100:1

#R6
ip extcommunity-list standard PERMITTED_VPNv4 permit rt 100:2

#R3 & R6
router bgp 100
 add vpnv4
  bgp rr-group PERMITTED_VPNv4

We only have two VRFs in our lab, so this works fine. But if we had hundreds of VRFs, this would not scale well. (And this feature is only used for scalability in the first place, when lots of VRFs are defined in the core).

Note that a better option might be to designate a unique RT for each RR. Then each customer VRF would export two RT values: one for the VPN membership, and one for which RR should reflect the VPNv4 routes.

Verification

We turn on VPNv4 update debugging and refresh VPNv4 inbound on R3.

#R3
debug bgp vpnv4 uni udpate in
clear bgp vpnv4 uni * soft in

We can see that the VPN_B routes are denied by the RT filter. 100:2 is not permitted.

All we see in R3’s local VPNv4 table are VPN_A routes:

Challenge

Let’s change the RT policy so that R3 and R6 each have a unique RT they are matching:

#R3
no ip extcommunity-list standard PERMITTED_VPNv4 permit rt 100:1
!
ip extcommunity-list standard PERMITTED_VPNv4 permit rt 100:3

#R6
no ip extcommunity-list standard PERMITTED_VPNv4 permit rt 100:2
!
ip extcommunity-list standard PERMITTED_VPNv4 permit rt 100:6

On the PEs, we export the appropriate RTs in addition to the regular RTs. Except we make a mistake on R5, exporting R6’s RT instead of R3. The question is: will this break the L3VPN?

#R2
vrf definition VPN_A
 rd 100:1
 route-target export 100:1
 route-target export 100:3
 route-target import 100:1

#R4
vrf definition VPN_B
 rd 100:2
 route-target export 100:2
 route-target export 100:6
 route-target import 100:2

#R5
vrf definition VPN_A
 rd 100:1
 route-target export 100:1
 route-target export 100:6
 route-target import 100:1

#XR1
vrf VPN_B
 address-family ipv4 unicast
  import route-target
   100:2
  !
  export route-target
   100:2
   100:6

The answer is that the L3VPN is still fully operational. The reason is that both R2 and R5 peer with both RRs. R3 will reflect 1.1.1.1/32, and R6 will reflect 8.8.8.8/32, so there is no issue.