RT Constrain
RT Constrain
Introduction
In an BGP/MPLS VPN environment (with or without Route-Reflectors), a PE router advertises VPNv4 prefixes in MP-BGP UPDATE messages to all remote PE routers for all configured VRFs. The UPDATE message also carries a BGP Extended Community called Route-Target (RT). The remote PEs "filter" received routes based on RT to control distribution of routes in VRFs.
Consider the figure below.
For this BGP/MPLS VPN network, R1 is configured to export prefix 192.168.1.0/24 from VRF A with RT 100:1 and 192.168.11.0/24 from VRF B with RT 100:2 to the route-reflector (RR). The RR reflects these prefixes to R3 and R4, only for R3 to discard the prefix 192.168.11.0/24 and R4 to discard the prefix 192.168.1.0/24. This is due to RT filtering. R3 is configured to import prefixes with RT 100:1 only into VRF A, while R4 is configured to import prefixes with RT 100:2 only into VRF B. This can be seen in the following debug output. As seen in the debug output, R3 only installs 192.168.1.0/24 in VRF A RIB. The same holds true for R4.
R3: "debug ip bgp vpnv4 unicast updates"
%BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up
BGP: nbr_topo global 2.2.2.2 VPNv4 Unicast:base (0x69318644:1) rcvd Refresh Start-of-RIB
BGP: nbr_topo global 2.2.2.2 VPNv4 Unicast:base (0x69318644:1) refresh_epoch is 2
BGP(4): 2.2.2.2 rcvd UPDATE w/ attr: nexthop 1.1.1.1, origin ?, localpref 100, metric 0, originator 1.1.1.1, clusterlist 2.2.2.2, extended community RT:100:1
BGP(4): 2.2.2.2 rcvd 1.1.1.1:1:192.168.1.0/24, label 17
BGP(4): 2.2.2.2 rcvd UPDATE w/ attr: nexthop 1.1.1.1, origin ?, localpref 100, metric 0, originator 1.1.1.1, clusterlist 2.2.2.2, extended community RT:100:2
BGP(4): 2.2.2.2 rcvd 1.1.1.1:2:192.168.11.0/24, label 16 -- DENIED due to: extended community not supported;
BGP: nbr_topo global 2.2.2.2 VPNv4 Unicast:base (0x69318644:1) rcvd Refresh End-of-RIB
BGP(4): Revise route installing 1 of 1 routes for 192.168.1.0/24 -> 1.1.1.1(A) to A IP table
Controlled Route Distribution
RFC 4684 introduces a way for PE routers to advertise RT membership [to remote PEs in case of iBGP full-mesh, or to RR]. The RT membership is advertised in BGP UPDATE messages using the MP_REACH_NLRI path-attribute (and withdraws are done using MP_UNREACH_NLRI path-attribute). The NLRI format is of the form [Origin AS Number, Route-Target]. The AFI/SAFI used to identify this NLRI is 1/132 and the capabilities are negotiated in BGP OPEN messages.
The significance of Origin AS number in the NLRI will be shown later in Inter-AS VPN scenario.
R3: Capability Negotiated
R3# show ip bgp vpnv4 all neighbors 2.2.2.2
<--- Output Omitted --->
Neighbor capabilities:
Route refresh: advertised and received(new)
Four-octets ASN Capability: advertised and received
Address family VPNv4 Unicast: advertised and received
Address family RT Filter: advertised and received
Enhanced Refresh Capability: advertised and received
Multisession Capability:
Stateful switchover support enabled: NO for session 1
This is feature is configured under BGP using the command address-family rtfilter unicast.
RR Configuration
router bgp 100
<--- Output Omitted --->
address-family rtfilter unicast
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 send-community extended
neighbor 1.1.1.1 route-reflector-client
neighbor 1.1.1.1 default-originate
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 send-community extended
neighbor 3.3.3.3 route-reflector-client
neighbor 3.3.3.3 default-originate
neighbor 4.4.4.4 activate
neighbor 4.4.4.4 send-community extended
neighbor 4.4.4.4 route-reflector-client
neighbor 4.4.4.4 default-originate
exit-address-family
Note the command neighbor x.x.x.x default-originate. This is enabled by default on RR towards the RR-Clients to advertise RT membership for any Route-Targets. This is also called default route-target.
The following debug output shows RT membership information received by RR.
RR: debug ip bgp rtfilter unicast updates
BGP(10): 4.4.4.4 rcvd UPDATE w/ attr: nexthop 4.4.4.4, origin i, localpref 100, metric 0
BGP(10): 4.4.4.4 rcvd 100:2:100:2
BGP(10): 3.3.3.3 rcvd UPDATE w/ attr: nexthop 3.3.3.3, origin i, localpref 100, metric 0
BGP(10): 3.3.3.3 rcvd 100:2:100:1
BGP(10): 1.1.1.1 rcvd UPDATE w/ attr: nexthop 1.1.1.1, origin i, localpref 100, metric 0
BGP(10): 1.1.1.1 rcvd 100:2:100:1
BGP(10): 1.1.1.1 rcvd 100:2:100:2
Note the debug output shows NLRI of the form 100:2:100:1. This can be broken down into -
AS Number: 100
BGP Extended Community Type Code: 2
Route-Target: 100:1
To view the RT membership information is received from BGP peers, use show ip bgp vpnv4 all neighbor x.x.x.x received rtfilter command.
RR# show ip bgp vpnv4 all nei 1.1.1.1 received rtfilters
Address family: VPNv4 Unicast
Extended community filter has: 2 entries with default filtering disabled
Incremental refresh walk mode
Status codes: * valid, S Stale > installed
Route-Target Outbound Filter
*> Extended Community RT:100:2
*> Extended Community RT:100:1
RR# show ip bgp vpnv4 all nei 3.3.3.3 received rtfilters
Address family: VPNv4 Unicast
Extended community filter has: 1 entries with default filtering disabled
Incremental refresh walk mode
Status codes: * valid, S Stale > installed
Route-Target Outbound Filter
*> Extended Community RT:100:1
RR# show ip bgp vpnv4 all nei 4.4.4.4 received rtfilters
Address family: VPNv4 Unicast
Extended community filter has: 1 entries with default filtering disabled
Incremental refresh walk mode
Status codes: * valid, S Stale > installed
Route-Target Outbound Filter
*> Extended Community RT:100:2
As seen above, the RR receives specific RT membership information from each PE router. Then the RR effectively translates this information into outbound route-filtering and sends only those prefixes to PEs for which it has a matching RT in its BGP table.
R3 receives prefix with RT 100:1 only
2.2.2.2 rcvd UPDATE w/ attr: nexthop 1.1.1.1, origin ?, localpref 100, metric 0, originator 1.1.1.1, clusterlist 2.2.2.2, extended community RT:100:1
2.2.2.2 rcvd 1.1.1.1:1:192.168.1.0/24, label 17
Revise route installing 1 of 1 routes for 192.168.1.0/24 -> 1.1.1.1(A) to A IP table
It must be noted that the RFC places two rules for Intra-AS RT membership information distribution. The rules are kept in place because BGP will perform best-path selection on the NLRI information received in BGP UPDATE messages and hence must guarantee a valid path must exist to the origin of the RT membership information advertisement. The first rule is-
"When advertising RT membership NLRI to a route-reflector client, the Originator attribute shall be set to the router-id of the advertiser, and the Next-hop attribute shall be set of the local address for that session."
This is important when RRs are used in Intra-AS scenarios. For example, R1 and R3 both distribute RT 100:1. When RR reflects R1's RT membership information to R3, RR sets the Originator ID to itself (2.2.2.2, rather than 1.1.1.1). This informs R3 that RR needs prefixes with RT 100:1. If the Originator ID was not changed, R3 cannot know that RR is expecting prefixes with RT 100:1 (which will then be reflected to R1).
The second rule is-
"When advertising an RT membership NLRI to a non-client peer, if the best path as selected by the path selection procedure described in Section 9.1 of the base BGP specification [4] is a route received from a non-client peer, and if there is an alternative path to the same destination from a client, the attributes of the client path are advertised to the peer."
Inter-AS MPLS VPN
Consider the figure below.
In this figure, R5 in AS200 and R6 in AS300 require prefixes with RT 100:1, and R6 in AS300 also requires prefixes with RT 100:2. So, the flooding graph from AS100 should include AS200 and AS300 for RT 100:1, but should only include AS300 for RT 100:2.
If AS number was not included in the RT membership information advertisement, ASBR1 would end up selecting only one path for RTs, and "prune" duplicate paths. This would not result in building a proper flooding graph for route distribution. The inclusion of AS number provides uniqueness to RT membership information, and additional information required for selecting best-path towards the originating AS.
Summary
RT Constrain provides a way to distribute only the required information to ASes using a new SAFI 132. This is yet another way to scale BGP by lowering processing of BGP messages. Note that with the IOS (15.2(4)S3) I tested, the PEs don't advertise the RTs in RT membership information advertisement defined using Import-map.
References:
RFC 4684 : Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)