[Bridge] Re :Re: Re :Re: Re :Re: Bridging LACP (802.3ad) frames not working

[Bridge] Re :Re: Re :Re: Re :Re: Bridging LACP (802.3ad) frames not working

[jhautbois]

[-- Attachment #1: Type: text/plain, Size: 407 bytes --]

(snip)
> I meant they get processed locally, before that they were dropped.

> The best solution is to write an ebtables rule to forward them.

Mmh, I can understand that, but I can't see which kind of rule would do  
that.
Something like :
ebtables -A FORWARDING -p 0x8809 -j ACCEPT ??

But I think this will not do anything, because it is forwarding by default.
Or there is something I can't see :-).

JM

[-- Attachment #2: Type: text/html, Size: 484 bytes --]

Re: [Bridge] Re :Re: Re :Re: Re :Re: Bridging LACP (802.3ad) frames not working

[Stephen Hemminger]

On Wed, 13 Jan 2010 16:47:14 +0000
jhautbois@gmail.com wrote:

> (snip)
> > I meant they get processed locally, before that they were dropped.
> 
> > The best solution is to write an ebtables rule to forward them.
> 
> Mmh, I can understand that, but I can't see which kind of rule would do  
> that.
> Something like :
> ebtables -A FORWARDING -p 0x8809 -j ACCEPT ??
> 
> But I think this will not do anything, because it is forwarding by default.
> Or there is something I can't see :-).
> 

You need to put the rule on the local input not forwarding chain.

Re: [Bridge] Re :Re: Re :Re: Re :Re: Bridging LACP (802.3ad) frames not working

[Jean-Michel Hautbois]

2010/1/13 Stephen Hemminger <shemminger@vyatta.com>:
> On Wed, 13 Jan 2010 16:47:14 +0000
> jhautbois@gmail.com wrote:
>
>> (snip)
>> > I meant they get processed locally, before that they were dropped.
>>
>> > The best solution is to write an ebtables rule to forward them.
>>
>> Mmh, I can understand that, but I can't see which kind of rule would do
>> that.
>> Something like :
>> ebtables -A FORWARDING -p 0x8809 -j ACCEPT ??
>>
>> But I think this will not do anything, because it is forwarding by default.
>> Or there is something I can't see :-).
>>
>
> You need to put the rule on the local input not forwarding chain.
>

You mean :
ebtables -A INPUT -p 0x8809 -j ACCEPT ?

According to my understanding of this graph :
http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png
I can't understand why it has to be in the INPUT...

JM

Re: [Bridge] Re :Re: Re :Re: Re :Re: Bridging LACP (802.3ad) frames not working

[Stephen Hemminger]

On Wed, 13 Jan 2010 17:53:10 +0100
Jean-Michel Hautbois <jhautbois@gmail.com> wrote:

> 2010/1/13 Stephen Hemminger <shemminger@vyatta.com>:
> > On Wed, 13 Jan 2010 16:47:14 +0000
> > jhautbois@gmail.com wrote:
> >
> >> (snip)
> >> > I meant they get processed locally, before that they were dropped.
> >>
> >> > The best solution is to write an ebtables rule to forward them.
> >>
> >> Mmh, I can understand that, but I can't see which kind of rule would do
> >> that.
> >> Something like :
> >> ebtables -A FORWARDING -p 0x8809 -j ACCEPT ??
> >>
> >> But I think this will not do anything, because it is forwarding by default.
> >> Or there is something I can't see :-).
> >>
> >
> > You need to put the rule on the local input not forwarding chain.
> >
> 
> You mean :
> ebtables -A INPUT -p 0x8809 -j ACCEPT ?
> 
> According to my understanding of this graph :
> http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png
> I can't understand why it has to be in the INPUT...

Because bridge input processing puts all link local packets to
the local input path.

Re: [Bridge] Re :Re: Re :Re: Re :Re: Bridging LACP (802.3ad) frames not working

[Jean-Michel Hautbois]

2010/1/13 Stephen Hemminger <shemminger@vyatta.com>:
> On Wed, 13 Jan 2010 17:53:10 +0100
> Jean-Michel Hautbois <jhautbois@gmail.com> wrote:
>
>> 2010/1/13 Stephen Hemminger <shemminger@vyatta.com>:
>> > On Wed, 13 Jan 2010 16:47:14 +0000
>> > jhautbois@gmail.com wrote:
>> >
>> >> (snip)
>> >> > I meant they get processed locally, before that they were dropped.
>> >>
>> >> > The best solution is to write an ebtables rule to forward them.
>> >>
>> >> Mmh, I can understand that, but I can't see which kind of rule would do
>> >> that.
>> >> Something like :
>> >> ebtables -A FORWARDING -p 0x8809 -j ACCEPT ??
>> >>
>> >> But I think this will not do anything, because it is forwarding by default.
>> >> Or there is something I can't see :-).
>> >>
>> >
>> > You need to put the rule on the local input not forwarding chain.
>> >
>>
>> You mean :
>> ebtables -A INPUT -p 0x8809 -j ACCEPT ?
>>
>> According to my understanding of this graph :
>> http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png
>> I can't understand why it has to be in the INPUT...
>
> Because bridge input processing puts all link local packets to
> the local input path.
>

It is not working.
I am sending LACP packets through a link, it arrives on my first
interface, I can see it (with wireshark) in my bridge, but when I am
just adding the rule (ebtables -A INPUT -p 0x8809 -j ACCEPT) it is not
going to my second interface...

JM

Re: [Bridge] Re :Re: Re :Re: Re :Re: Bridging LACP (802.3ad) frames not working

[Jean-Michel Hautbois]

It is working.

I have to do this :
ebtables -A INPUT -p 0x8809 -j ACCEPT
ebtables -A FORWARD -p 0x8809 -j ACCEPT

When I send a packet on my first interface, it is going on my second
interface if and only if I have both INPUT and FORWARD.

Thanks for your help !!

JM

Re: [Bridge] Re :Re: Re :Re: Re :Re: Bridging LACP (802.3ad) frames not working

[yavetskiy]

Hello.

I have the same problem with bridging 802.3ad frames.

But rules:
ebtables -A INPUT -p 0x8809 -j ACCEPT
ebtables -A FORWARD -p 0x8809 -j ACCEPT
are not enough to solve this problem, it still doesn't work for me.
I have vanila kernel 2.6.32 with no patches, Debian squeeze, eth1 and  
eth2 interfaces in bridge with stp disabled.
Maybe I've missed something? Do you have any ideas?
Thank you.


--
WBR
Yavetkiy Yuriy

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: [Bridge] Re :Re: Re :Re: Re :Re: Bridging LACP (802.3ad) frames not working

[Yavetskiy Yuriy]

Hello.

I solve my problem without ebtables.
Just add to net/bridge/br_input.c next strings (with +):

        if (unlikely(is_link_local(dest))) {
                /* Pause frames shouldn't be passed up by driver anyway */
                if (skb->protocol == htons(ETH_P_PAUSE))
                        goto drop;

+                /* Don't touch SLOW frames (LACP, etc.) */
+               if (skb->protocol == htons(ETH_P_SLOW))
+                        goto forward;

                /* If STP is turned off, then forward */
                if (p->br->stp_enabled == BR_NO_STP && dest[5] == 0)
                        goto forward;

                if (NF_HOOK(PF_BRIDGE, NF_BR_LOCAL_IN, skb, skb->dev,
                            NULL, br_handle_local_finish))
                        return NULL;    /* frame consumed by filter */
                else
                        return skb;     /* continue processing */
        }

and after I've compiled it to kernel 802.3ad frames became pass through 
linux bridge.


yavetskiy@kpi.ua wrote:
> Hello.
>
> I have the same problem with bridging 802.3ad frames.
>
> But rules:
> ebtables -A INPUT -p 0x8809 -j ACCEPT
> ebtables -A FORWARD -p 0x8809 -j ACCEPT
> are not enough to solve this problem, it still doesn't work for me.
> I have vanila kernel 2.6.32 with no patches, Debian squeeze, eth1 and  
> eth2 interfaces in bridge with stp disabled.
> Maybe I've missed something? Do you have any ideas?
> Thank you.
>
>
> --
> WBR
> Yavetkiy Yuriy
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge
>   


-- 
WBR
Yavetskiy Yuriy
ULTI-RIPE

Re: [Bridge] Re :Re: Re :Re: Re :Re: Bridging LACP (802.3ad) frames not working

[Stephen Hemminger]

On Wed, 20 Jan 2010 18:31:06 +0200
Yavetskiy Yuriy <yavetskiy@kpi.ua> wrote:

> Hello.
> 
> I solve my problem without ebtables.
> Just add to net/bridge/br_input.c next strings (with +):
> 
>         if (unlikely(is_link_local(dest))) {
>                 /* Pause frames shouldn't be passed up by driver anyway */
>                 if (skb->protocol == htons(ETH_P_PAUSE))
>                         goto drop;
> 
> +                /* Don't touch SLOW frames (LACP, etc.) */
> +               if (skb->protocol == htons(ETH_P_SLOW))
> +                        goto forward;
> 

Fine for your case, but in general it is wrong to forward these
frames. 


-- 

Re: [Bridge] Re :Re: Re :Re: Re :Re: Bridging LACP (802.3ad) frames not working

[Jean-Michel Hautbois]

2010/1/20 Stephen Hemminger <shemminger@linux-foundation.org>:
> On Wed, 20 Jan 2010 18:31:06 +0200
> Yavetskiy Yuriy <yavetskiy@kpi.ua> wrote:
>
>> Hello.
>>
>> I solve my problem without ebtables.
>> Just add to net/bridge/br_input.c next strings (with +):
>>
>>         if (unlikely(is_link_local(dest))) {
>>                 /* Pause frames shouldn't be passed up by driver anyway */
>>                 if (skb->protocol == htons(ETH_P_PAUSE))
>>                         goto drop;
>>
>> +                /* Don't touch SLOW frames (LACP, etc.) */
>> +               if (skb->protocol == htons(ETH_P_SLOW))
>> +                        goto forward;
>>
>
> Fine for your case, but in general it is wrong to forward these
> frames.

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...

Regards,
JM

Re: [Bridge] Re :Re: Re :Re: Re :Re: Bridging LACP (802.3ad) frames not working

[Phil Karn]

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.