Optimizing your weak links: BGP route-target constraints

In: Networking

When you need to be conscious about your MPLS router’s control plane resources, RFC 4684 Constrained Route Distribution for BGP/MPLS IP VPNs (RTC) is a no-brainer. RTC is a BGP address-family that allows operators to prevent their route-reflectors from sending unimportant routes.

Lets take a look at the topology and review what a standard MPLS network might look like.

Above we have 4 PE routers iBGP peered with a central route-reflector (RR) and two transit P routers with no BGP sessions (BGP free core). Additionally, address-family inet-vpn is being sent between all routers.

When the PE router initiates the BGP session with the RR, they will start exchanging routes as expected. In a sufficiently large network, this is hundreds of thousands or millions of routes. All those routes get sent whether or not the PE is going to need them; the responsibility of which routes to keep rests on the shoulders of the PE.

To determine if a route is kept, the PE router is going to analyze all the routing-instance VRF import policies and place received routes with matching route-targets in the bgp.l3vpn.0 routing table. Then routes are copied into their respective routing-instances routing tables.

policy-options {
    policy-statement PL-VRF-VPN-INET-IMP {
        term VPN-INET {
            from community RT-VPN-INET;
            then accept;
        }
    }
	community RT-VPN-INET members target:65000L:100;
}

routing-instances {
    vpn-inet {
        instance-type vrf;
        route-distinguisher 172.18.20.1:100;
        vrf-import PL-VRF-VPN-INET-IMP;
        vrf-table-label;
    }
}
Example of a VPN VRF import policy applied to a routing-instance

So, if the receiving router is already filtering routes that aren't going to be used to prevent further processing, what more can we improve on? Well, what if we simply don't send routes that aren't going to be used?

For obvious reasons, the RR doesn't know if it is exporting a route that is going to be dropped by the PE due to routing policy or unresolvable next-hops. However, we can tell the RR what communities we have locally configured to import into our bgp.l3vpn.0 table which means we can skip an entire step in the process and potentially prevent the processing of millions of routes.

To enable BGP RTC, add the following configuration:

# RR
set protocols bgp group [group] family route-target advertise-default

# PE
set protocols bgp group [group] family route-target

This configuration is going to add an additional auxiliary table called bgp.rtarget.0 where the router can advertise and receive communities that enable the peers to only send what the local PE plans on processing.

The route reflector is going to tell the clients to send it everything

RR advertised route-targets (give me everything)

But the improvement here is that the PE can now signal what it wants from the PE router by advertising the route-targets it has configured.

PE advertised route-targets (give me routes with these targets)

This optimization may not seem like much, but consider that various triggers exist that could cause the route-reflector to send all the routes (potentially millions) to the PE router. Also consider that the PE router could exist only for a single customer L3VPN and may not have the significant control-plane resources your standard PE router may have.

An overloaded ACX router
An ACX not being overloaded because BGP RTC is being implemented

Sources

Comments
More from Schy Networks
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Schy Networks.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.