Tag Archives: 642-813

CCNP: Switch – Part 7

Advanced Spanning Tree Protocol

We have looked at STP, but now it is time to dive a little deeper into this. Lets look at some basic definitions, and these are grouped into two groups;

  • the fasts – port, uplink and backbone
  • the guards – root, bpdu and loop


Portfast allows an access port to go directly from blocking to forwarding mode, without going through the whole discovery / listen / learn phase. This makes for bringing host links up faster, but should only be used with host (access) ports.

For switches that have the majority of ports configured as access ports, we can globally configure portfast as follows:

conf t
spanning-tree portfast default

and then go in and change each port that you do not need portfast on by issuing:

no spanning-tree portfast

Best practice however would dictate that ports be configured on a per port basis, or by using the port range command. The other thing to remember is that these ports do not broadcast TCN BPDUs.


Both uplinkfast and backbonefast get around the long delay inherent in the transition from blocking to forwarding.  This is a bit like portfast, but where portfast disables STP on an access port, and does not transmit TCN BPDUs, uplink fast does. This enables a rapid transition from blocking to forwarding on redundant trunk ports.

The problem solved here is that using STP; if a primary link goes down, it can take up to 50 seconds for a backup link to come up. That is too long in todays networks.

We can create what is termed and uplink group. These are a group of links that can be used for inter switch communication, and need to come up fast if one goes down. Essentially when one goes down, STP immediately brings up a backup link without going through the learning and listening phases.

  • Best practice is to use this on the access layer only.
  • Uplinkfast can only be enabled globally, on all VLANs.
  • Uplinkfast cannot be enabled on a root switch

So what happens when if a root port goes down, a backup port comes up and then the root port comes back up again. STP will attempt to make the root port the primary link again, however it does wait a little while as determined by the following:

(2 x fdw delay ) + 5 seconds = 2 x 20 seconds + 5 = 45.

When uplinkfast is enabled on a switch, to ensure that the switch does not become the root switch, the switch priority is set to 49152. This is well above the default of 32768.

The STP port cost is also increased by 3000, making it unlikely that downstream switches will use this link as a root link.

The command to enable this is the global command Spanning-tree uplinkfast

So how does Uplinkfast work?
From Cisco: The UplinkFast feature is designed to run in a switched environment when the switch has at least one alternate/backup root port (port in blocking state), that is why Cisco recommends that UplinkFast be enabled only for switches with blocked ports, typically at the access-layer.

I read this mean that Uplinkfast will not be enabled on a root switch as it has no blocked ports.


Backbone fast is a Cisco proprietary system for recovering from an indirect link failure. So what on earth is an indirect link failure?

An indirect link failure is one that occurs on another switch, but affects the switch in question.

An indirect link failure is detected when an inferior BPDU is received by the switch. In essence, the switch receives two BPDUs from different switches, both claiming to be root; one might even be itself. The switch decides which has the better priority and forwards that BPDU to the other ‘root’ switch.

So how does all of this work. The protocol at work here is RLQ or Root Link Query. The RLQ is transmitted by the port that would normally receive BPDUs.

The command to turn on Backbonefast is spanning-tree backbonefast, and show spanning-tree backbonefast will give its status.

We are unlikely to come across backbonefast in the CCNP but we should be aware of it, as it can still be found in production networks; remember though, that it is Cisco proprietary so it will only be found on Cisco devices.


Root guard is configured at the port level, and prevents downstream switches from becoming the primary or secondary root switch. In essence, we use this to prevent edge switches from becoming the root, in the event of some sort of root failure.

When a superior BPDU is received on this port, the port drops the BPDU and puts the port into Root Inconsistent state.

It will stay in root-inconsistent until it stops receiving superior BPDUs, then it transitions via the normal STP listen and learn process to forwarding packets again.

The command is per interface; spanning guard root , and should be placed on all ports where there are downstream (edge) switches.

BPDU guard

Disables a port by putting it into error disable mode, when portfast is enabled (ie; it is an access port) and it starts to receive BPDUs (in other words, has another switch or network device connected to it rather than a host.)

This prevents switching loops by preventing topology changes caused by BPDUs coming from a device that should not be connected.

Per interface command is spanning-tree bpduguard enable (or disable) and the global version of the command is spanning-tree portfast bpduguard default.  This command is used on access ports and access switches to prevent rouge switches changing the switch topology, where the portfast command is used.

For instance, on my own home LAN switch, I have:

spanning-tree mode pvst
no spanning-tree optimize bpdu transmission
spanning-tree extend system-id
interface FastEthernet0/1
 spanning-tree portfast
 spanning-tree bpduguard enable
interface FastEthernet0/2
 spanning-tree portfast
 spanning-tree bpduguard enable
interface FastEthernet0/3
 spanning-tree portfast
 spanning-tree bpduguard enable
interface FastEthernet0/4
 spanning-tree portfast
 spanning-tree bpduguard enable

BPDU Filtering.

It is also possible to filter BPDUs. You might do this if you do not want your ports to go into error-disable.

The operation of BPDU filter is different depending on weather the config is global or per port.

  • In global configuration, enabling PBDU filtering will enable this on all ports running portfast, and portfast will stop running on that port, if that port recieves a BPDU.
  • In per port config, portfast continues to run and will drop (or not respond) to any BPDUs received.


Loopguard guards against switching loops. Say what? Isn’t that what spanning tree and all that stuff I wrote above, does? Well yes but;

Ports in blocking mode block data traffic, but are still able to receive BPDUs

If in a mesh of switches, one link becomes unidirectional, it is possible that a loop can occur. How does this happen? Well if a switch stops receiving BPDUs, it might start (after the max age time, default 20 seconds) to look at other BPDUs and decide to change its topology or even become the root.

If this happens, this can disrupt switch operation. Loopguard prevents this from happening by putting the unidirectional port into loop inconsistent state. It way stay in this state until the link becomes bidirectional again, when it will come out of loop inconsistent state automatically.

By default, LoopGuard is disabled but it can be enabled on a port by port, or global basis:

  •  Per port : spanning-tree guard loop
  • Global : spanning-tree loopguard default

Loop guard operates on a per VLAN basis only.which makes sense when you think about it because  spanning tree works on a per VLAN basis.

BDPU Skew Detection.

Sometimes when BPDUs are sent out from the root, in a large switch network, we might loose or delay a BPDU packet. If that delay is over 2 seconds the downstream switches might (under some circumstances) start to transition to a new topology. We don’t want this to happen.

When the switch detects this situation, it sends a syslog message, every 60 seconds, until the situation has cleared. This might be caused by heavy CPU usage or a similar transient situation, or it might be something more permanent like a broadcast storm.

In the case of the skew reaching max age time / 2 (i.e. 10 seconds) the switch will start transmitting syslog error messages immediately, as this is a critical situation.


UDLD (Uni Directional Link Detection)

This is primarily intended for fiber optic communication and troubleshooting. One of the issues with fiber connections, is that a fiber connection consists of a pair of fibers – one for each direction. In essence, fiber connections are unidirectional. If one fiber goes down, we still might have either receive or transmit capability.

To detect the status of the fiber link, UDLD transmits a frame, and:

  • if it receives a frame in return, the link is good
  • If no frame is returned, the link is considered unidirectional

UDLD operates in two modes: normal and aggressive. UDLD sends 8 packets (a sort of L2 ping) and if they are not received, it does the following:

  • Normal – generates a syslog error message only
  • Aggressive – puts the port into error disable after 8 UDLD messages.

UDLD sends one packet per second.

Can be enabled on a per port basis or globally, but however it is enabled, it only runs on fiber optic port. UDLD enable in global config mode.

It is important to note that UDLD must be running on both ends of the link in order for the UDLD link status to work.


To check the status of the above configurations, we can use show spanning-tree summary totals. This will give us the output of the spanning tree command and configurations thus:

s2940#sh spanning-tree summary totals
Switch is in pvst mode
Root bridge for: VLAN0001
EtherChannel misconfig guard is enabled
Extended system ID is enabled
Portfast Default is disabled
PortFast BPDU Guard Default is disabled
Portfast BPDU Filter Default is disabled
Loopguard Default is disabled
UplinkFast is disabled
BackboneFast is disabled
Pathcost method used is short

… or you can drill down on a per port basis by issuing the spanning-tree interface detail command.

s2940#sho spanning-tree int fa0/1 det
 Port 1 (FastEthernet0/1) of VLAN0001 is forwarding 
 Port path cost 19, Port priority 128, Port Identifier 128.1.
 Designated root has priority 32769, address 0021.1ce8.a5c0
 Designated bridge has priority 32769, address 0021.1ce8.a5c0
 Designated port id is 128.1, designated path cost 0
 Timers: message age 0, forward delay 0, hold 0
 Number of transitions to forwarding state: 1
 The port is in the portfast mode
 Link type is point-to-point by default
 Bpdu guard is enabled
 BPDU: sent 1378620, received 0
Tweet about this on TwitterShare on Google+Share on LinkedInShare on FacebookShare on RedditShare on StumbleUponEmail this to someone

CCNP: Switch – Part 6

VLAN Trunking Protocol

VTP is not really a trunking protocol, although we often refer to it as a trunking protocol. What it does is it allows each switch in the network to have synchronized view of all the VLANs in the network. It also allows administrators to restrict, delete, modify and create VLANs.

So why do we want to do this?

In an ideal world we could manually enter the vlan configurations on each switch in the network, and get all of the details perfectly correct … every time.  Sadly, with my fat fingers, this would not happen, so we use VTP to propagate information across the switches,

VTP does not run by default, but if you execute a show vtp status, unlike other commands you will always get an out put.


You can tell it isn’t running, as there is no domain listed.


Beware with the domain, because it is case sensitive, and if you cut and paste, beware trailing spaces, because they count as well.

Also notice the domain is empty at this point. That is because VTP isn’t running. Beware that the domain name is case sensitive, so make sure you get the case correct. The domain does have to be set for each switch, and the domain sets the area that VTP is work in.

A switch can only belong to one domain and one domain only. Changing the config to a new domain will result in the switch leaving the old domain.

Operating Modes

Switches can be in one of three VTP modes:

  • Server – switch can create modify delete vlans (default)
  • Client – cannot create, modify or delete vlans but will adjust based on advertisements from servers.
  • Transparent – passes VTP traffic but does not act on it. Does not participate in the VTP domain and can have its own VLANs but they are locally significant only.

… and we can see what mode the switch is in by executing a show vtp status command.

Note also that in order to create a vlan on a client switch, we must create it on the server switch and then add a port into that vlan on the client switch. You cannot create a vlan on a client switch alone.

We can add a VLAN to a port on any switch as long as that VLAN exists.

VTP Versions

There are two versions of DTP, version 1 and version 2. There are differences and they are important,

  • Version 1 – in transparent mode, a switch will only forward advertisements if the VTPversion number and domain name on the switch, match the downstream switches.
  • Version 2 – will forward VTP advertisements across trunks regardless of the vtp domain name of the downstream switches.


VTP advertisements are multicast, but they do not go out on each port, instead they flow via trunks. This is because the only other devices that need these advertisements are other switches trunking with the switch you are on.

Revision Number

These can be big gotcha’s too. The VTP advertisement carries this revision number. This is how changes stay synchronized. By checking the revision number in the received packet against the latest revision number that the switch has, the right changes are made (or forwarded) to the switch config.

The revision number is incremented and sent once a change has been made to a switch (remember though that client switches cannot make changes) and that the VTP packet (and thus the revision number) only applies within its own domain.

So if I add another switch to the domain that has a revision number higher than the current revision number, we are screwed because its VLAN config will get propagated as its revision number is higher.

This means we must have a mechanism for resetting the revision nuber, but if you check IOS help, there is no VTP reset command. SO in that case, how do we reset the revision number?

There are two ways:

  • put the switch in transparent mode and then back into client or server mode – this will reset the revision number
  • Change the domain to a non existent domain, and then back into the correct domain.

It would be best practice to check this value and reset it before adding a new switch to a network.

There are also three types of advertisement sent out of a switch:

  • Summary Ads
  • Subset ads
  • Request ads
Summary Ads.

Sent from a VTP server either, every 5 minutes, or every time a change is made. The ad packet contains:

  • VTP domain name and version number
  • Configuration number
  • MD5 hash code
  • Timestamp
  • number of subset advertisement to follow
 Subset ads

These are sent by VTP servers upon a VLAN change. The ad contains:

  • VLAN created, deleted, activated or suspended
  • VLAN name if there is one.
  • new MTU
  • VLAN type (Ethernet / Token Ring / FDDI)
Client Request Ads.

Sent by the clients to the server to replace a deleted or corrupted vlan database

A summary ad is usually sent out followed by a number of subset ads.


Configuring VTP is pretty simple. The first gotcha is the domain name. The Domain Name is Case Sensitive! Getting the case of a single letter or getting a trailing (or preceding) space can also screw up a configuration.

The next thing to configure is the mode, and from the above, we have server, client or transparent,

We can also set a password. If we issue the command vtp password. The password is stored in clear text, even if the set password-encryption is enabled.

Be aware that for the exam, we only cover VTP versions 1 and 2 but there is a version three. V3 exists in IOS, and it is good to know about it, but we don’t need it for the exam at all.

VTP pruning

We know that trunk ports belong to all VLANs and pass all VLAN traffic including broadcast and multicast VLAN information – for all vlans -. This is an inefficient use of bandwidth and resource, so VTP pruning can be used to limit the trunks passing traffic only for the VLANs at the other end of the trunk and not every VLAN.

VTP pruning only needs to be turned on, on one VTP server, and it will propagate across the entire domain.

  • 2-1001 can be pruned
  • 1 and 1002/3/4/5 cannot be pruned

Final thoughts on VTP

When troubleshooting:

  • look for case sensitivity in the domain name
    • Look for VLANs pruned in active switches (shouldn’t but can happen)
  • Show interface trunk often can be used to check this
  • make sure the versions are consistent
  • Try to use Version 2 as it checks VLAN consistency
  • Version 1 does not support token ring!
  • Check the password when in secure mode

Also, as a general rule, try to stay with server and client modes. Only use transparent mode if you have to, and secure the VTP server switches to prevent malicious activity.


Tweet about this on TwitterShare on Google+Share on LinkedInShare on FacebookShare on RedditShare on StumbleUponEmail this to someone

CCNP: Switch – Part 5

Changing the Native VLAN

Sometimes, in a busy switch, we might want to change the native VLAN if a particular vlan is passing a lot of data. By making it the native VLAN, we can reduce the overhead on the switch, by removing the need for tagging. (Remember the native VLAN isn’t tagged in dot1q)

The command for this is; switchport trunk native vlan n, where n is the VLAN number.

Changing the Encapsulation

We talk a lot about encapsulation being IEEE 802.1q (or dot1q as it is widely known) but as we mentioned in a previous post, there are two encapsulation types: dot1q and ISL. ISL (Cisco Inter Switch Link) is the Cisco proprietary encapsulation and dot1q is the industry standard.

So how to we select which encap type to use? The command here is; switchport trunk encapsulation with options:

    • dot1q
    • ISL
    • negotiation

Note that ISL and Negotiation are not options on most modern switches as ISL is almost dead at this point. However, beware negotiation – it is used to negotiate the trunk encapsulation, and if ISL is supported at both ends, ISL will be selected.

Dynamic Trunk Protocol

The Dynamic Trunk Protocol (DTP) is our third trunk protocol, and is a Cisco Proprietary point to point protocol that attempts to negotiate a trunks with remote switch ports.

Show DTP will give the status of the DTP on a switch, or if you want more information than you can shake a stick at – show dtp interface.

The overhead is low, with HELLO frames sent every 30 seconds, but it runs on a per port basis. The timeout is 300 seconds.

There are two ways to get a trunk to form and we have looked at these before but we are going to take a little deeper look now. We can:

  • manually configure the port
  • let the switch handle the port automatically

To manually set the port we can use the above commands as well as switchport mode trunk.  We can also prevent the switch from negotiating encapsulation by executing a switchport nonegotiate (but this will only work if the port is in a non dynamic i.e. trunk mode)

Dynamic Auto will form trunks if asked, but will not actively form trunks.

Dynamic Desirable runs about forming trunks where ever it can!


Note that two dynamic auto mode trunks will not form trunk … and to turn off a trunk, simply make it an access port.

5.  VLAN filtering with trunks.

We can have a lot of VLANs and even in small modern networks, we can start to see quite a few VLANs popping up. We can have up to 4094 VLANs!

So how do we handle all these VLANS flowing over our trunks? We can filter VLAN traffic over our trunks. The default state is that all the VLANs are carried over the trunks, however; what if we want to  exclude a VLAN or two, or maybe only allow specific VLANs to run across a trunk?

We can implement that using the switchport allowed VLAN n command. We have options to add, except, all, none or remove.

In essence, we create a list of VLANs that we can add or subtract from the greater list; for instance:

  • switchport allowed vlan 10                 — only allows vlan 10
  • switchport allowed vlan except 10 — blocks vlan 10

… and so on.

Naming VLANs

So now that we have all of these VLANs, how do I keep track of them. Cisco switches allow us to assign names to vlans using the name command in vlan-config. In global config mode, I can type the vlan n command and drop into config mode. Then I can name the vlan.

conf t
vlan 10
name sales

You may notice that we configure vlans in much the same way that we configure ports, but there is another way that we can configure vlans. This comes from the old Catalyst day, and it is the VLAN Database.

Cisco doesn’t really recommend vlan database, but some older switches still support it. To get into the vlan database mode, you need to be in enable, not global configuration mode.

The command is vlan database.

When exiting this mode, you must remember to add the command apply or use exit (not ctrl Z). If you do not, you will loose all of your edits.

VLAN Design

The next question of course is; how do we decide what vlans to implement and how? This is where design comes in. As we work through this, keep the Cisco three layer switch design in mind (Core, Distribution and Access).

  • at the access layer we try to do Quality of Service (QoS) and vlan tagging.
  • at the distribution layer we can do layer three switching
  • at the core we do switching and only switching

Now, these are not hard and fast rules but as a general rule of thumb, they work.

End To End VLANS

Vlans span the entire network. This is where the host stays in the same vlan no matter where it is in the network. A nightmare to administer, but gives security. Use the 80/20 here.

80% of the traffic stays local to the switch and 20% travels across the network.

This type of design is dated as todays networks have a lot of mobile users.

Local vlans

These are designed with the 20/80 rule which states that 20% of the traffic is local traffic and the other 80% travels across the network. In this way we essentially group users by location. This is more typical of todays networks as we might have traffic moving over a WAN link to data center or off site server farm. In addition, we might have multiple remote offices and so on.

And Finally

The vlan data base is a separate file from the startup-config, so erasing the startup configuration DOES NOT remove the vlans from your switch. To do that, you must delete the vlan data base, vlan.dat.



Tweet about this on TwitterShare on Google+Share on LinkedInShare on FacebookShare on RedditShare on StumbleUponEmail this to someone

CCNP: Switch – Part 4

VLANS and Trunking

1.  Virtual Local Area Networks (refresh)

From our CCNA studies, we know that VLANS are used to limit broadcast scope, but they also limit network traffic. If we want hosts on different VLANs to be able to talk to each other, we have to use one of three methods:

Note that the best practice for VLANs is one VLAN per IP subnet

2.  SwitchPort Refresh

Cisco switch ports can are by default in dynamic desirable trunking mode which means that the ports will take the configuration of what ever is connected to it. If we connect a trunk, the port will trunk, if we connect a host, it will become an access port. Trunk ports are essentially transparent to VLANs and are used to allow all traffic between switches and switches, or switches and routers. Access ports can ONLY exist in one VLAN, which also means a host can ONLY exist in one VLAN. Port VLAN membership depends on two factors:

  • Static VLAN: the port is assigned to the VLAN and therefore any host connected to that port will be in that VLAN.
  • Dynamic VLAN: the VLAN is keyed to the host mac address, and thus the port is in what ever VLAN is keyed to the mac address of the host connected to the port.

Dynamic VLANs are not a part of the NP studies, but a brief run down on Dynamic VLAN can be found here.

A quick note about VLAN membership. When a packet enters a switch, via a port, the packet is tagged with the VLAN information pertaining to the VLAN membership of that port. It is this tag, that enables ports to filter VLAN traffic.

However, to get a switch port to perform this function, we have to tell it that it is a switchport and it belongs to a specific VLAN. We do this using the switchport command:

switchport mode access
switchport access vlan n

We do this because, by default, Cisco switchports are in Dynamic Desirable mode, meaning they are looking to trunk, and want to trunk. This can be a security risk.

3.  Trunk Ports

To get traffic across a trunk, the packets have to be encapsulated, so that the VLAN information is sent with the traffic. VLANs often span multiple switches and so we tag (or encapsulate) each packet with its corresponding VLAN ID. There are a number of ways to do this:

  • Inter Switch Link Protocol (ISL) – Cisco proprietary, not really used any more.
  • IEEE 802.1q (dot1q) – industry standard, used everywhere.
  • Dynamic Trunking Protocol (DTP) – Cisco proprietary, negotiates trunks.

ISL encapsulates the frame with a 26 byte header and 4 byte (CRC) trailer packet, for all VLANs. This adds overhead. It also does not understand the concept of native VLAN. Dot1q does not add any encapsulation to the native VLAN, and a 4 byte header for other VLANs, BUT the ‘header’ information is embedded within the frame, so the frame size remains the same. This is important because a frame is 1518 bytes. Add the ISL overhead and that makes it 1548 bytes … making it a giant frame.  With Dot1q adding the 4 byte header within the frame, it just reduces the payload by 4 bytes.

So, we have:

  • Runt frame <64 bytes
  • IEEE 802.3u frames up to 1518 bytes
  • IEEE 802.3ac allows for a frame up to 1522 bytes
    • (this allows a standard frame plus 4 bytes for Dot1q)
  • Frames >1518 bytes are giants
  • some Cisco devices have hardware to handle giant frames

All of this is great but how do we turn off a trunk port and stop it from trunking?  There is no trunk port off command, we simply make it an access port.

One command we should get used to using is show vlan id n. This gives a very nice run down on the VLAN and its ports.

4.  VMPS

Dynamic VLANs, as mentioned above are out of the scope of the CCNP, but we should know a little of the basics.  Dynamic VLANs are based on the VMPS or VLAN Membership Policy Server.

With VMPS, the VLAN is assigned to a host mac address, rather than the port. In order to facilitate this, the MAC address and VLAN assignment is stored in a database, on a TFTP server.

The VMPS data base is read every time the VMPS server is power cycles. The transfer format is UDP so we must make sure we do not block UDP using ACLs.

There are a few things to remember, when using VMPS:

  • portfast is enabled when for each access port by default
  • configure the data base, before configuring the ports
  • turn off port security when using VMPS
  • do not use VMPS when using trunks


Tweet about this on TwitterShare on Google+Share on LinkedInShare on FacebookShare on RedditShare on StumbleUponEmail this to someone

CCNP: Switch – Part 3

Continuing on with more about Spanning Tree Protocol from our last post.

How do we make our switch superior?

I mentioned above how we can influence the root bridge election by changing the spanning tree priority number. Its default is 32768, but we can change that (in increments of 4096) by using the spanning-tree vlan priority command.

By reducing the priority number, we can make our switch the root.

This is all great but what if I want to change the blocking ports on a per VLAN basis?

Well we can do that. Remember that traffic cannot span vlans without a router, so:


… this is a good representation of a per vlan stp scheme. We can change the blocked port by changing the port cost on a per VLAN basis as follows:

conf t
int fa0/n
spanning-tree vlan 9 cost 5

The cost is the new route cost is 5 and that makes (in this example) the STP recalculate for VLAN 9 only, a new route to the root bridge.

Using this technique, we can do some very primitive load balancing because vlan 1 traffic will use one port, and vlan 9 traffic will use another, but will still prevent switching loops.

In addition to this, we can peg the switch as the root by issuing the command spanning-tree vlan 1 root and that will make the switch the root bridge.

About these root bridges …

We can set a primary switch or root bridge (often a core switch in a larger network), but we can also specify a secondary root switch. This is handy in the case of a large network because it defines which switch will take over in the event of the primary switch failing. This might be important for smooth (but redundant) operation

The command for this would be spanning-tree vlan 1 root primary and spanning-tree vlan1 root secondary.


In this case it would be prudent to have the core switch as the primary root bridge, with the second core switch as the secondary root bridge. To have one of the access switches as the root in the event of a failure of the primary, would not be good for the smooth running of the network.

This is all very interesting, but how fast does all this STP stuff switch?

This is a great question and is sure to be an exam question. Lets say we have an stable STP set up and a cable goes bad, we loose connection and another port must come out of blocking to keep the traffic flowing. Well it isn’t instant. if it was, we would have the potential for more switching loops. What has to happen is that potential root ports must go through a number of states to determine which port becomes the new root port.

Those states are:

  • Disabled – this is a port that is administratively down. Cisco recognizes this as a valid STP state.
  • Blocking – no frame forwarding or receiving, and can only receive BPDUs
  • Listening – receives BPDUs, and can send BPDUs, allowing the port to participate in  root bridge election
  • Learning – Learning MAC addresses, but not forwarding frames yet.
  • Forwarding – send and receive frames and so on.

We can use show spanning-tree interface to have a look at individual interfaces and their STP status. The time spent in each of these states is dictated by the STP timers.

STP Timers

The STP algorithm is controlled by a number of timers – Beware – do not mess with these without good reason; they work well just they way they are. With that said, lets go poke them a bit and see what happens.

If you need to change a timer value, you MUST change it on the root bridge. The root will then inform the rest of the switch network of the change in timer value via BPDUs.

What timers do we have to play with?

There are three timers that control the STP algorithm. They are:

  •  Hello Time (default = 2 Seconds) – sets the frequency with which the root bridge sends out configuration BPDUs.
  • Forward Delay (default = 15 seconds) – this is the timer for each of the listening and learning phases
  • Maximum Age (default = 20 seconds) – this is the amount of time a switch retains the superior BPDU info before releasing it.

The command to change the timers is the same as the command above – spanning-tree vlan x ….. because the timers are set on a per VLAN basis.

With that said, if you change the timers for what ever reason and you have a secondary root bridge set up, you should change the timers there too.

What is the significance of the Root ID Priority?

Those numbers look familiar don’t they? Especially, if like me, you have spent a lot of time working with digital systems; 32768 is a nice round number for a default!

These numbers are calculated by the STP algorithm. For instance, when the spanning-tree vlan 1 root primary and secondary commands are issued, the STP algorithm lowers the priority ID number to ensure the election of the root bridge. Also remember that the increment for this priority number is steps of 4096.

  • Primary = 24596  —  (32768 – (2 x 4096))
  • Secondary =  28692  — (32768 – (1 x 4096))

So what the command does is decrements the Priority figure by 2 x 4096 for the root, and 1 x 4096 for the secondary.  Simple right? Well its not quite like that, there is a little more detail to it.

  • If the current Root Priority >24576
    • then new root Priority = 24576 (which is 24596 – 20)
  • If the current Root Priority <24576
    • then the new priority is that number -4096
Topology Change Notifications

These were the other BPDUs I mentioned at the beginning of this (rather long) blog post. So what do TCN BPDUs do?

TCN BPDUs are transmitted from any switch when it either:

  • puts a port into forwarding mode
  • put a port into blocking mode from forwarding or learning mode

That TCN BPDU is forwarded from the originator switch to the root switch.

Each switch that received the TCN, will forward it, and send an ACK back to the originator switch.

The root switch then sends a ACK as a configuration BPDU to the rest of the switch network. That BPDU has the topology change bit set, which tells the switches to change the Mac address table Ageing time from the default 300 seconds, to  the forward delay value (15 seconds).

This allows the switches to flush their MAC address tables of invalid entries. The switch does this for a total of:

forward delay (15 seconds) + max age (20 seconds) = 35 seconds

before reverting the ageing time back to the default value of 300 seconds again.

What About Portfast?

Portfast enabled ports cannot generate TCNs (because the are connected directly to hosts only)

Switch Load Sharing

We have looked a couple of ways of load sharing or primitive load balancing with:

  • per VLAN root assignments
  • adjusting port costs on a per vlan basis
  • but we can also adjust the vlan priority on a per port basis.

In interface config mode we can use the spanning-tree command to adjust the vlan priority for a single or range of vlans. The port priority value is 0-240, with 128 being the default.


You can see the effect of the port priority here in this screen shot. I have adjusted some of the ports to have a priority of 64 in some vlans.

Of course, the best way to load balance a group of trunks is to bundle them and create an Etherchannel, but sometimes, its good to mix things up!

Tweet about this on TwitterShare on Google+Share on LinkedInShare on FacebookShare on RedditShare on StumbleUponEmail this to someone