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.
Salem#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 100 percent (5/5), round-trip min/avg/max = 12/25/32 ms Salem#
Before 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:
CrystalLake#show ip route 188.8.131.52 % Network not in table
Yes, 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.
Salem(config)#router bgp 65000 Salem(config-router)#neighbor 184.108.40.206 next-hop-self
OK – now some quick tests on CrystalLake:
CrystalLake#show ip bgp BGP table version is 2, local router ID is 220.127.116.11 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 18.104.22.168 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: !!!!!
Excellent. 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.
Amityville#show ip bgp Amityville#CrystalLake(config)#router bgp 65000 CrystalLake(config-router)#neighbor 22.214.171.124 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#
Success! We have solved this trouble ticket. Notice how it threw several “classic” design issues at us in one trouble ticket. To review, they were:
- Requirements for aggregation
- Proper use of the network statement
- Next-hop reachability in BGP
- The iBGP Split-Horizon rule
While these should be pretty simple for a CCIE candidate, a challenge in the Troubleshooting section is working very, very fast. You need to quickly understand the diagram (perhaps making your own as we had to do here), and then quickly doing your troubleshooting and verification steps.
8 Responses to “CCIE R&S Troubleshooting – Sample Trouble Tickets – Part 2”
Leave a Reply