I write this post as I go through Route Target Constraint (RFC 4364) feature. I'll try to answer below questions:
- What problem does it solve?
- How vendor support does look like?
- What are deployment considerations?
Before looking into the feature, let's think for a moment how typical network involving route reflection works.
Here is the reference diagram:
In this setup, we have simplistic service provider network with two geographically distant POPs, let's say POP West and POP East. Each POP has its own route reflector which serves PEs within its own POP. Both RRs are connected as non-clients.
Now, let's assume there is a customer, let's call him RED, which has multiple CEs attached to POP West. There are two issues with this design:
- RR1 will reflect VPN RED routes according to regular BGP rules, which means it will waste CPU cycles and bandwidth to replicate VPN RED route updates towards MX16, which doesn't have RED CEs connected, thus not needing the prefixes
- VPN RED routes will be reflected to RR2, even though its clients may not need the routes (because of no connected CEs)
Second issues is more significant and cause that entire BGP design scale in terms of total number of VPN routes present in the network.
So, we can say that Route Target Constraint (Constrained Route Distribution or Route Target Filtering) is designed to reduce bandwidth, CPU and memory utilization on RRs and PEs by constraining the NLRI distribution to nodes that really need them.
The feature works by utilizing additional Address Family (AFI=1, SAFI=132) across BGP peerings. It has to be supported both by PEs and RRs. After the capability is negotiated, PE will signal all the RTs that it indents to import. Route Reflector will use this information to build an outbound filter towards the PE. In reverse direction, RR sends a RT default route indicating that it wants to receive all prefixes from PE.
IOS XR as a RR
In the first scenario, I will look at IOS XR working as a route reflector for 3 clients (IOS XR, IOS XE and Junos). Each of the clients has VRF RED (RT 123:1) configued. In addition, R2 has VRF BLUE (RT 123:2) configured.
Configuration of RR can be seen below:
router bgp 123
bgp router-id 3.3.3.3
bgp cluster-id 123.1.1.1
address-family vpnv4 unicast
!
address-family vpnv6 unicast
!
address-family ipv4 rt-filter
!
session-group iBGP
remote-as 123
update-source Loopback0
!
neighbor-group PE
address-family vpnv4 unicast
route-reflector-client
!
address-family vpnv6 unicast
route-reflector-client
!
address-family ipv4 rt-filter
route-reflector-client
!
!
neighbor 1.1.1.1
use session-group iBGP
use neighbor-group PE
!
neighbor 2.2.2.2
use session-group iBGP
use neighbor-group PE
!
neighbor 16.16.16.16
use session-group iBGP
use neighbor-group PE
!
!
Configuration of R1:
router bgp 123
bgp router-id 1.1.1.1
address-family vpnv4 unicast
!
address-family vpnv6 unicast
!
address-family ipv4 rt-filter
!
session-group iBGP
remote-as 123
update-source Loopback0
!
neighbor-group PE
address-family vpnv4 unicast
!
address-family vpnv6 unicast
!
address-family ipv4 rt-filter
!
!
neighbor 3.3.3.3
use session-group iBGP
use neighbor-group PE
!
vrf RED
rd 1.1.1.1:1
address-family ipv4 unicast
!
address-family ipv6 unicast
!
neighbor 10.1.14.14
remote-as 65001
address-family ipv4 unicast
route-policy PASS-ALL in
route-policy PASS-ALL out
as-override
!
!
neighbor fd00::10:1:14:14
remote-as 65001
address-family ipv6 unicast
route-policy PASS-ALL in
route-policy PASS-ALL out
!
!
!
!
Configuration of R2:
router bgp 123
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 3.3.3.3 remote-as 123
neighbor 3.3.3.3 update-source Loopback0
!
address-family ipv4
exit-address-family
!
address-family vpnv4
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 send-community extended
exit-address-family
!
address-family vpnv6
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 send-community extended
exit-address-family
!
address-family rtfilter unicast
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 send-community extended
exit-address-family
!
address-family ipv4 vrf BLUE
redistribute connected
exit-address-family
!
address-family ipv6 vrf BLUE
redistribute connected
exit-address-family
!
address-family ipv4 vrf RED
neighbor 10.2.15.15 remote-as 65001
neighbor 10.2.15.15 activate
neighbor 10.2.15.15 as-override
exit-address-family
!
address-family ipv6 vrf RED
neighbor FD00::10:2:15:15 remote-as 65001
neighbor FD00::10:2:15:15 activate
neighbor FD00::10:2:15:15 as-override
exit-address-family
Configuration of MX16:
protocols {
bgp {
group Internal {
type internal;
neighbor 3.3.3.3 {
family inet-vpn {
unicast;
}
family inet6-vpn {
unicast;
}
family route-target;
}
}
}
}
routing-instances {
RED {
instance-type vrf;
interface ge-0/0/4.101;
route-distinguisher 16.16.16.16:1;
vrf-target {
import target:123:1;
export target:123:1;
}
vrf-table-label;
protocols {
bgp {
group EXTERNAL {
type external;
neighbor 10.16.17.17 {
family inet {
unicast;
}
peer-as 65001;
as-override;
}
}
}
}
}
}
Looking at R3, we see that it receives 123:3:123:1/96 routes from their clients.
RP/0/0/CPU0:R3#show bgp ipv4 rt-filter
Wed Apr 11 12:36:45.579 UTC
BGP router identifier 3.3.3.3, local AS number 123
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000 RD version: 8
BGP main routing table version 8
BGP NSR Initial initsync version 2 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i123:2:123:1/96 1.1.1.1 100 32768 i
* i 2.2.2.2 0 100 32768 i
* i 16.16.16.16 100 32768 i
*>i123:2:123:2/96 2.2.2.2 0 100 32768 i
R2# show bgp vpnv4 unicast all neighbors 3.3.3.3 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:123:1
*> Extended Community RT:123:2
Questions to be answered
- Why the RT prefix is contains both RT and AS number? What would happened if it was RT only?
- If we have a BGP session with multiple AF and AFI=1,SAFI=132, then how does the router know to which AFs the filter should be applied?
Comments
comments powered by Disqus