CCIE R&S Troubleshooting ...
    03 November 09

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

    Posted byINE

    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.

    Screen shot 2009-10-31 at 5.44.38 PM

    If we slide over to the Salem device (an eBGP peer of HalloweenTime), we discover that connectivity is working from there just fine.


    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
    Success rate is 100 percent (5/5), round-trip min/avg/max = 12/25/32 ms

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

    OK - now some quick tests on CrystalLake:

    CrystalLake#show ip bgp
    BGP table version is 2, local router ID is
    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            0    100      0 65001 i

    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to, 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


    CrystalLake(config)#router bgp 65000
    CrystalLake(config-router)#neighbor route-reflector-client


    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
    Success rate is 80 percent (4/5), round-trip min/avg/max = 44/54/72 ms

    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.

    Hey! Don’t miss anything - subscribe to our newsletter!

    © 2022 INE. All Rights Reserved. All logos, trademarks and registered trademarks are the property of their respective owners.
    instagram Logofacebook Logotwitter Logolinkedin Logoyoutube Logo