#Route reflector update#

#Route reflector update#

RR1 has no alternate path in its BGP RIB and immediately sends an unreachable update to PE2: %BGP-5-NBR_RESET: Neighbor 10.0.0.3 reset (Peer closed the session)īGP(0): (base) 10.0.0.2 send unreachable (format) 10.0.0.3/32īGP(0): (base) 10.0.0.4 send unreachable (format) 10.0.0.3/32īased on the above, it seems like we should be using cluster ID on route reflectors to reduce the amount of BGP updates. There’s also no path hunting after the session with PE1 fails. Reflected update droppedīGP(0): 10.0.0.2 rcv UPDATE w/ attr: nexthop 10.0.0.3, origin i, localpref 100, With the same RR Cluster ID configured on RR1 and RR2, RR1 rejects a reflected update coming from RR2: BGP: 10.0.0.2 RR in same cluster. The Impact of BGP Route Reflector Cluster ID Immediately after sending an update to PE2, RR1 receives an update from RR2 saying hey, I have no idea where 10.0.0.3 is: BGP(0): 10.0.0.2 rcv UPDATE about 10.0.0.3/32 - withdrawnīGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.0.0.3/32Īs the final step, RR1 has to send yet another update to PE2 saying gee, I was wrong – I have no idea where 10.0.0.3/32 is: BGP(0): (base) 10.0.0.4 send unreachable (format) 10.0.0.3/32 RR2 goes though the same steps and arrives at the same conclusions (including sending an unreachable update to RR1). It also sends a modified version of the 10.0.0.3/32 prefix (that we know is bogus, but RR1 doesn’t) to PE2: BGP(0): (base) 10.0.0.4 send UPDATE (format) 10.0.0.3/32, next 10.0.0.3, metric 0, path Local RR1 removes the original route from PE1 and finds an alternate route in BGP RIB – the reflected update received from RR2: Revise route installing 1 of 1 routes for 10.0.0.3/32 -> 10.0.0.3(global) to main IP tableĪs RR1 is now using a route from RR2, it sends an unreachable update 3 to RR2: BGP(0): (base) 10.0.0.2 send unreachable (format) 10.0.0.3/32 %BGP_SESSION-5-ADJCHANGE: neighbor 10.0.0.3 IPv4 Unicast topology base removed from session %BGP-5-ADJCHANGE: neighbor 10.0.0.3 Down Peer closed the session When PE1 shuts down (simulated with no router bgp 65000 configuration command) it closes the BGP session with RR1 and RR2 (debugging printouts were collected on RR1): %BGP-5-NBR_RESET: Neighbor 10.0.0.3 reset (Peer closed the session) Origin IGP, metric 0, localpref 100, valid, internal, best Origin IGP, metric 0, localpref 100, valid, internal Never heard of path hunting? Let’s see what’s going on behind the scenes, using the simplest possible lab topology:īGP sessions in our sample lab (Graphviz hates drawing a leaf-and-spine fabric)īGP RIB entries for PE1 loopback (10.0.0.3) on RR1 rr1#sh ip bgp 10.0.0.3īGP routing table entry for 10.0.0.3/32, version 9

Fortunately, route reflector path hunting isn’t nearly as bad as EBGP path hunting. Using the analogy, it seems that we should use the same cluster ID on all route reflectors.

In an EBGP leaf-and-spine fabric we commonly use the same AS number on all spines to prevent path hunting. As always things aren’t as simple as they look it’s time for an analogy: if you squint just right, an autonomous system with a set of route reflectors and clients looks an awful lot like a leaf-and-spine fabric (route reflectors are spines, RR clients are leafs).Ī network with a single layer of BGP route reflectors OK, so it looks like we don’t need to set cluster id on route reflectors – the update loops are detected in any case and life is good. Long story short: cluster list serves the same role within an autonomous system as AS path does across autonomous systems (without the plethora of nerd knobs that would allow you to turn off sanity checks).

Even in that case, every RR adds its cluster ID (router ID is used as the default value) to the cluster list attribute on every reflected BGP prefix, and checks the cluster list on incoming updates.

The only way to generate an update propagation loop is a cycle of route reflectors with every route reflector being a client of other route reflectors 1.

While BGP route reflectors can cause permanent forwarding loops in sufficiently broken topologies, the Cluster ID was never needed to stop a routing update propagation loop: In a redundant design, you should use Route Reflector Cluster ID to avoid loops.