Hierarchical Network Design

• predictable behavior
• low maintenance
• high availability
• recover from failure and topology changes in a pre-determined manner
• scale to support future expansion and upgrades
• design around traffic flows rather than a particular type of traffic
• keep end users at consistent distances from resources
• cisco approach enables designers to organize the network into distinct layers of devices
• access
• distribution
• core
• the resulting network is:
• efficient
• intelligent
• scalable
• easily managed
• access layer switches are aggregated at the distribution switch layer
• distribution layer switches are aggregated as the core switch layer

Access Layer:

• end users connected
• low cost per switch port
• high port density
• scalable uplinks to higher layers
• user access functions:
• VLAN membership
• traffic and protocol filtering
• QoS
• resiliency through multiple uplinks

Distribution Layer:

• interconnection between the campus network’s access and core layers
• aggregation of multiple access-layer devices
• high layer 3 throughput for packet handling
• security and policy-based connectivity functions through access lists or packet filters
• QoS
• scalable and resilient high-speed links to the core and access layer
• switches capable of handling the total volume of throughput from all connected devices
• high port density of high speed links to to support the collection of access layer switches
• VLAN’s and broadcast domains converge at this layer and require routing, filtering and security
• usually a layer 3 boundary where routing meets the VLAN’s of the access layer

Core Layer:

• connectivity of all distribution layer devices
• AKA backbone
• needs to switch traffic as efficiently as possible
• very high throughput at layer 3
• no costly or unnecessary packet manipulations (ACL’s, filtering)
• Redundancy and resilience
• advanced QoS
• designed with simplicity and efficiency in mind

Switch Block:

• a group of access layer switches together with their distribution layer switches
• all switch blocks connect into the core block
• balanced mix of layer 2 and layer 3
• distribution layer shields the switch block from certain failures or conditions in other parts of the network.  eg.  broadcasts are not propagated from the switch block into the core and other switch blocks
• STP is confined to each switch block where a VLAN is bounded
• VLAN’s should not be extended beyond distribution switches
• the distribution layer should always be the boundary of VLAN’s, subnets and broadcasts
• VLAN traffic should not traverse the network core
• when sizing a switch block, consider:
• port density for access layer switches
• traffic types and patterns
• amount of layer 3 switching capacity at the distribution layer
• number of users connected to access layer switches
• geographic boundaries of of subnets or VLAN’s
• size of spanning tree domains
• usually no more than 2000 users should be placed within a single switch block, although sizing should be based primarily on:
• traffic types and behaviour
• size and number of common workgroups
• a switch block is too large if:
• the routers (MLS’s) at the distribution layer become traffic bottlenecks, possibly due to high volumes of inter VLAN traffic, intensive CPU processing or switching times required by policy or security functions
• broadcast or multicast traffic slows the switches in the block
• best practice is for all layer 2 connectivity to be contained within the access layer

Core Block:

• the campus network’s backbone
• required to connect 2 or more switch blocks in a campus network
• must be as efficient and resilient as possible as all traffic passing to and from all switch blocks must cross it
• carries more traffic than any other block
• links to/from the distribution layer can be L3 or L2 (using a small vlan bounded by the switches, and an SVI to provide routing)
• for sizing core switches, each one must be able to handle each of it incoming distribution links at 100% capacity

Collapsed Core:

• core is collapsed into distribution layer
• dist and core functions provide by the same switch devices
• used in smaller campus networks where a separate core is not warranted
• not an independent building block but integrated into the distribution layer of individual switch blocks
• each access layer switch has a redundant link to each dist/core layer switch
• all L3 subnets in the access layer terminate at the dist switches L3 ports
• dist/core switches connect to each other by one or more L3 links for redundancy/failover

Dual Core:

• connects 2 or more switch blocks in a redundant fashion
• independent from any other switch block
• 2 identical, redundant switches
• redundant links connect the distribution layer of a switch block to each of the dual core switches
• routing protocols plus provide equal cost load balancing between dist and core switches

 

InterVLAN Routing

• requires that routing be enabled for the layer 3 protocol – eg. IP Routing
• requires static routes or a dynamic routing protocol
• by default every port on most catalyst switch platforms is layer 2, and on 6500’s every port is layer 3 by default
• to determine the mode a switch port is in: Switch# show interface type mod/num switchport
• if the status is Switchport: Disabled then it’s layer 3
• to swap ports between layer 2 and 3: Switch# (config-if) [no] switchport
• an etherchannel can also become a layer 3 port
• to configure a Switched Virtual Interface (SVI):
• Switch(config)# vlan 100
• Switch(config-if)# ip address ip-address mask [secondary]
• Switch(config-if)# no shutdown

Multilayer Switching with CEF

• route once and switch many.  The Route Processor (RP) receives the first packet and a routing decision is made.  The Switching Engine (SE) then listens to see if it can switch the packet in both directions, and if so then subsequent packets can be switched directly to the destination port, bypassing the RP.
• AKA Netflow Switching or Route Cache Switching
• CEF has taken over from Netflow switching as it is more efficient, and runs by default in hardware
• The layer 3 engine maintains routing information, and the routing table is reformatted into a list with the most specific route first for each destination subnet – this is called the Forwarding Information Base
• the switch examines the FIB for the longest match (ie. most specific) destination route for a packet
• the FIB also contains the next hop address for each entry
• the FIB is dynamically updated upon changes to the routing table, or next hop addresses change or age-out of the ARP table

• display the FIB table: Switch# show ip cef [type mod/num | vlan vlan-id] [detail]
• packets that cannot be switched in hardware are marked as “CEF punt” and sent to the layer 3 engine.  some conditions can lead to this:
• no entry in FIB
• FIB table is full
• TTL expired
• MTU exceeded
• ICMP redirect is involved
• encapsulation type is not supported
• packets are tunneled and require encryption or compression
• an ACL with a log option is triggered
• NAT’ing is taking place
• aCEF (accelerated) is where CEF is multiple layer 3 forwarding engines, but only subsection of the FIB table is known each engine
• dCEF (disrtibuted) is as aCEF but with the whole FIB table on each engine
• the Adjacency Table is the list of IP to MAC mappings for every next hop entry in the FIB table.  view details with:
• Switch# show adjacency [type mod/num | vlan vlan-id ] [summary | detail]
• Packet Re-write – After finding valid FIB and adjacency table entries the switch must re-write the packet header before it can be forward the packet.   This is done in real time by the re-write packet engine.  The following changes are made:
• L2 dest address – changed to next-hop MAC
• L2 src address – changed to out bound L3 switch interface’s MAC
• L3 IP TTL – decremented by 1
• L3 IP checksum – recalculated due to changes to the IP header
• L2 frame checksum – recalculated due to changes to the L2 and L3 headers
• CEF is enabled by default on all CEF capable switches
• disable CEF on 3750 series interface: no ip route-cache cef
• disable CEF on 4500 series interface: no ip cef
• verify CEF: show ip cef

Using DHCP with a multilayer switch

• configuring an IOS DHCP server
• switch(config)# ip dhcp excluded- address start-ip and ip
• switch(config)# ip dhcp pool pool-name
• switch(config-dhcp)# network ip-address subnet-mask
• switch(config-dhcp)#  default-router ip address [ip-address2] [ip-address3]
• switch(config-dhcp)# lease {infinite | {days [hours [minutes]]}}
• switch(config-dhcp)# exit
• check leases with: show ip dhcp binding
• configuring a DHCP relay
• switch(config)# interface vlan 5
• switch(config-if)# ip address 192.168.1.1 255.255.255.0
• switch(config-if)# ip helper-address 192.168.199.4
• switch(config-if)# exit

Protecting The Spanning Tree Protocol Topology

 

There are 2 conditions that can occur to disrupt the loop free topology even when STP is running:

1. BPDU’s suddenly being received on a port that shouldn’t be receiving them – can result in unexpected re-convergence results
2. BPDU’s suddenly stop being received on a port that should be receiving them – a switch can then make incorrect assumptions about the topology and unintentionally create loops

Protecting against unexpected BPDU’s

 

Root Guard

• protects against a rogue switch connecting to the network and becoming the root bridge
• controls where candidate root bridges can be connected and found on a netwok
• if superior BPDU’s are received on a switch port with Root Guard enabled, the local switch will not allow the new switch to become the root
• puts the port in the root-inconsistent STP state while superior BPDU’s are being received, meaning no data can be sent or received on that port, but the port can listen to BPDU’s received to detect a new root advertising itself
• a root guard protected port can only forward or relay BPDU’s, it cannot be used to receive them
• prevents a port from ever becoming a root port
• is disabled by default, and is enabled only on a per port basis with the command: Switch(config-if)# spanning-tree guard root
• port goes back to it’s normal state after it stops receiving superior BPDU’s
• show ports in the state of root-inconsistent  by issuing: Switch# show spanning-tree inconsistentports

BPDU Guard

• protects ports that PortFast enabled, to prevent loops forming if a switch was accidentally connected to a port that should only be used by a workstation
• should be enabled on all port that have PortFast enabled
• if any BPDU (superior to the current root or not) is received on a port running BPDU guard, the port is put into errdisable state
• disabled on all ports by default
• can be configured as a global default, meaning that all ports that have PortFast enabled will also have BPDU Guard automatically enabled.  Command: Switch(config)# spanning-tree portfast bpdugaurd default
• can be enabled or disabled on a per port basis: Switch(config-if)# [no] spanning-tree bpduguard enable
• port remains in the errdisble state even after BPDU’s have stopped being received
• never enable on any switch uplink where the root bridge is located, as a switch with multiple uplinks may receive BPDU’s on any of those ports

Protecting against sudden loss of BPDU’s

 

Loop Guard

• blocking port + BPDU’s stop being received + last received BPDU ages out = port starts forward + bridging loop occurs
• loop guard keeps track of BPDU activity on non-designated ports
• moves port to loop-inconsistent state when BDPU’d stop being received, which effectively puts the port in the blocking state
• port is allowed to move through the normal STP states when BPDU’s start being received again (automatically)
• disabled by default on all switch ports
• enable as a global default: Switch(config)# spanning-tree loopguard default
• enable or disable per port:  Switch(config-if)# [no] spanning-tree guard loop
• although configured on a port the loop guard corrective action is limited only to the VLAN affected, it doesn’t block the entire port
• you can enable on all switch ports and the switch will figure out which ports are non-designated (usually alternative root ports and blocking ports)

UDLD (Unidirectional Link Detection)

• if a switch link becomes uni-directional perhaps due to faulty hardware in a GBIC of SFP, then this can cause a bridging loop as BPSU’d may not be received at on end of the link 
• Cisco only
• monitors ports to see if a link is truly bidirectional
• switch sends layer 2 UDLD frames identifying its switch port at regular intervals, and UDLD expects the frame to be echoed back with the far end switch port’s identification addded.  if received, all is OK, but if the echoed frames are not seen then the link must be unidirectional
• message interval is configurable, and the default is 15 seconds
• aim is to detect before STP has time to move a blocked port into a forwarding state
• 2 modes of operation:
• normal – action is to mark the port as having an undetermined state and generate a syslog message
• aggressive – switch takes action to re-establish the link by sending out UDLD frames once a second for 8 seconds, if no echo fame received back then the port is moved to errdisable state
• configured on a per port basis, although can be enabled globally for all fibre optic switch ports
• disabled by default
• to enable globally: Switch(config)# udld {enable | aggressive | message time seconds}
• enable or disable per port:  Switch(config-if)# udld {enable | aggressive | disable}
• can be safely enabled on all switch ports as UDLD is only enabled globally on fibre optic ports because copper/twisted pair connections do not have the physical layer conditions that allow unidirectional links to occur
• UDLD operates on each link of an etherchannel indpendently

Using BPDU Filtering to diable STP on a port

• used in special cases where you want to prevent BPDU’s from being sent or processed on one or more ports
• disabled on all switch ports by default
• configure as a global default for all ports: Switch(config)# spanning-tree portfast bpdufilter default
• enable or disable per port:  Switch(config-if)# spanning-tree bpdufilter {enable | disable}
• only enable on ports where a single host is connected making loops impossible

STP Root Bridge

 

Root bridge location should be determined as part of the design process.  Adjustments to the STP configuration can be made for things like using redundant links to load balance in parrallel, or configuring STP to converge quickly and predictably if a major topology change occurs.

 

note – if STP has been disabled for any reason, enable it by issuing the following commands:

 

Switch(config)# spanning-tree vlan vlan-id

Switch(config-if)# spanning-tree vlan vlan-id  (use if disabled for a specific VLAN on a specific port)

 

Root Bridge Placement considerations:

• switch speed – default settings may result in the slowest switch becoming root and having to handle a lot of traffic
• redundancy – default settings may result in a switch that isn’t ideal for the job becoming the root
• location – default settings may result in a switch in a distant location from a large section of the network becoming root, meaning a lot of traffic having too go the long  way round to pass through the root

Root Bridge Configuration – to prevent surpirises

• always configure one switch as the root bridge in a determined fashion
• always configure one switch as secondary root bridge in case the primary fails

Generally the root bridge should always be placed near the centre of a layer 2 network.  eg.  a distribution layer switch is a better choice than an access layer switch, and a switch near to a server farm is a good choice as in both cases they would be expected to handle most traffic.

 

There are two ways to manually configure a switch as a root bridge:

• manually set the bridge priority to a low value, so it wins the election.  Make sure that the bridge priority value of the other is higher.
• Switch(config)# spanning-tree vlan vlan-list prority bridge piority
• causing the would be root bridge to choose it’s own priority based on assumptions about other switched in the network
• Switch(config)# spanning-tree vlan vlan-id root {primary | secondary | diameter diameter}

Spanning Tree Customization

 

Tuning the root path cost – this can be modified from the default value, using the following command:

 

Switch(config-if)# spanning-tree [vlan vlan-id] cost cost   (cost can be 1-65535)

 

To view the port cost of an interface:

 

Switch# show spanning-tree interface type mod/num  [cost]

 

Tuning the port ID – a switch port number is fixed, but it port ID can be changed using the port priority:

 

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

 

Tuning Spanning Tree Convergence

 

Manually Modifying STP Timers

 

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

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

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

 

Automatically Configuring STP timers

 

Switch(config)# spanning-tree vlan vlan-list root {primary | secondary} [diameter diameter [hello-time hello-time]]

 

The above command adjusts STP timers according to the forumlas specified in 802.1D standard, by only giving the network’s diameter (max number of switches that layer 2 traffic will traverse)., an dan optional hello time.

 

Redundant Link Convergence

 

PortFast

• enables fast connectivity to be established on access-layer switch ports to workstations that are booting
• if not configured then delay will be 30 seconds from a port coming up before it is in forwarding mode (15 secs listening to learning + 15 secs learning to forwarding)
• on ports that only connect to workstations or single devices, bridging loops should never be possible
• portfast shortens the listening and learning states to a negligible amount of time, meaning the port immediately moves to the forwarding state
• STP loop detection is still in place though, meaning the port will be put in the blocking state if a loop is detected
• disabled by default
• can be configured as a global default, meaning that all ports that are configured for access mode (non trunking) will have portfast automatically enabled:
• Switch(config)# spanning-tree portfast default
• can be enabled or disabled on specific switch ports:
• Switch(config-if)# [no] spanning-tree portfast
• portfast = TCN BPDU’s are not sent when a switch port in portfast mode goes up or down
• to display the current portfast status:
• Switch# show spanning-tree interface type mod/num portfast

UplinkFast

• enables fast uplink failover on an access layer switch when dual uplinks are connected into the distribution layer
• gets rid of the up to 50 second delay that would occur if an access layer switch has redundant uplink connections to 2 distribution layers switches and one of the links fails
• enables switches at the ends of spanning-tree branches to have a functioning root port while keeping one or more redundant or potential root ports in blocking mode.  when the primary root port uplink fails, another port immediately is brought up for use
• Swtich(config)# spanning-tree uplinkfast [max-update-rate pkts-per-second]
• when enabled, it is for the whole switch and all VLAN’s
• keeps track of possible paths to the root bridge, so the command cannot be issued on the root bridge
• modifications are made to the local switch to ensure it doesn’t become the root bridge or a transit switch to the root bridge:
• bridge priority is raised to 49152
• port costs of all local switch ports raised by 3000
• the max-update-rate parameter allows the local switch to notify other upstream switches that stations downstream can be reached over the newly activated link.  this is done by sending the local switch sending dummy multicast frames to destination 0100.0ccd.cdcd on behalf of the stations contained in it’s MAC address table.  These frames are sent out a rate specified by this parameter, to control the amount of bandwidth used.
• display the current status of STP uplink fast:
• Switch# show spanning-tree uplinkfast

BackboneFast

• enables fast convergence in the network backbone or core layer switches after a spanning-tree topology change occurs
• a switch actively determines whether alternative paths exist to the root bridge, in case the switch detects an indirect link failure (a when a link that is not directly connected to a switch fails
• indirect link failures are detected when a switch receives inferior BPDU’s from it’s designated bridge on either it’s root port or a blocked port
• normally a switch must wait for the max-age timer to expire before responding to the inferior BPDU’s
• simple to configure
• short-circuits the max-age timer when needed
• can reduce the maximum convergence delay only from 50 to 30 seconds
• configure with the following command: Switch(config)# spanning-tree backbonefast
• should be enabled on all switches in the network because it requires the use of the RLQ request and reply mechanism
• disabled by default
• verify with the following command: Switch# show spanning-tree backbone fast

Overview

• defined in IEEE 802.1D.
• provides network link redundancy, so that a layer 2 switched network can recover from failures without intervention in a timely manner.
• solves the problem of bridging loops (forwarding a single frame around and around between two switches)
• enables switches to become aware of each other in order to negotiate a loop-free path through the network
• communicated among all connected switches
• algorithm executed based on info received from other switches
• switch calculates all the redundant paths to a reference point (Root Bridge)
• switch picks the best path to the root bridge, and then disables/blocks forwarding on the other paths
• computes a tree structure that spans all switches in a subnet or network
• STP algorithm is recalculated if a forwarding port fails or becomes disconnected, so another port can begin forwarding

Bridge Protocol Data Units (BPDU’s)

• BPDU frames sent out a port using the MAC address of the port itself as a source address
• frames sent to STP multicast MAC address 01-80-c2-00-00-00 as the switch is unaware of the other switches around it
• 2 types of BPDU
• configuration BPDU  – used for STP computation
• topology change notification (TCN) BPDU  – announces changes to the network topology
• sent out every switch port, every 2 seconds by default

Electing A Root Bridge

• election process takes place amongst all connected switches
• lowest bridge ID = Root Bridge
• Bridge ID consists of:
• bridge priority (2 bytes) – value can be 0-65535, default is 32768 (or 0x8000)
• MAC address (6 bytes – can come from the supervisor, backplane, or a pool of 1024 addresses that are assigned to every supervisor or back plane
• if switches have the same bridge priority then lowest MAC determines root bridge
• on boot up a switch assumes it is the root bridge
• each switch starts by sending out BPDU’s with the root bridge = it’s own bridge ID, and a sender bridge ID
• once elected only the RB can send out configuration BPDU’s, all other switches forward or relay them adding their own sender bridge ID’s
• switch learns of a better RB and then replaces it’s own RD ID with the one announced in the BPDU
• election is an on-going process, triggered by RB ID changes in BPDU’s every 2 seconds

Electing Root Ports

• each non-root switch must select one root port
• port with lowest root path cost wins
• root ports always point to the root bridge
• port is selected by calculating the root path cost , which is the cumulative cost of all the links leading to to the root bridge
• root path cost is modified as it travels along the links to give the cumulative cost
• higher bandwidth = lower cost

 

Link Bandwidth	STP Cost
4 Mbps	250
10 Mbps	100
16 Mbps	62
45 Mbps	39
100 Mbps	19
155 Mbps	14
622 Mbps	6
1 Gbps	4
10 Gbps	2

 

• root bridge send out BPDU with a root path cost of 0, because it’s ports are on the root bridge
• next closest neighbour receives BPDU, adds the path cost of it’s own port where the BPDU arrived, as the BPDU is received
• the neighbour sends out BPDU’s with new cumulative value as the root path cost
• root path cost is incremented by the ingress port path cost as the BPDU is received at each at each switch down the line
• new root path costs are calculated as the BPDU comes in to the switch, not as they go out
• after incrementing the root path cost, the switch also records the value in memory
• if BPDU’s come in on other ports, and the calculated root path cost is lower than that already in memory then the new value wins and this port becomes the root port

Electing Designated Ports

• each switch elects one designated port per network segment
• this port is the only one that forwards traffic to and from the segment
• decision based on lowest cumulative root path cost to the root bridge
• if switch receives a BPDU from a neighbour announcing a lower root path cost than it’s own then it assumes the neighbour has the designated port for that segment
• if a switch only receives BPDU’s on a port announcing a higher root path cost then it assumes that it has the designated port for that segment

 

Where there are ties in STP calculations, the following conditions are evaluated:

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

 

STP Timers – can be configured at the CLI, but only on the root bridge if required

 

Hello Time

• Interval between configuration BPDU’s sent by the root bride.
• non root switches use this as defined on the root bridge as they just relay BPDU’s sent by the root bridge
• all switches also have a locally configured hello time for timing of TCN BPDU’s
• default is 2 seconds

Forward Delay

• time that switch ports spend in both the listening and learning states
• default 15 seconds

Max Age

• time a switch stores a BPDU before discarding it
• each switch keeps a copy of the “best” BPDU it receives, and if it loses contact with the source of the BPDU it assumes a topology change must have occurred after the max age time elapsed, so the BPDU is aged out
• default 20 seconds

Topology Changes

• announced in TCN BPDU’s
• occurs when a switch either moves a port into the forwarding state, or from forwarding or learning to blocking (ie.  switch port up/down)
• TCN BPDU’d are sent out of the switches root port, so that ultimately the root bridge learns of the change
• contains no data about the change, only that there has been a change
• not sent if the port has been configured with Portfast enabled
• continually sent until acknowledgment from upstream switch is received
• root bridge receives the TCN BPDU then sends out updated configuration BPDU out to all other switches – done to signal the change but also causes the other switches to shorten their bridge table aging time from the default 300 seconds to the forward delay value (default 15 seconds), meaning the learned MAC addresses are flushed out much sooner than normal, avoiding bridge table curruption

• Direct Topology Changes – eg. a trunk link goes down
• Indirect Topology Change – links stay up but something in between as failed or is filtering traffic, so no data including BPDU’s is passing between the two switches
• Insignificant Topology Changes – eg. a PC is connected to a switch and it’s link goes up or down.  this will cause bridge tables to be flushed out and therefore more flooded frames as MAC’s are learned again.  Use Portfast on access ports to prevent this.

Types of Spanning Tree

• Common (CST)
• single instance of STP encompassing all VLAN’s
• 802.1Q based
• all CST BPDU’s are transmitted over trunk links using the native VLAN with untagged frames
• simple configuration, but has limitations such as redundant links being blocked with no capability for load balancing
• Per VLAN (PVST)
• cisco proprietary
• separate instance for each VLAN
• allows STP to be configured independently on each VLAN
• allows better performance and tuning
• makes load balancing possible over redundant links when the links are assigned to different VLAN’s
• as cisco proprietary it use ISL trunking encapsulation between switches
• Per VLAN Spanning Tree Plus (PVST+)
• cisco proprietary
• allows devices to interoperate with both PVST and CST
• operates over both 802.1Q and ISL trunks
• acts as a translator between groups of CST switches and groups of PVST switches

Rapid Spanning Tree Protocol

• IEEE 802.1D – original STP, topology change takes 30 seconds before port goes from blocking to forwarding
• IEEE 802.1w – RSTP, much faster convergence, as with STP can be applied as a single instance or multiple instances by using RSTP with Cisco’s own PVST+, resulting in Rapid PVST+.  Can also be used as part of IEEE 802.1s Multiple Spanning Tree (MST) operation.

RSTP Port Behavior

 

Root bridge election takes place as per STP, but then the following port roles are determined:

• root port – same as STP, one port per switch that has the best root path cost to the root
• designated port – switch port on a network segment that has the best root path cost to the root
• alternate port – port with an alternative path to the root, different to the path the root port takes, but less desirable eg.  an access layer switch with 2 uplink ports – 1 is root and the other alternate
• backup port – a port that provides a redundant but less desirable connection to a segment where another switch port already connects

RSTP defines the following port states, that can be applicable to any port:

• discarding – incoming frames are dropped, no MAC addresses are learned. combines all 802.1D’s disabled, blocking and listening states
• learning – incoming frames are dropped, but MAC addresses are learnt
• forwarding – incoming frames are forwarded according to MAC addresses learned and or being learned

BPDU’s in RSTP

• originate from the root bridge and are relayed by all switches down through the tree
• used the 802.1D BPDU format for backward compatability, but also makes use of some previously unused bits in the Message Type field
• BPDU version is also set to 2
• sent out every switch port at Hello Time intervals
• when 3 BPDU’s in a row are not received from a neighbour it is presumed to be down, which means a dead neighbour can be detected in 3 x the default Hello Time interval (3 x 2 Secs = 6 secs) as opposed to 802.1D’s Max Age Timer (default 20 secs)
• can co-exist with switches running STP as the BPDU’s are distinguished from 802.1D BPDU’s (version 0)

Rapid Spanning Tree Convergence

• convergence in STP is the process to get all switches from a state of independence to one of uniformity, with each switch knowing its place in the loop-free topology
• one common root bridge must be elected, and all switches must know about it
• the state of every switch port in the STP domain must be brought from a blocking state to the appropriate state to prevent loops
•  RSTP differs in that when a switch joins the topology it must base its forwarding decisions on the type of port

Port Types (every switch port can be considered one of the following types:

• edge port – at the edge of the network where only a single host connects.  RSTP keeps the traditional PortFast feature for familiarity, and will place the port immediately in the forwarding state unless a BPDU is received on it
• root port – has the best cost to the root of the STP instance.  only one root port can be selected and active at any one time.  if alternative paths are detected then these are identified as alternative root ports and can be placed immediately into the forwarding state when the existing root port fails
• point-to-point port – any port that connects to another switch and becomes a designated port.  proposal and agreement BPDU’s are exchanged in a quick handshake.  automatically determined by the duplex mode – full are point-to-point as only 2 switches can be present on the link, but half are considered to be on a shared medium so cannot be point-to-point

RSTP handles the complete STP convergence process as series of handshakes over point-to-point links

 

Synchronization

• a switch decides the state of each of it’s ports
• non-edge ports begin in the discarding state
• BPDU’s are exchanged and the root bridge can be identified
• if a switch receives a superior BPDU from it’s neighbour that port becomes the root port
• for non-edge ports a proposal-agreement handshake takes place to determine the state of each end of the link.  each switch assumes that it’s port should be the designated port for the segment and suggest this in a BPDU to the neighbour

Switch Port Aggregation with Etherchannel

 

2 to 8 links of 100mb, 1gb or 10gb can be bundled as one logical link of Fast Etherchannel (FEC), Gigabit Etherchannel (GEC), or 10 Gigabit Etherchannel (10 GEC) respectively, giving a full duplex bandwidth of up to 1600mbps, 16gbps or 160gbps.   There are no spanning tree issues as the links are bundled together as one logical link that can be either an access or trunk link.  Devices at either end of the etherchannel must speak “etherchannel” in order for the link to function correctly.

 

Traffic is distributed across the links in an etherchannel using a load-distribution algorithm, and each link can only operate at it’s maximum inherent speed (200mpbs for FE), so if one link in the bundle is favored by the algorithm then that link will carry a disproportionate amount of traffic.  Redundancy is also built in to etherchannel, so that if one of the links fails then traffic is automatically moved to an adjacent link (transparently to the end user), in less that a few milliseconds.  As links are restored then traffic is automatically distributed over the restored link.

 

bundled ports must:

• be of the same type, speed and duplex
• generally be in the same VLAN
• If used as a trunk then they must be in trunking mode, have the same native VLAN and pass the same set of VLANs.
• have the same spanning tree settings

Distributing Traffic in Etherchannel

 

Frames are forwarded over a specific link as the result of a hashing algorithm.  The algorithm can use the following to compute a binary pattern that selects a link number in the bundle to carry each frame:

• source IP
• destination IP
• combination of source and destination IP
• source and destination MAC address
• TCP/UDP port numbers

If only one address or a port number is hashed then a switch forwards each frame by using one or more of the low-order bits of the hash value as an index in to the bundled links.  If two addresses or port numbers are hashed then, a switch performs am exclusive-OR (XOR) operation on one or more lower order bits of the addresses or TCP/UDP port numbers as an index into the bundled links.

 

Eg. an etherchannel consisting of 2 links requires a 1-bit index.  If the index is 0, link 0 is selected; if the index is 1, link 1 is selected.  Either the lowest order address bit or the XOR of the last bit of the addresses in the frame is used as the index.  A four link bundle uses a hash of the last two bits, and an eight link bundle uses a hash of the last three bits.

 

Frame distribution on a two-link etherchannel using the source and destination IP:

 

Binary Address	Two-link Etherchannel XOR and Link Number
Addr1:…xxxxxxx0 Addr2:…xxxxxxx0	…xxxxxxx0: Use link 0
Addr1:…xxxxxxx0 Addr2:…xxxxxxx1	…xxxxxxx0: Use link 1
Addr1:…xxxxxxx1 Addr2:…xxxxxxx0	…xxxxxxx0: Use link 1
Addr1:…xxxxxxx1 Addr2:…xxxxxxx1	…xxxxxxx0: Use link 0

 

The XOR operation is performed independently on each bit position in the address value.  If the two addresses have the same bit value, the XOR result is always 0.  If the address bits differ then the result is always 1.

 

Example:  source: 192.168.1.1, destination: 172.31.67.46.  only the right-most (least significant) 3 bits are needed as an index.  In this case these are: 001 (1) and 110 (6) respectively.  For a 2 link EC a 1 bit XOR is performed on the right-most address bit: 1 XOR 0 = 1, meaning link 1 is used.  For a four link EC, a 2 bit XOR is performed: 01 XOR 10 = 11, meaning link 3 is used.  For an eight link EC, a 3 bit XOR is performed: 001 XOR 110 = 110, meaning link 7 is used.

 

Configuring Etherchannel Load Balancing

 

The hashing operation can be performed on either MAC or IP addresses and can be based solely on source or destination addresses, or both.  To set the frame distribution type for all etherchannel switch links:

 

Switch(config)# port-channel load-balance method

 

Types of etherchannel load-balancing methods

 

method Value	Hash Input	Hash Operation	Switch Model
src-ip	Source IP address	bits	All models
dst-ip	Destination IP address	bits	All models
src-dst-ip (default)	Source and destination IP address	XOR	All models
src-mac	Source MAC address	bits	All models
dst-mac	Destination MAC address	bits	All models
src-dst-mac	Source and destination MAC address	XOR	All models
src-port	Source port number	bits	6500, 4500
dst-port	Destination port number	bits	6500, 4500
src-dst-port	Source and destination port number	XOR	6500, 4500

 

To view the load balancing performance of an etherchannel, use the command show etherchannel port-channel, this shows each link and a Hex load value.

 

Etherchannel Negotiation Protocols

 

Port Aggregation Protocol (PAgP) – Cisco proprietary, and Link Aggregation Control Protocol (LACP), which is standards based.

 

Negotiation Mode		Negotiation Packets Sent	Characteristics
PAgP	LACP
On	On	No	All ports channeling
Auto	Passive	Yes	Waits to channel until asked
Desirable	Active	Yes	Actively asks to form a channel

 

Port Aggregation Protocol (PAgP)

 

Packets are exchanged between switches over etherchannel capable ports.  Neighbours are identified and port group capabilities are are learned and compared with ports on the local switch.  Ports with the same neighbour device ID, and port group capability are bundled together as a bidirectional point-to-point etherchannel link.  EC’s are formed only on ports that are configured for either identical static VLANs or trunking.  EC parameters are dynamically modified, eg. if the speed/duplex/configured VLAN of a port in a bundle is changed then PAgP reconfigures that parameter for all ports in the bundle.

 

Link Aggregation Control Protocol

 

Standards based alternative – IEEE 802.3ad, AKA IEEE 802.3 Clause 43, “Link Aggregation).  Operates the same as PAgP, but also assigns roles to the EC’s end points.  The switch withe lowest system prioirity (2 byte priority value followed by a 6 byte switch MAC address), is allowed to make decisions about what ports are actively participating in the EC at any given time.  Ports are selected and become active according to their port-priority value (a 2 byte priority followed by a 2 byte port number), where a low value indicates a higher priority.  A set of up to 16 potential links can be defined for each EC, and the switch will select up to 8 of these having the lowest port priorities as active EC links at any given time.  The other links are in standby until one of the active links goes down.

 

Etherchannel Configuaration

 

For each EC on a switch you must chose the negotiation protocol and assign the individual ports to it.  If you set the mode to ON, then neither PAgP or LACP packets are sent or received.  As ports are configured to be members of an EC, the switch automatically creates a logical port channel interface that represents the channel as a whole.

 

Configuring PAgP (the default)

 

Switch(config)# interface type mod/num

Switch(config-if)# channel-protocol pagp

Switch(config-if)# channel-group number mode {on | {{auto | desirable} [non-silent]}}

 

By default PAgP operates in silent sub-mode with the desirable and auto modes.  If you expect a PAgP capable switch to be on the far end then you should add the  non-silent keyword to the desirable or mode – this requires each port to receive PAgP packets before adding them to a channel.

 

Config example – EC with load balancing hash of source and destination port numbers, the switch actively negotiating, without waiting to listen for silent partners:

 

Switch(config)# port-channel load-balance src-dst-port

Switch(config)# interface range gig 3/1 – 4

Switch(config-if)# channel-protocol pagp

Switch(config-if)# channel-group 1 mode desirable non-silent

 

Configuring LACP

 

Switch(config)# lacp system-priority priority

Switch(config)# interface type mod/num

Switch(config-if)# channel-protocol lacp

Switch(config-if)# channel-group number mode {on | passive | active }

Switch(config-if)# lacp port-priority priority

 

system priority can be 1-65635 and should be defined first, default is 32,768) if both ends are the same then the switch with the lowest MAC address will be the ecision maker in the EC set up.  More interfaces than are allowed can be configured in the channel, and these will be in standby in case an interface fails.  Configure the active interfaces with a lower port priority (1-65635) using lacp port-priority, and a higher port priority for the standby interfaces.  IUf left to defaults then the lower numbered ports will be active.

 

Config example – EC with this switch as the decision maker (lower system priority), with some links set as standby by leaving their port priority as default and setting the active ports to 100:

 

Switch(config)# lacp system-priority 100

Switch(config)# interface range gig 2/1 – 4, gig 3/1 – 4

Switch(config-if)# channel-protocol lacp

Switch(config-if)# channel-group 1 mode active

Switch(config-if)# lacp port-priority 100

Switch(config-if)# exit

Switch(config)# interface range gig 2/5 – 8, gig 3/5 – 8

Switch(config-if)# channel-protocol lacp

Switch(config-if)# channel-group 1 mode active

 

Troubleshooting Etherchannel

• consistent configuration at both ends – access/trunk, speed/duplex, native VLAN etc
• EC on mode does not send or receive PAgP or LACP packets, so both ends must be set to on for a channel to form
• desirable (PAgP) and active (LACP) ask the far end to form a channel, so the far end must be set to either desirable or auto mode
• EC auto (PAgP) or passive (LACP) participates in a channel but only if the far end asks, therefore auto or passive at both ends = no channel
• PAgP desirable and auto modes default to silent sub-mode, in which no PAgP packets are expected from the far end.  If set to non silent mode then PAgP packets must be received before a channel will form
• show etherchannel summary – shows each ports status within the channel
• show etherchannel port – verify the negotiation mode and protocol
• show interface type mod/num etherchannel – shows all active etherchannel parameters for a port
• show etherchannel port-channel – time stamps of EC changes, and port index used by hashing algorithm
• show etherchannel detail – detailed status about each component
• show etherchannel load-balance – LB hashing algorithm
• show {pagp | lacp} neighbor – EC neighbours on each port
• show lacp sys-id – LACP system ID