Continuing on the example from the previous two posts on route reflection, we will add eBGP peers to the network. The topology below shows the routers R7 and R8 added to the topology.
 |
| Route Reflection Cluster w/ eBGP non-clients topology |
R5#show running-config | section routerThe network 140.1.57.5/32 is advertised in EIGRP to facilitate routing to the eBGP neighbor 140.1.57.7, which will be the advertised next-hop of the routes advertised out of AS 700. The neighbor statement under BGP only states the remote-as 700, which automatically makes it an eBGP peer.
router eigrp 100
network 10.0.0.0
network 140.1.57.5 0.0.0.0
router bgp 100
bgp log-neighbor-changes
network 172.16.5.0 mask 255.255.255.0
neighbor 10.0.15.1 remote-as 100
neighbor 140.1.57.7 remote-as 700
The pertinent configuration on R7 is shown below.
R7#show running-config | section routerAgain, simple neighbor statement with the remote-as being different from the local router BGP process. Redistribution of connected routes is done with a route-map, that references a prefix-list with entries matching on the networks stated in the topology diagram.
router bgp 700
bgp log-neighbor-changes
redistribute connected route-map RMAP_BGP_REDIST_CONN
neighbor 140.1.57.5 remote-as 100
R7#show route-map
route-map RMAP_BGP_REDIST_CONN, permit, sequence 10
Match clauses:
ip address prefix-lists: PFX_BGP_REDIST_CONN
Set clauses:
Policy routing matches: 0 packets, 0 bytes
R7#show ip prefix-list
ip prefix-list PFX_BGP_REDIST_CONN: 2 entries
seq 5 permit 70.0.0.0/7 ge 23 le 24
seq 6 permit 72.0.0.0/7 ge 23 le 24
Lets check out the BGP table and reachability from the perspective of R6.
R6#show ip bgp regexp ^700*The BGP table is filtered using regular expression (read more here: http://www.cisco.com/c/en/us/td/docs/ios/12_2/termserv/configuration/guide/ftersv_c/tcfaapre.html).
BGP table version is 21, local router ID is 172.16.6.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*>i 70.0.0.0/24 140.1.57.7 0 100 0 700 ?
*>i 71.0.0.0/24 140.1.57.7 0 100 0 700 ?
*>i 72.0.0.0/23 140.1.57.7 0 100 0 700 ?
R6#traceroute 70.0.0.1 source loopback 1
Type escape sequence to abort.
Tracing the route to 70.0.0.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.0.26.2 3 msec 3 msec 0 msec
2 10.0.12.1 1 msec 1 msec 0 msec
3 10.0.15.5 1 msec 0 msec 1 msec
4 140.1.57.7 1 msec * 4 msec
The traceroute shows the path taken going from R6 -> R2 -> R1 -> R5 -> R7 - meaning, through the two RR clusters, to a non-client iBGP peer and finally on to an eBGP peer. Also, notice the next hop in the BGP table output - it shows the next hop as R7, which is why the network needs to be added to the IGP to facilitate the recursive lookup done by BGP.
On to the connection between R1 and R8. Starting with the configuration done on R1 (again, assuming the IP interfaces are configured and up).
R1#configure terminalAnd the configuration done on R8 (omitted from the output is a route-map and prefix-list configured similar to that on R7).
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router bgp 100
R1(config-router)#neighbor 140.1.18.8 remote-as 800
R8#ping 140.1.18.1The intended peer is reachable with a regular ping and the configuration is quite simple - just the neighbor statement with the remote-as differing from the local router BGP process ID. Lets see the BGP neighbors and tables on R8.
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 140.1.18.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/3 ms
R8#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R8(config)#router bgp 800
R8(config-router)#neighbor 140.1.18.1 remote-as 100
R8#show ip bgp summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
140.1.18.1 4 100 19 17 12 0 0 00:12:02 8
R8#show ip bgp regexp ^100
BGP table version is 12, local router ID is 82.0.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 70.0.0.0/24 140.1.18.1 0 100 700 ?
*> 71.0.0.0/24 140.1.18.1 0 100 700 ?
*> 72.0.0.0/23 140.1.18.1 0 100 700 ?
*> 172.16.2.0/24 140.1.18.1 0 100 i
*> 172.16.3.0/24 140.1.18.1 0 100 i
*> 172.16.4.0/24 140.1.18.1 0 100 i
*> 172.16.5.0/24 140.1.18.1 0 100 i
*> 172.16.6.0/24 140.1.18.1 0 100 i
Again, the regexp parameter filters out routes that are not starting with the AS path of 100 (including local routes). Notice how all the routes are valid and best - meaning they should also be in the routing table. Lets see the routing table on R8.
R8#show ip route bgp | begin GatewayAs expected, the routes are in the routing table. We should be able to ping anything in the routing table from any of the BGP advertised prefixes on the router.
Gateway of last resort is not set
70.0.0.0/24 is subnetted, 1 subnets
B 70.0.0.0 [20/0] via 140.1.18.1, 00:14:38
71.0.0.0/24 is subnetted, 1 subnets
B 71.0.0.0 [20/0] via 140.1.18.1, 00:14:38
72.0.0.0/23 is subnetted, 1 subnets
B 72.0.0.0 [20/0] via 140.1.18.1, 00:14:38
172.16.0.0/24 is subnetted, 5 subnets
B 172.16.2.0 [20/0] via 140.1.18.1, 00:14:38
B 172.16.3.0 [20/0] via 140.1.18.1, 00:14:38
B 172.16.4.0 [20/0] via 140.1.18.1, 00:14:38
B 172.16.5.0 [20/0] via 140.1.18.1, 00:14:38
B 172.16.6.0 [20/0] via 140.1.18.1, 00:14:38
R8#ping 172.16.2.1 source loopback 1No dice. The routes are in the routing table on R8, but lets look at the routing table on R2, which we just tried to ping.
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.2.1, timeout is 2 seconds:
Packet sent with a source address of 81.0.0.1
.....
Success rate is 0 percent (0/5)
R2#show ip route bgp | begin GatewayThe routes advertised by R8 is not in the routing table. Lets jump back to R8 and see if it is indeed advertising the routes to its eBGP neighbor (R1).
Gateway of last resort is not set
70.0.0.0/24 is subnetted, 1 subnets
B 70.0.0.0 [200/0] via 140.1.57.7, 01:19:40
71.0.0.0/24 is subnetted, 1 subnets
B 71.0.0.0 [200/0] via 140.1.57.7, 01:19:40
72.0.0.0/23 is subnetted, 1 subnets
B 72.0.0.0 [200/0] via 140.1.57.7, 01:19:40
172.16.0.0/16 is variably subnetted, 6 subnets, 2 masks
B 172.16.3.0/24 [200/0] via 10.0.13.3, 1d05h
B 172.16.4.0/24 [200/0] via 10.0.14.4, 1d05h
B 172.16.5.0/24 [200/0] via 10.0.15.5, 1d05h
B 172.16.6.0/24 [200/0] via 10.0.26.6, 1d23h
R8#show ip bgp neighbors 140.1.18.1 advertised-routesIt is indeed doing so. Lets have a look at R1 to make sure it is receiving the routes from R8. You may be tempted to use the command show ip bgp neighbors <neighbor ip> received-routes, but as shown this will display an error regarding the inbound soft reconfiguration not being enabled for that particular peer.
BGP table version is 12, local router ID is 82.0.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 80.0.0.0/24 0.0.0.0 0 32768 ?
*> 81.0.0.0/24 0.0.0.0 0 32768 ?
*> 82.0.0.0/23 0.0.0.0 0 32768 ?
Total number of prefixes 3
R1#show ip bgp neighbors 140.1.18.8 received-routesSo, with the command show ip bgp neighbors 140.1.18.8 routes, we see that the routes are received from the eBGP peer and they are also marked valid and best. Lets take a look at the routes received on R2 from R1.
% Inbound soft reconfiguration not enabled on 140.1.18.8
R1#show ip bgp neighbors 140.1.18.8 routes
BGP table version is 16, local router ID is 10.0.15.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 80.0.0.0/24 140.1.18.8 0 0 800 ?
*> 81.0.0.0/24 140.1.18.8 0 0 800 ?
*> 82.0.0.0/23 140.1.18.8 0 0 800 ?
Total number of prefixes 3
R2#show ip bgp neighbors 10.0.12.1 routes
BGP table version is 25, local router ID is 10.0.12.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*>i 70.0.0.0/24 140.1.57.7 0 100 0 700 ?
*>i 71.0.0.0/24 140.1.57.7 0 100 0 700 ?
*>i 72.0.0.0/23 140.1.57.7 0 100 0 700 ?
* i 80.0.0.0/24 140.1.18.8 0 100 0 800 ?
* i 81.0.0.0/24 140.1.18.8 0 100 0 800 ?
* i 82.0.0.0/23 140.1.18.8 0 100 0 800 ?
*>i 172.16.3.0/24 10.0.13.3 0 100 0 i
*>i 172.16.4.0/24 10.0.14.4 0 100 0 i
*>i 172.16.5.0/24 10.0.15.5 0 100 0 i
Total number of prefixes 9
So, the routes are received, but notice how they are not marked as best. This is simply due to the fact, that BGP relies on the IGP to route to the next hop advertised in BGP updates. Lets check the routing table for a route to 140.1.18.8.
R2#show ip route 140.1.18.8
% Subnet not in table
The router R2 cannot route to the next hop and therefore BGP does not install the routes into the routing table.
The problem here was that I did not distribute the network 140.1.18.0 /24 via EIGRP on R1. The solution is simply to ensure the IGP has reachability to the edge networks connecting to eBGP peers or to have the iBGP peers re-write the next hop before advertising the routes with iBGP.
Below is an example of how to solve by altering the next hop. This is done on R1 for the peer-group and the non-client iBGP peer (R5).
R1#configure terminalThis makes R1 change the next hop value of routes learned from eBGP peers to itself. After clearing the neighbors on R1, we take a look at the BGP tables on R2 and R5 to see the effects.
R1(config)#router bgp 100
R1(config-router)#neighbor PGROUP next-hop-self
R1(config-router)#neighbor 10.0.15.5 next-hop-self
R2#show ip bgp
BGP table version is 28, local router ID is 10.0.12.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*>i 70.0.0.0/24 140.1.57.7 0 100 0 700 ?
*>i 71.0.0.0/24 140.1.57.7 0 100 0 700 ?
*>i 72.0.0.0/23 140.1.57.7 0 100 0 700 ?
*>i 80.0.0.0/24 10.0.12.1 0 100 0 800 ?
*>i 81.0.0.0/24 10.0.12.1 0 100 0 800 ?
*>i 82.0.0.0/23 10.0.12.1 0 100 0 800 ?
*> 172.16.2.0/24 0.0.0.0 0 32768 i
*>i 172.16.3.0/24 10.0.13.3 0 100 0 i
*>i 172.16.4.0/24 10.0.14.4 0 100 0 i
*>i 172.16.5.0/24 10.0.15.5 0 100 0 i
*>i 172.16.6.0/24 10.0.26.6 0 100 0 i
R5#show ip bgpThe routes are now valid and best and connectivity can now be achieved as shown by the ping done from R8 again.
BGP table version is 24, local router ID is 172.16.5.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 70.0.0.0/24 140.1.57.7 0 0 700 ?
*> 71.0.0.0/24 140.1.57.7 0 0 700 ?
*> 72.0.0.0/23 140.1.57.7 0 0 700 ?
*>i 80.0.0.0/24 10.0.15.1 0 100 0 800 ?
*>i 81.0.0.0/24 10.0.15.1 0 100 0 800 ?
*>i 82.0.0.0/23 10.0.15.1 0 100 0 800 ?
*>i 172.16.2.0/24 10.0.12.2 0 100 0 i
*>i 172.16.3.0/24 10.0.13.3 0 100 0 i
*>i 172.16.4.0/24 10.0.14.4 0 100 0 i
*> 172.16.5.0/24 0.0.0.0 0 32768 i
*>i 172.16.6.0/24 10.0.26.6 0 100 0 i
R8#ping 172.16.2.1 source loopback 1Success!
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.2.1, timeout is 2 seconds:
Packet sent with a source address of 81.0.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/5 ms
So in conclusion: behaviour of eBGP in relation to Route Reflection clusters - basically no change in behaviour from regular eBGP in a non-clustered environment.
I just threw in the little curveball on the last part to show a common problem with BGP not being a typical routing protocol like OSPF and EIGRP, but instead relies on the IGP to route to the destinations based on the next hop value of BGP NLRIs.
And, also, that there are multiple solutions to the same problem - this goes for almost anything, but especially for BGP!
No comments:
Post a Comment