Tag: layer 2

Cisco tips: Track down communication issues – Part 1

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.

Cisco: Layer 2 traffic filtering

Layer 2 traffic filtering can be very useful when you want to drop packets closer to
the source because you can do this on L2 next-hop which is the switch where the
devices are connected. Based on mac-address, Layer 2 filtering can be apply using
one of the two most common method: Port Security and MAC Access Groups.

Port Security is the more secure method of the two. To use it, map a switch port to the
specific MAC address of the connected device. It gives you more possibility than just
drop the packets from a specific source, depending on what you want to achieve on
the interface where it is applied.

MAC Access Groups are generally used for small networks of 20 devices or less. Add
a permit statement for all of your devices interface MAC addresses and apply the access
list to switch interface. This will limit inbound traffic to that interface to only those
MAC addresses on your list. Is not recommended when you have many MAC addresses,
because MAC access-list are the same like IP address access-list, so they consume a
lot of resources of the machine where it is applied.

For this tutorial we will use a Cisco 3750 in which it is connected a router ( R4 ). To test
Layer 2 traffic filtering, we have a point-to-point Layer 3 connection in between
( 10.0.0.0 /30 ), with physical interface used on the R4 and a Vlan 4 interface on the
switch. The port on the switch were R4 is connected is an access port in vlan 4.

Please see the tutorial below:

Limit traffic on a Cisco switch L2 port with minimal configuration

Let’s say that somebody (or some task in a test) ask you to limit the inbound traffic on a switch Layer 2 port by using minimal configuration possible. I must say that in the first steps I failed this task miserable, but actually is very simple to do it.

I will use a plain layer 2 Cisco 2950 switch for this task. I observed that I could not implement this on a Cisco 3500XL. I don’t know if the IOS image was wrong, but I didn’t investigate too much in that area as I cannot stand 3500XL switches and they are actually pretty old piece of hardware.

No topology is needed for this as I will only show how to do it and not testing it with real traffic. I will do testing later when I’ll have some more time, or you can do it on your own.

See the tutorial below: