Why the STP bridge priority must be a multiple of 4096

Posted by Bradley | switching | Friday 11 July 2008 00:49

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.

Proxy ARP

Posted by Bradley | ethernet | Tuesday 8 July 2008 15:05

The command no ip proxy-arp was one of those things which I saw in IOS configs and wasn’t to sure what proxy arp is used for or why it exists. Proxy ARP is where a router will respond on behalf of another device, it was used heavily in networks before the days of DHCP & default gateways where a host would ARP for an address that wasn’t on its subnet (modern networks just send the packets to the default gateway instead of arping for the address), the router on the local network would then act as a “proxy” and respond on behalf of the device outside of the subnet.

Proxy ARP isn’t used if hosts are set with default gateways or have routing intelligence, setting a default gateway instead of using proxy ARP is a much better option. Using Proxy ARP instead of a default gateway results in higher ARP traffic & the ARP tables of the hosts get very large as they maintain an IP/MAC binding for every single address the communicate with.

A pop quiz fact: I haven’t been able to verify this from another source but somebody at work told me that IBM helped created DHCP as they would assign workers/visitors with static IP addresses and as people moved around addresses would get lost, eventually they lost 750,000 addresses and needed to create a solution which stopped this from worsening. This is hear say and I cant vouch for its authenticity but its a decent story to talk about the need for DHCP.

RSTP – Rapid Spanning Tree Protocol

Posted by Bradley | switching | Monday 7 July 2008 17:29

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

PVST+ Regions seperated by a CST Region

Posted by Bradley | switching | Wednesday 2 July 2008 14:15

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!

« Previous Page