IPNET

You know how sometimes you plug in everything, configure device / ports and then the un-expected result is “not working”. Then you start to troubleshoot, which is a good point, but very important is where are you looking for the root cause of your issue.

A lot of people who have communication issue start by issuing a ping from one end to the other one. This is a good approach when somebody is reporting service issue (e.g. my webserver doesn’t work) as with the ping you can see immediately if is a communication issue or a server one. This scenario ussualy occurs when you already have a working environment and after a while somebody encounter a service issue.

Instead when you just deployed a new connection and you are having issue with it, ping is not the best approach. In the following article I will try to show you some good steps proven to be effective when you start troubleshooting. For today I will take as example a faulty communication between a Cisco switch and an end device (server or user device). This involes in the first step basic Layer 2 troubleshooting.

Scenario 1: You have an end device connected to a switch and you have no communication

a) Check the interface connection status:

OK – port is connected and protocol shows up status

Not OK – check the faulty port as it is in shutdown state

Not OK – port is not connected, protocol shows down status
You can check for cable error (damage, faulty plug, unplugged) or ask the owner of the remote device to check it.

If you found any error in the above step, try to fix them now. If the interface is connected, but still not working, follow on to the next steps.

b) Check speed and duplex settings
-if you have auto-negotiation here and it fails, you will end with an interface in down status
-again if you have static settings here, check to be the same on both sides.
-for more pro and cons regarding auto-negotiation vs static, please see Greg Ferro’s article

c) Check the interface switchport configuration:

There is no right and wrong configuration here, but I can point you to check the following:
– very important, check if the access VLAN is the right one
– if you have switchport auto-negotiation enabled, check to see that this is correctly achieved
– if you have switchport static configuration, check to have the correct settings for your needs
– if you need trunking (to an end device), check to allow the necessary VLANs on that trunk
– if you use private VLANs, pay attention to the configuration of primary and secondary vlan and right association

d) Check security on the Access port (BPDU guard, port-security, mac-address access-list…):

– port is in shutdown state due to Security Violation (1); The mac-address that you see there is the one coming to the port from the other end, but also you can see that there is a Configured Mac Address (1) on the port; Most probably the one configured on the port does not match the one from the network.

-if the result is like above one, you may want to check if that mac-address access-list allow communication from end device mac-address

– if your interface status is like this, you might have an issue with spanning-tree BPDUguard being enabled on the interface; I know I said that this is end device connected, but what if the user needed an extra port, and he connected there a switch? You always have to assume what’s the worst and check for possible issue.

f) Check the Spanning-tree protocol on the switch port

– your output might look different than the above one, but be sure to have there FWD (Forwarding) status if the port is connected to an end device.
– again it is very rare not to be in FWD status, but if the device has some strange bridging capabilities or user added another device in the middle, like a switch than you can identify a problem with Spanning-tree.

This are the basic stuff that I checked in regard to Layer 2 topology when I have no communication to the end host. In the next part, I will do a short presentation of the scenario when you have communication to end device, but the connection encounter traffic deprecation.

Check the 2nd Part of this series which deals with communication deprecation at Layer 2.

Do you have any other tips in regard to this topic? Anything else you check and can be added here? Be sure to comment below and your suggestion will be taken into consideration.