Date Tags notes

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 reference diagram:

Reference lab 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

  1. Why the RT prefix is contains both RT and AS number? What would happened if it was RT only?
  2. 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