One of the most dreaded stipulations of the Border Gateway Patrol, as taken directly from RFC4271:
“When a BGP speaker receives an UPDATE message from an internal peer,
the receiving BGP speaker SHALL NOT re-distribute the routing
information contained in that UPDATE message to other internal peers”
This presents quite a problem in organizations where the iBGP speakers are not all fully meshed, as seen below:
Imagine if this organization had 30 routers, or 230 routers--this would be impossible to setup and maintain.
There are two possible remedies. One is BGP confederations, the other is Route Reflectors (Henceforth referred to as RRs). A RR effectively disables the split-horizon mechanisms of BGP by allowing an iBGP speaker to advertise iBGP learner routes to other internal speakers. Documented in RFC2796, Route Reflectors are formally defined as “[a method of] alleviate the the need for "full mesh" IBGP” through “a BGP speaker advertising an IBGP learned route to another IBGP peer”
The effective use of RRs reduce the topology above to this:
This is an effective reduction in connections from (n2 - n) / 2 to n - 1, where n equals the number of iBGP speakers. For example, in the networks mentioned above with 30 and 230 speakers, they would be reduced from 435 to 29 connection and from 26335 to 229. The comparative graph of meshed connections to RRs is:
Now that the need for RRs is understood, the theory is quite simple:
1. A RR is peered with other iBGP speakers normally
2. The RR has a configuration option set to designate the downstream iBGP peers as RR clients
3. Non-client iBGP speakers peering with an RR is still subject to the non-transitive nature of iBGP to iBGP route advertisements
The term is self explanatory--The RR bounces routes down to the client speakers. The format of the advertisement is very similar to a standard BGP update:
As seen above the standard BGP update (with default attribute settings) contains the three well known mandatory attributes and two optionals: LOCAL_PREF and MED.
With the RR update, the inclusion of CLUSTER_LIST and ORIGINATOR. Not only do these signal the downstream router to add the route to its table, ignoring the iBGP rules. These attributes provide RR clusters with loop prevention.
Loop prevention in an RR topology is provided via:
1. The CLUSTER_ID BGP attribute. Each RR adds its cluster ID, which is by default the router ID (RID) of the RR, to route updates that are reflected to its downstream peers. This way routes do no become re-reflected into the cluster by way of redundant connections or multiple cluster RRs
2. ORIGINATOR_ID is labeled as the first iBGP speaker to advertise a prefix in a given AS. I a BGP speaker receives an advertisement with its own RID in said field, it discards the prefix.
3. Just as through normal operation of BGP, only the best routes are advertised to neighbors.
Configuration:
Easy as pie! All that needs to change is the addition of one statement per downstream peer in relation to the RR ‘server’. Here is the topology:
One of the spoke routers is advertising the network 33.3.3.3/29 into AS 503 via iBGP. Here is the BGP table on the RR server:
LolaBoat#sh ip bgp
BGP table version is 7, local router ID is 1.3.3.7
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.3.3.7/32 0.0.0.0 0 32768 i
*> 10.1.12.0/24 0.0.0.0 0 32768 i
*> 10.1.13.0/24 0.0.0.0 0 32768 i
*>i33.3.3.0/29 10.1.13.3 0 100 0 i
And the BGP table on the far spoke:
R2#sh ip bgp
BGP table version is 18, local router ID is 10.1.12.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i1.3.3.7/32 10.1.12.1 0 100 0 i
r>i10.1.12.0/24 10.1.12.1 0 100 0 i
*>i10.1.13.0/24 10.1.12.1 0 100 0 i
Note that the 33.3.3.0/29 prefix is missing. This is due to the hub router not advertising an iBGP learned route to another iBGP peer. We can see the hub is not advertising this route
LolaBoat#show ip bgp neighbors 10.1.12.2 advertised-routes
BGP table version is 9, local router ID is 1.3.3.7
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.3.3.7/32 0.0.0.0 0 32768 i
*> 10.1.12.0/24 0.0.0.0 0 32768 i
*> 10.1.13.0/24 0.0.0.0 0 32768 i
To fix this, the hub router is made into an RR. Please note this will drop any active BGP sessions:
LolaBoat(config)#router bgp 503
LolaBoat(config-router)#neighbor 10.1.12.2 route-reflector-client
*Mar 1 00:07:01.295: %BGP-5-ADJCHANGE: neighbor 10.1.12.2 Down RR client config change
*Mar 1 00:07:03.327: %BGP-5-ADJCHANGE: neighbor 10.1.12.2 Up
LolaBoat(config-router)#neighbor 10.1.13.3 route-reflector-client
LolaBoat(config-router)#
*Mar 1 00:07:16.467: %BGP-5-ADJCHANGE: neighbor 10.1.13.3 Down RR client config change
LolaBoat(config-router)#
*Mar 1 00:07:18.611: %BGP-5-ADJCHANGE: neighbor 10.1.13.3 Up
Now the RR (formerly referred to as the hub) will advertise the 33.3.3.0/29 prefix to the far spoke router:
LolaBoat#show ip bgp neighbors 10.1.12.2 advertised-routes
BGP table version is 11, local router ID is 1.3.3.7
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.3.3.7/32 0.0.0.0 0 32768 i
*> 10.1.12.0/24 0.0.0.0 0 32768 i
*> 10.1.13.0/24 0.0.0.0 0 32768 i
*>i33.3.3.0/29 10.1.13.3 0 100 0 i
And on the far spoke, success!
R2#sh ip bgp
BGP table version is 26, local router ID is 10.1.12.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i1.3.3.7/32 10.1.12.1 0 100 0 i
r>i10.1.12.0/24 10.1.12.1 0 100 0 i
*>i10.1.13.0/24 10.1.12.1 0 100 0 i
*>i33.3.3.0/29 10.1.13.3 0 100 0 i
You can see that the 33.3.3.0/29 prefix was reflected by closer inspection. The cluster list is present and is equal to the Loopback0 of the RR:
R2#sh ip bgp 33.3.3.0
BGP routing table entry for 33.3.3.0/29, version 26
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
Not advertised to any peer
Local
10.1.13.3 from 10.1.12.1 (1.3.3.7)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 10.1.13.3, Cluster list: 1.3.3.7
This can be changed on the RR simply (remember the decimal value will be converted to binary):
LolaBoat(config)#router bgp 503
LolaBoat(config-router)#bgp cluster-id 8675309
R2#sh ip bgp 33.3.3.0 | i Cluster
Originator: 10.1.13.3, Cluster list: 0.132.95.237
That is all for now. Stay tuned for a post detailing this in Junos as opposed to Cisco IOS :)
1 comment:
thanks, that was on point
Post a Comment