2010/1/12 richardvoigt@xxxxxxxxx <richardvoigt@xxxxxxxxx>: > On Tue, Jan 12, 2010 at 4:04 PM, Ross Vandegrift <ross@xxxxxxxxxxx> wrote: >> On Tue, Jan 12, 2010 at 09:40:30PM +0000, jhautbois@xxxxxxxxx wrote: >>> This is exactly the problem. >>> But, sounds like it is not possible... ? >> >> You could run a custom version of the bridge driver to enable bridging >> of frames sent to the bridge-management MAC addresses. Some folks >> have talked about doing similar things to enable bridging of STP. >> >> Doing that with STP makes a bit more sense to me (since there are >> valid networks that could be constructed that way). But you'll be >> breaking a pretty fundamental assumption of LACP.... > > LACP is between peers, not to the nearest connected device (generally > an ethernet cable). As long as the intermediate link acts just like a > wire and passes everything, LACP shouldn't care. And there are some > reasonable cases to want a Linux box to look like a piece of cable > (e.g. wiretap, timed lockdown, satellite network simulator which > inserts delay and errors, etc.) to the surrounding network. Of > course, whether seeing just one link out of an aggregation bundle is > useful is debatable, but Linux ought to be able to support it. I've > been bitten before by adding a new switch into an STP setup and having > it eat STP packets even though STP processing was disabled. So count > me as another vote for (at least the possibility of) layer 1-esque > transparent bridging. I think it would be interesting to have the ability to activate this functionality. AFAIK, this could be done in the br_handle_frame function, testing the skb->protocol and comparing it with ETH_P_SLOW. This could be conditionned by a flag, and this flag would be unabled by default. Why is this a problem ? If you tell this is not good, unless you know what you are doing, where is the problem ? This is a user problem, it is a functionality. If you misuse it, this is not a kernel problem... Best Regards, JM _______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/bridge
