Troubleshooting Advice

new2net

Hey.. looking for some advice on how to systematically approach a troubleshooting (both in the real world and for exams).

Do you typically start from Layer 3 and work down to Layer 1:

At Layer 3: Verify IP address and masks are correct
Verify default gateway address and DNS Server ect...
Verify routing tables ect.

Then move down to Layer 2 and check protocol status, collision counters, mac-address table ect..

Then down to Layer 1 and check cable type (and power of course!)

Or do you guys start from Layer 1 and work up to Layer 3?

The reason I left out Layer 4, is because I am not sure about what we can do there... we don't seem to have much control there (at least not at the CCENT/CCNA level). Ports and ACKs/SEQs seem to be generated and the choice of TCP/UDP is typically determined by the Application Layers...

I just hate to be trying all kinda random things with no apparent order.. I am trying to use the Layer 3 to Layer 1 approach..

Looking for some suggestions

Thanks!

networker050184

ALWAYS start at the physical layer. First check the port. Is L1 up? If no check the cable, power etc. Is L2 up? If no check the encapsulation etc. Is L3 up? If not check the ip address, default gateway, routing etc.

No point in checking routing if it the damn thing isn't even plugged in!

Panzer919

networker050184 wrote: »

ALWAYS start at the physical layer. First check the port. Is L1 up? If no check the cable, power etc. Is L2 up? If no check the encapsulation etc. Is L3 up? If not check the ip address, default gateway, routing etc.

No point in checking routing if it the damn thing isn't even plugged in!

Definitely +100

WilliamK99

+ a ton,

If you check Layer 3 first, you are setting yourself up for failure, I don't know how many times the problem has been as simple as an unplugged switch....

Bl8ckr0uter

+1

You should use the OSI model as a guide. Start from the bottom and work your way up.

kryolla

it all depends on what the issue is. Is it a certian route not in the routing table or BGP peering not coming up or trunk links not coming up or frame relay VC not coming up but other VCs are up. If a remote site lost all communication then yes check to see if you have a T1 down or if an end user cant connect to the network then its pretty obvious to check if the port is up first. Just my opinion

Panzer919

and if your in a help desk environment always start with layer 0 - AKA the PEBKAC layer

mikej412

kryolla wrote: »

it all depends on what the issue is.

I Agree.

While it's a good idea when you're first starting out to follow a structured approach to troubleshooting, once you have experience you may decide to start elsewhere -- depending on the problem.

But don't confuse identifying the problem with troubleshooting the problem.

rsutton

Like the previous comment, I generally look at all the reported symptoms and then troubleshoot accordingly. If I don't know where to look then I will follow the OSI model.

billscott92787

I agree that since you are starting out to first start from the Physical layer (layer 1) and work your way up. If you are dealing with the CCNA, chances are you're really only going to be dealing with Layers 1 - Layers 3 (as far as I have experience with all my reading), which are the Physical, Data Link, and Network Layer. Correct me if I'm wrong anyone. As far as I have heard from my friend which is a CCIE, the upper layers, are left for more advanced studies such as CCNP/CCIE. I mean we do we with some layer 3 (tcp, udp) stuff when you deal with access lists, like which ports to block and things of that nature. But that's about all I have seen with anything other than layers 1 - 3.

bgrablin

networker050184 wrote: »

ALWAYS start at the physical layer...

Are you Chris Bryant? In every video series he is ALWAYS saying that.

billscott92787 wrote: »

...I mean we do we with some layer 3 (tcp, udp) stuff when you deal with access lists, like which ports to block and things of that nature. But that's about all I have seen with anything other than layers 1 - 3.

I'm not sure if I just read your post wrong but [FONT=verdana,geneva,helvetica,arial,ms sans serif]both TCP and UDP are transport protocols, belonging to the Transport Layer (Layer 4) of the OSI model. Both TCP and UDP run on top of IP, that operates at the Network layer (Layer 3.)[/FONT]

Turgon

bgrablin wrote: »

Are you Chris Bryant? In every video series he is ALWAYS saying that.



I'm not sure if I just read your post wrong but [FONT=verdana,geneva,helvetica,arial,ms sans serif]both TCP and UDP are transport protocols, belonging to the Transport Layer (Layer 4) of the OSI model. Both TCP and UDP run on top of IP, that operates at the Network layer (Layer 3.)[/FONT]

A typo on the part of the poster I think as he goes on to mention that this is the only time he goes outside the first three OSI layers.

Back to the original question. The OSI model is a useful troubleshooting tool although in reality some of the distinctions of layers are somewhat blurred. You find with experience that you develop an instinct for problems and resolutions often without recourse to the model. Mike is correct that identifying the problem and troubleshooting are different. As for higher levels for those of you responsible for firewalls understanding layer 4 will really assist you in making sense of firewall logs and troubleshooting many problems. The three way handshake and segments in general are not as well understood as they should be by many network professionals. The same goes for layer 7 when you are looking at smtp negotiation and such that isn't happening.