Why the Virtual Switches Need Bpdu Guard

I have receive the question as below:

What happens if a VM running within a vSphere host sends a BPDU? Will it get dropped by the vSwitch or will it be sent to the physical switch (potentially triggering BPDU guard)?

Last, I got the answer from visibly harassed Kurt (@networkjanitor) Bales during the Networking Tech Field Day; one of his customers has managed to do just that.

Here’s a sketchy overview of what was going on: they were running a Windows VM inside his VMware infrastructure, decided to configure bridging between a vNIC and a VPN link, and the VM started to send BPDUs through the vNIC. vSwitch ignored them, but the physical switch didn’t – it shut down the port, cutting a number of VMs off the network.

Best case, BPDU guard on the physical switch blocks but doesn’t shut down the port – all VMs pinned to that link get blackholed, but the damage stops there. More often BPDU guard shuts down the physical port (the reaction of BPDU guard is vendor/switch-specific), VMs using that port get pinned to another port, and the misconfigured VM triggers BPDU guard on yet another port, until the whole vSphere host is cut off from the rest of the network. Absolutely worst case, you’re running VMware High Availability, the vSphere host triggers isolation response, and the offending VM is restarted on another host (eventually bringing down the whole cluster).

There is only one good solution to this problem: implement BPDU guard on the virtual switch. Unfortunately, no virtual switch running in VMware environment implements BPDU guard.

Nexus 1000V seems to offer a viable alternative. It has an implicit BPDU filter (you cannot configure it) that would block the BPDUs coming from a VM, but that only hides the problem – you could still get forwarding loops if a VM bridges between two vNICs connected to the same LAN. However, you can reject forged transmits (source-MAC-based filter, a standard vSphere feature) to block bridged packets coming from a VM.

Lacking Nexus 1000V, you can use a virtual firewall (example: vShield App) that can filter layer-2 packets based on ethertype. Yet again, you should combine that with rejection of forged transmits.

In theory, an interesting approach might be to use VM-FEX. A VM using VM-FEX is connected directly to a logical interface in the upstream switch and the BPDU guard configured on that interface would shut down just the offending VM. Unfortunately, I can’t find a way to configure BPDU guard in UCS Manager.

Other alternatives to BPDU guard in a vSwitch range from bad to worse:

Disable BPDU guard on the physical Cisco Switch. You’ve just moved the problem from access to distribution layer (if you use BPDU guard there) ... or you’ve made the whole layer-2 domain totally unstable, as any VM could cause STP topology change.

Enable BPDU filter on the physical switch. Even worse – if someone actually manages to configure bridging between two vNICs (or two physical NICs in a Hyper-V host), you’re toast; BPDU filter causes the physical switch to pretend the problem doesn’t exist.

Enable BPDU filter on the physical switch and reject forged transmits in vSwitch. This one protects against bridging within a VM, but not against physical server misconfiguration. If you’re absolutely utterly positive all your physical servers are vSphere hosts, you can use this approach (vSwitch has built-in loop prevention); if there’s a minimal chance someone might connect bare-metal server or a Hyper-V/XenServer host to your network, don’t even think about using BPDU filter on the physical switch.

Summary

BPDU filter available in Nexus 1000V or ethertype-based filters available in virtual firewalls can stop the BPDUs within the vSphere host (and thus protect the physical links). If you combine it with forged transmit rejection, you get a solution that protects the network from almost any VM-level misconfiguration.

However, I would still prefer a proper BPDU guard with logging in the virtual switches for several reasons:

BPDU filter just masks the configuration problem;

If the vSwitch accepts forged transmits, you could get an actual forwarding loop;

While the solution described above does protect the network on Catalyst 2960 , it also makes troubleshooting a lot more obscure – a clear logging message in vCenter telling the virtualization admin that BPDU guard has shut down a vNIC would be way better;

Last but definitely not least, someone just might decide to change the settings and accept forged transmits (with potentially disastrous results) while troubleshooting a customer problem @ 2AM.

Notes: There are more comments of discussing Virtual Switches Need Bpdu Guard in the original page http://blog.ipspace.net/2011/11/virtual-switches-need-bpdu-guard.html

Why the Cisco 2960S Randomly Reboots

Having a strange problem, my catalyst Catalyst 2960 switches keep randomly restarting. They are stacked and are running IOS version 12.2(58) SE2. I also can't find a crash log file in the flash directory after they randomly reboot.

                 

Ive checked the show version with no avail, but it does indicate a possible power issue:

System returned to ROM by power-on

System restarted at 09:11:13 PAC Tue Nov 15 2011

System image file is "flash:/c2960s-universalk9-mz.122-58.SE2/c2960s-universalk9-mz.122-58.SE2.bin"

Im not too sure, but the switch WS-C2960-48TT-L is connected to a ups, that a few other switches are also connected to and they did not go offline during the time the switch did.

I am not sure whats going on, as I have nothing to base it on.

The solution:

Try changing the power lead or connecting it to a different source.

The line "System returned to ROM by power-on" usually means that the switch thinks it reset due to power loss.  So you may have a power issue, or possibly the power supply in the switch is bad.  Can you swap the stack master roles so the other switch is master?  It's unlikely that both switches have bad power supplies, so with the other switch running the stack, you should be able to look at the logs and see if the first switch looses power alone, or if both switches go down and come back up at the same time.

You may also try moving the switch to a different port of the UPS.

Where does the Cisco IOS switch store VLAN information

I've got a 2960 switch WS-C2960S-48LPS-L  running IOS 12.2(25).  It has an access point connected to it but guests were unable to connect to one of the wireless networks the AP provides.

One of my techs looked into it and said that VLAN 12 was not configured on the Catalyst 2960 ; VLAN 12 is the VLAN the guest wireless network uses.  He just did "vlan 12" at a conf t prompt and it all woke up.  He didn't add any interfaces to VLAN 12.  So question 1 is this: VLAN 12 exists on the AP, and the switch port the AP is on is configured to trunk.  Why was it necessary to create VLAN 12 on the switch?  None of the resources accessed by users of the guest wifi are on that switch, they just need to use its backbone to our internet router, which is also configured to trunk.

Now I can see VLAN 12 in there when I do a "sho vlan", but I can't see the command that creates VLAN 12 in the running config.  So question 2 is, when the switch reboots or whatever, how does it know to re-create VLAN 12?  Is the info stored somewhere other than the running-config?

Asking because I can envision a time when the switch dies and we go to swap in a replacement by throwing a copy of the old config on it, then sit around scratching our heads because "everything should be identical" when really the VLAN is not being created.

The answer:

The actual vlan info is kept in a file called vlan.dat  .  Depending on the device this is normally in nvram.

What is kept in the startup-config file related to VLAN's are the layer 3 definitions for the svi if you have any.

 There can be two parts of a VLAN definition.  The VLAN itself, which is what is in the vlan.dat file I referenced early.  This allows the vlan to exist as a layer 2 resource. 

Then there is the svi, which is the virtual interface which is required if you want that vlan to exist at the layer 3 level.    A layer 3 interface for the vlan is not always required.

In a well-designed network you would push the Layer 3 outward and never have a lot of switches with the same vlans. So VTP is a tool to manage a badly-designed network. Even when I've had to push vlans to a number of switches, I prefer to manage it manually- because when VTP isn't used correctly (i.e. the default "server" mode is left in place on all switches), removing a vlan on one switch removes it everywhere!

And yes, you have to add the vlans to the switch, but that had to be done anyway. Setting VTP to transparent means that the vlan configuration is stored as part of the regular config where it can easily be recreated on a replacement switch.

More about the Cisco 2960 FAQ, please visit:

http://ciscoswichfaq.weebly.com/