A router configure to be a BGP Route Reflector can take a route learned from one iBGP Peer and advertise it to another iBGP Peer, which basically is the equivalent of “no ip split-horizon” only BGP style!
iBGP Peers that send routes to the route reflector are called “clients”, and when the Reflector receives routes from clients, it reflects the routes to other clients all the while the clients have no idea they are getting their routes from a Route Reflector.
Now as seen in the Topology I’ve changed it so the Spoke routers Peer to the Hub to avoid creating a full mesh network, and the Hub will reflect routes advertised from R2 to R3 and vice versa. Also note that R2 does not have an interface in the Ethernet segment to R4 in this lab.
A BGP Speaker with a Peering does not HAVE to be a client, these are known as “nonclients”, however they do require a TCP connection to every other router in the AS (which we are trying to avoid in the first place with the reflector).
So let’s get into the configuration, all the Peerings are already configured, so I’ll start by configuring 4.4.4.4/32 to be advertised by R4, verify its in the ip bgp table, and move along to configuring R1 as the Route Reflector:
R4
R4(config-router)#network 4.4.4.4 mask 255.255.255.255
R4(config-router)#^Z
R4#
*Apr 16 08:22:56.783: %SYS-5-CONFIG_I: Configured from console by console
R4#sh ip bgp
BGP table version is 2, local router ID is 44.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*> 4.4.4.4/32 0.0.0.0 0 32768 i
R4#
R3
R3#sh ip bgp
BGP table version is 2, local router ID is 3.3.3.3
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
*> 4.4.4.4/32 172.12.23.4 0 0 4 i
R3#
R1
R1#sh ip bgp
BGP table version is 1, local router ID is 172.16.11.1
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
* i4.4.4.4/32 172.12.23.4 0 100 0 4 i
R1#sh ip bgp 4.4.4.4
BGP routing table entry for 4.4.4.4/32, version 0
Paths: (1 available, no best path)
Not advertised to any peer
4
172.12.23.4 (inaccessible) from 172.12.123.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
R1#
So there are a few things going on here. First we note the route is valid, but does not have it’s fellow >, and we need to see both of those for a route in the ip bgp table. Also it shows “Not advertied to any peer router” which indicates BGP Split-Horizon in effect for that route, and finally (inaccessible) meaning it does not have a route to the destination network.
Also we have the expected BGP behavior of an iBGP Peer not advertising its interface as the Next Hop due to the route coming from a non-local AS, which we would either do some static routing, or the easier option issuing “neighbor 172.12.123.1 next-hop-self” on R3 so routes from remote AS’s are reachable.
So lets fix that issue:
R3(config)#router bgp 123
R3(config-router)#neighbor 172.12.123.1 next-hop-self
R3(config-router)#
ASR#1
[Resuming connection 1 to r1 … ]
R1#clear ip bgp * soft in
R1#sh ip bgp
BGP table version is 2, local router ID is 172.16.11.1
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
*>i4.4.4.4/32 172.12.123.3 0 100 0 4 i
R1#
Now we are on the right track here, however:
R1#sh ip bgp 4.4.4.4
BGP routing table entry for 4.4.4.4/32, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
4
172.12.123.3 from 172.12.123.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal, best
R1#
Split Horizon is still blocking the route from propagating to iBGP Peers, so I won’t bother with R2’s output, because there is nothing to show as indicated. However, lets advertise it’s loopback as well here and verify it on R1 so we can see if we can get it both routes advertising both ways:
R2#
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#router bgp 123
R2(config-router)#network 2.2.2.2 mask 255.255.255.255
R2(config-router)#^Z
R2#wr
Building configuration…
ASR#1
[Resuming connection 1 to r1 … ]
R1#sh ip bgp
BGP table version is 3, local router ID is 172.16.11.1
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
*>i2.2.2.2/32 172.12.123.2 0 100 0 i
*>i4.4.4.4/32 172.12.123.3 0 100 0 4 i
R1#sh ip bgp 2.2.2.2
BGP routing table entry for 2.2.2.2/32, version 3
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
Not advertised to any peer
Local
172.12.123.2 from 172.12.123.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
R1#
To solve this we could Peer R2 and R3 to make a full mesh, but we want to stay away from that, because of the scalability issues if we add 20 or 30 more routers into the mix in a real world or CCIE Lab environment.
So for that very reason, we will choose option 2, configuring R1 as a Route Reflector, and I’ll have to include some ? output to point out the most obvious command in IOS help:
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router bgp 123
R1(config-router)#neighbor 172.12.123.2 ?
activate Enable the Address Family for this Neighbor
advertise-map specify route-map for conditional advertisement
advertisement-interval Minimum interval between sending BGP routing updates
allowas-in Accept as-path with my AS present in it
capability Advertise capability to the peer
default-originate Originate default route to this neighbor
description Neighbor specific description
disable-connected-check One-hop away EBGP peer using loopback address
distribute-list Filter updates to/from this neighbor
dmzlink-bw Propagate the DMZ link bandwidth
ebgp-multihop Allow EBGP neighbors not on directly connected
networks
fall-over session fall on peer route lost
filter-list Establish BGP filters
inherit Inherit a template
local-as Specify a local-as number
maximum-prefix Maximum number of prefixes accepted from this peer
next-hop-self Disable the next hop calculation for this neighbor
next-hop-unchanged Propagate the iBGP paths’s next hop unchanged for
this neighbor
password Set a password
peer-group Member of the peer-group
prefix-list Filter updates to/from this neighbor
remote-as Specify a BGP neighbor
remove-private-as Remove private AS number from outbound updates
route-map Apply route map to neighbor
route-reflector-client Configure a neighbor as Route Reflector client
send-community Send Community attribute to this neighbor
shutdown Administratively shut down this neighbor
soft-reconfiguration Per neighbor soft reconfiguration
timers BGP per neighbor timers
translate-update Translate Update to MBGP format
transport Transport options
ttl-security BGP ttl security check
unsuppress-map Route-map to selectively unsuppress suppressed
routes
update-source Source of routing updates
version Set the BGP version to match a neighbor
weight Set default weight for routes from this neighbor
R1(config-router)#neighbor 172.12.123.2 route-reflector-client
R1(config-router)#
*Mar 31 13:47:18.106: %BGP-5-ADJCHANGE: neighbor 172.12.123.2 Down RR client config change
R1(config-router)#
*Mar 31 13:47:20.330: %BGP-5-ADJCHANGE: neighbor 172.12.123.2 Up
R1(config-router)#neighbor 172.12.123.3 route-reflector-client
R1(config-router)#
*Mar 31 13:47:42.627: %BGP-5-ADJCHANGE: neighbor 172.12.123.3 Down RR client config change
R1(config-router)#
*Mar 31 13:47:44.850: %BGP-5-ADJCHANGE: neighbor 172.12.123.3 Up
R1(config-router)#
As usual, we see the neighbor command come into play here, and the captain obvious of commands to configure this to be a reflector to that neighbor “route-reflector-client” which is pretty self explanatory.
As can be seen, it needs to be configured for each “client” in the network, and does drop the Adjacency to that Neighbor very briefly, as seen in the time stamps it was down for about 2 seconds before the neighbor was back up.
So with that being configured, lets take a look around at our clients, and over at R4:
R2#sh ip bgp
BGP table version is 5, local router ID is 2.2.2.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
*> 2.2.2.2/32 0.0.0.0 0 32768 i
*>i4.4.4.4/32 172.12.123.3 0 100 0 4 i
R2#
ASR#3
[Resuming connection 3 to r3 … ]
*Mar 2 18:24:30.291: %SYS-5-CONFIG_I: Configured from console by console[OK]
R3#sh ip bgp
BGP table version is 5, local router ID is 3.3.3.3
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
*>i2.2.2.2/32 172.12.123.2 0 100 0 i
*> 4.4.4.4/32 172.12.23.4 0 0 4 i
R3#
ASR#4
[Resuming connection 4 to r4 … ]
R4#sh ip bgp
BGP table version is 3, local router ID is 44.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.2/32 172.12.23.3 0 123 i
*> 4.4.4.4/32 0.0.0.0 0 32768 i
R4#
Looks good all around!
Now the verification command for this is “sh ip bgp neighbor” which I will spare the output, but it will be found under each neighbors individual segments as “Route-Reflector Client”, as and you can also see “Last reset due to RR client config change” – So remember to view this information use “sh ip bgp nei” !
So one more topic to cover before moving onto the next topic, is that Route Reflectors do not reflect routes to everyone, and how the Route Reflectors handles a route update depending on the type of BGP router that sent it.
Here is a list to memorize to save time troubleshooting issues caused be these behaviors:
- Updates from Route Reflector clients are sent to all clients and nonclient Peers
- Updates sent from eBGP Peers are sent to all client and nonclient Peers
- Updates from nonclient Peers are sent to all clients but not all nonclient Peers
So if you have nonclient peers in a Route Reflector topology, it is a red flag to watch out for that behavior of the Route reflector, eBGP and clients are good to go but nonclients will cause some chaos in the network.
That is all for that, onto Prefix lists as I believe the final BGP Topic outside of maybe some miscellaneous / helpful information 🙂 Almost there!
The DEVNET GRIND! 