Tuesday 9 March 2010

Layer 2 Technologies - SPAN, RSPAN and 802.3x Flow Control

This should be the last blueprint topic specifically covering ethernet, and it is a relatively short one... (That's not to say that I wont need to come back and clarify or elaborate on this or the previously documented topics)

1.50    Implement Switched Port Analyzer (SPAN), Remote Switched Port Analyzer (RSPAN), and flow control
(a) SPAN and RSPAN
(b) Flow Control


SPAN and RSPAN

The Switch Port Analyser (SPAN) and Remote SPAN (RSPAN) functions are Well documented on CCO. SPAN is particularly handy for troubleshooting with packet analysis tools like Wireshark or for use with security appliances like an IDS to determine if your network is under attack.

A SPAN port is contained locally on a switch, while RSPAN is configured across multiple switches and delivered over a dedicated VLAN (intermediate transport switches do not have to be RSPAN capable unless they are interacting with the RSPAN VLAN)


While it is possible to have multiple sessions in operation, these are the basic rules around SPAN/RSPAN ports:
  •     For SPAN sources, you can monitor traffic for a single port or VLAN or a series or range of ports or VLANs for each session. You cannot mix source ports and source VLANs within a single SPAN session.
  •     The destination port cannot be a source port; a source port cannot be a destination port.
  •     You cannot have two SPAN sessions using the same destination port.
  •     When you configure a switch port as a SPAN destination port, it is no longer a normal switch port; only monitored traffic passes through the SPAN destination port
SPAN ports have the capability to include the source interface encapsulation headers if the "encapsulation replicate" configuration setting is included.  RSPAN transports monitored frames without the encapsulation headers

Flow Control

There is a very good article about Ethernet Flow Control by Petr Lapukhov The main take away is that Cisco switches do not generate PAUSE Frames (though they can receive them) the issue is in QoS enabled networks, the pausing frames is an indiscriminate action that can impact priority traffic as well as best effort.  Flow control is disabled by default and is not recommended for QoS enabled networks.

These are the impacts on flow control settings for an interface:

flowcontrol receive on (or flowcontrol receive desired) - The interface cannot send pause frames but can operate with an attached device that is required to or can send pause frames; the interface can receive pause frames.

flowcontrol receive off - Flow control does not operate in either direction. In case of congestion, no indication is given to the link partner, and no pause frames are sent or received by either device.

Layer 2 Technologies - Implement Ethernet

So far all of the Layer 2 technologies have been related to Ethernet and it's implementation of some kind (well I guess things like IRB and CRB can use alternate technologies)

1.40    Implement Ethernet technologies

(a) Speed and duplex

(b) Ethernet, Fast Ethernet, and Gigabit Ethernet

(c) PPP over Ethernet  (PPPoE)


Speed and Duplex

I guess this goes back to CSMA/CD roots with garden hose size coaxial cable (ThickNet) and vampire taps towards the more typical full-duplex things we see today.

The bus based network had everyone sitting on the same transmission medium (the MA part is multiple access).  When a station wanted to talk it needed to be sure no one else was talking before it tried to talk (CS as in carrier sense) since it is possible that someone started talking at the same time as you, you needed to listen and be sure you didn't hear something on the wire that was different to what you were transmitting (the something different was a collision - the CD is collision detect) if you detected that a collision occured, you would send out a Jam signal to ensure that the other transmitting station knew that there was a problem and you would both wait a random amount of time before trying to transmit again.  It wasnt the most efficient means, I think peak efficiency is somewhere around 50% of the link bandwidth but it was relatively cheap and allowed you to "easily" add hosts onto the network.  This kind of duplexing (capability for both transmit and recieving) is called half-duplex since only one station can talk at a time.

A full-duplex connection is a dedicated point-to-point connection with a dedicated line for transmission and reception meaning that collisions don't occur and you could potentially max the link in the transmit and receive directions.

Ethernet, Fast Ethernet, and Gigabit Ethernet

"Ethernet" interfaces can support 10Mbps and usually support full-duplex (some really old interfaces only do half-duplex)

"FastEthernet" interfaces can be configured to be 10Mbps or 100Mbps with either half or full duplex.

"GigabitEthernet" interfaces can be usually configured to be 10, 100 or 1000Mbps with either half or full duplex (however some GBIC or SFPs are capable of a single speed only)

Autonegotiation

The IEEE 802.3u standard which introduced FastEthernet allowed automatic negotiation of speed and duplex between endpoints.  If one side was hard set, with the other set for auto negotiate, it is possible to get a duplex mismatch if the hard set side was set for full-duplex (although auto negotiate can correctly select the speed for a hard set interface, it will assume half-duplex on the auto negotiate side)

Common practice used to be to not to use autonegotiation and hard set interface options, however recommendations these days are to have both sides be auto negotiate as items such as flow control can be appropriately negotiated and other keep alive mechanisms be used that would not otherwise be available.

PPPoE

A PPPoE configuration is relatively common in a situation where you have an Ethernet WAN device that is connected to an ADSL modem that is in a bridge configuration (the DSL mode bridges Ethernet Frames on to an ATM PVC which terminates on a BRAS/BNG of the ISP)

PPPoE has an 8 byte overhead so a typical 1500 Byte MTU interface will actually be 1492 bytes when using PPPoE (this may need to be considered if using a protocol such as OSPF)


PPPoE Client configuration example (CHAP Authentication of client, Obtain IP address from Server)

interface FastEthernet0/0
 description Ethernet WAN to PPPoE Server Fa0/0
 pppoe enable
 pppoe-client dial-pool-number 1
!
interface Dialer1
 ip address negotiated previous
 encapsulation ppp
 dialer pool 1
 dialer persistent
 ppp chap hostname client ppp chap password 0 pppoe
!

PPPoE Server configuration (CHAP Authentication of Client against the local database and address allocation using IPCP) Note: PPPoE no longer uses VPDN configuration, and while IOS will convert to PPPoE VPDN config to a bba-group config once, it's best to know how to do it correctly.

aaa new-model
aaa authentication ppp default local

username client password 0 pppoe

ip dhcp excluded-address 192.168.200.254
ip dhcp pool PPPoE
 network 192.168.200.0 255.255.255.0
!
bba-group pppoe global
 virtual-template 1
!
interface Virtual-Template1
 ip unnumbered FastEthernet0/0
 peer default ip address dhcp-pool PPPoE
 ppp authentication chap
!
interface FastEthernet0/0
 description Ethernet WAN to PPPoE Client Fa0/0
 ip address 192.168.200.254 255.255.255.0
 pppoe enable
!

Below is a debug ppp negotation and debug ppp authentication on the PPPoEServer as the client connects (interestingly, we see that CDP is not enabled across the connection)

*Mar  1 00:54:37.103: ppp7 PPP: Send Message[Dynamic Bind Response]
*Mar  1 00:54:37.103: ppp7 PPP: Using vpn set call direction
*Mar  1 00:54:37.107: ppp7 PPP: Treating connection as a callin
*Mar  1 00:54:37.107: ppp7 PPP: Session handle[3A000009] Session id[7]
*Mar  1 00:54:37.107: ppp7 PPP: Phase is ESTABLISHING, Passive Open
*Mar  1 00:54:37.107: ppp7 LCP: State is Listen
*Mar  1 00:54:37.187: ppp7 LCP: I CONFREQ [Listen] id 1 len 10
*Mar  1 00:54:37.191: ppp7 LCP:    MagicNumber 0x01448040 (0x050601448040)
*Mar  1 00:54:37.191: ppp7 PPP: Authorization NOT required
*Mar  1 00:54:37.195: ppp7 LCP: O CONFREQ [Listen] id 1 len 19
*Mar  1 00:54:37.199: ppp7 LCP:    MRU 1492 (0x010405D4)
*Mar  1 00:54:37.199: ppp7 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:54:37.199: ppp7 LCP:    MagicNumber 0x0044CEAE (0x05060044CEAE)
*Mar  1 00:54:37.199: ppp7 LCP: O CONFACK [Listen] id 1 len 10
*Mar  1 00:54:37.199: ppp7 LCP:    MagicNumber 0x01448040 (0x050601448040)
*Mar  1 00:54:37.211: ppp7 LCP: I CONFNAK [ACKsent] id 1 len 8
*Mar  1 00:54:37.215: ppp7 LCP:    MRU 1500 (0x010405DC)
*Mar  1 00:54:37.215: ppp7 LCP: O CONFREQ [ACKsent] id 2 len 19
*Mar  1 00:54:37.215: ppp7 LCP:    MRU 1500 (0x010405DC)
*Mar  1 00:54:37.215: ppp7 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:54:37.215: ppp7 LCP:    MagicNumber 0x0044CEAE (0x05060044CEAE)
*Mar  1 00:54:37.227: ppp7 LCP: I CONFACK [ACKsent] id 2 len 19
*Mar  1 00:54:37.227: ppp7 LCP:    MRU 1500 (0x010405DC)
*Mar  1 00:54:37.227: ppp7 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:54:37.227: ppp7 LCP:    MagicNumber 0x0044CEAE (0x05060044CEAE)
*Mar  1 00:54:37.227: ppp7 LCP: State is Open
*Mar  1 00:54:37.227: ppp7 PPP: Phase is AUTHENTICATING, by this end
*Mar  1 00:54:37.231: ppp7 CHAP: O CHALLENGE id 1 len 23 from "R1"
*Mar  1 00:54:37.239: ppp7 CHAP: I RESPONSE id 1 len 27 from "client"
*Mar  1 00:54:37.243: ppp7 PPP: Phase is FORWARDING, Attempting Forward
*Mar  1 00:54:37.247: ppp7 PPP: Phase is AUTHENTICATING, Unauthenticated User
*Mar  1 00:54:37.251: ppp7 PPP: Sent CHAP LOGIN Request
*Mar  1 00:54:37.255: ppp7 PPP: Received LOGIN Response PASS
*Mar  1 00:54:37.255: ppp7 PPP: Phase is FORWARDING, Attempting Forward
*Mar  1 00:54:37.259: ppp7 PPP: Send Message[Connect Local]
*Mar  1 00:54:37.279: ppp7 PPP: Bind to [Virtual-Access1.1]
*Mar  1 00:54:37.283: Vi1.1 PPP: Send Message[Static Bind Response]
*Mar  1 00:54:37.299: Vi1.1 PPP: Phase is AUTHENTICATING, Authenticated User
*Mar  1 00:54:37.299: Vi1.1 CHAP: O SUCCESS id 1 len 4
*Mar  1 00:54:37.307: Vi1.1 PPP: Phase is UP
*Mar  1 00:54:37.311: Vi1.1 IPCP: O CONFREQ [Closed] id 1 len 10
*Mar  1 00:54:37.315: Vi1.1 IPCP:    Address 192.168.200.254 (0x0306C0A8C8FE)
*Mar  1 00:54:37.319: Vi1.1 PPP: Process pending ncp packets
*Mar  1 00:54:37.371: Vi1.1 IPCP: I CONFREQ [REQsent] id 1 len 10
*Mar  1 00:54:37.371: Vi1.1 IPCP:    Address 0.0.0.0 (0x030600000000)
*Mar  1 00:54:37.383: Vi1.1 CDPCP: I CONFREQ [Not negotiated] id 1 len 4
*Mar  1 00:54:37.383: Vi1.1 LCP: O PROTREJ [Open] id 3 len 10 protocol CDPCP (0x820701010004)
*Mar  1 00:54:39.275: Vi1.1 IPCP: Timeout: State REQsent
*Mar  1 00:54:39.279: Vi1.1 IPCP: O CONFREQ [REQsent] id 2 len 10
*Mar  1 00:54:39.283: Vi1.1 IPCP:    Address 192.168.200.254 (0x0306C0A8C8FE)
*Mar  1 00:54:39.375: Vi1.1 IPCP: Pool returned 192.168.200.20
*Mar  1 00:54:39.379: Vi1.1 IPCP: O CONFNAK [REQsent] id 1 len 10
*Mar  1 00:54:39.379: Vi1.1 IPCP:    Address 192.168.200.20 (0x0306C0A8C814)
*Mar  1 00:54:39.383: Vi1.1 IPCP: I CONFACK [REQsent] id 1 len 10
*Mar  1 00:54:39.387: Vi1.1 IPCP:    Address 192.168.200.254 (0x0306C0A8C8FE)
*Mar  1 00:54:39.387: Vi1.1 IPCP: ID 1 didn't match 2, discarding packet
*Mar  1 00:54:39.391: Vi1.1 IPCP: I CONFACK [REQsent] id 2 len 10
*Mar  1 00:54:39.395: Vi1.1 IPCP:    Address 192.168.200.254 (0x0306C0A8C8FE)
*Mar  1 00:54:39.399: Vi1.1 IPCP: I CONFREQ [ACKrcvd] id 2 len 10
*Mar  1 00:54:39.399: Vi1.1 IPCP:    Address 0.0.0.0 (0x030600000000)
*Mar  1 00:54:39.399: Vi1.1 IPCP: O CONFNAK [ACKrcvd] id 2 len 10
*Mar  1 00:54:39.399: Vi1.1 IPCP:    Address 192.168.200.20 (0x0306C0A8C814)
*Mar  1 00:54:39.407: Vi1.1 IPCP: I CONFREQ [ACKrcvd] id 3 len 10
*Mar  1 00:54:39.407: Vi1.1 IPCP:    Address 192.168.200.20 (0x0306C0A8C814)
*Mar  1 00:54:39.407: Vi1.1 IPCP: O CONFACK [ACKrcvd] id 3 len 10
*Mar  1 00:54:39.407: Vi1.1 IPCP:    Address 192.168.200.20 (0x0306C0A8C814)
*Mar  1 00:54:39.411: Vi1.1 IPCP: State is Open
*Mar  1 00:54:39.431: Vi1.1 IPCP: Install route to 192.168.200.20


On the server, if we execute a show users, we can see the client is connected based on the CHAP user name, the VirtualAccess Interface it is terminated on and the assigned IP address

Server#sh users
    Line       User       Host(s)              Idle       Location
*  0 con 0                idle                 00:00:00

  Interface    User               Mode         Idle     Peer Address
  Vi1.1        client             PPPoE        -        192.168.200.20

Client# sh ip route connected
C    192.168.10.0/24 is directly connected, FastEthernet0/1
     192.168.200.0/32 is subnetted, 2 subnets
C       192.168.200.254 is directly connected, Dialer1
C       192.168.200.20 is directly connected, Dialer1

Layer 2 Technologies - Trunking and Etherchannels

1.00    Implement Layer 2 Technologies

1.30    Implement trunk and trunk protocols, EtherChannel, and load-balancing

a) DTP (Dynamic Trunking Protocol)

b) Etherchannels

c) Allowed VLAN

d)
Router on a Stick

e) Native VLAN

DTP

Dynamic Trunking Protocol (DTP) is a Cisco switch only (not supported on routers) protocol where a switch will attempt to automatically negotiate the capability to support VLAN trunking on an interface.  If DTP fails, the interface will remain in access rather than trunking mode.

For DTP negotiation to occur, both switches need to be in the same VTP domain.  By default interfaces are set for DTP operation (by an implied no switchport nonegotiate).  To disable DTP on an interface "switchport nonegotiate" must be configured

Interface Configs for working trunks
Configuration Side AShort NameDescriptionFor Trunking Configure Side B with
switchport mode trunkTrunkAlways Trunking Side A and sends DTP Frames to Side B to help determing Trunking Modeswitchport mode trunk

switchport mode trunk + switchport nonegotiate,

switchport mode dynamic desirable,

switchport mode dynamic auto
switchport mode trunk
switchport nonegotiate
NonegotiateAlways Trunking Side A no DTP Frames sent to Side Bswitchport mode trunk,

switchport mode trunk + switchport nonegotiate
switchport mode dynamic desirabledesirableSends DTP Frames sent to Side B, trunks if negotiation succeedsswitchport mode trunk,

switchport mode dynamic desirable,

switchport mode dynamic auto
switchport mode dynamic autoautoReplies to DTP Frames sent from Side B, trunks if negotiation succeedsswitchport mode trunk,

switchport mode dynamic desirable
switchport mode accessaccessSends DTP Frames sent to Side B, but never trunksNo config results in a working trunk
switchport mode access
switchport nonegotiate
access nonegotiateNo DTP Frames sent to Side B never trunksNo config results in a working trunk

Trunk Encapsulation

Cisco propietary ISL encapsulate ethernet frames within an ISL frame that has 26 byte header and 4 byte CRC (encapsulated frames are sent with the switch src MAC to a multicast destination)

IEEE 802.1Q trunks insert a 4 byte tag into the existing ethernet frame.  The 4 bytes are inserted where the Type/Len field would be.  the Ethertype is 0x8100 to identify the frame as being an 802.1Q frame, and the other two bytes include a 12 bit VLAN ID and 3 bit Priority Tag (802.1p)

If the trunk encapsulation is not specified, and switches support both ISL and 802.1q, DTP will negotiated an ISL trunk in preference to an 802.1q trunk.  However if one side of a link specifies a particular encapsulation type, DTP will negotiate only for that type.

Link Aggregation (Etherchannels)

If we recall the point about STP, it was introduced to allow for redundant links in a network but since Ethernet can only work in a loop free topology, STP has to break the loops by placing a looping port into a blocking state.  This means that simply adding parallel ethernet links to increase bandwidth doesn't work on its own.  To get around this, we can logically bundle multiple physical interfaces into a PortChannel/EtherChannel bundle.  STP then uses the Portchannel interface for its topology information rather than the underlying physical interfaces.

There are three methods to enable link aggregation, hard coding, the Cisco propietary Port Aggregation Protocol (PAgP) or the IEE 802.1AD standard Link Aggregation Control Protocol (LACP)


Interface LACP/PAgP Configuration (channel-group mode xxx)
LACPPaGPResult
ononDisables LACP/PAgP and forces port into becoming part of the PortChannel (No negotation)
offoffDisables LACP/PAgP and prevents the port for becoming part of the PortChannel (No negotation)
passiveautoThis interface waits for the other side to send LACP/PAgP frames before responding and negotiate joining the Portchannel (If both sides set to this mode, they will not negotiate a port channel)
activedesirableThis interface actively sends LACP/PAgP frames to negotiate joining the Portchannel

In order for a Portchannel to be correctly configured, the physical interfaces have to be of the same type (FastEthernet, GigabitEthernet etc) and the underlying physical (e.g. speed, duplex, no SPAN) and logical configurations (e.g. VLAN or trunk configuration including Native VLAN and STP costs) also need to match.  Portchannels can be L2 (switchport) which can support VLAN trunking or L3 (no switch port) interfaces just like single physical interfaces.

Load Balancing across Etherchannels

In order to support load balancing across multiple links, a hashing algorithm is used. The data that is inputted into the algorithm can be selected to best match the particular traffic type that is traversing the Portchannel.  For example, most of the traffic heading from an access switch to a distribution switch is most likely heading towards the default router (Many source MAC addresses but a single destination MAC address) which may suggest an optimal configuration of  using source-mac from the egress of the access switch to the distribution switch while using destination-mac on the other side of link.  "port-channel load-balance " is the command, where can be used to select source/destination MAC, IP or UDP/TCP ports as the input.

Allowed VLANs

By default, all VLANs can traverse all trunk ports on a switch (assuming that VTP pruning isn't operational) to provide security or control where switch traffic can go it is possible to specifically list which VLANs can traverse a trunk port (switchport trunk allowed vlan xxx)  Router Trunk ports implicitly have this capability since subinterfaces created with "encapsulation dot1q xxx" are created as the configuration demands it and the router silently discards traffic for unconfigured VLAN ids.

Router on a Stick

A router on a stick is simply a router that connects to a switch with a VLAN trunk interface and routes between the VLANs, each VLAN is associated with a separate subnet and has to traverse the router to reach a host on the other subnet.


Native VLAN

The Native VLAN is a VLAN that on a VLAN trunk interface which does not have a VLAN tag.  By default VLAN 1 is the native VLAN but can be configured (switchport trunk native vlan xxx)

On a router, the main interface (untagged) is normally the native VLAN

interface FastEthernet0/0
 ip address 1.0.0.1 255.255.255.0
!
interface FastEthernet0/0.10
 encapsulation dot1q 10
 ip address 1.0.10.1 255.255.255.0
 

It is possible to specify an untagged frame to to be associated with a vlan interface on the router using the native statement as seen below:

interface FastEthernet0/1.22
 encapsulation dot1q 22 native
 ip address 1.1.22.1 255.255.255.0

Note: CDP can complain if there is a native VLAN mismatch between devices if they are not the same, while this will not break operation is can fill the logs with annoying warnings if the configuration is correct for the environment.  CDP v2 messages include the Native VLAN information, so if an interface is configured for v1 "no cdp advertise-v2" these warnings will stop, giving an alternative to disabling CDP on that interface (CDP can be seen as a security risk to some, however for the purposes of labbing, I think it's fine)



Layer 2 Technologies - VTP and Bridging

Just putting more notes down to ensure that I at least have some level of information touching each part blueprint topic at the moment....

Blue Print Topics Covered This Post

1.00 Implement Layer 2 Technologies


1.20 Implement VLAN and VLAN Trunking Protocol (VTP)

(a) VTP

(b) Pruning

(c) Bridging – Transparent, IRB, CRB


VTP

VLAN Trunking Protocol (VTP) is used to propogate VLAN configuration information across a VTP Domain, simplifying the administration of adding and deleting VLANs without having to touch every element. For switches that support VTP, VTP information is propogated across ISL or 802.1q Trunks interfaces.

Devices in a VTP domain can either be a Server, client or transparent. Only a server can be used to administratively create or delete VLANs (multiple servers are permitted in a domain, config changes on one server will be propogated and processed on the other servers). A client will take action on the VTP messages, creating or deleting VLAN information. A VTP transparent switch ignores VTP information. All VTP types propogate VTP information within the VTP domain.

FunctionServerclientTransparent
Originates VTP messagesYesNoNo
Processes received VTP messagesYesYesNo
Forwards received VTP messagesYesYesYes
Saves the VLAN configuration in flash:vlan.dat or nvramYesYesYes
Can use config mode to add/delete VLANsYesNoYes

All switches have a default configuration mode as a VTP server and belong to the NULL VTP domain. The VTP database besides the domain has a configuration version associated with it (starting at 0 and incrementing for each VLAN configuration changes) any switch that recieves a VTP database update that has a higher configuration version than what is currently used will immediately overwrite the existing database with the new configuration version. Joining of several operational switches together with a default VTP configuration can cause unexpected consequences where some VLAN information could be lost.

VLAN types and interaction with VTP
VLANNormal or Extended VLAN?Works with VTP v1/v2?Comments
0ReservedN/ANot available for use
1NormalNoDefault VLAN
2 - 1001NormalYes
1002 - 1005NormalNoFDDI and Token Ring Translational VLANs
1006 - 4094ExtendedNocan be used with VTPv3

VLAN Database Storage and Configuration
VTP ServerVTP Transparent
Storage of Normal Range VLANsflash:vlan.datflash:vlan.dat (preference) or running config
Storage of Extended Range VLANsNot Permittedrunning config
CLI configuration of Normal Range VLANsvlan database or conf tvlan database or conf t
CLI configuration of Extended Range VLANsNot Permittedconf t


VTP Pruning

VTP Pruning is a mechanism to reduce the flooding scope of Broadcast, Unknown and Multicast frames traffic across VLAN trunks. If a particular switch does not locally support a particular VLAN, VTP can "prune" it so that traffic related to that VLAN does not get sent across the trunk from a peer switch.

A VTP password can be defined to mitigate an uncontrolled device cannot effect the VTP domain (unfortunately it does not appear possible to stop VTP from exiting a trunk interface, however MAC filtering can be used to stop unwelcome VTP traffic from entering your switch)

Transparent Bridging

This stuff wasnt covered in the Certification Guide, so I used Cisco LAN Switching maybe this is more of a lab than written topic but anyway...

Routers can be configured not to route "no ip routing" and the establishment of bridge groups can be used to link physical interfaces (or their subinterfaces) that have individual broadcast domains into a single broadcast domain using the concept of bridge groups and using STP to ensure loop free operation.

Concurrent Routing and Bridging (CRB) was the initial step to support the simultaneous operation of bridging between some interfaces, while also performing routing, however without introducing a physical loopback to join a bridge group to a routed port it was not possible to combine routing and bridging within a single service.

Integrated Routing and Bridging (IRB) introduces the concept of a bridged virtual interface (BVI) which is a layer 3 interface that represents the bridge group (a Virtual MAC address for the BVI is created) and provides the capability for the Bridge Group traffic to be routed to other layer 3 interfaces on the router

Thursday 4 March 2010

Layer 2 Technologies - STP

So I've read through the Certification Guide and Routing TCP/IP Volume 1 and now it's time to go through and make some notes to ensure that I touch on all of the areas on the written blueprint.  Anthony Sequeira has a good list of the topics and links to the DocCD.

Today's rundown will be focusing on Section 1.10 Implementing Layer 2 Technologies, Spanning Tree Protocol, these areas don't necessarily drill down into all the components of these technologies, these are more my own cheat sheets for things I don't remember so clearly....

Blue Print Topics Covered This Post

1.00    Implement Layer 2 Technologies

1.10    Implement Spanning Tree Protocol (STP)

(a)
802.1d

(b)
802.1w

(c)
802.1s

(d)
Loop guard

(e)
Root guard

(f)
Bridge protocol data unit (BPDU) guard

(g)
Storm control

(h)
Unicast flooding

(i)
Port roles, failure propagation, and loop guard operation


802.1d Spanning Tree Protocol

Hello BPDUs are used to advertise cost that the switch has to reach the Root Bridge.

The Root bridge is determined by the lowest Bridge ID.
The Bridge ID consists of 4 bits of Priority 12 bits of VLAN ID and The 48 bits of Bridge MAC Address (Historically older versions of the standard the Priority was 12 bits - to attempt to have different PVST instances, the Bridge needed to have as many MAC Addresses as VLAN instances - this MAC address reduction situation makes more effective use of MAC address table space)

The default bridge priority is 32768 (The 4 bits representing priority are multiplied by 4096)

Costs are associated with interfaces and their bandwidths, faster interfaces typically have lower values than slower interfaces, however these can be changed from the defaults to deterministically select where block occurs.


The Root Port (RP) is a port on a bridge that is not the root bridge that has the lowest cost to reach the root bridge.  This cost is what is advertised to other switches through Designated Ports.

A Designated Port (DP).  On each LAN segment, only one switch (the designated switch - which has the lowest cost to reach the Root) will send Hello BPDUs and Configuration BPDUs to downstream switches

Note: All switches initially send Hello BPDUs out with their costs to the root, if they realise they are advertising an inferior root cost, they stop sending Hellos

Default Times:
  • Hello time = 2 seconds  (how often Hello BPDUs get transmitted)
  • MaxAge = 10 x Hello time i.e. 20 seconds (How long to wait if Hello BPDUs haven't arrived before attempting to converge - used for switches that are distant from the root bridge)
  • Forwarding Delay = 15 seconds (Used to ensure we don't get duplicate frames while converging and assembling a bridging table)

It can take roughly 50 seconds for the topology to converge on a link failure and a backup path become able to forward frames:

t = 0
 Determine there's a problem - such as no hello BPDUs to the RP (Wait MaxAge to age out the last received BPDU)
t = 20
 Previously Blocked Port enters Listening State (in listening state for Forwarding Delay)
t = 35
 Port in Listening State Enters Learning State (in learning state for Forwarding Delay)
t = 50
 Port is now forwarding (Convergence complete)


Failure Propogation


A switch that detects a change that will impact the switch topology needs to notify the Root Bridge.  The switch will send a Topology Change Notification (TCN) message out of its RP.  The peer switch that learnt this through its DP will send back a Topology Change Acknowledgement (TCA) in the Hello BPDU.  The peer switch will onforward the TCN to the Root Bridge.


Once the TCN hits the Root Bridge, it replies to the peer switch with a TCA and then it will inform the rest of the network topology of a change by setting the Topology Change (TC) Flag in it's next configuration BPDU (this forces all switches to set the aging time of the MAC addresses in their Bridging tables from the default of 300s to the Forwarding Delay time - default 15s).


PortFast, UplinkFast and BackboneFast

PortFastWhen an interface first comes up it can be 30 seconds before traffic can start being forwarded by the switch.  Portfast skips through the Listening and Learning phases and directly puts the interface into forwarding state.  This should only be used on single ended devices like routers or hosts
UplinkFastApplied on dual-homed access switches, Uplink fast tracks an alternate RP (which is kept in blocking state as per regular STP methods) If the active RP fails, the switch immediately makes the alternate RP the active RP and directly enters forwarding mode and sends out multicast frames on behalf of all local MAC addresses in order for the rest of the network to learn the new path.  When entering this global command, the bridge priority is set to 49152 and the port costs are set to 3,000 in order to influence the STP design so that it is not a transit switch.
BackboneFastUsed to detect indirect failures.  When a switch does not recieve an expected Hello BPDU, it will actively send a Root Link Query (RLQ) out it's root port asking if the upstream switch still has visibility of the root (the response will be another RLQ) this allows faster convergence by bypassing the need to wait for the MaxAge timer to expire.

PVST+ (Per VLAN Spanning Tree)

Supports individual STP instances for each VLAN allowing individual STP topologies and the ability to load balance VLANs across redundant links.  BPDUs are sent per VLAN

802.1w Rapid Spanning Tree Protocol

As the name implies, this is a faster version of STP and interworks with it.
  • It takes some of the Cisco propietary features (PortFast, UplinkFast and BackboneFast) and integrates them into the standard.
  • The MaxAge is 3 rather than 10 Hello times
  • The switch will has a backup DP when multiple ports are on the same LAN segment
It introduces link types:
point-to-pointThis is a full-duplex switch to switch link
sharedThis is a port where multiple switches can be seen (for example switches are connected to a hub)
edgeConnected to a non-STP enabled host

and Port Roles:
Root Port (RP)This is the same as the 802.1d RP
Designated Port (DP)This is the same as the 802.1d DP
Alternate Port (ALT)Backup RP (Like Backbone Fast)
Backup Port (BAC)Only on Link Type Shared, this is a Backup DP

RPVST+ (Rapid Per VLAN Spanning Tree)

802.1w version of PVST+



802.1s Multiple Spanning Tree/Multiple Instance Spanning Tree Protocol

MST takes some of the concepts used in 802.1w - however rather than a STP instance per VLAN, the network supports a number of STP instances which have VLANs mapped to each instance.

A MST Region consists of switches that share:
  • The same MST region name
  • The same revision number
  • The same VLAN to MST instance mappings

An MST Region appears as a single virtual switch to 802.1d switches or other MST Regions.

Root Guard

When configured on an interface, if superior BPDUs are received, the interface will be placed in a Loop Inconsistent State until the superior BPDUs stop arriving- this protects the network from a customer device changing the STP topology.

BPDU Guard

When configured on an interface, the reception of any BPDUs will cause the interface to enter error disabled state and will stay in that state unless configured to auto recover, or is manually configured (shut/no shut)

Loop Guard and UDLD

This functions protect against a unidirectional interface which can cause a bridging loop to occur.  With Loop Guard, if BPDUs are no longer received on a non-DP then that port is put into loop inconsistent blocking state.

UDLD identifies the peer of a link and will place an interface into error disable state if the peer no longer responds to Hello BPDUs.  Aggressive mode will attend to retry the link 8 times before shutting down.

Storm Control

Storm control is a layer 2 rate-limiting per interface feature that allows setting of thresholds of layer 2 traffic types on ingress.

interface Fastethernet0/1
 storm-control broadcast level pps 100 50

pps refers to packets per second, 100 is the forwarding limit (100 pps) that once exceeded will stop forwarding broadcast frames until the interface is receiving traffic below the falling threshold (50 pps)


interface Fastethernet0/1
 storm-control multicast level 0.50 0.40


0.50 is the interface rate percentage forwarding limit (500kbps) that once exceeded will stop forwarding multicast frames until the interface is receiving traffic below the falling threshold (400kbps)


interface Fastethernet0/1
 storm-control unicast level 80
 storm-control action trap


80 is the interface rate percentage forwarding limit (80Mbps) - the action trap comment generates a SNMP trap once storm-control takes an action