Globally configured is one thing, actually utilizing it is another, for instance, bpduguard is globally enabled via my default configuration, but it is not active on any of my interfaces within my datacenter. So really it is a meaningless command that exists.

BPDUguard enabled globally only applies to interfaces configured for portfast. I opted to leave portfast out of the port configurations based on the environment I operate, that is not to say it is acceptable in all environments, but it makes the most sense in mine given the administrative overhead it would cause.

Also, the risk of an individual plugging in a random switch in my datacenter is very very low. Nothing is done inside of the datacenter without explicit approval and 48 hour notice, and if I install a switch, I have someone there that plugs in the power, I have another person dedicated to running the cables etc. So the risk that I accept is completely dependent on the environment that I operate in. Not all places have such stringent requirements.

When making any engineering and design decision, you should consider all aspects, including risk, maintenance, difficulty to maintain, flexibility, etc.

Craig

I was in this camp until just a couple of days ago. Run bpduguard on the user blocks only and use change control mechanisms to minimize risk -

But we had a network loop created by bridging NICs together on a server and it crushed a pretty critical switch. It was quick, because a change was being made when it happened, the change was backed out and all was well.

I'm just thinking of changing my stance - especially as more interfaces get virtualized, it might be a good idea to hedge against loops on access ports everywhere on the network.

I guess my question is, why not enable it on all portfast enabled ports by default? If I have portfast enabled I clearly don't expect a bridge to be connected to that port, and if one is connected I want it shut down NOW. Bpduguard doesn't put anything onto the wire, so what is the harm in having it enabled?

My environment I work in is definately unique comapred to most places I have been in, not just from a technology standpoint, but I also take into account the network admin and engineers when I make design decisions.

From a virtualization and datacenter consolidation standpoint, I have no servers connected to my datacenter switches that don't produce BPDU's, in my envinronment, it makes no sense to run BPDU guard and filter. In fact I originally started out when building out a new DMZ, implementing BPDU guard and filter (because I too agree it's a best practice), but I ended up having more problems because of it, so I made the decision to accept the risks associated with not having it enabled.

I think of a BPDU guard and filter as a protection mechanism from users who don't know anything about networking, and don't realize that they can't double their bandwidth by simply bringing in a hub and connecting it to 2 of my switches. I don't view it as a mechanism to defend myself from myself, I don't have unimformed users wandering around my datacenter with patch cables and hubs :)

That being said, we have taken other measures to prevent the risks, such as standard configurations and install procedures for my datacenter to help mitigate such problems. Anything past that is a management issue :)

But really you have to determine what is best for your environment, that includes looking at the technical abilities of your admins and engineers and assessing risk. You can put in a bunch of commands for the sake of having a 12 page running configuration, but I'm a minimalist, and I am a firm believer that the simpler a solution, the better it is.

Craig

Your servers generate BPDU traffic? What kind of servers are these?

And bpdufilter is a different issue. I do not enable bpdufilter as a rule. True, it puts bpdu traffic on the wire where hosts are connected. But in my experience most loops are created by users that have a home-grade switch that has auto-mdix capabilities and they connect the same cable to two ports. If the port the switch is connected to is not generating BPDUs then bpdufilter does not detect this condition.

I'm not sure why people like to do this so much. I had one guy who decided to do this after he disconnected his laptop to go home for the night so that he would be able to locate the cable easily in the morning.

I run IBM Blade Chassis servers, they have the Cisco NIGESM switches installed.

Ah. So your datacenter switches aren't really connecting directly to servers but to another intermediate switch. I understand why in that environment bpduguard does not make sense. I am not familiar with the IBM blade servers, but I suspect that there is some way to configure switchport properties on the NIGESM switches where the servers connect to them on the backplane.

They are full blown switches for the most part, they do etherchannels, spanning-tree, port security, object tracking etc.

The only thing I have noticed about them is sometimes setting up the etherchannels is a bit flaky and painful, it doesn't support kron jobs, and the default spanning-tree protocol isn't PVST+.

Other than that my standarad templates work fine on them. The main thing I do them is setup object tracking, so if my etherchannel goes down, it error disables the switchports connecting to the servers, without that the server NIC's don't fail over properly.

Craig

Its really a best practices question - the subject of bpduguard in the user blocks is a no brainer - not enabling it is crazy. But I've gotten a range of feedback concerning having it enabled on server access ports in the DC, so I thought I would reach out here for feedback.