0% found this document useful (0 votes)

543 views104 pages

Switching PDF

Uploaded by

Rajkeen Chamanshaikh

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

543 views104 pages

Switching PDF

Uploaded by

Rajkeen Chamanshaikh

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 104

Switching Architectures v1.

11 – Aaron Balchunas 1

- Switching Architectures -
Network Traffic Models
Traffic flow is an important consideration when designing scalable, efficient
networks. Fundamentally, this involves understanding two things:
• Where do resources reside?
• Where do the users reside that access those resources?
Legacy networks adhered to the 80/20 design, which dictated that:
• 80 percent of traffic should remain on the local network.
• 20 percent of traffic should be routed to a remote network.
To accommodate this design practice, resources were placed as close as
possible to the users that required them. This allowed the majority of traffic
to be switched, instead of routed, which reduced latency in legacy networks.
The 80/20 design allowed VLANs to be trunked across the entire campus
network, a concept known as end-to-end VLANs:

End-to-end VLANs allow a host to exist anywhere on the campus network,

while maintaining Layer-2 connectivity to its resources.
However, this flat design poses numerous challenges for scalability and
performance:
• STP domains are very large, which may result in instability or
convergence issues.
• Broadcasts proliferate throughout the entire campus network.
• Maintaining end-to-end VLANs adds administrative overhead.
• Troubleshooting issues can be difficult.

***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Switching Architectures v1.11 – Aaron Balchunas 2

Network Traffic Models (continued)

As network technology improved, centralization of resources became the
dominant trend. Modern networks adhere to the 20/80 design:
• 20 percent of traffic should remain on the local network.
• 80 percent of traffic should be routed to a remote network.
Instead of placing workgroup resources in every local network, most
organizations centralize resources into a datacenter environment. Layer-3
switching allows users to access these resources with minimal latency.
The 20/80 design encourages a local VLAN approach. VLANs should stay
localized to a single switch or switch block:

This design provides several benefits:

• STP domains are limited, reducing the risk of convergence issues.
• Broadcast traffic is isolated within smaller broadcast domains.
• Simpler, hierarchical design improves scalability and performance.
• Troubleshooting issues is typically easier.
There are nearly no drawbacks to this design, outside of a legacy application
requiring Layer-2 connectivity between users and resources. In that scenario,
it’s time to invest in a better application. ☺

The Cisco Hierarchical Network Model

To aid in designing scalable networks, Cisco developed a hierarchical
network model, which consists of three layers:
• Access layer
• Distribution layer
• Core layer

Cisco Hierarchical Model – Access Layer

The access layer is where users and hosts connect into the network.
Switches at the access layer typically have the following characteristics:
• High port density
• Low cost per port
• Scalable, redundant uplinks to higher layers
• Host-level functions such as VLANs, traffic filtering, and QoS
In an 80/20 design, resources are placed as close as possible to the users that
require them. Thus, most traffic will never need to leave the access layer.
In a 20/80 design, traffic must be forwarded through higher layers to reach
centralized resources.

(Reference: CCNP Switch 642-813 Official Certification Guide by David Hucaby. Cisco Press)
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Switching Architectures v1.11 – Aaron Balchunas 4

Cisco Hierarchical Model – Distribution Layer

The distribution layer is responsible for aggregating access layer switches,

and connecting the access layer to the core layer. Switches at the distribution
layer typically have the following characteristics:
• Layer-3 or multilayer forwarding
• Traffic filtering and QoS
• Scalable, redundant links to the core and access layers
Historically, the distribution layer was the Layer-3 boundary in a
hierarchical network design:
• The connection between access and distribution layers was Layer-2.
• The distribution switches are configured with VLAN SVIs.
• Hosts in the access layer use the SVIs as their default gateway.
This remains a common design today.
However, pushing Layer-3 to the access-layer has become increasingly
prevalent. VLAN SVIs are configured on the access layer switch, which
hosts will use as their default gateway.
A routed connection is then used between access and distribution layers,
further minimizing STP convergence issues and limiting broadcast traffic.

(Reference: CCNP Switch 642-813 Official Certification Guide by David Hucaby. Cisco Press)

Cisco Hierarchical Model – Core Layer

The core layer is responsible for connecting all distribution layer switches.
The core is often referred to as the network backbone, as it forwards traffic
from to every end of the network.
Switches at the core layer typically have the following characteristics:
• High-throughput Layer-3 or multilayer forwarding
• Absence of traffic filtering, to limit latency
• Scalable, redundant links to the distribution layer and other core
switches
• Advanced QoS functions
Proper core layer design is focused on speed and efficiency. In a 20/80
design, most traffic will traverse the core layer. Thus, core switches are often
the highest-capacity switches in the campus environment.
Smaller campus environments may not require a clearly defined core layer
separated from the distribution layer. Often, the functions of the core and
distribution layers are combined into a single layer. This is referred to as a
collapsed core design.

Cisco Hierarchical Model – Practical Application

A hierarchical approach to network design enforces scalability and
manageability. Within this framework, the network can be
compartmentalized into modular blocks, based on function.

The above example illustrates common block types:

• User block – containing end users
• Server block – containing the resources accessed by users
• Edge block – containing the routers and firewalls that connect users
to the WAN or Internet
Each block connects to each other through the core layer, which is often
referred to as the core block. Connections from one layer to another should
always be redundant.
A large campus environment may contain multiple user, server, or edge
blocks. Limiting bottlenecks and broadcasts are key considerations when
determining the size of a block.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Switching Tables v1.11 – Aaron Balchunas 1

- Switching Tables -
Layer-2 Forwarding Overview
Layer-2 devices build hardware address tables, which at a minimum
contain the following:
• Hardware addresses for hosts (such as Ethernet MAC addresses)
• The port each hardware address is associated with
Using this information, Layer-2 devices will make intelligent forwarding
decisions based on the frame (or data-link) header. A frame can then be
forwarded out only the appropriate destination port, instead of all ports.
Layer-2 forwarding was originally referred to as bridging. Bridging is a
largely deprecated term (mostly for marketing purposes), and Layer-2
forwarding is now commonly referred to as switching.

Switching Queues
Layer-2 switches utilize queues to store incoming and outgoing frames.
Consider the following diagram:

1. The switch receives a frame on Port 1, from HostA destined for HostB.
2. The frame is placed in Port 1’s ingress queue.
3. The switch performs a lookup on the destination hardware address -
HostB in this example.
4. The switch determines that the appropriate destination port for HostB is
Port 2.
5. The frame is placed in Port 2’s egress queue.
If the switch had no knowledge of HostB’s hardware address, the frame
would be placed in the egress queue of all ports except for the originating
port, and thus flooded to the entire network.
A port can contain multiple ingress or egress queues. This allows critical
traffic to be prioritized over less important traffic.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Switching Tables v1.11 – Aaron Balchunas 2

MAC Address Table

In the previous example, the switch made a forwarding decision based on
the destination host’s hardware address. The switch essentially forwarded
the frame from one port’s ingress queue to another port’s egress queue.
To perform this forwarding decision, a switch consults its hardware address
table. For Ethernet switches, this is referred to as the MAC address table,
or the Layer-2 forwarding table.
When a switch is first powered on, the MAC address table will be empty.
The switch will build the table through a dynamic learning process, by
observing the source MAC address of frames:

1. Initially, the switch will have no knowledge of the MAC addresses of

HostA and HostB.
2. When HostA sends a frame to HostB, the switch will add HostA’s MAC
address to its table, associating it with port ethernet1.
3. The switch will not learn HostB’s MAC address until HostB sends a
frame back to HostA, or to any other host connected to the switch.
4. HostB’s MAC address will then be associated with port ethernet2.
Remember: a switch will only add MAC address table entries based on the
source MAC address in a frame.
The MAC address table is stored in fast volatile memory, allowing lookups
to be performed very quickly. However, this also results in dynamically-
learned MAC addresses being lost if the switch is rebooted or powered off.
Stale (or idle) entries in the table will be aged out. By default on Cisco
switches, idle entries will be purged after 300 seconds.
Most switches support statically configuring MAC addresses into the table,
which will survive a reboot or power failure, and never be purged. Statically
configuring entries in the table is only required in limited circumstances.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Switching Tables v1.11 – Aaron Balchunas 3

CAM and TCAM Tables

On Cisco switches, the MAC address table is stored in Content
Addressable Memory (CAM).
CAM differs from the more prevalent Random Access Memory (RAM):
• RAM queries a specific memory address, and then returns the data or
content stored at that address location.
• CAM operates essentially in the reverse, and does not require that a
memory address be provided. Instead, CAM queries for the desired
content, and then returns all matching results, including any
associated content.
CAM is significantly faster than RAM, as it searches the entire memory
content in one cycle, instead of a single address at a time. However, CAM is
more expensive than RAM.
When performing a MAC address table lookup, the MAC address itself is
the content being queried. For any matching results, CAM will return the
destination port (the associated content).
Cisco uses the terms MAC address table and CAM table interchangeably.
This guide will use the term CAM table moving forward.
Idle entries in the CAM are purged after 300 seconds, by default. This timer
is reset every time a frame is received with the associated MAC address on
the correct port.
If a host moves to a different port on a switch, the CAM table entry for the
previous port will be purged immediately. This is desirable behavior - a
MAC address is unique, and should never exist on more than one switch port
unless a switching loop or other issue exists.
Ternary Content Addressable Memory (TCAM) tables provide high-
speed lookups for two additional functions:
• Filtering traffic using access-lists
• Prioritizing traffic using QoS
TCAM tables are covered in greater detail later in this guide.
Multilayer switches utilize the Forwarding Information Base (FIB) table
for L3 forwarding decisions. Multilayer switching is covered extensively in
a different guide.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Switching Tables v1.11 – Aaron Balchunas 4

Managing the CAM Table

Each entry in the CAM table contains the following information:
• The MAC address
• The switch port the MAC address was learned on
• The VLAN of the switch port
• A time stamp, for the aging timer
To view the entire CAM table:
Switch# show mac address-table
vlan mac address type port
-------+---------------+---------+---------------------
9 000c.291e.96f0 dynamic GigabitEthernet1/1
9 000c.293c.7cac dynamic GigabitEthernet1/1
9 000c.2950.e3e9 dynamic GigabitEthernet1/1
9 000c.29ba.fe28 dynamic GigabitEthernet1/2
9 842b.2ba6.3a7d dynamic GigabitEthernet1/3
9 d067.e50b.1975 dynamic GigabitEthernet1/5
9 d067.e51e.e35a dynamic GigabitEthernet2/1
9 f04d.a2f6.d37b dynamic GigabitEthernet2/2

A single switch port can learn many addresses. In the above output,
GigabitEthernet1/1 has multiple MAC addresses associated with it. This
usually indicates this is an uplink to another switch.
To view the CAM table entries for a specific port or MAC address:
Switch# show mac address-table interface GigabitEthernet 1/5
vlan mac address type port
-------+---------------+---------+---------------------
9 d067.e50b.1975 dynamic GigabitEthernet1/5

Switch# show mac address-table address f04d.a2f6.d37b

vlan mac address type port
-------+---------------+---------+---------------------
9 f04d.a2f6.d37b dynamic GigabitEthernet2/2

The output of a command can be filtered using the pipe command. For
example, to search for any entry that contains 3a7d in the MAC address:
Switch# show mac address-table | include 3a7d
vlan mac address type port
-------+---------------+---------+---------------------
9 842b.2ba6.3a7d dynamic GigabitEthernet1/3
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Switching Tables v1.11 – Aaron Balchunas 5

Managing the CAM Table (continued)

To specifically display only dynamic or static CAM entries:
Switch# show mac address-table dynamic
Switch# show mac address-table static

To view the total number of entries in the CAM table:

Switch# show mac address-table count
MAC Entries for all vlans:
Dynamic Unicast Address Count: 234
Static Unicast Address (User-defined) Count: 0
Static Unicast Address (System-defined) Count: 6
Total Unicast MAC Addresses In Use: 240
Total Unicast MAC Addresses Available: 55000
Multicast MAC Address Count: 9
Total Multicast MAC Addresses Available: 32768

The CAM aging timer can be changed from its default of 300, though this is
needed only in rare circumstances:
Switch# config t
Switch(config)# mac address-table aging-time 360

To add a static entry into the CAM table:

Switch(config)# mac address-table static 0011.2233.4455 vlan 9 interface
GigabitEthernet 2/7

To clear all dynamic entries in the CAM table:

Switch# clear mac address-table dynamic all

To clear a single entry in the CAM, either by MAC address or interface:

Switch# clear mac address-table dynamic address d067.e51e.e35a
Switch# clear mac address-table dynamic interface GigabitEthernet 2/1

Note: In Cisco IOS versions prior to 12.1, the syntax for all CAM table
commands contained an additional hyphen between mac and address:
Switch# show mac-address-table

This additional hyphen is no longer required on modern versions of the

IOS. Some IOS versions may support both syntaxes.

Ternary Content Addressable Memory (TCAM)

Recall that switches utilize TCAM tables for two purposes:
• Filtering traffic using access-lists
• Prioritizing traffic using QoS
Some Layer-3 devices store the routing table in TCAM as well. Most Layer-
3 switches support multiple TCAM tables, to separately manage the access-
lists for inbound and outbound traffic, and for QoS.
The TCAM consists of two components:
• Feature Manager (FM) – automatically integrates access-lists into
the TCAM.
• Switching Database Manager (SDM) – supports partitioning the
TCAM for separate functions (supported on only some Cisco models).
Each entry in the TCAM table contains three components, defined by
access-list entries:
• Values – defines the addresses or ports that must be matched
• Masks – defines how much of each address to match
• Result – defines the action to take when a match occurs
Consider the following access-list:
Switch(config)# access-list WEB permit tcp 10.1.1.0 0.0.0.255 host 10.2.1.1 eq 443
Switch(config)# access-list WEB deny tcp 10.1.0.0 0.0.0.255 host 10.2.1.1 eq 80

• The values are the source (10.1.1.0) and destination (10.2.1.1)

addresses, and the TCP ports (443 and 80, respectively).
• The masks are 0.0.0.255 for the source, and 0.0.0.0 for the
destination. This indicates that the first three octets must match for the
source, and the destination much match exactly.
• The results are permit for the first entry, and deny for the second.
Other results are possible - such as when using QoS which is more
concerned with prioritizing traffic than filtering it.
The Feature Manager (FM) will automatically integrate the access-list
named WEB into the TCAM. Configuring the TCAM consists solely of
creating the necessary access-lists. However, the access-list will not take
effect until it’s applied to an interface or VLAN.

- Switch Port Configuration -

Cisco Operating Systems
Cisco offers two brands of network switches:
• Catalyst – Cisco’s flagship switching platform, with a large selection
of models spanning access, distribution, and core layers.
• Nexus – high-end switches focused at datacenter environments.
Depending on the brand and model, Cisco supports one of three switch
operating systems:
• Catalyst OS (CatOS) - interface based on set commands, that is
almost entirely deprecated. CatOS will not be covered in this guide.
• IOS – interface that is nearly identical to the Cisco router IOS, except
for switching-specific commands.
• NX-OS – interface supported exclusively on Nexus brand switches.
The following details the supported operating system for various Cisco
platforms:
CatOS IOS NX-OS
• Catalyst 1200 • Catalyst 29xx • Nexus 1000V
• Catalyst 2948 • Catalyst 35xx • Nexus 3000
• Catalyst 4000 • Catalyst 36xx • Nexus 4000
• Catalyst 4500 • Catalyst 37xx • Nexus 5000
• Catalyst 5000 • Catalyst 38xx • Nexus 7000
• Catalyst 5500 • Catalyst 4500 • Nexus 9000
• Catalyst 6000 • Catalyst 4900
• Catalyst 6500 • Catalyst 6500
• Catalyst 6800

The basic IOS interface is nearly identical between switches and routers, and
is covered in great detail in other guides on this site:
• Introduction to the Cisco IOS
• Advanced IOS Functions
This guide will focus on switch-specific IOS functions. For a more
comprehensive IOS review, consult the guides listed above.

Switch Port Configuration

Traditionally, network connections on switches have been referred to as
ports, while on routers they are referred to as interfaces. However, in the
Cisco IOS, switch ports are referred to as interfaces as well.
Additionally, most Cisco switches are modular. Thus, configuration
commands must reflect both the module and interface number, in the
following format: module/interface
Some catalyst switches support being stacked – essentially, multiple
physical switches connected together to form one logical switch.
Configuration commands must reflect the stack, module, and interface
number, in the following format: stack/module/interface
To enter interface configuration mode for the third Fast Ethernet interface
off of the second module:
Switch(config)# interface FastEthernet 2/3
Switch(config-if)#

Note that most switches will number their modules and interfaces starting at
1, while most routers will number their modules/interfaces starting at 0.
The above command can be shortened, as long as the truncated command is
not ambiguous:
Switch(config)# interface fa 2/3

If the interface above was Gigabit Ethernet instead of Fast Ethernet:

Switch(config)# interface GigabitEthernet 2/3
Switch(config)# interface gi 2/3

Note: On Nexus switches using the NX-OS, the speed of an Ethernet

interface is not used to identify it – all interfaces are simply Ethernet:
NexusSwitch(config)# interface Ethernet 2/3

Multiple interfaces can be configured simultaneously:

Switch(config)# interface range gi2/3 , gi2/5 , gi2/7
Switch(config-if-range)#

The above command selects interfaces gi2/3, gi2/5, gi2/7. Please note that
there is a space on either side of each comma.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Switch Port Configuration v1.31 – Aaron Balchunas 3

Switch Port Configuration (continued)

A contiguous range of interfaces can be specified:
Switch(config)# interface range gi3/10 - 15

The above command selects interfaces gi3/10 through gi3/15. Please note
the space on either side of the dash.
Macros can be created for groups of interfaces that are configured often:
Switch(config)# define interface-range MACRONAME gi3/10 – 15
Switch(config)# interface range macro MACRONAME
Switch(config-if-range)#

The first command creates a macro (or group) of interfaces called

MACRONAME. The second command actually selects those interfaces for
configuration.
Descriptions can be applied to an interface for documentation purposes:
Switch(config)# interface gi3/10
Switch(config-if)# description WEBSERVER

Spaces are allowed in a description:

Switch(config)# interface gi2/10
Switch(config-if)# description CHECK PRINTER IN PAYROLL

Descriptions can greatly assist in troubleshooting issues, as long as they are

accurate. Descriptions on access-layer switches can be difficult to manage,
as hosts may change interfaces often.
Scenarios where adding descriptions to interfaces is valuable:
• Switch or router uplinks
• WAN connections
• Datacenter hosts – such as servers or firewalls

Descriptions should be as detailed as possible. For example, including the

circuit number on a WAN connection can accelerate resolution of an outage.
If an interface does not have an accurate description, there are two methods
of determining what is connected to it:
• Trace the physical cable to the host (always fun)
• Leverage the CAM table to identify a host by its MAC address
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Switch Port Configuration v1.31 – Aaron Balchunas 4

Switch Port Configuration – Speed and Duplex

Some switch interfaces are fixed at a single speed. Often though, a single
switch interface can support multiple speeds.
For example, a Gigabit Ethernet interface is often backwards-compatible
with original and Fast Ethernet, and is referred to as a 10/100/1000 interface.
To manually specify the speed of an interface:
Switch(config)# interface gi3/10
Switch(config-if)# speed 10
Switch(config-if)# speed 100
Switch(config-if)# speed 1000

The duplex of an interface can be manually specified as well:

Switch(config)# interface gi3/10
Switch(config-if)# duplex half
Switch(config-if)# duplex full

Ethernet also has the ability to autonegotiate both the speed and duplex of
an interface. Autonegotiation will attempt to use the fastest speed available,
and will attempt to use full-duplex if both devices support it.
Only one command is required to force an interface to autonegotiate its
speed and duplex:
Switch(config)# interface gi3/10
Switch(config-if)# speed auto

The configuration must be consistent on both sides of the connection. Both

sides must be configured to autonegotiate, or both sides must be hardcoded
with identical settings. Otherwise a duplex mismatch error can occur.
For example, if a workstation’s interface is configured to autonegotiate, and
the switch interface is hardcoded for 100Mbps and full-duplex, then a
duplex mismatch will occur. The workstation’s interface will sense the
correct speed of 100Mbps, but will not detect the correct duplex and will
default to half-duplex.
If the duplex is mismatched, collisions will occur. Because the full-duplex
side of the connection does not utilize CSMA/CD, performance is severely
degraded. These issues can be difficult to troubleshoot, as the network
connection will still function, but will be excruciatingly slow.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Switch Port Configuration v1.31 – Aaron Balchunas 5

Switch Port Configuration – Speed and Duplex (continued)

When autonegotiation was first developed, manufacturers did not always
adhere to the same standard. This resulted in frequent mismatch issues, and a
sentiment of distrust towards autonegotiation.
Though modern network hardware has alleviated most of the
incompatibility, many administrators are still skeptical of autonegotiation
and choose to hardcode all connections. Another common practice is to
hardcode server and datacenter connections, but to allow user devices to
autonegotiate.
Gigabit Ethernet provided several enhancements to autonegotiation, such as
hardware flow control. Most manufacturers recommend autonegotiation
on Gigabit Ethernet interfaces as a best practice.

Switch Port Configuration - Shutdown

By default on most Cisco switches, all interfaces will be in an
administratively shutdown state. An interface that is shutdown will not
send or receive traffic.
To take an interface out of a shutdown state:
Switch(config)# interface gi3/10
Switch(config-if)# no shutdown

Intuitively, to place the interface into a shutdown state again:

Switch(config)# interface gi3/10
Switch(config-if)# shutdown

It is possible to shut or no shut multiple interface simultaneously, using the

range command:
Switch(config)# interface range gi3/10 – 15
Switch(config-if-range)# no shut

Be careful – do not unintentionally shutdown the wrong interfaces when

using the range command.
It is possible to apply any configuration to an interface that is shutdown.
However, the interface (and corresponding configuration) will not become
active until the interface is no shut.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Switch Port Configuration v1.31 – Aaron Balchunas 6

Switch Port Error Conditions

Cisco switches can detect error conditions on an interface. If the error is
severe enough, the switch can automatically disable that interface. An
interface that is disabled due to an error is considered to be in an errdisable
state.
The following events can put a port into errdisable state:

Error with dynamic ARP inspection, used to prevent

arp-inspection
ARP poisoning.
BPDU is received on an interface configured for STP
bpduguard
Portfast and BPDU guard.
channel-misconfig Error with an Etherchannel configuration
dhcp-rate-limit Error with DHCP Snooping
dtp-flap Flapping between trunk encapsulations (ISL or 802.1Q)
gbic-invalid Invalid SFP or GBIC module
ilpower Error with inline power
Interface is looped (received a keepalive packet that it
loopback
sent out).
l2tpguard Error with L2 tunneling
link-flap Interface is flapping between an up or down state
mac-limit Violation of MAC address limit
Flapping of an Etherchannel during PaGP negotiation,
pagp-flap
usually due to misconfiguration
psecure-violation Violation of port-security
BPDU from a root bridge received on a non-designated
rootguard
port
security-violation Violation of 802.1x security
storm-control Broadcast storm detected
udld Unidirectional link detected
unicast-flood Violation of unicast flooding limit
(Reference: http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/69980-errdisable-recovery.html)

Switch Port Error Conditions (continued)

All errdisable conditions are enabled by default. To disable a specific
errdisable condition:
Switch(config)# no errdisable detect cause link-flap

It is also possible to disable all errdisable conditions:

Switch(config)# no errdisable detect cause all

To enable errdisable conditions again, either individually or collectively:

Switch(config)# errdisable detect cause udld
Switch(config)# errdisable detect cause all

An interface can be manually recovered from an errdisable state by

performing a shutdown and then no shutdown:
Switch(config)# interface gi3/10
Switch(config-if)# shut
Switch(config-if)# no shut

However, if the error condition still exists, the interface will be placed back
into an errdisable state again. Thus, an interface should not be recovered
until the root cause is resolved.
Interfaces can also automatically recover from an error condition. First, the
errdisable conditions that should auto-recover must be individually or
collectively identified:
Switch(config)# errdisable recovery cause udld
Switch(config)# errdisable recovery cause all

By default, an interface will recover from an errdisable state in 300 seconds.

This timer can be adjusted:
Switch(config)# errdisable recovery interval 250

To view which errdisable conditions are currently enabled for recovery:

Switch# show errdisable recovery

By default, automatic errdisable recovery is disabled for all conditions.

Note that all errdisable commands are applied globally, and thus apply to all
interfaces on the switch.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Switch Port Configuration v1.31 – Aaron Balchunas 8

Troubleshooting Switch Port s

Cisco switches offer several show commands for monitoring and
troubleshooting switch ports.
The show interface is invaluable, and provides the following information:
• Current interface status – up, down, administratively down, errdisable
• Speed and duplex
• Current input/output rates
• Historical packet input/output and error statistics

To view the details of a specific interface, such as GigabitEthernet 3/10:

Switch# show interface gi3/10
GigabitEthernet3/10 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet Port, address is 2c54.2db2.dab1
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, link type is auto, media type is 10/100/1000-TX
input flow-control is on, output flow-control is on
Auto-MDIX on (operational: on)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:25, output never, output hang never
Last clearing of "show interface" counters 1y9w
Input queue: 0/2000/0/0 (size/max/drops/flush); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 6000 bits/sec, 8 packets/sec
190197453 packets input, 22130686309 bytes, 0 no buffer
Received 1660069 broadcasts (1295453 multicasts)
0 runts, 110243 giants, 0 throttles
110243 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
518261888 packets output, 352807215573 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

To view details of all interfaces:

Switch# show interface

Troubleshooting Switch Port s (continued)

The show interface command provides an occasionally overwhelming
amount of detailed information.
The show interface status command provides a high-level summary of all
switch interfaces:
Switch# show interface status

Port Name Status Vlan Duplex Speed Type

Gi2/1 connected 15 a-full a-100 10/100/1000-TX
Gi2/2 notconnect 15 auto auto 10/100/1000-TX
Gi2/3 connected 15 a-full a-100 10/100/1000-TX
Gi2/4 connected 15 a-full a-1000 10/100/1000-TX
Gi2/5 connected 15 a-half a-10 10/100/1000-TX
Gi2/6 notconnect 15 auto auto 10/100/1000-TX
Gi2/7 connected 15 a-full a-100 10/100/1000-TX
Gi2/8 connected 15 a-full a-100 10/100/1000-TX
Gi2/9 connected 15 a-full a-100 10/100/1000-TX
Gi2/10 notconnect 15 auto auto 10/100/1000-TX
Gi2/11 notconnect 9 auto auto 10/100/1000-TX

<snipped for brevity>

To view which interfaces are currently in an errdisable state, including the

reason for the errdisable condition:
Switch# show interface status err-disabled
Port Name Status Reason
Gi3/1 err-disabled rootguard
Gi3/3 err-disabled ilpower
Gi3/8 err-disabled security-violation
Gi3/9 err-disabled grue-eats-your-face

Watch out for the grue.

***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Virtual LANs (VLANs) and VTP v1.31 – Aaron Balchunas 1

- Virtual LANs (VLANs) and VTP -

Collision vs. Broadcast Domains
A collision domain is simply defined as any physical segment where a
collision can occur. Hubs can only operate at half-duplex, and thus all ports
on a hub belong to the same collision domain.
Layer-2 switches can operate at full duplex. Each individual port on a switch
belongs to its own collision domain. Thus, Layer-2 switches create more
collision domains, which results in fewer collisions.
Like hubs though, Layer-2 switches belong to only one broadcast domain.
A Layer-2 switch will forward both broadcasts and multicasts out every port
but the originating port.
Only Layer-3 devices separate broadcast domains. Because of this, Layer-2
switches are poorly suited for large, scalable networks. The Layer-2 header
provides no mechanism to differentiate one network from another, only one
host from another.

Virtual LANs (VLANs)

By default, a switch will forward both broadcasts and multicasts out every
port but the originating port. However, a switch can be logically segmented
into separate broadcast domains, using Virtual LANs (or VLANs).
Each VLAN represents a unique broadcast domain:
• Traffic between devices within the same VLAN is switched.
• Traffic between devices in different VLANs requires a Layer-3
device to communicate.
Broadcasts from one VLAN will not be forwarded to another VLAN. The
logical separation provided by VLANs is not a Layer-3 function. VLAN
tags are inserted into the Layer-2 header.
Thus, a switch that supports VLANs is not necessarily a Layer-3 switch.
However, a purely Layer-2 switch cannot route between VLANs.
Remember, though VLANs provide separation for Layer-3 broadcast
domains, they are still a Layer-2 function. A VLAN often has a direct
relationship with an IP subnet, though this is not a requirement.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Virtual LANs (VLANs) and VTP v1.31 – Aaron Balchunas 2

VLAN Example
Consider the following example:

Four hosts are connected to a Layer-2 switch that supports VLANs:

• HostA and HostB belong to VLAN 100
• HostC and HostD belong to VLAN 200
Because HostA and HostB belong to the same VLAN, they belong to the
same broadcast domain as well. The switch will be able to forward frames
between the two hosts without the need of a Layer-3 device, such as a router.
Likewise, HostC and HostD belong to the same VLAN, and thus the same
broadcast domain. They also will be able to communicate without an
intervening Layer-3 device.
However, HostA and HostB will not be able to communicate with HostC and
HostD. They are members of separate VLANs, and belong in different
broadcast domains. Thus, a Layer-3 device is required for those hosts to
communicate.
A broadcast sent from a host in VLAN 100 will be received by all other
hosts in that same VLAN. However, that broadcast will not be forwarded to
any other VLAN, such as VLAN 200.
On Cisco switches, all interfaces belong to VLAN 1 by default. VLAN 1 is
also considered the Management VLAN, and should be dedicated for
system traffic such as CDP, STP, VTP, and DTP.

***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Virtual LANs (VLANs) and VTP v1.31 – Aaron Balchunas 3

Advantages of VLANs
VLANs provide the several benefits:
• Broadcast Control – eliminates unnecessary broadcast traffic,
improving network performance and scalability.
• Security – logically separates users and departments, allowing
administrators to implement access-lists to control traffic between
VLANs.
• Flexibility – removes the physical boundaries of a network, allowing
a user or device to exist anywhere.
VLANs are very common in LAN and campus networks. For example, user
networks are often separated from server networks using VLANs.
VLANs can span across WANs as well, though there are only limited
scenarios where this is necessary or recommended.

VLAN Membership
VLAN membership can be configured one of two ways:
• Statically
• Dynamically
Statically assigning a VLAN involves manually assigning an individual or
group of ports to a VLAN. Any host connected to that port (or ports)
immediately becomes a member of that VLAN. This is transparent to the
host - it is unaware that it belongs to a VLAN.
VLANs can be assigned dynamically based on the MAC address of the
host. This allows a host to remain in the same VLAN, regardless of which
switch port it is connected to.
Dynamic VLAN assignment requires a separate database to maintain the
MAC-address-to-VLAN relationship. Cisco developed the VLAN
Membership Policy Server (VMPS) to provide this functionality.
In more sophisticated systems, a user’s network account can be used to
determine VLAN membership, instead of a host’s MAC address.
Static VLAN assignment is far more common than dynamic, and will be the
focus of this guide.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Virtual LANs (VLANs) and VTP v1.31 – Aaron Balchunas 4

Creating VLANs
By default, all interfaces belong to VLAN 1. To assign an interface to a
different VLAN, that VLAN must first be created:
Switch(config)# vlan 100
Switch(config-vlan)# name SERVERS

The first command creates VLAN 100, and enters VLAN configuration
mode. The second command assigns the name SERVERS to this VLAN.
Note that naming a VLAN is not required.
The standard range of VLAN numbers is 1 – 1005, with VLANs 1002-1005
reserved for legacy Token Ring and FDDI purposes.
A switch operating in VTP transparent mode can additionally use the
VLAN range of 1006 – 4094. These are known as extended-range VLANs.
VTP is covered in great detail later in this guide.
To remove an individual VLAN:
Switch(config)# no vlan 100

Note that VLAN 1 cannot be removed. To remove a group of VLANs:

Switch(config)# no vlan 150-200

To view all created VLANs, including the interfaces assigned to each

VLAN:
Switch# show vlan
VLAN Name Status Ports
---- -------------------------- --------- -----------
1 default active gi1/1-24
100 SERVERS active
1002 fddi-default suspended
1003 token-ring-default suspended
1004 fddinet-default suspended
1005 trnet-default suspended

Note that no interfaces have been assigned to the newly created VLAN 100
yet.

***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Virtual LANs (VLANs) and VTP v1.31 – Aaron Balchunas 5

Statically Assigning VLANs

To statically assign an interface into a specific VLAN:
Switch(config)# interface gi1/10
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 100

The first command enters interface configuration mode. The second

command indicates that this is an access port, as opposed to a trunk port.
This will be explained in detail shortly.
The third command assigns this access port to VLAN 100. Note that the
VLAN number is specified, and not the VLAN name.
The show vlan command should now reflect the new VLAN assignment:
Switch# show vlan
VLAN Name Status Ports
---- -------------------------- --------- -----------
1 default active gi1/1-9,11-24
100 SERVERS active gi1/10
1002 fddi-default suspended
1003 token-ring-default suspended
1004 fddinet-default suspended
1005 trnet-default suspended

For switches running in VTP server or client mode, the list of VLANs are
stored in a database file named vlan.dat. The vlan.dat file is usually stored
in flash, though on some switch models it is stored in NVRAM. The VLAN
database will be maintained even if the switch is rebooted.
For switches running in VTP transparent mode, the list of VLANs is stored
in the startup-config file in NVRAM. VTP is covered extensively later in
this guide.
Regardless of VTP mode, the VLAN assignment for every switch interface
is stored in the switch’s startup-config.

***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Virtual LANs (VLANs) and VTP v1.31 – Aaron Balchunas 6

VLAN Port Types

A VLAN-enabled switch supports two types of ports:
• Access ports
• Trunk ports
An access port is a member of only a single VLAN. Access ports are most
often used to connect host devices, such as computers and printers. By
default on Cisco switches, all switch ports are access ports.
Any host connected to an access port immediately becomes a member of the
VLAN configured on that port. This is transparent to the host - it is unaware
that it belongs to a VLAN.
It is possible for a VLAN to span more than one switch. There are two
methods of connecting a VLAN across multiple switches:
• Create uplink access ports between the switches, one for each VLAN.
• Create a trunk connection between the switches.
A trunk port is not a member of a single VLAN. The traffic from any or all
VLANs can traverse trunk links to reach other switches.
Uplinking access ports quickly becomes unfeasible in large switching
environments. The following illustrates the advantage of using trunk ports:

***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Virtual LANs (VLANs) and VTP v1.31 – Aaron Balchunas 7

VLAN Frame-Tagging
When VLANs span multiple switches, a mechanism is required to identify
which VLAN a frame belongs to. This is accomplished through frame
tagging, which places a VLAN ID in each frame.
Tagging only occurs when a frame is sent out a trunk port. Traffic sent out
access ports is never tagged. Consider the following example:
SwitchA SwitchB

Trunk - VLANs 100, 200

gi gi
/ 11

/ 21
/10 1/
12 /20 1/
22
gi1 gi1
gi 1

gi1
HostA HostB HostC HostD HostE HostF
VLAN 100 VLAN 100 VLAN 200 VLAN 100 VLAN 100 VLAN 200

If HostA sends a frame to HostB, no frame tagging will occur:

• The frame never leaves the SwitchA.
• The frame stays within its own VLAN.
• The frame is simply switched to HostB.
If HostA sends a frame to HostC, which is in a separate VLAN:
• The frame again never leaves the switch.
• Frame tagging will still not occur.
• Because HostC is in a different VLAN, the frame must be routed.
If HostA sends a frame to HostD, which is on a separate switch:
• The frame is sent out the trunk port to SwitchB.
• The frame must be tagged as it is sent out the trunk port.
• The frame is tagged with its VLAN ID - VLAN 100 in this example.
• When SwitchB receives the frame, it will only forward it out ports
belonging to VLAN 100 – gi1/20 and gi1/21.
• If SwitchB has HostD’s MAC address in its table, it will forward the
frame only out the appropriate port – gi1/20.
• The VLAN tag is stripped from the frame before being forwarded to
the host.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Virtual LANs (VLANs) and VTP v1.31 – Aaron Balchunas 8

Frame Tagging Protocols

Cisco switches support two frame tagging protocols:
• Inter-Switch Link (ISL)
• IEEE 802.1Q
The tagging protocol can be manually specified on a trunk port, or
dynamically negotiated using Cisco’s proprietary Dynamic Trunking
Protocol (DTP).

Inter-Switch Link (ISL)

Inter-Switch Link (ISL) is Cisco’s proprietary frame tagging protocol. ISL
supports several technologies:
• Ethernet
• Token Ring
• FDDI
• ATM
ISL encapsulates a frame with an additional header (26 bytes) and trailer (4
bytes). Thus, ISL increases the size of a frame by 30 bytes.
The header contains several fields, including a 15-bit VLAN ID. The trailer
contains an additional 4-byte CRC to verify data integrity.
Normally, the maximum possible size of an Ethernet frame is 1518 bytes.
This is known as the Maximum Transmission Unit (MTU). Most Ethernet
devices use a default MTU of 1514 bytes.
ISL increases the frame size by another 30 bytes. Thus, most switches will
disregard ISL-tagged frames as being oversized, and drop the frame. An
oversized frame is usually referred to as a giant. Somewhat endearingly, a
slightly oversized frame is known as a baby giant.
Cisco switches are specifically engineered to support these giant ISL –
tagged frames. Note that this is a key reason why ISL is Cisco-proprietary.
ISL supports a maximum of 1000 VLANs on a trunk port. ISL is also almost
entirely deprecated - most modern Cisco switches no longer support it.
(Reference: http://www.cisco.com/c/en/us/support/docs/lan-switching/8021q/17056-741-4.html)
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Virtual LANs (VLANs) and VTP v1.31 – Aaron Balchunas 9

IEEE 802.1Q
IEEE 802.1Q, otherwise referred to as dot1Q, is an industry-standard
frame-tagging protocol.
802.1Q is supported by nearly all switch manufacturers, including Cisco.
Because 802.1Q is an open standard, switches from different vendors can be
trunked together.
Recall that ISL encapsulates a frame with an additional header and trailer. In
contrast, 802.1Q embeds a 4-byte VLAN tag directly into the Layer-2 frame
header. Because the Layer-2 header is modified, 802.1Q must recalculate the
frame’s CRC value.
The VLAN tag includes a 12-bit VLAN ID. This tag increases the size of an
Ethernet frame, from its default of 1514 bytes to 1518 bytes. Nearly all
modern switches support the 802.1Q tag and the slight increase in frame
size.
802.1Q supports a maximum of 4096 VLANs on a trunk port.

Configuring Trunk Links

To manually configure an interface as a trunk port:
Switch(config)# interface gi2/24
Switch(config-if)# switchport mode trunk

For a switch that supports both ISL and 802.1Q, the tagging or
encapsulation protocol must be configured first:
Switch(config)# interface gi2/24
Switch(config-if)# switchport trunk encapsulation isl
Switch(config-if)# switchport mode trunk
Switch(config)# interface gi2/24
Switch(config-if)# switchport trunk encapsulation dot1q
Switch(config-if)# switchport mode trunk

Important note: Both sides of the trunk must be configured with the same
tagging protocol. Otherwise, a trunk connection will not form.
If the switch only supports 802.1Q, the switchport trunk encapsulation
command will not be available.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Virtual LANs (VLANs) and VTP v1.31 – Aaron Balchunas 10

Configuring Trunk Links (continued)

The switch can negotiate the tagging protocol, using DTP:
Switch(config)# interface gi2/24
Switch(config-if)# switchport trunk encapsulation negotiate
Switch(config-if)# switchport mode trunk

The tagging protocol that is supported by both switches will be used. If the
switches support both ISL and 802.1Q, ISL will be the preferred protocol.
By default, all active VLANs are allowed to traverse a trunk link. While this
is convenient, a good security practice is to allow only necessary VLANs
over a trunk.
To explicitly allow a subset of VLANs on a trunk port:
Switch(config)# interface gi2/24
Switch(config-if)# switchport trunk allowed vlan 3,9,11-15

The above command will force the trunk link to only forward traffic from
VLANS 3, 9, and 11 – 15. To remove a VLAN from the allowed list:
Switch(config)# interface gi2/24
Switch(config-if)# switchport trunk allowed vlan remove 12

To add a specific VLAN back into the allowed list:

Switch(config)# interface gi2/24
Switch(config-if)# switchport trunk allowed vlan add 25

Important Note: It is common to restrict the allowed VLANs on a trunk

link, and then add to the allowed list as new VLANs are created. However,
don’t forget to use the add parameter. If add is omitted, the command will
replace the list of allowed VLANs on the trunk link, to the great distress of
network admins everywhere (sorry Karl). Always remember to add! ☺
To allow all VLANs except for a specific range:
Switch(config-if)# switchport trunk allowed vlan except 50-99

To allow all VLANs again:

Switch(config-if)# switchport trunk allowed vlan all

***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Virtual LANs (VLANs) and VTP v1.31 – Aaron Balchunas 11

Native VLANs
Recall that a trunk port tags frames with a VLAN ID. But what happens if a
trunk port receives an untagged frame?
The native VLAN determines the VLAN that untagged traffic belongs to.
By default on all trunking ports, the native VLAN is VLAN 1. The native
VLAN can be changed on a per trunk port basis:
Switch(config)# interface gi2/24
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport trunk native vlan 42

Only one native VLAN can be assigned to a trunk port. All untagged traffic
received on this port will become a member of the native VLAN.
Additionally, frames belonging to the native VLAN are not tagged when
being sent out a trunk port.
Native VLANS are only supported on 802.1Q trunk ports. ISL does not
support untagged frames, and will always tag frames from all VLANs.
The native VLAN must be configured identically on both sides of the
802.1Q trunk, otherwise the switches will not form a trunk connection.
The original intent of native VLANs was for legacy compatibility with hubs.
Consider the following deprecated example:

The hub has no knowledge of VLANs or 802.1Q. Traffic from hosts

connected to the hub will be forwarded to the switches untagged, which in
turn will place the untagged traffic into the native VLAN.
Native VLANs pose a security risk, allowing an attacker to hop to another
VLAN by double-tagging a frame. This can be mitigated by changing the
native VLAN to an unused or disabled VLAN. A better solution is to force
trunk ports to tag native VLAN traffic - globally or on a per-trunk basis:
Switch(config)# vlan dot1q tag native
Switch(config)# interface gi2/24
Switch(config-if)# switchport trunk native vlan tag
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Virtual LANs (VLANs) and VTP v1.31 – Aaron Balchunas 12

Dynamic Trunking Protocol (DTP)

Recall that a trunk’s frame tagging protocol can be autonegotiated, through
the use of the Dynamic Trunking Protocol (DTP).
DTP can also negotiate whether a port becomes a trunk at all. Previous
examples demonstrated how to manually configure a port to trunk:
Switch(config)# interface gi2/24
Switch(config-if)# switchport mode trunk

DTP has two modes to dynamically decide whether a port becomes a trunk:
• Desirable – the port will actively attempt to form a trunk with the
remote switch. This is the default setting.
• Auto – the port will passively wait for the remote switch to initiate the
trunk.
To configure the DTP mode on an interface:
Switch(config)# interface gi2/24
Switch(config-if)# switchport mode dynamic desirable
Switch(config-if)# switchport mode dynamic auto

Trunk ports send out DTP frames every 30 seconds to indicate their
configured mode.
A trunk will form in the following configurations:
• manual trunk manual trunk
• manual trunk dynamic desirable
• manual trunk dynamic auto
• dynamic desirable dynamic desirable
• dynamic desirable dynamic auto
A trunk will never form if the two sides of the trunk are set to dynamic auto,
as both ports are waiting for the other to initialize the trunk.
It is best practice to manually configure trunk ports, to avoid DTP
negotiation errors. DTP is also vulnerable to VLAN spoofing attacks.
To explicitly disable DTP:
Switch(config)# interface gi2/24
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport nonegotiate
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Virtual LANs (VLANs) and VTP v1.31 – Aaron Balchunas 13

Troubleshooting Trunk Connections

A trunk connection requires several parameters to be configured identically
on both sides of the trunk:
• Trunk Mode
• Frame-tagging protocol
• Native VLAN
• Allowed VLANs
• VTP Domain – only when using DTP to negotiate a trunk
If there is a mismatch in configuration, the trunk connection will never
become active.
To determine whether an interface is an access or trunk port:
Switch# show interface gi2/24 switchport
Name: Gi2/24
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: Off
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 42

<snip>

To view the status of all trunk links:

Switch# show interface trunk
Port Mode Encapsulation Status Native VLAN
Fa0/24 on 802.1q trunking 42

Port Vlans allowed on trunk

Fa0/24 3,9,11-15

Port Vlans allowed and active in management domain

Fa0/24 3,9

Port Vlans in spanning tree forwarding state and not pruned

Fa0/24 3,9

Note that VLANs 11-15 are not active. Most likely, no interfaces have been
assigned to those VLANs.
If there are no interfaces in an active trunking state, the show interface trunk
command will return no output.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Virtual LANs (VLANs) and VTP v1.31 – Aaron Balchunas 14

VLAN Trunking Protocol (VTP)

Maintaining a consistent VLAN database can be difficult in a large
switching environment.
Cisco’s proprietary VLAN Trunking Protocol (VTP) simplifies this
management - updates to the VLAN database are propagated to all switches
using VTP advertisements.
VTP requires that all participating switches join a VTP domain. Switches
must belong to the same domain to share VLAN information, and a switch
can only belong to a single domain.

VTP Versions
There are three versions of VTP. VTP version 1 supports the standard 1 –
1005 VLAN range. VTP version 1 is also default on Catalyst switches.
VTP version 2 introduces some additional features:
• Token Ring support
• VLAN consistency checks
• Domain-independent transparent pass through
VTPv1 and v2 are not compatible. The VTP version is dictated by the VTP
server, discussed in detail shortly. If the VTP server is configured for
VTPv2, all other switches in the VTP domain will change to v2 as well.
Until recently, VTP Version 3 was supported on only limited Cisco switch
platforms. VTPv3 was built to be flexible, and can forward both VLAN and
other database information, such as Multiple Spanning Tree (MST) protocol.
Other enhancements provided by VTPv3 include:
• Support for the extended 1006-4094 VLAN range.
• Support for private VLANs.
• Improved VTP authentication.
• Protection from accidental database overwrites, by using VTP primary
and secondary servers.
• Ability to enable VTP on a per-port basis.

(Reference: http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3560/software/release/12-2_52_se/configuration/guide/3560scg/swvtp.html)

***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Virtual LANs (VLANs) and VTP v1.31 – Aaron Balchunas 15

VTP Modes
A switch using VTP must operate in one of three modes:
• Server
• Client
• Transparent
VTP servers are responsible for creating, deleting, or modifying entries in
the VLAN database. Each VTP domain must have at least one VTP server,
and this is the default mode for Cisco switches.
Servers advertise the VLAN database to all other switches in the VTP
domain, including other servers. VTP servers can only advertise the standard
1-1005 VLAN range, and advertisements are only sent out trunk ports.
VTP clients cannot modify the VLAN database, and rely on advertisements
from other switches to update VLAN information. A client will also forward
VTP advertisements out every trunk port.
Remember: switches must be in the same VTP Domain to share and accept
updates to the VLAN database. Only servers can change the VLAN
database.
A VTP transparent switch maintains its own local VLAN database, and
does not directly participate in the VTP domain. A transparent switch will
never accept VLAN database information from another switch, even a
server. Also, a transparent switch will never advertise its local VLAN
database to another switch.
Transparent switches will pass through advertisements from other switches
in the VTP domain. The VTP version dictates how the pass through is
handled:
• VTP version 1 – the transparent switch will only pass through
advertisements from the same VTP domain.
• VTP version 2 – the transparent switch will pass through
advertisements from any VTP domain.

***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Virtual LANs (VLANs) and VTP v1.31 – Aaron Balchunas 16

VTP Advertisements – Revision Number

Recall that updates to the VLAN database are propagated using VTP
advertisements. VTP advertisements are always sent out trunk ports, on
VLAN 1.
VTP advertisements are marked with a 32-bit configuration revision
number, to identify the most current VLAN database revision. Any change
to the VLAN database increments the configuration revision number by 1.
Thus, a higher number represents a newer database revision.
A switch will only accept an advertisement if the revision number is higher
than the current VLAN database. Advertisements with a lower revision
number are ignored.
Important note: While only VTP servers can change the VLAN database,
VTP clients can advertise updates, to other clients and even to a server! As
long as the revision number is higher, the switch will accept the update.
This can result in a newly-introduced switch advertising a blank or incorrect
VLAN database to all other switches in the domain. Switch ports would then
lose their VLAN memberships, resulting in a significant network outage.
This can be avoided when implementing a new switch into the VTP domain.
Best practice is to configure a new switch as a VTP client, and reset its
revision number to zero before deploying into a production network.
There are two methods of resetting the revision number to zero on a switch:
1. Change the VTP domain name, and then change it back to the original
name.
2. Change the VTP mode to transparent, and then change it back to
either server or client. Transparent switches always a revision number
of 0.
VTP has fallen out of favor, due to the risk of an unintentional overwrite of
the VLAN database. Until very recently, Cisco did not support VTP on the
Nexus platform of switches.
VTPv3 directly addresses this risk through the use of VTP primary and
secondary servers. Only the primary server is allowed to update the VLAN
database on other switches. Only one primary server is allowed per domain.
(Reference: http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/solution_guide_c78_508010.html)

***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Virtual LANs (VLANs) and VTP v1.31 – Aaron Balchunas 17

VTP Advertisements – Message Types

Three message types exist for VTP advertisements:
• Summary Advertisement
• Subset Advertisement
• Advertisement Request
Both VTP servers and clients will send out a summary advertisement
every 300 seconds. Summary advertisements contain the following
information about the VTP domain:
• VTP version
• Domain name
• Configuration revision number
• Time stamp
• MD5 digest
Summary advertisements are also sent when a change occurs to the VLAN
database. The summary is then followed with a subset advertisement,
which actually contains the full, updated VLAN database.
A subset advertisement will contain the following information:
• VTP version
• Domain name
• Configuration revision number
• VLAN IDs for each VLAN in the database
• VLAN-specific information, such as the VLAN name and MTU
Important note: Switches will only accept summary and subset
advertisements if the domain name and MD5 digest match. Otherwise, the
advertisements are ignored.
If a switch receives a summary advertisement with a revision number higher
than its own, it will send out an advertisement request. VTP servers will
then respond with an updated summary and subset advertisement so that the
switch can synchronize to the most current VLAN database.
A switch that is reset or newly joined to the VTP domain will also send out
an advertisement request.

(Reference: http://www.cisco.com/c/en/us/support/docs/lan-switching/vtp/10558-21.html#vtp_msg)

***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Virtual LANs (VLANs) and VTP v1.31 – Aaron Balchunas 18

Configuring VTP
By default, a switch is in VTP server mode, and joined to a blank domain
labeled NULL.
To change the VTP domain name:
Switch(config)# vtp domain MYDOMAIN

Note that the domain name is case sensitive. To configure the VTP mode:
Switch(config)# vtp mode server
Switch(config)# vtp mode client
Switch(config)# vtp mode transparent

The VTP domain can be secured using a password:

Switch(config)# vtp password P@SSWORD!

The password is also case sensitive. All switches participating in the VTP
domain must be configured with the same password. The password is hashed
into a 16-byte MD5 digest.
Cisco switches use VTP version 1 by default, which is not compatible with
VTPv2. The VTP version is dictated by the VTP server, and if the server is
configured for VTPv2, all other switches in the VTP domain will change to
v2 as well.
Switch(config)# vtp version 2

To view status information about VTP:

Switch# show vtp status
VTP Version : 2
Configuration Revision : 42
Maximum VLANs supported locally : 1005
Number of existing VLANs : 7
VTP Operating Mode : Server
VTP Domain Name : MYDOMAIN
VTP Pruning Mode : Disabled
VTP V2 Mode : Enabled
VTP Traps Generation : Disabled
MD5 digest : 0x42 0x51 0x69 0xBA 0xBE 0xFA 0xCE 0x34
Configuration last modified by 0.0.0.0 at 6-22-14 4:07:52

To view VTP statistical information and error counters:

Switch# show vtp counters

***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Virtual LANs (VLANs) and VTP v1.31 – Aaron Balchunas 19

VTP Pruning
Recall that Layer-2 switches belong to only one broadcast domain. A
Layer-2 switch will thus forward both broadcasts and multicasts out every
port in the same VLAN but the originating port. This includes sending out
broadcasts out trunk ports to other switches, which will in turn flood that
broadcast out all ports in the same VLAN.
VTP pruning eliminates unnecessary broadcast or multicast traffic
throughout the switching infrastructure. Consider the following example:

Assume that a host is connected to SwitchB, in VLAN 300. If the host sends
out a broadcast, SwitchB will forward the broadcast out every port in VLAN
300, including the trunk ports to SwitchA and SwitchC. Both SwitchA and
SwitchC will then forward that broadcast out every port in VLAN 300.
However, SwitchA does not have any ports in VLAN 300, and will drop the
broadcast. Thus, sending the broadcast to SwitchA is a waste of bandwidth.
VTP pruning allows a switch to learn which VLANs are active on its
neighbors. Thus, broadcasts are only sent out the necessary trunk ports
where those VLANs exist. In the preceding example, pruning would prevent
VLAN 300 broadcasts from being sent to SwitchA, and would prevent
VLAN 100 and 200 broadcasts from being sent to SwitchC.
VTP pruning is disabled by default on IOS switches. VTP pruning must be
enabled on a server, and will be applied globally to the entire VTP domain:
Switch(config)# vtp pruning

Both VLAN 1 and the system VLANs 1002-1005 are never eligible for
pruning. To manually specify which VLANs are pruning eligible on a trunk:
Switch(config)# interface gi2/24
Switch(config-if)# switchport trunk pruning vlan 2-10
Switch(config-if)# switchport trunk pruning vlan add 42
Switch(config-if)# switchport trunk pruning vlan remove 5
Switch(config-if)# switchport trunk pruning vlan except 100-200
Switch(config-if)# switchport trunk pruning vlan none
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
EtherChannel v1.11 – Aaron Balchunas 1

- EtherChannel -
Port Aggregation
A network will often span across multiple switches. Trunk ports are usually
used to connect switches together.
There are two issues with using only a single physical port for the trunk
connection:
• The port represents a single point of failure. If the port goes down,
the trunk connection is lost.
• The port represents a traffic bottleneck. All other ports on the switch
will use that one port to communicate across the trunk connection.
Thus, the obvious benefits of adding redundancy to the trunk connection are
fault tolerance and increased bandwidth, via load balancing.
However, simply trunking two or more ports between the switches will not
work, as this creates a switching loop. One of two things will occur:
• Spanning Tree Protocol (STP) will disable one or more ports to
eliminate the loop.
• If STP is disabled, the switching loop will result in an almost
instantaneous broadcast storm, crippling the network.
Port aggregation allows multiple physical ports to be bundled together to
form a single logical port. The switch and STP will treat the bundled ports as
a single interface, eliminating the possibility of a switching loop.
Cisco’s implementation of port aggregation is called EtherChannel.
EtherChannel supports Fast, Gigabit, and 10 Gigabit Ethernet ports.
A maximum of 8 active ports are supported in a single EtherChannel. If the
ports are operating in full duplex, the maximum theoretical bandwidth
supported is as follows:
• Fast Ethernet – 1600 Mbps
• Gigabit Ethernet – 16 Gbps
• 10 Gigabit Ethernet – 160 Gbps
The maximum number of supported EtherChannels on a single switch is
platform-dependent, though most support up to 64 or 128 EtherChannels.

EtherChannel Requirements
The previous section described the benefits of port aggregation for a trunk
connection. However, EtherChannels can be formed with either access or
trunk ports. EtherChannels are also supported on Layer-3 interfaces.
Implementing an EtherChannel for access ports provides increased
bandwidth and redundancy to a host device, such as a server. However, the
host device must support a port aggregation protocol, such as LACP. Port
aggregation protocols are covered in great detail later in this guide.
Similarly, implementing EtherChannel for trunk connections provides
increased bandwidth and redundancy to other switches.

If a port in an EtherChannel bundle fails, traffic will be redistributed across

the remaining ports in the bundle. This happens nearly instantaneously.
For an EtherChannel to become active, all ports in the bundle must be
configured identically, regardless if the EtherChannel is being used with
access or trunk ports. Port settings that must be identical include the
following:
• Speed settings
• Duplex settings
• STP settings
• VLAN membership (for access ports)
• Native VLAN (for trunk ports)
• Allowed VLANs (for trunk ports)
• Trunking encapsulation protocol (for trunk ports)
On trunk connections, the above settings must be configured identically
across all participating ports on both switches.
Historically, port-security has not been supported on an EtherChannel.
Newer platforms may provide support as long as port-security is enabled on
both the physical interfaces and the EtherChannel itself.

EtherChannel Load-Balancing
Traffic sent across an EtherChannel is not evenly distributed across all ports
in the bundle. Instead, EtherChannel utilizes a load-balancing algorithm to
determine the port to send the traffic out, based on one of several criteria:
• Source IP address - src-ip
• Destination IP address - dst-ip
• Source and destination IP address - src-dst-ip
• Source MAC address - src-mac
• Destination MAC address - dst-mac
• Source and Destination MAC address - src-dst-mac
• Source TCP/UDP port number - src-port
• Destination TCP/UDP port number - dst-port
• Source and destination port number - src-dst-port
Using a deterministic algorithm prevents perfect load-balancing. However, a
particular traffic flow is forced to always use the same port in the bundle,
preventing out-of-order delivery.
The default load-balancing method for a Layer-2 EtherChannel is either src-
mac or src-dst-mac, depending on the platform. The default method for a
Layer-3 EtherChannel is src-dst-ip.
The load-balancing method must be configured globally on the switch:
Switch(config)# port-channel load-balance src-dst-mac

To display the currently configured load-balancing method:

Switch# show etherchannel load-balance
EtherChannel Load-balancing Configuration:
src-dst-mac

To view the load on each port in an EtherChannel (output abbreviated):

Switch# show etherchannel 1 port-channel
Index Load Port EC state
------+------+--------+------------
0 55 Gi2/23 active
1 3A Gi2/24 active

The load is rather cryptically represented in a hexadecimal value.

(Reference: http://www.cisco.com/c/en/us/support/docs/lan-switching/etherchannel/12023-4.html)
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
EtherChannel v1.11 – Aaron Balchunas 4

EtherChannel Load-Balancing Example

Consider the following example, where ports gi2/23 and gi2/24 on both
switches are members of an EtherChannel:

Assume that the load-balancing method is src-ip. The first port in the
EtherChannel will become Link0; the second will become Link1.
The two links in the EtherChannel can be represented in one binary bit. The
load-balancing algorithm will create an index that associates Link0 with a
binary bit of 0, and Link1 with a bit of 1.

As traffic passes through the EtherChannel, the algorithm will convert the
source IP addresses into a binary hash, to compare against the index. For
example, consider the following IP addresses and their binary equivalents:
10.1.1.2 00001010.00000001.00000001.00000010
10.1.1.3 00001010.00000001.00000001.00000011

Because there are only two ports in the EtherChannel, only one bit needs to
be considered in the IP address – the last bit. The first address ends with a 0
bit, and thus would be sent out Link0. The second address ends with a 1 bit,
and thus would be sent down Link1. Simple, right?
An EtherChannel that contained four ports would require a 2-bit index,
requiring that the last two bits of the IP address be considered:
Link0 00
Link1 01
Link2 10
Link3 11
Best practice dictates that EtherChannels should contain an even number of
ports, to promote uniform load-balancing. An EtherChannel can support an
odd number of ports; however, this may result in one of the ports being
severely overburdened due to uneven load-balancing.

EtherChannel Load-Balancing Example (continued)

Consider again the following example:

This time, assume that the load-balancing method is src-dst-ip. Again, the
first port in the EtherChannel will become Link0; the second will become
Link1.
Both the source and destination IP must be considered when choosing a link.
This requires performing an exclusive OR (XOR) operation. In an XOR
operation, if the two values being compared are equal, the result is 0. If the
two values are not equal, the result is 1.
The following illustrates all possible results with a 1-bit index:
Source 0 1 0 1
Destination 0 0 1 1
Result 0 1 1 0

Consider the following source and destination IP address pair:

Source 192.168.1.10 11000000.10101000.00000001.00001010
Destination 192.168.2.25 11000000.10101000.00000010.00011001

The XOR result of the above address pair would be 1. Thus, the traffic
would be sent out Link1.
The following illustrates all possible results with a 2-bit index, representing
four ports:
Source 00 00 00 00 01 01 01 01 10 10 10 10 11 11 11 11
Destination 00 01 10 11 00 01 10 11 00 01 10 11 00 01 10 11
Result 00 01 10 11 01 00 11 10 10 11 00 01 11 10 01 00

There are four possible results (00, 01, 10, 11), corresponding to the four
ports in the EtherChannel.
Regardless of the load-balancing method used, STP will always send its
packets through the first operational port in an EtherChannel bundle.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
EtherChannel v1.11 – Aaron Balchunas 6

EtherChannel – Manual Configuration

There are two methods of configuring an EtherChannel:
• Manually
• Dynamically, using an aggregation protocol
To manually configure two ports to join an EtherChannel:
Switch(config)# interface range gi2/23 - 24
Switch(config-if)# channel-group 1 mode on
The remote switch must also have the EtherChannel manually configured as
on. Remember that speed, duplex, VLAN, and STP configuration must be
configured identically across all participating ports on both switches.
The channel-group number identifies the EtherChannel on the local switch.
This number does not need to match on both switches, though for
documentation purposes it should.
Adding switch ports to a channel-group creates a logical port-channel
interface. This interface can be configured by referencing the channel-
group number:
Switch(config)# interface port-channel 1
Switch(config-if)#

Changes made to the logical port-channel interface are applied to all

physical switch ports in the channel-group:
Switch(config)# interface port-channel 1
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport trunk allowed vlan 50-100

To configure a port-channel as a Layer-3 interface:

Switch(config)# interface port-channel 1
Switch(config-if)# no switchport
Switch(config-if)# ip address 192.168.10.1 255.255.255.0

By default, a port-channel interface is administratively shutdown. To bring

the port-channel online:
Switch(config)# interface port-channel 1
Switch(config-if)# no shut

Physical port properties, such as speed and duplex, must be configured on

the physical interface, and not on the port-channel interface.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
EtherChannel v1.11 – Aaron Balchunas 7

EtherChannel – Dynamic Configuration

Cisco switches support two dynamic aggregation protocols:
• PAgP (Port Aggregation Protocol) – Cisco proprietary aggregating
protocol.
• LACP (Link Aggregation Control Protocol) – IEEE standardized
aggregation protocol, originally defined in 802.3ad.
Both PAgP and LACP exchange negotiation packets to form the
EtherChannel. When an EtherChannel is configured manually, no
negotiation packets are exchanged.
Thus, an EtherChannel will never form if one switch manually configured
the EtherChannel, and the other switch is using a dynamic aggregation
protocol.
PAgP and LACP are not compatible – both sides of an EtherChannel must
use the same aggregation protocol.

EthernChannel - PAgP
PAgP is a Cisco-proprietary aggregation protocol, and supports two modes:
• Desirable – actively attempts to form a channel
• Auto – waits for the remote switch to initiate the channel
A PAgP channel will form in the following configurations:
• desirable desirable
• desirable auto
A channel will not form if both sides are set to auto. Also, PAgP will not
form a channel if the remote side is running LACP, or manually configured.
To create an EtherChannel using PAgP negotiation:
Switch(config)# interface range gi2/23 – 24
Switch(config-if)# channel-protocol pagp
Switch(config-if)# channel-group 1 mode desirable
Switch(config-if)# channel-group 1 mode auto

PAgP requires that speed, duplex, VLAN, and STP configuration be

configured identically across all participating ports.

EtherChannel - LACP
LACP is an IEEE standard aggregation protocol, and supports two modes:
• Active – actively attempts to form a channel
• Passive – waits for the remote switch to initiate the channel
An LACP channel will form in the following configurations:
• active active
• active passive
A channel will not form if both sides are set to passive. Also, LACP will
not form a channel if the remote side is running PAgP, or manually
configured.
To create an EtherChannel using LACP negotiation:
Switch(config)# interface range gi2/23 – 24
Switch(config-if)# channel-protocol lacp
Switch(config-if)# channel-group 1 mode active
Switch(config-if)# channel-group 1 mode passive
LACP requires that speed, duplex, VLAN, and STP configuration be
configured identically across all participating ports.
Recall that a maximum of 8 active ports are supported in a single
EtherChannel. LACP supports adding an additional 8 ports into the bundle
in a standby state, to replace an active port if it goes down.
LACP assigns a numerical port-priority to each port, to determine which
ports become active in the EtherChannel. By default, the priority is set to
32768, and a lower priority is preferred. If there is a tie in port-priority, the
lowest port number is preferred.
To change the LACP port-priority to something other than default:
Switch(config)# interface range gi2/23 – 24
Switch(config-if)# lacp port-priority 100
LACP also assigns a system-priority to each switch, dictated which switch
becomes the decision-maker if there is a conflict about active ports. The
default system-priority is 32768, and a lower priority is again preferred. If
there is a tie in system-priority, the lowest switch MAC address is preferred.
To globally change the system-priority on a switch:
Switch(config)# lacp system-priority 500
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
EtherChannel v1.11 – Aaron Balchunas 9

Troubleshooting EtherChannel
To view status information on all configured EtherChannels:
Switch# show etherchannel summary

Flags: D - down P - in port-channel

I - stand-alone s - suspended
R - Layer3 S - Layer2
U - port-channel in use

Group Port-channel Ports

---------- --------------- ---------------
1 Po1(SU) Gi2/23(P) Gi2/24(P)

Note that both ports have a status of P, which indicates that they are up and
active in the EtherChannel.
On Cisco Nexus switches, the syntax for this command is slightly different:
NexusSwitch# show port-channel summary

- Spanning Tree Protocol -

Switching Loops
A Layer-2 switch belongs to only one broadcast domain, and will forward
both broadcasts and multicasts out every port but the originating port.
When a switching loop is introduced into the network, a destructive
broadcast storm will develop within seconds. A storm occurs when
broadcasts are endlessly forwarded through the loop. Eventually, the storm
will choke off all other network traffic.
Consider the following example:

If HostA sends out a broadcast, SwitchD will forward the broadcast out all
ports in the same VLAN, including the trunk ports connecting to SwitchB
and SwitchE. In turn, those two switches will forward that broadcast out all
ports, including the trunks to the neighboring SwitchA and SwitchC.
The broadcast will loop around the switches infinitely. In fact, there will be
two separate broadcast storms cycling in opposite directions through the
switching loop. Only powering off the switches or physically removing the
loop will stop the storm.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Spanning Tree Protocol v1.31 – Aaron Balchunas 2

Spanning Tree Protocol (STP)

Spanning Tree Protocol (STP) was developed to prevent the broadcast
storms caused by switching loops. STP was originally defined in IEEE
802.1D.
Switches running STP will build a map or topology of the entire switching
network. STP will identify if there are any loops, and then disable or block
as many ports as necessary to eliminate all loops in the topology.
A blocked port can be reactivated if another port goes down. This allows
STP to maintain redundancy and fault-tolerance.
However, because ports are blocked to eliminate loops, STP does not
support load balancing unless an EtherChannel is used. EtherChannel is
covered in great detail in another guide.
STP switches exchange Bridge Protocol Data Units (BPDU’s) to build the
topology database. BPDU’s are forwarded out all ports every two seconds,
to a dedicated MAC multicast address of 0180.c200.0000.
Building the STP topology is a multistep convergence process:
• A Root Bridge is elected
• Root ports are identified
• Designated ports are identified
• Ports are placed in a blocking state as required, to eliminate loops
The Root Bridge serves as the central reference point for the STP topology.
STP was originally developed when Layer-2 bridges were still prevalent,
and thus the term Root Bridge is still used for nostalgic reasons. It is also
acceptable to use the term Root Switch, though this is less common.
Once the full topology is determined, and loops are eliminated, the switches
are considered converged.
STP is enabled by default on all Cisco switches, for all VLANs.

Electing an STP Root Bridge

The first step in the STP convergence process is electing a Root Bridge,
which is the central reference point for the STP topology. As a best practice,
the Root Bridge should be the most centralized switch in the STP topology.
A Root Bridge is elected based on its Bridge ID, comprised of two
components in the original 802.1D standard:
• 16-bit Bridge priority
• 48-bit MAC address
The default priority is 32,768, and the lowest priority wins. If there is a tie
in priority, the lowest MAC address is used as the tie-breaker.
Consider the following example:
SwitchA
Priority: 100
MAC: 0000.1111.2222

SwitchB SwitchC
Priority: 32,768 Priority: 32,768
MAC: 0000.2222.3333 MAC: 0000.6666.7777

SwitchD SwitchE
Priority: 100 Priority: 32,768
MAC: 0000.4444.5555 MAC: 0000.8888.9999

Switches exchange BPDU’s to perform the election process, and the lowest
Bridge ID determines the Root Bridge:
• SwitchB, SwitchC, and SwitchE have the default priority of 32,768.
• SwitchA and SwitchD are tied with a lower priority of 100.
• SwitchA has the lowest MAC address, and will be elected the Root
Bridge.
By default, a switch will always believe it is the Root Bridge, until it
receives a BPDU from a switch with a lower Bridge ID. This is referred to
as a superior BPDU. The election process is continuous – if a new switch
with the lowest Bridge ID is added to the topology, it will be elected as the
Root Bridge.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Spanning Tree Protocol v1.31 – Aaron Balchunas 4

Identifying Root Ports

The second step in the STP convergence process is to identify root ports.
The root port of each switch has the lowest root path cost to get to the Root
Bridge.
Each switch can only have one root port. The Root Bridge cannot have a
root port, as the purpose of a root port is to point to the Root Bridge.
Path cost is a cumulative cost to the Root Bridge, based on the bandwidth of
the links. The higher the bandwidth, the lower the path cost:
Bandwidth Cost
4 Mbps 250
10 Mbps 100
16 Mbps 62
45 Mbps 39
100 Mbps 19
155 Mbps 14
1 Gbps 4
10 Gbps 2
A lower cost is preferred. Consider the following example:

Each 1Gbps link has a path cost of 4. SwitchA has a cumulative path cost of
0, because it is the Root Bridge. Thus, when SwitchA sends out BPDU’s, it
advertises a root path cost of 0.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Spanning Tree Protocol v1.31 – Aaron Balchunas 5

Identifying Root Ports (continued)

SwitchB has two paths to the Root Bridge:
• A direct connection to SwitchA, with a path cost of 4.
• Another path through SwitchD, with a path cost of 16.

The lowest cumulative path cost is considered superior, thus the port
directly connecting to SwitchA will become the root port. A BPDU
advertising a higher path cost is often referred to as an inferior BPDU.
SwitchD also has two paths to the Root Bridge:
• A path through SwitchB, with a path cost of 8.
• A path through SwitchE, with a path cost of 12.
• The port to SwitchB is preferred, and will become the root port.
Recall that the Root Bridge will advertise BPDU’s with a path cost of 0. As
the downstream switches receive these BPDU’s, they will add the path cost
of the receiving port, and then advertise the cumulative cost to neighbors.
For example, SwitchC will receive a BPDU with a path cost of 0 from
SwitchA, which is the Root Bridge. SwitchC will add the path cost of its
receiving port, and thus SwitchC’s cumulative path cost will be 4.
SwitchC will advertise a path cost of 4 to SwitchE, which will add the path
cost of its receiving port. SwitchE’s cumulative path cost will thus be 8.
Path cost can be artificially adjusted on a per-port basis:
SwitchD(config)# int gi2/22
SwitchD(config-if)# spanning-tree vlan 101 cost 42
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Spanning Tree Protocol v1.31 – Aaron Balchunas 6

Identifying Designated Ports

The third step in the STP convergence process is to identify designated
ports. A single designated port is identified for each network segment. This
port is responsible for forwarding BPDUs and frames to that segment.
If two ports are eligible to become the designated port, then there is a loop.
One of the ports will be placed in a blocking state to eliminate the loop.
Similar to a root port, the designated port is determined by the lowest
cumulative path cost leading the Root Bridge. A designated port will never
be placed in a blocking state, unless there is a change to the switching
topology and a more preferred designated port is elected.
Note: A port can never be both a designated port and a root port.
Consider the following example:

Ports on the Root Bridge are never placed in a blocking state. Thus, the two
ports off of SwitchA will automatically become designated ports.
Remember, every network segment must have one designated port,
regardless if a root port already exists on that segment.
Thus, the network segments between SwitchB and SwitchD, and between
SwitchC and SwitchE, both require a designated port. The ports on SwitchD
and Switch E have already been identified as root ports, thus the ports on
Switch B and C will become the designated ports.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Spanning Tree Protocol v1.31 – Aaron Balchunas 7

Identifying Designated Ports (continued)

Note that the network segment between SwitchD and SwitchE does not
contain a root port:

Because two ports on this segment are eligible to become the designated
port, STP recognizes that a loop exists. One of the ports must be elected as
the designated port, and the other must be placed in a blocking state.
Normally, whichever switch has the lowest cumulative path cost will have
its port become designated. The switch with the highest path cost will have
its port blocked.
In the above example, there is a tie in cumulative path cost. Both SwitchD
and SwitchE have a path cost of 12 to reach the Root Bridge on that
segment.
The lowest Bridge ID is used as the tiebreaker. SwitchD has a priority of
100, and SwitchE has the default priority of 32,768.
Thus, the port on SwitchD will become the designated port. The port on
SwitchE will be placed in a blocking state.
As with electing the Root Bridge, if there is a tie in priority, the lowest
MAC address is used as the tie breaker.
Remember: Any port not elected as a root or designated port will be placed
in a blocking state.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Spanning Tree Protocol v1.31 – Aaron Balchunas 8

Port ID
When electing root and designated ports, it is possible to have a tie in both
path cost and Bridge ID. Consider the following example:

The bandwidth of both links is equal, thus both ports on SwitchB have an
equal path cost to the Root Bridge. Which port will become the root port
then? Normally, the lowest Bridge ID is used as the tiebreaker, but that is
not possible in this circumstance.
Port ID is used as the final tiebreaker, and consists of two components:
• 4-bit port priority
• 12-bit port number, derived from the physical port number
By default, the port priority of an interface is 128, and a lower priority is
preferred. If there is a tie in priority, the lowest port number is preferred.
The sender port ID determines the tie break, and not the local port ID. In the
above example, SwitchB must decide whether gi2/23 or gi2/24 becomes the
root port. SwitchB will observe BPDU’s from SwitchA, which will contain
the port ID’s for gi2/10 and gi2/11.
If priorities are equal, the sender Port ID from gi2/10 is preferred, due to the
lower port number. Thus, gi2/23 on SwitchB will become the root port.
The port number is a fixed value, but port priority can be changed on a per-
interface basis:
Switch(config)# int gi2/11
Switch(config-if)# spanning-tree vlan 101 port-priority 32
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Spanning Tree Protocol v1.31 – Aaron Balchunas 9

Port ID (continued)
Note: Some reference material may state that the Port ID is comprised of an
8-bit priority and 8-bit port number. This was accurate in the original
802.1D specification.
However, IEEE 802.1t revised the original specification to provide the
larger 12-bit port number field, to accommodate modular switches with high
port density.
Even more confusing – some whitepapers on Cisco’s website will define the
Port ID as a combination of port priority and MAC address, instead of port
number. This is not accurate in modern STP implementations.

Remember: Port ID is the last tiebreaker STP will consider. STP

determines root and designated ports using the following criteria, in order:
• Lowest path cost to the Root Bridge
• Lowest bridge ID
• Lowest sender port ID
Lowest Bridge ID is always used to determine the Root Bridge.

Versions of STP
There are three flavors of the original 802.1D version of STP:
• Common Spanning Tree (CST)
• Per-VLAN Spanning Tree (PVST)
• Per-VLAN Spanning Tree Plus (PVST+)
CST utilizes a single STP instance for all VLANs, and is sometimes referred
to as mono spanning tree. All CST BPDU’s are sent over the native VLAN
on a trunk port, and thus are untagged.
PVST employs a separate STP instance for each VLAN, improving
flexibility and performance. PVST requires trunk ports to use ISL
encapsulation. PVST and CST are not compatible.
The enhanced PVST+ is compatible with both CST and PVST, and supports
both ISL and 802.1Q encapsulation. PVST+ is the default mode on many
Cisco platforms.
STP has continued to evolve over time. Modern extensions of STP will be
covered later in this guide:
• Rapid Spanning Tree Protocol (RSTP)
• Multiple Spanning Tree (MST)

Extended System IDs

In the original 802.1D standard, the 64-bit Bridge ID consisted of two
components:
• 16-bit Bridge priority
• 48-bit MAC address
As STP evolved to operate on a per-VLAN basis, a unique Bridge ID
became mandatory for each VLAN. This was originally accomplished by
assigning a unique switch MAC address to the Bridge ID of each VLAN.
This approach suffered from scalability issues, requiring that a switch
support at least 1024 unique system MAC addresses – at least one per
VLAN.
IEEE 802.1t altered the Bridge ID to include an extended system ID,
which identifies the VLAN number of the STP instance. The Bridge ID
remained 64 bits, but now consisted of three components:
• 4-bit Bridge priority
• 12-bit System or VLAN ID
• 48-bit MAC address
By stealing 12 bits from the bridge priority, the range of priorities is altered:
• The original priority ranged from 0 to 65,535, with 32,768 as default.
• With extended system IDs, the new priority range is 0 to 61,440, and
the priority must be in multiples of 4,096.
• The default is still 32,768.
Extended system ID’s are enabled by default and cannot be disabled if a
switch platform does not support 1024 system MAC addresses.
For platforms that support 1024 MAC addresses, the extended system ID
can be manually enabled:
Switch(config)# spanning-tree extend system-id

Extended system IDs increase the number of supported VLANs in the STP
topology from 1005 to 4094.

Basic STP Configuration

STP is enabled by default on all Cisco switches, for all VLANs and ports.
PVST+ is the default STP mode on most modern Cisco platforms, allowing
each VLAN to run a separate STP instance.
STP can be disabled. This should be done with caution - any switching loop
will result in a broadcast storm. To disable STP for an entire VLAN:
Switch(config)# no spanning-tree vlan 101

A range of VLANs can be specified:

Switch(config)# no spanning-tree vlan 1 - 4094

STP can also be disabled on a per-port basis, for a specific VLAN:

Switch(config)# interface gi2/23
Switch(config-if)# no spanning-tree vlan 101

The switch with the lowest Bridge ID is elected as the Root Bridge. The
priority can be adjusted from its default of 32,768, to increase the likelihood
that a switch is elected as the Root Bridge.
Priority can be configured on a per-VLAN basis. Remember that the priority
must be in multiples of 4,096 when extended system IDs are enabled:
SwitchA(config)# spanning-tree vlan 101 priority 8192

A switch can be indirectly forced to become the Root Bridge for a specific
VLAN:
SwitchA(config)# spanning-tree vlan 101 root primary

The root primary parameter automatically lowers the priority to 24,576. If

another switch has a priority lower than 24,576, the priority will be lowered
to 4,096 less than the current Root Bridge.
STP does not technically support a backup Root Bridge. However, the root
secondary command can increase the likelihood that a specified switch will
succeed as the new Root Bridge in the event of a failure:
SwitchB(config)# spanning-tree vlan 101 root secondary

The root secondary parameter in the above command automatically lowers

the switch’s priority to 28,672.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Spanning Tree Protocol v1.31 – Aaron Balchunas 13

STP Port States

As STP converges the switching topology, a switch port will progress
through a series of states:
• Blocking
• Listening
• Learning
• Forwarding
Initially, a switch port will start in a blocking state:
• A blocking port will not forward frames or learn MAC addresses.
• A blocking port will still listen for BPDUs from other switches, to
learn about changes to the switching topology.
A port will then transition from a blocking to a listening state:
• The switch must believe that the port will not be shut down to
eliminate a loop. In other words, the port may become a root or
designated port.
• A listening port will not forward frames or learn MAC addresses.
• A listening port will send and listen for BPDUs, to participate in the
election of the Root Bridge, root ports, and designated ports.
• If a listening port is not elected as a root or a designated Port, it will
transition back to a blocking state.
If a listening port is elected as a root or designated port, it will transition to a
learning state:
• A port must wait a brief period of time, referred to as the forward
delay, before transitioning from a listening to learning state.
• A learning port will continue to send and listen for BPDUs.
• A learning port will begin to add MAC addresses to the CAM table.
• However, a learning port cannot forward frames quite yet.
Finally, a learning port will transition to a forwarding state:
• A port must wait another forward delay before transitioning from
learning to forwarding.
• A forwarding port is fully functional – it will send and listen for
BPDUs, learn MAC addresses, and forward frames.
• Root and designated ports will eventually transition to a forwarding
state.

STP Port States (continued)

Technically, there is a fifth port state – disabled. A port in a disabled state
has been administratively shutdown. A disabled port does not forward
frames or participate in STP convergence.
Why does a port start in a blocking state? STP must initially assume that a
loop exists. A broadcast storm can form in seconds, and requires physical
intervention to stop.
Thus, STP will always take a proactive approach. Starting in a blocking state
allows STP to complete its convergence process before any traffic is
forwarded. In perfect STP operation, a broadcast storm should never occur.

To view the current state of a port:

SwitchA# show spanning-tree interface gi2/10

Vlan Role Sts Cost Prio.Nbr Type

------------------- ---- --- --------- -------- -----------------
VLAN0101 Desg FWD 4 128.34 P2p
VLAN0102 Desg FWD 4 128.34 P2p

SwitchB# show spanning-tree interface gi2/24

Vlan Role Sts Cost Prio.Nbr Type

------------------- ---- --- --------- -------- -----------------
VLAN0101 Root FWD 4 128.48 P2p
VLAN0102 Altn BLK 4 128.48 P2p

STP Timers
Switches running STP exchange BPDUs to build and converge the topology
database. There are three timers that are crucial to the STP process:
• Hello timer
• Forward delay timer
• Max age timer
The hello timer determines how often switches send BPDUs. By default,
BPDUs are sent every 2 seconds.
The forward delay timer determines how long a port must spend in both a
learning and listening state:
• Introducing this delay period ensures that STP will have enough time
to detect and eliminate loops.
• By default, the forward delay is 15 seconds.
• Because a port must transition through two forward delays, the total
delay time is 30 seconds.
The max age timer indicates how long a switch will retain BPDU
information from a neighbor switch, before discarding it:
• Remember that BPDUs are sent every two seconds.
• If a switch fails to receive a BPDU from a neighboring switch for the
max age period, it will assume there was a change in the switching
topology.
• STP will then purge that neighbor’s BPDU information.
• By default, the max age timer is 20 seconds.
Timer values can be adjusted. However, this is rarely necessary, and can
negatively impact STP performance and reliability.
Timers must be changed on the Root Bridge. The Root Bridge will
propagate the new timer values to all switches using BPDUs. Non-root
switches will ignore their locally configured timer values.
To manually adjust the three STP timers for a specific VLAN:
Switch(config)# spanning-tree vlan 101 hello-time 10
Switch(config)# spanning-tree vlan 101 forward-time 20
Switch(config)# spanning-tree vlan 101 max-age 40

The timer values are measured in seconds, and the above represents the
maximum possible value for each timer.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Spanning Tree Protocol v1.31 – Aaron Balchunas 16

STP Diameter
The default values of each STP timer are based on the diameter of the
switching topology.
The diameter is the length of the topology, measured in the number of
switches including the Root Bridge. The following example has a diameter
of 4 switches:
SwitchA
Root Bridge

SwitchB

SwitchC

SwitchD

By default, STP assumes a switching diameter of 7. This is also the

maximum diameter.
Note: The switching topology can contain more than seven switches.
However, each branch of the switching tree can only extend seven switches
deep, with the Root Bridge always at the top of the branch.
The diameter should be configured on the Root Bridge:
SwitchA(config)# spanning-tree vlan 101 root primary diameter 5

The diameter command adjusts the hello, forward delay, and max age
timers. This is the recommended way to adjust timers, as the timers are
tuned specifically to the diameter of the switching network.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Spanning Tree Protocol v1.31 – Aaron Balchunas 17

STP Topology Changes

Switches exchange two types of BPDUs when building and converging the
topology database:
• Configuration BPDUs
• Topology Change Notification (TCN) BPDUs
Configuration BPDUs are used to elect Root Bridges, root ports, and
designated ports.
A TCN will be sent under two circumstances:
• When a port transitions into a forwarding state.
• When a forwarding or learning port transitions into a blocking or
down state.
When a topology change occurs, a switch will send a TCN BPDU out its
root port, destined for the Root Bridge. The TCN contains no information
about the change – it only indicates that a change occurred.
Consider the following example:

If the port on SwitchD connecting to SwitchE went down:

• SwitchD would send a TCN out its root port to SwitchB.
• SwitchB will acknowledge this TCN, by responding with a TCN with
the Topology Change Acknowledgement (TCA) flag set.
• SwitchB then forward the TCN out its root port to SwitchA, the Root
Bridge.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Spanning Tree Protocol v1.31 – Aaron Balchunas 18

STP Topology Changes (continued)

Once the Root Bridge receives the TCN, it will send out a configuration
BPDU to all switches, with the Topology Change (TC) flag set. This
ensures that all switches in the STP topology are informed of the change.

When a switch receives this root BPDU, it will temporarily reduce its CAM
aging timer from 300 seconds to a value equal to the forward delay timer -
15 seconds by default. This allows any erroneous MAC addresses to be
quickly flushed from the CAM table.
The CAM aging timer will remain at a reduced value for the duration of one
forward delay plus one max age period – a total of 35 seconds by default.
Two types of failures can occur in the STP topology, depending on the
perspective of a switch:
• Direct failures
• Indirect failures
For example, if the root port on SwitchB fails, SwitchB would consider this
a direct failure. SwitchB will detect immediately that the physical port is
down, and STP will react accordingly.
That same port failing would represent an indirect failure for SwitchD.
SwitchD would lose its path to the Root Bridge. However, because the port
is not local on SwitchD, it must learn of the topology change from its
neighbors.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Spanning Tree Protocol v1.31 – Aaron Balchunas 19

STP Topology Changes (continued)

By detecting and reacting to link failures, STP can take advantage of the
redundancy provided by loops. However, the failover is not instantaneous.

If the root port on SwitchE were to fail:

• SwitchE would immediately purge any BPDU information received
from SwitchC.
• SwitchC would send a TCN to the Root Bridge.
• The Root Bridge would send a configuration BPDU to all switches,
with the TC flag set.
• All switches would reduce their CAM aging timer to 15 seconds.
• SwitchE would eventually receive a BPDU from SwitchD.
Remember, blocked ports still receive BPDUs to learn about
topology changes.
• The blocked port to SwitchD now represents the best and only path
for SwitchE to reach the Root Bridge.
• The blocked port will transition first to a listening state, and then to a
learning state. The port will wait the forward delay time in both states,
for a total of 30 seconds.
• The port will finally transition to a forwarding state.
Thus, hosts on SwitchE will be impacted by this failure for a minimum of 30
seconds. STP will maintain redundancy if there is a loop, but a link failure
will still negatively impact the network for a short period.

Improving STP Convergence

In many environments, a 30 second outage for every topology change is
unacceptable. Cisco developed three proprietary features that improve STP
convergence time:
• PortFast
• UplinkFast
• BackboneFast
Each feature will be covered in detail in the following sections.

PortFast
By default, all ports on a switch participate in the STP topology. This
includes any port that connects to a host, such as a workstation. In most
circumstances, a host represents no risk of a loop.
The host port will transition through the normal STP states, including
waiting two forward delay times. Thus, a host will be without network
connectivity for a minimum of 30 seconds when first powered on.
This is not ideal for a couple reasons:
• Users will be annoyed by the brief outage.
• A host will often request an IP address through DHCP during bootup.
If the switch port is not forwarding quickly enough, the DHCP
request may fail.
• Devices that boot from network may fail as well.
PortFast allows a switch port to bypass the usual progression of STP states.
The port will instead transition from a blocking to a forwarding state
immediately, eliminating the typical 30 second delay.
PortFast should only be enabled on ports connected to a host. If enabled on a
port connecting to a switch or hub, any loop may result in a broadcast storm.
Note: PortFast does not disable STP on a port - it merely accelerates STP
convergence. If a PortFast-enabled port receives a BPDU, it will transition
through the normal process of STP states.

PortFast (continued)
SwitchA
Root Bridge

Root Port Root Port

SwitchB SwitchC

Root Port Root Port

SwitchD SwitchE

gi1/14

HostA

PortFast provides an additional benefit. Remember that a switch will

generate a TCN if a port transitions to a forwarding or blocked state. This is
true even if the port connects to a host device, such as a workstation.
Thus, powering on or off a workstation will cause TCNs to reach the Root
Bridge, which will send out configuration BPDUs in response. Because the
switching topology did not technically change, no outage will occur.
However, all switches will reduce the CAM aging timer to 15 seconds, thus
purging MAC addresses from the table very quickly. This will increase
frame flooding and reduce the efficiency and performance.
PortFast eliminates this unnecessary BPDU traffic and frame flooding. A
TCN will not be generated for state changes on a PortFast-enabled port.
Portfast is disabled by default. To enable PortFast on a switch port:
SwitchD(config)# int gi1/14
SwitchD(config-if)# spanning-tree portfast

PortFast can also be globally enabled for all interfaces:

SwitchD(config)# spanning-tree portfast default

UplinkFast
Often, a switch will have multiple uplinks to another upstream switch:
SwitchA
Root Bridge

gi2/23 gi2/24

SwitchB

If the links are not bundled using an EtherChannel, at least one of the ports
will transition to a blocking state to eliminate the loop. In the above
example, port gi2/24 was placed into a blocking state on SwitchB.
Normally, if the root port fails on the local switch, STP will need to perform
a recalculation to transition the other port out of a blocking state. At a
minimum, this process will take 30 seconds.
UplinkFast allows a blocking port to be held in a standby state. If the root
port fails, the blocking port can immediately transition to a forwarding state.
Thus, UplinkFast improves convergence time for direct failures in the STP
topology.
If multiple ports are in a blocking state, whichever port has the lowest root
path cost will transition to forwarding.
UplinkFast is disabled by default, and must be enabled globally for all
VLANs on the switch:
Switch(config)# spanning-tree uplinkfast

UplinkFast functions by tracking all possible links to the Root Bridge. Thus,
UplinkFast is not supported on the Root Bridge. In fact, enabling this
feature will automatically increase a switch’s bridge priority to 49,152.
UplinkFast is intended for the furthest downstream switches in the STP
topology.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Spanning Tree Protocol v1.31 – Aaron Balchunas 23

BackboneFast
UplinkFast provides faster convergence if a directly-connected port fails. In
contrast, BackboneFast provides improved convergence if there is an
indirect failure in the STP topology.

If the link between SwitchB and SwitchA fails, SwitchD will eventually
recalculate a path through SwitchE to reach the Root Bridge. However,
SwitchD must wait the max age timer before purging SwitchB’s superior
BPDU information. By default, this is 20 seconds.
BackboneFast allows a switch to bypass the max age timer. The switch will
accept SwitchE’s inferior BPDU’s immediately. The blocked port on
SwitchE must still transition to a forwarding state. Thus, BackboneFast
essentially reduces total convergence time from 50 seconds to 30 seconds for
an indirect failure.
This is accomplished by sending out Root Link Queries (RLQs). The Root
Bridge will respond to these queries with a RLQ Reply:
• If a RLQ Reply is received on a root port, the switch knows that the
root path is stable.
• If a RLQ Reply is received on a non-root port, the switch knows that
the root path has failed. The max age timer is immediately expired to
allow a new root port to be elected.
BackboneFast is a global command, and should be enabled on every switch:
Switch(config)# spanning-tree backbonefast
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Spanning Tree Protocol v1.31 – Aaron Balchunas 24

Protecting STP
STP is vulnerable to attack for two reasons:
• STP builds the topology by accepting BPDUs from neighboring
switches.
• The Root Bridge is always determined by the lowest Bridge ID.
A switch with a low priority can be maliciously or inadvertently installed on
the network, and then elected as the Root Bridge. STP will reconverge, often
resulting in instability or a suboptimal topology.
Cisco implemented three mechanisms to protect the STP topology:
• Root Guard
• BPDU Guard
• BPDU Filtering
All three mechanisms are configured on a per-port basis, and are disabled by
default.

Root Guard
Root Guard prevents an unauthorized switch from advertising itself as a
Root Bridge. If a BPDU superior to the Root Bridge is received on a port
with Root Guard enabled, the port is placed in a root-inconsistent state.
In this state, the port is essentially in a blocking state, and will not forward
frames. The port can still listen for BPDUs.
Root Guard is enabled on a per-port basis, and is disabled by default:
Switch(config)# interface gi1/14
Switch(config-if)# spanning-tree guard root

To view all ports that have been placed in a root-inconsistent state:

Switch# show spanning-tree inconsistentports

Name Interface Inconsistency

-------------------- -------------------- ------------------
VLAN100 GigabitEthernet1/14 Root Inconsistent

Root Guard can automatically recover. As soon as superior BPDUs are no

longer received, the port will transition normally through STP states.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Spanning Tree Protocol v1.31 – Aaron Balchunas 25

BPDU Guard
Recall that PortFast allows a switch port to bypass the usual progression of
STP states. However, PortFast does not disable STP on a port - it merely
accelerates STP convergence. However, a PortFast-enabled port will still
accept BPDUs.
PortFast should only be enabled on ports connected to a host. If enabled on a
port connecting to a switch, any loop may result in a broadcast storm.
To prevent such a scenario, BPDU Guard can be used in conjunction with
PortFast. Under normal circumstances, a port with PortFast enabled should
never receive a BPDU, as it is intended only for hosts.
BPDU Guard will place a port in an errdisable state if a BPDU is received,
regardless if the BPDU is superior or inferior. The STP topology will not be
impacted by another switch that is inadvertently connected to that port.
BPDU Guard should be enabled on any port with PortFast enabled. It is
disabled by default, and can be enabled on a per-interface basis:
Switch(config)# interface gi1/14
Switch(config-if)# spanning-tree bpduguard enable

If BPDU Guard is enabled globally, it will only apply to PortFast ports:

Switch(config)# spanning-tree portfast bpduguard default

An interface can be manually recovered from an errdisable state by

performing a shutdown and then no shutdown:
Switch(config)# interface gi1/14
Switch(config-if)# shutdown
Switch(config-if)# no shutdown

BPDUs will still be sent out ports enabled with BPDU Guard.

BPDU Filtering
BPDU Filtering prevents BPDUs from being sent out a port, and must be
enabled in conjunction with PortFast.
If a BPDU is received on a port, BPDU Filtering will react one of two ways,
depending on how it was configured.
• If filtering is enabled globally, a received BPDU will disable PortFast
on the port. The port will then transition normally through the STP
process.
• If filtering is enabled on a per-interface basis, a received BPDU is
ignored.
Great care must be taken when manually enabling BPDU Filtering on a port.
Because the port will ignore a received BPDU, STP is essentially disabled.
The port will neither be err-disabled nor progress through the STP process,
and thus the port is susceptible to loops.
If BPDU Filtering is enabled globally, it will only apply to PortFast ports:
Switch(config)# spanning-tree portfast bpdufilter default

To enable BPDU Filtering on a per-interface basis:

Switch(config)# interface gi1/15
Switch(config-if)# spanning-tree bpdufilter enable

Unidirectional Link Detection (UDLD)

Most network communication is bidirectional. Occasionally, a hardware
fault will cause traffic to be transmitted in only one direction, or
unidirectional. Fiber ports are the most susceptible to this type of fault.
STP requires that switches exchange BPDUs bidirectionally. If a port
becomes unidirectional, BPDUs will not be received by one of the switches.
That switch may then incorrectly transition a blocking port to a forwarding
state, and create a loop.
Cisco developed Unidirectional Link Detection (UDLD) to ensure that
bidirectional communication is maintained. UDLD sends out ID frames on
a port, and waits for the remote switch to respond with its own ID frame. If
the remote switch does not respond, UDLD assumes the port has a
unidirectional fault.
By default, UDLD sends out ID frames every 15 seconds on most Cisco
platforms. Some platforms default to every 7 seconds. UDLD must be
enabled on both sides of a link.
UDLD reacts one of two ways when a unidirectional link is detected:
• Normal Mode – the port is not shut down, but is flagged as being in
an undetermined state.
• Aggressive Mode – the port is placed in an errdisable state
UDLD can be enabled globally, though it will only apply for fiber ports:
Switch(config)# udld enable message time 20
Switch(config)# udld aggressive message time 20

The enable parameter sets UDLD into normal mode, and the aggressive
parameter is for aggressive mode. The message time parameter modifies
how often ID frames are sent out, measured in seconds.
UDLD can be configured on a per-interface basis:
Switch(config-if)# udld enable
Switch(config-if)# udld aggressive
Switch(config-if)# udld disable

To view UDLD status on ports, and reset any ports disabled by UDLD:
Switch# show udld
Switch# udld reset
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Spanning Tree Protocol v1.31 – Aaron Balchunas 28

Loop Guard
STP relies on the exchange of BPDUs to maintain a loop free environment.
If a software or hardware failure causes a switch to stop receiving BPDUs, a
switch will eventually discard that BPDU information, after the max age
timer has expired.
This may result in the switch incorrectly transitioning a blocking port to a
forwarding state, thus creating a loop.
UDLD addresses only one of the possible causes of this scenario – a
unidirectional link. Other issues may prevent BPDUs from being received or
processed, such as the CPU on a switch being at max utilization.
Loop Guard provides a more comprehensive solution – if a blocking port
stops receiving BPDUs on a VLAN, it is moved into a loop-inconsistent
state for that VLAN.
A port in a loop-inconsistent state cannot forward traffic for the affected
VLANs, and is essentially in a pseudo-errdisable state.
However, Loop Guard can automatically recover. As soon as BPDUs are
received again, the port will transition normally through STP states.
Loop Guard can be enabled globally:
Switch(config)# spanning-tree loopguard default

Loop Guard can also be enabled on a per-interface basis:

Switch(config)# interface gi2/23
Switch(config-if)# spanning-tree guard loop

Loop Guard should only be enabled on trunk ports, or ports that connect to
other switches. Loop Guard should never be enabled on a port connecting to
a host, as an access port should never receive a BPDU.

(Reference: http://astorinonetworks.com/2011/09/01/understanding-spanning-tree-loopguard/)

Troubleshooting STP
To view general STP information for all VLANs:
Switch# show spanning-tree
VLAN0101
Spanning tree enabled protocol ieee
Root ID Priority 32869
Address 000a.f43b.1b80
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32869 (priority 32768 sys-id-ext 101)

Address 000a.f43b.1b80
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300

Interface Role Sts Cost Prio.Nbr Type

---------------- ---- --- --------- -------- --------------------------
Gi2/23 Desg FWD 4 128.47 P2p

<snipped for brevity>

To view more detailed STP information:

Switch# show spanning-tree
VLAN0101 is executing the ieee compatible Spanning Tree protocol
Bridge Identifier has priority 32768, sysid 101, address 000a.f43b.1b80
Configured hello time 2, max age 20, forward delay 15
We are the root of the spanning tree
Topology change flag not set, detected flag not set
Number of topology changes 1 last change occurred 1w6d ago
from GigabitEthernet2/23
Times: hold 1, topology change 35, notification 2
hello 2, max age 20, forward delay 15
Timers: hello 0, topology change 0, notification 0, aging 300

Port 47 (GigabitEthernet2/23) of VLAN0101 is forwarding

Port path cost 4, Port priority 128, Port Identifier 128.47.
Designated root has priority 32869, address 000a.f43b.1b80
Designated bridge has priority 32869, address 000a.f43b.1b80
Designated port id is 128.47, designated path cost 0
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is point-to-point by default
BPDU: sent 1129012, received 0

To view STP information specific to an interface:

Switch# show spanning-tree interface gi2/24

Vlan Role Sts Cost Prio.Nbr Type

------------------- ---- --- --------- -------- -----------------
VLAN0101 Root FWD 4 128.48 P2p
VLAN0102 Altn BLK 4 128.48 P2p
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Spanning Tree Protocol v1.31 – Aaron Balchunas 30

Per-VLAN Spanning Tree (PVST) Load Balancing

PVST and PVST+ employ a separate STP instance for each VLAN. This
provides superior flexibility over CST, which only supports a single STP
instance for all VLANs.
Consider the following example:
SwitchA
Root Bridge

Topology for
All VLANs

SwitchB

If a port on SwitchB enters a blocking state to eliminate the loop, that port
will block traffic from all VLANs. Redundancy is not lost, as STP will
recognize if the non-blocked port goes down, and reactivate the blocked
port.
However, this is inefficient, as the potential bandwidth of the blocked port is
unavailable for any VLAN. In contrast, PVST supports load balancing
VLANs across the switching topology:

PVST runs a separate instance for each VLAN, allowing a port to enter a
blocking state only for that specific VLAN. This provides both redundancy
and more efficient use of available bandwidth.
Note: An even better solution for the above example is to use an
EtherChannel, which STP will treat as a single logical interface.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Spanning Tree Protocol v1.31 – Aaron Balchunas 31

Rapid Spanning Tree Protocol (RSTP)

In modern networks, a 30 to 50 second convergence delay is unacceptable.
Enhancements were made to the original IEEE 802.1D standard to address
this. The result was 802.1w, or Rapid Spanning Tree Protocol (RSTP).
RSTP is similar in many respects to STP:
• BPDUs are forwarded between switches
• A Root Bridge is elected, based on the lowest Bridge ID.
• Root and designated ports are elected and function identically to STP.
RSTP defines four port roles:
• Root Port – Port on each switch that has the best path cost to the Root
Bridge. A switch can only have one root port.
• Alternate Port – Backup root port that has a less desirable path cost.
• Designated Port – Non-root port that represents the best path cost for
each network segment to the Root Bridge.
• Backup Port – Backup designated port that has a less desirable path
cost.
802.1D STP supported five port states, while RSTP supports three:
• Discarding
• Learning
• Forwarding
Initially, a switch port starts in a discarding state:
• A discarding port will not forward frames or learn MAC addresses.
• A discarding port will listen for BPDUs.
• Alternate and backup ports will remain in a discarding state.
RSTP does not need a listening state. Instead, if a port is elected as a root or
designated port, it will transition from discarding to a learning state:
• A learning port will begin to add MAC addresses to the CAM table.
• However, a learning port cannot forward frames quite yet.
Finally, a learning port will transition to a forwarding state:
• A forwarding port is fully functional – it will send and listen for
BPDUs, learn MAC addresses, and forward frames.
• Root and designated ports will eventually transition to a forwarding
state.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Spanning Tree Protocol v1.31 – Aaron Balchunas 32

Rapid Spanning Tree Protocol (RSTP) (continued)

The key benefit of RSTP is faster convergence:
• BPDUs are generated by every switch, and sent out at the hello interval.
• Switches no longer require artificial forward delay timers.
In 802.1D, BPDUs are generated by the Root Bridge. If a switch receives a
BPDU from the Root Bridge on its root port, it will propagate the BPDU
downstream to its neighbors. This convergence process is slow, and STP
relies on forward delay timers to ensure a loop-free environment.
In RSTP, switches will handshake directly with their neighbors, allowing
the topology to be quickly synchronized. This allows ports to rapidly
transition from a discarding state to a forwarding state without a delay timer.
A key component of the RSTP process is the type of each port:
• Edge – port that connects to a host. This port behaves exactly like a
PortFast-enabled port, transitioning to a forwarding state immediately.
• Root – port that connects to another switch, and has the best path cost
to the Root Bridge.
• Point-to-Point – port that connects to another switch, with the
potential to become the designated port for a segment.
Note: If an edge port receives a BPDU, it will lose its edge port status and
transition normally through the RSTP process. On Cisco switches, any port
configured with PortFast becomes an Edge Port.
The RSTP convergence process is as follows:
• Switches exchange BPDUs to elect the Root Bridge.
• Edge ports immediately transition into a forwarding state.
• All potential root and point-to-point ports start in a discarding state.
• If a port receives a superior BPDU, it will become a root port, and
transition immediately to a forwarding state.
• For a point-to-point port, each switch will exchange a handshake
proposal to determine which port becomes designated.
• Once the switches agree, the designated port is moved immediately
into a forwarding state.
Every switch will perform this handshaking process with each of its
neighbors, until all switches are synchronized. Complete convergence
happens very quickly – within seconds.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Spanning Tree Protocol v1.31 – Aaron Balchunas 33

Rapid Spanning Tree Protocol (RSTP) (continued)

RSTP handles topology changes more efficiently than 802.1D STP, which
generates a Topology Change Notification (TCN) in two circumstances:
• When a port transitions into a forwarding state.
• When a port transitions into a blocking or down state.
The TCN will eventually reach the Root Bridge, which will then inform all
other switches of the change by sending a BPDU with the Topology Change
(TC) bit set.
In RSTP, only a non-edge port transitioning to a forwarding state will
generate a TCN. The switch recognizing a topology change does not have to
inform the Root Bridge first. Any switch can generate and forward a TC
BPDU, allowing the topology to quickly converge via handshakes.
A switch receiving a TC BPDU will flush all MAC addresses learned on
designated ports, except for the port that received the TC BPDU.
In the event of a topology change, RSTP will allow alternate or backup ports
to immediately enter a forwarding state. Additionally, RSTP does not have to
wait an arbitrary max age timer to accept an inferior BPDU, if there is an
indirect failure in the topology.
Essentially, RSTP inherently supports the functionality of UplinkFast and
BackboneFast.
RSTP is compatible with 802.1D STP. If a neighboring switch does not
respond to an RSTP handshake, a port reverts back to transitioning through
802.1D states. Note that this means that all RSTP benefits are lost on that
port.
Two implementations of RSTP exist:
• Rapid Per-VLAN Spanning Tree Protocol (RPVST+)
• Multiple Spanning Tree (MST)
RPVST+ is Cisco proprietary, while MST is defined in the IEEE 802.1s
standard.
To enable RPVST+ globally on a switch:
Switch(config)# spanning-tree mode rapid-pvst

Multiple Spanning Tree (MST)

Earlier in this guide, three versions of 802.1D STP were described:
• CST utilizes a single STP instance for all VLANs.
• PVST and PVST+ employ a separate STP instance for each VLAN.
PVST and PVST+ are more efficient, and allow STP to load balance
VLANs across links. This comes at a cost – maintaining a separate STP
instance for each VLAN adds overhead to the CPU and memory on a switch.
Multiple Spanning Tree (MST), defined in IEEE 802.1s, allows a group
of VLANs to be mapped to an STP instance.
Each MST instance (MSTI) builds its own RSTP topology database,
including electing its own Root Bridge. A VLAN can only be assigned to
one instance.
MST further separates the STP topology into regions. All switches in a
region must be configured with identical MST parameters:
• 32-byte configuration name
• 16-bit revision number
• VLAN-to-instance mapping database
If two switches are configured with different MST parameters, they belong
to different MST regions.
For most Cisco platforms, a region can contain a maximum of 16 MST
instances, numbered 0 through 15. By default, all VLANs belong to
instance 0.
The Internal Spanning Tree (IST) is responsible for maintaining the
topology for the entire region and all of the MSTIs. Only the IST can send
and receive BPDUs, and encapsulates the MSTI information within a BPDU
as an MST record (M-record).
The IST is always mapped to instance 0.
MST is compatible with all other implementations of STP. An MST region
is obfuscated from non-MST switches, which will see the entire MST region
as a single 802.1D or RSTP switch.

Multiple Spanning Tree (MST) (continued)

To enable MST globally on a switch:
Switch(config)# spanning-tree mode mst

Changes to MST parameters must be made from MST configuration mode:

Switch(config)# spanning-tree mst configuration
Switch(config-mst)#

To assign the MST configuration name and revision number:

Switch(config-mst)# name MYMSTNAME
Switch(config-mst)# revision 2

To map VLANs to a specific MST instances:

Switch(config-mst)# instance 2 vlan 1-100
Switch(config-mst)# instance 3 vlan 101-200

Remember: A maximum of 16 MST instances are supported, numbered 0 to

15. The MST configuration name, revision number, and VLAN-to-instance
mapping must be identical on all switches in the same region.
To view the changes to the configuration:
Switch(config-mst)# show pending
Pending MST configuration
Name [MYMSTNAME]
Revision 2
Instance Vlans mapped
-------- ------------------------
0 201-4094
2 1-100
3 101-200

All other MST parameters are configured identically to 802.1D STP, with
two exceptions:
• The mst parameter must be used on all commands
• All commands reference the MST instance instead of a VLAN.
Thus, to configure a switch as the Root Bridge for MST instance 2:
Switch(config)# spanning-tree mst 2 root primary

- Multilayer Switching -
Routing Between VLANs
By default, a switch will forward both broadcasts and multicasts out every
port but the originating port. However, a switch can be logically segmented
into separate broadcast domains, using Virtual LANs (or VLANs).
Each VLAN represents a unique broadcast domain:
• Traffic between devices within the same VLAN is switched.
• Traffic between devices in different VLANs requires a Layer-3
device to communicate.
There are three methods of routing between VLANs. The first method
involves using an external router with a separate physical interface in each
VLAN. This is the least scalable solution, and impractical for environments
with a large number of VLANs:

The second method involves using an external router with a single trunk
link to the switch, over which all VLANs can be routed. The router must
support either 802.1Q or ISL encapsulation. This method is known as
router-on-a-stick:

The final method involves using a multilayer switch, which supports both
Layer-2 and Layer-3 forwarding:

Multilayer switching is a generic term, encompassing any switch that can

forward traffic at layers higher than Layer-2.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Multilayer Switching v1.21 – Aaron Balchunas 2

Configuring Router-on-a-Stick
Consider the following router-on-a-stick example:
SwitchA
gi0/1 gi1/10
< Trunking VLANs 101,102 >
gi1/14 gi1/15
RouterA

HostA HostB
VLAN 101 VLAN 102

Four elements must be considered in this scenario:

• Interface gi1/10 on SwitchA must be configured as a trunk port.
• Interfaces gi1/14 and gi1/15 on SwitchB must be assigned to their
specified VLANs.
• Interface gi0/1 on RouterA must be split into subinterfaces, one for
each VLAN.
• Each subinterface must support the encapsulation protocol used by
the trunk port on SwitchA.
Configuration on SwitchA would be as follows:
SwitchA(config)# interface gi1/10
SwitchA(config-if)# switchport mode trunk
SwitchA(config-if)# switchport trunk encapsulation dot1q
SwitchA(config-if)# no shut

SwitchA(config)# interface gi1/14

SwitchA(config-if)# switchport mode access
SwitchA(config-if)# switchport access vlan 101
SwitchA(config-if)# no shut

SwitchA(config)# interface gi1/15

SwitchA(config-if)# switchport mode access
SwitchA(config-if)# switchport access vlan 102
SwitchA(config-if)# no shut

Note that no Layer-3 information was configured on SwitchA.

Configuring Router-on-a-Stick (continued)

SwitchA
gi0/1 gi1/10
< Trunking VLANs 101,102 >
gi1/14 gi1/15
RouterA

HostA HostB
VLAN 101 VLAN 102

Configuration on RouterA would be as follows:

RouterA(config)# interface gi0/1
RouterA(config-if)# no shut
RouterA(config)# interface gi0/1.101
RouterA(config-subif)# encapsulation dot1q 101
RouterA(config-subif)# ip address 10.101.101.1 255.255.255.0
RouterA(config)# interface gi0/1.102
RouterA(config-subif)# encapsulation dot1q 102
RouterA(config-subif)# ip address 10.102.102.1 255.255.255.0

Each subinterface was configured with dot1q encapsulation, to match the

configuration of SwitchA’s trunk port.
Frames sent across the trunk port will be tagged with the VLAN ID. The
number after each encapsulation dot1q command represents this VLAN ID.
Otherwise, the router could not interpret the VLAN tag.
The IP address on each subinterface represents the gateway for each VLAN:
• HostA is in VLAN 101, and will use 10.101.101.1 as its gateway.
• HostB is in VLAN 102, and will use 10.102.102.1 as its gateway.
• HostA and HostB should now have full Layer-3 connectivity.
There are inherent disadvantages to router-on-a-stick:
• All routed traffic will share the same physical router interface, which
represents a bottleneck.
• ISL and DOT1Q encapsulation puts an increased load on the router
processor.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Multilayer Switching v1.21 – Aaron Balchunas 4

Multilayer Switch Port Types

Multilayer switches support both Layer-2 and Layer-3 forwarding.
Layer-2 forwarding, usually referred to as switching, involves decisions
based on frame or data-link headers. Switches will build hardware address
tables to intelligently forward frames.
Layer-3 forwarding, usually referred to as routing, involves decisions
based on packet or network headers. Routers build routing tables to forward
packets from one network to another.
A multilayer switch supports three port types:
• Layer-2 or switchports
• Layer-3 or routed ports
• Switched Virtual Interfaces (SVIs)
A switchport can either be an access or trunk port. By default on Cisco
switches, all interfaces are switchports. To manually configure an interface
as a switchport:
Switch(config)# interface gi1/10
Switch(config-if)# switchport

A routed port behaves exactly like a physical router interface, and is not
associated with a VLAN. The no switchport command configures an
interface as a routed port, allowing an IP address to be assigned:
Switch(config)# interface gi1/20
Switch(config-if)# no switchport
Switch(config-if)# ip address 10.101.101.1 255.255.255.0

Multilayer switches support configuring a VLAN as a logical routed

interface, known as a Switched Virtual Interface (SVI). The SVI is
referenced by the VLAN number:
Switch(config)# interface vlan 101
Switch(config-if)# ip address 10.101.101.1 255.255.255.0
Switch(config-if)# no shut

SVIs are the most common method of configuring inter-VLAN routing. The
logical VLAN interface will not become online unless:
• The VLAN is created.
• At least one port is active in the VLAN.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Multilayer Switching v1.21 – Aaron Balchunas 5

Configuring Inter-VLAN Routing Using SVIs

Configuring inter-VLAN routing using SVIs is very simple. First, the

VLANs must be created:
SwitchA(config)# vlan 101
SwitchA(config-vlan)# name VLAN101
SwitchA(config)# vlan 102
SwitchA(config-vlan)# name VLAN102

Layer-3 forwarding must then be enabled globally on the multilayer switch:

SwitchA(config)# ip routing

Finally, each VLAN SVI must be assigned an IP address:

SwitchA(config)# interface vlan 101
SwitchA(config-if)# ip address 10.101.101.1 255.255.255.0
SwitchA(config-if)# no shut
SwitchA(config)# interface vlan 102
SwitchA(config-if)# ip address 10.102.102.1 255.255.255.0
SwitchA(config-if)# no shut

The IP address on each SVI represents the gateway for hosts on each
VLAN. The two networks will be added to the routing table as directly
connected routes.
Remember: an SVI requires at least one port to be active in the VLAN:
SwitchA(config)# interface gi1/14
SwitchA(config-if)# switchport mode access
SwitchA(config-if)# switchport access vlan 101
SwitchA(config-if)# no shut

SwitchA(config)# interface gi1/15

SwitchA(config-if)# switchport mode access
SwitchA(config-if)# switchport access vlan 102
SwitchA(config-if)# no shut
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Multilayer Switching v1.21 – Aaron Balchunas 6

Multilayer Switching – Route Once, Switch Many

Originally, multilayer switches consisted of two independent components:
• Routing engine
• Switching engine
The first packet in an IP traffic flow must be sent to the routing engine to be
routed. The switching engine could then cache this traffic flow. Subsequent
packets destined for that flow could then be switched instead of routed. This
greatly reduced forwarding latency.
This concept is often referred to as route once, switch many.
Just like a router, a multilayer switch must update the following header
information:
• Layer 2 destination address
• Layer 2 source address
• Layer 3 IP Time-to-Live (TTL)
Additionally, the Layer-2 and Layer-3 checksums must be updated to reflect
the changes in header information.
Cisco’s original implementation of multilayer switching was known as
NetFlow or route-cache switching. NetFlow incorporated separate routing
and switching engines.
NetFlow was eventually replaced with Cisco Express Forwarding (CEF),
which addressed some of the disadvantages of NetFlow:
• CEF is less CPU intensive.
• CEF does not dynamically cache routes, eliminating the risk of
stale routes in the cache if the routing topology changes.

Cisco Express Forwarding (CEF)

CEF consists of two basic components:
• Layer-3 Engine
• Layer-3 Forwarding Engine – Switches data based on the FIB.
The Layer-3 Engine is responsible for building the routing table and then
routing traffic. The routing table can be built either statically or dynamically,
via a routing protocol.
Each entry in the routing table will contain the following:
• Destination prefix
• Destination mask
• Layer-3 next-hop address
CEF reorganizes the routing table into a more efficient table called the
Forward Information Base (FIB). The most specific routes are placed at
the top of the FIB, to accelerate forwarding lookups. Any change to the
routing table is immediately reflected in the FIB.
The Layer-3 Forwarding Engine uses the FIB to switch traffic in hardware,
which incurs less latency than routing it through the Layer-3 Engine. If a
packet cannot be switched using the Forwarding Engine, it will be punted
back to the Layer-3 Engine to be routed.
The FIB contains the Layer-3 next-hop for every destination network. CEF
will additionally build an Adjacency Table, containing the Layer-2
address for each next-hop in the FIB. This eliminates the latency from ARP
requests when forwarding traffic to the next-hop address.
If there is no next-hop entry in the Adjacency Table, a packet must be sent to
the Layer-3 Engine to glean the next-hop’s Layer-2 address, via an ARP
request.
CEF is enabled by default on most Cisco multilayer switch platforms. In
fact, it is impossible to disable CEF on many platforms.
To manually enable CEF, when necessary:
Switch(config)# ip cef

Cisco Express Forwarding (CEF) (continued)

CEF can be disabled on a per-interface basis on some platforms. Depending
on the model, the syntax will be different:
Switch(config)# interface gi1/15
Switch(config-if)# no ip route-cache cef
Switch(config-if)# no ip cef

To view entries in the FIB table:

Switch# show ip cef

Prefix Next Hop Interface

172.16.1.0/24 10.50.1.1 Vlan50

172.16.2.0/24 10.50.1.2 Vlan50
172.16.0.0/16 10.50.1.2 Vlan50
0.0.0.0/0 10.10.1.1 Vlan10

The most specific entries are installed at the top of the table. Note that each
FIB entry contains the following information:
• The destination prefix
• The destination mask
• The next-hop address
• The local interface where the next-hop exists

To view the Adjacency Table:

Switch# show adjacency
Protocol Interface Address
IP Vlan50 10.50.1.1(6)
4 packets, 1337 bytes
0001234567891112abcdef120800
ARP 01:42:69
Protocol Interface Address
IP Vlan50 10.50.1.2(6)
69 packets, 42012 bytes
000C765412421112abcdef120800
ARP 01:42:69

- Switched Port Analyzer (SPAN) -

Traffic Monitoring
A common practice when troubleshooting network issues is to examine the
headers and payload of packets, through the use of packet sniffers or
analyzers.
A packet must first be captured before it can be analyzed. Packets can be
captured and analyzed on a host using locally installed software. Wireshark
and tcpdump are popular tools for this.
In legacy networks using hubs, all traffic on the network could be easily
captured. A hub forwards a packet out every port, regardless of the
destination. Thus, a single workstation with Wireshark could capture and
analyze traffic between any two hosts.
This is no longer possible on modern networks that use switches. A packet
will only be forwarded out the appropriate destination port. Thus, centrally
analyzing all traffic on a network is more difficult.

Switch Port Analyzer (SPAN)

Cisco developed the Switched Port Analyzer (SPAN) feature to facilitate
the capturing of packets. SPAN is supported on most Cisco switch
platforms.
SPAN works by copying the traffic from one or more source ports. The
copy is then sent out a SPAN destination port. The destination port will
often be connected to a host running packet analyzing software, such as
Wireshark.
Because SPAN only makes a copy of traffic, the source traffic is never
affected. SPAN is an out-of-band process.
In addition to troubleshooting network issues and performance, SPAN is
useful for intrusion detection systems (IDS) and application monitoring
platforms.
SPAN is often referred to as port mirroring.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Switched Port Analyzer (SPAN) v1.11 – Aaron Balchunas 2

SPAN Sources and Destinations

A SPAN source is where traffic is mirrored from. A SPAN source can
consist of one or more of the following:
• Access switchports
• Trunk ports
• Routed interfaces
• EtherChannels
• Entire VLANs
SPAN can mirror either inbound or outbound traffic on a source, or both.
A SPAN destination is where traffic is mirrored to. A SPAN destination port
can consist of only a single switchport, and is completely dedicated for that
purpose.
No other traffic is forwarded to or from a SPAN destination, including
management traffic such as STP and CDP. A SPAN destination does not
participate in the STP topology.
A SPAN destination port can only participate in one SPAN session, and
cannot be a SPAN source port.
Most Cisco platforms do not support an EtherChannel as a SPAN
destination. For the limited models that do, the EtherChannel must be
manually configured as on – port aggregation protocols are not supported.
The traffic from the SPAN source can exceed the bandwidth capacity of the
SPAN destination port. For example, a SPAN source of an entire VLAN can
easily exceed the capacity of a single Gigabit Ethernet port.
In this circumstance, some packets will be dropped at the SPAN destination.
Remember: source traffic is never affected by SPAN.

Configuring SPAN
Configuring SPAN involves two steps:
• Identifying the SPAN source or sources
• Identifying the SPAN destination
To configure SPAN sources:
Switch(config)# monitor session 1 source interface gi0/10 rx
Switch(config)# monitor session 1 source interface gi0/11 tx
Switch(config)# monitor session 1 source vlan 100 both

The command syntax begins monitor session, and assigns it a session

number. In the above example, the session number is 1. The SPAN
destination must use the same session number.
The above example identifies three sources:
• Inbound or rx traffic on port gi0/10
• Outbound or tx traffic on port gi0/11
• Both inbound and outbound traffic on VLAN 100
When specifying a trunk port as a source, it is possible to restrict which
VLANs are mirrored:
Switch(config)# monitor session 1 filter vlan 1-5

To configure a SPAN destination port:

Switch(config)# monitor session 1 destination interface gi0/15

Remember, the session number must match between the source and
destination. To disable a specific monitoring session:
Switch(config)# no monitor session 1

To view the status of a SPAN session:

Switch(config)# show monitor session 1
Session 1
------------
Type : local
Source Ports:
RX Only: gi0/10
TX Only: gi0/11
Both: None
Source VLANs:
RX Only: None
TX Only: None
Both: 100
Destination Ports: gi0/15

Remote SPAN (RSPAN)

The previous page describes the configuration of Local SPAN, where both
the SPAN source and destination exist on the same switch.
Remote SPAN (RSPAN) allows the SPAN source and destination to exist
on different switches. This involves configuring a RSPAN VLAN – the
mirrored traffic will be carried across this VLAN from switch to switch.
Considering the following example:

The SPAN source exists on SwitchA, and the SPAN destination exists on
SwitchC. Each switch must be configured with the RSPAN VLAN,
including the intermediary SwitchB.
To configure RSPAN on SwitchA:
SwitchA(config)# vlan 200
SwitchA(config-vlan)# remote-span
SwitchA(config)# monitor session 1 source interface gi0/10
SwitchA(config)# monitor session 1 destination vlan 200

To configure RSPAN on SwitchB:

SwitchB(config)# vlan 200
SwitchB(config-vlan)# remote-span

To configure RSPAN on SwitchC:

SwitchC(config)# vlan 200
SwitchC(config-vlan)# remote-span
SwitchC(config)# monitor session 1 source vlan 200
SwitchC(config)# monitor session 1 destination interface gi0/11

Note that on SwitchA, the SPAN destination is the RSPAN VLAN, instead
of a port. On SwitchC, the SPAN source is the RSPAN VLAN.

- Switch and VLAN Security -

Switch Port Security
Port Security adds an additional layer of security to the switching network.
The MAC address of a host generally does not change. If a specific host will
always remain connected to a specific switch port, then the switch can filter
all other MAC addresses on that port using Port Security.
Port Security supports both statically mapping MAC addresses, and
dynamically learning addresses from traffic sent on the port.
To enable Port Security on an interface:
Switch(config)# interface gi1/10
Switch(config-if)# switchport port-security

By default, Port Security will allow only one MAC on an interface. To

adjust the maximum number of allowed VLANs, up to 1024:
Switch(config-if)# switchport port-security maximum 2

To statically map the allowed MAC addresses on an interface:

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

Only hosts configured with the above two MAC addresses will be allowed to
send traffic through this port.
If the maximum number of MAC addresses for this port had been set to 10,
but only two were statically mapped, the switch would dynamically learn the
remaining eight MAC addresses.
Port Security refers to dynamically learned MAC addresses as sticky
addresses. Sticky addresses can be aged out after a period of inactivity,
measured in minutes:
Switch(config-if)# switchport port-security aging time 10

Port Security aging is disabled by default.

Switch Port Security (continued)

A violation occurs if an unauthorized MAC address attempts to forward
traffic through a port. There are three violation actions a switch can
perform:
• Shutdown – If a violation occurs, the interface is placed in an
errdisable state. The interface will stop forwarding all traffic,
including non-violating traffic, until it is removed from an errdisable
state. This is the default action for Port Security.
• Restrict – If a violation occurs, the interface will remain online.
Legitimate traffic will be forwarded, and unauthorized traffic will be
dropped. Violations are logged, either via a syslog message or SNMP
trap.
• Protect – If a violation occurs, the interface will remain online.
Legitimate traffic will be forwarded and unauthorized traffic will be
dropped, but no logging will occur.
To configure the desired Port Security violation action:
Switch(config-if)# switchport port-security violation shutdown
Switch(config-if)# switchport port-security violation restrict
Switch(config-if)# switchport port-security violation protect

To view Port Security configuration and status for a specific interface:

Switch# show port-security interface gi1/10
Port Security: Enabled
Port status: SecureUp
Violation mode: Shutdown
Maximum MAC Addresses: 10
Total MAC Addresses: 10
Configured MAC Addresses: 2
Aging time: 10 mins
Aging type: Inactivity
SecureStatic address aging: Enabled
Security Violation count: 0

Note that the maximum MAC addresses is set to 10, and that the total MAC
addresses is currently at 10 as well. The violation mode is set to shutdown.
If another MAC address attempts to forward traffic through this port, the
port will be place in an errdisable state.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Switch and VLAN Security v1.51 – Aaron Balchunas 3

802.1x Port Authentication

802.1x Port Authentication forces a host device to authenticate with the
switch, before the switch will forward traffic on behalf of that host. This is
accomplished using the Extensible Authentication Protocol over LANs
(EAPOL). 802.1x only supports RADIUS servers to provide authentication.
Both the switch and the host must support 802.1x to use port authentication:
• If the host supports 802.1x, but the switch does not – the host will not
utilize 802.1x and will communicate normally with the switch.
• If the switch supports 802.1x, but the host does not – the interface will
stay in an unauthorized state, and will not forward traffic.
A switch interface configured for 802.1x authentication stays in an
unauthorized state until a client successfully authenticates. The only traffic
permitted through an interface in an unauthorized state is as follows:
• EAPOL, for client authentication
• Spanning Tree Protocol (STP)
• Cisco Discovery Protocol (CDP)
To globally enable 802.1x authentication on the switch:
Switch(config)# dot1x system-auth-control

To specify the authenticating RADIUS servers, and configure 802.1x to

utilize those RADIUS servers:
Switch(config)# aaa new-model
Switch(config)# radius-server host 192.168.1.42 key CISCO
Switch(config)# aaa authentication dot1x default group radius

Finally, 802.1x authentication must be configured on the desired interfaces:

Switch(config)# interface gi1/10
Switch(config-if)# dot1x port-control auto

An interface can be configured in one of three 802.1x states:

• force-authorized – The interface will always authorize any client,
essentially disabling authentication. This is the default state.
• force-unauthorized – The interface will never authorize any client,
essentially preventing traffic from being forwarded.
• auto – The interface will actively attempt to authenticate the client.

VLAN Access-Lists
Normally, access-lists are applied to interfaces to filter traffic between
networks or VLANs.
VLAN Access-Lists (VACLs) filter traffic within a VLAN. Because intra-
VLAN traffic does not traverse an interface, it cannot be directly filtered
using a normal access-list.
For a VACL to function, traffic must first be identified using an access-list:
Switch(config)# ip access-list extended BLOCKTHIS
Switch(config-ext-nacl)# permit ip host 10.1.5.10 10.1.0.0 0.0.255.255

VACLs support three types of access-lists:

• IP
• IPX
• MAC address
Note that the access-list is not used to deny or permit traffic. Instead, it
identifies traffic for the VACL to deny or permit. The ACL permit
parameter functions as a true statement, and a deny parameter functions as a
false statement.
To configure the VACL itself:
Switch(config)# vlan access-map MY_VACL 5
Switch(config-access-map)# match ip address BLOCKTHIS
Switch(config-access-map)# action drop
Switch(config-access-map)# vlan access-map MY_VACL 10
Switch(config-access-map)# action forward
Switch(config)# vlan filter MY_VACL vlan-list 102

The first line creates a vlan access-map named MY_VACL. Traffic that
matches entries in the BLOCKTHIS access-list will be dropped.
The final vlan access-map entry contains only an action to forward. This
will apply to all other traffic, as no other access-list was specified. Finally
the VACL is applied to VLAN 102.
Notice that every access-map statement contains a sequence number - 5 and
10 respectively in the above example. This dictates the order in which the
rules should be processed.
***
All original material copyright © 2014 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
Switch and VLAN Security v1.51 – Aaron Balchunas 5

Private VLANs
Private VLANs (PVLANs) allow for further segmentation of a subnet
within a VLAN. This is accomplished by creating secondary VLANs within
a primary VLAN.
The secondary VLAN can communicate only with the primary VLAN, and
not any other secondary VLANs.
There are two types of secondary VLANs:
• Community
• Isolated
Hosts within a community VLAN can communicate with each other, and
with the primary VLAN.
Hosts within an isolated VLAN cannot communicate with each other.
However, the hosts can still communicate with the primary VLAN.
Private VLANs are only locally-significant to the switch. VTP will not pass
information on Private VLANs to other switches.
Each switch port in a private VLAN must be configured with a specific
mode:
• Promiscuous
• Host
A promiscuous port can communicate with the primary VLAN and all
secondary VLANs. Gateway devices such as routers and switches should be
configured as promiscuous ports.
A host port can communicate only with promiscuous ports, and other ports
within the local community VLAN. Host devices such as workstations
should be configured as host ports.
Private VLANs allow a group of hosts to be segmented within a VLAN,
while still allowing those devices to reach external networks via a
promiscuous gateway.
Service providers can use private VLANs to segregate the traffic of multiple
customers, while allowing them to share a gateway.

Private VLAN Configuration

Configuring private VLANs involves the following:
• Creating secondary VLANs
• Creating primary VLANs
• Associating secondary VLANs to a primary VLAN
• Associating ports to either a primary or secondary VLAN
To create secondary VLANs:
Switch(config)# vlan 100
Switch(config-vlan)# private-vlan community
Switch(config)# vlan 101
Switch(config-vlan)# private-vlan isolated

To create a primary VLAN, and associate secondary VLANs:

Switch(config)# vlan 50
Switch(config-vlan)# private-vlan primary
Switch(config-vlan)# private-vlan association 100,101

To associate a port to a primary and secondary VLAN:

Switch(config)# interface gi1/10
Switch(config-if)# switchport private-vlan host
Switch(config-if)# switchport private-vlan host-association 50 101

The gi1/10 port has been identified as a host port, and associated with
primary VLAN 50, and secondary VLAN 101.
To configure a promiscuous port:
Switch(config)# interface gi1/20
Switch(config-if)# switchport private-vlan promiscuous
Switch(config-if)# switchport private-vlan mapping 50 100.101

The promiscuous gi1/20 port is associated with primary VLAN 50, and the
two secondary VLANs, 100 and 101.
To allow the primary VLAN SVI to perform Layer-3 forwarding for
specified secondary VLANs:
Switch(config)# interface vlan 50
Switch(config-if)# private-vlan mapping 100,101

DHCP Snooping
Dynamic Host Control Protocol (DHCP) provides administrators with a
mechanism to dynamically assign IP addresses, rather than manually
configuring the address on each host.
DHCP servers lease out IP addresses to DHCP clients, for a specific period
of time. There are four steps to this DHCP process:
• When a DHCP client first boots up, it broadcasts a DHCPDiscover
message, searching for a DHCP server.
• If a DHCP server exists on the local segment, it will respond with a
DHCPOffer, containing the offered IP address, subnet mask, etc.
• Once the client receives the offer, it will respond with a
DHCPRequest, indicating that it will accept the offered protocol
information.
• Finally, the server responds with a DHCPACK, acknowledging the
clients acceptance of offered protocol information.
Malicious attackers can place a rogue DHCP server on the trusted network,
intercepting DHCP packets while masquerading as a legitimate DHCP
server. This is a form of spoofing attack, which intends to gain unauthorized
access or steal information by sourcing packets from a trusted source. This is
also referred to as a man-in-the-middle attack.
DHCP attacks of this sort can be mitigated by using DHCP Snooping. Only
specified interfaces will accept DHCPOffer packets – unauthorized
interfaces will discard these packets, and then place the interface in an
errdisable state.
DHCP Snooping must first be globally enabled on the switch:
Switch(config)# ip dhcp snooping

Then, DHCP snooping must be enabled for one or more VLANs:

Switch(config)# ip dhcp snooping vlan 5

By default, all interfaces are considered untrusted by DHCP Snooping.

Interfaces connecting to legitimate DHCP servers must be trusted:
Switch(config)# interface gi1/20
Switch(config)# ip dhcp snooping trust

Dynamic ARP Inspection

Another common man-in-the-middle attack is ARP spoofing, sometimes
referred to as ARP poisoning. A malicious host can masquerade as another
host, by intercepting ARP requests and responding with its own MAC
address.
Dynamic ARP Inspection (DAI) mitigates the risk of ARP Spoofing, by
inspecting all ARP traffic on untrusted ports. DAI will confirm that a
legitimate MAC-to-IP translation has occurred, by comparing it against a
trusted database.
This MAC-to-IP database can be statically configured, or DAI can utilize the
DHCP Snooping table, assuming that DHCP Snooping has been enabled.
To globally enable DAI for one or more VLANs:
Switch(config)# ip arp inspection vlan 100

By default, all interfaces in VLAN 100 will be considered untrusted, and

thus subject to inspection by DAI. Trunk ports to other switches should be
configured as trusted, indicating no inspection will occur, as each switch
should handle DAI locally:
Switch(config)# interface gi1/24
Switch(config-if)# ip arp inspection trust

To create a manual MAC-to-IP database for DAI to reference:

Switch(config)# arp access-list DAI_LIST
Switch(config-acl)# permit ip host 10.1.1.5 mac host 000a.1111.2222
Switch(config-acl)# permit ip host 10.1.1.6 mac host 000b.3333.4444

Switch(config)# ip arp inspection filter DAI_LIST vlan 100

If an ARP response does not match the MAC-to-IP entry for a particular IP
address, then DAI drops the ARP response and generates a log message.

Attivo BOTsink Appliance User Guide
No ratings yet
Attivo BOTsink Appliance User Guide
874 pages
Wiring Drawing
100% (10)
Wiring Drawing
8 pages
BGP Case Studies PDF
No ratings yet
BGP Case Studies PDF
79 pages
Attivo Central Manager User Guide
No ratings yet
Attivo Central Manager User Guide
848 pages
M11 Pro Complete User Manual - EN
No ratings yet
M11 Pro Complete User Manual - EN
37 pages
[Ebooks PDF] download Android Cookbook Problems and Solutions for Android Developers 2nd Edition Ian F. Darwin full chapters
100% (2)
[Ebooks PDF] download Android Cookbook Problems and Solutions for Android Developers 2nd Edition Ian F. Darwin full chapters
55 pages
Energy Metering IC With SPI Interface and Active Power Pulse Output
No ratings yet
Energy Metering IC With SPI Interface and Active Power Pulse Output
44 pages
ImplementingACIv2
No ratings yet
ImplementingACIv2
105 pages
Penetration Testing and Network Defense
No ratings yet
Penetration Testing and Network Defense
624 pages
ISE Secure Wired Access Prescriptive Deployment Guide - Cisco Community
No ratings yet
ISE Secure Wired Access Prescriptive Deployment Guide - Cisco Community
186 pages
Libro Acsa
No ratings yet
Libro Acsa
684 pages
DPC-08S Xguard User Manual
100% (1)
DPC-08S Xguard User Manual
39 pages
MIT AI course Making AI Work
No ratings yet
MIT AI course Making AI Work
11 pages
End-To-End QoS Network Design Quality of Service in LANs WANs and VPNs
No ratings yet
End-To-End QoS Network Design Quality of Service in LANs WANs and VPNs
769 pages
Interdomain Multicast Soln Guide 1587050838
No ratings yet
Interdomain Multicast Soln Guide 1587050838
336 pages
Power VT PDF
No ratings yet
Power VT PDF
2 pages
Is Is Network Design Solutions
No ratings yet
Is Is Network Design Solutions
416 pages
TPControl-API-Commands-supported-in-addition-to-AMX-commands
No ratings yet
TPControl-API-Commands-supported-in-addition-to-AMX-commands
19 pages
Ccie Entreprise SW
100% (1)
Ccie Entreprise SW
282 pages
IPDirector Userman IPEdit
No ratings yet
IPDirector Userman IPEdit
270 pages
Aveva Intouch Access Anywhere User Guide
No ratings yet
Aveva Intouch Access Anywhere User Guide
38 pages
IATF & IQA System Awareness Training
No ratings yet
IATF & IQA System Awareness Training
20 pages
Brkccie 3000
100% (1)
Brkccie 3000
93 pages
NBSC - Wo - 18-0020 - Nokia Bsc193 PLDT Sta. Mesa (2nd) Cs Link Cleanup
No ratings yet
NBSC - Wo - 18-0020 - Nokia Bsc193 PLDT Sta. Mesa (2nd) Cs Link Cleanup
29 pages
Rus Ukr Cyber - SLIDES
No ratings yet
Rus Ukr Cyber - SLIDES
19 pages
Control Policies SD Wan
No ratings yet
Control Policies SD Wan
58 pages
Biomedical Applications of DSP
0% (1)
Biomedical Applications of DSP
6 pages
400 101 PDF
100% (1)
400 101 PDF
508 pages
Services PDF
No ratings yet
Services PDF
33 pages
HUMAN RESOURCE INFORMATION SYSTEM-Case
No ratings yet
HUMAN RESOURCE INFORMATION SYSTEM-Case
11 pages
PIC18F47K42 Curiosity Nano Schematics
No ratings yet
PIC18F47K42 Curiosity Nano Schematics
16 pages
Understanding OSPF
No ratings yet
Understanding OSPF
289 pages
Balance of System: Tamilvanan, 2011189014
No ratings yet
Balance of System: Tamilvanan, 2011189014
30 pages
Applications of DSP
No ratings yet
Applications of DSP
11 pages
VPNCH01
No ratings yet
VPNCH01
37 pages
Quick Start Guide: IBM Security Identity Manager
No ratings yet
Quick Start Guide: IBM Security Identity Manager
2 pages
WSA 7.0.0 UserGuide
No ratings yet
WSA 7.0.0 UserGuide
784 pages
Integrated Management System: Departmental Functional Manual
No ratings yet
Integrated Management System: Departmental Functional Manual
40 pages
Versa - Configure AAA
No ratings yet
Versa - Configure AAA
21 pages
Tutor
No ratings yet
Tutor
5 pages
Making A Knockoff WiFi Pineapple From A GL-iNet AR150
100% (1)
Making A Knockoff WiFi Pineapple From A GL-iNet AR150
4 pages
01 Cisco CCIE Routing - Switching V4 Experience
No ratings yet
01 Cisco CCIE Routing - Switching V4 Experience
16 pages
IOS XR BGP Commands PDF
No ratings yet
IOS XR BGP Commands PDF
420 pages
Wi-Fi Capacity Analysis WP PDF
No ratings yet
Wi-Fi Capacity Analysis WP PDF
21 pages
Port Channels and LACP
No ratings yet
Port Channels and LACP
68 pages
As 1973-1993 Pneumatic Tyres - Passenger Car Light Truck and Truck Bus - Retreading and Repair Processes
No ratings yet
As 1973-1993 Pneumatic Tyres - Passenger Car Light Truck and Truck Bus - Retreading and Repair Processes
8 pages
General Networking: Introduction To Networks
No ratings yet
General Networking: Introduction To Networks
3 pages
Resume: Objective
No ratings yet
Resume: Objective
3 pages
Cisco FireAmp User Guide
No ratings yet
Cisco FireAmp User Guide
187 pages
IR Sensor Based Distance Measurement System
No ratings yet
IR Sensor Based Distance Measurement System
5 pages
Konecranes - Brochure - Noell HYBRID Straddle Carrier - 2020
No ratings yet
Konecranes - Brochure - Noell HYBRID Straddle Carrier - 2020
3 pages
BRKCRS 3146
No ratings yet
BRKCRS 3146
89 pages
Cisco 3750 Configuration Guide
No ratings yet
Cisco 3750 Configuration Guide
1,010 pages
Object-Oriented Programming Lab Problems
No ratings yet
Object-Oriented Programming Lab Problems
6 pages
CCNP - BSCI.Quick - Reference.Sheets - Exam.642901 Ebook - Ipmanager.ir PDF
100% (1)
CCNP - BSCI.Quick - Reference.Sheets - Exam.642901 Ebook - Ipmanager.ir PDF
73 pages
CCIE Voice Lab Workbook
No ratings yet
CCIE Voice Lab Workbook
30 pages
Eng Civil
No ratings yet
Eng Civil
10 pages
BRKCRT 8001
100% (1)
BRKCRT 8001
264 pages
SPM (visualizing progress)
No ratings yet
SPM (visualizing progress)
4 pages
TW QFabric TrafficFlows
No ratings yet
TW QFabric TrafficFlows
82 pages
Alt - F6104GW6-1 PDF
No ratings yet
Alt - F6104GW6-1 PDF
4 pages
CCNP v6 Route Lab 2.1
No ratings yet
CCNP v6 Route Lab 2.1
13 pages
CIS Cisco Firewall Benchmark v2.2.0
No ratings yet
CIS Cisco Firewall Benchmark v2.2.0
56 pages
Training Man-E Cisco - Multicast PDF
No ratings yet
Training Man-E Cisco - Multicast PDF
65 pages
Zenon 8 20 Release Infographic EN
No ratings yet
Zenon 8 20 Release Infographic EN
5 pages
SISAS Slides Book
No ratings yet
SISAS Slides Book
68 pages
ISR Router Family PDF
No ratings yet
ISR Router Family PDF
26 pages
BRKCRS 2663
No ratings yet
BRKCRS 2663
88 pages
Dry Vacuum Pump - LS Series
No ratings yet
Dry Vacuum Pump - LS Series
4 pages
Lab-00-01 - Configure Cisco 3600 Router To Use As A Switch in GNS3
No ratings yet
Lab-00-01 - Configure Cisco 3600 Router To Use As A Switch in GNS3
1 page
IT NE 2005 LAB 4 - Securing Administrative Access Using AAA and RADIUS.
No ratings yet
IT NE 2005 LAB 4 - Securing Administrative Access Using AAA and RADIUS.
16 pages
300-420 ENSLD Designing Cisco Enterprise
No ratings yet
300-420 ENSLD Designing Cisco Enterprise
3 pages
Switch Stack Update: Prerequisites
No ratings yet
Switch Stack Update: Prerequisites
10 pages
CCNP Switch Tema 10
0% (1)
CCNP Switch Tema 10
7 pages
Photonic Crystal Fibers
No ratings yet
Photonic Crystal Fibers
10 pages
Catalyst 3650 Series Switches Best Practices Guide
No ratings yet
Catalyst 3650 Series Switches Best Practices Guide
14 pages
Deploying Ipv6 in Branch Networks: Last Updated: April 8, 2011
No ratings yet
Deploying Ipv6 in Branch Networks: Last Updated: April 8, 2011
40 pages
QoS Hierarchical Queueing Framework Configuration Guide, CiscoIOS Release 15M&T
No ratings yet
QoS Hierarchical Queueing Framework Configuration Guide, CiscoIOS Release 15M&T
32 pages
Catalyst 6500 Series and Cisco 7600 Series Firewall Services Module Installation and Configuration Note
No ratings yet
Catalyst 6500 Series and Cisco 7600 Series Firewall Services Module Installation and Configuration Note
218 pages
What Is The Main Difference Between DMVPN Phase 2 and Phase 3 ? - Network Bulls
No ratings yet
What Is The Main Difference Between DMVPN Phase 2 and Phase 3 ? - Network Bulls
6 pages
Connect&Develop Summary
No ratings yet
Connect&Develop Summary
2 pages
CCIE Enterprise Wireless v1 Exam Topics
No ratings yet
CCIE Enterprise Wireless v1 Exam Topics
6 pages
Cisco SD Access
No ratings yet
Cisco SD Access
10 pages
101 - Exam 300-115
No ratings yet
101 - Exam 300-115
11 pages
Cisco NX-OS IOS BGP (Advanced) Comparison
No ratings yet
Cisco NX-OS IOS BGP (Advanced) Comparison
6 pages
1-Booklist For CCIE
No ratings yet
1-Booklist For CCIE
3 pages
CCNA Study Guide - Vir Lab 4 Lab Mapping
No ratings yet
CCNA Study Guide - Vir Lab 4 Lab Mapping
4 pages
QinQ Introduction
No ratings yet
QinQ Introduction
4 pages
CCIE R&S Recommed Reading PDF
No ratings yet
CCIE R&S Recommed Reading PDF
1 page
Deploying Cisco Service Provider Network Routing (642-883) : Exam Description
No ratings yet
Deploying Cisco Service Provider Network Routing (642-883) : Exam Description
2 pages
CCNA Sample Questions
No ratings yet
CCNA Sample Questions
13 pages
REMOTE ACCESS VPN- SSL VPN: A deep dive into SSL VPN from basic
From Everand
REMOTE ACCESS VPN- SSL VPN: A deep dive into SSL VPN from basic
MAMTA DEVI
5/5 (1)
Mastering SaltStack
From Everand
Mastering SaltStack
Joseph Hall
No ratings yet
Mastering The Spritekit Framework: Develop Professional Games With This New Ios 7 Framework
From Everand
Mastering The Spritekit Framework: Develop Professional Games With This New Ios 7 Framework
Peter van de Put
No ratings yet
Next-Generation switching OS configuration and management: Troubleshooting NX-OS in Enterprise Environments
From Everand
Next-Generation switching OS configuration and management: Troubleshooting NX-OS in Enterprise Environments
Mamta Devi
No ratings yet
VMware Horizon View Essentials
From Everand
VMware Horizon View Essentials
Peter von Oven
No ratings yet

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.