L1 and L2 Troubleshooting

Back>

Layer 1 Trouble-shooting

80% of all network problems are contributed to the physical connectivity at OSI layer 1. If network devices have loose or faulty hardware, electrical signals cannot flow through. As a general guidance, we check these points:

1. Cables -- how the physical hardware is used to attach NICs to the LAN segment? does the length exceeds recommendations.
2. Cards -- does the network adaptor interface card work?
3. Connectors -- does the cable end points correctly insert into interface card? Is there presence of cross-talk?
4. Configuration -- OSI layer 2 through 7 software -- check the parameters used to provide network information, plan tagging and subnet masking. Is this a new installation or existing installation? If something has never worked, check if configuration has been implemented correctly. If something used to work but now does not, what/when did the change happen? Are there all or a few devices experiencing the symptom? 
5. Clocking -- this is an OSI layer 1 or 2 component, it is used to synchronize data into the configured bandwidth speed, which is critical for WAN communication.

Layer 2 trouble-shooting

They layer 2 Ethernet switch is one of the most common networking device. Layer 2 switching is associated with the Data link layer (L2) of the OSI model. Layer 2 ethernet switches forwards traffic in network frames across various network segments, based on information in the frame's Ethernet header. The routers are operating at layer 3, where package capture are used to trouble-shooting routing problem. But even layer 3 switch use a layer 2 mode. In fact, it is often preferable to assure that switches at layer 2 and network infrastructure at layer 1 operate correctly before testing at upper layers of the OSI stack. By testing at layer1 and layer2 before layer3, network engineers increase their success rate in development testing and quality assurance while using in-house tools.

Cisco trouble-shooting commands

The most import troubleshooting command is "show interface fa0/0".

R1#show interface serial0

In normal conditions, we will see:

"Serial0 is up, line protocal is up."

The first part is the port's physical status, the second part is the port's logical status.

When we have problem at L1 and L2, we will see:

• "Serial0 is administratively down, line protocal is down." "administratively down" means the interface is shutdown by the adminstrator manually. Use "no shutdown" to open it.


• "Serial0 is down, line protocol is down". This time "down" means there are physical problem about the connection. The solution is to check the layer 1 devices such as port connection or wrong cable.


• "fa 0/0 is down, line protocol is down (err-disabled)". "err-disabled" means the port is shut down because of some security vialations. Check the port security for the trouble with command "show-port security interface".


• "Serial0 is up, line protocol is down". In this case, the L1 physical layer is fine, but L2 or higher level protocol is wrong. Most possibly, either the clock rate is not set on the DCE or the encapsulation type don't match on both ends of the link.


• "Serial0 is up, line protocol is down (looped)". In this case, the L1 physical layer is fine, but L2 or higher level protocol is wrong. "(looped)" means there is an active loopback on the router, on the line between the router and the local Frame Relay switch, or on the local Frame Relay switch itself. To fix it,  save your running-config and issue the encapsulation hdlc, keepalive 10 and unique ip address commands on the main interface. Check this cisco document for details.

Another useful IOS "show" commands are

Switch#show mac-address-table

Swtich#show vlan brief

Router#show version

Don't forget the command "ping 1.0.0.0" and the extended ping command "ping".

Sometimes, we need run-time informations, we use debug commands.

R1#debug ip packet

R1#debug ip protocols

R1#debug ip rip

To add a time stamp to a debug or log message, use command "service timestamps".

If we want to see the output of our debugs during our session, use command "terminal monitor" in EXEC mode. All debug outputs and system error messages for the current terminal and session will be displayed.

Looking at log files can give us insight about during troubleshooting. To enable system messages to a local buffer use command "logging buffered [size]" in global configuration mode. The default size is 4096k and once this is full older messages will be overwritten with newer ones.

Don't forget the house-keeping after trouble-shooting.

R1#show debug

R1#undebug all