Advanced Switching Reference Manual Ver. 0.9

8/21/2019 Advanced Switching Reference Manual Ver. 0.9

http://slidepdf.com/reader/full/advanced-switching-reference-manual-ver-09 1/168

eference Manual ver. 1.0 (2012-14)

eated by Paul Nadstoga ([email protected])



Contents

PLANNING & DESIGN 1

ETHERNET 9

VLANs 30

SPANNING TREE PROTOCOL 60

L2 SECURITY 10

HIGH AVAILABILITY 12

APPENDIXES 14



PLANNING &DESIGN

• CISCO Design Recommendations

• Enterprise Campus Network Design



ADVANCED SWITCHING ver. 1.0 CREATED BY PAWEL ‘PAUL’ NADSTOGA ([email protected]) 2013-14

SCO DESIGN RECOMMENDATIONS

NERAL 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 ACCESS LAYER: focus on port density and VLAN termination

o DISTRIBUTION LAYER: focus on routing and boundary definitions

o

CORE LAYER: exclusive focus on traffic transport optimization

CURITY PLANNING

list all the applications running in the environment

consider having a network audit

the design should include:

o an incident response plan

o

security policy

o

a list of customer’s requirements

AN PLANNING

organizational objectives to keep in mind when developing a VLAN implementation plan could include:

o

improving customer support

o

increased competitiveness

o

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




ONA

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 NETWORK INFRASTRUCTURE LAYER – where all the network devices are connected (network, servers, storage etc.)

o

INTERACTIVE SERVICES LAYER – allocated resources to applications delivered through the network infrastructure layer

o

APPLICATION LAYER – includes business applications

DIOO

PREPARE – requirements, strategy, financial justification

PLAN – network requirements, shortcoming of the existing network, project plan

DESIGN –

create design specificationsIMPLEMENT – build the network and add additional components

OPERATE – maintain network health, day to day operations

OPTIMIZE – proactive management, optimize the network design




TERPRISE CAMPUS NETWORK DESIGN

ERARCHICAL 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

LOCAL – same segment / VLAN as user (traffic can access ACCESS layer only)

o REMOTE – different segment / VLAN as user (traffic can access DISTRIBUTION layer)

o

ENTERPRISE – central to all campus users (traff ic can access DISTRIBUTION and CORE layers)

CCESS 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

STRIBUTION 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

ORE 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




ODULAR 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 SWITCH BLOCK

o CORE BLOCK




WITCH 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

devices at the DISTRIBUTION layer become bottlenecks (due to the volume of inter-VLAN traffic, CPU intensive filtering and packet manipulation etc.)

o 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

WITCH BLOCK EXAMPLES:

L2 ACCESS SWITCHES L2 / 3 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

VLANs are limited to the ACCESS

switches

no dependence on STP convergence

L3 links between ACCESS and

DISTRIBUTION switches carry routin

updates

networks stability thorough the rou

protocol convergence




ORE BLOCK

connects two or more SWITCH BLOCKs together

must be as efficient and resilient as possible (it is campus network’s 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

COLLAPSED CORE

o DUAL CORE

OLLAPSED CORE

CORE and DISTRIBUTION layers merged together (their functions are provided by the same devic

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!




UAL 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




HERNET STANDARD

HERNET 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

HERNET STANDARDS

NAME STANDARD OVERVIEW COMMENTS

ETHERNET 802.3

10 Mbps

CSMA/CD half / full duplex

100 m. cable limit

usually used to connect ACCESS switches to end devices

The half-duplex and collisions issues

non-existent in switched Ethernet.

FAST ETHERNET 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

GIGABIT ETHERNET 802.3z

1,000 Mpbs

full-duplex (auto-negotiation is not possible)

the L1 has been modified:

o

IEEE 802.3 Ethernet provided frame format, CSMA/CD, full duplex and other Ethernetcharacteristics

o 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 GIGABIT ETHERNET 802.3ae

10,000 Mpbs

same frame format allows backward compatibility

full-duplex mode exclusively




HERNET SWITCH

HERNET 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




HERNET SWITCH OPERATION

OPERATION PURPOSE COMMENTS

LEARNING

upon arrival on a switchport ,every frame’s 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 view CAM table:

<Switch#show mac address-table>

To avoid having duplicate entries in t

table, the switch will delete an entry

port to MAC mapping if the same MA

has been learned on a different port

addresses are unique and should nev

seen on more than one switch port).

If a MAC address is being learnt on

multiple interfaces, it is flagged as

flapping.

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

To modify the aging timer :

<Switch(config)#mac address-table aging-time (300, 10-1000000)>

aging-time 0 – disables aging

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

For broadcasts and multicasts floodin

considered a default behaviour.

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 port’s ingress queues

the frame’s 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




WITCH FRAME FORWARDING LOGIC

AYER 2 SWITCHING

ingress queues – inbound frames are placed in one of the switches ingress queues with ea

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

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

AYER 3 SWITCHING

L2 forwarding table – destination MAC address is used as an index to the CAM

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




WITCH FORWARDING ARCHITECTURES

Process Switching

o

each packet is examined by the internal processor and is handled in software (only used in routers)

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

o the route processor tracks the first packet’s flow and sets up a shortcut for the remaining packets to avoid software-based routing (immediately forwarding in hardware)

o

used by both routers and L3 Switches

CEF (topology based switching)

o

CISCO Express Forwarding

o

routing table dynamically populates a single database of the entire network topology in hardware

o

default option on CISCO routers and switches




WITCH MEMORY TYPES

MEMORY OVERVIEW COMMENTS

(CAM) CONTENT-ADDRESSABLE MEMORY

capable of searching the entire content in a single operation

provides two results upon lookup: 0 (true) / 1 (false)

stores MAC table

vlan – port’s VLAN membership

mac address – L2 address associated with the switch

type – static or dynamic

port – switch port mapped to the MAC address

Stale entries are aged out after 300 sec. and deleted. To view the MAC table content:

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




(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 paral

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 protocolinformation (all patterns to be matched)

Masks – 134 bit quantities that select only the value

of interest; a mask bit i s set to exactly match a value

or is not set for value bit that do not matter

Results – numeric values that represent what actions

take after the TCAM lookup occurs (e.g. permit, deny

index value to a QoS po licer etc.)




WITCHPORT

WITCHPORT CONFIGURATIONS

ORT SELECTION

ITEM COMMANDS COMMENTS

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

<S1(config-if )#...>

MULTIPLE PORTS<S1(config)#interface range (type) (1st ) (, | -) (2nd ) …>

<S1(config-if-range)#...>

MACROS

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

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

<S1(config-if-range)#...>

ORT ID

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

ORT SPEED / DUPLEX MODE

SPEED

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

CISCO recommends hardcoding the speed value

NOTE: Gigabit Ethernet ports are always set to 1000!

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

of Auto, both its speed and duplex mode is negot

If both ports are set to auto-negotiate , they will u

the highest common speed.




DUPLEX MODE

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

CISCO recommends hardcoding the duplex value

Auto-negotiation is only allowed on Fast Ethernet and G

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 canno

modified manually.

The process is repeated whenever the port’s statu

changes.

Duplex mismatch: different modes on each end; h

duplex station will detect collision when both end

transmit, the full duplex end will transmit at any t

If a mode is set to a non-auto value on one end an

auto on another, the negotiation will fail (either b

are set to auto or mode on both is set to the same

value)

Auto-negotiation uses priorities to determine wh

technology to agree on – if both devices can supp

more than one technology, the one with highest

priority is used

PRIORITY TECHNOLOGY

7 100BASE-T2 (full duplex)

6 100BASE-TX (full duplex)

5 100BASE-T2 (half duplex)

4 100BASE-T4

3 100BASE-TX

2 10BASE-T (full duplex)

1 10BASE-T




ROR MANAGEMENT

DETECTION SCOPE

<S1(config)#errdisable detect cause (all | cause name)>

TRIGGER SCOPE

all every possible cause

arp-inspection dynamic ARP inspection

bpduguard BDPU is received on a STP Port F

channel-misconfig EtherChannel bundle

dhcp-rate-limit DHCP snooping

dtp-flap DTP flapping

inpower inline power

link-flap link flapping

rootguard BDPU received on an wrong por

security-violation security policy breach

storm-control strom control threshold exceede

udld unidirectional link

ERROR RECOVERY

Manual:

<S1(config-if)#shutdown>

<S1(config-if)#no shutdown>

Automatic:

<S1(config)#errdisable recovery (all | cause name)>

<S1(config)#errdisable recovery interval (300, 30-86400)>

errdisable recovery interval – time interval

port stays down before automatic recovery




WITCHPORT VERIFICATION AND TSHOOTING

show interfaces (interface)

show interfaces status

show interface status err-disabled

COMMAND VERIFIES / DISPLAYS EXAMPLE / SCREENSHOT

show interfaces

port status

description

encapsulation

keepalive mechanism

duplex mode port speed




show interfaces status

description / status / vlan ID / dupex mode / speed / type

show interfaces status errdisabled Lists all ports in error disable state




HERCHANNEL

HERCHANEL 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




HERCHANNEL 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

SELECT LOAD BALANCING

METHOD

<S1(config)#port-channel load-balance (src-ip, method )>

METHOD HASH INPUT

src-ip source IP address

dst-ip destination IP address

src-dst-ip source and destination IP address

src-mac source MAC address

dst-mac destination MAC address

src-dst-mac source and destination MAC address




HERCHANNEL CONFIGURATIONS

AgP 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


SELECT MEMBER PORTS

<S1(config)#interface (*range) (interface)>

*<S1(config-if)#shutdown>

When ports are configured as member ports of an EtherChannel, a logical por

channel interface is automatically created.

Good practice to shut down the ports that are being configured.

HARDCODE NEGOTIATION PROTOCOL <S1(config-if)#channel-protocol pagp>

CONFIGURE THE GROUP

<S1(config-if)#channel-group (1-64) mode (auto | desirable) *(silent)>

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 befo

being added to the budle; if PAgP is not heard on an active port

remains in the UP state but PAgP reports to the SPT that the po

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 doesn’t

participate in PAgP.

NOTE: it may take as long as 50 sec. for the data to start flowing thr

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

the STP moving through the LISTENING and LEARNING




CP

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


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 <S1(config)#interface (*range) (interface)> When ports are configured as member ports of an EtherChannel, a lo

port-channel interface is automatically created.

HARDCODE NEGOTIATION PROTOCOL <S1(config-if)#channel-protocol lacp>

CONFIGURE THE GROUP

<S1(config-if)#channel-group (1-64) mode (passive | active)>

mode passive – willing to become an EtherChannel; not pro-ac

mode active - willing to become an EtherChannel , pro-active

HARDCODE PORT LACP PRIORITY

<S1(config-if)#lacp port-priority (32768, 1-65535)> 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 thehigher the priority) ( port ID is used as tie-breaker).

The ports in the standby mode replace the ones that failed.




ON-NEGOTIATE

does not use negotiation protocol and hardcodes the channel


SELECT MEMBER PORTS

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

*<S1(configif)#shutdown>

When ports are configured as member ports of an EtherChannel, a logical po

channel interface is automatically created.


CONFIGURE THE GROUP <S1(config-if)#channel-group (1-64) mode on>

YER 3 EtherChannel


SELECT MEMBER PORTS

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


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<S1(config-if)#channel-group (1-64) mode (on | desirable | auto | passive | active> If a negotiation protocol has been configured, the mode cannot be

to on.

DISABLE SWITCHING ON THE LOGICAL

CHANNEL INTERFACE

<S1(config)#interface port-channel (1-64)>

<S1(config-if)#no switchport>

ASSIGN IP ADDRESS ON THE LOGICAL

CHANNEL INTERFACE

<S1(config-)#interface port-channel ( port channel )>

<S1(config-if)#ip address A.A.A.A M.M.M.M>




HERCHANNEL 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

show etherchannel

group state (L2 or L3)

number of member ports

negotiation protocol

show etherchannel detail

Detailed information about configured EtherChannels




show etherchannel summary Summarized information on existing port-channels

show etherchannel load-balance

EtherChannel load balancing information

show etherchannel port-channel

Information on the virtual port-channel interface

show etherchannel protocol Information on the negotiation protocol used for the given group




show lacp internal

Summary of LACP etherchannel

show lacp neighbor

Displays LACP neighbours

show lacp sys-id Displays LACP System ID



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

1 – 1005

o 1002 – 1005 are reserved for Token Ring and FDDI VLANs

o

1, 1002 – 1005 are created automatically and cannot be removed

o

stored in NVRAM

o

stored in vlan.dat in flash memory

EXTENDED RANGE

o 1006 – 4094

o

designed for ISPs

o

stored in running-config

o not learned by VTP!




VLAN TYPES

DATA VLAN

o

configured to carry only user generated traffic

o

can be also referred to user VLAN

DEFAULT VLAN

o

the VLAN all switch ports become members of upon switch boot up

o

for CISCO switches this is VLAN 1

o

cannot be renamed or deleted

o

L2 control traffic, e.g. CDP, will always be sent on default VLAN (this behaviour cannot be changed!)

o

security best practice – associate all switch ports with a VLAN other than VLAN 1 after switch boot up

NATIVE VLAN

o

assigned to an 802.1q trunk ports

o

every untagged frames will be placed on native VLAN

o

created to maintain backwards compatibility with devices generating untagged traffic

o

the first switch to receive a frame strips off the native VLAN tag and forwards it out all ports

MANAGEMENT VLAN

o

any VLAN configured to carry management traffic

o

e.g. HTTP, SSH, SNMP

VOICE VLAN

o

any VLAN configured to carry VoIP traffic

o

VoIP has to be separated from other traffic due to its demand for quality




TATIC VLANs CONFIGURATIONS

STEP # COMMANDS COMMENTS

CREATE A VLAN

SINGLE:

<S1(config)#vlan (1-1001, 1006-4094)>

RANGE:

<S1(config)#vlan (vlan id ),(vlan id )-(vlan-id )>

*<S1(config-vlan)#name (name; up to 32 characters)>

1-1001 – normal range; stored automatically in vlan.dat

1006-4094 – extended range; stored in runnin-config

*ADD DESCRIPTION <S1(config-vlan)#description (description; up to 32 characters, no spaces)>

*ADD NAME <S1(config-vlan)#name (name)>

ASSIGN PORTS

<S1(config)#interace (interface)>

<S1(config-if)#switchport mode access>

<S1(config-if)#switchport access vlan (vlan id )>

When a port is assigned to a non-existing VLAN, that VLAN is c

automatically.

A port can belong to only one VLAN at a time.

If a port with existing VLAN membership is assigned to anothe

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)>

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 caus

ports assigned to the given VLAN to stop transmitting dat

active – brings back a VLAN from the suspended state

TSHOOT

show vlan

show vlan brief

show vlan summary




RUNKS

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

RUNK ENCAPSULATION PROTOCOLS

ISL

o

Inter-Switch Link

o

CISCO proprietary

o

adds a 26-byte header and 4-byte trailer to the frame (30 byte overhead total) (double tagging)

o

a 15-bit source VLAN ID is placed in the header

o the trailer contains CRC information

o does not support untagged frames!

IEEE 802.1q

o

open standard

o

VLAND ID is embedded into the existing frame (single tagging)

o

the VLAN ID is contained in the last 12 bits of the tag (0-4095; except for 0,1,4095)

o

supports untagged frames but only on the native VLAN




RUNK 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)


SELECT PORTS

<S1(config)#interface (*range) (interface)>


Good practice to shut down the ports that are b

configured.

HARDCODE L2 MODE<S1(config-if)#switchport> A switch port must be in Layer 2 mode before it

be configured as trunk.

SELECT ENCAPSULATION<S1(config-if)#switchport trunk encapsulation (isl | dot1q | negotiate)> negotiate – chooses whichever protocol is supp

on both ends (ISL is given preference)

DEFINE NATIVE VLAN

<S1(config-if)#switchport trunk native vlan (1-4094)> NOTE: native VLAN is used only with dot1q

encapsulation (ISL does not support untagged fr

A native VLAN mismatch will still bring the trunk

up, but an error message will be generated (via

messages) and there’s a risk that traffic will no

traverse the link correctly.

Also, the error will be generated even if theencapsulation is set to ISL – in that case mismat

have no effect on the operation whatsoever.

SELECT VLANs THAT WILL BE

ALLOWED ON THE TRUNK

<S1(config-if)#switchport trunk allowed vlan (all | none | vlan id )

<S1(config-if)#switchport trunk allowed vlan *((add | except | remove) (vlan id ))>

allowed vlan all – all (1-4094) VLANs are a

allowed vlan add | remove – adds | remo

VLANs from the current list; this should ref

the configuration at the other end




SELECT TRUNK MODE

<S1(config-if)#switchport mode (trunk | dynamic desirable | dynamic auto)> mode trunk – unconditional, permanent tr

mode (if the mode is selected, DTP on the

should be set to nonegotiate)

TSHOOT

show interfaces (interface) trunk

show interfaces (interface) switchport

show dtp




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 COMMENTS

TRUNK

starts as a TRUNK port

periodically sends DTP frames (advertisements) to the remote host

unconditional trunking state

To hardcode mode on an interface:

<S1(config-if)#switchport mode trunk>

If this mode is used, DTP on the port should be

disabled.

DYNAMIC AUTO

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


< S1(config-if)#switchport mode dynamic auto>

DYNAMIC DESIRABLE (default)

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>




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




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

domain’s 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




TP 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>




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

domain name + length

o

version

o

configuration revision number

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

Included information:

VTP version

number of subset advertisement to fol

domain length

domain name

revision number

ID of the switch that last update the re

time stamp

MD5 encryption hash code




SUBSET

sent after a VLAN database change takes place

list specific changes that have been performed e.g. creating and deleting VLAN

Included information:

VLAN status (activated / suspended)

VLAN type (Ethernet / Token Ring)

MTU

VLAN name length

VLAN number

VLAN name

REQUEST

sent to the SERVER to request any VLAN information the switch is lacking

replied with SUMMARY followed by SUBSET

Triggers:

VLAN database has been cleared

VTP domain name change

receipt of a SUMMARY with a h igher

revision number than the local value

the switch has been reset

missed SUBSET advertisement




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 i s 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 m ember 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 change the VTP mode to TRANSPARENT and then change it back to SERVER

o 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 s witches in VTP Transparent mode!

VLAN 1 is considered pruning ineligible!

disabled by default




VTP CONFIGURATIONS

VTP Version = 1

VTP Domain Name = null

VTP Mode = Server

Config Revision = 0

VLANs = 1


CONFIGURE DOMAIN

<S1(config)#vtp domain name (domain name; up to 32 characters)>

If no VTP Domain Name has been configured on any swit

the segment, switches will not multicast VTP messages (e

they are VTP Servers).

Once a switch running in VTP Server mode has been conf

with a VTP Domain, other switches VTP Servers / Clients

same segment will automatically learn the Domain Name

Revision Number and VLANs.

It then can start sending VTP messages itself.

DTP sends the VTP Domain Name in its packets. If two en

a link belong to different VTP Domains, the trunk will not

(if DTP is used to negotiate a trunk).

The exceptions to the above:

both ends have default DTP settings (VTP Domain = n

one end has hardcoded DTP Domain the other is left

default (in this case, the DTP Domain is learned and

adopted)

Because a switch can only be configured with a single VT

Domain, it will only listen and act on VTP advertisements

hears that match its own VTP Domain Name




CONFIGURE MODE <S1(config)#vtp mode (server | client | transparent)>

CONFIGURE PASSWORD

<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 SERVE

and then is used to validate received advertisements (by

CLIENTS).

CONFIGURE VERSION

<S1(config)#vtp version (1 | 2)> The versions are not interoperable with the domain!

Switches that only support ver. 1 cannot participate in th

domain along ver. 2 switches.

When the VTP Version is set to 2 on a server, all version 2

capable switches in the domain auto-configure themselv

user ver. 2

CONFIGURE PRUNING

Enable pruning on switch (VLANs 2-1001):

<S1(config)#vtp 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 ))>

VLAN 1, 1002-1005 are never eligible for pruning!




VTP VERIFICATION AND TSHOOTING

show vtp status

show vtp counters

show interface (interface) pruning

COMMAND DISPLAYS / VERIFIES EXAMPLE SCREENSHOT

show vtp status

VTP Version

VTP Domain

VTP Mode

VTP Revision

VTP Encryption

show vtp counters

Various statistics associated with VTP operation

show interface (interface) pruning

VTP Pruning related information




NTER-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




NTER-VLAN ROUTING WITH A ROUTER

OPTION 1: ONE INTERFACE PER VLAN

a router’s 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 router’s 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

simple configuration

o

the switch does not have to support L3 (just VLANs and trunking)

DISADVANTAGES:

o

router is a single point of failure

o

if the trunk becomes congested all VLANs will affected

o

higher latency

o

added processing on the router




NTER-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

XAMPLE 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

VI 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

o 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)

o confirm:

S1#show interface (interface)>




OPTION 2: ROUTED PORTS

a L3 Switch’s 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>

<S1(config-if)#no switchport> <-- enables L3 routing capabilities, disables L2 switching capabilities

To verify:

<S1#show interface (interface) switchport>




PACKET FORWARDING ARCHITECTURES

Process Switching

o

each packet is examined by the internal processor and is handled in software (only used in routers)

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

o

the route processor tracks the flow’s first packet and sets up a shortcut for the remaining packets to avoid software-based routing (immediately forwarding in hardware)

o

used by both routers and L3 Switches

CEF (topology based switching)

o


o

routing table dynamically populates a single database of the entire network topology in hardware

o

default option on CISCO routers and switches




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 router’s 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

Routing Table

o

ARP Table

Layer 3 Forwarding Table

o

FIB

o

Adjacency Table

Rewrite Engine




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 en

dCEF (Distributed CEF ) – CEF is distributed completely among multiple L3 forwarding en

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 polic




REWRITE ENGINE

dedicated packet-rewrite hardware

after valid entries have been found in the FIB and Adjacencies Tables , packet’s header must be rewritten

the process takes place in real time

the packet undergoes the following changes before being forwarded:

o

L2 ADDR DESTINATION NEXT-HOP L2 ADDR

o

L2 ADDR SRC OUTBOUND PORT L2 ADDR

o

L3 IP TTL DECREMANTED BY 1

o

L3 CHECKSUM RECALCULATE

o

L2 CHECKSUM RECALCULATE




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

show interface (interface) switchport

L2 / L3 capabilities

operational mode

trunk encapsulation native VLAN

allowed VLANs

pruning




show interface vlan (vlan id )

SVI related information

show ip cef

Views content of FIB




show ip cef (source) detail

Detailed information for the FIB content.

show ip cef (source) summary

Summarized information for the FIB content.




show adjacency (source) detail

Detailed FIB adjacency information




show adjacency (source) summary

Summarised FIB adjacency content information

show cef not-cef-switched

Counters for packets not switched by CEF



SPANNING TREEPROTOCOL

• 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



ADVANCED SWITCHING ver. 1.0 CREATED BY PAWEL ‘PAUL’ NADST OGA ([email protected]) 2013-14

P OVERVIEW

Spanning Tree Protocol

ensures there’s 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

BPDUs are exchanged

o

a single switch is designated as the root bridge that servers as a reference point for all STP calculations

o

other switches decide which ports to block and which to keep active




P CONCEPTS

OOT 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

ANGERS 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

EST PRACTICE:

a primary root bridge should always be chosen in a deterministic fashion

a secondary root bridge should be chosen for redundancy purposes

statically set a switch as the primary root bridge:

1(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)

statically set a switch as the secondary root bridge:

1(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

statically hardcode switch priority (preferred option):

1(config)#spanning-tree priority vlan (vlan id ) priority (32768, 0-65535)>




DU

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

FIELD # BYTES FIELD FUNCTION

1 2 Protocol ID (always set to 0)

2 1 Version (always set to 0)

3 1 Msg. Type (Configuration or TCN)

4 1 Flags TC (Topology Change) or TCA (Topology Change Ack.)

5 8 Root ID Root BID (Priority (2 byte) + MAC (6 byte))

6 4 Root Cost Cost from local port to the root bridge

7 8 BID Sender BID (Priority (2 byte) + MAC (6 byte))

8 2 Port ID Originating Port Identifier (Port Priority + Port Number)

9 2 Msg. Age Time elapsed since the root sent conf. msg. on which the current msg. is based (in 256th of a sec.)

10 2 Max Age The maximum time the root should be considered live and operational (in 256th of a sec.) (20, 6-40)

11 2 Hello Time The time interval between successive BPDUs generated by the root (in 256th of a sec.) (2, 1-10)

12 2 Forward Delay The delay that the switches should wait before transitioning to another STP state (256th of a sec.) (15, 4-30)

Configuration

BPDU

TCN

BPDU




IDGE 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 it’s elected as the root

contains the following fields:

o

bridge priority

o

extended system ID

o

MAC address

BITS 16 48

NO EXTENDED ID: BRIDGE PRIORITY MAC ADDRESS

BITS 4 12 48

WITH EXTENDED ID: BRIDGE PRIORITY EXTENDED SYS ID MAC ADDRESS

FIELD OVERVIEW COMMENTS

BRIDGE PRIORITY

can only be configured as multiples of 4096

To configure:

Method 1:

<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>

The lower the value the higher the priority.

root primary - sets bridge priority to 24576

If the priority of the active root is lower than 24576:

o

set the local priority value to match the one of the ro

(but only if local MAC is lower than the one of the roo

o

set the local priority the next 4096 increment below t

priority of the active root

NOTE: if the next increment is less than 4096 the switch will

set the priority to 0 (zero) - it will have to be done manually

root secondary – priority is set to 28672 (becomes the n

root bridge if the current fails and other switches are

configured with default settings)




EXTENDED SYS ID

an STP enhancement created to support VLANs

System ID = VLAN ID

omitted in certain STP configurations (early STP implementation didn’t use VLANs)

contains the VLAN ID with which the BPDU is associated

To enable:

<S1(config)#spanning-tree extend system-id>

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.

MAC ADDRESS

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>

The MAC used for STP can come from the Supervisor module

the backplane or a pool of 1024 addresses that are assigned

every supervisor or backplane (depending on the switch mod

Because by default every bridge is configured with the same

priority value, the MAC address is the deciding factor for roobridge election.

If election is performed according to the default settings, thi

will most likely mean that the physically oldest switch on the

network becomes the root .




ORT 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

4 250 5,000,000

10 100 2,000,000

16 62 1,250,000

100 19 200,000

1,000 4 20,000

2,000 3 10,000

10,000 2 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:





OOT PATH COST

the cumulative costs of all links leading to the root bridge

determined in the following manner:

1.

root bridge generates a BPDU with the root path cost = 0 (zero) because all of its ports sit directly to the root

2.

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

3.

the BPDU is sent out with the updated root path cost value

4.

as each switch receives the BPDU, the root path cost is incremented by the ingress port path cost

ter 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

wer value becomes the new root path cost and the root port is updated accordingly.




ORT 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

root port

o

designated port

o

non-designated port

o

disabled port

ROLE OVERVIEW COMMENTS

ROOT

x1 per switch

exists only on the non-root bridges only one allowed per bridge

switchport with the best (lowest) root path cost

When two ports complete for a role choose t

one with:

lowest BID received from a neighbour

o

lowest bridge priority

o

lowest MAC

lowest root path cost

lowest port ID received from a neighbour

o lowest port priority

o

lowest port number

DESIGNATED

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

NON-DESIGNATED

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




ORT STATES

each switch port transitions through x5 different states during the convergence process

STATE OVERVIEW COMMENTS

DISABLED

does not participate in the STP process

does not forward frames

Possible reasons for this state:

the port was shutdown

the port is not operational

BLOCKING

A port will go into this state when:

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

The purpose of this state is for the switch to:

find the root bridge

figure out what roles to assign to each port

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




DU 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 f rame 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!

configure network diameter:

1(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 BPDU’s 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




P CONVERGENCE

the election of root bridge and port roles takes place simultaneously

the port roles may change multiple times before the convergence has finished

AGE 0: IDENTIFY LINK’S COSTS

SCOPE --> ALL SWITCHED TOPOLOGY

on a link-to-link basis, identify and assign STP Cost to each link

AGE 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 t aking 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 proc

ection deciding factors (lower is better): lowest BID

1.

select the switch with the lowest bridge priority (default = 32768)

2.

select the switch with the lowest MAC address

o verify the identity of the root bridge:

S1#show spanning-tree root>




AGE 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

ection deciding factors (lower is better):

1. select the port with the lowest root path cost

2. select the port that received a BPDU from a switch with lowest bridge ID (bridge priority + MAC)

3. select the port that received a BPDU from a port with lowest port ID ( port priority + port number )

o verify the identity of the root ports:

S1#show spanning-tree>

AGE 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

ection deciding factors (lower is better):

1. select the port with the lowest root path cost

2. select the port that generated a BPDU with lowest BiD (bridge priority + MAC)

3.

select the port with lowest port ID ( port priority + port number )

o verify the identity of the designated and non-designated ports:

S1#show spanning-tree>




P TOPOLOGY CHANGE

RECT 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 i

MAC table

AMPLE:

CAT A detects a link failure on the fa1/2

CAT C detects a link failure on the fa1/1

CAT C removes its best BPDU it had received from the root bridge since the link is DOWN

TCN BPDU is not sent by CAT C because its root port is down

CAT A sends a Configuration BPDU with the TCN bit set on fa1/1 (only link that is UP)

This BPDU is received and relayed to each switch along the way

CAT A and B shorten their TABLE AGE TIMER to FORWAD DELAY value (300 --> 15 sec.)

(the timer is shorten for the duration of (MAX AGE + FORWARD DELAY))

CAT C fa1/2 becomes the root port because it received the best BPDU from the root

0.

CAT C fa1/2 transitions through all STP states: LISTENING, LEARNING and FORWARDING




DIRECT TOPOLOGY CHANGE

occurs when a there’s no link failure but the flow of data is still compromised

e.g. a firewall is blocking the traffic

AMPLE:

The link between CAT A and CAT C is UP | UP but there’s no data flow

No link failure detected so no TCN are sent

After the MAX AGE timer has expired, the CAT C flushes its best BPDU

The next BPDU received is on port fa1/2 (currently in the BLOCKING state)

The fa1/2 port is now the root port for CAT C and transitions through all states




SIGNIFICANT TOPOLOGY CHANGE

occurs when a access port link changes status

AMPLE:

The link between CAT C and PC is treated like a regular link

The state of the link will change every time the PC is booted / shut down

If the link goes DOWN, CAT C sends away the TCN BPDU

CAT A sends back an acknowledgement

CAT A sends BPDU with TCN set on fa1/1 and fa1/2

CAT B and C change their TABLE AGE TIME to FORWARD DELAY

when a port is configured with PortFast , no TCN are sent!




P CONFIGURATIONS

ITEM COMMANDS COMMENTS

NETWORK DIAMETERTo adjust network diameter:

<S1(config)#spanning-tree vlan 1 root primary diameter (2-7)>

BRIDGE PRIORITY

To statically set a switch as the primary root bridge:

<S1(config-if)#spanning-tree vlan (vlan id ) root primary>

To statically set a switch as the secondary root bridge:

<S1(config-if)#spanning-tree vlan (vlan id ) root secondary>

To statically hardcode switch priority (preferred option):

<S1(config)#spanning-tree priority vlan (vlan id ) priority (32768, 0-65535)>

To verify:

<S1#show spanning-tree bridge>

root primary – priority is set to 24576 (if local MAC i

lower than the one of the current root )

OR

the next 4096 increment below the current root ’s pr

root secondary – priority is set to 28672 (becomes th

next root bridge if the current fails but only if other

switches are configured with default settings)

EXTENDED SYS-ID

To enable:

<S1(config)#spanning-tree extend system-id>

To verify:

<S1#show spanning-tree summary>

PORT COSTS

To configure the port cost on an interface:

<S1(config-if)#spanning-tree cost (*vlan (vlan-id )) (cost; 1-2000000000)>

To default port cost:

<S1(config-if)#no spanning-tree cost>

To verify:





PORT PRIORITYTo modify STP port priority:

<S1(config-if)#spannin-tree port-priority (128; 0-240)>

Increments of 16

TIMERS

o HELLO

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.)>

o

FORWARD DELAY

To adjust:

<S1(config)#spanning-tree timer (*vlan (vlan-id )) forward-time (15, 4-30 sec.)>

o MAXIMUM AGE

To adjust:

S1(config)#spanning-tree timer (*vlan (vlan-id )) max-age (20, 6-40 sec.)>

PVRST+

To enable PVRST+ mode:

<S1(config)#spanning-tree mode rapid-pvst>

To re-start the protocol migration process:

<S1#clear spanning-tree detected-protocols>

clear spannig-tree detected protocols – forces the r

negotiation with adjacent switches




P EXTENSIONS

OMPARSION

GLOBAL INTERFACE

SCOPE VIOLATION / PURPOSE VIOLATION / PURPOSE

PortFast all ACCESS ports

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

BPDUGuard all PortFast ports

BPDU is received

place port in err-disabled state

unconditional (port does not need to be PortFast enabled)

BPDU is received


BPDUFilter all PortFast ports 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

RootGuard --- --- BPDU is received

place port in root-inconsistent state

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

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

UDLD SWITCH

applies on all optic-fibre ports

keepalive ceased incoming


applies on the port

keepalive ceased incoming





rtFast

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

o 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)

o 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 toLISTENING or LEARNING states i.e. it will remain FORWARDING in case it had been doing so – the PortFast status w

be lost and if after that port goes into BLOCKING and it will behave as per standard STP behaviour

o verify:

S1#show spanning-tree interface (interface) portfast>

DU Guard

if a BPDU is received on a port with PortFast and BPDU Guardenabled, 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 beenmanually re-enabled

recommended to enable on all PortFast ports

not recommended to enable on uplinks where the root is located

disabled by default

o enable BPDU Guard on all PortFast enabled ports (PortFast has to be enabled):

S1(config)#spanning-tree portfast bpduguard default>

o enable BPDU Guard on a per interface basis (does not have to be PortFast enabled):

S1(config-if)#spanning-tree bpduguard enable>

o view err-disabled ports:

S1#show interfaces status err-disabled>




DU 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

o enable BPDU Filter on all PortFast ports (filters OUTBOUND BPDUs on all PortFast enabled ports):

S1(config)#spanning-tree portfast bpdu filter default>

o 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)>

plinkFast

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 r

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 the

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

o 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 port’s failu

o verify:

S1#show spanning-tree uplinkfast>




ckboneFast

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

send out UDP RLQ Request

o 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)

o

if an RLQ Reply is received on the root port --> the path to the root bridge is stableo

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

o enable BackboneFast:

S1(config)#spanning-tree backbonefast>

o verify:

S1#show spanning-tree backbonefast>




ot 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

o enable BackboneFast:

S1(config-if)#spanning-tree guard root>

o verify:

S1#show spanning-tree detail>

o view blocked ports:

<S1#show spanning-tree inconsistentports>




op 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

o enable Loop Guard globally:

S1(config)#spanning-tree loopguard default>

o enable Loop Guard on a port:

S1(config-if)#spanning-tree guard loop> <-- only the offending VLANs are blocked; not the port itself

o view blocked ports:

S1#show spanning-tree inconsistentports>




DLD

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 NORMAL – port status marked as having an undetermined state; syslog message generated; port allowed to continue its operation

o 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

o enable UDLD on all fibre optic ports:

S1(config)#udld (enable | aggressive)>

o enable UDLD on a single port (fibre or not):

S1(config-if)#udld port (*aggressive)> OR <S1(config-if)#udld (enable | aggressive)>

o adjust UDLD message parameters:

S1(config)#udld message time (7 or 15; 7-90 sec.)

o reset all interfaces which have been shutdown by UDLD:

S1#udld reset>

o verify:

S1#show udld>




P 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


show spanning-tree

Basic information about:

Root ID

Bridge ID

Interfaces Roles / States / Costs / Types




show spanning-tree detail

Detailed information about STP and participating ports.

Designated Port ID = received Port ID

show spanning-tree summary

Summarized information on STP.

show spanning-tree root

Displays the current Root Bridge.

show spanning-tree bridge

Displays local BiD info.




P FLAVOURS

T

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

VST

Per VLAN Spanning Tree Protocol

CISCO proprietary version of CST

x1 instance of STP per VLAN

requires ISL encapsulation of trunks

VST+

Per VLAN Spanning Tree Protocol +

CISCO proprietary version of CST

provides interoperability between CSP and PVSP

works over both ISL and dot1q trunks




TP

Rapid Spanning Tree Protocol

802.1w

ST

Multiple Spanning Tree

802.1s




APID SPANNING TREE

802.1w

developed to use 802.1d’s 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)

enable RPVST+ mode:

1(config)#spanning-tree mode rapid-pvst>

re-start the protocol migration process:

1#clear spanning-tree detected-protocols>




TP 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

1 2 Protocol ID

2 1 Version

3 1 Msg. Type

4 1 Flags # BIT # FIELD

5 8 Root ID 1 7 TCN

6 4 Root Cost 2 6 PROPOSAL

7 8 BID 3 4-5 PORT ROLE

8 2 Port ID 4 3 LEARNING

9 2 Msg. Age 5 2 FORWARDING

10 2 Max Age 6 1 AGREEMENT

11 2 Hello Time 7 0 TCA

12 2 Forward Delay




TP LINK TYPES

the type of port determines its state

TYPE OVERVIEW COMMENTS

POINT-TO-POINT

connects to another switch

BPDUs are being received

full duplex ports are automatically considered point-to-point links

To hardcode port type:

<S1(config-if)#spanning-tree link-type point-to-point>

Half-duplex ports are considered to be on a shared medium and can

become a point-to-point link (traditional 802.1d must be used).

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)>

EDGE

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 :

<S1(config-if)#spanning-tree portfast>




TP PORT ROLES

all ports are initially placed in DESIGNATED role


ROOT

as per 802.1d

DESIGNATED

as per 802.1d

ALTERNATE

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

BACKUP

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




TP 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


DISCARDING

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

LEARNING

incoming frames are dropped

MAC addresses are learned

FORWARDING incoming frames are forwarded

MAC addresses are learned

OPERATIONAL PORT STATE 802.1D 802.1W

DISABLED DISABLED

DISCARDINGENABLED BLOCKING

ENABLED LISTENING

ENABLED LEARNING LEARNING

ENABLED FORWARDING FORWARDING




TP 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 / DISCARDI

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

ONVERGENCE SEQUENCE (BASED ON THE CENTRE SWITCH):




AMPLE:

TIAL STATE:

RSTP is enabled

all switchport are disabled (shutdown)

SW3 has the best BiD

SW1 fa0/1 and SW2 fa0/1 are enabled (no shutdown)

Link type is negotiated:

full-duplex --> POINT-TO-POINT

Ports are put into:

ROLE --> DESIGNATED

STATE --> DISCARDING

Send BPDU with proposal bit (0100 0000) set - advertise self as the root bridge

Compare BPDUs:

SW1 --> local BiD superior; ignore proposal

SW2 --> local BiD inferior; accept SW1 as the root

. SW2 puts fa0/1 in:

ROLE --> ROOT


SW2 sends out BPDU with agreement bit set (0000 0010)

SW2puts its fa0/1 in:

ROLE --> ROOT

STATE --> FORWARDING

SW1 receives the agreement and puts its fa0/1 in:

ROLE --> DESIGNATED





0. SW1 fa1/1 and SW4 fa1/1 are enabled (no shutdown)

1.



2.

Ports are put into:

ROLE --> DESIGNATED


3.

SW2: send BPDU with proposal bit (0100 0000) set advertising SW1as the root bridge

4. SW4 send BPDU with proposal bit (0100 0000) set advertising self as the root bridge

5.

SYNC started, place all non-edge ports into:

ROLE --> DESIGNATED


6.

Compare BPDUs:

SW2 --> SW1 BiD superior; ignore proposal


7.

SW4 puts fa0/1 in:

ROLE --> ROOT


8.


9. SW4 puts fa1/1 in:

ROLE --> ROOT


0.

SW2receives the agreement and puts its fa1/1 in:

ROLE --> DESIGNATED





1.

SW3 fa0/1 and SW4 fa0/1 are enabled (no shutdown)

2.



3.

Ports are put into:

ROLE --> DESIGNATED


4.

Send BPDU with proposal bit (0100 0000) set advertising self as the root bridge

5.

SYNC started, place all non-edge ports into:

ROLE --> DESIGNATED STATE --> DISCARDING

6.

Compare BPDUs:

SW4 --> SW1 BiD superior; ignore proposal



ROLE --> ROOT


8.


9. SW4receives the agreement and puts its fa0/1 in:

ROLE --> DESIGNATED



ROLE --> ROOT





TP 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




ULTIPLE 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 MST Configuration Name (32 characters)

o MST Revision Number (0-6553)

o

MST VLAN -to-instance mapping (4096)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 if all attributes match, the STP instances within MST can be shared as part of the same region

o 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)




ST CONFIGURATIONS

ONFIGURATION


ENABLE MST MODE<S1(config)#spanning-tree mode mst> After MST is enabled (and configured) PVST+ operation s

(a switch cannot run both MST and PVST+ simultaneously

ENTER MST CONFIGURATION MODE

<S1(config)#spanning-tree mst configuration>

<S1(config-mst)#>

root primary – priority is set to 24576 OR the next 40

increment below the current root ’s priority

root secondary – priority is set to 28672 (becomes th

next root bridge if the current fails and other switch

are configured with default settings)

DISPLAY CURRENT CONFIGURATION <S1(config-mst)#show current>

CONFIGURE REGION

Regions are identified by having the same name, revision

number and VLAN-to-instance assignments. If any of the

differs, regions fall back to RPVST+.

o NAME <S1(config-mst)#name (region name)> Identify the MST domain.

o REVISION NUMBER <S1(config-mst)#revision (0-65535)> Allows for tracking changes to the region (manually).

o 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 chan

ABORT CHANGES <S1(conifg-mst)#abort> Exists MST sub-configuration mode and abandons chang




NING

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)>

TIMERS

<S1(config)#spanning-tree mst hello-time (2; 1-10)>

<S1(config)#spanning-tree mst forward-time (15; 4-30)>

<S1(config)#spanning-tree mst max-age (20; 6-40)>

Timers are not applied to specific MST instances because

timers are defined through the IST instance and BPDUs.




ST VERIFICATION AND TSHOOTING

show spanning-tree mst detail

show spanning-tree mst configuration

show spanning-tree mst interface (interface)


show spanning-tree mst detail

Basic information about:

Root ID

Bridge ID

Interfaces Roles / States / Costs / Types

show spanning-tree mst configuration

MST Region configuration:

Name

Revision #

VLANs-to-Instance mappings



L2 SECURITY

• Port Security

• Port Based Authentication

• L2 Attacks Mitigation

• VLANs Security

• Network Monitoring



ADVANCED SWITCHING ver. 1.0 CREATED BY PAWEL ‘PAUL’ NADSTOGA ([email protected]) 2013 -14

ORT SECURITY

VERVIEW

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!

ONFIGURATION


PUT PORT IN ACCESS MODE <S1(config-if)#switchport mode access>

ENABLE PORT SECURITY <S1(config-if)#switchport port-security>

SET MAC LIMIT<S1(config-if)#switchport port-security maximum (1-132)> Specifies the maximum number of MAC addresses

allowed on the port.

SET VIOLATION POLICY

<S1(config-if)#switchport port-security violation (shutdown | restrict | protect)>

To recover a port from err-disable state:

<S1(config-if)#shut>

<S1(config-if)#no shut OR

<S1(config)#errdisable recovery cause psecure-violation>

shutdown – the port is put into err-disable s

restrict – port stays UP | UP, offending pack

are dropped and running count is kept, can s

a trap to SNMP or a syslog msg.

protect – port stays UP | UP, offending pack

are dropped

CONFIGURE STATIC MACs

<S1(config-if)#switchport port-security mac-address (H.H.H | sticky)> If the number of static addresses configured is les

than number of allowed addresses on the port, th

remaining addresses are learned dynamically.

CONFIGURE MAC AGING

POLICY

<S1(config-if)#switchport port-security aging static time (0-1440 sec.) (absolute | inactivity)> absolute – static entries are aged out after

defined period of time

inactivity – static entries are aged out i f inac

for the defined period of time

TSHOOT

show port-security

show port-security interface (interface)

show interfaces status err-disabled

clear port-security dynamic (address (H.H.H) | interface (interface)>




ORT BASED AUTHENTICATION

VERVIEW

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 user’s 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 serv

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

EAPOL

o

STP

o

CDP




2.1x CONFIGURATION


ENABLE AAA <S1(config)#aaa new-model>

DEFINE RADIUS SERVER <S1(config)#radius-server host (hostname | A.A.A.A) key (string)> Multiple RADIUS servers can be configured.

ENABLE AUTHENTIACTION METHOD <S1(config)#aaa authentication dot1x default group radius>

ENABLE 802.1X

<S1(config)#dot1x system-auth-control> Once 802.1x is globally enabled on a switch, all

switchports default to the force-authorized state –

PC connected to a switchport can immediately sta

accessing the network.

CONFIGURE PORTS

<S1(config-if)#dot1x port-control (force-authorized | force-unauthorized | auto)> 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

force-unauthorized – port is force to never

authorize any connected client

auto – port uses an 802.1x exchange to mov

from the unauthorized to authorized state, if

successful (requires an 802.1x capable

application on the client)

*ALLOW MULTIPLE HOSTS ON A PORT<S1(config-if)#dot1x host-most multi-host> Useful when multiple hosts are connected to the

switchport through a hub or a switch.

TSHOOT show dot1x all

show dot1x statistics interface (interface)




ATTACKS MITIGATION

HCP 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

ONFIGURATION


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<S1(config-if)#ip dhcp snooping trust> Legitimate devise, such as DHCP Server, should be

placed behind trusted ports.

DEFINE DHCP REQUEST RATE <S1(config-if)#ip dhcp snooping limit rate (1-4294967294 pps.)> No limit by default.

*OPTION-82

<S1(config-if)#ip dhcp snooping information option> DHCP Relay Agent Information.

When a DHCP Request is intercepted on an untrus

port, the switch add its own MAC address and porinto the Option-82 field in the DHCP Request. The

DHCP Reply echos back the Option-82 information

When switch intercepts the DHCP Reply it compar

the Option-82 to confirm that the Reply arrived on

valid port on itself.

Enabled be default.

TSHOOT show ip dhcp snooping

show ip dhcp snooping binding




DDRESS 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

ITIGATION: 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

ONFIGURATION


ENABLE DHCP SNOOPING GLOBALLY<S1(config)#ip dhcp snooping> Must be enabled to allow packet inspection!

See DHCP Snooping configuration.

ENABLE PORT-SECURITY <S1(config-if)#switchport port-security> See port security configuration.

STATIC IP BINDINGS

<S1(config)#ip source binding (mac addres) vlan (vlan id ) ( A.A.A.A) interface (interface)> When static inspection is used, DHCP Snooping m

be enabled for a relevant VLAN.

The host’s MAC address is bound to specific VLAN

IP address, and is expected to be found on a speci

interface.

ENABLE SOURCE IP GUARD ON I-FACE

<S1(config-if)#ip verify source (port-securtity)> ip verify source – 1st check: inspect the sourc

address

port -security – 2nd check: inspect the source

address

TSHOOT 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 ))




RP 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

ITIGATION: 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

ONFIGURATION


ENABLE DHCP SNOOPING GLOBALLY <S1(config)#ip dhcp snooping> See DHCP Snooping configuration.

ENABLE DAI<S1(config)#ip arp inspection vlan (vlan id )> By default, all switchports associated with the VLA

specified are considered untrusted .

*VALIDATE L2 HEADER

<S1(config)#ip arp inspection validate (src-mac | dst-mac | ip)> By default, only the MAC and IP addresses contain

within the ARP Reply are validated. This option

validates that the packet is really coming from the

address listed inside it.

src-mac – check the source MAC in L2 heade

against sender MAC in the ARP Reply

dst -mac – check the destination MAC in L2

header against destination MAC in the ARP R

ip – check the sender’s IP address in all ARPrequests; check the source IP against the

destination IP in all ARP Replies

*DEFINE ARP ACL<S1(config-if)#arp access-list ( ARP ACL name)>

<S1(config-if)#permit ip host (source IP) mac host (source MAC ) *(log)>

Specifies static IP to MAC mappings that are perm




*APPLY ARP ACL TO AN I-FACE

<S1(config-if)#ip arp inspection filter ( ARP ACL name) vlan (vlan id ) (*static)> When ARP Reply packet is intercepted, its content

checked against the ARP ACL first, the DHCP Snoo

database next.

static – prevents check against the DHCP

Snooping dabatase

TSHOOT show ip verify source ( interface)

show ip source binding ( A.A.A.A) (H.H.H ) (dhcp snooping | static) (interface (interface)) (vlan (vlan id ))




N 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%

ITIGATION: STORM CONTROL

allows to shutdown interfaces that generate excessive traffic

the blocked port remains shut down until the traffic drops below the failing threshold

ONFIGURATION


ENABLE STORM CONTROL

<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)>

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

TSHOOT show storm-control (interface)

show storm-control history




WITCH SPOOFING

a switchport is left to its default settings:

o switchport mode dynamic auto

o

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 attacker’s PC masquerades as a switch

the attacker has access to any VLAN that is permitted to pass over the trunk

ITIGATION:

plicitly set switchport mode to access:

1(config-if)#switchport mode access>

sable DTP:

1(config-if)#switchport nonegotiate>

utdown any used ports:

1(config-if)#shut>

AN 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

the attacker is connected to an access switchport

o

the same switch must have an 802.1q trunk

o

the trunk must have the attacker’s access VLAN as its native VLAN

ITIGATION:

create dedicated native VLAN:

prune the native VLAN off both ends of the trunk

force a switch to tag the native VLAN on all its 802.1q trunks:

1(config)#vlan dot1q tag native>




ANs SECURITY

ACLs

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

ACLs CONFIGURATIONS


DEFINE ACCESS MAP <S1(config)#vlan access-map (map name)>

DEFINE MATCHING CONDITIONS

<S1(config-access-map)#match ip address ( ACL # | name)>

<S1(config-access-map)#match ipx address ( ACL # | name)>

<S1(config-access-map)#match mac address ( ACL # | name)>

NOTE: ACLs with a log parameter are not suppo

DEFINE ACTION

<S1(config-access-map)#action (drop | forward (capture) | redirect ( interface)> drop – matching packets are dropped

forward – matching packets are allowed

redirect – matching packets are redirected

specified interface

APPLY TO VLAN<S1(config)#vlan filter (map name) vlan-list (vlan id )> VACLs are applied globally to one more VLANs a

not to VLAN SVI

TSHOOT show vlan access-map (map name)>

show vlan filter




IVATE VLANs

VERVIEW

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

PROMISCIOUS – communicates with every port within the PRIMARY and SECONDARY VLANs

o

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!




IVATE VLANs CONFIGURATIONS


SET VTP TO TRANSPARENT MODE <S1(config)#vtp mode transparent)> Private VLANs have only local significance.

CONFIGURE SECONDARY VLANs

<S1(config)#vlan (vlan id )

<S1(config-vlan)#private-vlan (community | isolated)>

community – devices within the community Second

VLAN can communicate with each other and with t

promiscuous port

isolated – devices within the isolated Secondary VLA

can only communicate with the promiscuous port

CONFIGURE PRIMARY VLAN

<S1(config)#vlan (vlan id )

<S1(config-vlan)#private-vlan primary>

1-1001 – normal range; stored automatically in vlan

in flash 1006-4094 – extended range; stored in runnin-conf

YER 2

ASSOCIATE SECONDARY VLANs

WITH PRIMARY VLAN

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

<S1(config-vlan)#private-vlan association (secondary VLAN # ),(secondary VLAN# )…>

ASSIGN PORT ROLES

<S1(config)# interface (interface)>

<S1(config-if)#switchport mode private-vlan (host | promiscuous)>

host - connects to a host that resides on an isolate

community VLAN

promiscuous – connects to a router, firewall or oth

gateway and can communicate with any device on t

primary or its secondary VLANs (ignore PVLAN rules

ASSIGN PORTS TO SECONDARY

VLANs

<S1(config-if)#switchport private-vlan host-association ( primary vlan) (secondary vlan)>

MAP PROMISCIOUS PORT TO

SECONDARY VLANs

<S1(config)#interface ( promiscuous port )>

<S1(config-if)#switchport private-vlan mapping ( primary vlan) (allowed secondary vlan

1),(allowed secondary vlan 2)…>




YER 3

ASSOCIATE SECONDARY VLAN TO

PRIMARY VLAN SVI

<S1(config)#interface vlan (vlan # )>

<S1(config-if)#private-vlan mapping ( pvlan id )>

Allows L3 traffic switching that originated from SECONDA

VLANs.

Configured on Primary VLAN’s VLAN Interface.

TSHOOT show vlan private-vlan

show vlan private-vlan type




ETWORK MONITORING

SLOG

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

YSLOG MESSAGE FORMAT:




SLOG CONFIGURATIONS


LOCATE LOGGING SERVER

<Router(config)#logging host (hostname | A.A.A.A)>

*<Router(config)#logging source-interface (interface)>

source-interface – (optional) can be useful in

situations where more than one link to the s

exists (normally, the router will use informat

in the routing table to select the best path)

SET LOGGING SEVERITY FOR THE MESSAGES SENT TO THE :

LVL KEYWORD

0 EMERGENCIES

1 ALERTS

2 CRITICAL

3 ERRORS

4 WARNINGS

5 NOTIFICATIONS

6 INFORMATIONAL

7 DEBUGGING

o SERVER <Router(config)#logging trap (lvl | keyword )>

o

CONSOLE <Router(config)#logging console (lvl | keyword )>

o BUFFER <Router(config)#logging buffered (lvl | keyword )>

o LINES

<Router(config)#logging monitor (lvl | keyword )>

ENABLE LOGGING

<Router(config)#logging on>

<Router#terminal monitor>

logging on - enables logging on all outputs terminal monitor – enables logging on virtua

lines

Only the console logging is enabled by default .

Logging to specific destinations can be controlled

individually.

TSHOOT show logging




MP

the standard for network monitoring and management

x3 core elements:

o Network Management Application (SNMP Manager)

o SNMP Agents (running inside a managed device)

o

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

SNMP ver. 1 – insecure

o

SNMP ver. 2 – introduced the RW community strings, added 64 bit counter support, insecure

o

SNMP ver. 3 – provides encryption and authentication

NMP CONFIGURATIONS


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 )




SLA

Internet Protocol Service Level Agreement

technology that allows Cisco devices to automatically gather information about data traffic e.g.:

o

network latency and response time

o

packet loss

o

jitter and IP Voice quality

o

end-to-end network connectivity

IP SLA end-point can be either a device or an IP SLA Responder

P SLA OPERATION:

source sends an IP SLA control message with the configured operation to the responder (UDP 1967) (protocol, port, and duration)

if MD5 is enabled, the checksum is sent with the control message

if authentication is enabled, the responder verifies it (if it fail s, 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




SLA CONFIGURATIONS

COMPONENTS COMMANDS COMMENTS

PROBE

<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:

<Router#show ip sla configuration>

operation number - identification number of the IP S

operation

icmp-echo - configures source to non-responder type

probe

*icmp-echo source-interface - specifies the source

interface of the ICMP probes

*icmp-echo source-ip - specifies the source IP addres

the ICMP probes (when a source IP / hostname is not

configured, IP SLA chooses the IP address nearest to

probe’s 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 w

for a response from its request packet (default = 500

msec.)

threshold - sets the rising threshold that generates a

reaction event and stores history operation for an IP

operation (e.g. sends SNMP trap) (default = 5000 mse

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>

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 (th

default parameter is pending meaning no informatiocollected)

TRACKING

OBJECTS

<Router(config)#track (tracked object; 1-500) ip sla ( probe number 1-2147483647) reachability>

<Router(config-track)#delay up (0-180 sec.) down (0-180 sec.)>

To verify:

<Router#show track>

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 even

(regulate flapping of the tracking state)




RESPONDERS <S1(config)#ip sla responder) Enables sending and receiving IP SLAs control packets.




SLA VERIFICATION AND TSHOOTING

show ip sla statistics

show ip sla configuration

debug ip sla trace (*1-2147483647)

COMMAND VERIFIES EXAMPLE

show ip sla statistics

operation ID

type of operation

start time

latest return code: OK | FAIL

number of successes / failures

operation TTL

show ip sla configuration

type of operation

target address / source interface

schedule

threshold

statistics

debug ip sla trace (*1-2147483647) Debugs IP SLA processes



HIGHAVAILABILITY

• Redundant Supervisory Engines

• First Hop Redundancy Protocols




DUNDANT SUPERVISORY ENGINES

only available on Catalyst 4500 / 6500 families

provides redundancy for the switch’s 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

RPR

o

RPR+

o

SSO




R

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)

R+

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.

O

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)

DUNDANCY MODES CONFIGURATIONS


ENABLE REDUNDANCY

<Router(config)#redundancy> Command needs to be issued on both modu

Once enabled, all configuration changes only

needs to be entered on the ACTIVE superviso(the running—config is automatically synced

SELECT REDUNDANCY MODE

<Router(config-red)#mode (rpr | rpr-plus | sso)> When enabling RPR+, and the peer only supp

RPR, the supervisor automatically fall backs t

RPR.

TSHOOT show redundancy states




SF

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

BGP

o

OSPF

o

EIGRP

o

IS-IS

SF CONFIGURATIONS

PROTOCOL COMMANDS COMMENTS

BGP<Router(config-router)#router bgp ( AS number )>

<Router(config-router)#bgp graceful-restart>

EIGRP<Router(config-router)#router eigrp ( AS number )>

<Router(config-router)#nsf>

OSFP<Router(config-router)#router ospf ( process ID)>

<Router(config-router)#nsf)>

IS-IS

<Router(config-router)#router isis (tag)>

<Router(config-router)#nsf (cisco | ietf)>

<Router(config-router)#nsf interval (minutes)>

<Router(config-router)#nsf t3 (manual (sec.) | adjacency)>

<Router(config-router)#nsf interface wait (sec.)>




RST HOP REDUNDANCY PROTOCOLS

OTOCOLS COMPARISON

OTE: 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




RP

VERVIEW

Hot Standby Routing Protocol

CISCO proprietary

a single vIP and vMAC per a HSRP group (2+ routers)

HELLOs are sent to:

o ver 1: 224.0.0.2, UDP 1985

o 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)!

RTUAL MAC ADDRESS

CISCO VENDOR ID HSRP ID x - STANDBY GROUP #

ver. 1 0000.0C 07.AC xx

CISCO VENDOR ID HSRP ID x - STANDBY GROUP #

ver. 2 0000.0C 9F.FX xx




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 First candidate to become an ACTIVE router (x1 per HSRP Group)

ACTIVE Responds to traffic sent on the vIP (x1 per HSRP Group) (once elected, it broadcasts vIP:vMAC and mulitcasts HELLOs with own IP:vMAC)




RP CONFIGURATIONS


CTIVIATION

VERSION <Router(config-if)#standby version (1 | 2)> Up to 255 and 4095 group members respectively

NAME

<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 o

interface (can be the same for different VL

HSRP routers with the same group number shar

vMAC – that’s why the group number needs to b

the same on every HSRP node for a given vIP.

Otherwise, vIP will be associated with two differ

vMACs causing connectivity issues.

GROUP PRIORITY

<Router(config-if)#standby (group number ) priority (100, 0-255)> priority – the router with the highest prior

becomes the ACTIVE router for the group

The group number must be unique on a segmen

each vIP.

If all routers share the same priority, then the on

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 the

default gateway.




NING

PREEMPTION

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

assume the ACTIVE role at any time (normally, it

to wait for the current ACTIVE router to fail).

minimum – forces the router to wait for a

configured period before attempting to

overthrow the active router with lower pri

this delay beings as soon as the router is

capable of assuming the active role

reload – forces the router to wait after it h

been reloaded or restarted

TRACKING

<Router(config-if)#standby (group number ) track (interface) ( priority decrement; 10, 1-255)>

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

TIMERS

<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.)>

HSRP Routers configure their timers according to

values advertised by the ACTIVE router. Based o

them, the STANDBY router monitors the ACTIVE

router and the LISTEN routers monitor the STAN

router.

If x3 HELLOs are missed OR the HOLD timer expi

STANDBY ACTIVE

LISTEN STANDBY




AUTHENTICATION

o

PLAIN-TEXT <Router(config-if)#standby (group) authentication (string)>

o MD5

<Router(config-if)#standby (group) authentication md5 key-string (0 | 7) (string; 64 characters)>

OR

<Router(config)#key chain (chain name)

<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)>

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

the standby groups on that interface.

LOAD BALACING

EXAMPLE:

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




RP VERIFICATION AND TSHOOTING

show standby

show standby brief

show standby neighbors

debug standby (errors | events | packets)


show standby

HSRP Group settings

ACTIVE – STANDBY routers

vIP / vMAC

show standby brief

Summarized HSRP configurations

show standby neighbors

HSRP Neighbours relate info

debug standby (errors | events | packets) Debugs events associated with HSRP




RRP

VERVIEW

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




RRP CONFIGURATIONS


CTIVATION

DESCRIPTION <Router(config-if)#vrrp (group number; 1-254) description (group name; 80 char max.)>

GROUP PRIORITY

<Router(config-if)#vrrp (group number ) priority (100, 1-254)>

*NOTE: when the current Master fails, it advertises priority = 0 forcing the election process

priority – the router with the highest priority

becomes the master router for the group

If all routers share the same priority, then th

with highest IP address on the VRRP interfac

becomes the active.

vIP

<Router(config-if)#vrrp (group number ) ip (ip address)> Clients should point to this virtual address as

default gateway.

MAC: 0000.5e00.01xx (group number)

NING

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

TRACKING<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)>

TIMERS

<Router(config-if)#vrrp (group number ) timers advertise (msec (hello; 50-999)) (hello; 1-255)>

<Router(config-if)#vrrp (group number ) timers learn>

*issues with learning msec!

advertise – advertise timers to the BAC

learn – learn timers from the MASTER

Down interval = 3 * HELLO + SKEW

SKEW = (256 – local priority ) / 256




AUTHENTICATION

o

PLAIN-TEXT <Router(config-if)#vrrp (group number ) authentication (string)>

o MD5

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

OR

<Router(config)#key chain (chain name)



<Router(config-if)#vrrp (group name) authentication md5 key-chain (chain name)>

If the key string in a message matches the ke

configured on a VRRP peer, the message is

accepted.

If the group is omitted, the password is appl

to all the standby groups on that interface.




BP

VERVIEW

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

the router in the group with the highest configured priority OR highest IP address

o

manages the load balancing and responds to ARPs send on the vIP

o

assigns vMAC addresses to itself and AVFs

o

listens to all ARP request on a given subnet and responds with a vMAC using one of the load balancing algorithms

o

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

OAD BALANCING ALGORITHMS

weighted – based on the preconfigured value of weighting (the gateway’s 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




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 Indicates that the gateway is next in line to be the ACTIVE AVG

ACTIVE 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)




BP CONFIGURATIONS

CTIVIATION


*NAME <Router(config-if)#glbp (group number ; 0-1023) name (group name)>

PRIORITY <Router(config-if)#glbp (group number ) priority (100, 1-255)>Determines what router will become the AVG

the group.

VIRTUAL IP <Router(config-if)#glbp (group number ) ip ( A.A.A.A)>One virtual IP per VLAN.

Needs to be explicitly configured only on AVG

NING

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)>

WEIGHTINING <Router(config-if)#glbp (group number ) weighting (100, 1-254) (lower (1-99) upper (1-100))>

Determines what routers will become the AV

for the group.

If the value drops below the lower threshold

goes beyond the upper one, the AVF can / ca

function as an AVF.

If weighted load balancing is used, this value

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)>

ip routing – interface routing capabiliti

(routing enabled, IP address present,

interface is UP)

TIMERS

<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.)>

<Router(config-if)#standby (group number ) timers redirect (600, 0-3600 sec.) (timeout ; 14400, 622-64600 sec.)>

The AVG will advertise its timer values to the

AVFs.




AUTHENTICATION

o

PLAIN-TEXT <Router(config-if)# glbp (group number ) authentication (string)>

o MD5

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

OR

<Router(config)#key chain (chain name)>



<Router(config-if)# glbp (group number ) authentication md5 key-chain (chain name)>

If the key string in a message matches the k

configured on an HSRP peer, the message is

accepted.

If the group is omitted, the password is app

to all the standby groups on that interface.




show glbp brief

debug glbp Debugs events associated with GLBP



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/



http://packetlife.net/users/stretch/




desirable Enable PAgP unconditionally

on Enable Etherchannel only

passive 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 theshow 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 use, minimum links not met

u - unsuitable for bundling

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(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 1 00:45:50.647: %LINK-3-UPDOWN: Interface FastEthernet0/14, changed state to up



*Mar 1 00:45:53.487: %LINK-3-UPDOWN: Interface Port-channel1, changed state to 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

i bl f b dli






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 1 00:56:12.287: %LINK-3-UPDOWN: Interface Port-channel1, changed state to up



In the Campus Network High Availability Design Guide, Cisco recommend forgoing the use of a negotiation protocol andconfiguring 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





http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/HA_campus_DG/hacampusdg.html#wp1108396



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


http://packetlife.net/blog/category/switching/

http://packetlife.net/blog/2009/dec/10/etherchannel-costs-and-failover/



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 Forward Delay 15 sec

Bridge ID 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 Role Sts Cost Prio.Nbr Type

------------------- ---- --- --------- -------- --------------------------------

Fa0/1 Desg FWD 19 128.1 P2p




Fa0/19 Desg FWD 19 128.19 P2p Peer(STP)



Po13 Desg FWD 9 128 65 P2p


http://packetlife.net/blog/2008/sep/5/spanning-tree-port-costs/

http://www.cisco.com/en/US/docs/switches/lan/catalyst3550/software/release/12.2_44_se/configuration/guide/swethchl.html





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:


...


------------------- ---- --- --------- -------- --------------------------------

...

Po23 Altn BLK 9 128.65 P2p

Po12 Root FWD 12 128.66 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:


...


------------------- ---- --- --------- -------- --------------------------------

...

Po23 Root FWD 9 128.65 P2p

Po12 Altn BLK 19 128.66 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






!


no switchport

no ip address

channel-group 12 mode active

!


no switchport

no ip addresschannel-group 12 mode active

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 IP Address/Mask Cost State Nbrs F/C

Lo0 1 0 10.0.0.1/32 1 P2P 0/0

Po12 1 0 10.0.12.1/24 1 BDR 1/1

Po13 1 0 10.0.13.1/24 1 BDR 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 routers.

S1(config-router)# ^Z

S1# show ip ospf interface brief

Interface PID Area IP Address/Mask Cost State Nbrs F/C

Lo0 1 0 10.0.0.1/32 1 P2P 0/0

Po12 1 0 10.0.12.1/24 333 BDR 1/1

Po13 1 0 10.0.13.1/24 333 BDR 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):




d f 10 0 12 1 h l12 00 00 02












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 to1000 (for a total path cost of 1001). This cost is high enough to now favor the alternate route with a cost of 667:




Last update from 10.0.23.3 on Port-channel23, 00:00:49 ago




Finally, some higher-end platforms such as the Catalyst 6500 series support the port-channel min-link command, which forces anEtherhchannel to a down state if it has fewer than the specified number of member links.

Posted in Design


http://packetlife.net/blog/category/design/

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/channel.html#wp1047602



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/



http://packetlife.net/captures/DTP.cap

http://en.wikipedia.org/wiki/VTP

http://en.wikipedia.org/wiki/Dynamic_Trunking_Protocol





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/category/security/



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 Mode Encapsulation Status Native vlan

Gi0/1 on 802.1q trunking 1

Port Vlans allowed on trunk

Gi0/1 1-4094

Port Vlans allowed and active in management domain

Gi0/1 1,10,20,30

Port Vlans in spanning tree forwarding state and not prunedGi0/1 1,10

Switch 2:


...

Port Vlans in spanning tree forwarding state and not pruned

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 thetrunk (VLAN 10 is absent from the last line of the output):


...


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:


...


Fa0/1 1 10

http://packetlife.net/blog/2008/jun/26/when-does-vlan-pruning-occur/




http://www.networking-forum.com/viewtopic.php?t=6868





Posted in Switching




packetlife.

by Jeremy Stretch v

I E E E

C i s c o

SPANNING TREE · PART 1

BPDU Format

Protocol ID 16

Spanning Tree Protocols

Algorithm

Legacy STP PVST

Defined By

Instances

Trunking

PVST+ RPVST+ MST

Legacy ST

802.1D-1998

1

N/A

Legacy ST

Cisco

Per VLAN

ISL

Legacy ST

Cisco

Per VLAN

802.1Q, ISL

Rapid ST

Cisco

Per VLAN

802.1Q, ISL

Rapid ST

802.1s,802.1Q-200

Configurable

802.1Q, ISL

RSTP

Rapid ST

802.1w,802.1D-2004

1

N/A

Spanning Tree Instance Comparison

STP

C

A B

All VLANs

x

RootPVST+

C

A B

VLAN 1

VLAN 10

VLAN 20

VLAN 30

xx xx

VLAN 1,10 Root VLAN 20,30 RootMST

C

A B

MSTI 0 (1, 1

MSTI 1 (20, x x

MSTI 0 Root MSTI 1 Root

Field Bits

Version 8

BPDU Type 8

Flags 8

Root ID 64

Root Path Cost 32

Bridge ID 64

Port ID 16

Message Age 16

Max Age 16

Hello Time 16

Forward Delay 16

Spanning Tree Specifications

802.1D-1998

PVSTISL PVST+ RPVST+

802.1w

802.1s

802.1D-2004

802.1Q-2003

802.1Q-1998

802.1Q-2005

Link Costs

4 Mbps 250

Bandwidth Cost

10 Mbps 100

16 Mbps 62

45 Mbps 39

100 Mbps 19

155 Mbps 14

622 Mbps 6

1 Gbps 4

10 Gbps 2

Default Timers

Hello

Forward Delay

Max Age

2s

15s

20s

Port States

Disabled

Discardin

Legacy ST Rapid ST

Blocking

Listening

Learning LearningForwarding Forwardi

IEEE 802.1D-1998 · Deprecated legacy STP standard

IEEE 802.1w · Introduced RSTP

IEEE 802.1D-2004 · Replaced legacy STP with RSTP

IEEE 802.1s · Introduced MST

IEEE 802.1Q-2003 · Added MST to 802.1Q

PVST · Per-VLAN implementation of legacy STP

PVST+ · Added 802.1Q trunking to PVST

RPVST+ · Per-VLAN implementation of RSTP

Port Roles

Root Root

Legacy ST Rapid ST

Designated Designat

BlockingAlternate

Backup

Spanning Tree Operation

Determine root bridgeThe bridge advertising the lowest bridge ID becomes the root bridge

Select root portEach bridge selects its primary port facing the root

Select designated portsOne designated port is selected per segment

Block ports with loopsAll non-root and non-desginated ports are blocked

1

2

3

4

IEEE 802.1Q-2005 · Most recent 802.1Q revision

20+ Gbps 1



packetlife.

by Jeremy Stretch v

SPANNING TREE · PART 2PVST+ and RPVST+ Configuration

spanning-tree mode {pvst | rapid-pvst}

! Bridge priorityspanning-tree vlan 1-4094 priority 32768

! Timers, in secondsspanning-tree vlan 1-4094 hello-time 2

spanning-tree vlan 1-4094 forward-time 15spanning-tree vlan 1-4094 max-age 20

! PVST+ Enhancementsspanning-tree backbonefastspanning-tree uplinkfast

! Interface attributesinterface FastEthernet0/1spanning-tree [vlan 1-4094] port-priority 128spanning-tree [vlan 1-4094] cost 19

! Manual link type specificationspanning-tree link-type {point-to-point | shared}

! Enables PortFast if running PVST+, or! designates an edge port under RPVST+spanning-tree portfast

! Spanning tree protectionspanning-tree guard {loop | root | none}

! Per-interface togglingspanning-tree bpduguard enablespanning-tree bpdufilter enable

Troubleshooting

show spanning-tree [summary | detail | root

show spanning-tree [interface | vlan]

MST Configuration

spanning-tree mode mst

! MST Configurationspanning-tree mst configurationname MyTreerevision 1

! Map VLANs to instancesinstance 1 vlan 20, 30instance 2 vlan 40, 50

! Bridge priority (per instance)spanning-tree mst 1 priority 32768

! Timers, in secondsspanning-tree mst hello-time 2spanning-tree mst forward-time 15spanning-tree mst max-age 20

! Maximum hops for BPDUsspanning-tree mst max-hops 20

! Interface attributesinterface FastEthernet0/1spanning-tree mst 1 port-priority 128spanning-tree mst 1 cost 19

Bridge ID Format

Pri Sys ID Ext MAC Address

4 12 48

System ID Extension12-bit value taken from VLAN number (IEEE 802.1t

Priority4-bit bridge priority (configurable from 0 to 61440 increments of 4096)

MAC Address48-bit unique identifier

Path Selection

1 Bridge with lowest root ID becomes the root

2

3

4

Prefer the neighbor with the lowest cost to root

Prefer the neighbor with the lowest bridge ID

Prefer the lowest sender port ID

Optional PVST+ Ehancements

PortFastEnables immediate transition into the forwarding st(designates edge ports under MST)

UplinkFastEnables switches to maintain backup paths to root

BackboneFastEnables immediate expiration of the Max Age timer the event of an indirect link failure

Spanning Tree Protection

Root GuardPrevents a port from becoming the root port

BPDU GuardError-disables a port if a BPDU is received

Loop GuardPrevents a blocked port from transitioning to listeniafter the Max Age timer has expired

BPDU FilterBlocks BPDUs on an interface (disables STP)

RSTP Link Types

Point-to-Point

Connects to exactly one other bridge (full duplex)SharedPotentially connects to multiple bridges (half duplex

EdgeConnects to a single host; designated by PortFast

show spanning-tree mst […]



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 interface f0/13

Port Security : Enabled

Port Status : Secure-down

Violation Mode : Shutdown

Aging Time : 0 mins

Aging Type : Absolute

SecureStatic Address Aging : Disabled

Maximum MAC Addresses : 1

Total MAC Addresses : 0

Configured MAC Addresses : 0

Sticky MAC Addresses : 0

Last Source Address:Vlan : 0000.0000.0000:0

Security Violation Count : 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 Status : Secure-up


Aging Time : 0 mins







Last Source Address:Vlan : 001b.d41b.a4d8:10


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/




http://www.cisco.com/en/US/docs/switches/lan/catalyst3550/software/release/12.2_44_se/configuration/guide/swtrafc.html#wp1038501





%PM-4-ERR_DISABLE: psecure-violation error detected on Fa0/13, putting Fa0/13 in err-disable st

%PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 0021.55

%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:



Port Status : Secure-shutdown


Aging Time : 0 mins







Last Source Address:Vlan : 0021.55c8.f13c:10


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.55




Violation Mode : Restrict

Aging Time : 0 minsAging Type : Absolute











Last Source Address:Vlan : 0021.55c8.f13c:10


Unfortunately, violating traffic will continue to trigger log notifications, and the violation counter will continue to increase, until the

violating host is dealt with.

Maximum MAC Addresses

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

spanning-tree portfast

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












Aging Time : 0 mins



Maximum MAC Addresses : 1Total MAC Addresses : 1





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 mode access

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

spanning-tree portfast

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






Aging Time : 5 mins

Aging Type : Inactivity






Last Source Address:Vlan : 001b d41b a4d8:10








After five minutes of inactivity, we can see that the address has been purged:





Aging Time : 5 mins

Aging Type : Inactivity








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



http://packetlife.net/blog/category/security/

http://packetlife.net/blog/2008/aug/6/simple-wired-8021x-lab/

http://packetlife.net/blog/2009/sep/14/errdisable-autorecovery/



packetlife.

by Jeremy Stretch v

IEEE 802.1X802.1X Header

Configuration

! Define a RADIUS serverradius-server host 10.0.0.100radius-server key MyRadiusKey! Configure 802.1X to authenticate via AAAaaa new-modelaaa authentication dot1x default group radius! Enable 802.1X authentication globallydot1x system-auth-control

Global Configuration

! Static access modeswitchport mode access

! Enable 802.1X authentication per portdot1x port-control auto! Configure host mode (single or multi)dot1x host-mode single-host! Configure maximum authentication attemptsdot1x max-reauth-req! Enable periodic reauthenticationdot1x reauthentication! Configure a guest VLANdot1x guest-vlan 123! Configure a restricted VLANdot1x auth-fail vlan 456dot1x auth-fail max-attempts 3

Interface Configuration

802.1X Packet Types EAP Codes

0 EAP Packet

1 EAPOL-Start

2 EAPOL-Logoff

3 EAPOL-Key

4 EAPOL-Encap-ASF-Alert

1 Request

2 Response

3 Success

4 Failure

Terminology

EAP Over LANs (EAPOL)EAP encapsulated by 802.1X for transport across LANs

Extensible Authentication Protocol (EAP)A flexible authentication framework defined in RFC 3748

Authentication ServerA backend server which authenticates the credentialsprovided by supplicants (for example, a RADIUS server)

Troubleshooting

show dot1x [statistics] [interface <interface>]

dot1x test eapol-capable [interface <interface>

dot1x re-authenticate interface <interface>

EAP Header

EAP Flow Chart

SupplicantThe device (client) attached to an access link that reque

authentication by the authenticatorAuthenticatorThe device that controls the status of a link; typically awired switch or wireless access point

Guest VLANFallback VLAN for clients not 802.1X-capable

Restricted VLANFallback VLAN for clients which fail authentication

Interface Defaults

Max Auth Requests 2

Reauthentication Off

Quiet Period 60s

Reauth Period 1hr

Server Timeout 30s

EAP Req/Resp Type

1 Identity

2 Notification

3 Nak

4 MD5 Challenge

Supplicant Timeout 30s

Tx Period 30s

5 One Time Passwo

6 Generic Token Ca

254 Expanded Types

255 Experimental

Port-Control Options

force-unauthorized

Always unauthorized; authentication attempts are ignor

force-authorized

Port will always remain in authorized state (default)

auto

Supplicants must authenticate to gain access

Identity Request

Identity Response

Challenge Request

Challenge Response

Success

Access Request

Access Challenge

Access Request

Access Accept

EAP RADIUS

Code Identifier Length Data

1 1 2

Version Type Length EAP

1 1 2

Supplicant Authenticator Authentication

Server



packetlife.FIRST HOP R EDUNDANCYProtocols

HSRP Configuration

interface FastEthernet0/0ip address 10.0.1.2 255.255.255.0standby version {1 | 2}standby 1 ip 10 0 1 1

Virtual Router Redundancy Protocol (VRRP)An open-standard alternative to Cisco's HSRP,

providing the same functionality

Hot Standby Router Protocol (HSRP)Provides default gateway redundancy using one activeand one standby router; standardized but licensed byCisco Systems

Gateway Load Balancing Protocol (GLBP)Supports arbitrary load balancing in addition toredundancy across gateways; Cisco proprietary

Attributes

HSRP

NoLoad Balancing

RFC 2281Standard

Transport

IPv6 Support

Default Hello

Default Priority

Multicast Group

UDP/1985

Yes

3 sec

100

224.0.0.2

VRRP

No

RFC 3768

IP/112

No

1 sec

100

224.0.0.18

GLBP

Yes

Cisco

UDP/322

Yes

3 sec

100

224.0.0.1

HSRP VRRP GLBP

Standby Active Listen

100 200 100

Backup Master

100 200 100

Backup

Speak · Gateway election in progress

HSRP/GLBP Interface States

Active · Active router/VG

Standby · Backup router/VG

AVF AVF

AVG

100 200 100

AVF

Advanced Switching Reference Manual Ver. 0.9

Documents

Transcript of Advanced Switching Reference Manual Ver. 0.9