Advanced Switching Reference Manual Ver. 0.9

Reference Manual ver. 1.
0 (2012-14)
Created by Paul Nadstoga (pnadstoga@gmali.com)
Contents
PLANNING & DESIGN
ETHERNET
VLANs
SPANNING TREE PROTOCOL
L2 SECURITY
HIGH AVAILABILITY
APPENDIXES
1
9
30
60
103
124
145
PLANNING &
DESIGN
CISCO Design Recommendations
Enterprise Campus Network Design
CISCO DESIGN RECOMMENDATIONS

GENERAL NETWORK PLANNING
test the design on a pilot network first before deploying in on the corporate network
when planning for High Availability, use correct technology and redundancy within that technology
a documented rollback plan should be a part of any implementation plan
VLAN approach recommended whenever possible:
o
o
o
ACCESS LAYER: focus on port density and VLAN termination

DISTRIBUTION LAYER: focus on routing and boundary definitions
CORE LAYER: exclusive focus on traffic transport optimization
SECURITY PLANNING
list all the applications running in the environment

consider having a network audit
the design should include:
o
o
o
an incident response plan

security policy
a list of customers requirements
VLAN PLANNING
organizational objectives to keep in mind when developing a VLAN implementation plan could include:
o
o
o
improving customer support

increased competitiveness
reduced costs
have a summary implementation plan that lays out the implementation overview
incremental implementation of components is the recommended approach when defining a VLAN implementation plan
ADVANCED SWITCHING ver. 1.0 CREATED BY PAWEL PAUL NADSTOGA (PNADSTOGA@GMAIL.COM) 2013-14
SONA
CISCO model that provides guidance, best practices, and blueprints for connecting network services and applications to enable business solutions
SONA outlines three layers for the enterprise network:
o
o
o
NETWORK INFRASTRUCTURE LAYER where all the network devices are connected (network, servers, storage etc.)
INTERACTIVE SERVICES LAYER allocated resources to applications delivered through the network infrastructure layer
APPLICATION LAYER includes business applications
PPDIOO
PREPARE requirements, strategy, financial justification

PLAN network requirements, shortcoming of the existing network, project plan
DESIGN create design specifications
IMPLEMENT build the network and add additional components
OPERATE maintain network health, day to day operations
OPTIMIZE proactive management, optimize the network design
ENTERPRISE CAMPUS NETWORK DESIGN

HIERARCHICAL NETWORK DESIGN
a design based around organising the network into distinct layers of devices
traffic flow is the most important factor in the design (not traffic type)
the network should be design so that all end users are located at a consistent distance from the resources they need to use
the resulting network is: efficient, intelligent, scalable, and easily managed
traffic flow can be classified as three types (based on where the network service / resources are located in relation to the end user):
o
o
o
LOCAL same segment / VLAN as user (traffic can access ACCESS layer only)
REMOTE different segment / VLAN as user (traffic can access DISTRIBUTION layer)
ENTERPRISE central to all campus users (traffic can access DISTRIBUTION and CORE layers)
ACCESS LAYER
user connect here to the network

high port density
scalable uplinks to higher layers
user access functions (VLANs, traffic and protocol filtering, QoS)
redundancy through multiple uplinks
DISTRIBUTION LAYER
interconnection between ACCESS and CORE layers

high port density of high-speed links to support the collection of ACCESS layer switches
aggregate uplinks from ACCESS layer switches
high L3 throughput (to be capable of processing the total volume of traffic from all the connected devices)
ACLs, packet filters
QoS
redundancy through multiple uplinks
CORE LAYER
provides connectivity of all DISTRIBUTION layer devices

must be capable of switching traffic as efficiently as possible
very high throughput at L3
no unnecessary packet manipulation (ACLs, filtering etc.)
high availability
advanced QoS functions
MODULAR NETWORK DESIGN
each layer of the hierarchical network model can be broken into basic functional units
the modules can then be sized appropriately and connected, while allowing for future scalability and expansion
enterprise campus network can be divided into the following units:
o
o
SWITCH BLOCK
CORE BLOCK
SWITCH BLOCK
a group of ACCESS together with their DISTRIBUTION layer switches

all switch blocks connect to the CORE BLOCK providing end-to-end connectivity across campus
contains a balanced mix of L2 (ACCESS) and L3 (DISTRIBUTION) functionality
confines STP
the DISTRIBUTION is the boundary for VLANs, subnets and broadcasts these are not propagated into the CORE BLOCK
usually no more than 2000 users should be placed within a single SWITCH BLOCK
the size should be based primarily on traffic types and behaviour, and size and number of common workgroups
a SWITCH BLOCK is too large when:
o
o
devices at the DISTRIBUTION layer become bottlenecks (due to the volume of inter-VLAN traffic, CPU intensive filtering and packet manipulation etc.)
broadcast / multicast traffic slows down the traffic
x2 DISTRIBUTION switches per SWITCH BLOCK with ACCESS switches having two uplinks (connecting to each DISTRIBUTION switch)
all L2 connectivity should be contained within ACCESS layer
only L3 connectivity at DISTRIBUTION layer
SWITCH BLOCK EXAMPLES:

L2 ACCESS SWITCHES
each VLAN extends to the

DISTRIBUTION switch but no further
no dependence on STP convergence
a L3 link between DISTRIBUTION
switches to carry routing updates
L2 / 3 ACCESS SWITCHES
VLANs are limited to the ACCESS

switches
no dependence on STP convergence
L3 links between ACCESS and
DISTRIBUTION switches carry routing
updates
networks stability thorough the routing
protocol convergence
CORE BLOCK
connects two or more SWITCH BLOCKs together

must be as efficient and resilient as possible (it is campus networks basic foundation and carries much more traffic than SWITCH BLOCK)
at a minimum each CORE switch must handle switching each of its incoming DISTRIBUTION links at 100% capacity
two basic designs:
o
o
COLLAPSED CORE
DUAL CORE
COLLAPSED CORE
CORE and DISTRIBUTION layers merged together (their functions are provided by the same devices)
smaller campus networks (a separate CORE layer is now warranted)
each ACCESS switch has a redundant link to each DISTRIBUTION / CORE switch
all L3 subnets presents in the ACCESS layer terminate at the DISTRIBUTION switches L3 ports
DISTRIBUTION / CORE switches are interconnected with one or more links
at L3 redundancy is provided through a redundant gateway protocol (HSRP, VRRP, GLBP)
the CORE is not scalable when more SWITCH BLOCKS are added!
DUAL CORE
CORE functions is an independent module

recommended to build the CORE with multilayer switches
use two identical switches to provide redundancy
SWITCH
Ethernet Standard
Ethernet Switch
Switchport
Etherchannel
ETHERNET STANDARD
ETHERNET OVERVIEW
a LAN technology
the medium should be chosen in accordance to the needs and requirements
Ethernet is popular because of its low cost, market availability, and scalability to higher bandwidths
ETHERNET STANDARDS
NAME
ETHERNET
FAST ETHERNET
GIGABIT ETHERNET
STANDARD
OVERVIEW
802.3
10 Mbps
CSMA/CD
half / full duplex
100 m. cable limit
usually used to connect ACCESS switches to end devices
802.3u
100 Mbps
CSMA/CD
half / full duplex
100 m. cable limit
usually used to connect ACCESS to DISTRIBUTION switches
same L2 as 802.3, different L1
backward compatibility with 802.3u allows for operation at maximum common level
1,000 Mpbs
full-duplex (auto-negotiation is not possible)
the L1 has been modified:
o
802.3z
10 GIGABIT ETHERNET
802.3ae
COMMENTS
The half-duplex and collisions issues are
non-existent in switched Ethernet.
IEEE 802.3 Ethernet provided frame format, CSMA/CD, full duplex and other Ethernet
characteristics
ANSI X3T11 FibreChannel provided a base of high-speed ASICs, optical components,
encoding/decoding and serialization mechanisms
usually used to connect individual devices to a switch or to connect 2 x switches together
10,000 Mpbs
same frame format allows backward compatibility
full-duplex mode exclusively
10
ETHERNET SWITCH
ETHERNET SWITCH OVERVIEW
L2/L3 device used to forward frames

frame forwarding decision is based on the destination MAC address and its associated switchport
the MAC address-to-switchport mapping can be done statically or dynamically
the scope of collision domain is limited to a given segment because every switchport is its own isolated segment
segments can operate at full-duplex speed because there is no contention on the media
each switchport offers dedicated bandwidth across the segment
packets are received, inspected and then forwarded (store and forward) corrupted frames are not forwarded
limits can be set on broadcast traffic
11
ETHERNET SWITCH OPERATION

OPERATION
PURPOSE
LEARNING
COMMENTS
upon arrival on a switchport , every frames source MAC address is examined and compared to entries in the CAM table
if no entry is present, the MAC address is mapped to the port it arrived on and the entry is time-stamped
if an entry is present, the timestamp is updated
if the entry is present but the MAC arrived on a different port, the entry is deleted and MAC is mapped to the
most recent arrival port
To manually add an entry to the CAM table:

<Switch(config)# mac address-table static (HH:HH:HH) vlan (vlan ID) interface (interface)>
To avoid having duplicate entries in the

table, the switch will delete an entry for a
port to MAC mapping if the same MAC
has been learned on a different port (MAC
addresses are unique and should never be
seen on more than one switch port).
If a MAC address is being learnt on
multiple interfaces, it is flagged as
flapping.
To view CAM table:

<Switch#show mac address-table>
AGING
entries in the CAM table are kept for 300 sec. before being deleted
the timer is reset when the switch receives a frame from a node on the same port
aging-time 0 disables aging
To modify the aging timer:

<Switch(config)#mac address-table aging-time (300, 10-1000000)>
FLOODING
the switch floods the frame (sends it on all operational ports) when no entries in the CAM tables can be found
also known as unknown unicast flooding
SELECTIVE FORWARDING
based on the information found in the CAM table

when a frame arrives at a switch port, it is placed into one of the ports ingress queues
the frames destination MAC address is used as a key into the CAM table
if the address if found, the outbound port + VLAN ID are used
if the address is not found, the frame is flooded on all switch ports (except the one the frame was received on)
FILTERING
based on the information found in the TCAM table

frames can be filtered based on ACLs and QoS parameters
frames that failed the CRC check are dropped
For broadcasts and multicasts flooding is

considered a default behaviour.
12
SWITCH FRAME FORWARDING LOGIC

LAYER 2 SWITCHING
ingress queues inbound frames are placed in one of the switches ingress queues with each
having different priority or service levels
security ACLs (TCAM) used for inbound / outbound frames filtering
QoS ACLs (TCAM) - used to classify frames and apply policies
L2 forwarding table destination MAC address is used as an index to the CAM table
egress queues outbound frames are placed here; determined by QoS values
contained in the frame or passed along with the frame
The decisions where and whether at all forward the frame are made simultaneously!
LAYER 3 SWITCHING
L2 forwarding table destination MAC address is used as an index to the CAM table
L3 forwarding table destination IP address is used as an index to the FIB table
security ACLs (TCAM) used for inbound / outbound frames filtering
QoS ACLs (TCAM) - used to classify frames and apply policies
The decisions where and whether at all forward the frame are made simultaneously!
13
SWITCH FORWARDING ARCHITECTURES
Process Switching
o
Route Caching (NetFlow switching, fast switching, flow-based switching)

o
o
each packet is examined by the internal processor and is handled in software (only used in routers)
the route processor tracks the first packets flow and sets up a shortcut for the remaining packets to avoid software-based routing (immediately forwarding in hardware)
used by both routers and L3 Switches
CEF (topology based switching)

o
o
o
CISCO Express Forwarding

routing table dynamically populates a single database of the entire network topology in hardware
default option on CISCO routers and switches
14
SWITCH MEMORY TYPES

MEMORY
(CAM) CONTENT-ADDRESSABLE MEMORY
OVERVIEW
capable of searching the entire content in a single operation

provides two results upon lookup: 0 (true) / 1 (false)
stores MAC table
To view the MAC table content:
COMMENTS
vlan ports VLAN membership

mac address L2 address associated with the switch port
type static or dynamic
port switch port mapped to the MAC address
Stale entries are aged out after 300 sec. and deleted.
<S1#show mac address-table (dynamic | address (mac-address) | interface (interface))>
TSHOOT
show mac address-table

show mac address-table count
clear mac address-table
15
(TCAM) TERNARY CONTENT-ADDRESSABLE MEMORY
provides three results upon lookup: 0 (true), 1 (false), any value
Most switches have multiple TCAM so that inbound and

outbound filtering can be done simultaneously or in parallel
with L2 / L3 forwarding decision.
On the Catalyst Switch IOS TCAM operation consist of:
Feature Manager (FM) the FM software compiles /

merges ACLs into entries in the TCAM table.
Switching Database Manager (SDM) used to
manipulate TCAM partitions for use for different
functions
TCAM entries are composed of:
Values 134 bit quantities consisting of source and

destination addresses + other relevant protocol
information (all patterns to be matched)
Masks 134 bit quantities that select only the value bits
of interest; a mask bit is set to exactly match a value bit
or is not set for value bit that do not matter
Results numeric values that represent what actions to
take after the TCAM lookup occurs (e.g. permit, deny,
index value to a QoS policer etc.)
16
SWITCHPORT
SWITCHPORT CONFIGURATIONS
PORT SELECTION
ITEM
SINGLE PORT
MULTIPLE PORTS
COMMANDS
COMMENTS
<S1(config)#interface (type) (number)>

<S1(config-if)#...>
<S1(config)#interface range (type) (1st) (, | -) (2nd) >
<S1(config-if-range)#...>
<S1(config)#define interface-range (macro name) (type) (1st) (, | -) (2nd) >
MACROS
<S1(config)#interface range macro (macro name)>

<S1(config-if-range)#...>
PORT ID
DESCRIPTION
<S1(config-if)#description (description; up to 240 characters)>
PORT SPEED / DUPLEX MODE
SPEED
<S1(config-if)#speed (auto | 10 | 100 | 1000)>
NOTE: Gigabit Ethernet ports are always set to 1000!
CISCO recommends hardcoding the speed value
If a 10/100 or a 10/100/1000 port is assigned a speed

of Auto, both its speed and duplex mode is negotiated.
If both ports are set to auto-negotiate, they will use
the highest common speed.
17
<S1(config-if)#duplex (auto | full | half)>

CISCO recommends hardcoding the duplex value
Auto-negotiation is only allowed on Fast Ethernet and Gigabit

Ethernet ports.
The port that participates in auto-negotiation
attempts a full-duplex operation first and, if not
successful, half-duplex next.
If the speed is set to auto, the duplex mode cannot be
modified manually.
The process is repeated whenever the ports status
changes.
Duplex mismatch: different modes on each end; halfduplex station will detect collision when both ends
transmit, the full duplex end will transmit at any time.
If a mode is set to a non-auto value on one end and to
auto on another, the negotiation will fail (either both
are set to auto or mode on both is set to the same
value)
DUPLEX MODE
Auto-negotiation uses priorities to determine which

technology to agree on if both devices can support
more than one technology, the one with highest
priority is used
PRIORITY
TECHNOLOGY
100BASE-T2 (full duplex)
100BASE-TX (full duplex)
100BASE-T2 (half duplex)
100BASE-T4
100BASE-TX
10BASE-T (full duplex)
10BASE-T
18
ERROR MANAGEMENT
<S1(config)#errdisable detect cause (all | cause name)>
TRIGGER
all
arp-inspection
bpduguard
channel-misconfig
dhcp-rate-limit
DETECTION SCOPE
EtherChannel bundle
DHCP snooping
inline power
link-flap
link flapping
udld
BDPU is received on a STP Port Fast
inpower
storm-control
<S1(config-if)#shutdown>
<S1(config-if)#no shutdown>
dynamic ARP inspection
DTP flapping
security-violation
every possible cause
dtp-flap
rootguard
Manual:
SCOPE
BDPU received on an wrong port

security policy breach
strom control threshold exceeded
unidirectional link
errdisable recovery interval time interval the

port stays down before automatic recovery
ERROR RECOVERY
Automatic:
<S1(config)#errdisable recovery (all | cause name)>
<S1(config)#errdisable recovery interval (300, 30-86400)>
19
SWITCHPORT VERIFICATION AND TSHOOTING
show interfaces (interface)

show interfaces status
show interface status err-disabled
COMMAND
VERIFIES / DISPLAYS
EXAMPLE / SCREENSHOT
port status
description
encapsulation
keepalive mechanism
duplex mode
port speed
show interfaces
20
show interfaces status
show interfaces status errdisabled
description / status / vlan ID / dupex mode / speed / type
Lists all ports in error disable state
21
ETHERCHANNEL
ETHERCHANEL OVERVIEW
a method of aggregating from 2 up to 8 links (of same media type and speed) together into a single logical link
the bundle provides a full-duplex bandwidth
can operate either as an access or trunk link
traffic is distributed across the individual links within the bundle
if one of the links within the bundle fails, traffic is automatically moved to an adjacent link
all links must have identical VLAN settings
all links must have identical speed and duplex settings
all links must have identical trunk port settings
all links must have identical STP settings
none of the individual ports can have switch port security enabled
none of the individual ports can be a SPAN port
frames are forwarded on a specific link as a result of a hashing algorithm
can be established using the following mechanisms: PAgP, LACP (IEEE 802.3ad) or static persistence
if settings are applied to bundle --> apply to member ports
if settings are applied to a member --> leave member in the bundle but suspend it
22
ETHERCHANNEL LOAD BALACING
load-balancing is performed by frame (not by bit)

load-balancing parameters do not have to match on both ends however, this may result in asymmetric balancing
if a frame cannot meet the load balancing criteria, the switch automatically falls back to the next lowest method
the load balancing algorithm is set globally for the switch i.e. not on a port to port basis
no received broadcast / multicasts are sent out other ports in the bundle
outgoing broadcast / multicasts are load balanced as per standard operation
a method should be chosen that provides the greatest distribution or variety when the channel links are indexed
STEP #
COMMAND
COMMENTS
<S1(config)#port-channel load-balance (src-ip, method)>

METHOD
SELECT LOAD BALANCING

METHOD
HASH INPUT
OPS
src-ip
source IP address
bits
dst-ip
destination IP address
bits
src-dst-ip
source and destination IP address
XOR
src-mac
source MAC address
bits
dst-mac
destination MAC address
bits
source and destination MAC address
XOR
src-dst-mac
23
ETHERCHANNEL CONFIGURATIONS
PAgP EtherChannel
Port Aggregation Protocol

CISCO proprietary
using a negotiation protocol introduces overhead and delay in initialization
STP sends packets over only one physical link the PAgP bundle
STEP #
COMMAND
COMMENTS
<S1(config)#interface (*range) (interface)>
SELECT MEMBER PORTS
When ports are configured as member ports of an EtherChannel, a logical portchannel interface is automatically created.
*<S1(config-if)#shutdown>
Good practice to shut down the ports that are being configured.
HARDCODE NEGOTIATION PROTOCOL
<S1(config-if)#channel-protocol pagp>
<S1(config-if)#channel-group (1-64) mode (auto | desirable) *(silent)>
CONFIGURE THE GROUP
auto willing to become an EtherChannel; not pro-active

desirable - willing to become an EtherChannel, pro-active
non-silent all ports are expected to receive a PAgP traffic before
being added to the budle; if PAgP is not heard on an active port, it
remains in the UP state but PAgP reports to the SPT that the port is
DOWN
silent forms EtherChannel even if no PAgP traffic has been
received from the other end; allows the switch to form an
EtherChannel with devices such as file server that doesnt
participate in PAgP.
NOTE: it may take as long as 50 sec. for the data to start flowing through
the bundle first 15 sec. are result of PAgP silent mode waiting to
receive inbound PAgP messages, and the final 30 sec. are the result of
the STP moving through the LISTENING and LEARNING
24
LACP
Link Aggregation Control Protocol

IEEE 802.3ad
the switch with the lowest system priority (2-byte priority value + 6 byte MAC address) decides what ports actively are participating in the EtherChannel
up to 16 ports can be defined as a member ports
up to 8 ports are selected as active based on the port priority (lower value = higher priority)
remaining ports are put into standby mode
using a negotiation protocol introduces overhead and delay in initialization
STEP #
COMMAND
COMMENTS
HARDCODE LACP PRIORITY
<S1(config)#lacp system-priority (32768, 1-65535)>
The lower the value the higher the priority (MAC is used as tie-breaker).
SELECT MEMBER PORTS
When ports are configured as member ports of an EtherChannel, a logical

port-channel interface is automatically created.
HARDCODE NEGOTIATION PROTOCOL
<S1(config-if)#channel-protocol lacp>
<S1(config-if)#channel-group (1-64) mode (passive | active)>
CONFIGURE THE GROUP
<S1(config-if)#lacp port-priority (32768, 1-65535)>
HARDCODE PORT LACP PRIORITY
mode passive willing to become an EtherChannel; not pro-active

mode active - willing to become an EtherChannel, pro-active
Up to 16 ports can be defined as member ports but only max. 8 are

selected as active based on the port priority (the lower the value the
higher the priority) (port ID is used as tie-breaker).
The ports in the standby mode replace the ones that failed.
25
NON-NEGOTIATE
does not use negotiation protocol and hardcodes the channel

STEP #
COMMAND
COMMENTS
<S1(config)#interface (*range) (type) (number)>
SELECT MEMBER PORTS
When ports are configured as member ports of an EtherChannel, a logical portchannel interface is automatically created.
*<S1(configif)#shutdown>
CONFIGURE THE GROUP
<S1(config-if)#channel-group (1-64) mode on>
LAYER 3 EtherChannel
STEP #
COMMAND
COMMENTS
<S1(config)#interface (*range) (type) (number)>
SELECT MEMBER PORTS
When ports are configured as member ports of an EtherChannel, a

logical port-channel interface is automatically created.
DISABLE SWITCHING
<S1(config-if)#no switchport>
SELECT NEGOTIATION PROTOCOL
<S1(config-if)#channel-protocol (pagp | lacp)>
CONFIGURE THE GROUP
DISABLE SWITCHING ON THE LOGICAL

CHANNEL INTERFACE
<S1(config)#interface port-channel (1-64)>
ASSIGN IP ADDRESS ON THE LOGICAL

CHANNEL INTERFACE
<S1(config-)#interface port-channel (port channel)>
<S1(config-if)#channel-group (1-64) mode (on | desirable | auto | passive | active>
If a negotiation protocol has been configured, the mode cannot be set

to on.
<S1(config-if)#ip address A.A.A.A M.M.M.M>
26
ETHERCHANNEL VERIFICATION AND TSHOOTING
show etherchannel
show etherchannel detail
show etherchannel summary
show etherchannel load-balance
show etherchannel (1-64) port-channel
show etherchannel (1-64) protocol
show (pagp | lacp) neighbor
show etherchannel (1-64) summary
show lacp sys-id
COMMAND
VERIFIES / DISPLAYS
EXAMPLE / SCREENSHOT
group state (L2 or L3)

number of member ports
negotiation protocol
show etherchannel
Detailed information about configured EtherChannels
show etherchannel detail
27
show etherchannel summary
Summarized information on existing port-channels

EtherChannel load balancing information
show etherchannel load-balance
Information on the virtual port-channel interface
show etherchannel port-channel
show etherchannel protocol
Information on the negotiation protocol used for the given group
28
Summary of LACP etherchannel
show lacp internal
Displays LACP neighbours
show lacp neighbor
show lacp sys-id
Displays LACP System ID
29
VLANs
VLANs
Trunks
DTP
VTP
Inter-VLAN Routing
Packet Forwarding Architectures

Multilayer Switching with CEF
VLANs
OVERVIEW
Virtual LANs
logical network segments
promote security sensitive traffic can be separated from the rest of the network
promote cost reduction less need for hardware upgrade and more efficient use of existing bandwidth
promote better performance by containing broadcasts to a single VLAN and avoiding broadcast storms
promote higher efficiency by making it easier to manage network
VLAN member devices do not have to be physically connected but there has to be end-to-end connectivity
VLAN membership can either be assigned statically (port-based membership) or dynamically (MAC-based membership)
no negotiation protocol is used devices automatically assume connectivity to a VLAN when they connect to a port
upon assignment to a VLAN, a port receives a Port VLAN ID (PVID) that associates it with a VLAN number
ports on a single switch can be assigned to multiple VLANs
traffic will not flow between ports associated with two different VLANs (unless L3 routing is configured)
end-to-end VLANs span the entire L2 of a network
local VLANs small percent of the traffic is local, while the majority is remote
recommended one-to-one correspondence between VLANs and IP subnets
VLANs should not extend beyond the L2 domain of the DISTRIBUTION switch (should not enter the CORE and another switch block)
VLAN ID RANGES
NORMAL RANGE
o
o
o
o
o
1 1005
1002 1005 are reserved for Token Ring and FDDI VLANs
1, 1002 1005 are created automatically and cannot be removed
stored in NVRAM
stored in vlan.dat in flash memory
EXTENDED RANGE
o
o
o
o
1006 4094
designed for ISPs
stored in running-config
not learned by VTP!
31
VLAN TYPES
DATA VLAN
o
o
DEFAULT VLAN
o
o
o
o
o
assigned to an 802.1q trunk ports

every untagged frames will be placed on native VLAN
created to maintain backwards compatibility with devices generating untagged traffic
the first switch to receive a frame strips off the native VLAN tag and forwards it out all ports
MANAGEMENT VLAN
o
o
the VLAN all switch ports become members of upon switch boot up
for CISCO switches this is VLAN 1
cannot be renamed or deleted
L2 control traffic, e.g. CDP, will always be sent on default VLAN (this behaviour cannot be changed!)
security best practice associate all switch ports with a VLAN other than VLAN 1 after switch boot up
NATIVE VLAN
o
o
o
o
configured to carry only user generated traffic

can be also referred to user VLAN
any VLAN configured to carry management traffic

e.g. HTTP, SSH, SNMP
VOICE VLAN
o
o
any VLAN configured to carry VoIP traffic

VoIP has to be separated from other traffic due to its demand for quality
32
STATIC VLANs CONFIGURATIONS

STEP #
COMMANDS
COMMENTS
SINGLE:
<S1(config)#vlan (1-1001, 1006-4094)>
CREATE A VLAN
1-1001 normal range; stored automatically in vlan.dat in flash

1006-4094 extended range; stored in runnin-config
RANGE:
<S1(config)#vlan (vlan id),(vlan id)-(vlan-id)>
*<S1(config-vlan)#name (name; up to 32 characters)>
*ADD DESCRIPTION
<S1(config-vlan)#description (description; up to 32 characters, no spaces)>
*ADD NAME
<S1(config-vlan)#name (name)>
<S1(config)#interace (interface)>
<S1(config-if)#switchport mode access>
ASSIGN PORTS
<S1(config-if)#switchport access vlan (vlan id)>
When a port is assigned to a non-existing VLAN, that VLAN is created

automatically.
A port can belong to only one VLAN at a time.
If a port with existing VLAN membership is assigned to another
VLAN, the original membership is removed.
Any ports that are not moved to an active VLAN are unable to
communicate after that VLAN is deleted.
*ADMINISTRATIVE
SHUTDOWN
<S1(config)#vlan (vlan id)>
<S1(config-vlan)#(no) shutdown>
<S1(config-vlan)#state (suspend | active)>
TSHOOT
shutdown locally shuts down VLAN and causes all ports

assigned to the given VLAN to stop transmitting data
suspend shuts down VLAN across VTP Domain and causes all
ports assigned to the given VLAN to stop transmitting data
active brings back a VLAN from the suspended state
show vlan
show vlan brief
show vlan summary
33
TRUNKS
OVERVIEW
a point-to-point link between one or more Ethernet switch interfaces and another networking device e.g. router or switch
acts as a conduit for VLANs between routers and switches
carries traffic of multiple VLANs over a single link
allows to extend a VLAN across the entire network
TRUNK ENCAPSULATION PROTOCOLS
ISL
o
o
o
o
o
o
Inter-Switch Link
CISCO proprietary
adds a 26-byte header and 4-byte trailer to the frame (30 byte overhead total) (double tagging)
a 15-bit source VLAN ID is placed in the header
the trailer contains CRC information
does not support untagged frames!
IEEE 802.1q
o
o
o
o
open standard
VLAND ID is embedded into the existing frame (single tagging)
the VLAN ID is contained in the last 12 bits of the tag (0-4095; except for 0,1,4095)
supports untagged frames but only on the native VLAN
34
TRUNK CONFIGURATIONS
The following parameters must be agreeable on both ends:
mode (unconditional, negotiated, non-negotiated)

encapsulation (ISL or 802.1Q)
native VLAN
allowed VLANs
speed
duplex mode
VTP Domain Name (but only if DTP is used to negotiate the trunk)
STEP #
COMMENTS
SELECT PORTS
HARDCODE L2 MODE
SELECT ENCAPSULATION
COMMANDS
Good practice to shut down the ports that are being

configured.
<S1(config-if)#switchport>
A switch port must be in Layer 2 mode before it can

be configured as trunk.
<S1(config-if)#switchport trunk encapsulation (isl | dot1q | negotiate)>
negotiate chooses whichever protocol is supported

on both ends (ISL is given preference)
<S1(config-if)#switchport trunk native vlan (1-4094)>
NOTE: native VLAN is used only with dot1q

encapsulation (ISL does not support untagged frames)
A native VLAN mismatch will still bring the trunk link
up, but an error message will be generated (via CDP
messages) and theres a risk that traffic will no
traverse the link correctly.
DEFINE NATIVE VLAN
Also, the error will be generated even if the

encapsulation is set to ISL in that case mismatch will
have no effect on the operation whatsoever.
<S1(config-if)#switchport trunk allowed vlan (all | none | vlan id)
SELECT VLANs THAT WILL BE

ALLOWED ON THE TRUNK
<S1(config-if)#switchport trunk allowed vlan *((add | except | remove) (vlan id))>
allowed vlan all all (1-4094) VLANs are allowed

allowed vlan add | remove adds | removes
VLANs from the current list; this should reflect
the configuration at the other end
35
<S1(config-if)#switchport mode (trunk | dynamic desirable | dynamic auto)>
SELECT TRUNK MODE
TSHOOT
mode trunk unconditional, permanent trunk

mode (if the mode is selected, DTP on the port
should be set to nonegotiate)
show interfaces (interface) trunk

show interfaces (interface) switchport
show dtp
36
DTP
OVERVIEW
Dynamic Trunking Protocol

CISCO proprietary
manages trunk negotiation between ports that support DTP
supports both ISL and 802.1q
DTP frames are generated every 30 sec.
will not form a trunk between switches in different VTP Domains!
enabled by default on CISCO switches
DTP MODES
MODE
OVERVIEW
starts as a TRUNK port

periodically sends DTP frames (advertisements) to the remote host
unconditional trunking state
COMMENTS
If this mode is used, DTP on the port should be
disabled.
TRUNK
To hardcode mode on an interface:
DYNAMIC AUTO
<S1(config-if)#switchport mode trunk>
starts as an ACCESS port

periodically sends DTP frames to the remote host
advertises that it is able to trunk
does not request remote host to go into trunking mode
DYNAMIC DESIRABLE (default)
< S1(config-if)#switchport mode dynamic auto>
starts as an ACCESS port

periodically sends DTP frames to the remote host
advertises that is able to trunk
requests remote host to go into trunking mode
<S1(config-if)#switchport mode dynamic desirable>
37
NO-NEGOTIATE
disables DTP protocol

use when connecting switches from different vendors
<S1(config-if)#switchport nonegotiate>
ACCESS
TRUNK
DYNAMIC AUTO
DYNAMIC DESIRABLE
NO-NEGOTIATE
ACCESS
ACCESS
MISMATCH
ACCESS
ACCESS
MISMATCH
TRUNK
MISMATCH
TRUNK
TRUNK
TRUNK
TRUNK
DYNAMIC AUTO
ACCESS
TRUNK
ACCESS
TRUNK
MISMATCH
DYNAMIC DESIRABLE
ACCESS
TRUNK
TRUNK
TRUNK
MISMATCH
NO-NEGOTIATE
MISMATCH
TRUNK
MISMATCH
MISMATCH
TRUNK
38
VTP
OVERVIEW
Virtual Trunking Protocol

CISCO proprietary
L2 protocol that maintains VLAN configuration consistency by managing the addition, deletion, and renaming of VLANs across multiple CISCO switches
only VLAN IDs (1-1005) are learned (extended range is not supported)
VLAN configurations are stored in VLAN database (vlan.dat)
VTP VERSIONS
VER. 1
default version
in TRANSPARENT mode, VTP Version and VTP Domain are checked before forwarding the frame to other switches using VTP
VER. 2
in TRANSPARENT mode, frame are forwarded without checking the VTP Version and VTP Domain first
consistency checks are performed before forwarding the frame
supports Token Ring switching and VLANs
supports unrecognized TLV
VER. 3
available only on platforms running the CatOS operating system

supports extended VLANs
VTP DOMAINS
network segment consisting of a single or more interconnected switches that share same VLANs information using VTP
VTP area with common VTP requirements
domains boundary is defined by a router or a L3 switch in each domain
a switch can only be a member of a single domain
switches in different VTP Domains do not share VTP information
domain name is propagated by the VTP Server and accepted by VTP enabled switches with lower revision number
39
VTP MODES
SERVER
default VTP mode

can change global / local VLAN configuration
can create, delete and rename VLANs
propagate the VLAN information to VTP CLIENT in the same domain
global VLAN information stored in flash and in NVRAM
To enable server mode:

<S1(config)#vtp mode server>
CLIENT
cannot change global / local VLAN configuration

global VLAN information stored in flash
also can cause sync problem if has a higher revision number than the current server!

<S1(config)#vtp mode client>
TRANSPARENT
only forwards VTP Advertisements to servers and clients

can only change local VLAN configuration
local VLAN information stored in NVRAM
the Revision Number is always set to 0 (zero)
in Ver. 1 VTP messages are not forwarded to switches with different VTP domain names and VTP versions
in Ver. 2 VTP messages are forwarded to other switches regardless of their VTP settings

<S1(config)#vtp mode client>
40
VTP ADVERTISEMENTS
only sent over trunk links!

VTP frame consists of header and message fields
VTP information is inserted into the data field of the Ethernet frame
Ethernet frame is then ecapsulated into ISL or 802.1q trunk frame
the destination address is a reserved multicast address (01-00-0C-CC-CC-CC)
VTP Header field always contains these fields disregard of VTP message type:
o
o
o
domain name + length

version
configuration revision number
Included information:
SUMMARY
contain global domain information

sent every 5 min. by the VTP SERVER or CLIENT to neighboring VTP enabled switches
sent immediately after a VLAN database change occurred and followed by a subset advertisement
VTP version
number of subset advertisement to follow
domain length
domain name
revision number
ID of the switch that last update the rev. #
time stamp
MD5 encryption hash code
41
Included information:
VLAN status (activated / suspended)

VLAN type (Ethernet / Token Ring)
MTU
VLAN name length
VLAN number
VLAN name
SUBSET
sent after a VLAN database change takes place

list specific changes that have been performed e.g. creating and deleting VLAN
Triggers:
REQUEST
sent to the SERVER to request any VLAN information the switch is lacking
replied with SUMMARY followed by SUBSET
VLAN database has been cleared

VTP domain name change
receipt of a SUMMARY with a higher
revision number than the local value
the switch has been reset
missed SUBSET advertisement
42
VTP REVISION NUMBER
a 32-bit index used by VTP switches to keep track of the most recent information change
revision number from the last heard VTP advertisement is recorded
the VTP advertisement process always starts with configuration revision number 0 (zero)
when changes are made on the VTP server, the revision number is incremented +1 before the advertisements are sent
when listening switches (configured as member of the same domain as the advertising switch) receive an advertisement with greater revision number than stored locally, the
advertisement overwrites any stored VLAN information
VTP revision number is stored in NVRAM and is not altered by a power cycle of the switch
to reset the revision number:
o
o
change the VTP mode to TRANSPARENT and then change it back to SERVER
change the VTP domain name to a nonexistent VTP domain and then change it back to original name
if the VTP revision number is not reset to 0 before adding it to the network, a pre-existing revision number can cause to other switches to clear their VTP database
VTP PRUNING
removes unnecessary trunk broadcast traffic on switches with no active ports for the specific VLAN
broadcast and unknown unicast frames on a VLAN are forwarded over a trunk only if the switch on the receiving end of the trunk has ports in that VLAN
when associating a switch port with a VLAN, the switch sends a special advertisement to its neighbors that it has active ports in that VLAN
pruning only needs to be enabled on the VTP Server
VLANS are pruning eligible when there are no active access ports associated with it
pruning has no effect on switches in VTP Transparent mode!
VLAN 1 is considered pruning ineligible!
disabled by default
43
VTP CONFIGURATIONS
VTP Version = 1
VTP Domain Name = null
VTP Mode = Server
Config Revision = 0
VLANs = 1
STEP #
COMMANDS
COMMENTS
<S1(config)#vtp domain name (domain name; up to 32 characters)>
If no VTP Domain Name has been configured on any switch on

the segment, switches will not multicast VTP messages (even if
they are VTP Servers).
Once a switch running in VTP Server mode has been configured
with a VTP Domain, other switches VTP Servers / Clients on the
same segment will automatically learn the Domain Name,
Revision Number and VLANs.
It then can start sending VTP messages itself.
CONFIGURE DOMAIN
DTP sends the VTP Domain Name in its packets. If two ends of
a link belong to different VTP Domains, the trunk will not form
(if DTP is used to negotiate a trunk).
The exceptions to the above:
both ends have default DTP settings (VTP Domain = null)
one end has hardcoded DTP Domain the other is left at
default (in this case, the DTP Domain is learned and
adopted)
Because a switch can only be configured with a single VTP
Domain, it will only listen and act on VTP advertisements it
hears that match its own VTP Domain Name
44
CONFIGURE MODE
<S1(config)#vtp mode (server | client | transparent)>

<S1(config)#vtp password (password; up to 32 characters; case sensitive)>
The password itself is not sent instead the MD5 hash is

computed and sent in the VTP advertisements (by SERVERS)
and then is used to validate received advertisements (by
CLIENTS).
<S1(config)#vtp version (1 | 2)>
The versions are not interoperable with the domain!
CONFIGURE PASSWORD
Switches that only support ver. 1 cannot participate in the VTP

domain along ver. 2 switches.
CONFIGURE VERSION
When the VTP Version is set to 2 on a server, all version 2

capable switches in the domain auto-configure themselves to
user ver. 2
Enable pruning on switch (VLANs 2-1001):
VLAN 1, 1002-1005 are never eligible for pruning!
<S1(config)#vtp pruning>
CONFIGURE PRUNING
For individual VLANs:

<S1(config-if)#switchport trunk pruning vlan (all | none | vlan id)
<S1(config-if)#switchport trunk pruning vlan *((add | except | remove) (vlan id))>
45
VTP VERIFICATION AND TSHOOTING
show vtp status

show vtp counters
show interface (interface) pruning
COMMAND
show vtp status
DISPLAYS / VERIFIES
EXAMPLE SCREENSHOT
VTP Version
VTP Domain
VTP Mode
VTP Revision
VTP Encryption
Various statistics associated with VTP operation
show vtp counters
VTP Pruning related information
show interface (interface) pruning
46
INTER-VLAN ROUTING
OVERVIEW
the process of switching traffic from one VLAN to another

for inter-VLAN traffic flow, a L3 device is required (a router or a L3 / Multilayer switch)
CISCO recommends implementing L3 switching at the Distribution or Core switches (to terminate local VLANs and isolate network problems)
available solutions:
DEVICE: ROUTER
OPTION 1: ONE INTERFACE PER VLAN

OPTION 2: ROUTER-ON-A-STICK
DEVICE: L3 / MULTILAYER SWITCH
OPTION 1: SVI
OPTION 2: ROUTED PORTS
47
INTER-VLAN ROUTING WITH A ROUTER

OPTION 1: ONE INTERFACE PER VLAN
a routers interface is assigned an IP address on the same subnet as a VLAN

routing is performed in software
ADVANTAGES:
o
simple configuration
DISADVANTAGES:
o
low scalability (number of supported VLANs is limited to the number of available ports on the router)
OPTION 2: ROUTER-ON-A-STICK
a trunk on a switch connects to a routers interface configured with sub-interfaces

each sub-interface has to be configured with the same encapsulation type (ISL / 802d.q)
the encapsulation has to match the type configured on the far end of the trunk
native VLAN must match on both ends of the link
match sub-interface ID with the VLAN # (as best practice)
routing performed in software
ADVANTAGES:
o
o
simple configuration
the switch does not have to support L3 (just VLANs and trunking)
DISADVANTAGES:
o
o
o
o
router is a single point of failure

if the trunk becomes congested all VLANs will affected
higher latency
added processing on the router
48
INTER-VLAN ROUTING WITH A L3 SWITCH

OPTION 1: SVI
Switched Virtual Interface

virtual routed port on an VLAN that performs routing for all packets for the associated VLAN
allow for L3 functionality for an entire VLAN
only x1 SVI per a VLAN can be created
routing performed in hardware
SVI for VLAN1 is created by default
EXAMPLE USE:
default gateway for users within VLAN

virtual router between VLANs
provides IP address for connectivity to the switch itself
can be used as an interface for routing protocols
SVI IS UP|UP WHEN:
the associated VLAN exists in the VLAN database

the associated VLAN is active
the SVI has been configured (interface vlan (1-4094))
the SVI is not administratively shutdown
at least one port is associated with the VLAN, it is UP|UP and in the STP FORWARDING state
To configure an SVI:
<S1(config)#ip routing>
<S1(config)#vlan 100>
<S1(config-vlan)#exit>
<S1(config)#interface vlan 100>
<S1(config-if#)ip address A.A.A.A M.M.M.M>
<S1(config-if)#switchport autostate exlude>
<-- exclude a switchport from the autostate calculations (the SVI will stay UP even though the associated VLAN is DOWN)
To confirm:
<S1#show interface (interface)>
49
OPTION 2: ROUTED PORTS
a L3 Switchs L2 port converted to a L3 port

sub-interfaces are not supported on routed ports
usually configured on Distribution Layer switches facing the Core Layer
do not support L2 protocols e.g. STP
L2 and L3 switching performed in hardware
To configure a L2 port:
<S1(config-if)#switchport>
<-- disables L2 switching capabilities, enables L3 routing capabilities
To configure a L3 port:
<S1(config)#ip routing>
<-- enables L3 routing capabilities, disables L2 switching capabilities
To verify:
<S1#show interface (interface) switchport>
50
PACKET FORWARDING ARCHITECTURES
Process Switching
o
Route Caching (NetFlow switching, fast switching, flow-based switching)

o
o
each packet is examined by the internal processor and is handled in software (only used in routers)
the route processor tracks the flows first packet and sets up a shortcut for the remaining packets to avoid software-based routing (immediately forwarding in hardware)
used by both routers and L3 Switches
CEF (topology based switching)

o
o
o

routing table dynamically populates a single database of the entire network topology in hardware
default option on CISCO routers and switches
51
MULTILAYER SWITCHING WITH CEF

an implementation of MLS that CISCO uses on its routers and switches that uses an advanced IP lookup and forwarding algorithm to deliver maximum L3 switching performance
less CPU-intensive that route caching (takes off the load from the routers processor)
a CEF based multilayer switch consists of two functional blocks: FIB and Adjacency Table
Layer 3 Engine builds the routing information (static routes or routing protocols) used by Layer 3 Forwarding Engine to switch packets in hardware
enabled by default on CISCO routers and 3560 switches
To enable / disable (disabling is not recommended!):

<S1(config-if)#(no) ip route-cache cef>
<S1(config-if)#(no) no ip cef>
CEF BASED MULTILAYER SWITCH COMPONENTS:
Layer 3 Engine
o
o
Routing Table
ARP Table
Layer 3 Forwarding Table

o
o
FIB
Adjacency Table
Rewrite Engine
52
FIB (Forwarding Information Base)

To view the FIB content:
<R1#show ip cef (interface | vlan (vlan id) | prefix) (longer-prefixes | detail)>
L3 information database (reformatted routing table)

an ordered list with the most specific route first for each IP subnet in the routing table
contains next-hop address for each entry
dynamic in nature (entries are update as necessary)
packets marked as CEF punt are immediately sent to L3 Engine for further processing
aCEF (Accelerated CEF) a portion of FIB is distributed across multiple L3 forwarding engines
dCEF (Distributed CEF) CEF is distributed completely among multiple L3 forwarding engines
CEF Punt examples:
(No_adj) packets with header options

expired TTL field
destined for tunnel interface
MTU is exceeded
unsupported encapsulation
ADJACENCY TABLE
To view the table content:
<R1#show adjacency (interface | vlan (vlan id)) (summary | detail)>
database that stores L2 information for every next-hop entry (called adjacency)
consists of the MAC addresses of nodes that can be reached in a single L2 hop
entries include both the IP and MAC address
adjacencies are kept for each next-hop router and the host that is directly connected
adjacencies are built from the ARP table
ADJACENY TYPE
OVERVIEW
NULL
used to switch packets destined for null interface
PUNT
used when packets must be sent to L3 for further processing
GLEAN
used when connecting to a group of hosts (prefix for the subnet)
DROP
used to switch packets that cannot be forwarded normally
DISCARD
used to switch packets discarded because of an ACL or other policy
53
REWRITE ENGINE
dedicated packet-rewrite hardware

after valid entries have been found in the FIB and Adjacencies Tables, packets header must be rewritten
the process takes place in real time
the packet undergoes the following changes before being forwarded:
o
o
o
o
o
L2 ADDR DESTINATION
L2 ADDR SRC
L3 IP TTL
L3 CHECKSUM
L2 CHECKSUM
NEXT-HOP L2 ADDR
OUTBOUND PORT L2 ADDR
DECREMANTED BY 1
RECALCULATE
RECALCULATE
54
MULTILAYER SWITCHING VERIFICATION AND TSHOOTING
show interface (interface) switchport

show interface vlan (vlan id)
show ip cef (source) detail
show adjacency (interface | vlan (vlan id)) (summary | detail)>
show cef not-cef-switched
COMMAND
VERIFIES
SCREENSHOT
L2 / L3 capabilities
operational mode
trunk encapsulation
native VLAN
allowed VLANs
pruning
show interface (interface) switchport
55
SVI related information
show interface vlan (vlan id)
Views content of FIB
show ip cef
56
Detailed information for the FIB content.
show ip cef (source) detail
Summarized information for the FIB content.
show ip cef (source) summary
57
Detailed FIB adjacency information
show adjacency (source) detail
58
Summarised FIB adjacency content information
show adjacency (source) summary
Counters for packets not switched by CEF
show cef not-cef-switched
59
SPANNING TREE
PROTOCOL
STP Overview
STP Concepts
STP Convergence
STP Topology Change
STP Configurations
STP Extensions
STP Verification and Tshooting
STP Flavours
Rapid Spanning Tree
Multiple Spanning Tree
STP OVERVIEW
Spanning Tree Protocol

ensures theres only one logical path between all destinations
all redundant paths are intentionally blocked i.e. all traffic (except for BPDUs never blocked) is prevented from entering and/or leaving the port
STP compensates for link failures by activating previously blocked ports
the SPT Algorithm decides which ports should be blocked and which ones should stay active:
o
o
o
BPDUs are exchanged

a single switch is designated as the root bridge that servers as a reference point for all STP calculations
other switches decide which ports to block and which to keep active
61
STP CONCEPTS
ROOT BRIDGE
a designated switch under the STP instance that servers as a reference point for all STP calculations
selected through an election process by exchanging BPDUs by every switch on the network
initially the root ID matches the local BID (which causes all switches to identify themselves as root bridges upon boot up, before any BPDUs are exchanged)
ideally placed in Distribution Layer i.e. in the centre of the network
the bridge advertising the lowest BID become the root bridge
DANGERS OF LETTING THE DEAFULT SETTINGS CHOOSE THE ROOT:
random location (most likely sub-optimal)

no backup root bridge
election based solely on the MAC address
BEST PRACTICE:
a primary root bridge should always be chosen in a deterministic fashion

a secondary root bridge should be chosen for redundancy purposes
To statically set a switch as the primary root bridge:

<S1(config-if)#spanning-tree vlan (vlan id) root primary>
<-- sets priority to a value lower than the one of the active root (guarantees root election)
To statically set a switch as the secondary root bridge:

<S1(config-if)#spanning-tree vlan (vlan id) root secondary>
<-- sets priority to 28672; does not guarantee that the switch becomes the new root if the primary fails
To statically hardcode switch priority (preferred option):

<S1(config)#spanning-tree priority vlan (vlan id) priority (32768, 0-65535)>
62
BPDU
Bridge Protocol Distribution Unit
STP message
sent to a well-known multicast address: 01-80-C2-00-00-00
x2 types: Configuration BPDUs and TCN (Topology Change Notification) BPDUs
contain x12 fields used to exchange path and priority information that STP uses to determine the root bridge and paths to it and to maintain stable, loop-free topology
Configuration BPDU
TCN BPDU
FIELD #
BYTES
FIELD
FUNCTION
Protocol ID
(always set to 0)
Version
(always set to 0)
Msg. Type
(Configuration or TCN)
Flags
TC (Topology Change) or TCA (Topology Change Ack.)
Root ID
Root BID (Priority (2 byte) + MAC (6 byte))
Root Cost
Cost from local port to the root bridge
BID
Sender BID (Priority (2 byte) + MAC (6 byte))
Port ID
Originating Port Identifier (Port Priority + Port Number)
Msg. Age
Time elapsed since the root sent conf. msg. on which the current msg. is based (in 256th of a sec.)
10
Max Age
The maximum time the root should be considered live and operational (in 256th of a sec.) (20, 6-40)
11
Hello Time
The time interval between successive BPDUs generated by the root (in 256th of a sec.) (2, 1-10)
12
Forward Delay
The delay that the switches should wait before transitioning to another STP state (256th of a sec.) (15, 4-30)
63
BRIDGE ID
used to determine the root bridge on the network

64 bits
when the election is performed according to the default settings root bridge placement can be unpredictable
it is recommended to hardcode appropriately low bridge priority on the desired root bridge to unsure its elected as the root
contains the following fields:
o
o
o
bridge priority
extended system ID
MAC address
BITS
NO EXTENDED ID:
16
48
BRIDGE PRIORITY
MAC ADDRESS
BITS
WITH EXTENDED ID:
FIELD
12
48
BRIDGE PRIORITY
EXTENDED SYS ID
MAC ADDRESS
OVERVIEW
COMMENTS
The lower the value the higher the priority.
can only be configured as multiples of 4096
To configure:
Method 1:
BRIDGE PRIORITY
root primary - sets bridge priority to 24576
If the priority of the active root is lower than 24576:
<S1(config-if)#spanning-tree vlan (vlan ID) root (primary | secondary)>
Method 2:
<S1(config-if)#spanning-tree vlan (vlan ID) priority (32768, 1-65536)>

To verify:
<S1#show spanning-tree>
set the local priority value to match the one of the root
(but only if local MAC is lower than the one of the root)
set the local priority the next 4096 increment below the
priority of the active root
NOTE: if the next increment is less than 4096 the switch will not
set the priority to 0 (zero) - it will have to be done manually
root secondary priority is set to 28672 (becomes the next

root bridge if the current fails and other switches are
configured with default settings)
64
EXTENDED SYS ID
an STP enhancement created to support VLANs

System ID = VLAN ID
omitted in certain STP configurations (early STP implementation didnt use VLANs)
contains the VLAN ID with which the BPDU is associated
If the switch cannot support 1024 unique MAC address of its

own use, the Ex Sys ID is enabled by default.
Otherwise, the traditional method is enabled by default.
To enable:
<S1(config)#spanning-tree extend system-id>
lower MAC address breaks the tie if switches have the same bridge priority
To view the MAC used by STP:
<S1#show spanning-tree bridge>

MAC ADDRESS
The MAC used for STP can come from the Supervisor module,
the backplane or a pool of 1024 addresses that are assigned to
every supervisor or backplane (depending on the switch model).
Because by default every bridge is configured with the same
priority value, the MAC address is the deciding factor for root
bridge election.
If election is performed according to the default settings, this
will most likely mean that the physically oldest switch on the
network becomes the root.
65
PORT COST
the default port costs are defined by the speed at which the port operates
not carried in the BPDUs (only the root path cost is)
DEFAULTS:
PORT SPEED (Mbit/s)
COST: STP (802.1D)
COST: RSTP
250
5,000,000
10
100
2,000,000
16
62
1,250,000
100
19
200,000
1,000
20,000
2,000
10,000
10,000
2,000
To configure the port cost on an interface:

<S1(config-if)#spanning-tree cost (*vlan (vlan-id)) ( 1-2000000000)>
<-- if the vlan parameter is omitted, the change will apply to every VLAN
To default port cost:

<S1(config-if)#no spanning-tree cost>
To verify:
66
ROOT PATH COST
the cumulative costs of all links leading to the root bridge

determined in the following manner:
1.
2.
3.
4.
root bridge generates a BPDU with the root path cost = 0 (zero) because all of its ports sit directly to the root
as the BPDU is received by the next-closes neighbour, it adds the path cost of its own receiving port to the root path cost
the BPDU is sent out with the updated root path cost value
as each switch receives the BPDU, the root path cost is incremented by the ingress port path cost
After incriminating the root path cost the switch locally stores the updated value when a BPDU is received on another port and the new root path cost is lower than the recorded one, the
lower value becomes the new root path cost and the root port is updated accordingly.
67
PORT ROLES
the location of the root bridge in the network topology determines how port roles are calculated
the following are the roles that switch ports are automatically configured for during the STP process:
o
o
o
o
root port
designated port
non-designated port
disabled port
ROLE
ROOT
DESIGNATED
NON-DESIGNATED
OVERVIEW
COMMENTS
x1 per switch
exists only on the non-root bridges
only one allowed per bridge
switchport with the best (lowest) root path cost
x1 per segment (i.e. per a collision domain)

exists on both root and non-root bridges
it is the port that receives and forwards the frames towards the root bridge
all ports are designated on the root bridge
if multiple switches exist on the same segment, a designated switch is elected and its corresponding switch
port begins forwarding frames for the segment
capable of populating the MAC table
exist only on non-root bridges

a port that is neither a root port nor designated port
put in a BLOCKING state
cannot forward frames
cannot populate the MAC table
When two ports complete for a role choose the

one with:
lowest BID received from a neighbour

o
o
lowest bridge priority

lowest MAC
lowest root path cost

lowest port ID received from a neighbour
o
o
lowest port priority

lowest port number
68
PORT STATES
each switch port transitions through x5 different states during the convergence process
STATE
DISABLED
OVERVIEW
COMMENTS
Possible reasons for this state:
does not participate in the STP process

does not forward frames
the port was shutdown

the port is not operational
A port will go into this state when:
The purpose of this state is for the switch to:
root bridge election is taking place

a better path to the root has been found
a port is neither root nor designated
only BPDUs are processed (all other traffic is dropped)
duration: 20 sec. (MAX AGE TIMER) OR infinite if a loop has been detected
BLOCKING
LISTENING
only root and designated ports transition into this state

only BPDUs are processed (all other traffic is dropped)
duration: 15 sec. (FORWARD DELAY TIMER)
LEARNING
root and designated ports start to process user frames (but only to populate the MAC table)
user frames are not forwarded
duration: 15 sec. (FORWARD DELAY TIMER)
FORWARDING
port is fully functional
find the root bridge

figure out what roles to assign to each port
69
BPDU TIMERS
the timers dictate how long a port will stay in a given state
the default timer values allow an adequate time for convergence in a network with a switch diameter of 7
diameter = a number of switches a frame has to traverse to travel from the two farthest points on the broadcast domain
it is recommended they are not adjusted directly because the timer values have been optimized for the 7 switch diameter
if necessary, the diameter should be adjusted and let the timers be adjusted automatically
timers should only be adjusted on the root bridge who will propagate the values in its BPDU across the network!
To configure network diameter:

<S1(config)#spanning-tree vlan 1 root primary diameter>
TIMER
OVERVIEW
HELLO
the interval at which the root bridge sends the Configuration BPDUs
the hello timer interval set on the root determines the timer for all non-root bridges since they only relay the BPDUs originated by the root
all switches use the locally defined value for transmission of the TCN BPDUs
To adjust:
<S1(config)#spanning-tree timer (*vlan (vlan-id )) hello-time (2, 1-10 sec.)>
OR
<S1(config)#spannig-tree vlan 100 root primary diameter (diameter) hello-time (2, 1-10 sec.)>
FORWARD DELAY
time spent in FORWARD + LEARNING states
To adjust:
<S1(config)#spanning-tree timer (*vlan (vlan-id )) forward-time (15, 4-30 sec.)>
MAXIMUM AGE
time spent in the BLOCKING state (while the root bridge election and port roles assignment are taking place)
controls the maximum length of time a switch port retains best Configuration BPDU
To adjust:
S1(config)#spanning-tree timer (*vlan (vlan-id )) max-age (20, 6-40 sec.)>
NOTE: if vlan parameter is omitted, the change is applied to all the VLANs
70
STP CONVERGENCE
the election of root bridge and port roles takes place simultaneously
the port roles may change multiple times before the convergence has finished
STAGE 0: IDENTIFY LINKS COSTS
SCOPE --> ALL SWITCHED TOPOLOGY

on a link-to-link basis, identify and assign STP Cost to each link
STAGE 1: ELECT THE ROOT BRIDGE
SCOPE --> ALL SWITCHED TOPOLOGY

the convergence process is triggered after the switch has finished booting OR there has been a path failure on the network
initially all ports are put into BLOCKING state to prevent loops from taking place before the STP had time to calculate root paths and assign port roles
as soon as the boot up process is finished, switches start simultaneously generating BPDUs on the network (2 sec. as per HELLO TIMER) in an attempt to become the root bridge
initially all switches assume they are the root bridge (because root ID = BID)
switches receive the BPDUs and compare the BID with the local value
the lower BID is adopted and then advertised in the BPDU as the root ID
the election process ends once the lowest BID populates the root ID field in the BPDU frames of all the switches in the network
switches continue to forward their BPDU frames advertising the root ID of the root bridge (2 sec. as per HELLO TIMER)
switches retain the BPDU information for a limited time (20 sec. as per MAX AGE TIMER) after it stopped receiving BPDUs before assuming path failure and starting new election process
Election deciding factors (lower is better): lowest BID

1.
2.
select the switch with the lowest bridge priority (default = 32768)
select the switch with the lowest MAC address
To verify the identity of the root bridge:

<S1#show spanning-tree root>
71
STAGE 2: ELECT THE ROOT PORTS
SCOPE --> EACH NON-ROOT BRIDGE

x1 per a non-root bridge
after the root bridge has been elected, the switches start to assign the roles to local ports
root port --> the port with the lowest root path cost (lowest cumulative cost to the root bridge)
the cost is calculated by summing up the costs of the outbound ports on their way to the root bridge
Election deciding factors (lower is better):

1.
2.
3.
select the port with the lowest root path cost

select the port that received a BPDU from a switch with lowest bridge ID (bridge priority + MAC)
select the port that received a BPDU from a port with lowest port ID (port priority + port number)
To verify the identity of the root ports:

STAGE 3: ELECT THE DESIGNATED PORTS
SCOPE --> EACH COLLISION DOMAIN

x1 per segment
after the root port has been elected on a switch, the remaining ports need be configured either as designated or non-designated ports
when two non-root switchports are connected to the same segment (collision domain), a competition for the designated role begins
the two switches exchange BPDUs to decide which port is designated and which one is non-designated
place the non-designated ports into BLOCKING state
Election deciding factors (lower is better):

1.
2.
3.
select the port with the lowest root path cost

select the port that generated a BPDU with lowest BiD (bridge priority + MAC)
select the port with lowest port ID (port priority + port number)
To verify the identity of the designated and non-designated ports:

72
STP TOPOLOGY CHANGE

DIRECT TOPOLOGY CHANGE
occurs when a port transitions into FORWARDING state OR when a port in FORWARDING or LEARNING state transitions into BLOCKING state
the switch sends out a TCN BPDU on its root port, which forwarded until it reaches the root bridge
TCN BPDU carries no data and only informs recipients that the change has occurred
the switch continues to send TCN BPDU every HELLO TIME interval until an ACK from its upstream neighbour is received
when the root bridge receives the TCN BPDU it then sets Topology Change flag in its Configuration BPDU, which is relayed to every other bridge in the network
all other switches shorten their TABLE AGE TIME (default = 300 sec.) timer to FORWARD DELAY value (default = 15 sec.)
this condition causes the entries in the switches MAC tables to be flushed out much sooner than they normally would but devices communicating actively during that period are kept in the
MAC table
EXAMPLE:
1.
CAT A detects a link failure on the fa1/2
2.
CAT C detects a link failure on the fa1/1
3.
CAT C removes its best BPDU it had received from the root bridge since the link is DOWN
4.
TCN BPDU is not sent by CAT C because its root port is down
5.
CAT A sends a Configuration BPDU with the TCN bit set on fa1/1 (only link that is UP)
6.
This BPDU is received and relayed to each switch along the way
7.
CAT A and B shorten their TABLE AGE TIMER to FORWAD DELAY value (300 --> 15 sec.)
8.
(the timer is shorten for the duration of (MAX AGE + FORWARD DELAY))
9.
CAT C fa1/2 becomes the root port because it received the best BPDU from the root
10. CAT C fa1/2 transitions through all STP states: LISTENING, LEARNING and FORWARDING
73
INDIRECT TOPOLOGY CHANGE
occurs when a theres no link failure but the flow of data is still compromised
e.g. a firewall is blocking the traffic
EXAMPLE:
1.
The link between CAT A and CAT C is UP | UP but theres no data flow
2.
No link failure detected so no TCN are sent
3.
After the MAX AGE timer has expired, the CAT C flushes its best BPDU
4.
The next BPDU received is on port fa1/2 (currently in the BLOCKING state)
5.
The fa1/2 port is now the root port for CAT C and transitions through all states
74
INSIGNIFICANT TOPOLOGY CHANGE
occurs when a access port link changes status
EXAMPLE:
1.
The link between CAT C and PC is treated like a regular link
2.
The state of the link will change every time the PC is booted / shut down
3.
If the link goes DOWN, CAT C sends away the TCN BPDU
4.
CAT A sends back an acknowledgement
5.
CAT A sends BPDU with TCN set on fa1/1 and fa1/2
6.
CAT B and C change their TABLE AGE TIME to FORWARD DELAY
*when a port is configured with PortFast, no TCN are sent!
75
STP CONFIGURATIONS
ITEM
NETWORK DIAMETER
COMMANDS
COMMENTS
To adjust network diameter:

<S1(config)#spanning-tree vlan 1 root primary diameter (2-7)>
To statically set a switch as the primary root bridge:

<S1(config-if)#spanning-tree vlan (vlan id) root primary>
OR
To statically set a switch as the secondary root bridge:
root primary priority is set to 24576 (if local MAC is

lower than the one of the current root)
<S1(config-if)#spanning-tree vlan (vlan id) root secondary>
the next 4096 increment below the current roots priority
BRIDGE PRIORITY
To statically hardcode switch priority (preferred option):

<S1(config)#spanning-tree priority vlan (vlan id) priority (32768, 0-65535)>
root secondary priority is set to 28672 (becomes the

next root bridge if the current fails but only if other
switches are configured with default settings)
To verify:
<S1#show spanning-tree bridge>
To enable:
<S1(config)#spanning-tree extend system-id>

EXTENDED SYS-ID
To verify:
<S1#show spanning-tree summary>
To configure the port cost on an interface:
<S1(config-if)#spanning-tree cost (*vlan (vlan-id)) (cost; 1-2000000000)>
PORT COSTS
To default port cost:

<S1(config-if)#no spanning-tree cost>
To verify:
76
PORT PRIORITY
TIMERS
To modify STP port priority:
Increments of 16
<S1(config-if)#spannin-tree port-priority (128; 0-240)>
To adjust:
o
HELLO
<S1(config)#spanning-tree timer (*vlan (vlan-id )) hello-time (2, 1-10 sec.)>

OR
<S1(config)#spannig-tree vlan 100 root primary diameter (diameter) hello-time (2, 1-10 sec.)>
To adjust:
FORWARD DELAY
<S1(config)#spanning-tree timer (*vlan (vlan-id )) forward-time (15, 4-30 sec.)>
To adjust:
MAXIMUM AGE
S1(config)#spanning-tree timer (*vlan (vlan-id )) max-age (20, 6-40 sec.)>
To enable PVRST+ mode:
<S1(config)#spanning-tree mode rapid-pvst>
PVRST+
clear spannig-tree detected protocols forces the renegotiation with adjacent switches
To re-start the protocol migration process:

<S1#clear spanning-tree detected-protocols>
77
STP EXTENSIONS
COMPARSION
GLOBAL
SCOPE
INTERFACE
VIOLATION / PURPOSE
VIOLATION / PURPOSE
BPDU is received
strip the PortFast status
place port in LISTENING state
cycle through STP states
BPDU is received
strip the PortFast status
state FORWARDING? --> do not place in LISTENING
state BLOCKING?
--> cycle through STP states
BPDU is received
place port in err-disabled state
unconditional (port does not need to be PortFast enabled)

BPDU is received
filter BPDUs sent from PortFast ports

allows a small number of initial BPDUs
unconditional (port does not need to be PortFast enabled)

filter all inbound / outbound BPDUs
BPDU is received
place port in root-inconsistent state
PortFast
all ACCESS ports
BPDUGuard
all PortFast ports
BPDUFilter
all PortFast ports
RootGuard
---
UplinkFast
SWITCH
Immediate transition of alternative root port into FORWARDING state.
---
BackboneFast
SWITCH
Find alternative path to root upon indirect failure.
---
---
LoopGuard
non-designated ports
UDLD
SWITCH
activate on all ports

only enable on non-designated ports
port stops receiving BPDUs
place port in loop-inconsitent state
activate on the port

only enable once the port became non-designated
port stops receiving BPDUs
place port in loop-inconsitent state
applies on all optic-fibre ports

keepalive ceased incoming
applies on the port

keepalive ceased incoming
78
PortFast
CISCO proprietary
enabled on ports in access mode on links on which a loop should never occur (e.g. port is connected to an end-device)
immediate transition of the port from BLOCKING into FORWARDING state (unless loop detected then keep BLOCKING)
a flapping PortFast enabled port does not generate the TCN
disabled by default
To enable PortFast on all access ports (global mode):

<S1(config)#spanning-tree portfast default>
<-- causes the ports to start forwarding traffic immediately (unless a BPDU is ever received on that port)
To enable PortFast on a per interface basis (unconditional mode):

<S1(config-if)#spanning-tree portfast>
<-- causes the port to unconditionally become a PortFast port (received BPDU will not force the port to fall back to
LISTENING or LEARNING states i.e. it will remain FORWARDING in case it had been doing so the PortFast status will
be lost and if after that port goes into BLOCKING and it will behave as per standard STP behaviour
To verify:
<S1#show spanning-tree interface (interface) portfast>
BPDU Guard
if a BPDU is received on a port with PortFast and BPDU Guard enabled, the port is put into errdisable state (shutdown with error condition only BPDUs are allowed to be received / transmitted!)
the port remains in this state (even when BPDU stop arriving) until it has been manually re-enabled
recommended to enable on all PortFast ports
not recommended to enable on uplinks where the root is located
disabled by default
To enable BPDU Guard on all PortFast enabled ports (PortFast has to be enabled):
<S1(config)#spanning-tree portfast bpduguard default>
To enable BPDU Guard on a per interface basis (does not have to be PortFast enabled):
<S1(config-if)#spanning-tree bpduguard enable>
To view err-disabled ports:
<S1#show interfaces status err-disabled>
79
BPDU Filter
CISCO proprietary
filters BPDUs on a port effectively disables STP on a port
possible use --> to define demarcation points
takes precedence over BPDUGuard (if both are enabled)
disabled by default
To enable BPDU Filter on all PortFast ports (filters OUTBOUND BPDUs on all PortFast enabled ports):
<S1(config)#spanning-tree portfast bpdu filter default>
To enable BPDU Filter on a single port (filters INBOUND / OUTBOUND BPDUs on a port; does not have to be PortFast enabled):
<S1(config-if)#spanning-tree bpdufilter (enable | disable)>
UplinkFast
CISCO proprietary
should be enabled on the ACCESS LAYER switches only! (since they are not supposed to become a transit path for any traffic)
should the root port fail, the alternate port is transitioned into FORWARDING state immediately
keeps a record of all parallel path to the root bridge and puts ports to the same destination in port groups
when the root port fails, the most favourable port in the port group (with the next-lowest root path cost; either in BLOCKING or FORWARDING states) becomes the new root port
enabled for the entire switch and all VLANs BUT cannot be enabled on the root bridge
when enabled, the bridge priority is changed to 49152 and the port cost for every port is incremented by 3000 (to ensure the switch is never elected as the root bridge OR transit to root)
upon link switchover, the switch starts sending dummy multicast packets to 0100.0ccd.cdcd, using the entries in the MAC table as the source, to let the upstream devices know that they
can be reach via the originating switch over the newly nominated root port (NOTE: no packets are sent once the primary root port restores!)
disabled by default
To enable UplinkFast:
<S1(config)#spanning-tree uplinkfast (max-update-rate (packets per sec; 150, 0-65535))>
<-- causes an alternative port to start forwarding immediately upon the root ports failure
To verify:
<S1#show spanning-tree uplinkfast>
80
BackboneFast
CISCO proprietary
when enabled, the switch actively searches for alternative path to the root bridge after an indirect link failure is discovered (a link not directly connected to the switch fails)
operates by short-circuiting the MAX AGE timer
alternative paths to the root bridge are determined according to the port types that receive an inferior BPDUs:
if the inferior BPDU arrives at a BLOCKING port, the switch considers the root port and all other BLOCKING ports to be alternative paths to the root bridge
if the inferior BPDU arrives at the root port, the switch considers all BLOCKING ports to be alternative paths to the root bridge
if the inferior BPDU arrives at the root port and no ports are BLOCKING, the switch assumes connectivity to the root has been lost and now considers itself the root (bypass MAX AGE)
RLQ (Root Link Query):
o
o
o
o
send out UDP RLQ Request

if the recipient is the root OR has lost connection to the root --> send RLQ Reply (otherwise, propagate to other switches until a RLQ Reply can be generated)
if an RLQ Reply is received on the root port --> the path to the root bridge is stable
if an RLQ Reply is received on a non-root port --> immediately expire MAX AGE + find alternative root path
if used, BackboneFast should be enabled on every switch in the STP domain because of its reliance on RLQ Request and Reply mechanisms
disabled by default
To enable BackboneFast:
<S1(config)#spanning-tree backbonefast>
To verify:
<S1#show spanning-tree backbonefast>
81
Root Guard
used to protect the current root bridge from being overthrown by another switch with a better BID
enabled on a per port basis towards ports that connect to switches that should never become the root bridge
if a better BPDU is received on a root port with Root Guard enabled, that port is put into root-inconsistent state (which basically is equal to LISTENING state)
the root-inconsistent state is maintained as long as superior BPDUs are being received
once superior BPDUs stop incoming, the port is cycled through normal STP states to return to FORWARDING state
once Root Guard is enabled on a port it is applied to all VLANs
disabled by default
To enable BackboneFast:
<S1(config-if)#spanning-tree guard root>
To verify:
<S1#show spanning-tree detail>
To view blocked ports:
<S1#show spanning-tree inconsistentports>
82
Loop Guard
CISCO proprietary
keeps track of BPDU activity on non-designated ports
as long as BPDUs are being received, the port operates normally
if BPDUs are stopped being received, the port is put into loop-inconsistent state (effectively it is BLOCKING but its non-designated state is maintained)
once BPDU are received again the switchport is recovered automatically
the corrective blocking action is taken on a per-VLAN basis
when BPDUs are being received again, the port is allowed to go through the normal STP states
can be enabled on every single port regardless of its role switch figures out which ports are non-designated
recommended to enable on all uplinks
if a port is part of an EtherChannel bundle and is deemed unidirectional, the entire bundle (port channel) is placed in err-disabled state!
disabled by default
To enable Loop Guard globally:

<S1(config)#spanning-tree loopguard default>
To enable Loop Guard on a port:
<S1(config-if)#spanning-tree guard loop>
<-- only the offending VLANs are blocked; not the port itself
To view blocked ports:

<S1#show spanning-tree inconsistentports>
83
UDLD
CISCO proprietary
helps discovering unidirectional links before the STP has had time to converge
proactively monitors the link to ensure traffic flows in both directions
a special L2 UDLD frame identifying the originating port is transmitted at regular intervals (Layer 2 PING)
an echo message from the far end is expected in return identifying the far end port
if echo is received the switch assumes the link is bidirectional
if echo is not received the switch assumes the link is unidirectional the switchport is placed into err-disabled state
a unidirectional link is detected approximately after 45 sec.
UDLD feature must be enabled on both ends to work properly
UDLD frames are sent independently off each other (timers do not have to match)
only after an echo message has been received, UDLD will block the port once further echos stopped incoming
x2 modes of operation:
o
o
NORMAL port status marked as having an undetermined state; syslog message generated; port allowed to continue its operation
AGGRESSIVE actions are taken to re-establish the link: x1 frame a second for 8 seconds are sent; if no echo is received the port is put into err-disable state
if a port is part of an EtherChannel bundle and is deemed unidirectional, only that single port is put into err-disable state not the entire bundle
does not require STP
disabled by default
To enable UDLD on all fibre optic ports:

<S1(config)#udld (enable | aggressive)>
To enable UDLD on a single port (fibre or not):
<S1(config-if)#udld port (*aggressive)>
OR
<S1(config-if)#udld (enable | aggressive)>
To adjust UDLD message parameters:

<S1(config)#udld message time (7 or 15; 7-90 sec.)
To reset all interfaces which have been shutdown by UDLD:
<S1#udld reset>
To verify:
<S1#show udld>
84
STP VERIFICATION AND TSHOOTING
show spanning-tree
show spanning-tree detail
show spanning-tree summary
show spanning-tree root
show spanning-tree bridge
show spanning-tree interface (interface)
show spanning-tree interface (interface) portfast
show spanning-tree uplinkfast
show spanning-tree backbonefast
show spanning-tree inconsistentports
show udld (interface)
debug spanning-tree switch state
COMMAND
VERIFIES
SCREENSHOT
Basic information about:
Root ID
Bridge ID
Interfaces Roles / States / Costs / Types
show spanning-tree
85
Detailed information about STP and participating ports.
Designated Port ID = received Port ID
show spanning-tree detail
Summarized information on STP.
show spanning-tree summary
Displays the current Root Bridge.
show spanning-tree root
show spanning-tree bridge
Displays local BiD info.
86
STP FLAVOURS
CST
IEEE 802.1q
Common Spanning Tree
x1 instance of STP
BPDUs are sent on the native VLAN with untagged frames
requires 802.1q encapsulation of trunks
PVST
Per VLAN Spanning Tree Protocol

CISCO proprietary version of CST
x1 instance of STP per VLAN
requires ISL encapsulation of trunks
PVST+
Per VLAN Spanning Tree Protocol +

CISCO proprietary version of CST
provides interoperability between CSP and PVSP
works over both ISL and dot1q trunks
87
RSTP
Rapid Spanning Tree Protocol

802.1w
MST
Multiple Spanning Tree

802.1s
88
RAPID SPANNING TREE
802.1w
developed to use 802.1ds concepts and make the convergence faster
can be used as the underlying mechanism with: PVST+ (--> RPVST+ (Rapid Per VLAN Spanning Tree+)) and MST
achieves its rapid nature by letting each switch interact with its neighbours through each port
requires a full-duplex point-to-point connections between switches to achieve fast convergence
proactive and for this reason RSTP does not need to use CSP delay timers
backward compatible with 802.1d (can revert to 802.1d on a per-port basis)
CISCO STP extensions are transparent and integrated into the protocol at a low lever (because of that UplinkFast and BackboneFast cannot be run with RSPT)
To enable RPVST+ mode:

<S1(config)#spanning-tree mode rapid-pvst>
To re-start the protocol migration process:
<S1#clear spanning-tree detected-protocols>
89
RSTP BPDU
uses 802.1d format for backward compatibility

#2 Version field is set to 2
the originating port identifies itself by its RSTP role and state
BPDUs are sent out every switch port as per the hello timer, regardless of whether BPDUs are received from the root bridge
when x3 BPDUs are missed in a row the neighbour is presumed to be down and all information related to the port leading to that neighbour is immediately aged out
each port attempts to operate according to the STP BPDU version that is received (MIGRATION DELAY TIMER - a mechanism that locks the STP version to avoid flapping)
#
BYTES
FIELD
Protocol ID
Version
Msg. Type
Flags
BIT #
FIELD
Root ID
TCN
Root Cost
PROPOSAL
BID
4-5
PORT ROLE
Port ID
LEARNING
Msg. Age
FORWARDING
10
Max Age
AGREEMENT
11
Hello Time
TCA
12
Forward Delay
90
RSTP LINK TYPES
the type of port determines its state

TYPE
POINT-TO-POINT
OVERVIEW
COMMENTS
connects to another switch

BPDUs are being received
full duplex ports are automatically considered point-to-point links
Half-duplex ports are considered to be on a shared medium and cannot

become a point-to-point link (traditional 802.1d must be used).
To hardcode port type:

<S1(config-if)#spanning-tree link-type point-to-point>
SHARED
connects to a shared medium e.g. a hub

BPDUs are being received
half duplex ports are automatically considered shared links
To hardcode port type:

<S1(config-if)#spanning-tree link-type shared)>
a port on an edge of the network where a single host connects

immediately placed in FORWARDING state
the moment a BPDU is received on the port, it loses its Edge Port status and generates a TCN
To hardcode port as an edge port:

EDGE
<S1(config-if)#spanning-tree portfast>
91
RSTP PORT ROLES
all ports are initially placed in DESIGNATED role

ROLE
OVERVIEW
as per 802.1d
as per 802.1d
a port that has an alternative path to the root bridge

present on non-designated switches
transitions to designated role in case the current designated path fails
DISCARDING
a backup designated port

blocked because it received a BPDU advertised by the local switch
only valid in shared LAN environment i.e. half-duplex hub
DISCARDING
COMMENTS
ROOT
DESIGNATED
ALTERNATE
BACKUP
92
RSTP PORT STATE
all ports are initially placed in DISCARDING state

RSTP defines port states only according to what the port does with incoming frames
any port can be in one of the following states
ROLE
OVERVIEW
DISCARDING
LEARNING
incoming frames are dropped

MAC addresses are learned
FORWARDING
incoming frames are forwarded

MAC addresses are learned
seen in stable topology and during topology synchronization

incoming frames are dropped
no MAC addresses are learned
combines 802.1d DISABLED, BLOCKING and LISTENING states
COMMENTS
OPERATIONAL PORT STATE
802.1D
802.1W
DISABLED
DISABLED
ENABLED
BLOCKING
ENABLED
LISTENING
ENABLED
LEARNING
LEARNING
ENABLED
FORWARDING
FORWARDING
DISCARDING
93
RSTP CONVERGENCE
convergence is achived via propagation of handshakes over point-to-point links

synchronisation ensures that no bridging loops are introduced to the topology (once proposal with better BPDU is received, all non-edge ports are moved to DESIGNATED / DISCARDING)
convergence begins with a switch sending a proposal message and the receiving switch starts sync once the proposal message has been received
if no reply has been received, the switch assumes the far end does not understand / is running CTP and cycles the ports through 802.1d states
CONVERGENCE SEQUENCE (BASED ON THE CENTRE SWITCH):
94
EXAMPLE:
INITIAL STATE:
RSTP is enabled
all switchport are disabled (shutdown)
SW3 has the best BiD
1.
SW1 fa0/1 and SW2 fa0/1 are enabled (no shutdown)
2.
Link type is negotiated:
3.
full-duplex
--> POINT-TO-POINT
Ports are put into:
ROLE
STATE
--> DESIGNATED
--> DISCARDING
4.
Send BPDU with proposal bit (0100 0000) set - advertise self as the root bridge
5.
Compare BPDUs:
6.
SW1
SW2
--> local BiD superior; ignore proposal

--> local BiD inferior; accept SW1 as the root
SW2 puts fa0/1 in:
ROLE
STATE
--> ROOT
--> DISCARDING
7.
SW2 sends out BPDU with agreement bit set (0000 0010)
8.
SW2 puts its fa0/1 in:
9.
ROLE
STATE
--> ROOT
--> FORWARDING
SW1 receives the agreement and puts its fa0/1 in:
ROLE
STATE
--> DESIGNATED
--> FORWARDING
95
10. SW1 fa1/1 and SW4 fa1/1 are enabled (no shutdown)
11. Link type is negotiated:
full-duplex
--> POINT-TO-POINT
12. Ports are put into:
ROLE
STATE
--> DESIGNATED
--> DISCARDING
13. SW2: send BPDU with proposal bit (0100 0000) set advertising SW1 as the root bridge
14. SW4 send BPDU with proposal bit (0100 0000) set advertising self as the root bridge
15. SYNC started, place all non-edge ports into:
ROLE
STATE
--> DESIGNATED
--> DISCARDING
16. Compare BPDUs:
SW2
SW4
--> SW1 BiD superior; ignore proposal

17. SW4 puts fa0/1 in:
ROLE
STATE
--> ROOT
--> DISCARDING
18. SW4 sends out BPDU with agreement bit set (0000 0010)
ROLE
STATE
--> ROOT
--> FORWARDING
20. SW2 receives the agreement and puts its fa1/1 in:
ROLE
STATE
--> DESIGNATED
--> FORWARDING
96
21. SW3 fa0/1 and SW4 fa0/1 are enabled (no shutdown)
22. Link type is negotiated:
full-duplex
--> POINT-TO-POINT
23. Ports are put into:
ROLE
STATE
--> DESIGNATED
--> DISCARDING
24. Send BPDU with proposal bit (0100 0000) set advertising self as the root bridge
25. SYNC started, place all non-edge ports into:
ROLE
STATE
--> DESIGNATED
--> DISCARDING
26. Compare BPDUs:
SW4
SW3
--> SW1 BiD superior; ignore proposal

ROLE
STATE
--> ROOT
--> DISCARDING
28. SW3 sends out BPDU with agreement bit set (0000 0010)
29. SW4 receives the agreement and puts its fa0/1 in:
ROLE
STATE
--> DESIGNATED
--> FORWARDING
ROLE
STATE
--> ROOT
--> FORWARDING
97
RSTP TOPOLOGY CHANGE
detected when a non-edge port transitions into FORWARDING state (a link failure is not a trigger!)
topology changes are detected only so that bridging tables can be updated and corrected as host appear first on a failed port and then on a different functioning port
TC (Topology Change) messages (BPDU with TC bit set) are sent out all the non-edge DESIGNATED ports (for the duration of x2 hello interval)
all MAC addresses associated with the non-edge DESIGNATED ports are flushed from the CAM table (forces the addresses to be re-learnt after the change)
all neighboring switches that receive the TC message must flush the MAC addresses learnt on all ports except the one that receives the TC message
switches forward TC on their DESIGNATED ports
98
MULTIPLE SPANNING TREE
802.1s
developed to address the surplus or lack of STP instances
allows for configuration of the exact number of STP instances needed
one or more VLANs are mapped to a single MST instance
multiple instances can be used, each supporting different set of VLANs
switches are grouped into regions (black box bridge), where very switch in a region must run MST with compatible parameters
in most cases, a single MST region is sufficient (more can be configured)
within a region, all switches must run the same instance of MST, meaning the following need to be identical:
o
o
o
if two switches have the same set of attributes, they belong to the same MST region
if two switches do not have the same set of attributes, they belong to different MST regions
MST BPDUs contain configuration attributes, which are compared by the switches:
o
o
MST Configuration Name (32 characters)

MST Revision Number (0-6553)
MST VLAN-to-instance mapping (4096)
if all attributes match, the STP instances within MST can be shared as part of the same region
if all attributes do not match, the switch is seen to be at the MST boundary (one region meets another OR region meets traditional 802.1d)
VLAN-to-instance mapping is configured on each switch and is not sent in MST BPDUs
MST BPDU contain hash computed from the instance table
IST (Internal Spanning Tree) works out a loop free topology inside a MST region and between links connecting the regions / switches running 802.1.d
IST presents the entire region as a single virtual bridge to the CST outside (BPDUs are exchanged at the region boundary only over the native VLAN of trunks)
IST = MST Instance 0
MST Instances combine with the IST at the region boundary to form a sub-tree of CST
only IST BPDUs are sent into and out of a region
MST uses RSTP as the underlying mechanism (uses RSTP port costs)
99
MST CONFIGURATIONS
CONFIGURATION
STEP #
ENABLE MST MODE
ENTER MST CONFIGURATION MODE
DISPLAY CURRENT CONFIGURATION
CONFIGURE REGION
COMMANDS
COMMENTS
<S1(config)#spanning-tree mode mst>
After MST is enabled (and configured) PVST+ operation stops

(a switch cannot run both MST and PVST+ simultaneously).
<S1(config)#spanning-tree mst configuration>
<S1(config-mst)#>
root primary priority is set to 24576 OR the next 4096

increment below the current roots priority
root secondary priority is set to 28672 (becomes the
next root bridge if the current fails and other switches
are configured with default settings)
<S1(config-mst)#show current>
Regions are identified by having the same name, revision
number and VLAN-to-instance assignments. If any of these
differs, regions fall back to RPVST+.
NAME
<S1(config-mst)#name (region name)>
Identify the MST domain.
REVISION NUMBER
<S1(config-mst)#revision (0-65535)>
Allows for tracking changes to the region (manually).
GROUP VLANs INTO INSTANCES
<S1(config-mst)#instance (0-15) vlan (vlan #)>
By default all VLANs are mapped to IST (MSTI 0).
CONFIRM CHANGES
<S1(config-mst)#show pending>
IMPLEMENT CHANGES
<S1(config-mst)#exit>
Exists MST sub-configuration mode and implements changes.
ABORT CHANGES
<S1(conifg-mst)#abort>
Exists MST sub-configuration mode and abandons changes.
100
TUNING
SET ROOT BRIDGE
<S1(config)#spanning-tree mst (instance) root (primary | secondary)>
SET BRIDGE PRIORITY
<S1(config)#spanning-tree mst (instance) priority (32768; 0-61440)
SET PORT COST
<S1(config-if)#spanning-tree mst (instance) cost (1-200000000)>
SET PORT PRIORITY
<S1(config-if)#spanning-tree mst (instance) port-priority (128; 0-240)>

<S1(config)#spanning-tree mst hello-time (2; 1-10)>
TIMERS
<S1(config)#spanning-tree mst forward-time (15; 4-30)>
Timers are not applied to specific MST instances because all

timers are defined through the IST instance and BPDUs.
<S1(config)#spanning-tree mst max-age (20; 6-40)>
101
MST VERIFICATION AND TSHOOTING
show spanning-tree mst detail

show spanning-tree mst configuration
show spanning-tree mst interface (interface)
COMMAND
VERIFIES
SCREENSHOT
Basic information about:
Root ID
Bridge ID
Interfaces Roles / States / Costs / Types
show spanning-tree mst detail
MST Region configuration:
show spanning-tree mst configuration
Name
Revision #
VLANs-to-Instance mappings
102
L2 SECURITY
Port Security
Port Based Authentication
L2 Attacks Mitigation
VLANs Security
Network Monitoring
PORT SECURITY
OVERVIEW
the port security feature on Catalyst switches allows to control port access based on MAC addresses
can only be enabled on ports explicitly set to access mode!
CONFIGURATION
STEP #
COMMAND
PUT PORT IN ACCESS MODE
ENABLE PORT SECURITY
<S1(config-if)#switchport port-security>
SET MAC LIMIT
COMMENTS
<S1(config-if)#switchport port-security maximum (1-132)>
Specifies the maximum number of MAC addresses

allowed on the port.
<S1(config-if)#switchport port-security violation (shutdown | restrict | protect)>
To recover a port from err-disable state:
SET VIOLATION POLICY
<S1(config-if)#shut>
<S1(config-if)#no shut
OR
shutdown the port is put into err-disable state

restrict port stays UP | UP, offending packets
are dropped and running count is kept, can send
a trap to SNMP or a syslog msg.
protect port stays UP | UP, offending packets
are dropped
<S1(config)#errdisable recovery cause psecure-violation>

<S1(config-if)#switchport port-security mac-address (H.H.H | sticky)>
CONFIGURE STATIC MACs
CONFIGURE MAC AGING

POLICY
<S1(config-if)#switchport port-security aging static time (0-1440 sec.) (absolute | inactivity)>
TSHOOT
If the number of static addresses configured is less

than number of allowed addresses on the port, the
remaining addresses are learned dynamically.
absolute static entries are aged out after

defined period of time
inactivity static entries are aged out if inactive
for the defined period of time
show port-security
show port-security interface (interface)
show interfaces status err-disabled
clear port-security dynamic (address (H.H.H) | interface (interface)>
104
PORT BASED AUTHENTICATION

OVERVIEW
802.1x
a combination of port security and AAA
only supported by RADIUS servers
when enabled, the switch will not pass any traffic until the user has authenticated with the switch
i.e. any services offered by the switch will not be made available to the connected device until authentication takes place
both the switch and the end users PC must support the 802.1x standard
it uses EAPOL (Extensible Authentication Protocol over LAN) a shell that stores the authentication information (the switch does not check the content just passes it to defined server)
either the switch or the client can initiate an 802.1x session
if the client is configured for 802.1x but the switch is not, the client abandons the protocol and continues to communicate normally
if the switch is configured for 802.1x but the client is not, the switchport remains in the unauthorized state that will not forward any traffic to the client
protocols allowed through the switchport before authentication takes place:
o
o
o
EAPOL
STP
CDP
105
802.1x CONFIGURATION
STEP #
COMMAND
ENABLE AAA
<S1(config)#aaa new-model>
DEFINE RADIUS SERVER
<S1(config)#radius-server host (hostname | A.A.A.A) key (string)>
ENABLE AUTHENTIACTION METHOD
<S1(config)#aaa authentication dot1x default group radius>

<S1(config)#dot1x system-auth-control>
Multiple RADIUS servers can be configured.
Once 802.1x is globally enabled on a switch, all

switchports default to the force-authorized state any
PC connected to a switchport can immediately start
accessing the network.
ENABLE 802.1X
<S1(config-if)#dot1x port-control (force-authorized | force-unauthorized | auto)>
COMMENTS
CONFIGURE PORTS
*ALLOW MULTIPLE HOSTS ON A PORT
TSHOOT
<S1(config-if)#dot1x host-most multi-host>
force-authorized port is forced to always

authorize any connected client (no
authentication necessary); useful when port
connects to a device that do not support 802.1x
force-unauthorized port is force to never
authorize any connected client
auto port uses an 802.1x exchange to move
from the unauthorized to authorized state, if
successful (requires an 802.1x capable
application on the client)
Useful when multiple hosts are connected to the

switchport through a hub or a switch.
show dot1x all

show dot1x statistics interface (interface)
106
L2 ATTACKS MITIGATION
DHCP SPOOFING
the attacker responds to DHCP Requests, listing himself as the default gateway or DNS server
MITIGATION: DHCP SNOOPING
labels switchports as trusted and untrusted

trusted ports permit all DHCP messages
untrusted ports permit only ingress DHCP Request messages
DHCP Reply (DHCPOFFER, DHCPACK, DHCPNAK) packets incoming on untrusted ports are dropped and the offending port is placed in err-disabled state
DHCP Snooping also keeps tracks of completed DHCP Bindings as clients receive legitimate replies (IP to MAC binding, lease time etc.)
by default all ports are untrusted
CONFIGURATION
STEP #
COMMAND
ENABLE DHCP SNOOPING GLOBALLY
<S1(config)#ip dhcp snooping>
ENABLE DHCP SNOOPING ON VLAN
<S1(config)#ip dhcp snooping vlan (vlan id)
ENABLE DHCP SNOOPING ON I-FACE
DEFINE DHCP REQUEST RATE
COMMENTS
<S1(config-if)#ip dhcp snooping trust>
Legitimate devise, such as DHCP Server, should be

placed behind trusted ports.
<S1(config-if)#ip dhcp snooping limit rate (1-4294967294 pps.)>
No limit by default.
<S1(config-if)#ip dhcp snooping information option>
DHCP Relay Agent Information.

When a DHCP Request is intercepted on an untrusted
port, the switch add its own MAC address and port ID
into the Option-82 field in the DHCP Request. The
DHCP Reply echos back the Option-82 information.
When switch intercepts the DHCP Reply it compares
the Option-82 to confirm that the Reply arrived on a
valid port on itself.
*OPTION-82
Enabled be default.
TSHOOT
show ip dhcp snooping

show ip dhcp snooping binding
107
ADDRESS SPOOFING
using a spoofed L2/L3 address to masquerade as another host

difficult to detect spoofed addresses once they are used inside the VLAN
can be used to disguise the origin of DoS attacks
MITIGATION: IP SOURCE GUARD
used to detect and supress address spoofing attacks

uses DHCP Snooping database or static IP bindings to dynamically create ACL on a per-port basis
if the address is something other than learned or statically configured, the packet is dropped
the feature should be used consistently on all ACCESS switches
CONFIGURATION
STEP #
ENABLE PORT-SECURITY
COMMAND
<S1(config-if)#switchport port-security>
See port security configuration.
<S1(config)#ip source binding (mac addres) vlan (vlan id) (A.A.A.A) interface (interface)>
When static inspection is used, DHCP Snooping must to

be enabled for a relevant VLAN.
The hosts MAC address is bound to specific VLAN and
IP address, and is expected to be found on a specific
interface.
<S1(config-if)#ip verify source (port-securtity)>

ENABLE SOURCE IP GUARD ON I-FACE
TSHOOT
Must be enabled to allow packet inspection!

See DHCP Snooping configuration.
STATIC IP BINDINGS
COMMENTS
ip verify source 1st check: inspect the source IP

address
port-security 2nd check: inspect the source MAC
address
show ip verify source interface (interface)

show ip source binding (A.A.A.A) (H.H.H) (dhcp snooping | static) (interface (interface)) (vlan (vlan id))
108
ARP POISONING, ARP SPOOFING
the attacker sends own, crafted ARP Reply to a broadcasted ARP Request thus wedges into the normal forwarding path
packets will be sent to attacker instead of the legitimate destination
MITIGATION: DYNAMIC ARP INSPECTION
works like DHCP Snooping

classifies ports as trusted and untrusted
all ARP packets arriving on untrusted ports undergo inspection (no inspection is performed on ARP packets arriving on trusted ports)
during the inspection the switch checks the MAC and IP addresses reported in the ARP Reply packet against known and trusted values (DHCP Snooping database, static entries)
if the ARP Reply packet contains invalid information, the packet is dropped and a log message is generated
CONFIGURATION
STEP #
ENABLE DAI
COMMAND
COMMENTS
See DHCP Snooping configuration.
<S1(config)#ip arp inspection vlan (vlan id)>
By default, all switchports associated with the VLAN

specified are considered untrusted.
<S1(config)#ip arp inspection validate (src-mac | dst-mac | ip)>
By default, only the MAC and IP addresses contained

within the ARP Reply are validated. This option
validates that the packet is really coming from the
address listed inside it.
*VALIDATE L2 HEADER
*DEFINE ARP ACL
<S1(config-if)#arp access-list (ARP ACL name)>
src-mac check the source MAC in L2 header

against sender MAC in the ARP Reply
dst-mac check the destination MAC in L2
header against destination MAC in the ARP Reply
ip check the senders IP address in all ARP
requests; check the source IP against the
destination IP in all ARP Replies
Specifies static IP to MAC mappings that are permitted.
<S1(config-if)#permit ip host (source IP) mac host (source MAC) *(log)>
109
<S1(config-if)#ip arp inspection filter (ARP ACL name) vlan (vlan id) (*static)>
*APPLY ARP ACL TO AN I-FACE
When ARP Reply packet is intercepted, its content is

checked against the ARP ACL first, the DHCP Snooping
database next.
TSHOOT
static prevents check against the DHCP

Snooping dabatase
show ip verify source (interface)

show ip source binding (A.A.A.A) (H.H.H) (dhcp snooping | static) (interface (interface)) (vlan (vlan id))
110
LAN STORM ATTACKS
the attacker floods the LAN with packets creating excessive traffic and hurting network performance
can increase the CPU utilization on a switch to 100%
MITIGATION: STORM CONTROL
allows to shutdown interfaces that generate excessive traffic

the blocked port remains shut down until the traffic drops below the failing threshold
CONFIGURATION
STEP #
COMMAND
COMMENTS
<S1(config-if)#storm-control (broadcast | multicast | unicast) level ()>
level (level-low)
bps (bps-low)
pps (pps-low)
<S1(config-if)#storm-control action (shutdown | trap)>
ENABLE STORM CONTROL
TSHOOT
level (level-low) specifies the rising and falling

suppression levels as a % of total bandwidth of the port:
level rising suppression (0.00 100.00); flooding of
storm packets is blocked when the value specified is
reached
level-low falling suppression level (0.00 100.00); by
default equals to the value of rising suppression
bps (bps-low) specifies the rising and falling
suppression levels as a rate in bits per seconds at which
traffic is received on the port.
pps (pps-low) specifies the rising and falling
suppression levels as a rate in packets per seconds at
which traffic is received
action shutdown err-disabled status
action trap the switch sends a SNMP trap when a storm
occurs
show storm-control (interface)

show storm-control history
111
SWITCH SPOOFING
a switchport is left to its default settings:

o
o
switchport mode dynamic auto

switchport trunk allowed vlan all
the port is awaiting DTP negotiation from the connected device

the attacker sends crafted DTP packets --> the link mode changes to trunk
the attackers PC masquerades as a switch
the attacker has access to any VLAN that is permitted to pass over the trunk
MITIGATION:
Explicitly set switchport mode to access:
Disable DTP:
<S1(config-if)#switchport nonegotiate>
Shutdown any used ports:
<S1(config-if)#shut>
VLAN HOPPING
the attacker crafts and sends frames with spoofed 802.1Q tags
the payload arrives on a totally different VLAN, without the use of a L3 device
the attacks is possible when:
o
o
o
the attacker is connected to an access switchport

the same switch must have an 802.1q trunk
the trunk must have the attackers access VLAN as its native VLAN
MITIGATION:
create dedicated native VLAN:

prune the native VLAN off both ends of the trunk
To force a switch to tag the native VLAN on all its 802.1q trunks:
<S1(config)#vlan dot1q tag native>
112
VLANs SECURITY
VACLs
VLAN Access Lists

capable of affecting the traffic as it traverse a VLAN
not defined by direction
like regular ACLs, they are merged into TCAM
they can permit, deny or redirect packets as they are matched
configured in a route map fashion as a VLAN access map
VACLs and RACLs can be used in combination
VACLs CONFIGURATIONS
STEP #
DEFINE ACCESS MAP
COMMANDS
COMMENTS
<S1(config)#vlan access-map (map name)>

<S1(config-access-map)#match ip address (ACL # | name)>
DEFINE MATCHING CONDITIONS
NOTE: ACLs with a log parameter are not supported!
<S1(config-access-map)#match ipx address (ACL # | name)>

<S1(config-access-map)#match mac address (ACL # | name)>
<S1(config-access-map)#action (drop | forward (capture) | redirect (interface)>
DEFINE ACTION
APPLY TO VLAN
TSHOOT
<S1(config)#vlan filter (map name) vlan-list (vlan id)>
drop matching packets are dropped

forward matching packets are allowed
redirect matching packets are redirected to
specified interface
VACLs are applied globally to one more VLANs and

not to VLAN SVI
show vlan access-map (map name)>

show vlan filter
113
PRIVATE VLANs
OVERVIEW
provide a way to segment traffic within a VLAN by creating sub-VLANs

the PRIMARY VLAN can contain a number of SECONDAY VLANs (every SECONDARY VLAN has to be associated with one PRIMARY VLAN)
a SECONDARY VLAN can function as a COMMUNITY (unlimited numbers) or ISOLATED (only x1 per PRIMARY!)
devices within the COMMUNITY VLAN can communicate with each other AND with PRIMARY VLAN
devices within the ISOLATED VLAN can only communicate with PRIMARY VLAN
SECONDARY VLAN type (community or isolated) dictates the role of the port
a switchport can be configured in following modes:
o
o
PROMISCIOUS communicates with every port within the PRIMARY and SECONDARY VLANs
HOST can communicate with only PROMISCIOUS port or ports within the COMMUNITY VLAN
if PRIVATE VLANs are to be implemented the switch has to be set to VTP TRANSPARENT mode!
114
PRIVATE VLANs CONFIGURATIONS

STEP #
SET VTP TO TRANSPARENT MODE
COMMANDS
COMMENTS
<S1(config)#vtp mode transparent)>
Private VLANs have only local significance.
<S1(config)#vlan (vlan id)
CONFIGURE SECONDARY VLANs
CONFIGURE PRIMARY VLAN
<S1(config-vlan)#private-vlan (community | isolated)>
<S1(config)#vlan (vlan id)
<S1(config-vlan)#private-vlan primary>
community devices within the community Secondary

VLAN can communicate with each other and with the
promiscuous port
isolated devices within the isolated Secondary VLAN
can only communicate with the promiscuous port
1-1001 normal range; stored automatically in vlan.dat
in flash
1006-4094 extended range; stored in runnin-config
LAYER 2
ASSOCIATE SECONDARY VLANs

WITH PRIMARY VLAN
ASSIGN PORT ROLES
ASSIGN PORTS TO SECONDARY

VLANs
MAP PROMISCIOUS PORT TO

SECONDARY VLANs
<S1(config)#vlan (primary vlan id)>

<S1(config-vlan)#private-vlan association (secondary VLAN #),(secondary VLAN#)>
<S1(config)# interface (interface)>
<S1(config-if)#switchport mode private-vlan (host | promiscuous)>
host - connects to a host that resides on an isolated or

community VLAN
promiscuous connects to a router, firewall or other
gateway and can communicate with any device on the
primary or its secondary VLANs (ignore PVLAN rules!).
<S1(config-if)#switchport private-vlan host-association (primary vlan) (secondary vlan)>
<S1(config)#interface (promiscuous port)>

<S1(config-if)#switchport private-vlan mapping (primary vlan) (allowed secondary vlan
1),(allowed secondary vlan 2)>
115
LAYER 3
ASSOCIATE SECONDARY VLAN TO

PRIMARY VLAN SVI
TSHOOT
<S1(config)#interface vlan (vlan #)>

<S1(config-if)#private-vlan mapping (pvlan id)>
Allows L3 traffic switching that originated from SECONDARY

VLANs.
Configured on Primary VLANs VLAN Interface.
show vlan private-vlan

show vlan private-vlan type
116
NETWORK MONITORING
SYSLOG
the standard for logging system events

allows a network-attached device to report and log error and notification messages either locally or to a remote syslog server
sent in plain text using UDP port 514
SYSLOG MESSAGE FORMAT:
117
SYSLOG CONFIGURATIONS
STEP #
COMMANDS
<Router(config)#logging host (hostname | A.A.A.A)>
COMMENTS
*<Router(config)#logging source-interface (interface)>
LOCATE LOGGING SERVER
SET LOGGING SEVERITY FOR THE MESSAGES SENT TO THE :

o
SERVER
<Router(config)#logging trap (lvl | keyword)>
CONSOLE
<Router(config)#logging console (lvl | keyword)>
BUFFER
<Router(config)#logging buffered (lvl | keyword)>
LVL
<Router(config)#logging monitor (lvl | keyword)>
LINES
<Router(config)#logging on>
<Router#terminal monitor>
source-interface (optional) can be useful in

situations where more than one link to the server
exists (normally, the router will use information
in the routing table to select the best path)
ENABLE LOGGING
KEYWORD
EMERGENCIES
ALERTS
CRITICAL
ERRORS
WARNINGS
NOTIFICATIONS
INFORMATIONAL
DEBUGGING
logging on - enables logging on all outputs

terminal monitor enables logging on virtual
lines
Only the console logging is enabled by default.

Logging to specific destinations can be controlled
individually.
TSHOOT
show logging
118
SNMP
the standard for network monitoring and management

x3 core elements:
o
o
o
Network Management Application (SNMP Manager)

SNMP Agents (running inside a managed device)
MID Database (inside the agent)
SNMP network management applications periodically use UDP to poll the agent residing on a managed device for useful, predetermined information
SNMP traps are sent when certain events take place
the data collected by the agent is stored in the MIB
community strings are used to provide a level authorization RO (Read Only) and RW (Read Write)
versions:
o
o
o
SNMP ver. 1 insecure

SNMP ver. 2 introduced the RW community strings, added 64 bit counter support, insecure
SNMP ver. 3 provides encryption and authentication
SNMP CONFIGURATIONS
STEP #
COMMANDS
COMMENTS
CONFIGURE SNMP ACL
<S1(config)#access-list 100 permit ip (source) (destination)>
CONFIGURE COMMUNITY STRINGS
<S1(config)#snmp-server community (string) (ro | rw) (SNMP ACL)>
CONFIGURE SNMP TRAP DESTINATION
<S1(config)#snmp-server trap (SNMP server IP)>
CONFIGURE SNMP VER. 3 USER
<S1(config)#snmp-server user (username) (group) v3>
TSHOOT
show snmp user (user)
119
IP SLA
Internet Protocol Service Level Agreement

technology that allows Cisco devices to automatically gather information about data traffic e.g.:
o
o
o
o
network latency and response time

packet loss
jitter and IP Voice quality
end-to-end network connectivity
IP SLA end-point can be either a device or an IP SLA Responder
IP SLA OPERATION:
1.
source sends an IP SLA control message with the configured operation to the responder (UDP 1967) (protocol, port, and duration)
2.
3.
4.
if MD5 is enabled, the checksum is sent with the control message

if authentication is enabled, the responder verifies it (if it fails, the responder returns an authentication failure message)
if a response is not received from the responder, it will attempt until it eventually times out
the responder sends a confirmation message back to the source router and listens on the specified port
if the response from the control message is OK, it begins sending probe packets
the responder responds to the incoming probe packets for the predetermined time
120
IP SLA CONFIGURATIONS
COMPONENTS
COMMANDS
COMMENTS
<Router(config)#ip sla (operation number 1-2147483647)>
<Router(config-ip-sla)#icmp-echo (destination IP | hostname) (*(source-interface (interface) |

(source-ip (ip address))>
<Router(config-ip-sla-echo)#frequency (1-604800 sec.)>
<Router(config-ip-sla-echo)#timeout (0-604800000 msec.)>
<Router(config-ip-sla-echo)#threshold (0-60000 msec.)>

To verify:
PROBE
<Router#show ip sla configuration>
operation number - identification number of the IP SLA

operation
icmp-echo - configures source to non-responder type of
probe
*icmp-echo source-interface - specifies the source
interface of the ICMP probes
*icmp-echo source-ip - specifies the source IP address of
the ICMP probes (when a source IP / hostname is not
configured, IP SLA chooses the IP address nearest to the
probes destination)
frequency - sets the rate at which a specified IP SLAs
operation repeat (default = 60 sec.)
timeout - sets the amount of time IP SLA operation waits
for a response from its request packet (default = 5000
msec.)
threshold - sets the rising threshold that generates a
reaction event and stores history operation for an IP SLA
operation (e.g. sends SNMP trap) (default = 5000 msec.)
The three above values have to be configured so that:

frequency > timeout > threshold
SCHEDULE
<Router(config)#ip sla schedule (probe number 1-2147483647) (life (0-2147483647 sec.) | forever))
start-time (hh:mm:ss | now | pending)>
To verify:
<Router#show ip sla configuration>

<Router(config)#track (tracked object; 1-500) ip sla (probe number 1-2147483647) reachability>
TRACKING
OBJECTS
<Router(config-track)#delay up (0-180 sec.) down (0-180 sec.)>

To verify:
ip sla schedule - schedule for the probe defined

life - number of seconds the IP SLA operation actively
collects information (default = 3600 sec.)
start-time - time when the IP SLA operation starts (the
default parameter is pending meaning no information is
collected)
reachability - tracks whether the route is reachable
*delay - specifies a period of time to delay
communicating state changes of a tracked object
up | down - time to delay the notification of an event
(regulate flapping of the tracking state)
<Router#show track>
121
RESPONDERS
<S1(config)#ip sla responder)
Enables sending and receiving IP SLAs control packets.
122
IP SLA VERIFICATION AND TSHOOTING
show ip sla statistics

show ip sla configuration
debug ip sla trace (*1-2147483647)
COMMAND
show ip sla statistics
show ip sla configuration
debug ip sla trace (*1-2147483647)
VERIFIES
operation ID
type of operation
start time
latest return code: OK | FAIL
number of successes / failures
operation TTL
type of operation
target address / source interface
schedule
threshold
statistics
EXAMPLE
Debugs IP SLA processes
123
HIGH
AVAILABILITY
Redundant Supervisory Engines
First Hop Redundancy Protocols
REDUNDANT SUPERVISORY ENGINES
only available on Catalyst 4500 / 6500 families

provides redundancy for the switchs supervisory engine
accomplished by having redundant hardware in place within a switch chassis
the first supervisor module to successfully boot becomes the ACTIVE supervisor for the chassis
the second supervisor module to boot remains in STANDBY role, waiting for the active supervisor to fail
the STANDBY supervisor is allowed to boot up and initialize only up to a certain level (any remaining functions will be initialized only when the supervisor is ready to become active)
available redundancy modes:
o
o
o
RPR
RPR+
SSO
125
RPR
Route Processor Redundancy

redundant supervisor is only partially booted and initialized
upon failover, the STANDBY supervisor module must reload every other module in the switch and then load the remainder of supervisory functions
all dynamic routing information is lost upon failover (ACTIVE and STANDBY supervisors do not synchronize routing information)
FAILOVER TIME 2 4 min. (C6500) | < 60 sec. (C4500)
RPR+
Route Processor Redundancy +

redundant supervisor is booted, allowing the supervisor and route engine to initialize
no L2 or L3 functions are started
upon failover, the STANDBY supervisor finished initializing without reloading other switch modules (switch ports will retain their states)
FAILOVER TIME 30 60 sec.
SSO
Stateful Switchover
redundant supervisor is fully booted and initialized
startup and running configurations, ACLs, L2 + L3 tables are synced between the ACTIVE and STANDBY modules
L2 information and switch ports states are maintained on both supervisors (hardware switching is not affected during failover)
FAILOVER TIME 0 - 3 sec. (C6500) | < 1 sec. (C4500)
REDUNDANCY MODES CONFIGURATIONS

STEP #
ENABLE REDUNDANCY
SELECT REDUNDANCY MODE
TSHOOT
COMMANDS
COMMENTS
<Router(config)#redundancy>
Command needs to be issued on both modules.

Once enabled, all configuration changes only
needs to be entered on the ACTIVE supervisor
(the runningconfig is automatically synced).
<Router(config-red)#mode (rpr | rpr-plus | sso)>
When enabling RPR+, and the peer only supports

RPR, the supervisor automatically fall backs to
RPR.
show redundancy states
126
NSF
Non Stop Forwarding

CISCO proprietary
designed to optimize L3 reconvergence after a failover
focuses on quickly rebuilding the RIB (Routing Information Base) after the switchover
RIB is used to generate the FIB table for CEF, which is downloaded to any switch modules / hardware that can perform CEF
NSF must be supported and enabled on both the router that might need assistance and the routers that will provide assistance
supported by:
o
o
o
o
BGP
OSPF
EIGRP
IS-IS
NSF CONFIGURATIONS
PROTOCOL
BGP
EIGRP
OSFP
COMMANDS
COMMENTS
<Router(config-router)#router bgp (AS number)>

<Router(config-router)#bgp graceful-restart>
<Router(config-router)#router eigrp (AS number)>
<Router(config-router)#nsf>
<Router(config-router)#router ospf (process ID)>
<Router(config-router)#nsf)>
<Router(config-router)#router isis (tag)>
<Router(config-router)#nsf (cisco | ietf)>
IS-IS
<Router(config-router)#nsf interval (minutes)>

<Router(config-router)#nsf t3 (manual (sec.) | adjacency)>
<Router(config-router)#nsf interface wait (sec.)>
127
FIRST HOP REDUNDANCY PROTOCOLS

PROTOCOLS COMPARISON
NOTE: if multiple protocols are run on an interface, the same vIP can only be used once i.e. used by only one FHRP protocol
HSRP
VRRP
GLBP
STANDARD
CISCO
RFC 3768
CISCO
MULTICAST
224.0.0.2
224.0.0.18
224.0.0.102
TRANSPORT
UDP 1985
IP 112
UDP 3222
vIP
0000.0c07.acxx
0000.5e00.01xx
0007.b4xx.xxyy
LOAD BALANCING
NO
NO
YES
IPv6
YES
NO
YES
GROUP
0-255
1-255
0-1023
PRIORITY
100 (0-255)
100 (1-254)
100 (1-255)
HELLO
3 (1-254)
1 (1-255)
3 (1-254)
PREEMPT
YES (DISABLED)
YES (ENABLED)
YES (DISABLED)
TRACKING
YES (INTERFACE)
YES (IP SLA)
YES (IP SLA, IP ROUTING)
ROLES
128
HSRP
OVERVIEW
Hot Standby Routing Protocol

CISCO proprietary
a single vIP and vMAC per a HSRP group (2+ routers)
HELLOs are sent to:
o
o
ver 1: 224.0.0.2, UDP 1985

ver 2: 224.0.0.102, UDP 2029
x1 ACTIVE, x1 STANDBY and remainder in the LISTEN state (referred to as PASSIVE)

only the ACTIVE router process the traffic sent on the vIP
can only be configured on L3 interfaces (SVI, routed interfaces, and Etherchannels)!
VIRTUAL MAC ADDRESS
ver. 1
ver. 2
CISCO VENDOR ID
HSRP ID
x - STANDBY GROUP #
0000.0C
07.AC
xx
CISCO VENDOR ID
HSRP ID
x - STANDBY GROUP #
0000.0C
9F.FX
xx
129
HSRP STATES
INITIAL
HSRP has not been enabled (state is entered through a configuration change OR when an interface first becomes available)
LEARN
Awaiting HELLOs from the ACTIVE router (the vIP has not yet been configured and no HELLO has been received from the ACTIVE router)
LISTEN
Neither ACTIVE nor STANDBY (monitors HELLOs from those routers)
SPEAK
Active participation in the ACTIVE / STANDBY router election (note: to enter this state, a router has to have a vIP configured)
STANDBY
ACTIVE
First candidate to become an ACTIVE router (x1 per HSRP Group)

Responds to traffic sent on the vIP (x1 per HSRP Group) (once elected, it broadcasts vIP:vMAC and mulitcasts HELLOs with own IP:vMAC)
130
HSRP CONFIGURATIONS
STEP #
COMMANDS
COMMENTS
ACTIVIATION
VERSION
<Router(config-if)#standby version (1 | 2)>
Up to 255 and 4095 group members respectively.
<Router(config-if)#standby (group number; 0-255) name (group name; 25 char max., no spaces)>
group number has to be the same for an

HSRP Group but is only locally significant on an
interface (can be the same for different VLANs)
HSRP routers with the same group number share the

vMAC thats why the group number needs to be
the same on every HSRP node for a given vIP.
NAME
Otherwise, vIP will be associated with two different

vMACs causing connectivity issues.
<Router(config-if)#standby (group number) priority (100, 0-255)>
priority the router with the highest priority

becomes the ACTIVE router for the group
The group number must be unique on a segment for

each vIP.
GROUP PRIORITY
If all routers share the same priority, then the one

with highest IP address on the HSRP interface
becomes the ACTIVE.
vIP
<Router(config-if)#standby (group number) ip (A.A.A.A)>
Clients should point to this virtual address as their

default gateway.
131
TUNING
<Router(config-if)#standby (group number) preempt (*delay (minimum (0-3600 sec.)) (reload (0-3600 sec.)))>
When configured, a router with highest priority can

assume the ACTIVE role at any time (normally, it has
to wait for the current ACTIVE router to fail).
PREEMPTION
<Router(config-if)#standby (group number) track (interface) (priority decrement; 10, 1-255)>
TRACKING
minimum forces the router to wait for a

configured period before attempting to
overthrow the active router with lower priority;
this delay beings as soon as the router is
capable of assuming the active role
reload forces the router to wait after it has
been reloaded or restarted
track when tracked interface goes DOWN,
the group priority is decremented by the
configured value
Adds the following entry to the running-config:

track 1 interface (interface) line-protocol
<Router(config-if)#standby (group number) timers (hello; 3, 1-254 sec.) (hold; 10, 1-254 sec.)>
<Router(config-if)#standby (group number) timers msec (hello 15-999 msec.) msec (hold 50-3000 msec.)>
TIMERS
HSRP Routers configure their timers according to the

values advertised by the ACTIVE router. Based on
them, the STANDBY router monitors the ACTIVE
router and the LISTEN routers monitor the STANDBY
router.
If x3 HELLOs are missed OR the HOLD timer expires:
STANDBY ACTIVE
LISTEN STANDBY
132
AUTHENTICATION
o
PLAIN-TEXT
<Router(config-if)#standby (group) authentication (string)>

<Router(config-if)#standby (group) authentication md5 key-string (0 | 7) (string; 64 characters)>
OR
MD5
<Router(config)#key chain (chain name)
If the key string in a message matches the key

configured on an HSRP peer, the message is
accepted.
If the group is omitted, the password is applied to all
the standby groups on that interface.
<Router(config-keychain)# key (key number; 0-2147483647)>

<Router(config-keychain-key)#key-string (0 | 7) (string)>
<Router(config-if)#standby group authentication md5 key-chain (chain name)>
EXAMPLE:
LOAD BALACING
CatalystA(conifg)#interface vlan50
CatalystA(config-if)#ip addresss 192.168.1.0 255.255.255.0
CatalystA(conifg-if)#standby 1 priority 200
CatalystA(conifg-if)#standby 1 preempt
CatalystA(conifg-if)#standby 1 ip 192.168.1.1
CatalystA(conifg-if)#standby 1 authentication cisco123
CatalystA(conifg-if)#standby 2 priority 100
CatalystA(conifg-if)#standby 2 ip 192.168.1.2
CatalystA(conifg-if)#standby 2 authentication cisco123
CatalystB(config)#interface vlan50
CatalystB(config-if)#ip addresss 192.168.1.0 255.255.255.0
CatalystB(config-if)#standby 1 priority 100
CatalystB(config-if)#standby 1 ip 192.168.1.1
CatalystB(config-if)#standby 1 authentication cisco123
CatalystB(config-if)#standby 2 priority 200
CatalystB(config-if)#standby 2 preempt
CatalystB(config-if)#standby 2 ip 192.168.1.2
CatalystB(config-if)#standby 2 authentication cisco123
133
HSRP VERIFICATION AND TSHOOTING
show standby
show standby brief
show standby neighbors
debug standby (errors | events | packets)
COMMAND
VERIFIES
SCREENSHOT
HSRP Group settings

ACTIVE STANDBY routers
vIP / vMAC
show standby
Summarized HSRP configurations
show standby brief
HSRP Neighbours relate info
show standby neighbors
debug standby (errors | events | packets)
Debugs events associated with HSRP
134
VRRP
OVERVIEW
Virtual Router Redundancy Protocol

RFC 2338
a single vIP and vMAC per a VRRP group
HELLOs are sent on 224.0.0.18, IP 112
x1 MASTER, remainder in the BACKUP
MASTER can share and use its actual interface IP address as the vIP
VIRTUAL MAC ADDRESS
VENDOR ID
VRRP ID
x - VRID
0000
5E00
01xx
VRRP STATES
INITIALIZE
Awaiting a start-up event
BACKUP
Monitoring of the availability and state of the MASTER router
MASTER
Responds to traffic sent on vIP (once elected, it: broadcasts gratuitous ARP with vMAC:vIP and multicasts HELLOs with vMAC:own IP
135
VRRP CONFIGURATIONS
STEP #
COMMANDS
COMMENTS
ACTIVATION
DESCRIPTION
<Router(config-if)#vrrp (group number; 1-254) description (group name; 80 char max.)>

<Router(config-if)#vrrp (group number) priority (100, 1-254)>
GROUP PRIORITY
*NOTE: when the current Master fails, it advertises priority = 0 forcing the election process
If all routers share the same priority, then the one

with highest IP address on the VRRP interface
becomes the active.
<Router(config-if)#vrrp (group number) ip (ip address)>
priority the router with the highest priority

becomes the master router for the group
Clients should point to this virtual address as their

default gateway.
vIP
MAC: 0000.5e00.01xx (group number)

TUNING
PREEMPTION
TRACKING
<Router(config-if)#vrrp (group number) preempt (delay minimum (0-3600 sec.))>

<Router(config-if)#standby (group number) track (object; 1-500) decrement (priority decrement; 1-255)>
<Router(config)#track (object; 1-500) interface (interface) (line-protocol | ip routing)>
<Router(config-if)#vrrp (group number) timers advertise (msec (hello; 50-999)) (hello; 1-255)>
TIMERS
Enabled by default
<Router(config-if)#vrrp (group number) timers learn>

*issues with learning msec!
advertise advertise timers to the BACKUP

learn learn timers from the MASTER
Down interval = 3 * HELLO + SKEW

SKEW = (256 local priority) / 256
136
AUTHENTICATION
o
PLAIN-TEXT
<Router(config-if)#vrrp (group number) authentication (string)>

<Router(config-if)#vrrp (group name) authentication md5 key-string (0 | 7) (string; 64 char.)>
OR
MD5
<Router(config)#key chain (chain name)


configured on a VRRP peer, the message is
accepted.
If the group is omitted, the password is applied
to all the standby groups on that interface.
<Router(config-if)#vrrp (group name) authentication md5 key-chain (chain name)>
137
VRRP VERIFICATION AND TSHOOTING
show vrrp (all | interface (interface))

show vrrp brief
debug vrrp (all | events | packets | state)
COMMAND
show vrrp
show vrrp brief
debug vrrp (all | events | packets | state)
VERIFIES
SCREENSHOT
Debugs events associated with VRRP
138
GLBP
OVERVIEW
Gateway Load Balancing Protocol

CISCO proprietary
traffic load balancing over up to four gateways
a single vIP and multiple vMAC addresses are used
HELLOs are sent to 224.0.0.102; UDP 3222
can only be configured on L3 interfaces (SVI, routed interfaces, and Etherchannels)!
AVG Active Virtual Gateway
o
o
o
o
o
the router in the group with the highest configured priority OR highest IP address
manages the load balancing and responds to ARPs send on the vIP
assigns vMAC addresses to itself and AVFs
listens to all ARP request on a given subnet and responds with a vMAC using one of the load balancing algorithms
also functions as an AVF
AVF Active Virtual Forwarders

o
a router participating in the GLBP group that was assigned this role by the AVG
VIRTUAL MAC ADDRESS
CISCO VENDOR ID
GLBP ID
AVF#
0007
B4xx
xxyy
*xxxx 6 zero bits followed by a 10 bit GLBP group number

*yy 8 bit AVF number
LOAD BALANCING ALGORITHMS
weighted based on the preconfigured value of weighting (the gateways forwarding capacity the higher the value the more frequent ARP replies)
host-dependant each host always uses the same specific AVF
round robin each vMAC is used to respond in turn
139
GLBP STATES
AVG
DISABLED
Indicates that the vIP address has not been configured or learned yet, but other GLBP configuration exists.
INITIAL
The vIP address has been configured or learned, but virtual gateway configuration is not complete (vIP has not been configured / check IP routing on the interface)
LISTEN
Virtual gateway is receiving HELLOs packets and is ready to change to the SPEAK state (if the ACTIVE or STANDBY AVG becomes unavailable)
SPEAK
Virtual gateway is attempting to become the ACTIVE or STANDBY AVG
STANDBY
ACTIVE
Indicates that the gateway is next in line to be the ACTIVE AVG

Indicates that this gateway is the AVG (is responsible for responding to ARP Requests for the vIP)
AVF
DISABLED
Indicates that the vMAC has not been assigned or learned (this is a transitory state because a virtual forwarder changing to a DISABLED state is deleted)
INITIAL
The vIP address has been configured or learned, but virtual gateway configuration is not complete (vIP has not been configured / check IP routing on the interface)
LISTEN
Virtual forwarder is receiving HELLOs and is ready to change to the ACTIVE state if the current ACTIVE AVF becomes unavailable.
ACTIVE
Indicates that this gateway is the AVF (is responsible for forwarding packets sent to the virtual forwarder MAC)
140
GLBP CONFIGURATIONS
ACTIVIATION
STEP #
COMMANDS
*NAME
<Router(config-if)#glbp (group number; 0-1023) name (group name)>
PRIORITY
<Router(config-if)#glbp (group number) priority (100, 1-255)>
VIRTUAL IP
<Router(config-if)#glbp (group number) ip (A.A.A.A)>
COMMENTS
Determines what router will become the AVG for

the group.
One virtual IP per VLAN.
Needs to be explicitly configured only on AVG.
TUNING
PREEMPT
<Router(config-if)#glbp (group number) preempt (delay minimum ((30, 0-3600 sec.))>
LOAD-BALANCING
<Router(config-if)#glbp (group number) load-balancing (round-robin | host-dependent | weighted)>

Determines what routers will become the AVFs
for the group.
WEIGHTINING
<Router(config-if)#glbp (group number) weighting (100, 1-254) (lower (1-99) upper (1-100))>
If the value drops below the lower threshold or

goes beyond the upper one, the AVF can / cannot
function as an AVF.
If weighted load balancing is used, this value will
determine the frequency of ARP Replies for a
given AVF.
TRACKING
<Router(config-if)#glbp (group number) weighting track (tracked object; 1-500) decrement (1-255)>
<Router(config)#track (object; 1-500) interface (interface) (line-protocol | ip routing)>
<Router(config-if)#standby (group number) timers (hello; 3, 1-254 sec.) (hold; 10, 1-254 sec.)>
TIMERS
<Router(config-if)#standby (group number) timers msec (hello; 15-999 msec.) msec (hold; 50-3000 msec.)>
ip routing interface routing capabilities

(routing enabled, IP address present,
interface is UP)
The AVG will advertise its timer values to the

AVFs.
<Router(config-if)#standby (group number) timers redirect (600, 0-3600 sec.) (timeout; 14400, 622-64600 sec.)>
141
AUTHENTICATION
o
PLAIN-TEXT
<Router(config-if)# glbp (group number) authentication (string)>

<Router(config-if)# glbp (group number) authentication md5 key-string (0 | 7) (string; 64 characters)>
OR
MD5
<Router(config)#key chain (chain name)>

configured on an HSRP peer, the message is
accepted.
If the group is omitted, the password is applied
to all the standby groups on that interface.

<Router(config-if)# glbp (group number) authentication md5 key-chain (chain name)>
142
GLBP VERIFICATION AND TSHOOTING
show glbp (*interface)

show glbp brief
show glbp (active | init | listen | standby| disabled)
debug glbp (errors | events | packets | terse)
COMMAND
VERIFIES
SCREENSHOT
show glbp
143
show glbp brief
debug glbp
Debugs events associated with GLBP
144
APPENDIXES
IPv4 Subnetting
RIP
EIGRP
OSPF
IS-IS
BGP
NAT
IPSec
IPv6
EtherChannel considerations
By stretch | Monday, January 18, 2010 at 4:04 a.m. UTC
EtherChannel is Cisco's term for bundling two or more physical Ethernet links for the purposes of aggregating available bandwidth
and, to a lesser extent, providing a measure of physical redundancy. Under normal conditions, all but one redundant physical link
between two switches will be disabled by STP at one end.
With EtherChannel configured, multiple links are grouped into a port-channel, which is assigned its own configurable virtual
interface. The bundle is treated as a single link.
EtherChannel Negotiation
An EtherChannel can be established using one of three mechanisms:
PAgP - Cisco's proprietary negotiation protocol
LACP (IEEE 802.3ad) - Standards-based negotiation protocol
Static Persistence ("On") - No negotiation protocol is used
Any of these three mechanisms will suffice for most scenarios, however the choice does deserve some consideration. PAgP, while
perfectly able, should probably be disqualified as a legacy proprietary protocol unless you have a specific need for it (such as
ancient hardware). That leaves LACP and "on", both of which have a specific benefit.
LACP helps protect against switching loops caused by misconfiguration; when enabled, an EtherChannel will only be formed after
successful negotiation between its two ends. However, this negotiation introduces an overhead and delay in initialization. Statically
configuring an EtherChannel ("on") imposes no delay yet can cause serious problems if not properly configured at both ends.
To configure an EtherChannel using LACP negotiation, each side must be set to either active or passive; only interfaces
configured in active mode will attempt to negotiate an EtherChannel. Passive interfaces merely respond to LACP requests. PAgP
behaves the same, but its two modes are refered to as desirable and auto.
Only a single line is needed to configure a group of ports as an EtherChannel:

S1(config)# interface range f0/13 -15
S1(config-if-range)# channel-group 1 mode ?
active
Enable LACP unconditionally
auto
Enable PAgP only if a PAgP device is detected
http://packetlife.net/blog/2010/jan/18/etherchannel-considerations/
Page 1
desirable
on
passive
Enable PAgP unconditionally

Enable Etherchannel only
Enable LACP only if a LACP device is detected
S1(config-if-range)# channel-group 1 mode active

Creating a port-channel interface Port-channel 1
As noted, a virtual port-channel interface Port-channel1 has been created to represent the logical link. Switchport configurations
applied to this interface are replicated to the physical member interfaces. We can inspect the health of the EtherChannel with the
show etherchannel summary command:
S1# show etherchannel summary
Flags: D - down
P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3
S - Layer2
U - in use
f - failed to allocate aggregator
M - not in
u w d -
use, minimum links not met

unsuitable for bundling
waiting to be aggregated
default port
Number of channel-groups in use: 1

Number of aggregators:
1
Group Port-channel Protocol
Ports
------+-------------+-----------+----------------------------------------------1
Po1(SD)
LACP
Fa0/13(D)
Fa0/14(D)
Fa0/15(D)
The opposite side of the LACP EtherChannel will typically be configured as passive, however it can be active as well.
S2(config-if-range)# channel-group 1 mode passive
When the member ports on both sides of the EtherChannel are enabled, the port-channel interface also transitions to the up state.
However, note the timing of the system messages:
*Mar
*Mar
*Mar
*Mar
1
1
1
1
00:45:50.647:
00:45:50.683:
00:45:50.691:
00:45:53.487:
%LINK-3-UPDOWN:
%LINK-3-UPDOWN:
%LINK-3-UPDOWN:
%LINK-3-UPDOWN:
Interface
Interface
Interface
Interface
FastEthernet0/14, changed state

Port-channel1, changed state to
to up
to up
to up
up
Almost a full three seconds elapsed between the member ports transitioning to the up state and the port-channel interface coming
up. Once it did, we can see the state of the EtherChannel has changed to "in use":
S1# show etherchannel summary
Flags: D - down
P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3
S - Layer2
U - in use
f - failed to allocate aggregator
M - not in use, minimum links not met
u - unsuitable for bundling
Page 2
w - waiting to be aggregated
d - default port
Number of channel-groups in use: 1
Number of aggregators:
1
Group Port-channel Protocol
Ports
------+-------------+-----------+----------------------------------------------1
Po1(SU)
LACP
Fa0/13(P)
Fa0/14(P)
Fa0/15(P)
Note the S indicating layer two operation; on multilayer platforms, EtherChannel interfaces can be configured for routed operation
as well.
For comparison, let's reconfigure the EtherChannel to function without a negtiation protocol ("on" mode):
S1(config)# no interface po1
S1(config)# interface range f0/13 -15
S1(config-if-range)# channel-group 1 mode on
S1(config-if-range)# no shutdown
This time we observe that the port-channel interface is enabled as soon as its first member port comes up, as there is no delay
imposed by negotiation:
*Mar
*Mar
*Mar
*Mar
1
1
1
1
00:56:12.271:
00:56:12.287:
00:56:12.291:
00:56:12.307:
%LINK-3-UPDOWN:
%LINK-3-UPDOWN:
%LINK-3-UPDOWN:
%LINK-3-UPDOWN:
Interface
Interface
Interface
Interface

Port-channel1, changed state to
to up
up
to up
to up
In the Campus Network High Availability Design Guide, Cisco recommend forgoing the use of a negotiation protocol and
configuring EtherChannels for static "on/on" operation; however they also caution that this approach offers no protection against
the effect of misconfigurations.
EtherChannel Load-Balancing
Another consideration to make when implementing EtherChannels is the type of load-balancing in effect. EtherChannel provides
load-balancing only per frame, not per bit. A switch decides which member link a frame will traverse by the outcome of a hash
function performed against one or more fields of each frame. Which fields are considered is dependent on the switch platform and
configuration. For example, a Catalyst 3550 can match only against a frame's destination or source MAC address:
S1(config)# port-channel load-balance ?
dst-mac Dst Mac Addr
src-mac Src Mac Addr
The show etherchannel load-balance command reveals that source MAC address load-balancing is default on the
Catalyst 3550:
S1# show etherchannel load-balance
EtherChannel Load-Balancing Configuration:
src-mac
EtherChannel Load-Balancing Addresses Used Per-Protocol:
Non-IP: Source MAC address
IPv4: Source MAC address
Page 3
More powerful platforms can match against IP address(es) or layer four port(s). Generally speaking, higher layer fields are more
favorable as they tend to be more dynamic, resulting in a more granular distribution of traffic across member links.
Direction of flow is also an important detail. For example, consider the following topology:
Routed packets entering the subnet from S1 are always sourced from the MAC address of the VLAN interface. If source MAC
load-balancing is in use, these frames will be forwarded down only one member link, because the outcome of the hash function will
always be the same. Configuring destination MAC load-balancing on S1 is recommended to achieve a more varied distribution of
frames and make better use of the available bandwidth.
The opposite is true on S2: Since all frames entering the EtherChannel from LAN hosts are destined for the MAC address of the
gateway (VLAN interface), source MAC address load-balancing works better here.
EtherChannel Bandwidth and Costs

Finally, remember that the perceived bandwidth of a port-channel interface is equal to the sum of its active member links. For
example, an EtherChannel with three active 100 Mbps members will show a bandwidth of 300 Mbps. Because members can still
fail individually, the bandwidth of a port-channel interface can fluctuate without going down.
For more information on EtherChannel bandwidth and spanning tree considerations, see Etherchannel costs and failover.
Posted in Switching
Page 4
Etherchannel costs and failover

By stretch | Thursday, December 10, 2009 at 5:12 a.m. UTC
IOS Etherchannel allows multiple physical links to be bonded via a single virtual interface so that their bandwidth is aggregated and
each link bears a (roughly) equal share of the traffic load. However, extra consideration should be paid when designing
Etherchannel links, as member links can fail, decreasing the aggregate link bandwidth without taking down the link.
Layer Two
In the above topology, three Etherchannels have been configured between the three switches, each composed of three 100 Mbps
member links. S1 is the spanning tree root. The Etherchannels were deployed with two design goals in mind:
Support up to 200 Mbps of traffic between any two switches.
Provide n + 1 redundancy (the Etherchannel will remain up with a single failed link).
We can see that each Etherchannel, having an aggregate bandwidth of 300 Mbps, is assigned a spanning tree cost of 9:
S1# show spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol rstp
Root ID
Priority
1
Address
0013.c412.0f00
This bridge is the root
Hello Time
2 sec Max Age 20 sec
Bridge ID
Forward Delay 15 sec
Priority
1
(priority 0 sys-id-ext 1)
Address
0013.c412.0f00
Hello Time
2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface
------------------Fa0/1
Fa0/3
Fa0/5
Fa0/9
Fa0/19
Fa0/20
Fa0/21
Po13
Role
---Desg
Desg
Desg
Desg
Desg
Desg
Desg
Desg
Sts
--FWD
FWD
FWD
FWD
FWD
FWD
FWD
FWD
Cost
--------19
19
19
19
19
19
19
9
Prio.Nbr
-------128.1
128.3
128.5
128.9
128.19
128.20
128.21
128.65
Type
-------------------------------P2p
P2p
P2p
P2p
P2p Peer(STP)
P2p Peer(STP)
P2p Peer(STP)
P2p
http://packetlife.net/blog/2009/dec/10/etherchannel-costs-and-failover/
Page 1
Po12
Desg FWD 9
128.66
P2p
What happens if one of the member links between S1 and S2 fails? The aggregate bandwidth of the Etherchannel is recalculated
as 200 Mbps, and the STP cost rises from 9 to 12:
...
Interface
Role Sts Cost
------------------- ---- --- --------...
Po23
Altn BLK 9
Po12
Root FWD 12
Prio.Nbr Type
-------- -------------------------------128.65
128.66
P2p
P2p
Our spanning topology remains unchanged: although the cost of S2's direct path to root has been raised from 9 to 12, 12 is still
lower than the aggregate cost to root (via S3) of 18 (9 + 9).
However, if a second link in the Etherchannel fails, leaving only a single 100 Mbps member link, its bandwidth is further reduced to
100 Mbps and its cost raised to 19. At this point, the alternate path to root via S3 has a lower cost. The spanning tree topology
reconverges to reflect this:
...
Interface
Role Sts Cost
------------------- ---- --- --------...
Po23
Root FWD 9
Po12
Altn BLK 19
Prio.Nbr Type
-------- -------------------------------128.65
128.66
P2p
P2p
Layer Three
Port-channel interfaces can operate as routed interfaces with IP addresses. The following snippet shows how a simple layer three
Etherchannel is configured:
interface Port-channel12
no switchport
ip address 10.0.12.1 255.255.255.0
!
interface FastEthernet0/13
no switchport
no ip address
channel-group 12 mode active
Page 2
!
no switchport
no ip address
!
no switchport
no ip address
OSPF is a good choice as an IGP for this setup because it bases interface metrics on bandwidth. However, the default OSPF
reference bandwidth is only 100 Mbps; any interface equal to or higher than 100 Mbps receives a cost of 1, which doesn't allow
differentiation between healthy and partially-failed Etherchannels.
S1# show ip ospf interface brief
Interface
PID
Area
Lo0
1
0
Po12
1
0
Po13
1
0
IP Address/Mask
10.0.0.1/32
10.0.12.1/24
10.0.13.1/24
Cost
1
1
1
State
P2P
BDR
BDR
Nbrs F/C
0/0
1/1
1/1
To resolve this, we raise the OSPF reference bandwidth to something much higher (say, 100 Gbps):
S1(config)# router ospf 1
S1(config-router)# auto-cost reference-bandwidth ?
The reference bandwidth in terms of Mbits per second
S1(config-router)# auto-cost reference-bandwidth 100000
% OSPF: Reference bandwidth is changed.
Please ensure reference bandwidth is consistent across all
S1(config-router)# ^Z
S1# show ip ospf interface brief
Interface
PID
Area
IP Address/Mask
Cost State
Lo0
1
0
10.0.0.1/32
1
P2P
Po12
1
0
10.0.12.1/24
333
BDR
Po13
1
0
10.0.13.1/24
333
BDR
routers.
Nbrs F/C
0/0
1/1
1/1
As you've probably predicted, the cost for S2 to reach the loopback interface of S1 (10.0.0.1/32) is 334 (333 for the Etherchannel
plus a metric of 1 for the loopback interface):
S2# show ip route 10.0.0.1
Routing entry for 10.0.0.1/32
Known via "ospf 1", distance 110, metric 334, type intra area
Last update from 10.0.12.1 on Port-channel12, 00:00:16 ago
Routing Descriptor Blocks:
* 10.0.12.1, from 10.0.0.1, 00:00:16 ago, via Port-channel12
Route metric is 334, traffic share count is 1
Revisiting our scenario with a failed member link between S1 and S2, we can observe very similar failover behavior (or rather, a
lack thereof):
Page 3

The failed Etherchannel, now operating at only 200 Mbps, is assgined a higher OSPF cost of 500 (for a total metric of 501).
However, 501 is still lower than the alternate route's aggregate cost of 667 (333 + 333 + 1), so our routing topology remains
unchanged.
Removing a second link from the etherhchannel, leaving a lone member link operating at 100 Mbps, increases its OSPF cost to
1000 (for a total path cost of 1001). This cost is high enough to now favor the alternate route with a cost of 667:
Finally, some higher-end platforms such as the Catalyst 6500 series support the port-channel min-link command, which forces an
Etherhchannel to a down state if it has fewer than the specified number of member links.
Posted in Design
Page 4
Disabling Dynamic Trunking Protocol (DTP)

By stretch | Tuesday, September 30, 2008 at 1:22 a.m. UTC
Cisco's Dynamic Trunking Protocol can facilitate the automatic creation of trunks between two switches. When two connected
ports are configured in dynamic mode, and at least one of the ports is configured as desirable, the two switches will negotiate the
formation of a trunk across the link. DTP isn't to be confused with VLAN Trunking Protocol (VTP), although the VTP domain does
come into play.
DTP on the wire is pretty simple, essentially only advertising the VTP domain, the status of the interface, and it's DTP type. These
packets are transmitted in the native (or access) VLAN every 60 seconds both natively and with ISL encapsulation (tagged as
VLAN 1) when DTP is enabled.
DTP is enabled by default on all modern Cisco switches. But a responsible network engineer has to ask himself, "why?" Do you
really want switches to form trunks on their own? I certainly don't, for several reasons.
First, it's simply bad design; trunks should be present where they were intended, and only where they were intended. Second,
leaving switch ports set to dynamic mode is a gaping security hole. If all it takes is the right DTP packet to form a trunk from an
access port, an intruder can easily inject traffic into whatever VLANs are allowed on the port (by default, all of them). Fortunately,
these two issues can be resolved by configuring a static switchport mode, either "access" or "trunk", as best practice dictates.
! Access port
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 10
! Trunk port
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport trunk encapsulation dot1q
However, even when a port is statically configured in such a manner, DTP is still active on the port. If you've ever attempted to
setup a trunk between two switches in different VTP domains and received the following error, you can thank DTP:
%DTP-5-DOMAINMISMATCH: Unable to perform trunk negotiation on port Fa0/1 because of
VTP domain mismatch.
Recall that DTP advertisements include the VTP domain name. A switch won't form a trunk on a DTP-enabled port to a switch
advertising a different VTP domain, even if the ports are manually configured in trunking mode. Nice, eh? Fortunately we can kill
http://packetlife.net/blog/2008/sep/30/disabling-dynamic-trunking-protocol-dtp/
Page 1
DTP once and for all with the switchport nonegotiate command on the interface.
Switch(config-if)# switchport nonegotiate
This configuration prevents DTP packets from being sent, effectively disabling trunk negotiation and evaluation of the VTP domain.
Posted in Security, Switching
http://packetlife.net/blog/2008/sep/30/disabling-dynamic-trunking-protocol-dtp/
Page 2
When does VLAN pruning occur?

By stretch | Thursday, June 26, 2008 at 1:04 a.m. UTC
sgtcasey over on networking-forum.com recently posed in an interesting question: what triggers VLAN pruning? Specifically, will a
switch only allow pruning of a VLAN from a trunk if it has no access ports configured for that VLAN? Or is it enough to have merely
no active ports?
Consider a simple trunking scenario:
Switch 1 is the VTP server, and has propagated VLANs 10, 20, and 30 to switch 2. The interfaces to which hosts A and B attach
are configured as access ports in VLAN 10, and an 802.1Q trunk is formed between the two switches. By examining the trunk
status on either switch we can verify that VLANs 1 and 10 are being passed while the others are pruned in both directions.
S1# show interface trunk
Port
Gi0/1
Port
Gi0/1
Mode
on
Encapsulation
802.1q
Status
trunking
Native vlan
1
Vlans allowed on trunk

1-4094
Port
Gi0/1
Vlans allowed and active in management domain

1,10,20,30
Port
Gi0/1
Vlans in spanning tree forwarding state and not pruned

1,10
Switch 2:
...
Port
Fa0/1
1,10
When host B is disconnected, its interface on switch 2 becomes inactive. As switch 2 has no remaining active ports in VLAN 10,
VLAN 10 becomes eligible for pruning. After roughly 30 seconds pass, we can see that switch 1 is now pruning VLAN 10 from the
trunk (VLAN 10 is absent from the last line of the output):
...
Port
Gi0/1
1
The VLAN remains unpruned on switch 2's end of the trunk, because it knows switch 1 still has at least one active port in VLAN 10:
...
Port
Fa0/1
1,10
http://packetlife.net/blog/2008/jun/26/when-does-vlan-pruning-occur/
Page 1
Posted in Switching
http://packetlife.net/blog/2008/jun/26/when-does-vlan-pruning-occur/
Page 2
SPANNING TREE PART 1
packetlife.net
Spanning Tree Protocols

Legacy STP
Algorithm Legacy ST
Defined By 802.1D-1998
Instances 1
Trunking N/A
PVST
PVST+
RSTP
RPVST+
MST
Legacy ST
Legacy ST
Rapid ST
Rapid ST
Rapid ST
Cisco
Cisco
802.1w,
802.1D-2004
Cisco
802.1s,
802.1Q-2003
Per VLAN
Per VLAN
Per VLAN
Configurable
ISL
802.1Q, ISL
N/A
802.1Q, ISL
802.1Q, ISL
Spanning Tree Instance Comparison

STP
PVST+
VLAN 1,10 Root
VLAN 20,30 Root
Root
A
All VLANs
xx xx
BPDU Format
Field
MST
MSTI 0 Root
MSTI 1 Root
A
VLAN 1
VLAN 10
VLAN 20
VLAN 30
Spanning Tree Specifications
Link Costs
Bits
802.1s
802.1Q-2003
MSTI 0 (1, 10)

MSTI 1 (20, 30)
802.1Q-2005
Bandwidth
Cost
4 Mbps
250
10 Mbps
100
16 Mbps
62
45 Mbps
39
100 Mbps
19
155 Mbps
14
622 Mbps
Protocol ID
16
Version
BPDU Type
Flags
Root ID
64
Root Path Cost
32
Bridge ID
64
Port ID
16
IEEE 802.1D-1998 Deprecated legacy STP standard
1 Gbps
Message Age
16
IEEE 802.1w Introduced RSTP
10 Gbps
Max Age
16
IEEE 802.1D-2004 Replaced legacy STP with RSTP
20+ Gbps
Hello Time
16
Forward Delay
16
802.1D-1998
802.1Q-1998
IEEE
ISL
Forward Delay
15s
Max Age
20s
Cisco
2s
PVST
802.1w
PVST+
IEEE 802.1s Introduced MST
2
3
4
Port States
Legacy ST
Rapid ST
IEEE 802.1Q-2005 Most recent 802.1Q revision
Disabled
PVST Per-VLAN implementation of legacy STP
Blocking
PVST+ Added 802.1Q trunking to PVST
Listening
RPVST+ Per-VLAN implementation of RSTP
Learning
Learning
Forwarding
Forwarding
Spanning Tree Operation

1
RPVST+
IEEE 802.1Q-2003 Added MST to 802.1Q
Default Timers
Hello
802.1D-2004
Discarding
Port Roles
Determine root bridge

The bridge advertising the lowest bridge ID becomes the root bridge
Legacy ST
Rapid ST
Select root port
Root
Root
Designated
Designated
Each bridge selects its primary port facing the root
Select designated ports

One designated port is selected per segment
Block ports with loops
Blocking
Alternate
Backup
All non-root and non-desginated ports are blocked
by Jeremy Stretch
v3.0
SPANNING TREE PART 2
packetlife.net
PVST+ and RPVST+ Configuration

spanning-tree mode {pvst | rapid-pvst}
! Bridge priority
spanning-tree vlan 1-4094 priority 32768
! Timers, in seconds
spanning-tree vlan 1-4094 hello-time 2
spanning-tree vlan 1-4094 forward-time 15
spanning-tree vlan 1-4094 max-age 20
! PVST+ Enhancements
spanning-tree backbonefast
spanning-tree uplinkfast
! Interface attributes
spanning-tree [vlan 1-4094] port-priority 128
spanning-tree [vlan 1-4094] cost 19
! Manual link type specification
spanning-tree link-type {point-to-point | shared}
! Enables PortFast if running PVST+, or
! designates an edge port under RPVST+
spanning-tree portfast
! Spanning tree protection
spanning-tree guard {loop | root | none}
! Per-interface toggling
spanning-tree bpduguard enable
spanning-tree bpdufilter enable
MST Configuration
spanning-tree mode mst
! MST Configuration
spanning-tree mst configuration
name MyTree
revision 1
! Map VLANs to instances
instance 1 vlan 20, 30
instance 2 vlan 40, 50
! Bridge priority (per instance)
spanning-tree mst 1 priority 32768
! Timers, in seconds
spanning-tree mst hello-time 2
spanning-tree mst forward-time 15
spanning-tree mst max-age 20
! Maximum hops for BPDUs
spanning-tree mst max-hops 20
Bridge ID Format
4
12
48
Pri
Sys ID Ext
MAC Address
Priority
4-bit bridge priority (configurable from 0 to 61440 in
increments of 4096)
System ID Extension
12-bit value taken from VLAN number (IEEE 802.1t)
MAC Address
48-bit unique identifier
Path Selection
1 Bridge with lowest root ID becomes the root
2 Prefer the neighbor with the lowest cost to root
3 Prefer the neighbor with the lowest bridge ID
4 Prefer the lowest sender port ID
Optional PVST+ Ehancements
PortFast
Enables immediate transition into the forwarding state
(designates edge ports under MST)
UplinkFast
Enables switches to maintain backup paths to root
BackboneFast
Enables immediate expiration of the Max Age timer in
the event of an indirect link failure
Spanning Tree Protection
Root Guard
Prevents a port from becoming the root port
BPDU Guard
Error-disables a port if a BPDU is received
Loop Guard
Prevents a blocked port from transitioning to listening
after the Max Age timer has expired
BPDU Filter
Blocks BPDUs on an interface (disables STP)
RSTP Link Types
Point-to-Point
Connects to exactly one other bridge (full duplex)
Shared
Potentially connects to multiple bridges (half duplex)
Edge
Connects to a single host; designated by PortFast
Troubleshooting
! Interface attributes
spanning-tree mst 1 port-priority 128
spanning-tree mst 1 cost 19
show spanning-tree [summary | detail | root]

show spanning-tree [interface | vlan]
show spanning-tree mst []
by Jeremy Stretch
v3.0
Port Security
By stretch | Monday, May 3, 2010 at 4:21 a.m. UTC
Port security is a layer two traffic control feature on Cisco Catalyst switches. It enables an administrator configure individual switch
ports to allow only a specified number of source MAC addresses ingressing the port. Its primary use is to deter the addition by
users of "dumb" switches to illegally extend the reach of the network (e.g. so that two or three users can share a single access
port). The addition of unmanaged devices complicates troubleshooting by administrators and is best avoided.
Enabling Port Security

Port security can be enabled with default parameters by issuing a single command on an interface:
Switch(config)# interface f0/13
Switch(config-if)# switchport port-security
Although only a single interface is used for illustration in this article, port security, if configured, is typically configured on all
user-facing interfaces.
We can view the default port security configuration with show port-security:
Switch# show port-security
Port Security
Port Status
Violation Mode
Aging Time
Aging Type
SecureStatic Address Aging
Maximum MAC Addresses
Total MAC Addresses
Configured MAC Addresses
Sticky MAC Addresses
Last Source Address:Vlan
Security Violation Count
interface f0/13
: Enabled
: Secure-down
: Shutdown
: 0 mins
: Absolute
: Disabled
: 1
: 0
: 0
: 0
: 0000.0000.0000:0
: 0
As you can see, there are a number of attributes which can be adjusted. We'll cover these in a moment. When a host connects to
the switch port, the port learns the host's MAC address as the first frame is received:
Port Security
Port Status
Violation Mode
Aging Time
Aging Type
Total MAC Addresses
interface f0/13
: Enabled
: Secure-up
: Shutdown
: 0 mins
: Absolute
: Disabled
: 1
: 1
: 0
: 0
: 001b.d41b.a4d8:10
: 0
Now, we disconnect the host from the port, connect a small switch or hub, and reconnect the original host plus a second,
unauthorized host so that they both attempt to share the access port. Observe what happens as soon as the second host attempts
to send traffic:
http://packetlife.net/blog/2010/may/3/port-security/
Page 1
%PM-4-ERR_DISABLE: psecure-violation error detected on Fa0/13, putting Fa0/13 in err-disable state

%PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 0021.55c8.f13c
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/13, changed state to down
%LINK-3-UPDOWN: Interface FastEthernet0/13, changed state to down
Inspecting the status of port security on the port again, we can see that the new MAC address triggered a violation:
Switch# show port-security interface f0/13
Port Security
: Enabled
Port Status
: Secure-shutdown
Violation Mode
: Shutdown
Aging Time
: 0 mins
Aging Type
: Absolute
SecureStatic Address Aging : Disabled
: 1
Total MAC Addresses
: 0
: 0
: 0
: 0021.55c8.f13c:10
: 1
Switch# show interfaces f0/13
FastEthernet0/13 is down, line protocol is down (err-disabled)
Hardware is Fast Ethernet, address is 0013.c412.0f0d (bia 0013.c412.0f0d)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
...
By default, a port security violation forces the interface into the error-disabled state. An administrator must re-enable the port
manually by issuing the shutdown interface command followed by no shutdown. This must be done after the offending host has
been removed, or the violation will be triggered again as soon as the second host sends another frame.
Tweaking Port Security

Violation Mode
Port security can be configured to take one of three actions upon detecting a violation:
shutdown (default) ; The interface is placed into the error-disabled state, blocking all traffic. protect ; Frames from MAC
addresses other than the allowed addresses are dropped; traffic from allowed addresses is permitted to pass normally. restrict ;
Like protect mode, but generates a syslog message and increases the violation counter.
By changing the violation mode to restrict, we are still alerted when a violation occurs, but legitimate traffic remains unaffected:
Switch(config-if)# switchport port-security violation restrict
Switch(config-if)# ^Z
Switch#
%PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 0021.55c8.f13c
Port Security
: Enabled
Port Status
: Secure-up
Violation Mode
: Restrict
Aging Time
: 0 mins
Aging Type
: Absolute
Page 2

Total MAC Addresses
:
:
:
:
:
:
1
1
0
0
0021.55c8.f13c:10
3
Unfortunately, violating traffic will continue to trigger log notifications, and the violation counter will continue to increase, until the
violating host is dealt with.

By default, port security limits the ingress MAC address count to one. This can be modified, for example, to accommodate both a
host and an IP phone connected in series on a switch port:
Switch(config-if)# switchport port-security maximum 2
One also has the option to set a maximum MAC count for the access and voice VLANs independently (assuming a voice VLAN
has been configured on the interface):
Switch(config-if)# switchport port-security maximum 1 vlan access
Switch(config-if)# switchport port-security maximum 1 vlan voice
MAC Address Learning

An administrator has the option of statically configuring allowed MAC addresses per interface. MAC addresses can optionally be
configured per VLAN (access or voice).
Switch(config-if)# switchport port-security mac-address 001b.d41b.a4d8 ?
vlan set VLAN ID of the VLAN on which this address can be learned
<cr>
Switch(config-if)# switchport port-security mac-address 001b.d41b.a4d8 vlan access
The configured MAC address(es) are recorded in the running configuration:
Switch# show running-config interface f0/13
Building configuration...
Current configuration : 259 bytes
!
switchport access vlan 10
switchport mode access
switchport voice vlan 20
switchport port-security
switchport port-security violation restrict
switchport port-security mac-address 001b.d41b.a4d8
end
Obviously, this is not a scalable practice. A much more convenient alternative is to enable "sticky" MAC address learning; MAC
addresses will be dynamically learned until the maximum limit for the interface is reached.
Switch(config-if)# no switchport port-security mac-address 001b.d41b.a4d8
Switch(config-if)# switchport port-security mac-address sticky
Page 3
Port Security
Port Status
Violation Mode
Aging Time
Aging Type
Total MAC Addresses
interface f0/13
: Enabled
: Secure-up
: Restrict
: 0 mins
: Absolute
: Disabled
: 1
: 1
: 0
: 1
: 001b.d41b.a4d8:10
: 0
After a MAC address has been learned, it is recorded to the configuration similarly to as if it were entered manually:
Switch# show running-config interface f0/13
Building configuration...
Current configuration : 311 bytes
!
switchport access vlan 10
switchport voice vlan 20
switchport port-security
switchport port-security violation restrict
switchport port-security mac-address sticky
switchport port-security mac-address sticky 001b.d41b.a4d8
end
MAC Address Aging

By default, secure MAC addresses are learned (in effect) permanently. Aging can be configured so that the addresses expire after
a certain amount of time has passed. This allows a new host to take the place of one which has been removed. Aging can be
configured to take effect at regular intervals, or only during periods of inactivity. The following example configures expiration of
MAC addresses after five minutes of inactivity:
Switch(config-if)# switchport port-security aging time 5
Switch(config-if)# switchport port-security aging type inactivity
Port Security
: Enabled
Port Status
: Secure-up
Violation Mode
: Restrict
Aging Time
: 5 mins
Aging Type
: Inactivity
: 1
Total MAC Addresses
: 1
: 0
: 0
: 001b.d41b.a4d8:10
Page 4
: 0
After five minutes of inactivity, we can see that the address has been purged:
Port Security
Port Status
Violation Mode
Aging Time
Aging Type
Total MAC Addresses
interface f0/13
: Enabled
: Secure-up
: Restrict
: 5 mins
: Inactivity
: Disabled
: 1
: 0
: 0
: 0
: 001b.d41b.a4d8:10
: 0
At this point, the old address will be re-learned the next time a frame is sent from that host, or a new host can take its place.
Auto-recovery
To avoid having to manually intervene every time a port-security violation forces an interface into the error-disabled state, one can
enable auto-recovery for port security violations. A recovery interval is configured in seconds.
Switch(config)# errdisable recovery cause psecure-violation
Switch(config)# errdisable recovery interval 600
Ten minutes after a port was error-disabled, we can see that the port is automatically transitioned back into operation:
%PM-4-ERR_RECOVER: Attempting to recover from psecure-violation err-disable state on Fa0/13
%LINK-3-UPDOWN: Interface FastEthernet0/13, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/13, changed state to up
This is a great way to automatically clear port security violations after the user has been given an opportunity to remove the
offending host(s). Note that is the cause is not cleared, the violation will trigger again after the port comes back up, re-initating the
auto-recovery cycle.
Footnote
Although a deterrent, port security is not a reliable security feature, as MAC addresses are trivially spoofed, and multiple hosts can
still easily be hidden behind a small router. IEEE 802.1X is a much more robust access edge security solution.
Posted in Security, Switching
Page 5
IEEE 802.1X
packetlife.net
802.1X Header
1
Version
1
Type
Terminology
2
Length
EAP
EAP Over LANs (EAPOL)

EAP encapsulated by 802.1X for transport across LANs
EAP Header
1
Code
1
Identifier
2
Length
Data
Authenticator
Supplicant
The device (client) attached to an access link that requests
authentication by the authenticator
Authenticator
The device that controls the status of a link; typically a
wired switch or wireless access point
EAP Flow Chart

Supplicant
Extensible Authentication Protocol (EAP)

A flexible authentication framework defined in RFC 3748
Authentication
Authentication Server
Server
A backend server which authenticates the credentials
provided by supplicants (for example, a RADIUS server)
Guest VLAN
Fallback VLAN for clients not 802.1X-capable
Restricted VLAN
Fallback VLAN for clients which fail authentication
Identity Request
Identity Response
Access Request
Challenge Request
Challenge Response
Access Challenge
Access Request
802.1X Packet Types

0 EAP Packet
1 Request
1 EAPOL-Start
2 Response
2 EAPOL-Logoff
3 Success
3 EAPOL-Key
4 Failure
4 EAPOL-Encap-ASF-Alert
Success
Access Accept
EAP
RADIUS
Configuration
Global Configuration
! Define a RADIUS server
radius-server host 10.0.0.100
radius-server key MyRadiusKey
! Configure 802.1X to authenticate via AAA
aaa new-model
aaa authentication dot1x default group radius
! Enable 802.1X authentication globally
dot1x system-auth-control
EAP Codes
Interface Defaults
Max Auth Requests 2
Reauthentication Off
Quiet Period 60s
EAP Req/Resp Types

1 Identity
2 Notification
3 Nak
4 MD5 Challenge
Reauth Period 1hr
5 One Time Password
Server Timeout 30s
6 Generic Token Card
Supplicant Timeout 30s

Tx Period 30s
254 Expanded Types

255 Experimental
Port-Control Options
Interface Configuration
! Static access mode

! Enable 802.1X authentication per port
dot1x port-control auto
! Configure host mode (single or multi)
dot1x host-mode single-host
! Configure maximum authentication attempts
dot1x max-reauth-req
! Enable periodic reauthentication
dot1x reauthentication
! Configure a guest VLAN
dot1x guest-vlan 123
! Configure a restricted VLAN
dot1x auth-fail vlan 456
dot1x auth-fail max-attempts 3
by Jeremy Stretch
force-authorized
Port will always remain in authorized state (default)
force-unauthorized
Always unauthorized; authentication attempts are ignored
auto
Supplicants must authenticate to gain access
Troubleshooting
show dot1x [statistics] [interface <interface>]
dot1x test eapol-capable [interface <interface>]
dot1x re-authenticate interface <interface>
v2.0
FIRST HOP REDUNDANCY
packetlife.net
Protocols
Attributes
HSRP
Hot Standby Router Protocol (HSRP)

Provides default gateway redundancy using one active
and one standby router; standardized but licensed by
Cisco Systems
Standard RFC 2281

Load Balancing No
IPv6 Support Yes
Virtual Router Redundancy Protocol (VRRP)

An open-standard alternative to Cisco's HSRP,
providing the same functionality
Transport UDP/1985
Default Priority 100
Gateway Load Balancing Protocol (GLBP)

Supports arbitrary load balancing in addition to
redundancy across gateways; Cisco proprietary
HSRP
100
Standby
200
Multicast Group 224.0.0.2
GLBP
RFC 3768
Cisco
No
Yes
No
Yes
IP/112
UDP/3222
100
100
1 sec
3 sec
224.0.0.18
224.0.0.102
VRRP
100
Active
Default Hello 3 sec
VRRP
Listen
100
200
Backup
Master
HSRP Configuration
ip address 10.0.1.2 255.255.255.0
standby version {1 | 2}
standby 1 ip 10.0.1.1
standby 1 timers <hello> <dead>
standby 1 priority <priority>
standby 1 preempt
standby 1 authentication md5 key-string <password>
standby 1 track <interface> <value>
standby 1 track <object> decrement <value>
GLBP
100
Backup
100
200
AVF
100
AVF
AVG
AVF
HSRP/GLBP Interface States

Speak Gateway election in progress
Active Active router/VG
Standby Backup router/VG
Listen Not the active router/VG
VRRP Interface States
Master Acting as the virtual router
Backup All non-master routers
VRRP Configuration
ip address 10.0.1.2 255.255.255.0
vrrp 1 ip 10.0.1.1
vrrp 1 timers {advertise <hello> | learn}
vrrp 1 priority <priority>
vrrp 1 preempt
vrrp 1 authentication md5 key-string <password>
vrrp 1 track <object> decrement <value>
GLBP Configuration
ip address 10.0.1.2 255.255.255.0
glbp 1 ip 10.0.1.1
glbp 1 timers <hello> <dead>
glbp 1 timers redirect <redirect> <time-out>
glbp 1 priority <priority>
glbp 1 preempt
glbp 1 forwarder preempt
glbp 1 authentication md5 key-string <password>
glbp 1 load-balancing <method>
glbp 1 weighting <weight> lower <lower> upper <upper>
glbp 1 weighting track <object> decrement <value>
by Jeremy Stretch
GLBP Roles
Active Virtual Gateway (AVG)
Answers for the virtual router and assigns
virtual MAC addresses to group members
Active Virtual Forwarder (AVF)
All routers which forward traffic for the group
GLBP Load Balancing
Round-Robin (default)
The AVG answers host ARP requests for the
virtual router with the next router in the cycle
Host-Dependent
Round-robin cycling is used while a consistent
AVF is maintained for each host
Weighted
Determines the proportionate share of hosts
handled by each AVF
Troubleshooting
show standby [brief]
show vrrp [brief]
show glbp [brief]
show track [brief]

v2.0

Advanced Switching Reference Manual Ver. 0.9

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Advanced Switching Reference Manual Ver. 0.9

Hochgeladen von

Copyright:

Verfügbare Formate

Reference Manual ver. 1.

Created by Paul Nadstoga (pnadstoga@gmali.com)

CISCO DESIGN RECOMMENDATIONS

ACCESS LAYER: focus on port density and VLAN termination

list all the applications running in the environment

an incident response plan

improving customer support

PREPARE requirements, strategy, financial justification

ENTERPRISE CAMPUS NETWORK DESIGN

user connect here to the network

interconnection between ACCESS and CORE layers

provides connectivity of all DISTRIBUTION layer devices

MODULAR NETWORK DESIGN

a group of ACCESS together with their DISTRIBUTION layer switches

SWITCH BLOCK EXAMPLES:

each VLAN extends to the

VLANs are limited to the ACCESS

connects two or more SWITCH BLOCKs together

CORE functions is an independent module

usually used to connect individual devices to a switch or to connect 2 x switches together

L2/L3 device used to forward frames

ETHERNET SWITCH OPERATION

To manually add an entry to the CAM table:

To avoid having duplicate entries in the

To view CAM table:

aging-time 0 disables aging

To modify the aging timer:

based on the information found in the CAM table

based on the information found in the TCAM table

For broadcasts and multicasts flooding is

SWITCH FRAME FORWARDING LOGIC

SWITCH FORWARDING ARCHITECTURES

Route Caching (NetFlow switching, fast switching, flow-based switching)

CEF (topology based switching)

CISCO Express Forwarding

SWITCH MEMORY TYPES

(CAM) CONTENT-ADDRESSABLE MEMORY

capable of searching the entire content in a single operation

To view the MAC table content:

vlan ports VLAN membership

<S1#show mac address-table (dynamic | address (mac-address) | interface (interface))>

show mac address-table

(TCAM) TERNARY CONTENT-ADDRESSABLE MEMORY

provides three results upon lookup: 0 (true), 1 (false), any value

Most switches have multiple TCAM so that inbound and

Feature Manager (FM) the FM software compiles /

TCAM entries are composed of:

Values 134 bit quantities consisting of source and

<S1(config)#interface (type) (number)>

<S1(config)#interface range macro (macro name)>

<S1(config-if)#description (description; up to 240 characters)>

PORT SPEED / DUPLEX MODE

<S1(config-if)#speed (auto | 10 | 100 | 1000)>

NOTE: Gigabit Ethernet ports are always set to 1000!

CISCO recommends hardcoding the speed value

If a 10/100 or a 10/100/1000 port is assigned a speed

<S1(config-if)#duplex (auto | full | half)>

Auto-negotiation is only allowed on Fast Ethernet and Gigabit

Auto-negotiation uses priorities to determine which

100BASE-T2 (full duplex)

100BASE-TX (full duplex)

100BASE-T2 (half duplex)

10BASE-T (full duplex)

BDPU is received on a STP Port Fast