On 1/20/2010 10:14 AM, Jean-Michel Hautbois wrote: > I agree, and once again, I wish we could add a flag that enables > forwarding these frames. > A flag that would be off by default. > I don't understand why this could be problematic... I can think of an admittedly arcane case where forwarding this type of traffic might get someone in trouble. But it's the arcane cases that can have you pulling your hair out. A few months ago I began to experiment with bridging on my Linux system at work. Although it was impossible for what I was doing to create a bridging loop, I decided to play it safe and enable STP anyway. A minute or so later I realized that my network connection was down - the link light was actually off on the port connected to the cable coming out of the wall. To make a long story short, I'd stumbled into a mechanism that the IT guys at work had implemented, for better or worse, to keep people from running "unauthorized" bridges. When their switch saw my BPDU frames, presumably by their special multicast address, it disabled my port for something like 10 minutes. Apparently they use some sort of commercially available product to do this. Since then I've noticed that at least some managed switches have the built-in capability to turn ports off when they see traffic that an administrator decides he doesn't like. I don't know if they also disable a port when it sees one of the other reserved MAC addresses (besides 01:80:c2:0:0:0), or perhaps one of the special 16-bit types reserved for the slow control protocols. But if lots of bridges start forwarding management frames that normally aren't forwarded, then someone who trips a booby trap like the one I did might end up disabling a much larger chunk of a network than a single port. And it might take a long time to figure out why. _______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/bridge
