The 3 major steps traditional 802.1d STP uses to stabilise the network are;

Elect the root switch – Only a single switch can be the root switch in a STP domain, each switch will send STP Bridge Protocol Data Units (BPDUs) listing itself as the root switch which is sent across the Layer 2 domain. If the switch receives BPDU with a lower bridge ID, it accepts that as the root switch and BPDUs sent from the switch will list the Bridge ID or the root switch in their BPDUs. Eventually all switches in an STP domain will have the same root switch, after the election period a new root switch will not be elected until hello frames sent from the root switch have stopped being received.

The Bridge ID originally consisted of a 2 byte priority and a 6 byte system ID (MAC Address), but the first 2 bytes were altered to supported technologies which require the VLAN information to be sent in BPDUs such as Multiple Spanning Tree (MST). So now the first 2 bytes consist of 4 bits for bridge priority (as these are the high order bits hence only multiples of 4096 are accepted values), and 12 bits to hold the Vlan information the new 12 bits is called the System ID extension. There is an older post I made about why the STP priority must be a multiple of 4096 here, this bit limitation is also the reason why there is a maximum vlan ID of 4095.

Determine the root port for each switch – After the root switch is elected every other switch apart from the root switch determines the port with the lowest cost to reach the root switch. The root switch sends out hellos and each port receiving the hello adds the port cost using the table below to the hello.

I think that it might have been a bit short sighted stopping the updated costs at 10Gbps, my organisation is running lots of 40 Gbps links and has just finished a field trial of 100 Gbps.

The ports on a non root switch which received the hello and has the lowest cost to to root switch is elected the root port. If 2 ports have the same cost to reach the root bridge the tiebreaker is the forwarding switches Bridge ID, and then an administratively defined port priority and finally the lowest internal port number.

Select the designated port for each segment – Only 1 switch in a spanning tree domain is allowed to forward frames to each LAN segment, this is called the Designated Port. Each switch port will send hellos and with the cost of its root port, this will be received by other switches on the segment and and the port with the lowest cost will become the DR while the other port will move to the blocking state. For tiebreakers the lowest forwarders Bridge ID, then lowest port priority and finally lowest port number is used just like the tiebreakers for the root port.

Detecting when bad things happen – The root switch will send out periodic hellos which will be received, updated and forwarded out of every designated port. The maxage timer is reset every time a hello is sent but if the maxage timer expires (default is 10x the hello therefore 20seconds) the switches elect a new root switch.

If a trunk goes down, a switch will sent a Topology Change Notification (TCN) BPDU out of its root port and will continue doing so every hello time until it receives a Topology Change Acknowledgement (TCA) which is a bit set in the BPDU. When a switch receives a TCN BPDU it will send back a TCA BPDU and the switches will continue forwarding on the root ports until it reaches the root switch. Once the root switch receives the TCN BPDU it will send out the next few BPDUs with the TCA bit set, when a switch receives this BPDU it will time out entries in the CAM

802.1d Interface States -During a topology change there is a risk of causing Layer 2 loops to prevent this the interfaces cycle through the usual blocking, listening, learning, forwarding or disabled states.

Personal Note – Im not going to blogging in such depth and breadth any more as it takes to much time and will cover topics which are more interesting or I struggle a bit on.

VLAN Trunking Protocol (VTP) – VTP updates are sent out of all active trunking interfaces (dot1Q or ISL). Each VTP advertisement includes a revision number that is incremented by a VTP server, the advertisement will only be processed by VTP servers and VTP clients in the same domain and correct password if the revision number is greater than the one currently stored on the switch. Standard range VLAN information is stored in vlan.dat file stored in the flash.

Cisco switches are VTP servers by default but will not send out VTP advertisements until a VTP domain is configured.

There are 3 main modes a VTP switch can be in Server, Client & Transparent.

Server – In VTP server mode you can create, edit and delete VLAN information on the switch and it will be propagated throughout the VTP domain. VTP servers also originate periodic VTP updates.

Client – VTP client mode is exactly the same as server mode except it is not possible to create edit or delete VLANs on the switch, you will need to edit them on a server in the VTP domain and they will update the client, clients will also originate VTP updates.

Transparent – In VTP transparent mode the switch will forward VTP advertisements but not process any of the advertisements. VLAN information can be changed on the switch but the information will not be propagated and stay local to the switch.

Standard/Extended range VLANs – VTP will only update standard range VLANs which is any VLAN with a number between 1 and 1005. If you wish to configure extended range VLANs (VLAN numbers 1024 to 4094) then the server must be in VTP transparent mode as VTP does not support these.

Note: VLANs 1006 to to 1024 were reserved for compatibility with CatOS based switches and shouldn’t not be used.

Extended range VLANS cant be stored in the vlan.dat file and will be stored in the running configuration, if the startup config and the vlan.dat have any differences only the vlan.dat information will be used.

VLAN Trunking – Interconnects between switches are trunked using either ISL or 802.1Q. ISL is Cisco propriety and encapsulates each frame with a 26 byte header and an additional trailer where as dot1Q which is an IEE standard adds a 4 byte tag after the source address field in the frame. dot1q will not tag the native VLAN on a link therefore any frames receiving on a VLAN trunk without a tag are presumed to be part of the native VLAN, ISL does not support native VLANs.

Dynamic Trunk Protocol (DTP) – DTP allows a switch port to automatically negotiate a trunk, this can be a security issue and personally I am not to keep on this and prefer to manually make each port either a trunk or access port. The DTP modes are;

on - Permanent trunk even if the neighbour cant support it

off - Permanent access port, so wont trunk even if the neighbour cant support it

desirable - Actively sends out DTP frames to attmpt become a trunk but will become a trunk or an access port.

auto - attempts to passively become a trunk, so wont send out frames but will respond if it receives them. Note that if both ends are set to auto then the port will not become a trunk

nonnegotaite - The port  will not send any DTP frames out, its recommended that this should be used when connecting the port to a non cisco switch which could react strangely to DTP frames.  Either use switchport mode trunk or switchport mode access to dictate what mode the port should be in.

Today I used the Cisco recommended TFTP server tftpd32 to copy an IOS image from my desktop to my lab 3550, but I got some errors which ultimately led to the transfer failing;

Switch3550#copy tftp flash
Address or name of remote host []? 10.0.0.1
Source filename []? c3550-ipservicesk9-mz.122-46.SE.bin
Destination filename [c3550-ipservicesk9-mz.122-46.SE.bin]?
Accessing tftp://10.0.0.1/c3550-ipservicesk9-mz.122-46.SE.bin...
Loading c3550-ipservicesk9-mz.122-46.SE.bin .from 10.0.0.1 (via FastEthernet0/24
):!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!O!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!O!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!O!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!O!!!!!!!!!!!!!!O!!!!!!!!!!!!!!O!!O!!!!O!!O!!!O!!!O!!!O!!O!!
!O!!!O!!O!!!O!!!O!!!O!!O!!!!O!!O!!!O!!!O!!O!!!O!!!O!!!O!!O!!!O!!!O!!!O!!O!!!O!!!
O!!O!!!!O!!O!!!O!!!O!!!O!!O!!!O!!!O!!O!!!O!!!O!!!O!!O!!!!O!!O!!O!!!!O!!O!!!O!!!O
!!O!!!O!!!O!!O!!O!!O!!OOO!OO!OO!OO!OOOO!OO!OO!OO!OOOO!OO!OO!OO!OOOO!OO!OO!OO!OOO
O!OO!OO!OO!OOOO!OO!OO!OO!OOOOO!OOOO!OOOOO... [timed out]
%Error reading tftp://10.0.0.1/c3550-ipservicesk9-mz.122-46.SE.bin (Timed out)

I tried resending the file and got the same error, I looked up the error code and O means that the packets were received out of order, I checked the interface and couldn’t see any issues with it;

Switch3550#show int fa0/24
FastEthernet0/24 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 0013.80a2.6b00 (bia 0013.80a2.6b00)
Internet address is 10.0.0.2/8
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is unknown media type
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:03, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 52000 bits/sec, 2 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
20965 packets input, 10551667 bytes, 0 no buffer
Received 2515 broadcasts (42 IP multicast)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 1279 multicast, 0 pause input
0 input packets with dribble condition detected
19122 packets output, 1248823 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out

To resolve it I doubled the timeout from 3 seconds to 6 seconds and increased the number or max retransmits from 6 to 12, and the transfer went smoothly. Im unsure of why I was getting the errors, I did not set tftpd32 to use an anticipation window and there was only a straight through cable between me and the switch, any suggestions why they were out of sequence would be appreciated!

So I thought this would be a good opportunity to review TFTP & some of its status codes like ! and O. TFTP uses UDP port 69, and block numbers within packets to order them. There was originally a 512 byte block per packet with a 32MB file limit but this has now increased to a variable block size and a 4GB limit with RFC 2348. TFTP is only used significantly today to transfer network device images & associated configurations across trusted networks, it has no methods of listing directories, packet encryption or passwords.

The characters which show the status of a transfer in IOS are
! – Indicates a successful transfer to 10 packets
O – Indicates out of sequence packets
. – Indicates a timeout
E – Uppercase E indicates an error
e – Lowercase e indicates flash is being erased
V – Indicates checksum verification

I remember when I first saw Storm Control in a config and thought “woah, whats that looks really confusing”, but really its pretty simple stuff.

We use storm control to rate limit layer 2 traffic, this helps us prevent a subnet from being flooded with broadcasts, multicasts which would adversely affect the performance of the entire subnet. Storm Control can only be configured on physical interfaces and will not work on subinterfaces, or an LACP/PAGP interface.

Configuration

The first command shown limits the broadcast to 200pps, and if this limit is reached will not forward any more broadcasts until this is reduced to 150pps
(config-if)#storm-control broadcast level pps 200 150

Multicast and unicast traffic can also be limited, the maximum level can also be entered as a percentage instead of pps, in the example below multicasts can use up to 5% of the interface bandwidth, and once that limit is reach no more multicasts will be forwarded until it drops to 4.5% of the total interface bandwidth
(config-if)#storm-control multicast level 5 4.5

In the final example unicast is limited to 80% of the interface bandwidth but a second value is not specified, this causes all unicast to be forwarded up to 80% of the bandwidth and it does not force the traffic to wait until it drops below a second level
(config-if)#storm-control unicast level 80

The default response for storm control is the drop packets which are over the rate limit, and create a syslog message, we can also generate a SNMP trap with the command
(config-if)#storm-control action trap

The show commands for this are also really easy, I will paste the output of this when I am home
(config-if)#show storm-control port [unicast|broadcast|multicast]

A recent example of a Layer 2 attack happening in the real world was where the popular hacking tool website Metasploit was taken down, the attacker who had a server in the same subnet as the Metasploit web server would send ARP messages saying that the MAC of the metasploit web server was actually on the attackers server. The actual MetaSploit webserver was up and running fine but any user visiting the website would see the attackers “victory” message instead of the actual Metasploit website. This attacked was not resolved but Dynamic Arp Inspection but its a cool example of what it can prevent.

There are many other attacks which abuse ARP messages and they commonly result in DOS or man in the middle attacks. Dynamic ARP Inspection (DAI) is a great method of preventing ARP based attacks.

If DAI is deployed on a switch it will examine ARP messages on every untrusted port and discard inappropriate ones, it does not examine ARPs on trusted ports. End stations should be configured as untrusted and connections to other switches & network devices should always be trusted, otherwise possibly valid ARP messages could be discarded.

The following are steps which DAI will decide whether to discard a packet on an untrusted port. Only step 1 is used by default steps 2 to 4 require extra configuration.

1 – If an ARP message states an IP address which has not been assigned via DHCP to that port the ARP is dropped.

2 – The ARP is checked against a staic list of IP/MACs and if it doesnt match the ARP is dropped

3 – An ARP reply should have the source MAC and the MAC in the message the same, if they are different the ARP is dropped. Also the destination MAC and MAC target are compared, if they are different the ARP is dropped

4 – Unusual IP addresses can be also filtered such as the subnet addresses, broadcast addresses and multicast addresses.

Configuration

DAI is enabled per VLAN with the following command;
ip arp inspection vlan vlan-range

All ports default to become trusted ports so to start the inspection of ARPs ports must be configured as untrusted with the interface command
no ip arp inspection trust

Option 2 in the list above where static IP/MAC lists can be checked with the following command
ip arp inspection filter arp-acl-name vlan vlan-range [static]

Steps 3 & 4 in the list above are not checked by default but they can be with the command
ip arp inspection validate {[src-mac] [dst-mac] [ip]}

The maximum rate of ARPs can also be limited to prevent DoS attacks with the command
ip arp inspection limit {rate pps [burst interval seconds] | none}

It came up very briefly at work today why the STP bridge priority must be a multiple of 4096 so I thought I would post my response on here.

There was only 2 fields in the original STP Bridge ID this was a 2 byte priority which allowed any value for the priority to be set from 0 to 65,535, followed by 6 bytes for the MAC address for those tie breaker situations.

But when multiple spanning trees instances started to appear on networks due to technologies such as PVST+ and MST this caused the switch to have a single BID for all the VLANs as it could not differentiate between the VLANs. So switch vendors like Cisco used a unique MAC address for each VLAN, but this caused a wastage of MAC addresses as each switch could have to reserve up to 4094 addresses if non standard VLANs were used (Im sure there must have been a limit to the amount each switch could reserve, but this was before my time so I don’t have any practical information on this).

Therefore to prevent the overuse of the MAC addresses they turned the 2 bytes which was used in the priority field of the Bridge ID into a 4 bit priority and used the remaining 12 bits for the vlan, the extra information which is used to carry the VLAN number is called the Extended System ID, and this process is sometimes called MAC address reduction as it reduces the number of reserved MAC addresses needed. The 12 bits of extra VLAN information allows support for 4096 VLANs, so there is full support for extended range VLANs. Therefore because of the use of the Extended System ID in the Bridge ID, there is only the first 4 bits of the original 2 byte number to be used for the bridge priority so it only allows multiplies of 4096.

I covered RSTP again last week and had a few notes on it, these notes are far from conclusive, but here goes.

RSTP is defined by IEEE 802.1w and improves upon STP which is defined in IEEE 802.1d. In a nutshell RSTP converges networks more “Rapidly” than STP.

Traditional STP sends hellos every 2 seconds and has a max age timer of 20 seconds, therefore 10 hellos would go missing before STP would start to converge. RSTP only waits for 3 times the hello time, the hello timer is still 2 seconds by default but as with traditional STP this can be changed. With traditional STP BDPUs are only sent from the root bridge and relayed by the other switches, with RSTP every switch sends it own BPDUs even if the root bridge is down, they are sent every hello timer.

Cisco created some cool features for traditional STP to help it converge quicker these are PortFast, UplinkFast, & BackboneFast, these are standardised in RSTP.

RSTP also defines some additional port roles;

• Root Port – Same as in STP
• Designated Port – Same as in STP
• Alternate Port – An alternative Root Port for a segment, same as Cisco UplinkFast feature
• Backup Port – A backup Designated Port for a shared segment.

RSTP also classifies the links in one of 3 types

• Point to Point – Fully Duplex links between 2 switches where hellos are exchanged are treated as Point to Point
• Shared – A Shared link is a port which connects to a hub
• Edge – A switch port which connects to an end system

If RSTP fails to receive a hello on a Point to Point link it immediately asks the other switch about its status, if its path to the root is down it immediately starts to converge. This is a standardised version of BackboneFast.

Traditional STP has 5 port states, Disabled, Blocking, Listening, Learning & Forwarding, RSTP on the other hand only has 3, Discarding, Learning & Forwarding. It converges faster as it does not need to go through the Listening stage as it actively queries its neighbors ensuring there are no loops.

RSTP helps networks achieve far speedier convergence times, traditional STP networks take around 30 to 50 seconds to converge where as RSTP can converge (dependant on topology) less than a second.

A fantastic link on RSTP – http://www.cisco.com/warp/public/473/146.html

On page 69 of the CCIE Routing & Switching Exam Certification Guide 3rd edition, there is an interesting topology where there are 2 PVST+ regions of Cisco switches separated by a CST region of non Cisco Switches. PVST+ cannot be supported on non Cisco devices. To get around this the PVST+ regions treat the path through a CST region as a single link and tunnel through the region using multicast frames.

The 2 PVST+ regions tunnel by sending BPDUs to the mulitcast MAC of 0100.0CCC.CCCD, the non cisco switches treat the frame as multicast and not as a BPDU and forward it. The PVST+ devices on the edge of the CST region listen on that address to receive the frames and forward them into the PVST+ region. Hurrah the PVST+ regions can communicate!

This topic is more relevant to the CCIE SP track so I will just briefly go over the concept of this.

801.1Q-in-Q tunneling AKA Q-in-Q is a method of passing VLAN traffic across a WAN. At a simple level a SP switch tags incoming frames with an extra 802.1Q header and its passed through the WAN, where at the egress port of the SP network the tag is removed. The customer frames then have their original 802.1Q headers preserved after traveling across the WAN.

Q-in-Q allows customer networks to tagged frames across a shared SP WAN, other layer 2 protocols such as CDP and VTP are also allowed and it does not matter if the customer does not have unique VLAN numbers.

Private VLANs (PVLANs) are not something I have been able to lab as I dont have a layer 3 switch (not yet anyway but I am saving my pennies for a Cisco 3550) and I havnt used them at work.

Anyway, PVLANs are a method of isolating ports in the same VLANs to provide security, a good example of their application is in a Service Provider Network where many end customers are connected to ports on a switch. They could put all of the customer ports on an isolated port in the PVLAN (more on that in a bit), and the gateway on a promiscuous port (again more in a bit) and a customer with multiple ports could be in their own community.

There are 3 types of ports in a PVLAN ports, promiscuous, community, and isolated.

Promiscuous ports: These ports can communicate with all other ports in the PVLAN including community and isolated. In the service provider example above the gateway would probably be on a promiscuous port.

Isolated ports: These ports are cant communicate with any other ports, except promiscuous ports. Isolated ports cannot talk to each other and in the example above the customers would be connected to a isolated port.

Community ports: These ports can communicate with other ports in the same community and promiscuous ports, but cant communicate with ports in other communities, or isolated ports. In the example above a customer with multiple connections could be in the their own community, this would allow layer 2 connectivity between the ports and they would still be able to access the gateway but have isolation from isolated ports.