Author Archives: Rich Bibby

About Rich Bibby

Rich is a Senior Network Engineer based in the UK, with a passion for all things Network Automation. Follow me on Twitter and GitHub

CCNP Study Notes – Traditonal Spanning Tree Protocol

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

CCNP Study Notes – Advanced Spanning Tree Protocol

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

CCNP Study Notes – Aggregating Switch Links

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


CCNP Study Notes – VLANs and Trunks

Static VLANs

Port-based membership.  End user devices are members of VLANs based on the physical switchport they are connected to, and are not aware of which VLAN they are in.  Ports are assigned to VLANs by an administrator and the port receives a Port VLAN ID (PVID) that links it to a VLAN number.  Switchports can be assigned to many different VLANs but no communication is possible between devices in different VLANs without a Layer 3 device to route packets or an external Layer 2 bridge device.

By default, all switchports are assigned to VLAN 1, type Ethernet with an MTU of 1500.  First a VLAN is created (by giving it a number) and then porrts are assigned to it.  Standard VLAN numbers are 1 to 1005, with 1 (default), 1002 – 1005 (reserved for legacy functions) created automatically.  Catalyst IOS switches can support extended range VLANs (1 – 4096) for compatability with IEEE 802.1Q.  Extended range is only enabled when the switch is configured for VTP transparent mode, as extended range VLANs are not stored in the VLAN database.

 

Create the VLAN:

Switch(config)# vlan vlan-num (creates the VLAN)

Switch(config-vlan)# name vlan-name (optional, if not used then the name is stored as VLAN XXX, where XXX is the numnber of the VLAN)

Switch(config)# no vlan vlan-num (deletes the VLAN)

 

Assign ports to the VLAN:

 

Switch(config)# interface type module/number

Switch(config-if)# switchport

Switch(config-if)# switchport mode access

Switch(config-if)# switchport access vlan vlan-num

 

On a L3 IOS switch, every port is configured for L3 operation by default so the switchport command is needed to make it L2

Verify the VLAN Config

Switch# show vlan

 

VLAN Name                             Status                Ports

—- ——————————– ——— ——————————-

1    default                                 active

500  Marketing                          active                Et0/1

1002 fddi-default                         act/unsup

1003 token-ring-default                act/unsup

1004 fddinet-default                    act/unsup

1005 trnet-default                       act/unsup

 

Dynamic VLANs

VLAN membership is based on the MAC address of the attached devices.  MAC addresses are assigned to a VLAN in a database on the VLAN Membership Policy Server (VMPS), by an administrator using a tool such as CiscoWorks.  More mobility for end users = more admin overhead.

 

VLAN Considerations

The number of VLANS depends on: traffic patterns, application types, workgroup segmentation and management requirements.  There should be a 1-to-1 correlation between a VLAN and an IP subnet.  VLANS should not extend beyond the Layer 2 domain of the Distribution switch, ie. not across the core in to another switch block.

 

End to End VLANs

AKA Campuswide VLANS – Span the entire switch fabric of a network, and are not reccomeded unless there is a good reason.  Each VLAN is available at each access layer of each switch block.  100% of traffic can cross the network core, so VLAN trunking has to be used to carry all VLAN’s between the Access and Distribution layer switches.

 

Local VLANs

20/80 rule is no common, ie 20% of traffic local and 80% is destined outside the VLAN.  Layer 3 functions can route inter-VLAN traffic intelligently, allowing maximum availability using multiple paths, scalabitlity and manageability.

 

VLAN Trunks

A switch port can support only one VLAN, although it can support multiple subnets.  A trunk link transports more than one VLAN through a single switch port – typically used to connect switch<–>switch or switch<–>router.  A trunk link is not assigned to a specific VLAN, but one, many or all active VLANS can be transported between switches on a single physical trunk link.  Separate inter-switch links can be used for each VLAN but it is much more efficient to use trunking instead of multiple single links.  Cisco supports trunking on fast and gigabit ethernet ports, and aggregated fast and gigabit etherchannels.

A switch needs to identify frames and their respective VLAN’s as they traverse a trunk link.  Each side of the link must be using the same method to “tag” frames with their user-defined VLAN ID.  The tagging process involves placing an identifier in the frame header, which is then examined as each frame passes through a swtich and is then removed.  The VLAN identifier is added back to the frame header if the frame is to be forwarded out over another turnk link, otherwise remains removed before the frame is forwarded out of an access port to its destination.  The sending and receiving hosts have no concept of VLAN’s. There are 2 methods for identifying VLAN’s:

Inter-Switch Link Protocol (ISL)

Cisco proprietary, encapsulates each frame between a 26 byte header and a 4 byte trailer.  The source VLAN is identified by a 15 bit VLAN ID field in the header, and the trailer contains a CRC value to ensure data integrity.  AKA double-tagging.  No longer supported on all Catalyst switch platforms.

IEEE 802.1Q Protocol

Standardized, allowing VLAN trunks to work between kit from different vendors.  Rather than encapsulating each frame with VLAN information, it is embedded within the frame.  AKA single tagging or internal tagging.  A 4 byte tag is added is added just after the source address field in the frame.  With 802.1Q there are “native” VLAN’s, and frames belonging to the native vlan are not tagged.

Note – 1518 bytes is the max ethernet frame size and tagging can cause frames to become too large.  Baby Giant frames (reported as ethernet errors or oversize frames) are frames that are only slightly bigger than the MTU.  For 802.1Q switches can comply with IEEE 802.3ac which extends the MTU to 1522 bytes.

Dynamic Trunking Protocol

Cisco proprietary protocol that allows devices to agree on the encapsulation method (dot1q / ISL) and whether to form a trunk or not.  DTP frames are sent out every 30 seconds to inform neighboring switch ports of the links mode.  The command switchport nonegotiate turns off DTP, so no negotiation takes place – useful if both end of a link are fixed as trunks.

 

VTP Configuration:

Switch(config)# interface type module/number

Switch(config-if)# switchport

Switch(config-if)# switchport trunk encapsulation {isl | dot1q | negotiate}

Switch(config-if)# switchport trunk native vlan vlan-id

Switch(config-if)# switchport trunk allowed vlan {vlan-list | all | {add | except | remove} vlan-list}

Switch(config-if)# switchport mode {trunk | dynamic | desirable | auto}

Switch ports must be in Layer 2 mode to support trunking, by using the switchport command.  negotiate is the default encapsulation, with ISL being favoured if both ends support both types.  For dot1q, you should specifiy the native VLAN also, default is 1. Also, by default, all active (defined + ports assigned) VLANs are allowed.

For the switchport mode command you can set the mode to any fo the following:

trunk – permanent trunk mode, if far end is set to trunk, dymanic desirable or dynamic auto then a trunk is formed.  It is best to set both ends to trunk, and set the encapsulation method if this is definitely required so no negotitaion takes place.

dynamic desirable (default) – port attempts to convert the link to a trunk.   If far end is set to trunk, dymanic desirable or dynamic auto then a trunk is formed.

dynamic auto- port can become a trunk if the far end requests it.  If far end is set to trunk or dymanic desirable then a trunk is formed.

To view the trunking status on a switch port use the show interface type mod/port trunk command

 

Troubleshooting VLAN’s and Trunks

A VLAN is nothing more than a logical network segment, so if a host in one location cannot access a host in another:

  • are both on the same IP subnet?
  • are both switch ports in the same VLAN?
  • check the path between the 2 hosts
  • is the VLAN carried along the path?
  • is the VLAN being trunked over any trunk links on the way?

To verify a VLAN config:

Switch# show vlan id vlan-id

Make sure the VLAN has an active status and is assigned to the correct ports

For Trunks to work, make sure the following are agreed at both ends:

  • Trunking mode
  • encapsulation method
  • Native VLAN (you can bring a trunk up with different native VLAN’s on each end but the switches will log errors about mismatches and it’s possible that traffic will not pass correctly between the 2 native VLAN’s
  • The native VLAN mismatch is discovered through the exchange of CDP messages.  Native VLAN is configured separately to the encapsulation type, so it is possible to have a native VLAN mismatch even with ISL – although this will be purely cosmetic and not cause a problem
  • Allowed VLAN’s – check that the VLAN in question is allowed over the trunk – all are by default

 

To check how a switch port is operating compared to how it is configured, issue:

Switch# show interface type mod/num switchport

for example the, administrative mode may be set to dynamic auto, yet the the operational mode is actually static access – this could mean that both ends are set to auto so neither request a trunk.  For more concise trunk info issue:

Switch# show interface type mod/num trunk

To see whether and how DTP is being used:

Switch# show dtp type mod/num

 

VLAN Trunkning Protocol

Used to manage VLAN’s amongst a group of switches spread over a campus network.  Using VTP trunk frames it manages addition, deletion, renaming of VLAN’s from a central point of control.  VTP is organised into management domains, or areas with common VLAN requirements, and a switch can belong to only one VTP domain.  VLAN information is not shared between switches in different VTP domains.

  • Server (default mode) – full control over VLAN creation/modification.  all VTP information is advertised to other switches in the domain, and all received VTP info is sync’d with the other switches.  Each VTP domain must have at least one server, and VLANs must be configured on only one server
  • Client – from a client, the administrator cannot create, change or delete any VLANs.  client switches listen to advertisements and then modify their VLAN config.  Advertisement are also relayed out of trunk links to other switches in the domain.
  • Transparent Mode – switches in this mode do not participate in VTP.  any VLAN config are local only to that switch.  for VTP version 1 the switches VTP domain name and version number must match those of other switches if it is to act as a relay, but version 2 will relay regardless.

 

VTP Advertisements

VTP advertisements (sent as multicast frames out of trunk ports) sent between switches, contain information about the management domain, VTP revision numbers, known VLAN’s (only 1 to 1005) and specific VLAN parameters.  Advertisements are non-secure by default, but a password can be added (secure mode), that must be configured on every switch to ensure that they all use identical encryption methods.

The revision number is incremented by the server when changes are made.  VTP Configuration Revision Numbers are used as an index to keep track of the most recent information.  This always starts at 0 and the last revision number that the switch heard is stored locally and then overwritten with the latest revision number when a new advertisement is received.  The revision number is stored in NVRAM and survives a reboot.

There are 2 ways to reset a switch’s VTP revision number back to 0 (to avoid problems with new switches trashing VTP domains with a higher revision number):

  • change the mode back to transparent, and then back to server
  • change the VTP domain name to something bogus and then back to the original again

Advertisements can originate as requests from a client on boot up, or from a server when changes have been made.  There are 3 advertisement forms:

  • Summary – sent by servers every 300 secs and whenever there is a change.  One or more subset advertisements will then follow
  • Subset – sent after a change occurs, listing the specific changes such as deleting a VLAN
  • Advertisement requests from clients – requested by switches for any VLAN information they may lack, such as after a reset when the VLAN database has been cleared

Catalyst switches in server mode store VLAN and VTP data in the flash file system (vlan.dat) so this information is retained after a reboot

 

VTP Configuration

By default a switch is in Server mode, with a NULL management domain, no password or secure mode.  If a VTP advertisement is heard on a trunk port the the switch learns the VTP domain name, VLAN’s, and the configuration revision  number/

Switch (config)# vtp domain domain-name

Switch (config)# vtp mode {server | client | transparent}

Switch (config)# vtp password password

Switch (config)# vtp version {1 | 2} (version 1 is default)

Switch # show vtp status – displays VTP parameters for a Management domain

Switch # show vtp counters – displays VTP messages and error counters

 

VTP Pruning

By default a trunk link transports traffic from all VLANs unless specific VLANs are removed from the trunk.  Pruning reduces unnecessary flooded traffic, so that broadcast and unknown unicast frames are forwarded over trunk link only if the switch on the receiving end has ports in that VLAN.  VTP pruning is an extension of VTP version 1, using an additional VTP message type.  When a switch has ports in a VLAN it advertises the fact to its connected switches, so they know whether to flood traffic from a VLAN or not.  VTP pruning disabled by default.  By default VLANs 2 to 1001 are eligible for pruning. VLAN 1 is never eligible.

Switch (config)# vtp pruning

If the above command is issued on a server then all other switches in the management domain will also enable pruning.  All general purpose VLANs are eligible for pruning on all trunk links by default.  To change the default list of pruning eligibility issue the following interface command:

Switch (config)# interface mod/num

Switch (config-if)# switchport trunk pruning vlan {{{add | except | remove} vlan-list} | none}

NB – even with pruning running, an instance of STP will still run for every VLAN that is allowed on a trunk, so to reduce the number of instances running you should manually “prune” un-needed VLANs from the trunk using the switchport trunk allowed vlan command.

 

Troubleshooting VTP

If a switch is not receiving updated information from a VTP server:

  • is it configured for transparent mode?
  • if it’s a client, is there actually a server? if not, make the client a server
  • the link toward the server may not be in trunking mode (show interface mod/num switchport)
  • VTP domain name matches the server?
  • VTP version is compatible with other switches in the domain?
  • VTP password matches? or isn’t being used?
  • show vtp status
  • show vtp counters
  • show vlan brief
  • show interface type mod/num switchport
  • show interface type mod/num pruning

CCNP Study Notes – Switch Port Configuration

Ethernet

Ethernet (10Mbps) – IEEE 802.3, 10mbps bandwidth between users, shared medium, both a collison domain and and a broadcast domain, CSMA/CD = half-duplex operation, more devices sharing the medium = more collisions = poor performance.  Ethernet switching allows full-duplex operation due to the fact that the switch dynamically allocates a dedicated 10Mbps to each port – this means that becasue collisions are not likely, devices can operate in full-duplex mode, which increases performance further as throughput is 10Mbps in both directions giving 20Mbps total throughput.  Cabling used is UTP 10Base-T, which is restricted to 100 metres end-to-end distance.

Fast Ethernet (100Mbps) –  IEEE.3u.  CSMS/CD and upper layer protocol operations are the same as with Ethernet.  Cabling can be UTP or Fibre:

100Base-TX – EIA/TIA Cat 5 UTP       – 2 pairs – 100m

100Base-T2 – EIA/TIA Cat 3,4,5 UTP – 2 pairs – 100m

100Base-T4 – EIA/TIA Cat 3,4,5 UTP – 4 pairs – 100m

100Base-FX – MM Fibre 62.5/125      – 1 pair –   400m half duplex  / 2000m full duplex

– SM Fibre                       – 1 pair –   10KM

Full-Duplex Fast Ethernet – 100Mbps in each direction giving 200Mbps total throughput, if devices at both ends of the link support it.  Fast Ethernet is also backwards compatible to 10Mbps, so if both ends of a link are set to aut-negotiate and one end is only cabpable of 10Mbps, then this will become then negotiated speed.  For auto-negiation to work, both ends of a link must be configured for it.  If duplex negotiation fails then a switchport always falls back to it’s default setting og half-duplex.  FEC (Fast Etherchannel) is the bundling together of up to 8 full-duplex fast ethernet links, giving 400Mbps – 1600Mbps duplex bandwidth.

Gigabit Ethernet – 1000Mbps, same 802.3 Ethernet frame format as 10 & 100, Physical layer has been modified to increase data speeds – the result is IEEE 802.3z.  Gigabit Ethernet port duplex is always set to full on Cisco switches, so dupplex auto-neg is not possible.  GEC (Gigabit EtherChannel) allows aggregation of 2 to 8 connectionsto give up to 16Gbps throughput.

10-Gigabit Ethernet – 10,000Mbps, IEEE 802.3ae, most 10Gbps cables are fibre, with the exception of Copper type CX4 with Infiniband connectors (up to 15 metres)

 

Switchport Error Conditions

By default Catalyst switches detects error conditions for every possible cause.  If an error is detected the port is put into state errdisable and is disabled.  To fine tune this behaviour and ensure that only certain causes can trigger a port being disabled use the following command from Global Config mode:

Switch(config)# [no] errdisable detect cause [all | cause-name]

To re-enable a port, issue a shut/no-shut command.  You can specifiy that ports will be automatically re-enabled (default after 300 Secs), with the following command:

Switch(config)#errdisbale recovery cause [all | cause-name]

Set the auto recovery timer:

Switch(config)# errdisable recovery interval seconds

 

Troubleshooting Port Connectivity

S4#sh interfaces e0/1

Ethernet0/1 is up, line protocol is up (connected)

Hardware is AmdP2, address is aabb.cc00.0410 (bia aabb.cc00.0410)

MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,

reliability 255/255, txload 1/255, rxload 1/255

 

1st up = Physical/Data Link Layer, if down then the link is disconnected for cann to be detected.

2nd up = Layer 2

 

Switch# show interface status (shows states for all switchports)

Switch# show interface status err-disabled (shows all switchports in the err-disabled state and the cause)

CCNP Study notes – Switch Operation

Layer 2 Switch Operation

An ethernet switch decides where to forward incoming frames based on the destination MAC address contained within the received frame. Using this method means that the ethernet media is no longer shared between all connected devices. A switch will not forward a frame unless it knows which switch port the destination MAC address is connected to. Each switch port is it’s own isolated Ethernet LAN segment. The switch isolates connected devices in the following ways:

  • collision domains are limited and made up of the switch port itself and either a single host or a connected hub
  • all devices can operate in full duplex mode
  • each device has dedicated bandwidth across the switching fabric to another switch port
  • “store and forward” = frames are checked for errors, if OK the frame is regenerated when forwarded or transmitted. Receive / Store & Inspect / Forward
  • broadcast traffic is limited to a volume threshold
  • intelligent filtering and forwarding becomes possible

MAC address / switch port mappings can either be statically configured via the CLI, or learned by the switch dynamically. To learn dynamically the switch checks the source MAC address of incoming frames and adds the MAC address, switch port and VLAN on which it arrived into a table (if it isn’t already in the table). The switch also checks the destination MAC address of the incoming frame, and then checks the table for a match to find the switchport and VLAN that the destination MAC is attached to. If there is a match, the frame is then forwarded out of the corresponding switch port. If there is no match then the frame is flooded out of all switch ports assigned to the source VLAN – known as unknown unicast flooding. A switch port will only listen and learn source MAC addresses if allowed to do so by STP (Spanning Tree Protocol), ie. the port is not in a blocking state.

Frames destined for broadcast or multicast MAC addresses are also flooded by the switch to all ports in the same VLAN as the port that the frame originated on.

 

Layer 2 Frame Forwarding Decision Process

RX ports —> Ingress Queue —> Inbound & Outbound Security ACL’s (TCAM) —> Egress Queues —>TX ports

—> Qos ACL’s Clasification & Policing (TCAM) —>

—> L2 Fowarding Table (CAM) —>

CAM Table – contains: MAC Address | Egress Port | VLAN

Incoming frames are placed into one of the receiving port’s Ingress queues. Each queue has a different priority or service level, allowing the ports to be configured so that important frames get priority treament and are processed and forwarded before less important frames.

Frames are pulled of the ingress queue to be processed and at this point the switch needs to work out where to forward the frame to, and also whether or not it should be forwarded and if it should, then how to forward it. In other words, the the switch asks itself where is this frame destined for? (destination MAC address), is it allowed to be forwarded there? (security ACL’s) if so how do I get it there? (Qos ACL’s, switch port, egress queue) . These decisions are made simultaneoulsy by separate elementrs of the switching hardware:

  • L2 Fowarding Table – The CAM (Content-Addressable Memory) table contains MAC Address | Egress Port | VLAN records and is searched using the destination MAC address as the key. If there’s a match, then the egress port and VLAN ID are read from the table. No match means the frame is marked for floooding out of every port in the VLAN.
  • Security ACL’s – The TCAM (Ternary Content-Addressable Memory) table stores ACL’s and a single look up will determine if a frame can be forwarded or not. Security ACL’s can use MAC address, protocol types (non IP), IP addresses layer 4 port numbers to match frames.
  • Qos ACL’s – As with security ACL’s, a single TCAM table look up can determine if Qos should be applied to frames. This will effect which egress queue a frame is placed into.

 

Multilayer Switch Operation

Multilayer switching is defined as the ability to forward frames based on layer 3 and 4 data contained in packets. The fact that the layer 3 and 4 encapsulations are contained in ethernet frames means that layer 2 switching happens at the same time. There are 2 types of MLS:

  • Route Caching – first generation technology, no longer used by Cisco Catalyst switches.
  • Topology Based – second generation, uses a database built from layer 3 routing information, that contains the entire network topology. The database is updated dynamically as the topolgoy changes. Longest match found = correct layer 3 destination. Also known as Cisco Express Forwarding (CEF). The routing process runnning on the switch downloads the current routing table database into the Forward Information Base (FIB) area of hardware.

 

Layer 3 Packet Forwarding Decision Process

RX ports —> Ingress Queue —> Inbound & Outbound Security ACL’s (TCAM) —> L3 Packet Rewrite —> Egress Queues —>TX ports

—> Qos ACL’s Clasification & Policing (TCAM) —>

—> L3 Fowarding Table (FIB) —>

—> L2 Fowarding Table (CAM) —>

 

FIB Table – contains: IP address | Next Hop IP address | Next Hop MAC address | Egress Port

Incoming packets are placed into one of the receiving port’s Ingress queues, and both the L2 and L3 destination addresses are checked. This means that the forwarding decision is based on two address tables, and the decision of how to forward is based on the Security and Qos access lists as with layer 2 switching. The L3 Fowarding Table is searched using the destination IP address as the key, the longest match (IP and netmask) is found which then results in the next hop IP address being obtained. The FIB also has a record of the next hop MAC address and VLAN ID.

The final step before the packet is placed in the appropriate egress queue is to to re-write the packet, because it has gone through a routing process so therefore the destination MAC address needs to be changed to the next hop MAC address, the source MAC address is changed to that of the switch, and the TTL value is decremented by one. Also both the layer 2 and layer 3 header checksums must be recalculated as the contents of the frame/packet have changed.

Some packets cannot be handled by CEF and have to be forwarded to the switch CPU for “procsess switching”. Example packet types are: ARP, IP packets needing a response from a router, IP broadcasts relayed as unicasts (DHCP, IP helper-address), routing protocol updates, CDP, IPX, packets to be NAT’ed or encrypted, Appletalk, DecNet etc.

 

Content Addressable Memory (CAM)

Used by all Catalyst switches for L2 switching. As a frame arrives into a switchport it’s source MAC address, port and VLAN ID are all recorded in the CAM table. One extra item recorded is a timestamp – if a MAC addreses is already recorded in the CAM table then only the time stamp is updated. Also if a device has moved and it’s MAC address is learned on a new switchport then the most recent port and timestamp is recorded, and the old entry removed from the table. Stale entries (by default >300 seconds old) are aged out and deleted from the table. If a MAC address is being learned on alternating switchports then the switch generates an error.

 

Add a static CAM table entry:

Switch(config)# mac address-table static mac-address vlan vlan-id interface type mod/num.

Change the aging time via the CLI:

Switch(config)# mac address-table aging-time seconds

View contents of the CAM table:

Switch# show mac address-table dynamic [address mac-address | interface type mod/num | vlan vlan-id ]

Check the size of the CAM table:

Switch# show mac address-table count (shows results per VLAN)

Clear an entry from the CAM table:

Switch# clear mac address-table dynamic [address mac-address | interface type mod/num | vlan vlan-id ]

 

Ternary Content Addressable Memory (TCAM)

An extension of the CAM table concept, with entries composed of Value, Mask and Result (VMR) combinations. Multilayer switches check for matching Access Control Entities (ACE’s) in ACL’s is done in hardaware – as opposed to routers where evaluating traffic against ACL’s can add latency to packets. TCAM allows a packet to be evaluated against an entire ACL in a single table lookup. Multiple TCAM’s allow this process to happen for both inbound and outbound traffic simultaneously. There are 2 components of TCAM:

 

  • Feature Manager (FM) – merges ACE’s into the TCAM table
  • Switching Database Manager (SMD) – configures/tunes the TCAM. On some switch models the TCAM can be partitioned (not on 45/6500 platform)

Review of CCNP SWITCH instructor led course

As part of my prep for the exam, I attended the Implementing Cisco IP Switched Networks training course in Manchester this week. The course was run by QA Training and delivered by an instructor from Fast Lane. The course follows the official Cisco curriculum and for the lab exercises the students work in pairs on actual Cisco switches and routers hosted at Fast Lane’s data centre in Berlin.

The course itself was very enjoyable, if a little hard going at times. There’s a lot of ground to cover in five days, but the instructor did a great job of delivering the content in a way that kept your interest and attention. Having said that, there’s only so many hours you can take of going round and round the intricacies of STP before your brain starts blocking data – boom boom!! See what I did there, fellow network geeks?

The instructor also did a fantastic job of coping with the fact that we had not one, not two, but THREE power cuts during the week!! It’s surprising how much you can cover with a whiteboard and marker pen when you have to, and this clearly demonstrated the fact that the instructor really knew his stuff! In fairness to QA, they did all they could to ensure the power cuts were as short as possible, and even threw in free lunches each day to apologise!

Overall, I’d have to say that I really enjoyed the course and definitely got a lot out of it. I feel much better prepared for the SWITCH exam than I did at the start of the week and I would definitely recommend QA as a training company. I certainly hope to use them again for the ROUTE course later this year.

Rich

Follow me on Twitter