This weekend I was turning up a new circuit for one of my clients and ran into an issue that I encountered once before and thought I would share some details. Years ago the most common type of circuits such as T1’s, T3’s, DS3, etc were delivered to a customer operating on a Layer 3 basis. When operating via Layer 3 the ISP and customers’ network would be completely segregated and bridged via a router which inherently prevented the possibility of Layer 2 spanning tree confusions.
Today, most circuits are simple Layer 2 Ethernet handoffs from the ISP’s that the customer typically terminates into a firewall. Since we are operating completely at the Layer 2 level things can start to get pretty hairy if spanning tree configurations are not exact. A messy scenario that has seen the light of day at some regional ISP’s is when the equipment on the customer’s side is accidently elected as the root bridge. This can cause gigabytes worth of the ISP’s traffic to redirect and flow through one customer’s link causing a cobweb of headaches for many people. Naturally, this is a “perfect storm” scenario, but it is something that still happens.
This weekend when I was setting up the Layer 2 Ethernet Handoff at my client site I immediately saw Sidera’s protection mechanisms kick into gear. After plugging the circuit into my perimeter Cisco 2960 WAN switch I noticed the port bouncing into error disabled mode. My port connecting to the ISP was configured in Portfast mode, which means that I am manually guaranteeing that whatever is plugged into that particular port cannot generate a physical loop. Ports configured in Portfast mode are typically servicing desktops, servers, etc – notice that these are devices that don’t generate any BPDU traffic like routers and switches do. A desktop typically has one NIC and therefore cannot generate a physical loop. PortFast skips the initial spanning tree checks for that port, which avoids the timeout of end stations at boot up. After noticing the error disabled port notification I investigated the logs further and saw in the details that BPDU’s were being received on the port. Right away I knew that my port was receiving BPDU’s from the ISP switch. Thankfully there is a quick and easy fix to this. On my port connecting to the ISP I enabled the following command on the interface: “spanning-tree bpdufilter enable”. This command prevents the port from sending or receiving BPDUs. So, my ISP’s switch is now happy to not receive any BPPDU’s messages from my end and my switch interface is now ignoring BPDU’s messages being sent to me since I never want to participate in a foreign switches’ Spanning Tree topology. At this point I reset the port and noticed that everything started operating as normal.
-Justin Vashisht (3cVguy)