In this post, we are going to continue troubleshooting with the Trouble Ticket from Part 1 of this series. If you want to check out Part 1, just click here.
When we finished last time, we had discovered and corrected an issue with the attempt at prefix aggregation on Transylvania.

If we slide over to the Salem device (an eBGP peer of HalloweenTime), we discover that connectivity is working from there just fine.
When we finished last time, we had discovered and corrected an issue with the attempt at prefix aggregation on Transylvania.

If we slide over to the Salem device (an eBGP peer of HalloweenTime), we discover that connectivity is working from there just fine.
Salem#ping 10.10.10.1Before I move one hop away to CrystalLake, I consider design issues that could be a problem. The big one that comes to mind here is next-hop reachability. The default next hop in BGP (an AS to AS protocol) is going to be the Salem-facing interface on HalloweenTown. CrystalLake needs to be able to reach that prefix in order for the BGP route(s) to be used there. Let me quickly check if CrystalLake can reach that prefix:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/25/32 ms
Salem#
CrystalLake#show ip route 23.10.0.0Yes, sure enough, we are going to have issues with next hop. Let me quickly add next-hop-self to the peering with CrystalLake on Salem.
% Network not in table
Salem(config)#router bgp 65000OK – now some quick tests on CrystalLake:
Salem(config-router)#neighbor 66.150.201.21 next-hop-self
CrystalLake#show ip bgpExcellent. One last hop to worry about. Looking at our hand drawn diagram I realize there is a design issue here, the iBGP split-horizon rule. Route-reflection is a simple solution. Let me verify there is an issue, then implement the fix.
BGP table version is 2, local router ID is 102.34.102.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
*>i10.10.0.0/16 66.150.201.12 0 100 0 65001 i
CrystalLake#ping 10.10.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
!!!!!
Amityville#show ip bgpSuccess! We have solved this trouble ticket. Notice how it threw several “classic” design issues at us in one trouble ticket. To review, they were:
Amityville#CrystalLake(config)#router bgp 65000
CrystalLake(config-router)#neighbor 102.34.102.12 route-reflector-client
Amityville#ping 10.10.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 44/54/72 ms
Amityville#
- Requirements for aggregation
- Proper use of the network statement
- Next-hop reachability in BGP
- The iBGP Split-Horizon rule
0 comments:
Post a Comment