From: Phil Karn <karn@philkarn.net>
To: bridge@lists.linux-foundation.org
Subject: Re: [Bridge] Re :Re: Re :Re: Re :Re: Bridging LACP (802.3ad) frames not working
Date: Thu, 18 Mar 2010 02:06:37 -0700 [thread overview]
Message-ID: <4BA1ED1D.80806@philkarn.net> (raw)
In-Reply-To: <8cad0aa1001201014ga54cf4br7b77577e874b4472@mail.gmail.com>
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.
next prev parent reply other threads:[~2010-03-18 9:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-19 19:44 [Bridge] Re :Re: Re :Re: Re :Re: Bridging LACP (802.3ad) frames not working yavetskiy
2010-01-20 16:31 ` Yavetskiy Yuriy
2010-01-20 17:54 ` Stephen Hemminger
2010-01-20 18:14 ` Jean-Michel Hautbois
2010-03-18 9:06 ` Phil Karn [this message]
-- strict thread matches above, loose matches on Subject: below --
2010-01-13 16:53 Jean-Michel Hautbois
2010-01-13 16:55 ` Stephen Hemminger
2010-01-13 17:21 ` Jean-Michel Hautbois
2010-01-13 17:42 ` Jean-Michel Hautbois
2010-01-13 16:30 [Bridge] " Stephen Hemminger
2010-01-13 16:47 ` [Bridge] Re :Re: " jhautbois
2010-01-13 16:49 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BA1ED1D.80806@philkarn.net \
--to=karn@philkarn.net \
--cc=bridge@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).