BPDU-Guard and Windows XP bridging

I agree with this document.

Just in case -

This is correct behaviour. The windows Bridge is not STP aware and forwards the BPDUs. As long as portfast is NOT enabled on the switch ports then all is OK since one of the switch ports goes STP blocking. If you have portfast on then you get short term network loops (or of course long term network loops if you get a meltdown caused by the loop:-)))).

The best way to do Windows resilient connection appears to me to be to use the approach described here:-

I can't seem to get a better link right now.

Thread "Ether-channel cross switches" in this group.

I would not fancy the bridging approach at all (unless desperate:-)

snipped-for-privacy@hotmail.co.uk crashed Echelon writing news: snipped-for-privacy@i42g2000cwa.googlegroups.com:

First, I am a beginner in this field, so excuse me for lame and noobish comments/questions.

But I only thought loop where detected when BPDU packets returned from the same port, where they originated, and then would result in a block.

If so, then I my logic sense, a bridge should not return packets, as if a loop existed.

Please do not see the 2 threads as one issue. My original question in this thread has nothing to do with etherchannel.

Just that I have a lot of customers coming with bridged interfaces on their machines (LAN and Bluetooth usually), where our BPDU-guard kicks in, and just wanted to know the reason behind this, since a bridge really is not a loop.

Hi,

The bridge really creates a loop. Let me say that again, the bridge really creates a loop.

A windows box with two interfaces with bridging enabled between them behaves pretty much like a wire.

For servers:- If you want two windows NICs connected to a single VLAN for the purposes of creating a more resilient network connection then my favoured method is the one pointed to previously. Yes it involves (sort of anyway) etherchannel. In summary you configure the wndows box to do etherchannel (but MS don't call it that) and connect the two ports to different switches. You get NO etherchannel, but you do get just the sort of resilient connection that you want. The box uses one wire unless it is not working and then it switches to using the other one. HP at least seem to support this method.

snipped-for-privacy@hotmail.co.uk crashed Echelon writing news: snipped-for-privacy@d34g2000cwd.googlegroups.com:

I dont want anything other than the explanation behind the blocking, let me refrase that I am just a tad tired of supporting customers who hook up a bridged PC, cause our loop protection is kicking in :)

No, you have a loop if the BPDU packets return to -any- port on the same device. The Spanning Tree Protocol figures out which connections to cut along the whole chain of switches in order to break the loop.

If you have a device bridging between two ports on the same switch, then the effect is like connecting a wire between those two ports: it must be stopped, because otherwise a broadcast packet sent into one of the ports will come back through the other port and the switch will treat it as a new broadcast and resend it to all the ports on the same VLAN, including to the port it went into before (leading to it coming back, and the switch rebroadcasting everywhere...) This is known as a "broadcast storm". At layer 2, there is no counter equivilent to the "time to live" (TTL) of IP, so the broadcast storm will not end until the loop causing the storm is broken.

Inexpensive unmanaged "consumer" switches often are dumb enough to pass BPDU to all of the other ports, so the problem is not just with Microsoft bridging: you are in danger any time your users take it upon themselves to install a cheap switch instead of waiting for a new datajack to be installed -- or when they decide that since they can get a switch for $40 at the local computer store, why should they pay $4000 for a switch approved by the IT department.

Broadcast storms aren't localized, either: a single loopback in a remote office is going to storm and the packets are going to be sent back uplink, possibly saturating that uplink. If your switches or routers are not up to handling full "wire speed", then they can get overwhelmed by the remote broadcast storm, so large parts of your critical infrastructure can potentially be taken down by a single accidental cross-wiring or a single Microsoft bridge.

There is an obvious lesson here: unmanaged switches and cheap routers might be much more affordable, but they can lead to huge network problems. You need at least managed switches (that will use STP) for all of your critical infrastructure.

snipped-for-privacy@hushmail.com (Walter Roberson) crashed Echelon writing news:%yxSg.64548$R63.55798@pd7urf1no:

As stated we are talking about Windows Bridge mode between 2 different medias, well more or less what I see most often. A bridge between the LAN port and Bluetooth, firewire, wireless etc.

So basically the bridge service in XP should return BPDU packets to the LAN port, either locally or the secondary media in the bridge mode.

Broadcast storm enabled as well, just for secondary protection.

BPDU-guard is a feature you enable on the switch, and works in conjunction with portfast. If you have "bpdu-guard" enabled and you have "spanning-tree portfast" configured on a port, the switch will shut down the port if it SEES a bdpu packet incoming on the port. If you don't want this behavoir, you can either a) turn off bdpu-guard, or b) turn off spanning-tree portfast on that port.

Scott