CCNP ROUTE 300-101 Part 1.0 – Network Principles

In its basic essence, Cisco Express Forwarding (CEF), is a feature that allows a router
to quickly and efficiently make a route lookup.


Cisco Express Forwarding

CEF is an optimized Layer 3 forwarding path through a router or switch. CEF optimizes routing table lookup by creating a special, easily searched tree structure based on the IP routing table. The forwarding information is called the Forwarding Information Base (FIB), and the cached adjacency information is called the Adjacency Table.


A lot of sources on router architecture divides router functions into three operational planes:

  • Management plane: is concerned with the management of the device. For example, an administrator connecting to a router through a Secure Shell (SSH) connection through one of the router’s VTY lines would be a management plane operation.
  • Control plane: is concerned with making packet-forwarding decisions. For example, routing protocol operation would be a control plane function. (the brain of the network)
  • Data plane: is concerned with the forwarding of data through a router (ASIC). For example, end-user traffic traveling from a user’s PC to a web server on a different network would go across the data plane. (means the hardware itself)


Data plane and control plane are the two planes that most directly impact how quickly packets can flow through a router. We will consider these two planes of operation and examine three different approaches that Cisco routers can take to forward packets arriving on an ingress interface and being sent out an appropriate egress interface – Packet Switching.


Note: Many people have a challenge with the term packet switching, because they think of Layer 2 operation, while routing being a Layer 3 operation. The key to understanding this term is to think of “Frame Switching” being Layer 2, while “Packet Switching” (routing) Layer 3 operation.


Cisco routers support the following three primary modes of packet switching:

  • Process switching
  • Fast switching
  • Cisco Express Forwarding (CEF)


Process Switching

When a router routes a packet (that is, performs packet switching), the router removes the packet’s Layer 2 header, examines the Layer 3 addressing, and decides how to forward the packet. The Layer 2 header is then rewritten (changing the source and destination MAC addresses and computing a new CRC), and the packet is forwarded out an appropriate interface. With process switching, as shown below, a router’s CPU becomes directly involved with packet-switching decisions. As a result, the performance of a router configured for process switching can suffer significantly.

packet switching

Note:  An interface can be configured for process switching by disabling fast switching on that interface. The command used to disable fast switching is:

R1(config)# no ip route-cache


Fast Switching

Fast switching uses a fast cache maintained in a router’s data plane (hardware). The fast cache contains information about how traffic from different data flows should be forwarded. As seen below, the first packet in a data flow is process switched by a router’s CPU.

After the router determines how to forward the first frame of a data flow, the forwarding information is stored in the fast cache. Subsequent packets in that same data flow are
forwarded based on information in the fast cache, as opposed to being process switched.
As a result, fast switching dramatically reduces a router’s CPU utilization, as compared to
process switching.

fast switching

Fast switching can be configured in interface configuration mode with the command:

R1(config-if)# ip route-cache


Cisco Express Forwarding

CEF maintains two tables in the data plane (forwarding plane). The Forwarding Information Base (FIB) maintains Layer 3 forwarding information, whereas the Adjacency table maintains Layer 2 information for next hops listed in the FIB.

Using these tables, populated from a router’s IP routing table and ARP cache, CEF can efficiently make forwarding decisions. CEF does not require the first packet of a data flow to be process switched, like fast switching. Rather, an entire data flow can be forwarded at the data plane, as seen below.


On many platforms, CEF is enabled by default. If it is not, you can globally enable
it with the following command:

R1(config)# ip cef

Alternately, if CEF is enabled globally but is not enabled on a specific interface, you can enable it on that interface with interface configuration command

R1(config-if)# ip route-cache cef


CEF Configuration and Verification

Enable CEF globaly

R1(config)# ip cef


Enable CEF on an interface (if CEF is globally enabled), in interface mode

R1(config-if)# ip route-cache cef


Verify multiple interface statistics, including information about an interface’s packet-switching mode.

R1# show ip interface fa0/0


Verify the contents of a router’s FIB.

R1# show ip cef


Verify information contained in the adjacency table of a router, including protocol and timer information.

R1# show adjacency detail


Next example illustrates the configuration and verification of CEF operation.  The routers in this topology have already been configured to exchange routes through EIGRP.

cef operation

R1 has CEF enabled globally but CEF is not enabled on interface Fa0/0. Next example shows how to enable CEF on an interface if CEF is already enabled globally.

R1# show ip int fa 0/0
FastEthernet0/0 is up, line protocol is up
Internet address is
Broadcast address is
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined:
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP Flow switching is disabled
IP CEF switching is disabled


Configure CEF on the same interface

R1# conf term
R1(config)# int fa 0/0
R1(config-if)# ip route-cache cef
R1(config-if)# end


Verify CEF configuration on the interface

R1# show ip int fa 0/0
FastEthernet0/0 is up, line protocol is up
Internet address is
Broadcast address is
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined:
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP Flow switching is disabled
IP CEF switching is enabled


On R2 CEF is disabled globally so we need to configure CEF on R2

 R2# show ip int fa 0/0
FastEthernet0/0 is up, line protocol is up
Internet address is
Broadcast address is
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined:
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is disabled
IP Flow switching is disabled
IP CEF switching is disabled

R2# conf t
R2(config)# ip cef
R2(config)# end
R2# show ip int fa 0/0
FastEthernet0/0 is up, line protocol is up
Internet address is
Broadcast address is
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined:
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP Flow switching is disabled
IP CEF switching is enabled


Verifying CEF operation on R1

R1# show ip cef
Prefix Next Hop Interface no route drop receive receive Loopback0 Serial1/0 attached Serial1/0 receive Serial1/0 receive Serial1/0 receive Serial1/0 drop attached FastEthernet0/0 receive FastEthernet0/0 receive FastEthernet0/0 receive FastEthernet0/0 Serial1/0 drop receive drop receive

R1# show adjacency detail
Protocol Interface Address
IP Serial1/0 point2point(11)
0 packets, 0 bytes
epoch 0
sourced in sev-epoch 1
Encap length 4


The show ip cef command, shows the contents of the FIB for Router R1. Note that if the next hop of a network prefix is set to attached, the entry represents a network to which the router is directly attached. If the next hop of a network prefix is set to receive, the entry represents an IP address on one of the router’s interfaces.

For example, the network prefix, with a next hop of attached, is a network
(30-bit mask) directly attached to Router R1’s Serial 1/0 interface. However, the network prefix of with a next hop of receive is a specific IP address (32-bit mask). Note that the all-0’s host addresses for directly attached networks (for ex, and the all-1’s host addresses for directly attached networks (for ex, also show up as receive entries.

Output from the show adjacency detail command displays information about how to
reach a specific adjacency shown in the FIB. Indicates that network /24 is reachable by going out of interface Serial 1/0. The adjacency table also shows interface Serial 1/0 uses a point-to-point connection. Therefore, the adjacent router is on the other side of the point-to-point link. If an interface in the adjacency table is an Ethernet interface, source and destination MAC address information is contained in the entry for the interface.



Hope this helps someone else!


CCNP SWITCH 300-115 – Part 3 Infrastructure Services – FHRP


Multilayer switches can act as IP gateways for connected hosts by providing gateway addresses at VLAN SVIs and Layer 3 physical interfaces. These switches can also participate in routing protocols, just as traditional routers do. For high availability, multilayer switches should offer a means of preventing one switch (gateway) failure from isolating an entire VLAN. Now we will focus on several approaches to providing router redundancy, including the following:

  • Hot Standby Router Protocol (HSRP)
  • Virtual Router Redundancy Protocol (VRRP)
  • Gateway Load Balancing Protocol (GLBP)

These are also commonly called first-hop redundancy protocols (FHRP) because the first router hop is given high availability.


Packet-Forwarding Review

When a host must communicate with a device on its local subnet, it can generate an ARP request, wait for the ARP reply, and exchange packets directly. However, if the far end is located on a different subnet, the host must rely on an intermediate system (a router, for example) to relay packets to and from that subnet.

A host identifies its nearest router, aka default gateway or next hop, by its IP address. If the host understands something about routing, it recognizes that all packets destined off-net must be sent to the gateway’s MAC address rather than the far end’s MAC address. The host first sends an ARP request to find the gateway’s MAC address. Then packets can be relayed to the gateway directly without having to look for ARP entries for individual destinations.

If the host is not so savvy about routing, it might still generate ARP requests for every off-net destination, hoping that someone will answer. Obviously, the off-net destinations cannot answer because they never receive the ARP request broadcasts, these requests are not forwarded across subnets (blocked by routers, firewalls, or even switches). Instead, you can configure the gateway to provide a proxy ARP function so that it will reply to ARP requests with its own MAC address, as if the destination itself had responded.

The issue of gateway availability becomes important. If the gateway router for a subnet or VLAN goes down, packets have no way of being forwarded out the local subnet. Several protocols are available that allow multiple routing devices to share a common gateway address so that if one goes down, another automatically can pick up the active gateway role.


Note: IPv6 offers some inherent gateway redundancy because every router connected to a subnet advertises its presence. Hosts overhear the advertisements and use the first router received. If that router fails, hosts have to wait up to 40 seconds to discover a replacement router—an inefficient process.


Hot Standby Router Protocol

HSRP is a Cisco proprietary protocol developed to allow several routers (or multilayer switches) to appear as a single gateway IP address. RFC 2281 describes this protocol in more detail.

HSRP runs on top of UDP port 1985. Packets are sent to multicast with TTL 1. Routers (or MLSs) use their actual IP address as the source address for protocol packets, not the virtual IP address. This is necessary so that the HSRP routers can identify each other.

The format of the data portion of the UDP datagram is:

                          1                   2                   3

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |   Version     |   Op Code     |     State     |   Hellotime   |
   |   Holdtime    |   Priority    |     Group     |   Reserved    |
   |                      Authentication  Data                     |
   |                      Authentication  Data                     |
   |                      Virtual IP Address                       |


As a brief explanation, each of the routers that provides redundancy for a given gateway address is assigned to a common HSRP group. One router is elected as the primary, or active, HSRP router, another is elected as the standby HSRP router and all the others remain in the listen HSRP state. The routers exchange HSRP hello messages at regular intervals so that they can remain aware of each other’s existence and that of the active router.

Below shows a simple network in which two multilayer switches use HSRP Group 1 to provide the redundant gateway address Switch A is the active router, with priority 200, and answers the ARP request for the gateway address. Because Switch B is in the Standby state, it never is used for traffic sent to Instead, only Switch A performs the gateway routing function, and only its uplink to the access layer is utilized.











Note: HSRP sends its hello messages to the multicast destination (“all routers”) using UDP port 1985.

An HSRP group can be assigned an arbitrary group number, from 0 to 255. If you configure HSRP groups on several VLAN interfaces, it can be handy to make the group number the same as the VLAN number. However, most Catalyst switches support only up to 16 unique HSRP group numbers. If you have more than 16 VLANs, you will quickly run out of group numbers. An alternative is to make the group number the same (that is, 1) for every VLAN interface. This is perfectly valid because the HSRP groups are locally significant only on an interface. HSRP Group 1 on interface VLAN 10 is unique and independent from HSRP Group 1 on interface VLAN 11.


HSRP Router Election

HSRP election is based on a priority value (0 to 255) that is configured on each router/MLS in the group. By default, the priority is 100.

The router with the highest priority value (255 is highest) becomes the active router for the group. If all router priorities are equal or set to the default value, the router with the highest IP address on the HSRP interface becomes the active router. To set the priority, use the following interface configuration command syntax:

Switch(config-if)# standby group priority priority


Suppose that one switch is left at its default priority of 100, while the local switch is intended to win the active role election. You can use the following command to set the HSRP priority to 200:

Switch(config-if)# standby 1 priority 200



When HSRP is configured on an interface, the router progresses through a series of states before becoming active. This forces a router to listen for others in a group and see where it fits into the pecking order. Devices participating in HSRP must progress their interfaces through the following state sequence:

1. Disabled
2. Init
3. Listen
4. Speak
5. Standby
6. Active


Only the Standby (second-highest priority) monitors the hello messages from the Active router. By default, hellos are sent every 3 seconds. If hellos are missed for the duration of the Hold-Time timer (default 10 seconds, 3x the Hello timer), the active router is presumed to be down. The standby router is then clear to assume the active role.

At that point, if other routers are sitting in the Listen state, the next-highest priority router is allowed to become the new standby router.

If you need to change the timer values, use the following interface configuration command. If you decide to change the timers, you should change them identically on all routers in the HSRP group.

Switch(config-if)# standby group timers [msec] hello [msec] holdtime


The hello and holdtime values can be given in seconds or in milliseconds, if the msec keyword precedes a value. The hello time can range from 1 to 254 seconds or from 15 to 999 milliseconds. The holdtime always should be at least three times the Hello timer and can range from 1 to 255 seconds or 50 to 3000 milliseconds.


Set the hello time at 100 milliseconds and the hold time to 300 milliseconds:

Switch(config-if)# standby 1 timers msec 100 msec 300


After the active router fails and the standby becomes active, the original active router cannot immediately become active when it is restored. In other words, if a router is not already active, it cannot become active again until the current active router fail, even if its priority is higher than that of the active router. An interesting case arises when routers are just being powered up or added to a network. The first router to bring up its interface becomes the HSRP active router, even if it has the lowest priority of all.

Configure a router to preempt or immediately take over the active role if its priority is the highest at any time:

Switch(config-if)# standby group preempt [delay [minimum seconds] [reload seconds]]


By default, the local router immediately can preempt another router that has the active role. To delay the preemption, use the delay keyword followed by one or both of the following parameters:

  • minimum – Add this keyword to force the router to wait for seconds (0 to 3600 seconds) before attempting to overthrow an active router with a lower priority. This delay time begins as soon as the router is capable of assuming the active role, such as after an interface comes up or after HSRP is configured.
  • reload – Add this keyword to force the router to wait for seconds (0 to 3600 seconds) after it has been reloaded or restarted. This is handy if there are routing protocols that need time to converge. The local router should not become the active gateway before its routing table is fully populated or it might not be capable of routing traffic properly.
  • HSRP also can use an authentication method to prevent unexpected devices from spoofing or participating in HSRP. All routers in the same standby group must have an identical authentication method and key. You can use either plain-text or MD5 authentication.


Plain-Text HSRP Authentication

HSRP messages are sent with a plain-text key string (up to eight characters) as a simple method to authenticate HSRP peers. If the key string in a message matches the key configured on an HSRP peer, the message is accepted. When keys are sent in the clear, they can be easily intercepted and used to impersonate legitimate peers. Plain-text authentication is intended only to prevent peers with a default configuration from participating in HSRP. Cisco devices use cisco as the default key string. This is useful only in a point-to-point interfaces or lab environments.

You can configure a plain-text authentication key for an HSRP group with the following interface configuration command:

Switch(config-if)# standby group authentication string


MD5 Authentication

MD5 authentication hash is computed on a portion of each HSRP message and a secret key known only to legitimate HSRP group peers. The MD5 hash value is sent along with HSRP messages. As a message is received, the peer recomputes the hash of the expected message contents and its own secret key, if the hash values are identical, the message is accepted.

MD5 authentication “secure” because the hash value contained in the HSRP messages is extremely difficult (if not impossible as off now) to reverse. The hash value itself is not used as a key, instead, the hash is used to validate the message contents.

You can configure MD5 authentication by associating a key string with an interface, using the following interface configuration command:

Switch(config-if)# standby group authentication md5 key-string [0 | 7] string


Note: By default, the key string (up to 64 characters) is given as plain text. This is the same as specifying the 0 keyword. After the key string is entered, it is shown as an encrypted value in the switch configuration. You also can copy and paste an encrypted key string value into this command by preceding the string with the 7 keyword.


Alternatively, you can define an MD5 key string as a key on a chain. This method is more flexible, enabling you to define more than one key on the switch. Any of the keys then can be associated with HSRP on any interface. If a key needs to be changed, you simply add a new key to the key chain and retire (delete) an old key.

First define the key chain globally, then add one key at a time. The key-number index is arbitrary, but keys are tried in sequential order. Finally, associate the key chain with HSRP on an interface by referencing its chain-name. You can use the following commands to configure HSRP MD5 authentication:

Switch(config)# key chain chain-name
Switch(config-keychain)# key key-number
Switch(config-keychain-key)# key-string [0 | 7] string
Switch(config)# interface type mod/num
Switch(config-if)# standby group authentication md5 key-chain chain-name


Conceding the Election

Consider an active router in an HSRP group: A group of clients sends packets to it for forwarding, and it has one or more links to the rest of the world. If one of those links fails, the router remains active. If all of those links fail, the router still remains active. But sooner or later, the path to the rest of the world is either crippled or removed, and packets from the clients no longer can be forwarded.

HSRP has a mechanism for detecting link failures and swaying the election, giving another router an opportunity to take over the active role. When a specific interface is tracked, HSRP reduces the router’s priority by a configurable amount as soon as the interface goes down. If more than one interface is tracked, the priority is reduced even more with each failed interface. The priority is incremented by the same amount as interfaces come back up.

Particularly useful when a switch has several paths out of a VLAN/segment, as more interfaces fail and remove the possible paths, other HSRP peers should appear to be more desirable and take over the active role. To configure interface tracking, use the following interface configuration command:

Switch(config-if)# standby group track type mod/num [decrementvalue]


Default decrement value for an interface is 10. Interface tracking does not involve the state of the HSRP interface itself. Instead, the state of other specific interfaces affects the usefulness of the local router/MLS as a gateway. The only way another router/switch can take over the active role after interface tracking reduces the priority is if the following two conditions are met:

  • Another router/switch now has a higher HSRP priority.
  • That same router/switch is using preempt in its HSRP configuration.


HSRP Gateway Addressing

Each router/switch in an HSRP group has its own unique IP address assigned to an interface. This address is used for all routing protocol and management traffic initiated by or destined to the router. In addition, each router has a common gateway IP address, the virtual router address, which is kept alive by HSRP. This address aka the HSRP address or the standby address. Clients can point to that virtual gateway address as their default gateway, knowing that a router/switch always keeps that address active. Keep in mind that the actual interface address and the virtual (standby) address must be configured to be in the same IP subnet.

You can assign the HSRP address with the following interface command:

Switch(config-if)# standby group ip ip-address [secondary]


When HSRP is used on an interface that has secondary IP addresses, you can add the secondary keyword so that HSRP can provide a redundant secondary gateway address.


Note: To use HSRP with IPv6, use the following commands to enable HSRP Version 2 and set the HSRP address:

Switch(config-if)# standby version 2
Switch(config-if)# standby ipv6 autoconfig


Each router/switch keeps a unique MAC address for its interface. This MAC address is always associated with the unique IP address configured on the interface.

For Virtual router address, HSRP defines a special MAC address of the form:


Where xx represents the HSRP group number as a two-digit hex value. For example, HSRP Group 1 appears as:


HSRP Group 16 appears as below (and so on):



Configuration commands you can use to configure switches A and B

Switch-A(config)# interface vlan 50
Switch-A(config-if)# ip address
Switch-A(config-if)# standby 1 priority 200
Switch-A(config-if)# standby 1 preempt
Switch-A(config-if)# standby 1 ip
Switch-A(config-if)# no shutdown
Switch-B(config)# interface vlan 50
Switch-B(config-if)# ip address
Switch-B(config-if)# standby 1 priority 100
Switch-B(config-if)# standby 1 preempt
Switch-B(config-if)# standby 1 ip
Switch-B(config-if)# no shutdown


Load Balancing with HSRP

Consider a network in which HSRP is used on two distribution switches to provide a redundant gateway address for access layer users. Only one of the two becomes the active HSRP router. the other remains in standby. All the users send their traffic to the active router over the uplink to the active router. The standby router and its uplink essentially sit idle until a router failure occurs.

Load balancing traffic across two uplinks to two HSRP switch with a single HSRP group is not possible. Then how is it possible to load balance with HSRP? The trick is to use two HSRP groups:

  • One group assigns an Active router to one switch.
  • The other group assigns another Active router to the other switch


Two different virtual router or gateway addresses can be used simultaneously. The rest of the trick is to make each switch function as the standby router for its partner’s HSRP group. In other words, each router is active for one group and standby for the other group. The clients or end users also must have their default gateway addresses configured as one of the two virtual HSRP group addresses.

Below presents this scenario. Now, Switch A is not only the active router for HSRP Group 1 (, but it is also the standby router for HSRP Group 2 ( Switch B is configured with its roles reversed. The remaining step is to configure half of the client PCs with the HSRP Group 1 virtual router address and the other half with the Group 2 address. This makes load balancing possible and effective. Each half of the hosts uses one switch as its gateway over one uplink.

Two HSRP Groups








Configuring Load Balancing Between HSRP Groups (for the above scenario):

Switch-A(config)# interface vlan 50
Switch-A(config-if)# ip address
Switch-A(config-if)# standby 1 priority 200
Switch-A(config-if)# standby 1 preempt
Switch-A(config-if)# standby 1 ip
Switch-A(config-if)# standby 1 authentication MyKey
Switch-A(config-if)# standby 2 priority 100
Switch-A(config-if)# standby 2 ip
Switch-A(config-if)# standby 2 authentication MyKey
Switch-B(config)# interface vlan 50
Switch-B(config-if)# ip address
Switch-B(config-if)# standby 1 priority 100
Switch-B(config-if)# standby 1 ip
Switch-B(config-if)# standby 1 authentication MyKey
Switch-B(config-if)# standby 2 priority 200
Switch-B(config-if)# standby 2 preempt
Switch-B(config-if)# standby 2 ip
Switch-B(config-if)# standby 2 authentication MyKey


Use the following command syntax to verify information about the status of one or more HSRP groups and interfaces:

Router# show standby [brief] [vlan vlan-id | type mod/num]


Based on the configuration above, the output in below shows that Switch A is the active router for HSRP Group 1 and the standby router for HSRP Group 2 on interface VLAN 50.

Verify the HSRP Router Role of a Switch: Switch A

Switch-A# show standby vlan 50 brief
P indicates configured to preempt.
Interface Grp Prio P State Active addr Standby addr Group addr
Vl50 1 200 P Active local
Vl50 2 100 Standby local
Switch-A# show standby vlan 50
Vlan50 - Group 1

Local state is Active, priority 200, may preempt
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 2.248
 Virtual IP address is configured
Active router is local
Standby router is expires in 9.860
Virtual mac address is 0000.0c07.ac01
Authentication text "MyKey"
2 state changes, last state change 00:11:58
IP redundancy name is "hsrp-Vl50-1" (default)

Vlan50 - Group 2
Local state is Standby, priority 100
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 1.302
Virtual IP address is configured
Active router is, priority 200 expires in 7.812
Standby router is local
Authentication text "MyKey"
4 state changes, last state change 00:10:04
IP redundancy name is "hsrp-Vl50-2" (default)


The output from Switch B below, shows that it has inverted roles from Switch A for HSRP Groups 1 and 2.

Switch-B# show standby vlan 50 brief
P indicates configured to preempt.
Interface Grp Prio P State Active addr Standby addr Group addr
Vl50 1 100 Standby local
Vl50 2 200 P Active local
Switch-B# show standby vlan 50

Vlan50 - Group 1
Local state is Standby, priority 100
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 0.980
Virtual IP address is configured
Active router is, priority 200 expires in 8.128
Standby router is local
Authentication text "MyKey"
1 state changes, last state change 00:01:12
IP redundancy name is "hsrp-Vl50-1" (default)

Vlan50 - Group 2
Local state is Active, priority 200, may preempt
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 2.888
Virtual IP address is configured
Active router is local
Standby router is expires in 8.500
Virtual mac address is 0000.0c07.ac02
Authentication text "MyKey"
1 state changes, last state change 00:01:16


Virtual Router Redundancy Protocol

VRRP is a standards-based alternative to HSRP, defined in IETF standard RFC 2338 (latest revision is RFC5798. VRRP is so similar to HSRP that you need to learn only slightly different terminology and a couple of slight functional differences. When you understand HSRP operation and configuration, you will also understand VRRP. I’m highlighting only the differences between HSRP and VRRP. VRRP provides one redundant gateway address from a group of routers. The active router is called the master router, whereas all others are in the backup state. The master router is the one with the highest router priority in the VRRP group.

VRRP group numbers range from 0 to 255, router priorities range from 1 to 254. (254 is the highest, 100 is the default.) The virtual router MAC address is of the form 0000.5e00.01xx, where xx is a two-digit hex VRRP group number.

VRRP advertisements are sent at 1-second intervals. Backup routers optionally can learn the advertisement interval from the master router. By default, all VRRP routers are configured to preempt the current master router if their priorities are greater.

VRRP sends its advertisements to the multicast destination address (VRRP), using IP protocol 112. VRRP was introduced in Cisco IOS Software Release 12.0(18)ST for routers, but is not supported consistently across all switching platforms.


VRRP Configuration Commands

Assign a VRRP router priority (default 100).

Switch(config-if)# vrrp group priority level


Alter the advertisement timer (default 1 second).

Switch(config-if)# vrrp group timers advertise [msec] interval


Learn the advertisement interval from the master router.

Switch(config-if)# vrrp group timers learn


Disable preempting (default is to preempt).

Switch(config-if)# no vrrp group preempt


Change the preempt delay (default 0 seconds).

Switch(config-if)# vrrp group preempt [delay seconds]


Use authentication for advertisements.

Switch(config-if)# vrrp group authentication string


Assign a virtual IP address.

Switch(config-if)# vrrp group ip ip-address [secondary]


Track an object.

Switch(config-if)# vrrp group track objectnumber [decrement priority]


As an example, the load-balancing scenario shown below is implemented using VRRP. You would use the configuration commands on the two Catalyst switches.

Configuring Load Balancing with VRRP

Switch-A(config)# interface vlan 50
Switch-A(config-if)# ip address
Switch-A(config-if)# vrrp 1 priority 200
Switch-A(config-if)# vrrp 1 ip
Switch-A(config-if)# vrrp 2 priority 100
Switch-A(config-if)# no vrrp 2 preempt
Switch-A(config-if)# vrrp 2 ip
Switch-B(config)# interface vlan 50
Switch-B(config-if)# ip address
Switch-B(config-if)# vrrp 1 priority 100
Switch-B(config-if)# no vrrp 1 preempt
Switch-B(config-if)# vrrp 1 ip
Switch-B(config-if)# vrrp 2 priority 200
Switch-B(config-if)# vrrp 2 ip


Verify information about VRRP status on one or more interfaces:

Switch# show vrrp [brief]


Verify Switch Roles for VRRP Load Balancing

Switch-A# show vrrp brief
Interface Grp Pri Time Own Pre State Master addr Group addr
Vlan50 1 200 3218 Y Master
Vlan50 2 100 3609 Backup

Switch-B# show vrrp brief
Interface Grp Pri Time Own Pre State Master addr Group addr
Vlan50 1 100 3609 Backup
Vlan50 2 200 3218 Y Master


Verifying VRRP Status for multiple VRRP Groups

Switch-A# show vrrp
Vlan50 - Group 1
State is Master
Virtual IP address is
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption is enabled
min delay is 0.000 sec
Priority is 200
Authentication is enabled
Master Router is (local),
priority is 200
Master Advertisement interval is 1.000
Master Down interval is 3.218 sec

Vlan50 - Group 2
State is Backup
Virtual IP address is
Virtual MAC address is 0000.5e00.0102
Advertisement interval is 1.000 sec
Preemption is disabled
Priority is 100
Authentication is enabled
Master Router is, priority
is 200
Master Advertisement interval is 1.000
Master Down interval is 3.609 sec
(expires in 2.977 sec)

Switch-B# show vrrp
Vlan50 - Group 1
State is Backup
Virtual IP address is
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption is disabled
Priority is 100
Authentication is enabled
Master Router is, priority
is 200
Master Advertisement interval is 1.000
Master Down interval is 3.609 sec
(expires in 2.833 sec)

Vlan50 - Group 2
State is Master
Virtual IP address is
Virtual MAC address is 0000.5e00.0102
Advertisement interval is 1.000 sec
Preemption is enabled
min delay is 0.000 sec
Priority is 200
Authentication is enabled
Master Router is (local),
priority is 200
Master Advertisement interval is 1.000
Master Down interval is 3.218 sec


Gateway Load Balancing Protocol

GLBP is a Cisco proprietary protocol designed to overcome the limitations of existing redundant router protocols. Some of the concepts are the same as with HSRP/VRRP, but the terminology is different, and the behavior is much more dynamic and robust.

Note: GLBP was introduced in Cisco IOS Software Release 12.2(14)S for routers, but is not consistently supported across all switching platforms.


To provide a virtual router, multiple switches (routers) are assigned to a common GLBP group. Instead of having just one active router performing forwarding for the virtual router address, all routers in the group can participate and offer load balancing by forwarding a portion of the overall traffic.

The advantage is that none of the clients has to be pointed toward a specific gateway address, they can all have the same default gateway set to the virtual router IP address. The load balancing is provided completely through the use of virtual router MAC addresses in ARP replies returned to the clients.

As a client sends an ARP request looking for the virtual router address, GLBP sends back an ARP reply with the virtual MAC address of a selected router in the group. The result is that all clients use the same gateway address but have differing MAC addresses for it.


Active Virtual Gateway

The trick behind this load balancing lies in the GLBP group. One router is elected the Active Virtual Gateway (AVG). This router has the highest priority value, or the highest IP address in the group, if there is no highest priority. The AVG answers all ARP requests for the virtual router address. Which MAC address it returns depends on which load-balancing algorithm it is configured to use. In any event, the virtual MAC address supported by one of the routers in the group is returned.

The AVG also assigns the necessary virtual MAC addresses to each of the routers participating in the GLBP group. Up to four virtual MAC addresses can be used in any group. Each of these routers is referred to as an Active Virtual Forwarder (AVF), forwarding traffic received on its virtual MAC address. Other routers in the group serve as backup or secondary virtual forwarders, in case the AVF fails. The AVG also assigns secondary roles.


Assign the GLBP priority to a router with the following interface configuration command:

Switch(config-if)# glbp group priority level


Note: GLBP group numbers range from 0 to 1023. The router priority can be 1 to 255 (255 is the highest priority), default 100.


As with HSRP, another router cannot take over an active role until the current active router fails. GLBP does allow a router to preempt and become the AVG if it has a higher priority than the current AVG. Use the following command to enable preempting and to set a time delay before preempting begins:

Switch(config-if)# glbp group preempt [delay minimum seconds]


Routers participating in GLBP must monitor each other’s presence so that another router can assume the role of a failed router. To do this, the AVG sends periodic hello messages to each of the other GLBP peers. In addition, it expects to receive hello messages from each of them. Hello messages are sent at hellotime intervals, with a default of 3 seconds. If hellos are not received from a peer within a holdtime, defaulting to 10 seconds, that peer is presumed to have failed.

Adjust the GLBP timers with the following interface configuration command syntax:

Switch(config-if)# glbp group timers [msec] hellotime [msec] holdtime


hellotime – from 1 to 60 seconds or from 50 to 60,000 milliseconds.

holdtime – must be greater than the hellotime and can go up to 180 seconds or 180,000 milliseconds.

Note: Always make the holdtime at least three times greater than the hellotime to give some tolerance to missed or delayed hellos from a functional peer.

Note:  just configure the timers on the router you have identified as the AVG. The AVG will advertise the timer values it is using, and every other
peer will learn those values if they have not already been explicitly set.


Active Virtual Forwarder

Each router participating in the GLBP group can become an AVF, if the AVG assigns it that role, along with a Virtual MAC Address. The virtual MAC addresses always have the form 0007.b4xx.xxyy. The 16-bit value denoted by xx.xx represents six 0 bits followed by a 10-bit GLBP group number.

The 8-bit yy value is the virtual forwarder number.

GLBP uses the periodic hello messages to detect AVF failures, too. Each router within a GLBP group must send hellos to every other GLBP peer. Hellos also are  expected from every other peer. If hellos from the AVF are not received by the AVG before its Hold-Time timer expires, the AVG assumes that the current AVF has failed. The AVG then assigns the AVF role to another router.
The router that is given the new AVF role might already be an AVF for a different virtual MAC address. Although a router can masquerade as two different virtual MAC addresses to support the two AVF functions, it does not make much sense to continue doing that for a long period of time. The AVG maintains two timers that help resolve this condition.

redirect timer – Determines when the AVG will stop using the old virtual MAC address in ARP replies. The AVF corresponding to the old address continues to act as a gateway for any clients that try to use it.

timeout timer – defaults to 14,400 seconds (4 hours) and can range from 700 to 64,800 seconds (18 hours). When expires, the old MAC address and the virtual forwarder using it are flushed from all the GLBP peers. The AVG assumes that the previously failed AVF will not return to service, so the resources assigned to it must be reclaimed. At this point, clients still using the old MAC address in their ARP caches must refresh the entry to obtain the new virtual MAC address.

redirect timer – defaults to 600 seconds (10 minutes) and can range from 0 to 3600 seconds (1 hour).


You can adjust these timers with the following interface configuration command:

Switch(config-if)# glbp group timers redirect redirect timeout


GLBP Weighting function to determine which router becomes the AVF for a virtual MAC address in a group. Each router begins with a maximum weight value (1 to 254).

As specific interfaces go down, the weight is decreased by a configured amount. GLBP uses thresholds to determine when a router can and cannot be the AVF. If the weight falls below the lower threshold, the router must give up its AVF role. When the weight rises above the upper threshold, the router can resume its AVF role.


A router receives a maximum weight of 100. If you want to make a Dynamic Weighting Adjustment, GLBP must know which interfaces to track and how to adjust the weight. You must first define an interface as a tracked object with the following global command:

Switch(config)# track object-number interface type member/module/number {lineprotocol | ip routing}


object-number – An arbitrary index (1 to 500) that is used for weight adjustment. The condition that triggers an adjustment can be line-protocol (the interface line protocol is up) or ip routing. (IP routing is enabled, the interface has an IP address, and the interface is up.)


Next, you must define the weighting thresholds for the interface with the following interface configuration command:

Switch(config-if)# glbp group weighting maximum [lower lower] [upper upper]


Maximum Weight – 1 to 254 (default 100).

Upper (default Maximum) and Lower (default 1) thresholds – define when the router can and cannot be the AVF, respectively.


Finally, you must configure GLBP to know which objects to track so that the weighting can be adjusted with the following interface configuration command:

Switch(config-if)# glbp group weighting track object-number [decrement value]


When the tracked object fails, the weighting is decremented by value (1 to 254, default 10). Likewise, a router that might serve as an AVF cannot preempt another when it has a higher weight value.


 GLBP Load Balancing

The AVG establishes load balancing by handing out virtual router MAC addresses to clients in a deterministic fashion. The AVG first must inform the AVFs in the group of the virtual MAC address that each should use. Up to four virtual MAC addresses, assigned in sequential order, can be used in a group.

You can use one of the following load-balancing methods in a GLBP group:

  • Round Robin: Each new ARP request for the virtual router address receives the next available virtual MAC address in reply. Traffic load is distributed evenly across all routers participating as AVFs in the group, assuming that each of the clients sends and receives the same amount of traffic. Default method used by GLBP.
  • Weighted: The GLBP group interface’s weighting value determines the proportion of traffic that should be sent to that AVF. A higher weighting results in more frequent ARP replies containing the virtual MAC address of that router. If interface tracking is not configured, the maximum weighting value configured is used to set the relative proportions among AVFs.
  • Host Dependent: Each client that generates an ARP request for the virtual router address always receives the same virtual MAC address in reply. This method is used if the clients have a need for a consistent gateway MAC address. (Otherwise, a client could receive replies with different MAC addresses for the router over time, depending on the load-balancing method in use.)


On the AVG router (or its successors), use the following configuration to define the method:

Switch(config-if)# glbp group load-balancing [round-robin | weighted | host-dependent]


Enabling GLBP

To enable GLBP, you must assign a virtual IP address to the group by using the following interface configuration command:

Switch(config-if)# glbp group ip [ip-address [secondary]]


If the ip-address is not given in the command, it is learned from another router in the group. However, if this router is to be the AVG, you must explicitly configure the IP address; otherwise, no other router knows what the value should be.


GLBP can also be used with IPv6. Use the following command to autoconfigure the address:

Switch(config-if)# glbp group ipv6 autoconfigure


Below shows a typical network in which three multilayer switches are participating in a common GLBP group. Switch A is elected the AVG, so it coordinates the entire GLBP process. The AVG answers all ARP requests for the virtual router It has identified itself, Switch B, and Switch C as AVFs for the group.

Round-Robin Load Balancing is being used. Each of the client PCs sends an ARP request to look for the virtual router address ( in turn, from left to right. Each time the AVG replies, the next sequential virtual MAC address is sent back to a client. After the fourth PC sends a request, all three virtual MAC addresses (and AVF routers) have been used, so the AVG cycles back to the first virtual MAC address.

Only one GLBP group has been configured, and all clients know of only one gateway IP address: However, all uplinks are being used, and all routers are proportionately forwarding traffic.










Redundancy is also inherent in the GLBP group: Switch A is the AVG, but the next-highest priority router can take over if the AVG fails. All routers have been given an AVF role for a unique virtual MAC address in the group. If one AVF fails, some clients remember the last-known virtual MAC address that was handed out. Therefore, another of the routers also takes over the AVF role for the failed router, causing the virtual MAC address to
remain alive at all times.

Below shows how these redundancy features react when the current active AVG fails. Before its failure, Switch A was the AVG because of its higher GLBP priority. After it failed, Switch B became the AVG, answering ARP requests with the appropriate virtual MAC address for gateway Switch A also had been acting as an AVF, participating in the gateway load balancing. Switch B also picks up this responsibility, using its virtual MAC address 0007.b400.0102 along with the one Switch A had been using, 0007.b400.0101. Therefore, any hosts that know the gateway by any of its virtual MAC addresses still can reach a live gateway or AVF.

GLBP Component Failure









Configuring GLBP Load Balancing

Switch-A(config)# interface vlan 50
Switch-A(config-if)# ip address
Switch-A(config-if)# glbp 1 priority 200
Switch-A(config-if)# glbp 1 preempt
Switch-A(config-if)# glbp 1 ip
Switch-B(config)# interface vlan 50
Switch-B(config-if)# ip address
Switch-B(config-if)# glbp 1 priority 150
Switch-B(config-if)# glbp 1 preempt
Switch-B(config-if)# glbp 1 ip
Switch-C(config)# interface vlan 50
Switch-C(config-if)# ip address
Switch-C(config-if)# glbp 1 priority 100
Switch-C(config-if)# glbp 1 ip


You can verify GLBP operation with the show glbp [brief] command, as demonstrated below. With the brief keyword, the GLBP roles are summarized showing the interface, GLBP group number (Grp), Virtual Forwarder Number (Fwd), GLBP Priority (Pri), State, and Addresses.


Verifying GLBP Operation

Switch-A# show glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Vl50 1 - 200 Active local
Vl50 1 1 7 Active 0007.b400.0101 local -
Vl50 1 2 7 Listen 0007.b400.0102 -
Vl50 1 3 7 Listen 0007.b400.0103 -

Switch-B# show glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Vl50 1 - 150 Standby local
Vl50 1 1 7 Listen 0007.b400.0101 -
Vl50 1 2 7 Active 0007.b400.0102 local -
Vl50 1 3 7 Listen 0007.b400.0103 -

Switch-C# show glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Vl50 1 - 100 Listen
Vl50 1 1 7 Listen 0007.b400.0101 -
Vl50 1 2 7 Listen 0007.b400.0102 -
Vl50 1 3 7 Active 0007.b400.0103 local -


Notice that Switch A is shown to be the AVG because it has a dash in the Fwd column and is in the Active state. It also is acting as AVF for virtual forwarder number 1. Because the GLBP group has three routers, there are three virtual forwarders and virtual MAC addresses. Switch A is in the Listen state for forwarders number 2 and 3, waiting to be given an active role in case one of those AVFs fails.

Switch B is shown to have the Standby role, waiting to take over in case the AVG fails. It is the AVF for virtual forwarder number 2.

Finally, Switch C has the lowest GLBP priority, so it stays in the Listen state, waiting for the active or standby AVG to fail. It is also the AVF for virtual forwarder number 3. You also can display more detailed information about the GLBP configuration and status by omitting the brief keyword.

Below shows this output on the AVG router. Because this is the AVG, the virtual forwarder roles it has assigned to each of the routers in the GLBP group also are shown.


Verify Detailed GLBP Configuration and Status Information

Switch-A# show glbp
Vlan50 - Group 1
State is Active
7 state changes, last state change 03:28:05
Virtual IP address is
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.672 secs
Redirect time 600 sec, forwarder time-out 14400 sec
Preemption enabled, min delay 0 sec
Active is local
Standby is, priority 150 (expires in 9.632 sec)
Priority 200 (configured)
Weighting 100 (default 100), thresholds: lower 1, upper 100
Load balancing: round-robin
There are 3 forwarders (1 active)
Forwarder 1
State is Active
3 state changes, last state change 03:27:37
MAC address is 0007.b400.0101 (default)
Owner ID is 00d0.0229.b80a
Redirection enabled
Preemption enabled, min delay 30 sec
Active is local, weighting 100
Forwarder 2
State is Listen
 MAC address is 0007.b400.0102 (learnt)
Owner ID is 0007.b372.dc4a
Redirection enabled, 598.308 sec remaining (maximum 600 sec)
Time to live: 14398.308 sec (maximum 14400 sec)
Preemption enabled, min delay 30 sec
Active is (primary), weighting 100 (expires in 8.308 sec)
Forwarder 3
State is Listen
MAC address is 0007.b400.0103 (learnt)
Owner ID is 00d0.ff8a.2c0a
Redirection enabled, 599.892 sec remaining (maximum 600 sec)
Time to live: 14399.892 sec (maximum 14400 sec)
Preemption enabled, min delay 30 sec
Active is (primary), weighting 100 (expires in 9.892 sec)


Verifying Gateway Redundancy (HSRP & GLBP)

Display HSRP status.

Switch# show standby brief


Display HSRP on an interface.

Switch# show standby type member/module/number


Display VRRP status.

Switch# show vrrp brief all


Display VRRP on an interface.

Switch# show vrrp interface type member/module/number


Display status of a GLBP group.

Switch# show glbp [group] [brief]



Hope this helps someone else!

CCNP SWITCH 300-115 – Part 2.2 Security With Cisco IOS AAA TACACS+ & RADIUS

Authentication Authorization and Accounting

You can manage user activity to and through a switch with authentication, authorization, and accounting (AAA) features. AAA uses standardized methods to challenge users for their credentials before access is allowed or authorized. Accounting protocols also can record user activity on a switch.

Simply put, think of AAA in the following manner:

  • Authentication: Who is the user?
  • Authorization: What is the user allowed to do?
  • Accounting: What did the user do?



You have several methods to manage users who might try to log in to one of your switches to perform some operation. At the most basic level, you could avoid any authentication other than simple passwords configured on the switch console/vty lines. Authorization can be equally simple: When users successfully log in, they are authorized for EXEC level privileges. By entering the correct enable secret password, users can be authorized for a higher privilege level.

Under the simple scenario, if a user knows the correct password, he can connect to the switch. But who is that user? You might never know who actually logged in and changed the configuration or rebooted the switch! Instead, you could use the username command to configure individual usernames and passwords on the switch. That would solve the user anonymity problem, but your network might consist of many administrative users
and many switches, requiring quite a bit of username configuration and maintenance.

A more scalable solution is to leverage AAA functions that are centralized, standardized, resilient, and flexible. A centralized authentication server can contain a database of all possible users and their passwords, as well as policies to authorize user activities. As users come and go, their accounts can be easily updated in one place. All switches and routers query the AAA server to get up-to-date information about a user.


Cisco switches can use the following two protocols to communicate with AAA servers:

  • TACACS+: A Cisco proprietary protocol that separates each of the AAA functions, communication is secure and encrypted over TCP port 49.
  • RADIUS: A standards-based protocol that combines authentication and authorization into a single resource; communication uses UDP ports 1812 and 1813 (accounting), but is not completely encrypted.


Both TACACS+ and RADIUS are arranged as a client/server setup, where a switch acts as a client talking to a AAA server. Below shows a simplified view of the process. In the AAA client role, a switch is often called a Network Access Device (NAD) or Network Access Server (NAS). When a user tries to connect to a switch, the switch challenges the user for credentials, then passes the credentials along to the AAA server. In simple terms, if the user passes authentication, the AAA server returns an “accept” message to the switch. Otherwise, a “reject” message is returned.

Simple AAA View





Note: Cisco implements AAA services in its Identity Services Engine (ISE) and Cisco Secure Access Control Server (ACS).


Configuring Authentication

Switch access can be granted only after a user’s identity has been validated. User authentication is commonly used on switches and routers to permit remote access to the network administration staff only. In this case, when someone uses Telnet or SSH to log in to a switch, that individual is challenged to provide a username and password. The individual’s credentials are then submitted to a device that can grant the user access.


TACACS+, administered through the AAA security services, can provide these services:

Authentication—Provides complete control of authentication through login and password dialog, challenge and response, and messaging support.

The authentication facility can conduct a dialog with the user (for example, after a username and password are provided, to challenge a user with several questions, such as home address, mother’s maiden name, service type, and social security number). The TACACS+ authentication service can also send messages to user screens. For example, a message could notify users that their passwords must be changed because of the company’s password aging policy.

Authorization—Provides fine-grained control over user capabilities for the duration of the user’s session, including but not limited to setting autocommands, access control, session duration, or protocol support. You can also enforce restrictions on what commands a user can execute with the TACACS+ authorization feature.

Accounting—Collects and sends information used for billing, auditing, and reporting to the TACACS+ daemon. Network managers can use the accounting facility to track user activity for a security audit or to provide information for user billing. Accounting records include user identities, start and stop times, executed commands (such as PPP), number of packets, and number of bytes.

The TACACS+ protocol provides authentication between the switch and the TACACS+ daemon, and it ensures confidentiality because all protocol exchanges between the switch and the TACACS+ daemon are encrypted.

You need a system running the TACACS+ daemon software to use TACACS+ on your switch.


User authentication can be handled by several methods:

-Usernames and passwords configured locally on the switch
-One or more external Remote Authentication Dial-In User Service (RADIUS) servers
-One or more external Terminal Access Controller Access Control System + (TACACS+) servers


Any combination of these methods can be used. In fact, authentication must be defined by grouping the desired methods into a method list. The list contains the types or protocols that will be used, in the sequential order that they will be tried.


To use authentication on a Catalyst switch, you must configure several things in the following order:

1. Enable AAA on the switch. All user authentication is handled locally by configuring usernames and passwords on the switch itself:

Switch(config)# aaa new-model

The new-model refers to the use of method lists, by which authentication methods and sources can be grouped or organized. The new model is much  more scalable than the “old model,” in which the authentication source was explicitly configured.


2. Define the source of authentication. You can compare user credentials against locally configured usernames and passwords, or against a database managed by external RADIUS or TACACS+ servers. Use locally configured usernames and passwords as a last resort, when no other authentication servers are reachable or in use on the network.

Switch(config)# username username password password


RADIUS or TACACS+ servers are defined in groups. First, define each server along with its secret shared password. This string is known only to the switch and the server, and provides a key for encrypting the authentication session. Use one of the following global configuration commands:

Switch(config)# radius-server host {hostname | ip-address} [key string]
Switch(config)# tacacs-server host {hostname | ip-address} [key string]


Define a group name that will contain a list of servers, using the following global configuration command:

Switch(config)# aaa group server {radius | tacacs+} group-name


Define each server of the group type with the following server-group configuration command:

Switch(config-sg)# server ip-address

You can define multiple RADIUS or TACACS+ servers by repeating the commands in this step.


3. Define a list of authentication methods to try. You can list switch login authentication methods by giving the method a descriptive name or using the unnamed “default” method. List each method or protocol type in the order that it should be tried. If none of the servers for the first method responds, the switch will try the servers in the next method listed.

Define a method list:

Switch(config)# aaa authentication login {default | list-namemethod1 [method2 ...]


Here the methods refer to the following keywords:

  • tacacs+: Each of the TACACS+ servers configured on the switch is tried, in the order that it was configured.
  • radius: Each of the RADIUS servers configured on the switch is tried, in the order that it was configured.
  • local: The user’s credentials are compared against all the username commands configured on the local switch.
  • line: The line passwords authenticate any connected user. No usernames can be used.


Note:  Add the local or line methods at the end of the list, as a last resort. This way, if all the RADIUS or TACACS+ servers are unavailable or the switch is completely isolated from the rest of the network, a locally configured authentication method will eventually be used. Otherwise, you will never be able to access the switch until at least one of the servers comes back online.


4. Apply a method list to a switch line.

First, select a line (console or vty for Telnet/SSH access) using the line line command. Then trigger the user authentication on that line to use an AAA
method list:

Switch(config-line)# login authentication {default | list-name}

You can use the default method list only if one list is sufficient for all circumstances on the switch. Otherwise, if you have configured named method lists, you can reference one of them here.


5. After authentication is configured on a switch, stay logged in on one session so that the authentication can be tested. If you exit the configuration session, you will not be able to log in again if the authentication is misconfigured. While you stay logged in on the original session, bring up a new Telnet session to the switch. If you can authenticate successfully, everything is configured properly.

Below example lists the commands necessary to configure a switch to use two TACACS+ servers to authenticate management users. The servers are and, also known as the AAA group named myauthservers.

AAA authentication group myauth is configured to try the TACACS+ server group. If none of the servers is available, local authentication will be used instead. Notice that a username lastresort is configured for that case. Finally, the myauth method is used to authenticate users on lines vty 0 through 15 for Telnet or SSH access.

Switch(config)# aaa new-model
Switch(config)# username lastresort password MySecretP@ssw0rd
Switch(config)# tacacs-server host key t@c@csk3y
Switch(config)# tacacs-server host key t@c@csk3y
Switch(config)# aaa group server tacacs+ myauthservers
Switch(config-sg)# server
Switch(config-sg)# server
Switch(config-sg)# exit
Switch(config)# aaa authentication login myauth group myauthservers local
Switch(config)# line vty 0 15
Switch(config-line)# login authentication myauth


Configuring Authorization

After a user is authenticated, the switch allows access to certain services or switch commands based on the user’s privilege level. Authenticated users are put at the EXEC level by default. Certain commands, such as show interface, are available at the EXEC level. Other commands, such as configure terminal, are accessible only if the user is able to move into the privileged EXEC or enable mode.

Authorization provides a means of granting specific users the ability to perform certain tasks. As with authentication, authorization is performed by querying external RADIUS or TACACS+ servers. If the authorization server has an entry for a user and a service or command, the switch allows the user to perform that task.

Configure authorization by first defining any RADIUS or TACACS+ servers that will be used. These normally are defined as part of the authentication configuration and do not need to be redefined for authorization.

Next, define a method list of authorization methods that will be tried in sequence using the following global configuration command:

Switch(config)# aaa authorization {commands | config-commands | configuration | exec | network | reverse-access} {default | list-name} method1 [method2 ...]


Here you specify the function or service needing authorization with one of the following keywords:

  • commands: The server must return permission to use any switch command at any privilege level.
  • config-commands: The server must return permission to use any switch configuration command
  • configuration: The server must return permission to enter the switch configuration mode.
  • exec: The server must return permission for the user to run a switch EXEC session. The server also can return the privilege level for the user so that the user immediately can be put into privileged EXEC (enable) mode without having to type in the enable command.
  • network: The server must return permission to use network-related services.
  • reverse-access: The server must return permission for the user to access a reverse Telnet session on the switch.


You can identify the method with a descriptive name (list-name) if you are configuring more than one list. Otherwise, a single unnamed list is called the default list. Each authorization method then is listed in the order it will be tried. The methods can be any of the following values:

  • group group-name: Requests are sent to the servers in a specific group.
  • group {radius | tacacs+}: Requests are sent to all servers of this type.
  • if-authenticated: Requests are granted if the user already is authenticated.
  • none: No external authorization is used; every user is authorized successfully.


Note: Only TACACS+ servers can authorize users with permission to use specific commands. RADIUS servers offer more of an all-or-nothing approach.


Next, you can apply an authorization method list to a specific line on the switch. Users accessing the switch through that line will be subject to authorization. Use the following line configuration command syntax:

Switch(config-line)# authorization {commands level | exec | reverse-access} {default | list-name}


If you do not use this command, the default group is used for all lines. To configure a switch to use AAA authorization for all lines, you enter the following:

Switch(config)# aaa authorization exec default group myauthservers none


The AAA servers contained in the group myauthservers are used as a default method to allow authenticated users into the EXEC mode or any other privilege level granted.


Verify TACACS+ Configuration

To verify TACACS+ statistics, use:

Switch# show tacacs


Configuring Accounting

The AAA accounting feature tracks the services that users are accessing and the amount of network resources that they are consuming. When AAA accounting is enabled, the switch reports user activity to the TACACS+ security server in the form of accounting records. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the security server. This data can then be analyzed for network management, client billing, or auditing.

This accounting information can be collected by RADIUS and  TACACS+ servers. Again, the RADIUS and TACACS+ servers must already be configured and grouped as part of the authentication configuration.

As usual, you must define a method list giving a sequence of accounting methods by using the following global configuration command syntax:

Switch(config)# aaa accounting {system | exec | commands level} {default | list-name} {start-stop | stop-only | wait-start | none} method1 [method2...]


The function triggering the accounting can be one of the following keywords:

  • system: Major switch events such as a reload are recorded.
  • exec: User authentication into an EXEC session is recorded, along with information about the user’s address and the time and duration of the session.
  • commands level: Information about any command running at a specific privilege level is recorded, along with the user who issued the command. You can specify that certain types of accounting records be sent to the accounting server using the following keywords:
    start-stop: Events are recorded when they start and stop.
    stop-only: Events are recorded only when they stop.
    none: No events are recorded.


Next, you can apply an accounting method list to a specific line on the switch. Users accessing the switch through that line will have their activity recorded. Use the following line-configuration command to accomplish this:

Switch(config-line)# accounting {commands level | connection | exec} {default | list-name}


If you do not use this command, the default group will be used for all lines. Below, AAA accounting is configured for all lines on the switch, using the AAA servers contained in the myauthservers group (in previous example). User EXEC sessions will be recorded as they start and stop, along with user information. Any commands that are entered while a user is in privilege level 15 (enable mode) will be recorded, too.

Switch(config)# aaa accounting exec default start-stop group myauthservers
Switch(config)# aaa accounting commands 15 default start-stop group myauthservers


Local privilege authorization fallback

The following examples show how to use a TACACS+ server to authorize the use of network services, including PPP and ARA. If the TACACS+ server is not available or an error occurs during the authorization process, the fallback method (none) is to grant all authorization requests:

Switch# aaa authorization network default group tacacs+ none



Hope this helps someone else!

CCNP SWITCH 300-115 – Part 2.0 – Infrastructure Security


Malicious users can send spoofed information to trick switches or other hosts into using a rogue machine as a gateway. The attacker’s goal is to become the Man-In-The-Middle, with a naive user sending packets to the attacker as if it were a router. The attacker can glean information from the packets sent to it before it forwards them normally. In this post I’ll describe three Cisco Catalyst features—DHCP Snooping, IP Source Guard, and Dynamic ARP Inspection—that prevent certain types of spoofing attacks.


DHCP Server

The DHCP server assigns IP addresses from specified address pools on a switch or router to DHCP clients and manages them. If the DHCP server cannot give the DHCP client the requested configuration parameters from its database, it forwards the request to one or more secondary DHCP servers defined by the network administrator.


DHCP Relay Agent

A DHCP relay agent is a Layer 3 device that forwards DHCP packets between clients and servers. Relay agents forward requests and replies between clients and servers when they are not on the same physical subnet. Relay agent forwarding is different from the normal Layer 2 forwarding, in which IP datagrams are switched transparently between networks. Relay agents receive DHCP messages and generate new DHCP messages to send on output interfaces.


DHCP Snooping

DHCP snooping is a DHCP security feature that provides network security by filtering untrusted DHCP messages and by building and maintaining a DHCP snooping binding database, also referred to as a DHCP snooping binding table.

DHCP snooping acts like a firewall between untrusted hosts and DHCP servers. You use DHCP snooping to differentiate between untrusted interfaces connected to the end user and trusted interfaces connected to the DHCP server or another switch.


DHCP Information Option (Option 82) 

Commonly used in metro or large enterprise deployments to provide additional information on “physical attachment” of the client. Option 82 is supposed to be used in distributed DHCP server/relay environment, where relays insert additional information to identify the client’s point of attachment.

Note: The DHCP option-82 feature is supported only when DHCP snooping is globally enabled and on the VLANs to which subscriber devices using this feature are assigned.

DHCP relay is supposed to insert the “giaddr” field in the relayed DHCP packets, so that DHCP server may identify the pool to be used for the request. The choice of the pool is made based on the “giaddr” field or the incoming interface, if the “giaddr” is missing or zero. Option 82 serves as refinement to the request, allowing the DHCP server to select a “sub-range” in the pool. (Notice that by default Cisco IOS devices reject packets with zero “giaddr” and by default Cisco Catalyst switches use “giaddr” of zero when configured for DHCP snooping!)


DHCP Snooping

A DHCP server normally provides all the basic information a client PC needs to operate on a network. The client might receive an IP address, a subnet mask, a default gateway address, DNS addresses, Default gateway, and so on.

Suppose that an attacker could bring up a rogue DHCP server on a machine in the same subnet as that same client PC. Now when the client broadcasts its DHCP request, the rogue server could send a carefully crafted DHCP reply with its own IP address substituted as the default gateway (man in the middle attack).

When the client receives the reply, it begins using the spoofed gateway address. Packets destined for addresses outside the local subnet then go to the attacker’s machine first. The attacker can forward the packets to the correct destination, but in the meantime, it can examine every packet that it intercepts. In effect, this becomes a type of man-in-the-middle attack, the attacker is wedged into the path and the client does not realize it (its transparent for clients).

Cisco switches can use the DHCP Snooping feature to help mitigate this type of attack. When DHCP Snooping is enabled, switch ports are categorized as trusted or untrusted. Legitimate DHCP servers can be found on trusted ports, whereas all other hosts sit behind untrusted ports.

A switch intercepts all DHCP requests coming from untrusted ports before flooding them throughout the VLAN. Any DHCP replies coming from an untrusted port are discarded because they must have come from a rogue DHCP server. In addition, the offending switch port automatically is shut down in the errdisable state.


DHCP Snooping Binding Database

DHCP snooping also keeps track of the completed DHCP bindings as clients receive legitimate replies. This database contains the client MAC address, IP address offered, lease time, and so on.

When DHCP snooping is enabled, the switch uses the DHCP snooping binding database to store information about untrusted interfaces. The database can have up to 8192 bindings.

Configure DHCP snooping first by enabling it globally on a switch with the following configuration command:

Switch(config)# ip dhcp snooping


Identify the VLANs where DHCP snooping should be implemented with the following command:

Switch(config)# ip dhcp snooping vlan 10,20

Note:  You can give a single VLAN number as vlan-id or a range of VLAN numbers by giving the start and end VLAN IDs of the range.


By default, all switch ports are assumed to be untrusted so that DHCP replies are not expected or permitted. Only trusted ports are allowed to send DHCP replies. You should identify only the ports where known, trusted DHCP servers are located. You can do this with the following interface command:

Switch(config)# interface gi0/0/1
Switch(config-if)# ip dhcp snooping trust


For untrusted ports, an unlimited rate of DHCP requests is accepted. If you want to ratelimit DHCP traffic on an untrusted port, use the following interface command:

Switch(config)# interface gi0/0/10
Switch(config-if)# ip dhcp snooping limit rate 20


The rate can be 1 to 2048 DHCP packets per second. You also can configure the switch to use DHCP option-82, the DHCP Relay Agent
Information option, which is described in RFCs 3046 and 6607. When a DHCP request is intercepted on an untrusted port, the switch adds its own MAC address and the switch port identifier into the option-82 field of the request. The request then is forwarded normally so that it can reach a trusted DHCP server.

Adding option-82 provides more information about the actual client that generated the DHCP request. In addition, the DHCP reply (if any) echoes back the option-82 information. The switch intercepts the reply and compares the option-82 data to confirm that the request came from a valid port on itself. This feature is enabled by default. You can enable or disable option-82 globally with the following configuration command:

Switch(config)# [no] ip dhcp snooping information option


Display its status with the following command:

Switch# show ip dhcp snooping [binding]


Note: You can use the binding keyword to display all the known DHCP bindings that have been overheard. The switch maintains these in its own database. Otherwise, only the switch ports that are trusted or that have rate limiting applied are listed. All other ports are considered to be untrusted with an unlimited DHCP request rate.


Example, interfaces Gigabit Ethernet 1/0/35 and 1/0/36 use access VLAN 104, are considered untrusted, and have DHCP rate limiting applied at three per second. A known  DHCP server is located on the Gigabit Ethernet 1/1/1 uplink. Bellow shows the configuration for this scenario.

Switch(config)# ip dhcp snooping
Switch(config)# ip dhcp snooping vlan 104
Switch(config)# interface range gigabitethernet 1/0/35 – 36
Switch(config-if)# ip dhcp snooping limit rate 3
Switch(config-if)# interface gigabitethernet 1/1/1
Switch(config-if)# ip dhcp snooping trust


Display DHCP Snooping Status

Switch# show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
Insertion of option 82 is enabled
Interface Trusted Rate limit (pps)
------------------------ ------- ----------------
GigabitEthernet1/0/35 no 3
GigabitEthernet1/0/36 no 3
GigabitEthernet1/1/1 yes unlimited


Displays the DHCP snooping configuration for a switch

Switch# show ip dhcp snooping

Displays only the dynamically configured bindings in the DHCP snooping binding database, also referred to as a binding table.

Switch# show ip dhcp snooping binding


Displays the DHCP snooping binding database status and statistics.

Switch# show ip dhcp snooping database


Displays the DHCP snooping statistics in summary or detail form.

Switch# show ip dhcp snooping statistics


Display the dynamically and statically configured bindings.

Switch# show ip source binding


IP Source Guard

Address spoofing is one type of attack that can be difficult to mitigate. Normally, a host is assigned an IP address and is expected to use that address in all the traffic it sends out. IP addresses are effectively used on the honor system, where hosts are trusted to behave themselves and use their own legitimate source addresses.

A compromised PC does not necessarily play by those rules. It can use its legitimate address, or it can begin to use spoofed addresses—borrowed from other hosts or used at random. Spoofed addresses are often used to disguise the origin of DoS attacks. If the source address does not really exist, no return traffic will find its way back to the originator.

Routers or Layer 3 devices can perform some simple tests to detect spoofed source addresses in packets passing through. For example, if the network is known to exist on VLAN 10, packets entering from VLAN 20 should never have source addresses in that subnet.

It’s difficult to detect spoofed addresses when they are used inside the VLAN or subnet where they should already exist. For example, within the network on  VLAN 10, as shown bellow, a rogue host begins to send packets with a spoofed source address of The address is certainly within the subnet, so it does not stand out as an obvious spoof. Therefore, the rogue host might be very successful in attacking other hosts in its own subnet or VLAN.

Cisco switches can use the IP Source Guard feature to detect and suppress address spoofing attacks, even if they occur within the same subnet. A Layer 2 switch, and a Layer 2 port in turn, normally learns and stores MAC addresses. The switch must have a way to look up MAC addresses and find out what IP address are associated with them.

Spoofed Source Address






IP Source Guard does this by making use of the DHCP snooping database and static IP source binding entries. If DHCP snooping is configured and enabled, the switch learns the MAC and IP addresses of hosts that use DHCP.

Packets arriving on a switch port can be tested for one of the following conditions:

  • The source IP address must be identical to the IP address learned by DHCP snooping or a static entry. A dynamic port access control list (ACL) is used to filter traffic. The switch automatically creates this ACL, adds the learned source IP address to the ACL, and applies the ACL to the interface where the address is learned.
  • The source MAC address must be identical to the MAC address learned on the switch port and by DHCP snooping. Port security is used to filter traffic.



If the address is something other than the one learned or statically configured, the switch drops the packet. To configure IP Source Guard, first configure and enable DHCP snooping. If you want IP Source Guard to detect spoofed MAC addresses, you also need to configure and enable port security.

For the hosts that do not use DHCP, you can configure a static IP source binding with the following command:

Switch(config)# ip source binding mac-address vlan 10 ip-address interface gi0/0/10

Here, the host’s MAC address is bound to a specific VLAN and IP address, and is expected to be found on a specific switch interface.

Next, enable IP source guard on one or more switch interfaces with the following commands:

Switch(config)# interface gi0/0/5
Switch(config-if)# ip verify source [port-security]


To summ it up, IP source guard is a security feature that restricts IP traffic on nonrouted, Layer 2 interfaces by filtering traffic based on the DHCP snooping binding database and on manually configured IP source bindings. You can use IP source guard to prevent traffic attacks caused when a host tries to use the IP address of its neighbor.

You can enable IP source guard when DHCP snooping is enabled on an untrusted interface. After IP source guard is enabled on an interface, the switch blocks all IP traffic received on the interface, except for DHCP packets allowed by DHCP snooping. A port access control list (ACL) is applied to the interface. The port ACL allows only IP traffic with a source IP address in the IP source binding table and denies all other traffic.

Note: As with all port ACLs, this port ACL takes precedence over any router ACLs or VLAN maps that affect the same interface.

The IP source binding table has bindings that are learned by DHCP snooping or are manually configured (static IP source bindings). An entry in this table has an IP address, its associated MAC address, and its associated VLAN number. The switch uses the IP source binding table only when IP source guard is enabled.

IP source guard is supported only on Layer 2 ports, including access and trunk ports. You can configure IP source guard with source IP address filtering or with source IP and MAC address filtering.


Source IP Address Filtering

When IP source guard is enabled with this option, IP traffic is filtered based on the source IP address. The switch forwards IP traffic when the source IP address matches an entry in the DHCP snooping binding database or a binding in the IP source binding table.

When a DHCP snooping binding or static IP source binding is added, changed, or deleted on an interface, the switch modifies the port ACL using the IP source binding changes, and re-applies the port ACL to the interface.

If you enable IP source guard on an interface on which IP source bindings (dynamically learned by DHCP snooping or manually configured) are not configured, the switch creates and applies a port ACL that denies all IP traffic on the interface. If you disable IP source guard, the switch removes the port ACL from the interface.


Source IP and MAC Address Filtering

When IP source guard is enabled with this option, IP traffic is filtered based on the source IP and MAC addresses. The switch forwards traffic only when the source IP and MAC addresses match an entry in the IP source binding table.

When IP source guard with source IP and MAC address filtering is enabled, the switch filters IP and non-IP traffic. If the source MAC address of an IP or non-IP packet matches a valid IP source binding, the switch forwards the packet. The switch drops all other types of packets except DHCP packets.

The switch uses port security to filter source MAC addresses. The interface can shut down when a port-security violation occurs.


Configure IP Source Guard

Enable IP source guard with source IP and MAC filtering on VLANs 10  and 11:

Switch# config t
Switch(config)# interface gigabitethernet1/0/1
Switch(config-if)# ip verify source port-security
Switch(config-if)# exit
Switch(config)# ip source binding 0100.0022.0010 vlan 10 interface gigabitethernet1/0/1
Switch(config)# ip source binding 0100.0230.0002 vlan 11 interface  gigabitethernet1/0/1
Switch(config)# end

Note: The ip verify source command inspects the source IP address only. You can add the port-security keyword to inspect the source MAC address, too. Remember, port-security must be enabled.


Verification Commands

Display the IP source bindings on a switch.

Switch# show ip source binding

Display the IP source guard configuration on the switch.

Switch# show ip verify source
Switch# show ip verify source gi0/0/10



Dynamic ARP Inspection

Hosts normally use the Address Resolution Protocol (ARP) to resolve an unknown MAC address when the IP address is known. If a MAC address is needed so that a packet can be forwarded at Layer 2, a host broadcasts an ARP request that contains the IP address of the target in question. If any other host is using that IP address, it responds with an ARP reply containing its MAC address.

The ARP process works well among trusted and well-behaved users. However, suppose that an attacker could send its own crafted ARP reply when it overhears an ARP request being broadcast. The reply could contain its own MAC address, causing the original requester to think that it is bound to the IP address in question. The requester would add the bogus ARP entry into its own ARP cache, only to begin forwarding packets to the spoofed MAC address.

In effect, this scheme places the attacker’s machine right in the middle of an otherwise legitimate path. Packets will be sent to the attacker instead of another host or the default gateway. The attacker can intercept packets and (perhaps) forward them on only after examining the packets’ contents.

This attack is known as ARP poisoning or ARP spoofing, and it is considered to be a type of man-in-the-middle attack. The attacker wedges into the normal forwarding path, transparent to the end users. Cisco switches can use the dynamic ARP inspection (DAI) feature to help mitigate this type of attack. DAI works much like DHCP snooping. All switch ports are classified as trusted or untrusted. The switch intercepts and inspects all ARP packets that arrive on an untrusted port, no inspection is done on trusted ports.


Interface Trust States and Network Security

Dynamic ARP inspection associates a trust state with each interface on the switch. Packets arriving on trusted interfaces bypass all dynamic ARP inspection validation checks, and those arriving on untrusted interfaces undergo the dynamic ARP inspection validation process.

In a typical network configuration, you configure all switch ports connected to host ports as untrusted and configure all switch ports connected to switches as trusted. With this configuration, all ARP packets entering the network from a given switch bypass the security check. No other validation is needed at any other place in the VLAN or in the network. You configure the trust setting by using the ip arp inspection trust interface command.

Note: Use the trust state configuration carefully. Configuring interfaces as untrusted when they should be trusted can result in a loss of connectivity.


Rate Limiting of ARP Packets

The switch CPU performs dynamic ARP inspection validation checks; therefore, the number of incoming ARP packets is rate-limited to prevent a denial-of-service attack. By default, the rate for untrusted interfaces is 15 packets per second (pps). Trusted interfaces are not rate-limited. You can change this setting by using the ip arp inspection limit interface command.

When the rate of incoming ARP packets exceeds the configured limit, the switch places the port in the error-disabled state. The port remains in that state until you intervene. You can use the errdisable recovery global command to enable error disable recovery so that ports automatically emerge from this state after a specified timeout period.


Relative Priority of ARP ACLs and DHCP Snooping Entries

Dynamic ARP inspection uses the DHCP snooping binding database for the list of valid IP-to-MAC address bindings.

ARP ACLs take precedence over entries in the DHCP snooping binding database. The switch uses ACLs only if you configure them by using the ip arp inspection filter vlan global command. The switch first compares ARP packets to user-configured ARP ACLs. If the ARP ACL denies the ARP packet, the switch also denies the packet even if a valid binding exists in the database populated by DHCP snooping.


Logging of Dropped Packets

When the switch drops a packet, it places an entry in the log buffer and then generates system messages on a rate-controlled basis. After the message is generated, the switch clears the entry from the log buffer. Each log entry contains flow information, such as the receiving VLAN, the port number, the source and destination IP addresses, and the source and destination MAC addresses.

You use the ip arp inspection log-buffer global command to configure the number of entries in the buffer and the number of entries needed in the specified interval to generate system messages. You specify the type of packets that are logged by using the ip arp inspection vlan logging global command.


Dynamic ARP Inspection Configuration Guidelines

These are the dynamic ARP inspection configuration guidelines:

  • Dynamic ARP inspection is an ingress security feature; it does not perform any egress checking.
  • Dynamic ARP inspection is not effective for hosts connected to switches that do not support dynamic ARP inspection or that do not have this feature enabled. Because man-in-the-middle attacks are limited to a single Layer 2 broadcast domain, separate the domain with dynamic ARP inspection checks from the one with no checking. This action secures the ARP caches of hosts in the domain enabled for dynamic ARP inspection.
  • Dynamic ARP inspection depends on the entries in the DHCP snooping binding database to verify IP-to-MAC address bindings in incoming ARP requests and ARP responses. Make sure to enable DHCP snooping to permit ARP packets that have dynamically assigned IP addresses.
  • When DHCP snooping is disabled or in non-DHCP environments, use ARP ACLs to permit or to deny packets.
  • Dynamic ARP inspection is supported on access ports, trunk ports, EtherChannel ports, and private VLAN ports.


When an ARP reply is received on an untrusted port, the switch checks the MAC and IP addresses reported in the reply packet against known and trusted values. A switch can gather trusted ARP information from statically configured entries or from dynamic entries in the DHCP snooping database. In the latter case, DHCP snooping must be enabled in addition to DAI.

If an ARP reply contains invalid information or values that conflict with entries in the trusted database, it is dropped and a log message is generated. This action prevents invalid or spoofed ARP entries from being sent and added to other machines’ ARP caches.

You can configure DAI by first enabling it on one or more client VLANs with the following command:

Switch(config)# ip arp inspection vlan vlan-range

The VLAN range can be a single VLAN ID, a range of VLAN IDs separated by a hyphen, or a list of VLAN IDs separated by commas.

By default, all switch ports associated with the VLAN range are considered to be untrusted. You should identify trusted ports as those that connect to other switches. In other words, the local switch will not inspect ARP packets arriving on trusted ports, it will assume that the neighboring switch also is performing DAI on all of its ports in that VLAN. Configure a trusted port with the following interface command:

Switch(config)# interface type member/module/number
Switch(config-if)# ip arp inspection trust


If you have hosts with statically configured IP address information, there will be no DHCP message exchange that can be inspected. Instead, you can configure an ARP access list that defines static MAC-IP address bindings that are permitted. Use the following commands to define the ARP access list and one or more static entries:

Switch(config)# arp access-list acl-name
Switch(config-acl)# permit ip host sender-ip mac host sender-mac [log] [Repeat the previous command as needed]
Switch(config-acl)# exit


Now the ARP access list must be applied to DAI with the following command:

Switch(config)# ip arp inspection filter arp-acl-name vlan vlan-range [static]


When ARP replies are intercepted, their contents are matched against the access list entries first. If no match is found, the DHCP snooping bindings database is checked next. You can give the static keyword to prevent the DHCP bindings database from being checked at all. In effect, this creates an implicit deny statement at the end of the ARP access list, if no match is found in the access list, the ARP reply is considered invalid.

Finally, you can specify further validations on the contents of ARP reply packets. By default, only the MAC and IP addresses contained within the ARP reply are validated. This does not take the actual MAC addresses contained in the Ethernet header of the ARP reply.

To validate that an ARP reply packet is really coming from the address listed inside it, you can enable DAI validation with the following command:

Switch(config)# ip arp inspection validate {[src-mac] [dst-mac] [ip]}


Be sure to specify at least one of the options:

  • src-mac: Check the source MAC address in the Ethernet header against the sender MAC address in the ARP reply.
  • dst-mac: Check the destination MAC address in the Ethernet header against the target MAC address in the ARP reply.
  • IP: Check the sender’s IP address in all ARP requests; check the sender’s IP address against the target IP address in all ARP replies.


Below demonstrates where DAI is enabled for all switch ports associated with VLAN 104 on an access layer switch. The uplink to a distribution switch (Gigabit Ethernet 1/0/49) is considered to be trusted.

Configuring DAI to Validate ARP Replies

Switch(config)# ip arp inspection vlan 104
Switch(config)# arp access-list StaticARP
Switch(config-acl)# permit ip host mac host 0006.5b02.a841
Switch(config-acl)# exit
Switch(config)# ip arp inspection filter StaticARP vlan 104
Switch(config)# interface gigabitethernet 1/0/49
Switch(config-if)# ip arp inspection trust


Verify Dynamic Arp Inspection

Verify detailed information about ARP ACLs.

Switch# show arp access-list[acl-name]


Verify the trust state and the rate limit of ARP packets for the specified interface or all interfaces.

Switch# show ip arp inspection interfaces [interface-id]


Verify the configuration and the operating state of dynamic ARP inspection for the specified VLAN. If no VLANs are specified or if a range is specified, displays information only for VLANs with dynamic ARP inspection enabled (active).

Switch# show ip arp inspection vlan vlan-range


Clears dynamic ARP inspection statistics.

Switch# clear ip arp inspection statistics


Displays statistics for forwarded, dropped, MAC validation failure, IP validation failure, ACL permitted and denied, and DHCP permitted and denied packets for the specified VLAN. If no VLANs are specified or if a range is specified, displays information only for VLANs with dynamic ARP inspection enabled (active).

Switch# show ip arp inspection statistics [vlanvlan-range]


Clears the dynamic ARP inspection log buffer.

Switch# clear ip arp inspection log


Displays the configuration and contents of the dynamic ARP inspection log buffer.

Switch# show ip arp inspection log


Switch Port Security

A network must be secured by controlling what stations can gain access to the network itself. Where user workstations are stationary, their MAC addresses always can be expected to connect to the same access layer switch ports. If stations are mobile, their MAC addresses can be learned dynamically or added to a list of addresses to expect on a switch port.

Catalyst switches offer the port security feature to control port access based on MAC addresses. To configure port security on an access layer switch port, begin by enabling it on a per-interface basis with the following interface-configuration command:

Switch(config-if)# switchport port-security


Next, you must identify a set of allowed MAC addresses so that the port can grant them access. You can explicitly configure addresses or they can be learned dynamically from port traffic. On each interface that uses port security, specify the maximum number of MAC addresses that will be allowed access using the following interface command:

Switch(config-if)# switchport port-security maximum max-addr


By default, port security will make sure that only one MAC address will be allowed access on each switch port. You can set the maximum number of addresses in the range of 1 to 1024.

Each interface using port security dynamically learns MAC addresses by default and expects those addresses to appear on that interface in the future. MAC addresses are learned as hosts transmit frames on an interface. The interface learns up to the maximum number of addresses allowed. Learned addresses also can be aged out of the table if those hosts are silent for a period of time. By default, no aging occurs.
To set the maximum number of MAC addresses that can be active on a switch port at any time to two, you could use the following command:

Switch(config-if)# switchport port-security maximum 2


By default, port security learns MAC addresses dynamically and stores them in the CAM table and also in the running configuration. If the switch reboots for some reason, port security will have to relearn a new set of MAC addresses. To make the learned addresses persistent across a switch reboot, you can enable “sticky” MAC address learning with the following command:

Switch(config-if)# switchport port-security mac-address sticky


You can also statically define one or more MAC addresses on an interface. Any of these addresses are allowed to access the network through the port. Use the following interface command to define a static address:

Switch(config-if)# switchport port-security mac-address mac-addr


If the number of static addresses configured is less than the maximum number of addresses secured on a port, the remaining addresses are learned dynamically. Be sure to set the maximum number appropriately.

Use the following command to configure a static address entry on an interface, so that 0006.5b02.a841 will be expected:

Switch(config-if)# switchport port-security mac-address 0006.5b02.a841


Define how each interface using port security should react if a MAC address is in violation by using the following interface-configuration command:

Switch(config-if)# switchport port-security violation {shutdown | restrict |protect}


A violation occurs if more than the maximum number of MAC addresses are learned or if an unknown (not statically defined) MAC address attempts to transmit on the port. The switch port takes one of the following configured actions when a violation is detected:

  • Shutdown: The port immediately is put into the errdisable state, which effectively shuts it down. It must be reenabled manually or through errdisable recovery to be used again.
  • Restrict: The port is allowed to stay up, but all packets from violating MAC addresses are dropped. The switch keeps a running count of the number of violating packets and can send an SNMP trap and a syslog message as an alert of the violation.
  • Protect: The port is allowed to stay up, as in the restrict mode. Although packets from violating addresses are dropped, no record of the violation is kept.


As an example of the restrict mode, a switch interface has received the following configuration commands:

interface GigabitEthernet1/0/11
switchport access vlan 991
switchport mode access
switchport port-security
switchport port-security violation restrict
spanning-tree portfast


When the default maximum of one MAC address is exceeded on this interface, the condition is logged but the interface stays up. This is shown by the following syslog message:

Jun 3 17:18:41.888 EDT: %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 0000.5e00.0101 on port GigabitEthernet1/0/11.


Note: If an interface is undergoing the restrict or protect condition, you might need to clear the learned MAC addresses so that a specific host can use the switch port. You can clear a MAC address or the complete port cache with the following command:

Switch# clear port-security {all | configured | dynamic | sticky} [address mac-addr | interface type member/mod/num]


In the shutdown mode, the port security action is much more drastic. When the maximum number of MAC addresses is exceeded, the following syslog messages indicate that the port has been shut down in the errdisable state:

Jun 3 17:14:19.018 EDT: %PM-4-ERR_DISABLE: psecure-violation error detected on
Gi1/0/11, putting Gi1/0/11 in err-disable state
Jun 3 17:14:19.022 EDT: %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation
occurred, caused by MAC address 0003.a089.efc5 on port GigabitEthernet1/0/11.
Jun 3 17:14:20.022 EDT: %LINEPROTO-5-UPDOWN: Line protocol on Interface
GigabitEthernet1/0/11, changed state to down
Jun 3 17:14:21.023 EDT: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/11, changed
state to down


Verify Port Security Port Status

Switch# show port-security interface gigabitethernet 1/0/11
Port Security : Enabled
Port Status : Secure-shutdown
Violation Mode : Shutdown
Aging Time : 0 mins
Aging Type : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses : 1
Total MAC Addresses : 0
Configured MAC Addresses : 0
Sticky MAC Addresses : 0
Last Source Address : 0003.a089.efc5
Security Violation Count : 1


Verify Summary Information for Ports in the Errdisable State

Switch# show interfaces status err-disabled
Port Name Status Reason
Gi1/0/11 Test port err-disabled psecure-violation


When a port is moved to the errdisable state, you must either manually cycle it or configure the switch to automatically re-enable ports after a prescribed delay. To manually cycle a port and return it to service, use the following commands:

Switch(config)# interface type member/mod/num
Switch(config-if)# shutdown
Switch(config-if)# no shutdown


Verify Port Security Status Summary Information

Switch# show port-security
Secure Port MaxSecureAddr CurrentAddr SecurityViolation Security Action
(Count) (Count) (Count)
Gi1/0/11 5 1 0 Restrict
Gi1/0/12 1 0 0 Shutdown
Total Addresses in System (excluding one mac per port) : 0
Max Addresses limit in System (excluding one mac per port) : 6176


Private VLANs

Normally, traffic is allowed to move unrestricted within a VLAN. Packets sent from one host to another normally are heard only by the destination host because of the nature of Layer 2 switching.

However, if one host broadcasts a packet, all hosts on the VLAN must listen. You can use a VACL to filter packets between a source and destination in a VLAN if both connect to the local switch.

Sometimes it would be nice to have the capability to segment traffic within a single VLAN, without having to use multiple VLANs and a router. For example, in a singleVLAN server farm, all servers should be capable of communicating with the router or  gateway, but the servers should not have to listen to each other’s broadcast traffic. Taking this a step further, suppose that each server belongs to a separate organization. Now each server should be isolated from the others but still be capable of reaching the gateway to find clients not on the local network.

Another application is a service provider network. Here, the provider might want to use a single VLAN to connect to several customer networks. Each customer needs to be able to contact the provider’s gateway on the VLAN. Clearly, the customer sites do not need to interact with each other.

Private VLANs (PVLANs) solve this problem on Catalyst switches. In a nutshell, a normal, or primary, VLAN can be logically associated with special unidirectional, or secondary, VLANs. Hosts associated with a secondary VLAN can communicate with ports on the primary VLAN (a router, for example), but not with another secondary VLAN. A secondary VLAN is configured as one of the following types:

  • Isolated: Any switch ports associated with an isolated VLAN can reach the primary VLAN but not any other secondary VLAN. In addition, hosts associated with the same isolated VLAN cannot reach each other. They are, in effect, isolated from everything except the primary VLAN.
  • Community: Any switch ports associated with a common community VLAN can communicate with each other and with the primary VLAN but not with any other secondary VLAN. This provides the basis for server farms and workgroups within an organization, while giving isolation between organizations.


All secondary VLANs must be associated with one primary VLAN to set up the unidirectional relationship. Private VLANs are configured using special cases of regular VLANs. However, the VLAN Trunking Protocol (VTP) does not pass any information about the private VLAN configuration. Therefore, private VLANs are only locally significant to a switch. Each of the private VLANs must be configured locally on each switch that interconnects them.

You must configure each physical switch port that uses a private VLAN with a VLAN association. You also must define the port with one of the following modes:

  • Promiscuous: The switch port connects to a router, firewall, or other common gateway device. This port can communicate with anything else connected to the primary or any secondary VLAN. In other words, the port is in promiscuous mode, in which the rules of private VLANs are ignored.
  • Host: The switch port connects to a regular host that resides on an isolated or community VLAN. The port communicates only with a promiscuous port or ports on the same community VLAN.


Below shows the basic private VLAN operation. Some host PCs connect to a secondary community VLAN. The two community VLANs associate with a primary VLAN, where the router connects. The router connects to a promiscuous port on the primary VLAN. A single host PC connects to a secondary isolated VLAN, so it can communicate only with the router’s promiscuous port.

Private VLAN Functionality












Private VLAN Configuration

Defining a private VLAN involves several configuration steps.

Begin by defining any secondary VLANs that are needed for isolation using the following commands:

Switch(config)# vlan vlan-id
Switch(config-vlan)# private-vlan {isolated | community}


The secondary VLAN can be an isolated VLAN (no connectivity between isolated ports) or a community VLAN (connectivity between member ports).

Define the primary VLAN that will provide the underlying private VLAN connectivity using the following commands:

Switch(config)# vlan vlan-id
Switch(config-vlan)# private-vlan primary
Switch(config-vlan)# private-vlan association {secondary-vlan-list | add secondary-vlan-list | remove secondary-vlan-list}


Be sure to associate the primary VLAN with all its component secondary VLANs using the association keyword. If the primary VLAN already has been configured, you can add (add) or remove (remove) secondary VLAN associations individually. These VLAN configuration commands set up only the mechanisms for unidirectional connectivity from the secondary VLANs to the primary VLAN. You also must associate the individual switch ports with their respective private VLANs.


Associate Ports with Private VLANs

Define the function of the port that will participate on a private VLAN using the following command:

Switch(config-if)# switchport mode private-vlan {host | promiscuous}


If the host connected to this port is a router, firewall, or common gateway for the VLAN, use the promiscuous keyword. This allows the host to reach all other promiscuous, isolated, or community ports associated with the primary VLAN. Otherwise, any isolated or community port must receive the host keyword.

For a non-promiscuous port (using the switchport mode private-vlan host command), you must associate the switch port with the appropriate primary and secondary VLANs. Only the private VLANs themselves have been configured until now. The switch port must know how to interact with the various VLANs using the following interface command:

Switch(config-if)# switchport private-vlan host-association primary-vlan-id secondary-vlan-id


Note: When a switch port is associated with private VLANs, you do not have to configure a static access VLAN. Instead, the port takes on membership in the primary and secondary VLANs simultaneously. This does not mean that the port has a fully functional assignment to multiple VLANs. Instead, it takes on only the unidirectional behavior between the secondary and primary VLANs.


For a promiscuous port (using the switchport mode private-vlan promiscuous command), you must map the port to primary and secondary VLANs. Notice that promiscuous mode ports, or ports that can communicate with any other private VLAN device, are mapped, whereas other secondary VLAN ports are associated. One (promiscuous mode port) exhibits bidirectional behavior, whereas the other (secondary VLAN ports) exhibits unidirectional or logical behavior.


Map promiscuous mode ports to primary and secondary VLANs:

Switch(config-if)# switchport private-vlan mapping primary-vlan-id secondary-vlanlist | {add secondary-vlan-list} | {remove secondary-vlan-list}


Assume, that the switch below is configured as the next config example. Host PCs on ports Gigabit Ethernet 1/0/1 and 1/0/2 are in community VLAN 10, hosts on ports Gigabit Ethernet 1/0/4 and 1/0/5 are in community VLAN 20, and the host on port Gigabit Ethernet 1/0/3 is in isolated VLAN 30. The router on port Gigabit Ethernet 1/0/48 is in promiscuous mode on primary VLAN 100. Each VLAN is assigned a role, and the primary VLAN is associated with its secondary VLANs. Then each interface is associated with a primary and secondary VLAN (if a host is attached) or mapped to the primary and secondary VLANs (if a promiscuous host is attached).

Switch(config)# vlan 10
Switch(config-vlan)# private-vlan community
Switch(config-vlan)# vlan 20
Switch(config-vlan)# private-vlan community
Switch(config-vlan)# vlan 30
Switch(config-vlan)# private-vlan isolated
Switch(config-vlan)# vlan 100
Switch(config-vlan)# private-vlan primary
Switch(config-vlan)# private-vlan association 10,20,30
Switch(config-vlan)# exit
Switch(config)# interface range gigabitethernet 1/0/1 - 1/0/2
Switch(config-if)# switchport mode private-vlan host
Switch(config-if)# switchport private-vlan host-association 100 10
Switch(config-if)# exit
Switch(config)# interface range gigabitethernet 1/0/4 - 1/0/5
Switch(config-if)# switchport mode private-vlan host
Switch(config-if)# switchport private-vlan host-association 100 20
Switch(config-if)# exit
Switch(config)# interface gigabitethernet 1/0/3
Switch(config-if)# switchport mode private-vlan host
Switch(config-if)# switchport private-vlan host-association 100 30
Switch(config-if)# exit
Switch(config)# interface gigabitethernet 1/0/48
Switch(config-if)# switchport mode private-vlan promiscuous
Switch(config-if)# switchport private-vlan mapping 100 10,20,30

Private VLAN Functionality











Associate Secondary VLANs to a Primary VLAN SVI

On SVI’s configured with Layer 3 addresses, you must configure some additional private VLAN mapping. Example, where the SVI for the primary VLAN, VLAN 200, has an IP address and participates in routing traffic. Secondary VLANs 40 (an isolated VLAN) and 50 (a community VLAN) are associated at Layer 2 with primary VLAN 200 using the configuration below.

Switch(config)# vlan 40
Switch(config-vlan)# private-vlan isolated
Switch(config-vlan)# vlan 50
Switch(config-vlan)# private-vlan community
Switch(config-vlan)# vlan 200
Switch(config-vlan)# private-vlan primary
Switch(config-vlan)# private-vlan association 40,50
Switch(config-vlan)# exit
Switch(config)# interface vlan 200
Switch(config-if)# ip address


Primary VLAN 200 can forward traffic at Layer 3, but the secondary VLAN associations with it are good at only Layer 2. To allow Layer 3 traffic switching coming from the secondary VLANs as well, you must add a private VLAN mapping to the primary VLAN SVI interface, using the following interface command syntax:

Switch(config-if)# private-vlan mapping {secondary-vlan-list | add secondary-vlanlist | remove secondary-vlan-list}


The primary VLAN SVI function is extended to the secondary VLANs instead of requiring SVIs for each of them. If some mapping already has been configured for the primary VLAN SVI, you can add or remove secondary VLAN mappings individually.

Continuing with the example configuration above , you would map the private VLAN by adding the following commands:

Switch(config)# interface vlan 200
Switch(config-if)# private-vlan mapping 40,50


Securing VLAN Trunks

Because trunk links usually are bounded between two switches, you might think that they are more or less secure. Each end of the trunk is connected to a device that is under your control, VLANs carried over the trunk remain isolated, and so on.

Some exploits can be leveraged to gain access to a trunk or to the VLANs carried over a trunk. Therefore, you should become familiar with how the attacks work and what steps you can take to prevent them in the first place.


Switch Spoofing

With the post “VLANs and Trunks,” two switches can be connected by a common trunk link that can carry traffic from multiple VLANs. The trunk does not have to exist all the time. The switches dynamically can negotiate its use and its encapsulation mode by exchanging DTP messages.

Although DTP can make switch administration easier, it also can expose switch ports to be compromised. Suppose that a switch port is left to its default configuration, in which the trunking mode is auto. Normally, the switch port would wait to be asked by another switch in the auto or on mode to become a trunk.

Now suppose that an end user’s PC is connected to that port. A well-behaved end user would not use DTP at all, so the port would come up in access mode with a single-access VLAN. A malicious user in turn, might exploit the use of DTP and attempt to negotiate a trunk with the switch port. This makes the PC appear to be another switch, thus the PC is spoofing a switch.

After the trunk is negotiated, the attacker has access to any VLAN that is permitted to pass over the trunk. If the switch port has been left to its default configuration, all VLANs configured on the switch are allowed onto the trunk. Below shows this scenario in which the attacker can receive any traffic being sent over the trunk on any VLAN. In addition, he can send traffic into any VLAN of his choice.

Switch Spoofing








To demonstrate this further, consider the next output, which shows the default access switch port configuration. Notice that trunking is possible because the port is set to dynamic auto mode, awaiting DTP negotiation from a connected device. If a trunk is negotiated, all VLANs are permitted to be carried over it.

Switch# show interfaces gigabitethernet 1/0/46 switchport
Name: Gi1/0/46
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: trunk
Administrative Trunking Encapsulation: negotiate
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk Native VLAN tagging: enabled
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk private VLANs: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled Capture VLANs Allowed: ALL
Protected: false
Unknown unicast blocked: disabled
Unknown multicast blocked: disabled
Appliance trust: none


The solution is to configure every switch port to have an expected and controlled behavior, instead of leaving an end-user switch port set to use DTP in auto mode, configure it to static access mode with the following commands:

Switch(config)# interface gi1/0/46
Switch(config-if)# switchport access vlan vlan-id
Switch(config-if)# switchport mode access


An end user will never be able to send any type of spoofed traffic that will make the switch port begin trunking. In addition, you need to disable any unused switch ports to prevent someone from discovering a live port that might be exploited.


VLAN Hopping

When securing VLAN trunks, also consider the potential for an exploit called VLAN hopping. Here, an attacker positioned on one access VLAN can craft and send frames with spoofed 802.1Q tags so that the packet payloads ultimately appear on a totally different VLAN, all without the use of a router. For this exploit to work, the following conditions must exist in the network configuration:

  • The attacker is connected to an access switch port.
  • The same switch must have an 802.1Q trunk.
  • The trunk must have the attacker’s access VLAN as its native VLAN.


The next scenario shows how VLAN hopping works. The attacker, situated on VLAN 10, sends frames that are doubly tagged as if an 802.1Q trunk were being used. The attacker is not connected to a trunk, he is spoofing the trunk encapsulation to trick the switch into making the frames hop over to another VLAN.

VLAN Hopping Attack Process





The regular frame (or malicious payload), in this case, is initially given an 802.1Q tag with the VLAN ID of the target VLAN. Then a second bogus 802.1Q tag is added with the attacker’s access VLAN ID.

When the local switch Switch A receives a doubly tagged frame, it decides to forward it out the trunk interface. Because the first tag has the same VLAN ID as the trunk’s native VLAN, that tag is removed as the frame is sent on the trunk. The switch believes that the native VLAN should be untagged, as it should. Now the second (innermost) tag is exposed on the trunk.

When Switch B receives the frame, it examines any 802.1Q tag it finds. The spoofed tag for VLAN 20 is found, so the tag is removed and the frame is forwarded onto VLAN 20. Now the attacker successfully has sent a frame on VLAN 10 and gotten the frame injected onto VLAN 20, all through Layer 2 switching!

The key to this type of attack revolves around the use of untagged native VLANs. You always should carefully configure trunk links with the following steps:

Step 1. Set the native VLAN of a trunk to a bogus or unused VLAN ID.
Step 2. Prune the native VLAN off both ends of the trunk.


Suppose that an 802.1Q trunk should carry only VLANs 10 and 20. You should set the native VLAN to an unused value, such as 800. Then you should remove VLAN 800 from the trunk so that it is confined to the trunk link itself. Below example demonstrates how to accomplish this.

Switch(config)# vlan 800
Switch(config-vlan)# name bogus_native
Switch(config-vlan)# exit
Switch(config)# interface gigabitethernet 1/0/1
Switch(config-if)# switchport trunk encapsulation dot1q
Switch(config-if)# switchport trunk native vlan 800
Switch(config-if)# switchport trunk allowed vlan remove 800
Switch(config-if)# switchport mode trunk


Note: Tip Although maintenance protocols such as CDP, PAgP, and DTP normally are carried over the native VLAN of a trunk, they will not be affected if the native VLAN is removed or manually pruned from the trunk. They still will be sent and received on the native VLAN as a special case even if the native VLAN ID is not in the list of allowed VLANs.


An alternative is to force all 802.1Q trunks to add tags to frames for the native VLAN, too. The double-tagged VLAN hopping attack will not work because the switch will not remove the first tag with the native VLAN ID (VLAN 10 in the example). Instead, that tag will remain on the spoofed frame as it enters the trunk. At the far end of the trunk, the same tag will be examined, and the frame will stay on the original access VLAN (VLAN 10).

To force a switch to tag the native VLAN on all its 802.1Q trunks, you can use the following command:

Switch(config)# vlan dot1q tag native


Storm control

Storm control prevents traffic on a LAN from being disrupted by a broadcast, multicast, or unicast storm on one of the physical interfaces. A LAN storm occurs when packets flood the LAN, creating excessive traffic and degrading network performance. Errors in the protocol-stack implementation, mistakes in network configurations, or users issuing a DoS attack can cause a storm.

Storm control (or traffic suppression) monitors packets passing from an interface to the switching bus and determines if the packet is unicast, multicast, or broadcast. The switch counts the number of packets of a specified type received within the 1-second time interval and compares the measurement with a predefined suppression-level threshold.

Storm control uses one of these methods to measure traffic activity:

• Bandwidth as a percentage of the total available bandwidth of the port that can be used by the broadcast, multicast, or unicast traffic

• Traffic rate in packets per second at which broadcast, multicast, or unicast packets are received

• Traffic rate in bits per second at which broadcast, multicast, or unicast packets are received

With each method, the port blocks traffic when the rising threshold is reached. The port remains blocked until the traffic rate drops below the falling threshold (if one is specified) and then resumes normal forwarding. If the falling suppression level is not specified, the switch blocks all traffic until the traffic rate drops below the rising suppression level. In general, the higher the level, the less effective the protection against broadcast storms.

Note: When the storm control threshold for multicast traffic is reached, all multicast traffic except control traffic, (BDPU and CDP) frames, are blocked. However, the switch does not differentiate between routing updates, such as OSPF, and regular multicast data traffic, so both types of traffic are blocked.

Storm Control is configured on a per-interface basis to monitor traffic that is arriving or being received at the interface. The idea is to take action on frames as they enter the switch and arrive at the internal switching bus, before they are flooded to multiple switch ports. You can configure thresholds for the amount of broadcast, multicast, or unknown unicast traffic and an action to be taken when the thresholds are exceeded.

Note: You configure storm control on a port and enter the threshold level that you want to be used for a particular type of traffic. Because of hardware limitations and the way in which packets of different sizes are counted, threshold percentages are approximations. Depending on the sizes of the packets making up the incoming traffic, the actual enforced threshold might differ from the configured level by several percentage points.


First, select an interface where frames might be received and flooded. Then configure a threshold using the following interface configuration command syntax:

Switch(config-if)# storm-control {broadcast | multicast | unicast} level {level [level-low] | bps bps [bps-low] | pps pps [pps-low]}


Select the type of threshold with the broadcast, multicast, or unicast keyword. Keep in mind that “unicast” actually means unknown unicast; otherwise, the threshold would limit the volume of normal unicast frames passing through the interface.

You can set the traffic threshold with the level keyword and one of the following keywords and values:

level [level-low]: The threshold is set to a percentage of the interface bandwidth. The level and level-low percentages can be a value with two decimal places from 0.00 to 100.00.

bps bps [bps-low]: The threshold is set to a specific bits per second rate. The bps and bps-low values can range from 0.0 to 10000000000.0 (10 Gbps), with one decimal place.

pps pps [pps-low]: The threshold is set to a specific packets per second rate. The pps and pps-low values can range from 0.0 to 10000000000.0 (10 Gbps), with one decimal place.


Storm Control will take action when the flooded traffic rises to the first value, then will stop the action when the traffic falls below that value. You can set a different falling threshold by specifying the second – low value.


Note: Rather than counting zeroes for large bps and pps values, you can use k, m, and g to designate kilo-, mega-, and giga- units.


You can repeat the storm control command to define separate thresholds for broadcast, multicast, and unknown unicast traffic.
Next, specify the action to be taken when the threshold is exceeded. By default, the excessive frames are simply dropped as they are received. In addition, you can use the following interface configuration command to shut down the interface in errdisable mode or to send an SNMP trap as an alert of a storm condition in progress:

Switch(config-if)# storm-control action {shutdown | trap}


Storm Control is enabled for traffic received on interface Gigabit Ethernet 1/0/1. Because there is no storm control action command entered, the default action to drop excessive frames will be taken. When broadcast frames exceed 50 percent of the interface bandwidth, they will be dropped. When the rate of multicast frames exceeds 50,000 packets per second, they will be dropped. Finally, when the volume of unknown unicast frames rises above 20 percent and then stays above 10 percent of the interface bandwidth, they will be dropped, example below.

Switch(config)# interface gigabitethernet1/0/1
Switch(config-if)# storm control broadcast level 50
Switch(config-if)# storm control multicast level pps 50k
Switch(config-if)# storm control unicast level 20 10


Storm Control Configuration Example

Enable unicast storm control on a port with an 87-percent rising suppression level and a 65-percent falling suppression level:

Switch# configure terminal
Switch(config)# interface gigabitethernet1/0/1
Switch(config-if)# storm-control unicast level 87 65


Enable broadcast address storm control on a port to a level of 20 percent. When the broadcast traffic exceeds the configured level of 20 percent of the total available bandwidth of the port within the traffic-storm-control interval, the switch drops all broadcast traffic until the end of the traffic-storm-control interval:

Switch# configure terminal
Switch(config)# interface gigabitethernet1/0/1
Switch(config-if)# storm-control broadcast level 20


Verify storm control suppression levels set on the interface for the specified traffic type. If you do not enter a traffic type, broadcast storm control settings are displayed.

Switch# show storm-control gigabitethernet1/0/1  [broadcast |multicast | unicast]


Hope this helps someone else!


CCNP SWITCH 300-115 – Part 1.8 – Chassis Virtualization and Aggregation Technologies

Understanding Switch Stacks

A switch stack is a set of up to nine stacking-capable switches connected through their StackWise Plus or StackWise ports. You can connect only Catalyst 3750-E switches in a stack, or you can connect both Catalyst 3750-E and Catalyst 3750 switches in the stack. Catalyst 3750-E stack members have StackWise Plus ports, and Catalyst 3750 members have StackWise ports. The stack can have one of these configurations:

  • Homogeneous stack— A Catalyst 3750-E-only stack with only Catalyst 3750-E switches as stack members.
  • Mixed stack –A mixed hardware stack with Catalyst 3750-E and 3750 switches as stack members.

As an example, a stack with Catalyst 3750-E and 3750 switches supporting the advanced IP services features.

–A mixed software stack with only Catalyst 3750-E switches supporting different features or only Catalyst 3750 switches supporting different features as stack members.

For example, a Catalyst 3750-E-only stack with some members running the IP base feature set, other members running the IP services feature set, and the remaining members running the advanced IP services feature set.

–A mixed hardware and software stack with the Catalyst 3750-E and 3750 switches supporting different features as stack members.

For example, a stack with the Catalyst 3750-E members running the advanced IP services feature set and the Catalyst 3750 members running the IP services software image.

One of the switches controls the operation of the stack and is called the Stack Master.

The Stack Master and the other switches in the stack are all stack members. The Catalyst 3750-E stack members use the Cisco StackWise Plus technology to work together as a unified system. Layer 2 and Layer 3 protocols present the entire switch stack as a single entity to the network.

The stack master is the single point of stack-wide management. From the stack master, you configure:

  • System-level (global) features that apply to all stack members
  • Interface-level features for each stack member


A switch stack is identified in the network by its bridge ID and, if it is operating as a Layer 3 device, its router MAC address. The bridge ID and router MAC address are determined by the MAC address of the stack master. Every stack member is identified by its own stack member number.

All stack members are eligible to be stack masters. If the stack master becomes unavailable, the remaining stack members elect a new stack master from among themselves. The switch with the highest stack member priority value becomes the new stack master.

The system-level features supported on the stack master are supported on the entire switch stack. If a switch in the stack is running the IP base or IP services feature set and the cryptographic (supporting encryption) universal software image, we recommend that this switch be the stack master. Encryption features are unavailable if the stack master is running the IP base or IP services feature set and the noncryptographic software image.

The stack master contains the saved and running configuration files for the switch stack. The configuration files include the system-level settings for the switch stack and the interface-level settings for each stack member. Each stack member has a current copy of these files for back-up purposes.

You manage the switch stack through a single IP address. The IP address is a system-level setting and is not specific to the stack master or to any other stack member. You can manage the stack through the same IP address even if you remove the stack master or any other stack member from the stack.


You can use these methods to manage switch stacks:

  • Network Assistant
  • Command-line over a serial connection to the console port of any stack member or the Ethernet management port of a stack member
  • A network management application through SNMP

Use SNMP to manage network features across the switch stack that are defined by supported MIBs. The switch does not support MIBs to manage stacking-specific features such as stack membership and election.

  • CiscoWorks network management software


Note: A switch stack is different from a switch cluster. A switch cluster is a set of switches connected through their LAN ports, such as the 10/100/1000 ports.


Switch Stack Membership

Each switch supports two stack ports, switches are connected in a daisy-chain fashion, one switch to the next, and one final connection connects the chain into a closed loop. You can think of the stacking cables as an extension of the switching fabric. When frames need to be moved from one physical
switch to another, they are sent across the bidirectional stacking cable loop to get there.

A switch stack has up to nine stack members connected through their StackWise Plus ports. A switch stack always has one stack master.

A standalone switch is a switch stack with one stack member that also operates as the stack master. You can connect one standalone switch to another  to create a switch stack containing two stack members, with one of them as the stack master.

Note Make sure that you power off the switches that you add to or remove from the switch stack.





You can connect standalone switches to an existing switch stack to increase the stack membership.






If you replace a stack member with an identical model, the new switch functions with exactly the same configuration as the replaced switch, assuming that the new switch is using the same member number as the replaced switch.

The operation of the switch stack continues uninterrupted during membership changes unless you remove the stack master or you add powered-on standalone switches or switch stacks.

Note: After adding or removing stack members, make sure that the switch stack is operating at full bandwidth (64 Gb/s). Press the Mode button on a stack member until the Stack mode LED is on. The last two right port LEDs on all switches in the stack should be green. Depending on the switch model, the last two right ports are 10-Gigabit Ethernet ports or small form-factor pluggable (SFP) module ports (10/100/1000 ports). If one or both of these LEDs are not green on any of the switches, the stack is not operating at full bandwidth.

Adding powered-on switches (merging) causes the stack masters of the merging switch stacks to elect a stack master from among themselves. The re-elected stack master retains its role and configuration and so do its stack members. All remaining switches, including the former stack masters, reload and join the switch stack as stack members. They change their stack member numbers to the lowest available numbers and use the stack configuration of the re-elected stack master.

Removing powered-on stack members causes the switch stack to divide (partition) into two or more switch stacks, each with the same configuration. This can cause an IP address configuration conflict in your network. If you want the switch stacks to remain separate, change the IP address or addresses of the newly created switch stacks. If you did not intend to partition the switch stack:

a. Power off the switches in the newly created switch stacks.

b. Reconnect them to the original switch stack through their StackWise Plus ports.

c. Power on the switches.


One advantage of the closed stacking loop is that individual switches can be inserted or removed without breaking the path between switches completely. The ring can be broken to add or remove a switch, but the remaining switches stay connected over the rest of the ring, thus you can make changes to the stack without interrupting its operation.

When switches are connected as a stack, each one still maintains switching functionality, but only one switch becomes the stack master and performs
all of the management functions. In fact, the whole stack is managed through a single IP address. If the master switch fails, other member switches can take over the role.


Virtual Switching System (Vss)

Cisco also offers switches that are based on a chassis with slots that can contain multiple switching modules. The chassis must contain a supervisor module that handles all the switch management functions, including things like routing updates and forwarding tables. A chassis can also contain a redundant supervisor module, which can take over in case the current supervisor fails. With platforms like the Cisco Catalyst 4500R, 6500, and 8500, you can configure two identical chassis to work as one logical switch. This is known as a Virtual Switching System (VSS), aka VSS pair.

One supervisor in one of the chassis controls the operation of the logical switch. If it fails, a supervisor in the other chassis can take over. To build the logical switch, the two chassis must be linked together by multiple interfaces that have been configured as a Virtual Switch Link (VSL). Bellow shows two switch chassis operating as a VSS pair.








Supervisor and Route Processor Redundancy

HSRP, VRRP, and GLBP router or gateway redundancy protocols can provide high availability only for the default gateway addresses. If one of the redundant gateway routers fails, another can pick up the pieces and appear to be the same gateway address. But what happens to the devices that are connected directly to the router that fails? If the switching or routing engine fails, packets probably will not get routed and interfaces will go down.

Some Cisco switches have the capability to provide redundancy for the supervisor engine itself. This is accomplished by having redundant hardware in place within a switch chassis, ready to take over during a failure. You also should consider switch power as a vital part of achieving high availability.

If a switch has a single power supply and a single power cord, the whole switch will fail if the power supply fails or if the power cord is accidentally unplugged. Some switch platforms can have multiple power supplies; if one power supply fails, another immediately takes over the load.


Redundant Switch Supervisors

Platforms such as the Catalyst 4500R, 6500, and 6800 can accept two supervisor modules installed in a single chassis. The first supervisor module to successfully boot becomes the active supervisor for the chassis. The other supervisor remains in a standby role, waiting for the active supervisor to fail.

The active supervisor always is allowed to boot and become fully initialized and operational. All switching functions are provided by the active supervisor. The standby supervisor, however, is allowed to boot and initialize only to a certain level. When the active module fails, the standby module can proceed to initialize any remaining functions and take over the active role.

Redundant supervisor modules can be configured in several modes. The redundancy mode affects how the two supervisors handshake and synchronize information. In addition, the mode limits the standby supervisor’s state of readiness. The more ready the standby module is allowed to become, the less initialization and failover time will be required.

You can use the following redundancy modes on Catalyst switches:

  • Route processor redundancy (RPR): The redundant supervisor is only partially booted and initialized. When the active module fails, the standby module must reload every other module in the switch and then initialize all the supervisor functions.
  • Route processor redundancy plus (RPR+): The redundant supervisor is booted, allowing the supervisor and route engine to initialize. No Layer 2 or Layer 3 functions are started, however. When the active module fails, the standby module finishes initializing without reloading other switch modules. This allows switch ports to retain their state.
  • Stateful switchover (SSO): The redundant supervisor is fully booted and initialized. Both the startup and running configuration contents are synchronized between the supervisor modules. Layer 2 information is maintained on both supervisors so that hardware switching can continue during a failover. The state of the switch interfaces is also maintained on both supervisors so that links do not flap during a failover.


Note:  Tip Sometimes the redundancy mode terminology can be confusing. In addition to the RPR, RPR+, and SSO terms, you might see single-router mode (SRM) and dual-router mode (DRM). SRM simply means that two route processors (integrated into the supervisors) are being used, but only one of them is active at any time. In DRM, two route processors are active at all times. HSRP usually is used to provide redundancy in DRM.
Although RPR and RPR+ have only one active supervisor, the route processor portion is not initialized on the standby unit. Therefore, SRM is not compatible with RPR or RPR+. SRM is inherent with SSO, which brings up the standby route


Configuring the Redundancy Mode

Redundancy modes supported on switch platforms.






Bellow shows how the supervisor redundancy modes compare with respect to the functions they perform. The shaded functions are performed as the standby supervisor initializes and then waits for the active supervisor to fail. When a failure is detected, the remaining functions must be performed in sequence before the standby supervisor can become fully active. Notice how the redundancy modes get progressively more initialized and ready to become active.







You can configure the supervisor redundancy mode by entering the redundancy configuration mode:

Switch(config)# redundancy


Next, select the redundancy mode with the following commands syntax:

Switch(config-red)# mode {rpr | rpr-plus | sso}


Note:  Upon initial configuration, you must enter the previous commands on both supervisor modules. When the redundancy mode is enabled, you will make all configuration changes on the active supervisor only. The running configuration is synchronized automatically from the active to the standby module.

If you configure RPR+ with the rpr-plus keyword, the supervisor attempts to bring up RPR+ with its peer module. The IOS images must be of exactly the same release before RPR+ will work. If the images differ, the supervisor automatically falls back to RPR mode instead.

Verifying Supervisor Module Redundancy Mode and State:

Switch# show redundancy states

my state = 13 -ACTIVE
peer state = 8 -STANDBY HOT
Mode = Duplex
Unit = Secondary

Unit ID = 2

Redundancy Mode (Operational) = Route Processor Redundancy Plus
Redundancy Mode (Configured) = Route Processor Redundancy Plus
Split Mode = Disabled
Manual Swact = Enabled
Communications = Up

client count = 11
client_notification_TMR = 30000 milliseconds
keep_alive TMR = 9000 milliseconds
keep_alive count = 1
keep_alive threshold = 18
RF debug mask = 0x0

The output shows that the switch is using RPR+ and that the second supervisor module (unit ID 2 and “my state”) holds the active role. The other supervisor module is in the standby state and is HOT, meaning that it has initialized as far as the redundancy mode will allow.


Configuring Supervisor Synchronization

By default, the active supervisor synchronizes its startup configuration and configuration register values with the standby supervisor. You also can specify other information that should be synchronized.

First, use the following commands to enter the main-cpu configuration mode:

Switch(config)# redundancy
Switch(config-red)# main-cpu


Then use the following command to specify the information that will be synchronized:

Switch(config-r-mc)# auto-sync {startup-config | config-register | bootvar}

Note:  You can repeat the command if you need to use more than one of the keywords. To return to the default, use the auto-sync standard command.


Nonstop Forwarding

Nonstop forwarding (NSF) is an interactive method that focuses on quickly rebuilding the Routing Information Base (RIB) table after a supervisor switchover. The RIB is used to generate the FIB table for CEF, which is downloaded to any switch modules or hardware that can perform Cisco Express Forwarding (CEF).

Instead of waiting on any configured Layer 3 routing protocols to converge and rebuild the FIB, a router can use NSF to get assistance from other NSF-aware neighbors. The neighbors then can provide routing information to the standby supervisor, allowing the routing tables to be assembled quickly. In short, the Cisco proprietary NSF functions must be built in to the routing protocols on both the router that will need assistance and
the router that will provide assistance.

NSF is supported by the BGP, EIGRP, OSPF, and IS-IS routing protocols. To configure NSF, you must add the following commands to any routing protocol configuration on the switch.


Switch(config)# router bgp as-number
Switch(config-router)# bgp graceful-restart



Switch(config)# router ospf process-id
Switch(config-router)# nsf



Switch(config)# router eigrp as-number
Switch(config-router)# nsf



Switch(config)# router isis [tag]
Switch(config-router)# nsf [cisco | ietf]
Switch(config-router)# nsf interval [minutes]
Switch(config-router)# nsf t3 {manual [seconds] | adjacency}
Switch(config-router)# nsf interface wait seconds


Hope this helps someone else!

CCNP SWITCH 300-115 – Part 1.7 – Traffic Mirroring with SPAN & RSPAN

Switched Port Analyzer (SPAN)

Suppose that a problem exists on your network and you want to use a network analyzer/Sniffer to gather data. Of interest is a conversation between two hosts connected to a switch, one on interface Gigabit Ethernet 1/0/1 and the other on Gigabit Ethernet 1/0/47. Both ports are assigned to VLAN 100. Because other devices are already connected there, you must connect your analyzer to a different switch port. If you connect your analyzer to another port on VLAN 100, what will your packet capture show?

Recall that, by definition, switches learn where MAC addresses are located and forward packets directly to those ports. The only time a packet is flooded to ports other than the specific destination is when the destination MAC address has not already been located or when the packet is destined for a broadcast or multicast address. Your packet capture will show only the broadcast and multicast packets that are being flooded to the
analyzer’s switch port. None of the conversation between the two hosts of interest will be overheard.

Catalyst switches can use the Switched Port Analyzer (SPAN) feature to mirror traffic from one source switch port or VLAN to a destination port. This allows a monitoring device, such as a network analyzer/sniffer, to be attached to the destination port for capturing traffic.

When packets arrive on the source port or VLAN, they are specially marked so that they can be copied to the SPAN destination port as they are delivered to the normal destination port. In this way, the packet capture receives an exact copy of the packets that are being forwarded to and from the SPAN source.


Understanding SPAN & RSPAN

You can analyze network traffic passing through ports or VLANs by using SPAN or RSPAN to send a copy of the traffic to another port on the switch or on another switch that has been connected to a network analyzer or other monitoring or security device. SPAN copies/mirrors traffic received or sent (or both) on source ports or source VLANs to a destination port for analysis. SPAN does not affect the switching of network traffic on the source ports or VLANs. You must dedicate the destination port for SPAN use. Except for traffic that is required for the SPAN or RSPAN session, destination ports do not receive or forward traffic.

Only traffic that enters or leaves source ports or traffic that enters or leaves source VLANs can be monitored by using SPAN, traffic routed to a source VLAN cannot be monitored. If incoming traffic is being monitored, traffic that gets routed from another VLAN to the source VLAN cannot be monitored, but traffic that is received on the source VLAN and routed to another VLAN can be monitored.

You can use the SPAN or RSPAN destination port to inject traffic from a network security device. If you connect an IDS sensor appliance to a destination port, the IDS device can send TCP reset packets to close down the TCP session of a suspected attacker.


There are two types of Switch Port Analyzer

Local SPAN: Both the SPAN source and destination are located on the local switch. The source is one or more switch ports.

Remote SPAN (RSPAN): The SPAN source and destination are located on different switches. Mirrored traffic is copied over a special-purpose VLAN across trunks between switches from the source to the destination.


Local SPAN

A local SPAN session exists on only one switch or switch stack. You must identify one or more source interfaces and a destination interface where monitored traffic will be copied or mirrored. Bellow illustrates the basic local SPAN operation where the goal is to monitor all traffic coming from Server1. Interface 5, where Server1 is connected, is the SPAN source. A network analyzer is connected to interface 23, which is the SPAN destination. As Ethernet frames arrive from Server1 on interface 5, the switch makes copies of them and forwards them to the network analyzer.

Local SPAN







Next picture shows how SPAN works with traffic in the opposite direction. In this case, the SPAN session is monitoring traffic going toward Server1. As Ethernet frames exit the switch going toward the SPAN source Server1, they are copied to the SPAN Traffic analyzer. When you configure a SPAN session, you can specify the direction of traffic that will be mirrored, as either received, transmitted, or both.

Local SPAN2







The SPAN source can be identified as one or more physical switch ports on the switch. The ports can belong to the same VLAN or different VLANs. In addition, a trunk port can be used as a SPAN source, causing traffic from all VLANs that are active on the trunk to be copied to the SPAN destination.

You can apply a VLAN filter to the SPAN source to limit which VLANs will be monitored on the trunk. A SPAN source can also be a switch port that is a member of an EtherChannel. In this case, only traffic passing over that physical port in the EtherChannel will be copied to the SPAN destination, allowing you to monitor a single link in the channel. To monitor all traffic passing across an entire EtherChannel, you can identify a port-channel interface as the SPAN source.

To monitor traffic passing within one or more VLANs on the switch, you can identify the VLANs as the SPAN source. This is essentially the same as local SPAN, but is often called VLAN-based SPAN or VSPAN. All switch ports that are active on a source VLAN become sources themselves.
The destination is identified as a physical interface located on the same switch as the source. Frames that are copied or mirrored from the SPAN source are copied into the SPAN destination port’s egress queue. Because the frames are merely copied within the switch, the original data is not affected and is still forwarded normally.
What happens if the SPAN source and destination ports are operating at different speeds? This easily could happen if the source is a VLAN with many hosts, or if the source is a 10-Gigabit Ethernet port and the destination is a Gigabit Ethernet port. Mirrored frames are copied into the destination port’s egress queue, as if normal Layer 2 switching had decided to forward them there. If the destination port becomes congested, the mirrored frames might be dropped from the queue and not transmitted out the destination port, so,  if the bandwidth of SPAN source traffic exceeds that of the SPAN destination port, some mirrored traffic might not be seen at the destination port.


Configure Local SPAN

Command syntax and logic is as follows.

Start by defining the source of the SPAN session data, using the following :

Switch(config)# monitor session session-number source {interface type member/mod/num | vlan vlan-id}[rx | tx | both]


SPAN sessions must be numbered uniquely using the session-number parameter. If multiple SPAN sources are needed, you can repeat this command. The SPAN source must be a physical switch interface or a Layer 2 VLAN, not a logical VLAN interface or SVI. However, you cannot mix both interfaces and VLANs in the same SPAN session. Instead, you can create separate sessions to monitor each type of source. Traffic can be selected for mirroring based on the direction it is traveling through the SPAN source. For example, you can select only traffic received on the source (rx), only

traffic transmitted from the source (tx), or traffic in both directions (both). By default, both directions are used.

Next, identify the SPAN destination by using the bellow command. Be sure to enter the same session number so that the destination gets bound to the corresponding source:

Switch(config)# monitor session session-number destination interface type member/mod/num [encapsulation replicate]


Note: the SPAN destination interface can only transmit mirrored traffic by default. Any frames that are sent into the destination interface are simply dropped. In most cases, the one-way traffic is sufficient because network analyzers only receive frames to be captured and analyzed. If you connect a device that also needs to transmit data back into the network, you can override the default SPAN behavior.

Add the following command syntax to the monitor session destination command to allow ingress traffic:

ingress {dot1q vlan vlan-id | isl | untagged vlan vlan-id


Because the SPAN destination interface is not bound to any specific interface or trunking encapsulation, you must specify how the ingress traffic should be handled. If the ingress traffic uses 802.1Q encapsulation, use the dot1q keyword and identify the default VLAN number. If the ingress traffic uses Inter-Switch Link (ISL) encapsulation, enter the isl keyword. Otherwise, if the ingress traffic is not encapsulated, use the untagged keyword
and identify to which VLAN the traffic should be sent.

If the SPAN source is a trunk port, you might want to mirror only traffic from specific VLANs on the trunk. You can specify a list of VLANs with the following command:

Switch(config)# monitor session session-number filter vlan vlan-range

From the previous picture above, suppose you would like to monitor traffic going to and coming from a device connected to interface Gigabit Ethernet 1/0/1. You have connected a network analyzer to interface Gigabit Ethernet1/0/48. Because the source and destination devices are connected to the same logical switch, you can use a local SPAN session to monitor the traffic.

Configuring a Local SPAN Session example

Switch(config)# monitor session 1 source interface gigabitethernet1/0/1 both
Switch(config)# monitor session 1 destination interface gigabitethernet1/0/48


Note: When local SPAN is enabled, STP is disabled on the destination port. This allows STP BPDUs to be captured and monitored but also allows the possibility for a bridging loop to form. Never connect a SPAN session’s destination port back into an active network. If the monitored packets need to be sent toward another switch, use RSPAN instead.

You can configure one or more simultaneous SPAN sessions on a Catalyst switch. The number of supported SPAN sessions depends on the switch model. A Catalyst 3750-X can support two sessions, a Catalyst 6500 can support up to 64. Each SPAN session is completely independent because there is no interaction between the mirroring processes of each one.

Set up SPAN session 1 for monitoring source port traffic to a destination port. First, any existing SPAN configuration for session 1 is deleted, and then bidirectional traffic is mirrored from source Gigabit Ethernet port 1 to destination Gigabit Ethernet port 2, retaining the encapsulation method.

Switch(config)# no monitor session 1
Switch(config)# monitor session 1 source interface gigabitethernet1/0/1
Switch(config)# monitor session 1 destination interface gigabitethernet1/0/2 encapsulation replicate
Switch(config)# end


Remove port 1 as a SPAN source for SPAN session 1

Switch(config)# no monitor session 1 source interface gigabitethernet1/0/1
Switch(config)# end


Disable received traffic monitoring on port 1, which was configured for bidirectional monitoring

Switch(config)# no monitor session 1 source interface gigabitethernet1/0/1 rx

The monitoring of traffic received on port 1 is disabled, but traffic sent from this port continues to be monitored.


Remove any existing configuration on SPAN session 2, configure SPAN session 2 to monitor received traffic on all ports belonging to VLANs 1 through 3, and send it to destination Gigabit Ethernet port 2. The configuration is then modified to also monitor all traffic on all ports belonging to VLAN 10.

Switch(config)# no monitor session 2
Switch(config)# monitor session 2 source vlan 1 - 3 rx
Switch(config)# monitor session 2 destination interface gigabitethernet1/0/2
Switch(config)# monitor session 2 source vlan 10
Switch(config)# end


Creating a Local SPAN Session and Configuring Incoming Traffic

Remove any existing configuration on SPAN session 2, configure SPAN session 2 to monitor received traffic on Gigabit Ethernet source port 1, and send it to destination Gigabit Ethernet port 2 with the same egress encapsulation type as the source port, and to enable ingress forwarding with IEEE 802.1Q encapsulation and VLAN 6 as the default ingress VLAN.

Switch(config)# no monitor session 2
Switch(config)# monitor session 2 source gigabitethernet1/0/1 rx
Switch(config)# monitor session 2 destination interface gigabitethernet1/0/2 encapsulation replicate ingress dot1q vlan 6 
Switch(config)# end


Specifying VLANs to Filter

Remove any existing configuration on SPAN session 2, configure SPAN session 2 to monitor traffic received on Gigabit Ethernet trunk port 2, and send traffic for only VLANs 1 through 5 and VLAN 9 to destination Gigabit Ethernet port 1.

Switch(config)# no monitor session 2
Switch(config)# monitor session 2 source interface gigabitethernet1/0/2 rx
Switch(config)# monitor session 2 filter vlan 1 - 5 , 9
Switch(config)# monitor session 2 destination interface gigabitethernet1/0/1
Switch(config)# end


Remote SPAN

In a large switched network or one that is geographically separated, it might not always be convenient to take a network analyzer to the switch where a SPAN source is located. To make SPAN more extensible, Cisco developed the Remote SPAN (RSPAN) feature. With RSPAN, the source and destination can be located on different switches in different locations.

The RSPAN source is identified on one switch where the source is connected, just as with local SPAN. The RSPAN destination is identified on another switch where the mirrored traffic will be collected. Then RSPAN will carry only the mirrored data over a special purpose VLAN across trunk links and intermediate switches between the source and destination. As long as every switch along the way is RSPAN capable, the source can be located at the far-end switch, while the network analyzer might be conveniently located at the switch nearest you.

The bellow example shows a network that uses RSPAN to mirror traffic from the source on Switch A to the destination on Switch C. The switches are connected by trunk links that carry a VLAN that is set aside for RSPAN traffic. At the source switch, mirrored frames are copied and sent toward the RSPAN destination over the RSPAN VLAN. At the destination switch, packets are pulled off the RSPAN VLAN and copied to the RSPAN destination port.

RSPAN VLAN has important differences from a regular VLAN. First, MAC address learning is disabled on the RSPAN VLAN. This is to prevent intermediate switches that transport the RSPAN VLAN from trying to forward the mirrored packets to their real destination MAC addresses.

Note: The purpose of SPAN or RSPAN is to simply mirror or copy interesting frames, not forward them normally.

An RSPAN-capable switch also floods the RSPAN packets out all its ports belonging to the RSPAN VLAN, in an effort to send them toward the RSPAN destination. Intermediate switches have no knowledge of the RSPAN source or destination; they know only of the RSPAN VLAN itself. Therefore, the RSPAN VLAN should be limited to the links that participate in RSPAN transport. In other words, the RSPAN VLAN should be allowed on trunks between switches, but should not be assigned to any other switch ports along the path.









Configuration wise, on switch 1 the configuration needed is port 1 as RSPAN source and VLAN 99 as the RSPAN destination. Following the switch path switch2 has no need for configuration and switch3 is then configured with VLAN 99 as the RSPAN source and port 48 as the RSPAN destination.


Configuring RSPAN

RSPAN configuration begins with the definition of the special-purpose RSPANVLAN. If you configure the RSPANVLAN on a VTP server, VTP correctly propagates it to other intermediate switches. If you are not using VTP, be sure to configure this VLAN for RSPAN explicitly on each intermediate switch. Otherwise, the RSPAN packets will not be delivered correctly.

If VTP pruning is in use, the RSPAN VLAN will be pruned from unnecessary trunks, limiting the traffic impact in unrelated areas of the network so make sure not to prune the desired VLAN from crossing the trunks.

Best is to create and maintain one or more RSPAN VLANs for the special monitoring purpose only. Set aside one RSPAN VLAN for each RSPAN session that will be used. Do not allow any normal hosts to join an RSPAN VLAN.


Configuration guidelines when configuring RSPAN

  • As RSPAN VLANs have special properties, you should reserve a few VLANs across your network for use as RSPAN VLANs; do not assign access ports to these VLANs.
  • You can apply an output ACL to RSPAN traffic to selectively filter or monitor specific packets. Specify these ACLs on the RSPAN VLAN in the RSPAN source switches.
  • For RSPAN configuration, you can distribute the source ports and the destination ports across multiple switches in your network.
  • RSPAN does not support BPDU packet monitoring or other Layer 2 switch protocols.
  • The RSPAN VLAN is configured only on trunk ports and not on access ports. To avoid unwanted traffic in RSPAN VLANs, make sure that the VLAN remote-span feature is supported in all the participating switches.
  • Access ports (including voice VLAN ports) on the RSPAN VLAN are put in the inactive state.
  • RSPAN VLANs are included as sources for port-based RSPAN sessions when source trunk ports have active RSPAN VLANs. RSPAN VLANs can also be sources in SPAN sessions. However, since the switch does not monitor spanned traffic, it does not support egress spanning of packets on any RSPAN VLAN identified as the destination of an RSPAN source session on the switch.

You can configure any VLAN as an RSPAN VLAN as long as these conditions are met:

–The same RSPAN VLAN is used for an RSPAN session in all the switches.

–All participating switches support RSPAN.


Define an RSPAN VLAN on each switch between the source and destination with the following configuration commands:

Switch(config)# vlan vlan-id
Switch(config-vlan)# remote-span


Next, you must identify the RSPAN source and destination on the two switches where the source and destination are connected. At the source switch, identify the source and destination with the following :

Switch(config)# monitor session session-number source {interface type member/ mod/num | vlan vlan-id}[rx | tx | both]
Switch(config)# monitor session session-number destination remote vlan rspan-vlan-id


Here, the source is either a physical switch interface or a Layer 2 VLAN (not an SVI interface). Notice that the syntax is identical to the local SPAN monitor session source command. The RSPAN destination is simply the RSPAN VLAN. This allows the mirrored packets to be copied into the special VLAN and sent on their way toward the final RSPAN destination. As with a local SPAN session, you can also use the monitor session filter command to filter VLANs from a trunk interface that is used as a SPAN source.

At the destination switch, you must again identify the RSPAN source and destination by using the following commands:

Switch(config)# monitor session session-number source remote vlan rspan-vlan-id
Switch(config)# monitor session session-number destination interface type member/mod/num [encapsulation replicate]










Again, using the last above network design, the source is connected to Switch 1 port Gigabit Ethernet 1/0/1. The destination is a network analyzer connected to port Gigabit Ethernet 1/0/48 on Switch 3. Switch 2 simply passes the RSPAN session traffic over VLAN 99, transported by trunk links to switches 1 and 3. For Switch 2, only the commands relevant to the RSPAN VLAN are listed. The trunk links are assumed to allow VLAN 99 toward Switches 1 and 3.

Configuring RSPAN on Switch 1

Switch(config)# vlan 99
Switch(config-vlan)# remote-span
Switch(config-vlan)# exit
Switch(config)# monitor session 1 source interface gigabitethernet 1/0/1 both
Switch(config)# monitor session 1 destination remote vlan 99


Configuring RSPAN on Switch 2

Switch(config)# vlan 99
Switch(config-vlan)# remote-span
Switch(config-vlan)# exit 


Configuring RSPAN on Switch 3

Switch(config)# vlan 99
Switch(config-vlan)# remote-span
Switch(config-vlan)# exit
Switch(config)# monitor session 1 source remote vlan 99
Switch(config)# monitor session 1 destination interface gigabitethernet 1/0/48 


Managing SPAN Sessions

Like any other configuration commands, the monitor session source and monitor session destination commands are placed into the running configuration of the switch as you enter them. You can display SPAN sessions by searching for the commands in the switch configuration:

Verify SPAN Sessions in the Switch Configuration

Switch# show running-config | include monitor
monitor session 1 source interface Gi1/0/1
monitor session 1 destination interface Gi1/0/48


You can also see verify about currently active SPAN sessions by entering the show monitor command. By default, all active sessions are displayed. You can use the session keyword to limit the output to specific sessions, all session, only local sessions, or only remote sessions. Command syntax:

Switch# show monitor [session {session-number | all | local | range range-list | remote}] [detail]


Verify the Currently Active SPAN Sessions

Switch# show monitor
Session 1
Type : Local Session
Source Ports :
Both : Gi1/0/1
Destination Ports : Gi1/0/48
Encapsulation : Native
Ingress : Disabled

Session 2
Type : Remote Source Session
Source Ports :
Both : Gi1/0/1
Dest RSPAN VLAN : 99


You can delete a SPAN session after the packet analysis is complete. SPAN sessions are numbered, so you can delete them by referencing the session number.

Delete one or more sessions

Switch(config)# no monitor session {session | range session-range} | local | all}


Important Note:  Session numbers can be given as an individual session, a range of sessions, all local SPAN sessions, or all sessions (local or remote). When you finish using a SPAN session, you always should disable or delete it, or someone might try to connect to the port that is configured as the SPAN destination. You could spend a good bit of time troubleshooting that user’s connectivity problem only to find that you left a SPAN session active there.


Hope this helps someone else!

CCNP SWITCH 300-115 – Part1.6 Configure and Verify Spanning Tree

STP Overview

STP is a Layer 2 link management protocol that provides path redundancy while preventing loops in the network. For a Layer 2 Ethernet network to function properly, only one active path can exist between any two stations. Multiple active paths among end stations cause loops in the network. If a loop exists in the network, end stations might receive duplicate messages. Switches might also learn end-station MAC addresses on multiple Layer 2 interfaces. These conditions result in an unstable network. Spanning-tree operation is transparent to end stations, which cannot detect whether they are connected to a single LAN segment or a switched LAN of multiple segments.

STP uses a spanning-tree algorithm to select one switch of a redundantly network as the root of the spanning tree. The algorithm calculates the best loop-free path through a Layer 2 network by assigning a role to each port, based on the role of the port in the active topology:

  • Root—A forwarding port elected for the spanning-tree topology
  • Designated—A forwarding port elected for every switched LAN segment
  • Alternate—A blocked port providing an alternate path to the root bridge in the spanning tree
  • Backup—A blocked port in a loopback configuration


The switch that has all of its ports as the designated role or as the backup role is the root switch. The switch that has at least one of its ports in the designated role is called the designated switch.

Spanning tree forces redundant data paths into a standby (blocked) state. If a network segment in the spanning tree fails and a redundant path exists, the spanning-tree algorithm recalculates the spanning-tree topology and activates the standby path.

Switches send and receive spanning-tree frames, bridge protocol data units (BPDUs), at regular intervals. The switches do not forward these frames but use them to construct a loop-free path. BPDUs contain information about the sending switch and its ports, including switch and MAC addresses, switch priority, port priority, and path cost.

Spanning tree uses this information to elect the root switch and root port for the switched network and the root port and designated port for each switched segment.

When two ports on a switch are part of a loop, the spanning-tree port priority and path cost settings control which port is put in the forwarding state and which is put in the blocking state. The spanning-tree port priority value represents the location of a port in the network topology and how well it is located to pass traffic. The path cost value represents the media speed.

Note: By default, the switch sends keepalive messages, (to ensure the connection is up), only on interfaces that do not have small form-factor pluggable (SFP) modules. You can change the default for an interface by entering the [no] keepalive interface command.


Spanning-Tree Topology and BPDUs

Data messages are exchanged in the form of Bridge Protocol Data Units (BPDUs). A switch sends a BPDU frame out a port, using the unique MAC address of the port itself as a source address.

BPDU frames are sent with a destination address of the well-known:

STP Multicast address 01-80-c2-00-00-00.

Two types of BPDU exist:

  • Configuration BPDU: used for spanning-tree computation
  • Topology Change Notification (TCN) BPDU: used to announce changes in the network topology


Configuration BPDU Message Content

Configuration BPDU











BPDU messages works as a foundation for a stable spanning-tree topology. Also, loops can be identified and removed by placing specific redundant ports in a Blocking or Standby state.

Notice that several key fields in the BPDU are related to bridge identification, path costs, and timer values. These all work together so that the network of switches can converge on a common spanning-tree topology and select the same reference points within the network.

By default, BPDUs are sent out all switch ports every 2 seconds so that current topology information is exchanged and loops are identified quickly.


Electing the Root Bridge

To agree on a loop-free topology, a common frame of reference must exist to use as a guide. This reference point is called the root bridge (switch). An election process among all connected switches chooses the root bridge. Each switch has a unique bridge ID that identifies it to other switches.

The bridge ID is an 8-byte value consisting of the following fields:

  • Bridge Priority (2 bytes): The priority of a switch in relation to all other switches. Priority field can have a value of 0 to 65,535 and defaults to 32,768 (or 0x8000) switch.
  • MAC Address (6 bytes): The MAC address used by a switch can come from the Supervisor module, the backplane, or a pool of 1024 addresses that are assigned to every supervisor or backplane, depending on the switch model. In any event, this address is hard-coded and unique, and the user cannot change it.


When a switch first powers up, it has a narrow view of its surroundings and assumes that it is the root bridge itself. The election process then proceeds as follows:

Every switch begins by sending out BPDUs with a root bridge ID equal to its own bridge ID and a sender bridge ID that is its own bridge ID. The sender bridge ID simply tells other  switches who is the actual sender of the BPDU message.

Note: After a root bridge is decided on, configuration BPDUs are sent only by the root bridge. All other bridges must forward or relay the BPDUs, adding their own sender bridge IDs to the message.

Received BPDUs are analyzed to see if a “better” root bridge is being announced. A root bridge is considered better if the root bridge ID value is lower than another.

Think of the root bridge ID as being broken into Bridge Priority and MAC Address fields. If two bridge priority values are equal, the lower MAC address makes the bridge ID better.

When a switch hears of a better root bridge, it replaces its own root bridge ID with the root bridge ID announced in the BPDU. The switch then is required to recommend or advertise the new root bridge ID in its own BPDU messages.

The election converges and all switches agree on the notion that one of them is the root bridge. If a new switch with a lower bridge priority powers up, it begins advertising itself as the root bridge.

Because the new switch does indeed have a lower bridge ID, all the switches soon reconsider and record it as the new root bridge. This can also happen if the new switch has a bridge priority equal to that of the existing root bridge but has a lower MAC address. Root bridge election is an ongoing process, triggered by root bridge ID changes in the BPDUs every 2 seconds. (beware).

Consider the small network bellow. Assume that each switch has a MAC address of all 0s, with the last hex digit equal to the switch label:

Priority 32768
MAC Address: 0000.0000.000a
Priority 32768
MAC Address: 0000.0000.000b
Priority 32768
MAC Address: 0000.0000.000c

spanning-tree bridge election





Each switch has the default bridge priority of 32,768. The switches are interconnected with Gigabit Ethernet links (Cost 4). All three switches try to elect themselves as  the root, but all of them have equal bridge priority values. The election outcome produces the root bridge by the lowest MAC address, Switch A.


Bridge ID, Switch Priority, and Extended System ID

802.1D standard requires that each switch has an unique bridge ID, which controls the selection of the root switch. Because each VLAN is considered as a different logical bridge with PVST+ and Rapid PVST+, the same switch must have a different bridge IDs for each configured VLAN.

Each VLAN on the switch has a unique 8-byte bridge ID. The 2 most-significant bytes are used for the switch priority, and the remaining 6 bytes are derived from the switch MAC address.

The switch supports the IEEE 802.1t spanning-tree extensions, and some of the bits previously used for the switch priority are now used as the VLAN identifier.

The result is that fewer MAC addresses are reserved for the switch, and a larger range of VLAN IDs can be supported, all while maintaining the uniqueness of the bridge ID. As shown bellow, the 2 bytes previously used for the switch priority are reallocated into a 4-bit priority value and a 12-bit extended system ID value equal to the VLAN ID.

Switch Priority Value & Extended System ID

Switch Priority Value and Extended System ID




Spanning tree uses the extended system ID, the switch priority, and the allocated spanning-tree MAC address to make the bridge ID unique for each VLAN.

Because the switch stack appears as a single switch to the rest of the network, all switches in the stack use the same bridge ID for a given spanning tree. If the stack master fails, the stack members recalculate their bridge IDs of all running spanning trees based on the new MAC address of the new stack master.

Support for the extended system ID affects how you manually configure the root switch, the secondary root switch, and the switch priority of a VLAN. When you change the switch priority, you change the probability that the switch will be elected as the root switch.

Note: Configuring a higher value decreases the probability, a lower value increases the probability.


Spanning-Tree Interface States (STP 802.1D)

When an interface transitions directly from nonparticipation in the spanning-tree topology to the forwarding state, it can create temporary data loops.

Interfaces must wait for new topology information to propagate through the switched LAN before starting to forward frames. They must allow the frame lifetime to expire for forwarded frames that have used the old topology.


Interface States (STP):

  • Blocking—The interface does not participate in frame forwarding.
  • Listening—The first transitional state after the blocking state when the spanning tree decides that the interface should participate in frame forwarding.
  • Learning—The interface prepares to participate in frame forwarding.
  • Forwarding—The interface forwards frames.
  • Disabled—The interface is not participating in spanning tree because of a shutdown port, no link on the port, or no spanning-tree instance running on the port.


An interface moves through these states:

  • Initialization -> Blocking
  • Blocking -> Listening or Disabled
  • Listening -> Learning or Disabled
  • Learning -> Forwarding or Disabled
  • Forwarding -> Disabled


Blocking State

Does not participate in frame forwarding. After initialization, a BPDU is sent to each switch interface. A switch initially functions as the root until it exchanges BPDUs with other switches. This exchange establishes which switch in the network is the root. An interface always enters the blocking state after switch initialization.

Blocking state performs these functions:

  • Discards frames received on the interface
  • Discards frames switched from another interface for forwarding
  • Does not learn addresses
  • Receives BPDUs


Listening State

The port still cannot send or receive data frames. However, the port is allowed to receive and send BPDUs so that it can actively participate in the Spanning Tree topology process. The port finally is allowed to become a root port or designated port because the switch can advertise the port by sending BPDUs to other switches. If the port loses its root port or designated port status, it returns to the Blocking state.

Listening state performs these functions

  • Discards frames received on the interface
  • Discards frames switched from another interface for forwarding
  • Does not learn addresses
  • Receives BPDUs


Learning State

After the forward delay in the Listening state, the port moves into the Learning state. The port still sends and receives BPDUs, the switch now can learn new MAC addresses to add to its address table. This gives the port an extra period of silent participation and allows the switch to assemble at least some address information. The port cannot yet send any data frames.

Learning state performs these functions:

  • Discards frames received on the interface
  • Discards frames switched from another interface for forwarding
  • Learns addresses
  • Receives BPDUs


Forwarding State

After another forward delay period in the Learning state, the port is allowed to move into the Forwarding state. The port now can send and
receive data frames, collect MAC addresses in its address table, and send and receive BPDUs. Fully functioning port within the spanning-tree topology.

Forwarding state performs these functions:

  • Receives and forwards frames received on the interface
  • Forwards frames switched from another interface
  • Learns addresses
  • Receives BPDUs


Disabled State

Ports administratively shut down, by administrator or by the system because of a fault condition, are in the Disabled state. This state is special and is not part of the normal STP progression for a port.

Disabled interface performs these functions:

  • Discards frames received on the interface
  • Discards frames switched from another interface for forwarding
  • Does not learn addresses
  • Does not receive BPDUs


Electing Root Ports

Once the root bridge has been elected for the entire switched network, each non-root switch must figure out where it is in relation to the root bridge. This action will be performed by selecting only one root port on each non-root switch. The root port always points toward the current root bridge (or the lowest path cost to the root).

Selecting a root port involves evaluating the root path cost. Its a cumulative cost of all the links leading to the root bridge.

A particular switch link also has a cost associated with it, called the path cost. To understand the difference between these values, only the root path cost is carried inside the BPDU.

As the root path cost travels along, other switches can modify its value to make it cumulative. The path cost is not contained in the BPDU. It is known only to the local switch where the port/path to a neighboring resides.

Path costs are defined as a 1-byte value, with the default values shown bellow. The higher the bandwidth of a link, the lower the cost. The original IEEE 802.1D standard defined path cost as:

1000 Mbps / Link bandwidth Mbps =

Networks commonly use Gigabit and 10-Gigabit Ethernet, which are both either too close to or greater than the maximum scale of 1000 Mbps. The IEEE now uses a non-linear scale for path cost (also shown bellow).


802.1D & 802.1W Path Cost

Stp Rstp Link Cost








The root path cost value is determined in the following manner:

  1. The root bridge sends out a BPDU with a root path cost value of 0 because its ports sit directly on the root bridge.
  2. When the next-closest neighbor receives the BPDU, it adds the path cost of its own port where the BPDU arrived. (This is done as the BPDU is received.)
  3. The neighbor sends out BPDUs with this new cumulative value as the root path cost.
  4. The root path cost is incremented by the ingress port path cost as the BPDU is received at each switch down the line.
  5. Notice the emphasis on incrementing the root path cost as BPDUs are received. When computing the spanning-tree algorithm manually, remember to compute a new root path cost as BPDUs come in to a switch port, not as they go out.


Electing Designated Ports

Each switch “connects” itself toward the reference point (root bridge) with the single link that has the best path. A tree structure is beginning to emerge, but links have only been identified at this point. All links still are connected and could be active, leaving bridging loops.

To remove bridging loops, STP makes a final computation to identify one designated port on each network segment. Suppose that two or more switches have ports connected to a single common network segment.

If a frame appears on that segment, all the bridges attempt to forward it to its destination. This behavior was the basis of a bridging loop and should be avoided.

Only one of the links on a segment should forward traffic to and from that segment, (Designated port).

Designated ports are chosen based on the lowest root path cost to the root bridge. If a neighboring switch on a shared LAN segment sends a BPDU announcing a lower root path cost, the neighbor must have the designated port.

If a switch learns only of higher root path costs from other BPDUs received on a port, however, it then correctly assumes that its own receiving port is the designated port for the segment.

The entire STP determination process has served only to identify bridges and ports. All ports are still active, and bridging loops still might occur. STP has a set of progressive states that each port must go through, regardless of the type or identification. These states actively prevent loops from forming.

All tie-breaking STP decisions are based on the following sequence of conditions:

  1. Lowest root bridge ID
  2. Lowest root path cost to root bridge
  3. Lowest sender bridge ID
  4. Lowest sender port ID


STP Port Functions During the Several States

STP States and Port Activity







The following shows a port going through the different STP states and roles, from Blocking to Designated / Forwarding.

SW1(config)# interface gigabitethernet1/0/1
SW1(config-if)# no shutdown
SW1(config-if)# end
Mar 30 08:12:11.199: STP SW: Gi1/0/1 new blocking req for 1 vlans
Mar 30 08:12:13.196: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state
to up
Mar 30 08:12:14.203: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/1, changed state to up
SW1# show spanning interface gigabitethernet1/0/1
Vlan     Role  Sts   Cost   Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0001 Desg  LIS   4      128.1    P2p
Mar 30 08:12:26.207: STP SW: Gi1/0/1 new learning req for 1 vlans
SW1# show spanning interface gigabitethernet1/0/1
Vlan     Role  Sts   Cost   Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0001 Desg  LRN   4      128.1    P2p
Mar 30 08:12:41.214: STP SW: Gi1/0/1 new forwarding req for 1 vlans
SW1# show spanning interface gigabitethernet1/0/1
Vlan     Role  Sts   Cost   Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0001 Desg  FWD   4      128.1    P2p


It begins as the port is administratively disabled. When the port is enabled, successive show spanning-tree interface type member/module/number commands display the port state as Listening, Learning, and then Forwarding.

Note: the time stamps and port states provided by the debug command, which give a sense of the timing between port states. Because this port was eligible as a root port, the show command never could execute fast enough to show the port in the Blocking state.


Spanning-Tree Timers

STP operates as switches send BPDUs to each other in an effort to form a loop-free topology. The BPDUs take a finite amount of time to travel from switch to switch. News of a topology change (a link or root bridge failure) can suffer from propagation delays as the announcement travels from one side of a network to the other.

Because of the possibility of these delays, keeping the spanning-tree topology from settling out or converging until all switches have had time to receive accurate information is crucial.

STP uses three timers to make sure that a network converges properly before a bridging loop can form:

  • Hello timer – 2 Seconds: Time interval between Configuration BPDUs sent by the root bridge. The hello time value configured in the root bridge switch determines the hello time for all non-root switches because they just relay the Configuration BPDUs as they are received from the root. All switches have a locally configured hello time that is used to time TCN BPDUs when they are retransmitted.
  • Forward Delay timer – 15 Seconds: Time interval that a switch port spends in both the Listening and Learning states.
  • Max Age timer – 20 Seconds: Time interval that a switch stores a BPDU before discarding it. Each switch port keeps a copy of the “best” BPDU that it has heard. If no more BPDUs are received, the switch assumes that a topology change must have occurred after the Max Age Time elapsed and so the BPDU is aged out.


STP timers can be configured or adjusted from the switch command line. However, the timer values never should be changed from the defaults without careful consideration.

Then the values should be changed only on the root bridge switch. Recall that the timer values are advertised in fields within the BPDU. The root bridge ensures that the timer values propagate to all other switches.


Note: Default STP timer values are based on some assumptions about the size of the network and the length of the hello time. A reference model of a network having a diameter of seven switches derives these values.

The diameter is measured from the root bridge switch outward, including the root bridge. In other words, if you draw the STP topology, the diameter is the number of switches connected in series from the root bridge out to the end of any branch in the tree.

The hello time is based on the time it takes for a BPDU to travel from the root bridge to a point seven switches away. This computation uses a hello time of 2 seconds.

Note:  Cisco also recommends that if changes need to be made, only the network diameter value should be modified on the root bridge switch.



Spanning-Tree Address Management

802.1D specifies 17 multicast addresses, ranging from 0x00180C2000000 to 0x0180C2000010, to be used by different bridge protocols. These addresses are static addresses that cannot be removed.

Regardless of the spanning-tree state, each switch in the stack receives but does not forward packets destined for addresses between 0x0180C2000000 and 0x0180C200000F.

If spanning tree is enabled, the CPU on the switch or on each switch in the stack receives packets destined for 0x0180C2000000 and 0x0180C2000010.

Note: If spanning tree is disabled, the switch or each switch in the stack forwards those packets as unknown multicast addresses.


Topology Changes

To announce a change in the network topology, switches send a TCN BPDUs. Bellow is the TCN BPDU message format.






A topology change occurs when a switch either moves a port into the Forwarding state or moves a port from the Forwarding or Learning states into the Blocking state.

A port on an active switch comes up or goes down. The switch sends a TCN BPDU out its root port so that the root bridge receives news of the topology change. Notice that the TCN BPDU carries no data about the change but informs recipients only that a change has occurred.

Note: switch will not send TCN BPDUs if the port has been configured with PortFast enabled.

The switch continues sending TCN BPDUs every hello time interval until it gets an acknowledgment from its upstream neighbor. The upstream neighbors receive the TCN BPDU, they propagate it on toward the root bridge and send their own acknowledgments.

When the root bridge receives the TCN BPDU, it also sends out an acknowledgment. But the root bridge sets the Topology Change flag in its Configuration BPDU, which is relayed to every other switch. This is done to signal the topology change and cause all other bridges to shorten their bridge table aging times from the default 300 seconds to the forward delay value default 15 seconds.


Direct Topology Changes

A direct topology change is one that can be detected on a switch interface. If a trunk link suddenly goes down, the switch on each end of the link can immediately detect a link failure. The absence of that link changes the topology, so other switches should be notified.


STP Types

STP was originally developed to operate in a bridged environment, basically supporting a single LAN (or one VLAN). Implementing STP into a switched environment has required additional consideration and modification to support multiple VLANs.


Common Spanning Tree (CST)

802.1Q standard specifies how VLANs are to be trunked between switches. It also specifies only a single instance of STP that encompasses all VLANs. This instance is called Common Spanning Tree (CST). All CST BPDUs are transmitted over trunk links using the native VLAN with untagged frames.

Having a single STP for many VLANs simplifies switch configuration and reduces switch CPU load during STP calculations. Having only one STP instance can cause limitations, too. Redundant links between switches will be blocked with no capability for load balancing. Conditions also can occur that would cause CST to mistakenly enable forwarding on a link that does not carry a specific VLAN, and other links would be blocked.


Per-VLAN Spanning Tree – PVST (Cisco Proprietary)

Per-VLAN Spanning Tree (PVST) operates a separate instance of STP for each individual VLAN. This allows the STP on each VLAN to be configured independently, offering better performance and tuning for specific conditions. Multiple spanning trees also make load balancing possible over redundant links when the links are assigned to different VLANs. One link might forward one set of VLANs, while another redundant link might forward a different set.

Note: PVST requires the use of Cisco ISL trunking encapsulation. In networks where PVST and CST coexist, interoperability problems occur. Each requires a different trunking method, so BPDUs are never exchanged between STP types.


Per-VLAN Spanning Tree Plus – PVST+ (Cisco Proprietary)

Allows devices to interoperate with both PVST and CST. PVST+ effectively supports three groups of STP operating in the same campus network:

  • CST – 1 instance of STP, over the native VLAN (802.1Q based)
  • PVST – 1 instance of STP per VLAN (Cisco ISL based)
  • PVST+ – Provides interoperability between CST and PVST (both 802.1Q and ISL)

PVST+ acts as a translator between groups of CST switches and groups of PVST switches. PVST+ can communicate directly with PVST by using ISL trunks. To communicate with CST, PVST+ exchanges BPDUs with CST as untagged frames over the native VLAN.

BPDUs from other instances of STP (other VLANs) are propagated across the CST portions of the network by tunneling. PVST+ sends these BPDUs by using a unique multicast address so that the CST switches forward them on to downstream neighbors without interpreting them first.

Based on the 802.1D standard and Cisco proprietary extensions. It is the default spanning-tree mode used on all Ethernet port-based VLANs. The PVST+ runs on each VLAN on the switch up to the maximum supported, ensuring that each has a loop-free path through the network.

Provides Layer 2 load-balancing for the VLAN on which it runs. You can create different logical topologies by using the VLANs on your network to ensure that all of your links are used but that no link is oversubscribed.

Each instance of PVST+ on a VLAN has a single root switch. This root switch propagates the spanning-tree information associated with that VLAN to all other switches in the network.


Rapid PVST+ (802.1w based)

Its the same as PVST+ except that is uses a rapid convergence. To provide rapid convergence, the rapid PVST+ immediately deletes dynamically learned MAC address entries on a per-port basis upon receiving a topology change.

The rapid PVST+ uses the same configuration as PVST+ (except where noted), and the switch needs only minimal extra configuration. The benefit of rapid PVST+ is that you can migrate a large PVST+ install base to rapid PVST+ without having to learn the complexities of the MSTP configuration and without having to reprovision your network. Each VLAN runs its own spanning-tree instance up to the maximum supported.


Multiple Spanning-Tree (MSTP – 802.1s)

You can map multiple VLANs to the same spanning-tree instance, which reduces the number of spanning-tree instances required to support a large number of VLANs. The MSTP runs on top of the RSTP (based on IEEE 802.1w), which provides for rapid convergence of the spanning tree by eliminating the forward delay and by quickly transitioning root ports and designated ports to the forwarding state.

Note: In a switch stack, the cross-stack rapid transition (CSRT) feature performs the same function as RSTP. You cannot run MSTP without RSTP or CSRT.

The most common deployment of MSTP is in the backbone and distribution layers of a Layer 2 switched network.


STP and 802.1Q Trunks

802.1Q standard for VLAN trunks imposes some limitations on the spanning-tree strategy for a network. It requires only one spanning-tree instance for all VLANs allowed on the trunks. In a network of Cisco switches connected through IEEE 802.1Q trunks, the switches maintain one spanning-tree instance for each VLAN allowed on the trunks.

When you connect a Cisco switch to a non-Cisco device through an 802.1Q trunk, the Cisco switch uses PVST+ to provide spanning-tree interoperability.

If rapid PVST+ is enabled, the switch uses it instead of PVST+. It combines the spanning-tree instance of the 802.1Q VLAN of the trunk with the spanning-tree instance of the non-Cisco 802.1Q switch.

All PVST+ or rapid-PVST+ information is maintained by Cisco switches separated by a cloud of non-Cisco 802.1Q switches. The non-Cisco 802.1Q cloud separating the Cisco switches is treated as a single trunk link between the switches.

PVST+ is automatically enabled on 802.1Q trunks, and no user configuration is required. The external spanning-tree behavior on access ports and ISL trunk ports is not affected by PVST+.


Default Spanning-Tree Configuration

Bellow is the default spanning-tree configuration.

STP defaults









Spanning-Tree Basic Configuration

Configuring a spanning-tree Mode. (All stack members run the same version of spanning-tree).

  • Select pvst to enable PVST+ (the default setting).
  • Select mst to enable MSTP (and RSTP). For more configuration steps, see “Configuring MSTP.”
  • Select rapid-pvst to enable rapid PVST+.


DSW1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
DSW1(config)# spanning-tree mode ?
 mst        Multiple spanning tree mode
 pvst       Per-Vlan spanning tree mode
 rapid-pvst Per-Vlan rapid spanning tree mode


Interface ID

(Recommended for rapid-PVST+ mode only) Specify an interface to configure, and enter interface configuration mode. Valid interfaces include physical ports, VLANs, and port channels. The VLAN ID range is 1 to 4094. The port-channel range is 1 to 48.

DSW1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
DSW1(config)# interface po1
DSW1(config-if)# spanning-tree ?
 bpdufilter    Don't send or receive BPDUs on this interface
 bpduguard     Don't accept BPDUs on this interface
 cost          Change an interface's spanning tree port path cost
 guard         Change an interface's spanning tree guard mode
 link-type     Specify a link type for spanning tree protocol use
 mst           Multiple spanning tree
 port-priority Change an interface's spanning tree port priority
 portfast      Enable an interface to move directly to forwarding on link up
 vlan          VLAN Switch Spanning Tree


Link Type

(Recommended for rapid-PVST+ mode only) Specify that the link type for this port is point-to-point. If you connect this port (local port) to a remote port through a point-to-point link and the local port becomes a designated port, the switch negotiates with the remote port and rapidly changes the local port to the forwarding state.

DSW1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
DSW1(config)# interface po1
DSW1(config-if)# spanning-tree link-type ?
 point-to-point    Consider the interface as point-to-point
 shared Consider   the interface as shared


Clear Detected Protocols

Recommended for rapid-PVST+ mode only. If any port on the switch is connected to a port on a legacy 802.1D switch, restart the protocol migration process on the entire switch. This step is optional if the designated switch detects that this switch is running rapid PVST+.

DSW1# clear spanning-tree ?
 counters Clear spanning tree statistics
 detected-protocols Restart the protocol migration process



DSW1# show spanning-tree summary
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
Configured Pathcost method used is short
Name      Blocking     Listening Learning   Forwarding  STP Active
---------------------- -------- --------- --------     ----------------
VLAN0001     0             0        0        16         16
---------------------- -------- --------- --------     ----------------
1 vlan       0             0        0        16         16

DSW1# show spanning-tree interface e0/0
Vlan                     Role     Sts       Cost      Prio.Nbr    Type
------------------- ----      ---   --------- -------- --------------------------------
VLAN0001        Desg     FWD      100          128.1         Shr


Configuring the Root Switch

The switch maintains a separate spanning-tree instance for each active VLAN configured on it.

A bridge ID, consisting of the switch priority and the switch MAC address, is associated with each instance. For each VLAN, the switch with the lowest bridge ID becomes the root switch for that VLAN.

To configure a switch to become the root for the specified VLAN, use the spanning-tree vlan vlan-id root global configuration command to modify the switch priority from the default value (32768) to a significantly lower value. Because of the extended system ID support, the switch sets its own priority for the specified VLAN to 24576 if this value will cause this switch to become the root for the specified VLAN.

Configure a switch to become the root for the specified VLAN.

  • For vlan-id, you can specify a single VLAN identified by VLAN ID number, a range of VLANs separated by a hyphen, or a series of VLANs separated by a comma. The range is 1 to 4094.
DSW1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
DSW1(config)# spanning-tree vlan 1 root primary
DSW1(config)# end
*Dec 14 11:23:01.911: %SYS-5-CONFIG_I: Configured from console by console
DSW1# show spanning-tree vlan 1
 Spanning tree enabled protocol ieee
 Root ID Priority 24577
 Address aabb.cc00.0100
 This bridge is the root
 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Note: If any root switch for the specified VLAN has a switch priority lower than 24576, the switch sets its own priority for the specified VLAN to 4096 less than the lowest switch priority. (4096 is the value of the least-significant bit of a 4-bit switch priority value)


For diameter, specify the maximum number of switches (2 – 7) between any two end stations. For hello-time seconds, specify the interval in seconds (1 – 10) between the generation of configuration messages by the root switch.

DSW1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
DSW1(config)# spanning-tree vlan 1 root primary diameter ?
 <2-7> Maximum number of bridges between any two end nodes
DSW1(config)# spanning-tree vlan 1 root primary diameter 4 hello-time ?
 <1-10> Hello interval in seconds


Configuring a Secondary Root Switch

The secondary root switch priority is modified from the default value (32768) to 28672. The switch is then likely to become the root switch for the specified VLAN if the primary root switch fails. This is assuming that the other network switches use the default switch priority of 32768.

You can execute this command on more than one switch to configure multiple backup root switches. Use the same network diameter and hello-time values that you used when you configured the primary root switch.

DSW2(config)# spanning-tree vlan 1 root secondary diameter 4 hello-time 2
DSW2(config)# end
*Dec 14 11:37:38.359: %SYS-5-CONFIG_I: Configured from console by console
DSW2# show spanning-tree detail

VLAN0001 is executing the ieee compatible Spanning Tree protocol
 Bridge Identifier has priority 28672, sysid 1, address aabb.cc00.0300
 Configured hello time 2, max age 14, forward delay 10
 Current root has priority 24577, address aabb.cc00.0100
 Root port is 1 (Ethernet0/0), cost of root path is 100
 Topology change flag not set, detected flag not set
 Number of topology changes 11 last change occurred 00:01:39 ago
 Times: hold 1, topology change 24, notification 2
 hello 2, max age 14, forward delay 10 
 Timers: hello 0, topology change 0, notification 0, aging 300


Configuring Port Priority

If a loop occurs, spanning tree uses the port priority when selecting an interface to put into the forwarding state. You can assign lower priority values (lower is better) to interfaces that you want selected first and lower priority values (higher values) that you want selected last.

If all interfaces have the same priority value, spanning tree puts the interface with the lowest interface number in the forwarding state and blocks the other interfaces.

Note: If a member of a switch stack, you must use the spanning-tree [vlan vlan-id] cost command instead of the spanning-tree [vlan vlan-id] port-priority command.


For priority, the range is 0 to 240, in increments of 16. The default is 128.

Valid values are 0, 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224, and 240. All other values are rejected. (The lower the number, the higher the priority).

DSW2# conf t
Enter configuration commands, one per line. End with CNTL/Z.
DSW2(config)# interface e0/1
DSW2(config-if)# spanning-tree port-priority 64
DSW2(config-if)# end


Configure the Switch Priority for a VLAN.

For vlan-id, you can specify a single VLAN identified by VLAN ID number, a range of VLANs separated by a hyphen, or a series of VLANs separated by a comma. The range is 1 to 4094. Priority values same as above.

DSW2(config)# spanning-tree vlan 1 priority 32769
DSW2# show spanning-tree interface e0/1
Vlan                Role   Sts    Cost        Prio.Nbr    Type
------------------- ----   ---    -------      --------   ------------
VLAN0001            Altn   BLK     100          64.2       Shr

DSW2# show spanning-tree vlan 1

 Spanning tree enabled protocol ieee
 Root ID Priority 24577
 Address aabb.cc00.0100
 Cost 100
 Port 1 (Ethernet0/0)
 Hello Time 2 sec Max Age 14 sec Forward Delay 10 sec

Bridge ID Priority 32769 (priority 32769 sys-id-ext 1)
 Address aabb.cc00.0300
 Hello Time 2 sec Max Age 14 sec Forward Delay 10 sec
 Aging Time 300 sec

Interface              Role     Sts        Cost      Prio.       Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et0/0                   Root   FWD     100       128.1         Shr 
Et0/1                   Altn   BLK     100       64.2          Shr 
Et0/2                   Desg   FWD     100       128.3         Shr


Configuring Path Cost

Path cost default value is the result of an interface speed. If a loop occurs, spanning tree uses cost when selecting an interface to put in the forwarding state. You can assign lower cost values to interfaces that you want selected first and higher cost values that you want selected last.

If all interfaces have the same cost value, spanning tree puts the interface with the lowest interface number in the forwarding state and blocks the other interfaces.

For cost, the range is 1 to 200.000.000, the default value is derived from the speed of the interface.

SW1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)# interface port-channel 1
SW1(config-if)# spanning-tree cost 16
SW1(config-if)# do show spanning-tree interface po1

Vlan Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0001 Root FWD 16 128.65 Shr Peer(STP) 
VLAN0002 Desg FWD 16 128.65 Shr Peer(STP) 
VLAN0003 Root FWD 16 128.65 Shr Peer(STP) 
VLAN0004 Desg FWD 16 128.65 Shr Peer(STP) 
VLAN0005 Root FWD 16 128.65 Shr Peer(STP) 
VLAN0006 Desg FWD 16 128.65 Shr Peer(STP) 
VLAN0007 Root FWD 16 128.65 Shr Peer(STP) 
VLAN0008 Desg FWD 16 128.65 Shr Peer(STP) 
VLAN0009 Root FWD 16 128.65 Shr Peer(STP) 
VLAN0010 Desg FWD 16 128.65 Shr Peer(STP)


Tunning Root Path Cost.

Before modifying a switch port’s path cost, you should always calculate the root path costs of other alternative paths through the network.

Changing one port’s cost might influence STP to choose that port as a root port, but other paths still could be preferred. You also should calculate a port’s existing path cost to determine what the new cost value should be. Careful calculation will ensure that the desired path indeed will be chosen.

Remember to keep a table of the cost values if you don’t want to memorize them.

Stp Rstp Link Cost








You can specify a single VLAN identified by VLAN number, a range of VLANs separated by a hyphen, or a series of VLANs separated by a comma. The range is 1 to 4094. For cost, the range is 1 to 200.000.000, the default value is derived from the speed of the interface.

SW1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config-if)# interface port-channel 1
SW1(config-if)# spanning-tree vlan 10 cost 9
SW1(config-if)# end
*Dec 14 16:48:15.058: %SYS-5-CONFIG_I: Configured from console by console
SW1# show spanning-tree vlan 10

 Spanning tree enabled protocol rstp
 Root ID Priority 24586
 Address aabb.cc00.0300
 This bridge is the root
 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

 Bridge ID Priority 24586 (priority 24576 sys-id-ext 10)
 Address aabb.cc00.0300
 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
 Aging Time 300 sec

Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et0/2 Desg FWD 100 128.3 Shr 
Et0/3 Desg FWD 100 128.4 Shr 
Po1 Desg FWD 9 128.65 Shr Peer(STP)

SW1# show spanning-tree interface port-channel 1

Vlan Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0001 Root FWD 16 128.65 Shr Peer(STP) 
VLAN0002 Desg FWD 16 128.65 Shr Peer(STP) 
VLAN0003 Root FWD 16 128.65 Shr Peer(STP) 
VLAN0004 Desg FWD 16 128.65 Shr Peer(STP) 
VLAN0005 Root FWD 16 128.65 Shr Peer(STP) 
VLAN0006 Desg FWD 16 128.65 Shr Peer(STP) 
VLAN0007 Root FWD 16 128.65 Shr Peer(STP) 
VLAN0008 Desg FWD 16 128.65 Shr Peer(STP) 
VLAN0009 Root FWD 16 128.65 Shr Peer(STP) 
VLAN0010 Desg FWD 9 128.65 Shr Peer(STP) 
VLAN0011 Root FWD 16 128.65 Shr Peer(STP) 
VLAN0012 Root FWD 16 128.65 Shr Peer(STP)


Tuning the Port ID

Another STP decision is the port ID. The port ID value that a switch uses is actually a 16-bit quantity – 8 bits for the port priority  and 8 bits for the port number. The port priority is a value from 0 to 255 and defaults to 128 for all ports.

The port number can range from 0 to 255 and represents the port’s actual physical mapping. Port numbers generally begin with 1 at port 1/0/1 and increment across each module, then across each stack member or slot. The numbers might not be completely intuitive or consecutive because each member or module is assigned a particular range of numbers. In addition, ports that are bundled into an EtherChannel or port channel interface always have a higher port ID than they would if they were not bundled.

Note:  Port numbers are usually intuitive on a single fixed configuration switch. STP port number can simply be the interface number, from 1 to 48. However, it is not easy to find the STP port number in a switch with many modules and many ports.

Notice how Gigabit Ethernet 1/0/1 is known as port number 1 (shown as Prio.Nbr 128.1), whereas 2/0/44 is known as port number 102:

Switch# show spanning-tree interface gi1/0/1
Vlan Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- ----------------
VLAN0100 Desg FWD 4 128.1 P2p Edge

Switch# show spanning-tree interface gi2/0/44
Vlan Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- ----------------
VLAN0100 Desg FWD 4 128.102 P2p Edge

Obviously, a port number is fixed because it is based only on its hardware location. The port ID, however, can be modified to influence an STP decision by using the port priority.


Configure Port Priority as follows:

Switch(config-if)# spanning-tree [vlan vlan-list] port-priority port-priority

You can modify the port priority for one or more VLANs by using the vlan parameter. The VLAN numbers are given as vlan-list, a list of single values or ranges of values separated by commas. Otherwise, the port priority is set for the port as a whole (all active VLANs).

Port-Priority Value0 – 255 (defaults 128).

Configure the port priority of Gigabit Ethernet 2/0/44 from 128 (the default) to 64 for VLANs 10 and 100:

Switch(config)# interface gigabitethernet 2/0/44
Switch(config-if)# spanning-tree vlan 10,100 port-priority 64
Switch(config-if)# end
Switch# show spanning-tree interface gigabitEthernet 2/0/44
Vlan Role Sts Cost Prio.Nbr Type
----------------- ---- --- --------- -------- -----------------------------
VLAN0010 Desg FWD 4 64.102 Edge P2p
VLAN0100 Desg FWD 4 64.102 Edge P2p
VLAN0200 Desg FWD 4 128.102 Edge P2p


Tuning Spanning-Tree Convergence

For the majority of cases, the default STP operation is sufficient to keep the network loop free and enable users to communicate. However, in certain situations, the default STP can cause network access to be delayed while timers expire and while preventing loops on links where loops are not possible.

When a single PC is connected to a switch port, a bridging loop is simply not possible. Another situation relates to the size of a Layer 2 switched network. In a network that is smaller, waiting until the default timer values expire might not make sense when they could be safely set to shorter values. You can safely make adjustments to the STP convergence process for more efficiency.


Modifying STP Timers

As a recap, STP uses three timers to keep track of various port operation states between bridges. Also the timers need to be modified only on the root bridge because the root bridge propagates all three timer values throughout the network as fields in the configuration BPDU.



Manually Configuring STP Timers

On the root switch modify STP timers with the bellow commands:

Switch(config)# spanning-tree [vlan vlan-id] hello-time seconds
Switch(config)# spanning-tree [vlan vlan-id] forward-time seconds
Switch(config)# spanning-tree [vlan vlan-id] max-age seconds


Note: Notice that the timers can be changed for a single VLAN on the switch by using the vlan vlan-id parameters. If you omit the vlan keyword, the timer values are configured for all instances (all VLANs) of STP on the switch.

The Hello timer triggers periodic “hello” (actually, the configuration BPDU) messages that are sent from the root to other bridges in the network.


Automatically Configuring STP Timers

Modifying STP timers can be tricky, given the calculations needed to derive proper STP operation. They are dependent on the Hello Time and the switched network’s diameter. Catalyst switches offer a single command that can change the timer values in a more controlled fashion. As described a few sections above.

The macro command is a better tool to use than with the individual commands

Switch(config)# spanning-tree vlan vlan-list root {primary | secondary} [diameter diameter [hello-time hello-time]]

STP timers will be adjusted as specified in the 802.1D standard by giving only the network’s diameter and an optional hello-time. If you do not specify a hello time, the default value of 2 seconds is assumed.  This command can be used only on a per-VLAN basis to modify the timers for a particular VLAN’s spanning tree instance.

Because this command makes a switch become the root bridge, all the modified timer values resulting from this command will be propagated to other switches through the configuration BPDU.


Verify the STP Timer Values in Use

 Switch# show spanning-tree vlan 100
Spanning tree enabled protocol ieee
Root ID Priority 100
Address 000c.8554.9a80
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 100 (priority 0 sys-id-ext 100)
Address 000c.8554.9a80
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
[output omitted]


Consider that the longest path that a packet can take through a sample network is three switches. This is considerably less than the reference diameter of seven that is used to calculate the default timer values. Therefore, you can safely assume that this network diameter is three, provided that no additional switches will be added to lengthen the longest path. Suppose that a hello time of 1 second is also desired, to shorten the time needed to detect a dead neighbor. The following command attempts to make the local switch become the root bridge and automatically adjusts the STP timers:

Switch(config)# spanning-tree vlan 100 root primary diameter 3 hello-time 1


Verify the new configuration

Switch# show spanning-tree vlan 100
Spanning tree enabled protocol ieee
Root ID Priority 100
Address 000c.8554.9a80
This bridge is the root
Hello Time 1 sec Max Age 7 sec Forward Delay 5 sec
Bridge ID Priority 100 (priority 0 sys-id-ext 100)
Address 000c.8554.9a80
Hello Time 1 sec Max Age 7 sec Forward Delay 5 sec
Aging Time 300


Redundant Link Convergence

Some additional methods allow faster STP convergence if a link failure occurs:

  • PortFast: Enables fast connectivity to be established on access layer switch ports to workstations that are booting.
  • UplinkFast: Enables fast-uplink failover on an access layer switch when dual uplinks are connected into the distribution layer.
  • BackboneFast: Enables fast convergence in the network backbone or core layer switches after a spanning-tree topology change occurs.


Instead of modifying timer values, these methods work by controlling convergence on specifically located ports within the network hierarchy.

STP has been enhanced to allow almost instantaneous topology changes instead of having to rely on Cisco-proprietary extensions. This enhancement is known as the Rapid Spanning Tree Protocol (802.1w).


PortFast: Access Layer Nodes

End-user workstation is usually connected to a switch port in the access layer. If the workstation is powered off and then turned on, the switch will sense that the port link status has gone down and back up.

The port will not be in a usable state until STP cycles from the Blocking state to the Forwarding state. With the default STP timers, this transition takes at least 30 seconds (15 seconds for Listening to Learning, and 15 seconds for Learning to Forwarding).

Therefore, the workstation cannot transmit or receive any useful data until the Forwarding state finally is reached on the port.

Note: If a switch port is running PAgP to negotiate EtherChannel configuration, an additional 20-second delay can occur (30+20=50 sec).

The PortFast feature shortens the Listening and Learning states to a negligible amount of time. When a workstation link comes up, the switch immediately moves the PortFast port into the Forwarding state. Spanning-tree loop detection is still in operation, however, the port moves into the Blocking state if a loop is ever detected on the port.

You can configure PortFast globally, affecting all switch ports with a single command. All ports that are configured for access mode (nontrunking) will have PortFast automatically enabled. You can use the following global configuration command to enable PortFast as the default:

Switch(config)# spanning-tree portfast default


Enable or disable PortFast feature on specific switch ports:

Switch(config-if)# [no] spanning-tree portfast


Another benefit of PortFast is that TCN BPDUs are not sent when a port in PortFast mode goes up or down. This simplifies the TCN transmission on a large network when end-user workstations are coming up or shutting down.

SW1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)# interface e1/0
SW1(config-if)# switchport host
switchport mode will be set to access
spanning-tree portfast will be enabled
channel group will be disabled


Verify PortFast status of an interface

SW1# show spanning-tree interface e1/0 portfast
VLAN0005 enabled


UplinkFast: Access Layer Uplinks

Consider an access layer switch that has redundant uplink connections to two distribution layer switches. Normally, one uplink would be in the Forwarding state and the other would be in the Blocking state.

If the primary uplink went down, up to 50 seconds could elapse before the redundant uplink could be used. The UplinkFast feature enables leaf-node switches or switches at the ends of the spanning-tree branches to have a functioning root port while keeping one or more redundant or potential root ports in Blocking mode. When the primary root port uplink fails, another blocked uplink immediately can be brought up for use.

Tip Many Catalyst switches have two built-in, high-speed uplink ports (Gigabit Ethernet, for example). UplinkFast keeps a record of all parallel paths to the root bridge. All uplink ports but one are kept in the Blocking state. If the root port fails, the uplink with the next-lowest root path cost is unblocked and used without delay.


To enable the UplinkFast

When enabled, it is enabled for the entire switch and all VLANs. UplinkFast works by keeping track of possible paths to the root bridge. Therefore, the command is not allowed on the root bridge switch.

Switch(config)# spanning-tree uplinkfast [max-update-rate pkts-per-second]


It also makes modifications to the local switch to ensure that it does not become the root bridge and that the switch is not used as a transit switch to get to the root bridge. The goal is to keep UplinkFast limited to leaf-node switches that are farthest from the root.

The bridge priority is raised to 49,152, making sure that the switch will NOT be elected to root bridge status. The port cost of all local switch ports is incremented by 3000, making the ports undesirable as paths to the root for any downstream switches.

The command includes a max-update-rate parameter. When an uplink on a switch goes down, UplinkFast makes it easy for the local switch to update its MAC addresse table to point to the new uplink. UplinkFast also provides a mechanism for the local switch to notify other upstream switches that downstream stations (access layer) can be reached over the newly activated uplink.

It accomplishes this by sending dummy multicast frames to destination 0100.0ccd.cdcd on behalf of the stations contained in its CAM table.

The MAC addresses are used as the source in the dummy frames, as if the stations actually had sent them. The idea is to quickly send the multicast frames over the new uplink, giving upstream hosts a chance to receive the frames and learn of the new path to those source addresses.

These multicast frames are sent out at a rate specified by the max-update-rate parameter in packets per second. This limits the amount of bandwidth used for the dummy multicasts if the CAM table is quite large.

Default is 150 packets per second (pps), but the rate can range from 0 to 65,535 pps. If the value is 0, no dummy multicasts are sent.


Verify the current status of STP UplinkFast

Switch# show spanning-tree uplinkfast
UplinkFast is enabled
Station update rate set to 150 packets/sec.
UplinkFast statistics
Number of transitions via UplinkFast (all VLANs) : 2
Number of proxy multicast addresses transmitted (all VLANs) : 52
Name Interface List
--------------------- --------------------------------
VLAN0001 Gi1/0/1(fwd)
VLAN0010 Gi1/0/1(fwd)
VLAN0100 Gi1/0/1(fwd)


BackboneFast: Redundant Backbone Paths

In the backbone, (core layer), a different method is used to shorten STP convergence. BackboneFast works by having a switch actively determine whether alternative paths exist to the root bridge, in case the switch detects an indirect link failure.

Note: Indirect link failures occur when a link that is not directly connected to a switch fails.

A switch detects an indirect link failure when it receives inferior BPDUs from its designated bridge on either its root port or a blocked port. (Inferior BPDUs are sent from designated bridge that has lost its connection to the root bridge, making it announce itself as the new root.)

A switch must wait for the Max Age timer to expire before responding to the inferior BPDUs. BackboneFast begins to determine whether other alternative paths to the root bridge exist according to the following port types that received the inferior BPDU:

1- If the inferior BPDU arrives on a port in the Blocking state, the switch considers the root port and all other blocked ports to be alternative paths to the root bridge.

2- If the inferior BPDU arrives on the root port itself, the switch considers all blocked ports to be alternative paths to the root bridge.

3- If the inferior BPDU arrives on the root port and no ports are blocked, the switch assumes that it has lost connectivity with the root bridge. In this case, the switch assumes that it has become the root bridge, and BackboneFast allows it to do so before the Max Age timer expires.

If the local switch has blocked ports, BackboneFast begins to use the Root Link Query (RLQ) protocol to see whether upstream switches have stable connections to the root bridge.

First, RLQ Requests are sent out. If a switch receives an RLQ Request and either is the root bridge or has lost connection to the root, it sends an RLQ Reply. Otherwise, the RLQ Request is propagated on to other switches until an RLQ Reply can be  generated. On the local switch, if an RLQ Reply is received on its current root port, the path to the root bridge is intact and stable. If it is received on a nonroot port, an alternative root path must be chosen. The Max Age timer immediately is expired so that a new root port can be found.

BackboneFast operates by short-circuiting the Max Age timer when needed. Although this function shortens the time a switch waits to detect a root path failure, ports still must go through full-length Forward Delay timer intervals during the Listening and Learning states.

Note: Where PortFast and UplinkFast enable immediate transitions, BackboneFast can reduce the maximum convergence delay only from 50 to 30



Configure BackboneFast

Switch(config)# spanning-tree backbonefast


Verify the current BackboneFast state

Switch# show spanning-tree backbonefast
BackboneFast is enabled


Note:  BackboneFast should be enabled on all switches in the network because BackboneFast requires the use of the RLQ Request and Reply mechanism to inform switches of Root Path stability. The RLQ protocol is active only when BackboneFast is enabled on a switch. BackboneFast is disabled by default.


Protecting Against Unexpected BPDUs


Root Guard

After an STP topology has converged and becomes loop free, switch ports are assigned the following roles:

  • Root port: The one port on a switch that is closest (with the lowest root path cost) to the root bridge.
  • Designated port: The port on a LAN segment that is closest to the root. This port relays, or transmits, BPDUs down the tree.
  • Blocking port: Ports that are neither root nor designated ports.
  • Alternate port: Ports that are candidate root ports (they are also close to the root bridge) but are in the Blocking state. These ports are identified for quick use by the UplinkFast feature.
  • Forwarding port: Ports where no other STP activity is detected or expected. These are ports with normal end-user connections.


The root bridge is always expected to be seen on the root port and the alternative ports because they have the best-cost path to it.

Root Guard is a means to control where candidate root bridges can be connected and found on a network. It learns the current root bridge’s bridge ID. If another switch advertises a superior BPDU, or one with a better bridge ID, on a port where Root Guard is enabled, the local switch will not allow the new switch to become the root.

As long as the superior BPDUs are being received on the port, the port will be kept in the root-inconsistent STP state. No data can be sent or received in that state, but the switch can listen to BPDUs received on the port to detect a new root advertising itself.

Root Guard designates that a port can only forward or relay BPDUs, not receive BPDUs. Root Guard prevents the port from ever becoming a root port where BPDUs normally would be received from the root bridge.

Enable Root Guard only on a per-port basis. (disabled on all switch ports by default).

Switch(config-if)# spanning-tree guard root


Verify switch ports that Root Guard has put into the root-inconsistent state:

Switch# show spanning-tree inconsistentports


BPDU Guard

BPDU Guard further protects the integrity of switch ports that have PortFast enabled. If any BPDU (whether superior to the current root or not) is received on a port where BPDU Guard is enabled, that port immediately is put into the errdisable state. The port is shut down in an error condition and must be either manually reenabled or automatically recovered through the errdisable timeout function.

BPDU Guard is disabled by default on all switch ports. You can configure BPDU Guard as a global default, affecting all switch ports with a single command. All ports that have PortFast enabled also have BPDU Guard automatically enabled.


Enable BPDU Guard as the default

Switch(config)# spanning-tree portfast bpduguard default


Enable or disable BPDU Guard on a per-port basis

Switch(config-if)# [no] spanning-tree bpduguard enable


You should use BPDU Guard on all switch ports where STP PortFast is enabled. This prevents any possibility that a switch will be added to the port, either intentionally or by mistake. An obvious application for BPDU Guard is on access layer switch ports where end devices connect. BPDUs normally would not be expected there and would be detected if a switch or hub inadvertently were connected.

Note:  You should never enable BPDU Guard on any switch uplink where the root bridge is located. If a switch has multiple uplinks, any of those ports could receive legitimate BPDUs from the root.


Protecting Against Sudden Loss of BPDUs

Cisco has added two STP features that help detect or prevent the unexpected loss of BPDUs:

  • Loop Guard
  • Unidirectional Link Detection (UDLD)


Loop Guard

When enabled, Loop Guard keeps track of the BPDU activity on nondesignated ports. While BPDUs are received, the port is allowed to behave normally. When BPDUs go missing, Loop Guard moves the port into the loop-inconsistent state. The port is effectively blocking at this point to prevent a loop from forming and to keep it in the nondesignated role.

When BPDUs are received on the port again, Loop Guard allows the port to move through the normal STP states and become active. Loop Guard automatically governs ports without the need for manual intervention. Loop Guard is disabled by default on all ports.

Enable Loop Guard as a global default, affecting all switch ports

Switch(config)# spanning-tree loopguard default


Enable or disable Loop Guard on a specific switch port

Switch(config-if)# [no] spanning-tree guard loop


Although Loop Guard is configured on a switch port, its corrective blocking action is taken on a per-VLAN basis. In other words, Loop Guard does not block the entire port, only the offending VLANs are blocked.

Note: You can enable Loop Guard on all switch ports, regardless of their functions. The switch figures out which ports are nondesignated and monitors the BPDU activity to keep them nondesignated. Nondesignated ports are generally the alternative root ports and ports that normally are blocking.



(Cisco proprietary). When enabled, UDLD interactively monitors a port to see whether the link is truly bidirectional. A switch sends special Layer 2 UDLD frames identifying its switch port at regular intervals. UDLD expects the far-end switch to echo those frames back across the same link, with the far-end switch port’s identification added.

If a UDLD frame is received in return and both neighboring ports are identified in the frame, the link must be bidirectional. If the echoed frames are not seen, the link must be unidirectional for some reason.

UDLD messages are sent at regular intervals, as long as the link is active. You can configure the message interval UDLD uses.

Default message interval is 15 seconds. The objective behind UDLD is to detect a unidirectional link condition before STP has time to move a blocked port into the Forwarding state.

Note: The target time must be less than the Max Age timer plus two intervals of the Forward Delay timer, or 50 seconds. UDLD can detect a unidirectional link after about three times the UDLD message interval (45 seconds total, using the default).

UDLD has two modes of operation

  • Normal mode: When a unidirectional link condition is detected, the port is allowed to continue its operation. UDLD merely marks the port as having an undetermined state and generates a syslog message.
  • Aggressive mode: When a unidirectional link condition is detected, the switch takes action to reestablish the link. UDLD messages are sent out once a second for 8 seconds. If none of those messages is echoed back, the port is placed in the errdisable state so that it cannot be used.


You configure UDLD on a per-port basis, although you can enable it globally for all fiberoptic switch ports (either native fiber or fiber-based GBIC or SFP modules). By default, UDLD is disabled on all switch ports.


Enable UDLD globally

Switch(config)# udld {enable | aggressive | message time seconds}


You can use the message time keywords to set the message interval to seconds, ranging from 1 to 90 seconds (default is 7 seconds). Enable or disable UDLD on individual switch ports:

Switch(config-if)# udld {enable | aggressive | disable}


Note: The default UDLD message interval times differ among switch platforms. Although two neighbors might have mismatched message time values, UDLD still works correctly.

The time interval is used only to decide when to send UDLD messages and as a basis for detecting a unidirectional link from the absence of echoed messages. If you decide to change the default message time, make sure that UDLD still can detect a fault before STP decides to move a link to the Forwarding state.

Note: If UDLD detects a unidirectional condition on a link, it takes action on only that link. This becomes important in an EtherChannel. If one link within the channel becomes unidirectional, UDLD flags or disables only the offending link in the bundle, not the entire EtherChannel.

UDLD sends and echoes its messages on each link within an EtherChannel channel independently. Once UDLD aggressive mode has put a switch port into the errdisable state, you must use the following to reenable it:

Switch# udld reset

All ports errdisabled because of UDLD will be reset and reenabled simultaneously, allowing traffic to begin passing through them again. This behavior differs somewhat from other errdisable conditions, where you would use the shutdown and no shutdown commands to reenable a port.


Using BPDU Filtering to Disable STP on a Port

BPDUs are sent on all switch ports, even ports where PortFast is enabled. BPDUs also can be received and processed if they are sent by neighbors. You always should allow STP to run on a switch to prevent loops.

In special cases if you need to prevent BPDUs from being sent/processed on ports, you can use BPDU filtering to effectively disable STP on those ports.

By default, BPDU filtering is disabled on all ports. You can configure BPDU filtering globally affecting all switch ports

Switch(config)# spanning-tree portfast bpdufilter default

Note:  The default keyword indicates that BPDU filtering will be enabled automatically on all ports that have PortFast enabled.


Enable or disable BPDU filtering on specific switch ports

Switch(config-if)# spanning-tree bpdufilter {enable | disable}


Note: Careful to enable BPDU filtering only under controlled circumstances in which you are absolutely sure that a switch port will have a single host connected and that a loop will be impossible. Otherwise, you should permit STP to operate on the switch ports as a precaution.

Warning: Do not confuse BPDU filtering with the BPDU Guard. BPDU Guard is used to detect inbound BPDUs on ports where BPDUs are not expected to be seen, then protect the STP stability by preventing those BPDUs from being processed. In contrast, BPDU filtering stops all BPDUs from being received or sent on a switch port, effectively disabling STP.


Troubleshooting STP Protection

With different types of STP protection features, you need to know which has been configured on a switch port.

Verify ports that have been labeled in inconsistent state.

Switch# show spanning-tree inconsistentports


Check for detailed reasons for inconsistencies.

Switch# show spanning-tree interface gi0/0 detail


Verify global BPDU Guard, BPDU filter, and Loop Guard states.

Switch# show spanning-tree summary


Verify UDLD status on one or all ports.

Switch# show udld
Switch# show udld gi0/0


Reenable ports that UDLD aggressive mode has errdisabled.

Switch# udld reset


Rapid Spanning Tree Protocol (802.1w)

The 802.1w standard was developed to use 802.1D’s principal concepts and make the resulting convergence much faster. This is aka Rapid Spanning Tree Protocol (RSTP), which defines how switches must interact with each other to keep the network topology loop free in a very efficient manner.

As with 802.1D, RSTP’s basic functionality can be applied as a single instance or multiple instances. This can be done by using RSTP as the underlying mechanism for the Cisco proprietary PVST+. The resulting combination is called Rapid PVST+ (RPVST+). RSTP also is used as part of the IEEE 802.1s Multiple Spanning Tree (MST) operation.


RSTP Port Behavior

In 802.1D, each switch port is assigned a role and a state at any given time. Depending on the port’s proximity to the root bridge, it takes on one of the following roles:

  • Root
  • Designated
  • Blocking (neither root nor designated)


Note: The Cisco proprietary UplinkFast reserved a hidden alternate port role for ports that offered parallel paths to the root but were in the Blocking state.


Remember that STP has each port also is assigned one of five possible states:

  • Disabled
  • Blocking
  • Listening
  • Learning
  • Forwarding


Only the Forwarding state allows data to be sent and received. A port’s state is tied to its role. A blocking port cannot be a root port or a designated port.

RSTP achieves its rapid nature by letting each switch interact with its neighbors through each port. This interaction is performed based on a port’s role, not strictly on the bridge protocol data units BPDUs (relayed from the root bridge). After the role is determined, each port can be given a state that determines what it does with incoming data.


RSTP Port Roles:

  • Root: This is the port that is the closest to the root bridge in terms of path cost.
  • Designated: Designated if it can send the best BPDU on the segment to which it is connected. 802.1D bridges link together different segments.
  • Alternate: A port that has an alternative path to the root. Its less desirable than the root port.
  • Backup: Provides redundant connectivity to the same segment and cannot guarantee an alternate connectivity to the root bridge. Therefore, it is excluded from the uplink group.


RSTP Port States

There are only three port states left in RSTP that correspond to the three possible operational states. In 802.1D are disabled, blocking, and listening states are merged into a unique 802.1w discarding state. Bellow os a table that compares both 802.1D and 802.1W port states.

rstp port states







Because RSTP distinguishes its BPDUs from 802.1D BPDUs, it can coexist with switches still using 802.1D. Each port attempts to operate according to the STP BPDU that is received. When an 802.1D BPDU (Version 0) is received on a port, that port begins to operate according to the 802.1D rules.

However, each port has a measure that locks the protocol in use, in case BPDUs from both 802.1D and RSTP are received within a short time frame. This can occur if the switches in a network are being migrated from one STP type to another.

Instead of flapping or toggling the STP type during a migration, the switch holds the protocol type for the duration of a migration delay timer. After this timer expires, the port is free to change protocols if needed.


RSTP Convergence

Convergence generally takes time because messages are propagated from switch to switch. The traditional 802.1D STP also requires the expiration of several timers before switch ports can safely be allowed to forward data. You can think of convergence as a two stage process:

  • One common root bridge must be “elected,” and all switches must know about it.
  • The state of every switch port in the STP domain must be brought from a Blocking state to a state that prevents loops.


RSTP takes a different approach when a switch needs to decide how to participate in the topology. When a switch first joins the topology or has detected a failure in the existing topology, RSTP requires it to base its forwarding decisions on the type of port.


RSTP Port Types

Every switch port can be considered one of the following types:

  • Edge: A port at the “edge” of the network, where only a single host connects. This has been identified by enabling the STP PortFast feature. The port cannot form a loop as it connects to one host, so it can be placed immediately in the Forwarding state. If a BPDU is received on an edge port, the port immediately loses its edge port status.
  • Root: The port that has the best cost to the root of the STP. Only one root port can be selected and active at any time, (alternative paths to the root can exist through other ports). If alternative paths are detected they are identified as alternative root ports and immediately can be placed in the Forwarding state when the existing root port fails.
  • Point-to-Point: Any port that connects to another switch and becomes a designated port. BPDUs are exchanged back and forth in the form of a proposal and an agreement. One switch proposes that its port becomes a designated port; if the other switch agrees, it replies with an agreement message.


Point-to-point ports automatically are determined by the duplex mode in use. Full-duplex ports are considered point to point because only two switches can be present on the link. STP convergence can occur quickly over a point-to-point link through RSTP handshake messages.

Half-duplex ports, are considered to be on a shared medium with possibly more than two switches present. STP convergence on a half-duplex port must occur between several directly connected switches. Therefore, the traditional 802.1D style convergence must be used resulting in a slower response because the shared-medium ports must go through the fixed Listening and Learning state time periods.



To participate in RSTP convergence, a switch must decide the state of each of its ports. Non-edge ports begin in the Discarding state. After BPDUs are exchanged between the switch and its neighbor, the Root Bridge can be identified. If a port receives a superior BPDU from a neighbor, that port becomes the root port.

For each non-edge port, the switch exchanges a handshake to decide the state of each end of the link. Each switch assumes that its port should become the designated port for the segment, and a configuration BPDU is sent to the neighbor suggesting this.

When a switch receives a proposal message on a port, the following sequence of events occurs.

1. If the proposal’s sender has a superior BPDU, the local switch realizes that the sender should be the designated switch (having the designated port) and that its own port must become the new root port.

2. Before the switch agrees to anything, it must synchronize itself with the topology.

3. All non-edge ports immediately are moved into the Discarding (blocking) state so that no bridging loops can form.

4. An configuration BPDU is sent back to the sender, indicating that the switch is in agreement with the new designated port choice. This also tells the sender that the switch is in the process of synchronizing itself.

5. The root port immediately is moved to the Forwarding state. The sender’s port also immediately can begin forwarding.

6. For each non-edge port that is currently in the Discarding state, a proposal message is sent to the respective neighbor.

7. A configuration BPDU is expected and received from a neighbor on a non-edge port.

8. The non-edge port immediately moves to the Forwarding state.


Convergence begins with a switch sending a proposal message. The recipient must synchronize itself by isolating itself from the rest of the topology. All non-edge ports are blocked until a proposal message can be sent, causing the nearest neighbors to synchronize themselves. This creates a moving “wave” of synchronizing switches, which quickly can decide to start forwarding on their links only if their neighbors agree.


Topology Changes and RSTP

As a reminder, when an 802.1D switch detects a port state change (up or down), it signals the root bridge by sending TCN BPDUs. The root bridge must signal the topology change by sending out a TCN message that is relayed to all switches in the STP domain.

RSTP detects a topology change only when a non-edge port transitions to the Forwarding state. This might seem odd because a link failure is not used as a trigger. RSTP uses all its rapid convergence mechanisms to prevent bridging loops from forming. Therefore, topology changes are detected only so that bridging tables can be updated and corrected as hosts appear first on a failed port and then on a different port.

When a topology change is detected, a switch must propagate news of the change to other switches in the network so that they can correct their bridging tables, too. This process is similar to the convergence and synchronization mechanism; TC messages propagate through the network in an ever-expanding wave.

BPDUs, with their TC bit set, are sent out all the non-edge designated ports. This is done until the TC timer expires, after two intervals of the Hello time.

This notifies neighboring switches of the new link and the topology change. In addition, all MAC addresses associated with the non-edge designated ports are flushed from the CAM table. This forces the addresses to be relearned after the change, in case hosts now appear on a different link.


RSTP Configuration

Remember that RSTP is just the underlying mechanism that a spanning-tree mode can use to detect topology changes and converge a network into a
loop-free topology. The only configuration changes related to RSTP affect the port or link type. The link type is used to determine how a switch negotiates topology information with its neighbors.

Configure an Edge port

Switch(config-if)# spanning-tree portfast

Note:  After PortFast is enabled, the port is considered to have only one host and is positioned at the edge of the network.


A port connecting to one other switch might be operating at half duplex, for some reason. Force the port to act as a point-to-point Link:

Switch(config-if)# spanning-tree link-type point-to-point


Rapid Per-VLAN Spanning Tree

PVST+ is the default STP mode on Catalyst switches. In PVST+, one spanning tree instance is created and used for each active VLAN that is defined on the switch. Each STP instance behaves according to the traditional 802.1D STP rules.

You can improve the efficiency of each STP instance by configuring a switch to begin using RSTP instead. This means that each VLAN will have its own independent instance of RSTP running on the switch. This mode is known as Rapid PVST+ (RPVST+). You only need one configuration step to change the STP mode and begin using RPVST+.

Configure the bellow command to accomplish this:

Switch(config)# spanning-tree mode rapid-pvst


Note:  Be careful when you use this command on a production network because any STP process that is currently running must be restarted. This can cause functioning links to move through the traditional STP states, preventing data from flowing for a short time.


To revert back to the default PVST+ mode, (traditional 802.1D STP)

Switch(config)# spanning-tree mode pvst


After enabling RPVST+, the switch beginins supporting both RSTP and 802.1D STP neighbors. It can detect the neighbor’s STP type by the BPDU version that is received.

Verify neighbor’s type in the following output

Switch# show spanning-tree vlan 171
Spanning tree enabled protocol rstp
Root ID Priority 4267
Address 00d0.0457.38aa
Cost 3
Port 833 (Port-channel1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32939 (priority 32768 sys-id-ext 171)
Address 0007.0d55.a800
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface        Role Sts   Cost     Prio.Nbr  Type
---------------- ---- ---- --------- -------- -------------------------------
Gi1/0/7          Desg FWD   4         128.7    P2p
Gi1/0/9/6        Altn BLK   4         128.9    P2p Peer(STP)
Po1              Root FWD   3         128.104  P2p
Po2              Desg FWD   3         128.834  P2p
Po3              Desg FWD   3         128.835  P2p

Note:  Other way to confirm the STP mode is to locate the spanning-tree mode command in the running configuration.

The output displays all the active ports participating in the VLAN 171 instance of RSTP, along with their port types. The string P2p denotes a point-to-point RSTP port type in which a full-duplex link connects two neighboring switches that both are running RSTP. If you see P2p Peer(STP), the port is a point-to-point type but the neighboring device is running traditional 802.1D STP.


Multiple Spanning Tree Protocol (802.1s)

As explained in first place, there were two spanning-tree implementations, IEEE 802.1Q and PVST+, both based on the 802.1D STP. These also represent the two extremes of STP operation in a network:

  • 802.1Q: Only a single instance of STP is used for all VLANs. If there are 500 VLANs, only 1 instance of STP will be running. This is called the Common Spanning Tree (CST) and operates over the trunk’s native VLAN.
  • PVST+: One instance of STP is used for each active VLAN in the network. If there are 500 VLANs, 500 independent instances of STP will be running.

PVST+ seems more attractive because it allows different VLANs to have different topologies so that each uplink can be forwarding. But it has consequences.

As the number of VLANs increases, so does the number of independent STP instances. Each instance uses some amount of the switch CPU and memory resources. The more instances that are in use, the fewer CPU resources will be available for switching. Also take in to account that it doesn’t make sense having 20 instances running when you only have a few paths that can work with your topology in terms of redundancy. It all depends on the network needs and design required though.

MSTP was developed to address the lack of and surplus of STP instances. The network admin can configure exactly the number of STP instances that makes sense for the enterprise network, no matter how many VLANs are in use. MST is defined in the 802.1s standard.


MSTP Overview

MSTP enables multiple VLANs to be mapped to the same spanning-tree instance, reducing the number of spanning-tree instances needed to support a large number of VLANs. The MSTP provides for multiple forwarding paths for data traffic and enables load-balancing. It improves the fault tolerance of the network because a failure in one instance (forwarding path) does not affect other instances (forwarding paths). The most common initial deployment of MSTP is in the backbone and distribution layers of a Layer 2 switched network. This provides the highly available network required in a service-provider environment.

When the switch is in the MST mode, the Rapid Spanning Tree Protocol (RSTP IEEE 802.1w), is automatically enabled. RSTP provides rapid convergence of the spanning tree through explicit handshaking that eliminates the IEEE 802.1D forwarding delay and quickly transitions root ports and designated ports to the forwarding state.

Both MSTP and RSTP improve the spanning-tree operation and maintain backward compatibility with equipment that is based on the 802.1D spanning tree, with existing Cisco-proprietary Multiple Instance STP (MISTP), and with existing Cisco per-VLAN spanning-tree plus (PVST+) and rapid per-VLAN spanning-tree plus (rapid PVST+).


MSTP Regions

MST is different from 802.1Q and PVST+, although it can interoperate with them. If a switch is configured to use MST, it somehow must figure out which of its neighbors are using which type of STP.

This is done by configuring switches into Common MST Regions, where every switch in a region runs MST with compatible parameters. In most networks, a single MST region is sufficient, although you can configure more than one region. Within the region, all switches must run the instance of MST that is defined by the following attributes:

  • Configuration Name (32 characters)
  • Configuration Revision Number (0 to 65535)
  • Instance-to-VLAN Mapping Table (4096 entries)


If two switches have the same set of attributes, they belong to the same MST region. If not, they belong to two independent regions. MST BPDUs contain configuration attributes so that switches receiving BPDUs can compare them against their local MST configurations. If the attributes match, the STP instances within MST can be shared as part of the same region. If not, a switch is seen  to be at the MST region boundary, where one region meets another or one region meets traditional (802.1D) STP.

MST instance-to-VLAN mapping table is not sent in the BPDUs because the instance mappings must be configured on each switch. A digest, or a hash code computed from the table contents, is sent. As the contents of the table change, the digest value will be different. A switch quickly can compare a received digest to its own to see if the advertised table is the same.


Spanning-Tree Instances Within MST

MST was designed to interoperate with all other forms of STP. It also must support STP instances from each STP type. This is where MST can get confusing. Think of the entire enterprise network as having a single CST topology so that one instance of STP represents any and all VLANs and MST regions present.

The CST maintains a common loop-free topology while integrating all forms of STP that might be in use. CST must regard each MST region as a single “black box” bridge because it has no idea what is inside the region, nor does it care. CST maintains a loop-free topology only with the links that connect the regions to each other and to standalone switches running 802.1Q CST.


IST Instances

Something other than CST must work out a loop-free topology inside each MST region. Within a single MST region, an Internal Spanning Tree (IST) instance runs to work out a loop-free topology between the links where CST meets the region boundary and all switches inside the region.

Think of the IST instance as a locally significant CST, bounded by the edges of the region. The IST presents the entire region as a single virtual bridge to the CST outside. BPDUs are exchanged at the region boundary only over the native VLAN of trunks, as if a single CST were in operation, which it is.


MST Instances

Remember, the whole idea behind MST is the capability to map multiple VLANs to a smaller number of STP instances. Inside a region, the actual MST instances (MSTI) exist alongside the IST. Cisco supports a maximum of 16 MSTIs in each region.

The IST always exists as MSTI number 0, leaving MSTIs 1 through 15 available for use.

The bellow shows how different MSTIs can exist within a single region. The left portion of the figure is identical to that of Figure 9-4 . In this network, two MST instances, MSTI 1 and MSTI 2, are configured with different VLANs mapped to each. Their topologies follow the same structure as the network on the left side of the figure, but each has converged differently.

IST instance









Notice that within the MST cloud, there are now three independent STP instances coexisting: MSTI1, MSTI 2, and the IST. Only the IST (MSTI 0) is allowed to send and receive MST BPDUs. Information about each of the other MSTIs is appended to the MST BPDU as an M-record. Therefore, even
if a region has all 16 instances active, only 1 BPDU is needed to convey STP information about them all.
Each of the MSTIs is significant only within a region, even if an adjacent region has the same MSTIs in use. In other words, the MSTIs combine with the IST only at the region boundary to form a subtree of the CST. That means only IST BPDUs are sent into and out of a region.
What if an MST region connects with a switch running traditional PVST+? MST can detect this situation by listening to the received BPDUs. If BPDUs are heard from more than one VLAN (the CST), PVST+ must be in use. When the MST region sends a BPDU toward the PVST+ switch, the IST BPDUs are replicated into all the VLANs on the PVST+ switch trunk.

Note:  Keep in mind that the IST instance is active on every port on a switch. Even if a port does not carry VLANs that have been mapped to the IST, IST must be running on the port. Also, by default, all VLANs are mapped to the IST instance. You must explicitly map them to other instances, if needed.


MSTP Configuration

You must manually configure the MST configuration attributes on each switch in a region. There is currently no method to propagate this information from one switch to another, as is done with a protocol such as VLAN Trunking Protocol (VTP).

Enable MST on the switch

Switch(config)# spanning-tree mode mst

Enter the MST configuration mode

Switch(config)# spanning-tree mst configuration

Assign a region configuration name (up to 32 characters)

Switch(config-mst)# name instance1


Assign a region configuration revision number (0 to 65,535)

Switch(config-mst)# revision 1


Note:  The configuration revision number gives you a means of tracking changes to the MST region configuration. Each time you make changes to the configuration, you should increase the number by one. Remember that the region configuration (including the revision number) must match on all switches in the  region, so you also need to update the revision numbers on the other switches to match.


Map VLANs to an MST instance

Switch(config-mst)# instance 1 vlan-range 10-20


Note:  The instance-id (0 to 15) carries topology information for the VLANs listed in vlan-list. The list can contain one or more VLANs separated by commas. You also can add a range of VLANs to the list by separating numbers with a hyphen. VLAN numbers can range from 1 to 4094. (Remember that, by default, all VLANs are mapped to instance 0, the IST.)


Show the pending changes you have made

Switch(config-mst)# show pending


Exit the MST configuration mode; commit the changes to the active MST region configuration

Switch(config-mst)# exit


After MST is enabled and configured, PVST+ operation stops and the switch changes to RSTP operation. A switch cannot run both MST and PVST+ at the same time. You also can tune the parameters that MST uses when it interacts with CST or traditional 802.1D.


More MST Configuration Commands Syntax

Set root bridge (macro)

Switch(config)# spanning-tree mst instance-id root {primary | secondary} [diameter diameter]


Set bridge priority

Switch(config)# spanning-tree mst instance-id priority bridgepriority


Set port cost

Switch(config)# spanning-tree mst instance-id cost cost


Set port priority

Switch(config)# spanning-tree mst instance-id port-priority port-priority


Set STP timers

Switch(config)# spanning-tree mst hello-time seconds
Switch(config)# spanning-tree mst forward-time seconds
Switch(config)# spanning-tree mst max-age seconds


Small Configuration Example

Switch(config)# spanning-tree mst configuration
 Switch(config-mst)# instance 1 vlan 10-20
 Switch(config-mst)# name region1
 Switch(config-mst)# revision 1
 Switch(config-mst)# show pending
 Pending MST configuration
 Name [region1]
 Revision 1
 Instance Vlans Mapped
 -------- ---------------------
 0 1-9,21-4094
 1 10-20
Switch(config-mst)# exit


Hope this helps someone else!