Spanning Tree Protocol

The Spanning Tree Protocol was created by DEC (Digital Equipment Corporation) now Compaq. This is not compatible with the IEEE 802.1d version which Cisco use.

The Spanning Tree Protocol:

Prevents loops, loops cause broadcast storms
Allows redundant links
Resilient to topology changes
STA (Spanning Tree Algorithm) - Used to calculate loop-free path
BPDUs (Bridge Protocol Data Units) are sent and received by switches in the network every 2 seconds (default) to determine spanning tree topology.
Bridge Priority - Numerical value held by switches. All Catalyst switches are 32768
Bridge ID = MAC Address



Spanning Tree States
Blocking No frames forwarded, BPDUs heard
Listening No frames forwarded, listening for frames
Learning No frames forwarded, learning addresses
Forwarding Frames forwarded, learning addresses
Disabled No frames forwarded, no BPDUs heard



STA - Spanning Tree Algorithm
Spanning Tree Algorithm is used to calculate a loop-free path.

All switch ports are in blocking mode to begin with. It takes approx 30 seconds until packets can be forwarded.

Step 1 : Elect Root Bridge - Lowest bridge priority, if there is a tie then switch with lowest bridge ID
Step 2 : Elect Root Ports - Locate redundant paths to root bridge; block all but on root. Root Path Cost is cumulative cost of path to root bridge. Ports directly connected to Root Bridge will be root ports, otherwise lowest root path cost used.
Step 3 : Elect Designated Ports - Single port that sends and receives traffic from a switch to and from Root Bridge - Lowest cost path to Root Bridge.






Spanning Tree Overview
 There can only be one Root Bridge.
 Root-Bridge ports are called 'Designated' and are set to send and receive traffic (forwarding state). All other redundant links to the root bridge are shutdown.
 Blocked ports still receive BPDUs.
 Convergence occurs when switches have transitioned to either forwarding or blocking states. No other data is forwarded during this time.
 Forward delay - Time taken for a switch to go from Listening to Learning (50 seconds default).
 IEEE default priority = 32,768, this is true for all devices running STP IEEE version.
 Port Fast Mode - Immediately brings a port from blocking to forwarding state by eliminating forward delays.
 Bridges can only have one spanning tree instance compared to switches which can have many.
 Bridge Protocol Data Units send confirmation messages using multicast frames.

ONLINE LABS FOR BCMSN(CCNP)

To begin, click on one of the bulleted items below.Building Scalable Cisco Networks (BSCN)


Configuring an Access Switch


Configuring a Distrbution Switch



Backup Ethernet ASW1 to DSW2


Trunk Configuration


Activating and Limiting Trunking



Creating a VTP Domain


Verifying the VTP Domain



Testing the VTP Domain


Vlans to Access Switch Ports Verifying Spanning Tree-Acc. Switch



Configure Fast Ethernet Channel



Configuring Uplink Fast-Access Switch


Configuring the Route Processor



Configuring a Distribution Switch


Config MLS on Router & Switch I


Config MLS on Router & Switch II


Access Lists



HSRP and IP Multicast Routing



Creating a VTP Mngmnt Domain

Switching – EtherChannels (02)

Configuring EtherChannels:-

Configuring Port Channel Logical Interfaces for Layer 3 EtherChannels

When configuring Layer 2 EtherChannels, you cannot put Layer 2 LAN ports into manually created port channel logical interfaces. When configuring Layer 3 EtherChannels, you must manually create the port channel logical interface as described in this section, and then put the Layer 3 LAN ports into the channel group. To create a port channel interface for a Layer 3 EtherChannel, perform this task:


Creates the port channel interface.
Router(config)# interface port-channel group_number
Assigns an IP address and subnet mask to the EtherChannel.
Router(config-if)# ip address ip_address mask
Router(config-if)# end


Configuring Channel Groups
When configuring Layer 3 EtherChannels, you must manually create the port channel logical interface first and then put the Layer 3 LAN ports into the channel group. When configuring Layer 2 EtherChannels, configure the LAN ports with the channel-group command, which automatically creates the port channel logical interface. To configure channel groups, perform this task for each LAN port:


Selects a LAN port to configure

Router(config)# interface interface-id

(Optional) On the selected LAN port, restricts the channel-group command to the EtherChannel protocol configured with the channel-protocol command.
Router(config-if)# channel-protocol (lacp | pagp}
! Configures the LAN port in a port channel and specifies the mode
Router(config-if)# channel-group group_number mode {active | auto | desirable | on | passive}
! (Optional for LACP) Valid values are 1 through 65535. Higher numbers have lower priority. The default is 32768.
Router(config-if)# lacp port-priority priority_value
Router(config-if)# end
! Verifies the configuration.
Router# show interfaces interface-id etherchannel



Configuring the LACP System Priority and System ID
To configure the LACP system priority and system ID, perform this task:
! (Optional for LACP) Valid values are 1 through 65535. Higher numbers have lower priority. The default is 32768.
Router(config)# lacp system-priority priority_value
! Verify
Router# show lacp sys-id


Configuring EtherChannel Load Balancing
To configure EtherChannel load balancing, perform this task:
! Configures the EtherChannel load-balancing method. The method is globally applied to all port channels.
Router(config)# port-channel load-balance {src-mac | dst-mac | src-dst-mac | src-ip | dst-ip | src-dst-ip | src-port | dst-port | src-dst-port} [module slot]
Router(config)# end
! Verifies the configuration.
Router# show etherchannel load-balance



Configuring the EtherChannel Min-Links Feature
To configure the EtherChannel min-links feature, perform this task:
! Selects an LACP port channel interface.
Router(config)# interface port-channel group_number
! Configures the minimum number of member ports that must be in the link-up state and bundled in the EtherChannel for the port
! channel interface to transition to the link-up state.
Router(config-if)# port-channel min-links number
Router(config-if)# end
! Verifies the configuration.
Router# show interfaces interface-id etherchannel



Configuring LACP 1:1 Redundancy
To configure the LACP 1:1 redundancy feature, perform this task:
! Selects an LACP port channel interface.
Router(config)# interface port-channel group_number
! Enables the fast switchover feature for this EtherChannel.
Router(config-if)# lacp fast-switchover
! Sets the maximum number of active member ports to be one.
Router(config-if)# lacp max-bundle 1
Router(config-if)# end

VLAN Access Control Lists (VACLs)

Vlan Access Control List are often also referred to as VLAN Access Maps or just VLAN Maps

When you want to filter traffic that is moving from one VLAN to another, things are real CCNA-like and friendly :-) We use an Access Control List. In fact, we should elaborate on that term a bit now in light of this discussion. We actually use a Router-based Access Control List or RACL.

But what if we want to filter traffic that is flowing within a VLAN? On no, a Router-based Access Control List cannot help us! This is when we turn to the VLAN Access Control List. To help us understand this feature, let us create a topology and a sample scenario. Here is the simple topology:




Notice the Fast Ethernet interfaces of R1 and R2 are within the same VLAN (VLAN 10). So, based on the theory we have discussed, we will need a VACL if we want to filter the ability of R1 to communicate with R2. For this experiment, let us use Telnet. Before we begin, let me try Telnetting from R1 to R2. We want to ensure that works before we try and prevent that capability with a VACL.



R1#telnet 10.10.10.2
Trying 10.10.10.2 ... Open

User Access Verification

Password:

R2>quit

[Connection to 10.10.10.2 closed by foreign host]
R1#



Excellent, there is everything we need in place to test a VACL now. Let us be very specific and create a VACL that denies the ability of R1 to Telnet to R2. Notice, we want to be very specific. Can R1 ping R2 when we are done? Sure! That is, if we configure all of this correctly.

I begin the scenario configuration with an Access Control List that will define the exact traffic we are interested in preventing. Notice I am using a permit Access Control List Entry (ACE) to specify the traffic, but I will end up denying it later on in the VACL structure.

SW2(config)#ip access-list extended ACL_TELNETR1_R2
SW2(config-ext-nacl)#permit tcp host 10.10.10.1 host 10.10.10.2 eq 23

Now that we have configured the identifying access list, it is time to configure the VACL. The first step is to create the VLAN Access Map, and then the second step is to apply it to the appropriate VLAN(s). Notice how these structures are eerily similar to Route Maps. Here is step one:


SW2(config-ext-nacl)#vlan access-map VACL_STOPTELNET
SW2(config-access-map)#action drop
SW2(config-access-map)#match ip address ACL_TELNETR1_R2
SW2(config-access-map)#vlan access-map VACL_STOPTELNET
SW2(config-access-map)#action forward
SW2(config-access-map)#exit


Notice that the ACL that matches on the Telnet has an action of DROP, then we match on all other traffic (implicitly), and we forward all of that. Forward is the default action, so I actually did not need the action forward commands, but I added them above to make it more clear for us to learn.

Now for the really easy part of this configuration. In step two, all I need to do is apply this “map” to the appropriate VLAN. That is our VLAN 10:


SW2(config)#vlan filter VACL_STOPTELNET vlan-list10


Now it is time for verification. In our case it should be very simple to test. R1 should be able to ping R1, but Telnet should fail. First the ping:


R1#ping 10.10.10.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
!!!!!


That worked as expected. Now, drumroll please, it is time for the Telnet attempt. This is a time in the lab exam where you really hope for a failure:

R1#telnet 10.10.10.2
Trying 10.10.10.2 ...
% Connection timed out; remote host not responding