RT-Constrain, VRF-Lite and Internet access in a VRF

Theoretical foundations and architecture

In a large network the Route Reflector by default sends every PE all VPNv4 routes of all customers, and the PE itself drops those whose Route Target is not imported by any local VRF. Thousands of PEs and millions of VPN prefixes turn this into needless load on the RR, the links and the PE CPU. RT-Constrain (RFC 4684) solves the problem on the sender side: a PE announces in a separate address family (AFI 1, SAFI 132) which Route Targets it needs, and the RR sends only the matching routes. The lesson covers the RTC route format, prefix matching, the default RT-constraint route, the RR hierarchy and the pitfalls of the initial exchange. The second part is VRF-Lite: several VRFs on one router without MPLS and MP-BGP, 802.1Q subinterfaces and a separate IGP per VRF. The third is Internet access for a VPN customer: a static route with the global keyword, a separate Internet VRF, the return route and notes on NAT. It assumes you know VRFs, RD/RT and the PE-CE protocols from the earlier lessons of the module.

Why RT-Constrain exists

Without extra measures a Route Reflector sends each client all VPNv4 routes it has received. The PE applies an implicit Route Target filter: a route whose RT is not imported by any local VRF is dropped (on Cisco this behaviour is disabled with no bgp default route-target filter). The wasted work has already happened: the RR built the update, the link carried it, the PE parsed the attributes. If a PE serves 5 VRFs out of several thousand, up to 99 percent of the received VPN routes are thrown away. This causes a load peak at a cold start of the RR (all clients come up at once) and on a session restart, and it delays the convergence of the needed routes in the shared update queue.

The mechanism of RFC 4684

RT-Constrain adds the address family AFI 1, SAFI 132 (Route Target Constraint, RTC). Its NLRI consists of a 4-byte origin AS and an 8-byte Route Target (an extended community): up to 12 bytes in total, that is up to 96 prefix bits. A PE creates an RTC route for every import RT of every VRF, usually with the origin AS equal to the local AS, and sends it to its neighbor. The neighbor (the RR) uses the received RTC routes as an outbound filter for that peer: a VPN route (SAFI 128 or VPNv6) is sent if at least one of its RTs matches one of the peer's RTC prefixes. If a peer did not negotiate the RTC family, no filtering is applied to it and the behaviour stays as before, so the rollout can be done in stages.

The match is by prefix. A full RTC route (96 bits) selects one specific RT. The shorter the prefix, the wider the coverage: 32 bits cover all RTs with a given origin AS, and length 0 is the default RT-constraint route, meaning "send me everything". It is used by nodes without their own filtering (for example a monitoring system or a top-level RR that needs all customer routes) and by an RR when the restriction must be switched off for a client. Cisco originates it with default-originate in the rtfilter family, Junos with advertise-default (check the exact syntax on your release).

Dynamics: what happens when an RT changes

An import RT is added to a VRF: the PE sends a new RTC route and the RR answers by sending the accumulated VPN routes with that RT, without a route refresh. An RT is removed: the RTC route is withdrawn, and the sender normally withdraws the already sent routes that are no longer needed. A mass RT edit in VRFs therefore produces an update burst on the RR: make such changes in batches during the maintenance window. Many implementations delay the first advertisement of VPN routes until they receive the RTC End-of-RIB or a timer expires, so as not to send surplus: if RTC is enabled on the client but not activated, VPN routes may arrive late - this is normal and is the first thing to check on the complaint "the VRF is up but there are no routes".

RR scaling and hierarchy

RTC does not reduce RR memory: it still holds all VPN routes in the Adj-RIB-In, only outbound distribution is filtered. The gain is in updates, bandwidth, client CPU and convergence time. To save RR memory, RRs are partitioned by client sets (RR1 serves some VPNs, RR2 the others) and the partitioning is combined with RTC. In a client - RR - top-level RR hierarchy the lower RR aggregates the RTC routes of its clients and advertises the combined set upward; identical RTCs from different PEs become a single path by best-path selection, and this must be considered for ECMP and add-path: verify that the upstream receives enough RTC paths, otherwise it will see one source instead of two. Between autonomous systems RTC works over eBGP: an ASBR advertises RTC routes with the origin AS of its own AS, and in Option B/C RTC reduces the volume exchanged between ASBRs (see RFC 4684 for details).

VRF-Lite

VRF-Lite is only the local part of a VPN: several independent RIBs and FIBs on one router, without labels and without MP-BGP. Separation is achieved by binding interfaces to a VRF; between routers each VRF needs its own link (a physical port or an 802.1Q subinterface with a separate VLAN) and its own routing process or a separate address family in BGP. On Cisco the RD is not mandatory in such a VRF, and RT is not used, because routes are not exchanged between VRFs through BGP. Typical uses: Multi-VRF CE (a customer router splits local networks), campus segmentation, the data center, and a PE-PE hand-off in the Inter-AS Option A scheme (back-to-back VRF).

Limitations: each VRF needs a subinterface, an IGP/BGP session and its own configuration set, so hundreds of VRFs do not scale manually, and this is what L3VPN is for. On Cisco every VRF with OSPF is a separate process (router ospf 30 vrf GUEST), and the number of processes is platform-limited. Table size limits are shared: VRFs share the device TCAM and FIB.