CCNP - TSHOOT - Troubleshooting the Routers...

Continuing my TSHOOT methodology, in this post I'm going to look at troubleshooting the network between R4, R3, R2,R1 and out to the web server at 209.65.200.241.

Having not sat the TSHOOT exam the impression I'm getting is the Trouble Ticket (TT) will state something like Client1 cannot access [insert resource]. As such you need to identify the system the issue is on and the resolution.

Again I'll be referring to the actual  TSHOOT topology - here

Let's say Client 1 cannot access the web server at  209.65.200.241. Based on my previous article, also assume Client 1 can ping 10.1.4.5 at R4. In this post I will outline how I see myself troubleshooting the connectivity issue to the web server.

I'll want to prove connectivity to R1. So in turn I'll ping each interface on the way to R1 at 10.1.1.1 If at any point the ping is not returned then log in to the router that you were trying to ping and begin troubleshooting.

1) Are the interface on the link UP/UP? check that one of them is not admin'd down:
#sh ip interfaces brief

2) With interfaces up, is the L2 Frame-Relay topology correct? the diagram shows that the routers are connected via point-to-point links therefore I'm expecting to see a config similar to:
R4(config)#int s0/0/0
R4(config-if)#encapsulation frame-relay point-to-point
R4(config-if)#no shutdown
!
R4(config)#int s0/0/0.34 point-to-point
R4(config-if)#ip address 10.1.1.10 255.255.255.252
R4(config-if)#frame-relay interface dlci 403

3) Assuming L2 is fine move on the routing protocols. Things to check here are:
i - is route redistribution functioning correctly on R4? check the routing table, check config
ii - Are the adjacencies up? Check the neighbor tables/topology tables.
iii -Are the correct networks being advertised to the neighbor? check the ospf network statements
iv -  is there any authentication in place? if so it must match at each end
v - is the routing table including the correct route as per the network diagram? If the route is not in the routing table it won't be advertised out to the neighbor.
vi - Is the routing config command 'passive-interface default' set? if it is then updates will be suppressed by default. You need to either remove the command using #no passive-interface default
Or you specifically list the interfaces you want to participate in dynamic routing using:
#passive-interface default
#no passive-interface f0/0
#no passive-interface f0/1
and so on...

4) Up to R1 I think that would cover off all the major connectivity issues you'd be likely to get. If you still have problems look closer at R1.

On R1 check you can get to the next-hop outside of the network. If you can the config on R1 should be sound. If you can't it could indicate any of the following.
i - Check over the interfaces as per previous points. Ensure they are UP/UP. if they aren't then troubleshoot accordingly.
ii - Check routing/BGP - is the BGP peering up? if not check the config, if the update source being used is a Loopback address then you need the update-source command set in the BGP config. Check the IP's of the Peers, check the remote-as command is correct
iii - Is there a default route? I'd expect there to be one. Simple question. Is it pointing to the correct outbound next-hop? not in towards the LAN?
iv - Are there any access-lists? if so, what are they permitting and what are they blocking? Could the implicit deny  be causing an issue here?
v- Is the default route being correctly redistributed? I'm expecting to see something like:
R1(config)#router ospf 1
R1(config)#default-information originate
vi - Is NAT in operation? check which interface is inside, outside, check the ip nat source statements. Check any NAT pools that my be configured? if a pool is not configured then I'm looking for the 'overload' option in the command :
#ip nat source list 10 interface s0/0/1 overload
With out Overload then port address translation is not working and you'd only be able to have 1 host using NAT at any one time.


Based on the exam topology I'd hope that by running through my structured check list from L1, L2 to L3 to L4 and above that the issue in hand would be revealed.

When I'm in the exam I'll be taking my cue from the information in the TT. As such I might not need to bother with L1/L2 checks if the remote peer is responding as expected.

My next article is going to look at the IPv6 topology and look at how I might be troubleshooting problems there.