Search queries that have led readers here, conversations with customers, and various blog posts, have made it clear that people are running full-speed into an interesting feature of the Cisco Nexus Fabric Extenders: FEX ports always run bpduguard. You can't turn it off.
For the uninitiated, Bridge Protocol Data Units (BPDUs) are the packets used by bridges (switches) to build a loop-free topology. BPDU Guard is a Cisco interface feature that immediately disables an interface if a BPDU arrives there. It's appropriate on interfaces where you never expect to plug in a switch. If you've ever plugged a switch into your cubicle jack at work, you may have experienced this feature firsthand.
BPDU Guard tends to go hand-in-hand with portfast, a feature that makes switch interfaces ready for use as soon as they link up, instead of forcing these fresh links to jump through the Spanning Tree Protocol (STP) loop prevention hoops.
If you're going to use portfast, you must use bpduguard.
Nexus Fabric Extenders (2148, 2248, 2232) run bpduguard on their interfaces all the time. It can't be disabled.
Bpdugaurd means that you can't hang a switch from a FEX. If you've adopted Cisco's vision of the modern data center, this can become a problem because the 2148 fabric extenders can only do gigabit. No 10/100 capability here. It turns out there's a lot of stuff in a modern data center that still can't do gigabit, but lives out in the general population that's intended to be served by the Fabric Extenders:
- HP server iLO interfaces
- Terminal server appliances
- Power strips
- Environmental monitors
- KVM equipment
The best option for these small, far-flung clients might be the installation of a small, 10/100 capable switch nearby. I selected the WS-C2960-24TC-S for this purpose in a recent build because it's super cheap (list price is $725) and because it has dual-purpose uplink ports. The natural inclination is to try to uplink directly into the nearby 2148T fabric extender. But, as soon as you do, the 2960 sends a BPDU, and the 2148 shuts down the interface.
You could disable spanning-tree on the 2960, but that's asking for trouble, and makes redundancy impossible. You could disable spanning tree on just the uplink interface because it's safer, but still doesn't accomplish redundancy. You could link the small switch directly to the distribution layer, but that's a lot of buck for relatively little bang.
Another possible answer is flexlinks, a long-forgotten uplink redundancy mechanism
that probably predates stable STP operation. I had assumed so, but it doesn't look like flex links is quite that old. I don't know why this feature was introduced, but it's useful here.
Enabling flexlinks is a one-liner: In 'interface GigabitEthernet 0/1 configuration context' do:
switchport backup interface GigabitEthernet 0/2
Now, Gig0/2 backs up Gig0/1. Spanning tree protocol is disabled on these two ports, so BPDU Guard won't cause a problem, and there's no risk of these ports creating a topology loop because only one one of them will be in forwarding mode.
Plug both interfaces into a fabric extender and you're in business.
The interfaces can be trunks or they can be access ports. If they're trunks, you can even balance the vlans across the uplinks if you're so inclined (personally, I don't care for it, but this is a very common strategy).
A topology change will flood bogus packets which appear to be sourced from your client systems so that upstream switches update their forwarding tables. ...A process that can be made even quicker with the 'swichport backup mmu' mechanism - but I doubt the Nexus supports that anyway.
100Mb/s is really the only real requirement. I can only think of two devices that are limited to only 10Mb/s in any of the networks I work on. And both of those are in my basement, which has not yet been migrated to the Nexus platform. Fortunately, the Nexus 2248 Fabric Extenders can do 100/1000, so you'll be much less inclined to try to hang a switch off of them. Plus they're cheaper, and have a few other benefits over the 2148T. As far as I'm aware, there's not a single technical reason to prefer a 2148 over the 2248, so stop buying 2148s.