MPLS Layer 3 VPNs (L3 VPNs) are a highly scalable way to deliver private multitenant connectivity. This article will not focus on overall L3VPN operation but will focus on Route Target Constraint, a control plane scaling feature.

I’ll be using the topology below for demonstration. Ther is a lot going on here, so I circled the nodes we’re interested in. There is a functional L3VPN service connecting CUST2_CE1 and CUST2_CE2. These CEs are hanging off PE1 and PE3. RR2 serves as a route reflector for the VPN network. RR1 is not functional and can be ignored. There is no CE for CUST2 attached to PE2.

Suppose for a moment that CUST2_CE1 starts originating a new route and advertises it to PE1 so the provider can announce the route to CE2. PE1 would receive the route and announce it to RR2. All PEs in the network are route-reflector clients. RR2 would run best path and reflect the results to all other PEs in the network. The inefficiency comes in that all PEs receive the route advertisement even though only 1 PE has a VRF for CUST2. Only 1 PE needs to receive the route, but it is sent to everyone anyways. The RR has no way of knowing which PEs are willing to import which route-targets (RTs).

The INET_GW routers serve as PEs also. Only PE3 needs to receive the CUST2_CE1 route but it is reflected to all the routers indicated below, just for most PEs to discard the routes.

We can verify the route advertisement behavior. PE2 does not need to receive routes for CUST2 but will anyways. Enabling a debug for VPNv4 updates on PE2 and triggering a route-refresh confirms that PE2 receives routes for the CUST2 VPN even though it doesn’t need them. PE2 discards the updates. The CUST2 VPN is using RT 65000:22 on both PEs.

PE2#debug bgp vpnv4 unicast updates 
BGP updates debugging is on for address family: VPNv4 Unicast 
PE2#clear ip bgp * soft
PE2#
*Jun 28 11:25:16.302: BGP: nbr_topo global 4.4.4.5 VPNv4 Unicast:base (0x732058C80020:1) rcvd Refresh Start-of-RIB
*Jun 28 11:25:16.302: BGP: nbr_topo global 4.4.4.5 VPNv4 Unicast:base (0x732058C80020:1) refresh_epoch is 3
*Jun 28 11:25:16.302: BGP: nbr_topo global 4.4.4.5 IPv4 Unicast:base (0x732058C80020:1) rcvd Refresh Start-of-RIB
*Jun 28 11:25:16.302: BGP: nbr_topo global 4.4.4.5 IPv4 Unicast:base (0x732058C80020:1) refresh_epoch is 2
*Jun 28 11:25:16.307: BGP(4): 4.4.4.5 rcvd UPDATE w/ attr: nexthop 3.0.0.3, origin i, localpref 100, metric 0, originator 3.0.0.3, clusterlist 4.4.4.5, merged path 65000, AS_PATH , extended community RT:65000:22
*Jun 28 11:25:16.307: BGP(4): 4.4.4.5 rcvd 65000:2:44.44.44.0/24, label 36 (0x24) -- DENIED due to:  extended community not supported;
*Jun 28 11:25:16.308: BGP(4): 4.4.4.5 rcvd UPDATE w/ attr: nexthop 1.0.0.1, origin i, localpref 100, metric 0, originator 1.0.0.1, clusterlist 4.4.4.5, merged path 65000, AS_PATH , extended community RT:65000:22
*Jun 28 11:25:16.308: BGP(4): 4.4.4.5 rcvd 65000:2:22.22.22.0/24, label 16 (0x10) -- DENIED due to:  extended community not supported;
*Jun 28 11:25:16.308: BGP: nbr_topo global 4.4.4.5 VPNv4 Unicast:base (0x732058C80020:1) rcvd Refresh End-of-RIB
PE2#
*Jun 28 11:25:16.308: BGP: nbr_topo global 4.4.4.5 IPv4 Unicast:base (0x732058C80020:1) rcvd Refresh End-of-RIB

This route advertisement behavior could cause significant overhead in large MPLS VPN networks. Consider a VPN provider with thousands of customers and a million routes. Any CE maintenance would cause the entire VPNv4 table on the route-reflector to be advertised to the CE, regardless of how many routes are needed.

Route Target Constraint is an extension to BGP to reduce advertisement overhead. RTC is implemented as a standalone address-family. It works by allowing PEs to advertise their RT import lists as MP_REACH_NLRI and MP_UNREACH_NLRI, essentially allowing PEs to ‘subscribe’ to route-targets they wish to receive. Both peers must support and be configured for the rtfilter AFI for the feature to work. It can be rolled out incrementally though. Peers that are not active in the rtfilter AFI receive the full VPNv4 BGP feed as normal.

Configuration and Operation

For the demo network we can configure RR2 and PE2 to support route target constraint so that PE2 doesn’t receive the CUST2 routes anymore.

RR2 Configuration:

To enable the feature, we just need to activate the BGP peer(s) in address-family rtfilter.

PE2 Configuration:

Post-release edit! The PEs also need to be configured as route-reflector clients within the rtfilter AFI! It took me a few minutes to realize why the network no longer functioned after enabling RT filter. Without reflecting the RT constraint updates, the PEs stopped advertising routes to the RR. Route Target Constraint is a two way street!

Now that PE2 is using RT constraint, we can trigger another route refresh to confirm PE2 does not receive the CUST2 VPN routes. No routes are received just so they can be dropped.

Let’s enable RT constraint on PE3 so we can see it subscribe to CUST2s VPN routes. I left a debug running on the route-reflector to capture rtfilter enablement.

PE2 is importing RT 65000:22 for the CUST2 VRF.

Using the command shown, we can confirm that RR2 received a ‘subscription’ to RT 65000:22 from PE3 (aka 3.0.0.3).

If we were to add a new VRF to PE3 with a different import RT, PE3 would send an rtfilter update to the route-reflector to ‘subscribe’ to this newly needed route set. As stated earlier, this could greatly reduce the amount of unnecessary route advertisements in large scale VPN networks.

Thanks for stopping by! Hopefully this helped you gain a high level understanding of how RT Constraint can be used to reduce unnecessary BGP updates in MPLS VPN networks.