Friday 7 September 2012

BGP RT Constrained Route Distribution


BGP RT Constrained Route Distribution is described in RFC 4684 and provides a mechanism for MP-BGP peers to exchange RT (route target) information and automatically filter outbound route updates based on this information.

Background
Before BGP RT Constrained Route Distribution, the default behaviour for a MP-BGP session would be to send all VPNv4 routes to the configured peer regardless of the peer's VPN membership.  This will mean that a PE with a relatively small VPN membership will receive routes for every VPN on the network from a route reflector.  The PE will filter the routes ingress and discard any routes where the RT value does not match a local VRF.  However wouldn’t it make more sense to filter the routes on egress?  If you’re reading this and thinking, I can do that with ORF, then yes you can.  However, it requires the administrator to manually define the list of routes.

By using BGP RT Constrained Route Distribution then MP-BGP speakers can exchange RT information and will then only send VPNv4 routes which the peer BGP speaker requires.

Technical Details
On initial BGP peer start up (OPEN message) the BGP speakers will exchange capabilities.  For MP-BGP this includes a capability code of 1, as described in RFC 2854.  Within this capability code, each BGP speaker will signal that it supports AFI 1, SAFI 132 (in addition to the normal SAFI 128).


At this point, BGP speakers will normally start to exchange UPDATE messages which include routing information.  However, with BGP RT Constrained Route Distribution the BGP speakers will first exchange update messages with AFI=1, SAFI=132.  These UPDATE messages have RT values encoded in MP_REACH_NLRI or MP_UNREACH_NLRI attributes.  The example below shows a PE signalling RT values of 179:100 and 179:102.


After the exchange of RT information, standard UPDATE messages with VPNv4 prefixes are exchanged (but only for the relevant RTs !!).

Cisco Implementation
On a Cisco platform then all we need to do is enable an additional address family (SAFI) for each BGP peer by configuring the below commands.  The neighbour IP should be a VPNv4 peer (whether it be the IP of a PE or a RR).

On PE or RR Routers
router bgp 179
 address-family rtfilter unicast
  neighbor A.B.C.D activate
  neighbor A.B.C.D send-community extended
 exit-address-family

If we are using RRs then by default, the RR will send a default RT of 0:0:0/0 (aka wildcard RT) effectively asking the PEs to “send me all your routes”.  The packet capture below shows this


However, we can also configure any router to send a default RT with the following command

router bgp 179
 address-family rtfilter unicast
  neighbor A.B.C.D default-originate

Lastly some show commands to check it’s working are below
#sh ip bgp neighbors A.B.C.D | i RT Filter:
    Address family RT Filter: advertised and received
#sh ip bgp rtfilter

Juniper Implementation
On Junos, similarly, all we need to do is configure the additional address family (SAFI) on each BGP peer.  The neighbour IP should be a VPNv4 peer (whether it be the IP of a PE or a RR).

On PE or RR Routers
# set protocols bgp group IBGP neighbor A.B.C.D family route-target

For Junos, the RR will send a default RT in the exact same way as Cisco.  But we can configure any router to send a default RT with the following command

# set protocols bgp group IBGP neighbor A.B.C.D family route-target advertise-default

Lastly some show commands to check it’s working are below
> show bgp neighbor | match NLRI | match session
  NLRI for this session: inet-vpn-unicast route-target
> show route table bgp.rtarget.0

Notes and References

This feature was introduced into IOS in version 15.1 and Junos before version 7.4.
You will need wireshark 1.7.1 or later to decode SAFI 132.

http://tools.ietf.org/html/rfc4684

About the Author

The author of this blog works for Vanguard IT who provide a range of professional services and managed services

For more information go to https://vanguard-it.net

1 comment: