[Bridge] [ebtables]Explanation of the packet flow...

[Bridge] [ebtables]Explanation of the packet flow...

[Jean-Michel Hautbois]

Hi everybody !

I am trying to understand the "PacketFlow.png" image from the website.
I have several misunderstanding, especially on the "Bridging Decision" circles.

I would like to understand which way a packet takes when the rule on
-A INPUT -j ACCEPT is on, for example. When looking at the packet
flow, I would say it is going to the "routing decision" circle, but, I
am not sure...

I would also like to understand what is necessary in order to have a
packet transparently directed from one interface to the other. I would
say that only the "-A FORWARD -j ACCEPT" rule is necessary, but
Wireshark doesn't agree with me...

Thanks in advance for your help.
Best Regards,
JM

Re: [Bridge] [ebtables]Explanation of the packet flow...

[Bart De Schuymer]

Jean-Michel Hautbois schreef:
> Hi everybody !
>
> I am trying to understand the "PacketFlow.png" image from the website.
> I have several misunderstanding, especially on the "Bridging Decision" circles.
>
> I would like to understand which way a packet takes when the rule on
> -A INPUT -j ACCEPT is on, for example. When looking at the packet
> flow, I would say it is going to the "routing decision" circle, but, I
> am not sure...
>
>   
It is handed to the IP layer, which includes a routing decision.

> I would also like to understand what is necessary in order to have a
> packet transparently directed from one interface to the other. I would
> say that only the "-A FORWARD -j ACCEPT" rule is necessary, but
> Wireshark doesn't agree with me...
>
>   
Ebtables is used to filter bridged traffic. You can't use ebtables to
direct a packet to another interface.

Bart

-- 
Bart De Schuymer
www.artinalgorithms.be

Re: [Bridge] [ebtables]Explanation of the packet flow...

[Jean-Michel Hautbois]

2010/1/16 Bart De Schuymer <bdschuym@pandora.be>:
> Jean-Michel Hautbois schreef:
>> Hi everybody !
>>
>> I am trying to understand the "PacketFlow.png" image from the website.
>> I have several misunderstanding, especially on the "Bridging Decision" circles.
>>
>> I would like to understand which way a packet takes when the rule on
>> -A INPUT -j ACCEPT is on, for example. When looking at the packet
>> flow, I would say it is going to the "routing decision" circle, but, I
>> am not sure...
>>
>>
> It is handed to the IP layer, which includes a routing decision.

But this is only true for L3 layer ?
Or routing decision is at a L2 level, in order to decide whether to
bridge should route a packet up to the IP layer or not. That's it ?

>> I would also like to understand what is necessary in order to have a
>> packet transparently directed from one interface to the other. I would
>> say that only the "-A FORWARD -j ACCEPT" rule is necessary, but
>> Wireshark doesn't agree with me...
>>
>>
> Ebtables is used to filter bridged traffic. You can't use ebtables to
> direct a packet to another interface.

Well, when a bridge is between two interfaces, this is quite the same
than saying it is forwarded from one to the other, in my point of
view. No ?

JM

Re: [Bridge] [ebtables]Explanation of the packet flow...

[Bart De Schuymer]

Jean-Michel Hautbois schreef:
> 2010/1/16 Bart De Schuymer <bdschuym@pandora.be>:
>   
>> Jean-Michel Hautbois schreef:
>>     
>>> Hi everybody !
>>>
>>> I am trying to understand the "PacketFlow.png" image from the website.
>>> I have several misunderstanding, especially on the "Bridging Decision" circles.
>>>
>>> I would like to understand which way a packet takes when the rule on
>>> -A INPUT -j ACCEPT is on, for example. When looking at the packet
>>> flow, I would say it is going to the "routing decision" circle, but, I
>>> am not sure...
>>>
>>>
>>>       
>> It is handed to the IP layer, which includes a routing decision.
>>     
>
> But this is only true for L3 layer ?
> Or routing decision is at a L2 level, in order to decide whether to
> bridge should route a packet up to the IP layer or not. That's it ?
>
>   
The packet flow picture describes the detailed IP packet flow. This is
clearly mentioned in the accompanying document. If you don't know on
what layer routing is done, please try looking it up.
>>> I would also like to understand what is necessary in order to have a
>>> packet transparently directed from one interface to the other. I would
>>> say that only the "-A FORWARD -j ACCEPT" rule is necessary, but
>>> Wireshark doesn't agree with me...
>>>
>>>
>>>       
>> Ebtables is used to filter bridged traffic. You can't use ebtables to
>> direct a packet to another interface.
>>     
>
> Well, when a bridge is between two interfaces, this is quite the same
> than saying it is forwarded from one to the other, in my point of
> view. No ?
>
>   
The bridge indeed forwards the packets, not ebtables. You don't need
ebtables for that unless you want to filter the traffic.

Bart

-- 
Bart De Schuymer
www.artinalgorithms.be

Re: [Bridge] [ebtables]Explanation of the packet flow...

[Jean-Michel Hautbois]

>> Well, when a bridge is between two interfaces, this is quite the same
>> than saying it is forwarded from one to the other, in my point of
>> view. No ?
>>
>>
> The bridge indeed forwards the packets, not ebtables. You don't need
> ebtables for that unless you want to filter the traffic.

Well, let's take my example.
I have a bridge between eth0 and eth1. This bridge is stp disabled,
and the ebtables filter table accepts input, forward and output.

I didn't specify any filtering rule.
When I send a packet (LACP for me), it is not going from one eth to the other.
I have to say, explicitly, that the packet with ethertype 0x8809 are
accepted in "forward".

This is why I have some difficulties understanding the packetFlow,
because, depending on the protocol, the behaviour doesn't seem to be
the same...

Regards,
JM

Re: [Bridge] [ebtables]Explanation of the packet flow...

[Bart De Schuymer]

Jean-Michel Hautbois schreef:
>>> Well, when a bridge is between two interfaces, this is quite the same
>>> than saying it is forwarded from one to the other, in my point of
>>> view. No ?
>>>
>>>
>>>       
>> The bridge indeed forwards the packets, not ebtables. You don't need
>> ebtables for that unless you want to filter the traffic.
>>     
>
> Well, let's take my example.
> I have a bridge between eth0 and eth1. This bridge is stp disabled,
> and the ebtables filter table accepts input, forward and output.
>
> I didn't specify any filtering rule.
> When I send a packet (LACP for me), it is not going from one eth to the other.
> I have to say, explicitly, that the packet with ethertype 0x8809 are
> accepted in "forward".
>
> This is why I have some difficulties understanding the packetFlow,
> because, depending on the protocol, the behaviour doesn't seem to be
> the same...
>
>   
You don't provide enough information for us (at least for me) to tell
you what's wrong. It's probably something as simple as changing the
default policy of the FORWARD chain from DROP to ACCEPT. Just rmmod the
ebtables kernel module if you don't need it...

Bart

-- 
Bart De Schuymer
www.artinalgorithms.be

Re: [Bridge] [ebtables]Explanation of the packet flow...

[Jean-Michel Hautbois]

2010/1/17 Bart De Schuymer <bdschuym@pandora.be>:
> Jean-Michel Hautbois schreef:
>>>> Well, when a bridge is between two interfaces, this is quite the same
>>>> than saying it is forwarded from one to the other, in my point of
>>>> view. No ?
>>>>
>>>>
>>>>
>>> The bridge indeed forwards the packets, not ebtables. You don't need
>>> ebtables for that unless you want to filter the traffic.
>>>
>>
>> Well, let's take my example.
>> I have a bridge between eth0 and eth1. This bridge is stp disabled,
>> and the ebtables filter table accepts input, forward and output.
>>
>> I didn't specify any filtering rule.
>> When I send a packet (LACP for me), it is not going from one eth to the other.
>> I have to say, explicitly, that the packet with ethertype 0x8809 are
>> accepted in "forward".
>>
>> This is why I have some difficulties understanding the packetFlow,
>> because, depending on the protocol, the behaviour doesn't seem to be
>> the same...
>>
>>
> You don't provide enough information for us (at least for me) to tell
> you what's wrong. It's probably something as simple as changing the
> default policy of the FORWARD chain from DROP to ACCEPT. Just rmmod the
> ebtables kernel module if you don't need it...
>

Default policy of the FORWARD chain is on ACCEPT.
I can't rmmod, because I do need ebtables for one of the interfaces.

JM