CCIE R&S Troubleshooting – Sample Trouble Tickets – Part 2

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 23.10.0.0   
% 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 66.150.201.21 next-hop-self

OK – now some quick tests on CrystalLake:

CrystalLake#show ip bgp
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:
!!!!!

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 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#

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.