Академический Документы
Профессиональный Документы
Культура Документы
From CT3
By Ivan Pepelnjak
Route reflector is an IBGP feature that allows you to build scalable IBGP networks. The original BGPv4
(http://tools.ietf.org/html/rfc1771) contained no intra-AS loop prevention mechanism; routers were therefore
prohibited from sending routes received from an IBGP peer to another IBGP peer, requiring a full-mesh of
IBGP sessions between all BGP routers within an AS.
New BGP standard (RFC 4271 (http://tools.ietf.org/html/rfc4271) ) includes references to
the BGP route reflector functionality.
Route reflector functionality (defined in RFC 4456 (http://tools.ietf.org/html/rfc4456) ) adds a new attribute
(cluster list) which can detect route propagation loops within an AS, the full-mesh requirement is thus
significantly relaxed.
Contents
1 Route Reflector rules
2 Monitoring Route Reflection
3 Loop Detection and Avoidance
4 Route Reflector Design Rules
5 Cluster-ID is Obsolete
6 Additional Resources
http://wiki.nil.com/BGP_route_reflectors
1/7
25/2/2014
If the route does not have the Originator ID attribute (it has not been reflected before), the router ID of
the IBGP peer from which the route has been received is copied into the Originator ID attribute.
If the route does not have the Cluster list attribute, its added to the route.
The value configured with the bgp cluster-id router configuration command (or the router ID of the
route reflector if the cluster-id is not configured) is prepended to the Cluster list attribute.
Route reflector does not change or remove any other attributes of the reflected routes (even non-transitive
attributes), ensuring that the IBGP routes are not changed within the autonomous system.
The next-hop-self neighbor configuration parameter or (most of the) set options of
outbound route-map configured on route-reflector clients are ignored for reflected routes.
BGP next-hop can be changed set ip next-hop route map command (BGP next hop
propagation feature
(http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fs_bgpnh.html) introduced in
IOS release 12.2)
Standard and extended BGP communities are removed from the reflected routes unless
the neighbor send-community [both] is configured on the route reflector. The link
bandwidth community is removed from reflected route if the route-reflector performs
IBGP multipath load-sharing for that route.
The same command will also indicate whether a route was received from a route-reflector client (and will thus
be reflected to all IBGP peers):
RR#show ip bgp 10.2.2.0
BGP routing table entry for 10.2.2.0/24, version 18
Paths: (2 available, best #2, table default)
Multipath: eBGP iBGP
Flag: 0x1A20
Advertised to update-groups:
1
65001, (Received from a RR-client)
10.0.1.2 (metric 65) from 10.0.1.2 (10.0.1.2)
Origin IGP, metric 0, localpref 100, valid, internal, multipath
65001, (Received from a RR-client)
10.0.1.1 (metric 65) from 10.0.1.1 (10.0.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, multipath, best
The route propagation policy of a route reflector is also displayed in the show ip bgp update-group printout:
http://wiki.nil.com/BGP_route_reflectors
2/7
25/2/2014
3/7
25/2/2014
BGP route reflectors combined with IBGP full mesh between core routers
http://wiki.nil.com/BGP_route_reflectors
4/7
25/2/2014
With the improved IBGP loop avoidance, you could use more relaxed designs, ranging from route-reflectorclient being configured on every IBGP neighbor to designs where the edge routers act as route reflector clients
and all other BGP routers in the AS act as route reflectors.
http://wiki.nil.com/BGP_route_reflectors
5/7
25/2/2014
Cluster-ID is Obsolete
Cisco IOS implementation of route reflector functionality supports the bgp cluster-id parameter, which is used
in the Cluster list attribute instead of the Router ID. The cluster-id parameter is useful in redundant route
reflector scenarios where multiple route reflectors serve the same set of clients, but can lead to partial
connectivity when multiple IBGP sessions are disrupted.
http://wiki.nil.com/BGP_route_reflectors
6/7
25/2/2014
The revised BGP route selection rules ensure that a route reflector in a cluster always prefers route from a client
(with shorter Cluster list) over a reflected route, thus making the bgp cluster-id parameter obsolete. You
should not use the bgp cluster-id in new designs to increase the resilience of your network.
Retrieved from "http://wiki.nil.com/BGP_route_reflectors"
Category: BGP
This page was last modified on 30 April 2009, at 07:46.
http://wiki.nil.com/BGP_route_reflectors
7/7