Tag: spanning-tree

Cisco STP forward-time command trick

This is more a topic for exams, like Cisco CCIE, but also it can appear in real-world environments.

Consider the following simple topology:
Simple L2 topology

SW1 is the spanning-tree root bridge for all VLANs. Imagine that you have a request which ask you that when a port becomes active, no matter of VLAN, it should wait 10 seconds until it transition to forwarding state.

You look into configuration mode and spot the “spanning-tree .. forward-time..” command. OK, simple enough, you go there and type:

spanning-tree vlan 1-4094 forward-time 10

Task completed. This is what I also thought. Looks pretty straight forward, but it’s a mistake which I learned from and I hope you will read this before doing it.
Lucky for me it was just a test lab not the real CCIE lab, but if I don’t teach this kind of things or spend the entire day fine-tuning STP, I tend to forget.

Back to this example, let’s see on the SW2 what’s happening after I did configure the above command on SW1. By the way, you need to configure this command only on the STP root bridge because the downstream devices will inherit the values.

On the SW2 I shutdown the root interface to force the alternate interface (which is in blocking state) to transition to forward state and check the output of “debug spanning-tree events” :

00:55:15: STP: VLAN0001 new root port Fa0/2, cost 19
00:55:15: STP: VLAN0001 Fa0/2 -> listening
...
00:55:25: STP: VLAN0001 Fa0/2 -> learning
...
00:55:35: STP: VLAN0001 sent Topology Change Notice on Fa0/2
00:55:35: STP: VLAN0001 Fa0/2 -> forwarding

From :15 seconds when the port entered Listening state until :35 seconds when it went into Forwarding state there are 20 seconds. We were required to have 10 seconds not 20. That’s not good.

Going back and checking the parameters of a STP for a particular VLAN did not give me too much information to clarify the issue:

show spanning-tree vlan 1 | i Forward
Hello Time   3 sec  Max Age 10 sec  Forward Delay 10 sec

OK, after reading again carefully the documentation I came to the understanding that value added to this command is applied to each state towards the forwarding state.
The STP Port States are: Blocking, Listening, Learning, Forwarding and Disabled.

When I did shutdown the root port, the alternate port when immediately to Listening state then waited for 10 seconds until it transition to Learning state and again 10 Seconds to achieve Forwarding state.

The correct solution was obvious now to decrease the forward-time to 5 seconds.

spanning-tree vlan 1-4094 forward-time 5

Let’s check again:

01:11:55: STP: VLAN0001 new root port Fa0/2, cost 19
01:11:55: STP: VLAN0001 Fa0/2 -> listening
...
01:12:00: STP: VLAN0001 Fa0/2 -> learning
...
01:12:05: STP: VLAN0001 sent Topology Change Notice on Fa0/2
01:12:05: STP: VLAN0001 Fa0/2 -> forwarding

Now the total time is 10 second.

I hope this will help others to avoid my mistakes.


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.