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
Reading in 2015. Very useful post
ReplyDelete