ebtables processing... - Networking

This is a discussion on ebtables processing... - Networking ; Hi - I'm mucking around with this command at work, and I'm not quite clear on the packet processing logic within the Linux bridging code. What I'm trying to do are the following setup commands on a router, with IP ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: ebtables processing...

  1. ebtables processing...

    Hi -

    I'm mucking around with this command at work, and I'm not quite
    clear on the packet processing logic within the Linux bridging code.

    What I'm trying to do are the following setup commands on a router,
    with IP 192.168.1.1

    1) ebtables -t broute -P BROUTING DROP
    2) ebtables -t broute -A BROUTING -p IPv4 --ip-dst 192.168.1.1 -i
    atm0 -j ACCEPT

    What I'm hoping to accomplish here is to set the broute table to
    always send its packets to the routing code, EXCEPT for frames with a
    destination IP of 192.168.1.1.

    So, am I correct in assuming that any frames with IPv4 destination of
    192.168.1.1 will be bridged over to the ATM interface. So
    essentially, I can't ping the router's IP?

    But I guess my central question is, what's the processing order

    1) any rules in the chain and THEN
    2) the default policy in the broute table

    Sorry if I'm not more clear...I'm still trying to wrap my head around
    this feature, and the man pages only go so far.

    Thanks, Charles.

  2. Re: ebtables processing...

    On Sep 16, 3:04*pm, shokwave wrote:

    > * *I'm mucking around with this command at work, and I'm not quite
    > clear on the packet processing logic within the Linux bridging code.
    >
    > What I'm trying to do are the following setup commands on a router,
    > with IP 192.168.1.1
    >
    > 1) *ebtables -t broute -P BROUTING DROP
    > 2) *ebtables -t broute -A BROUTING -p IPv4 --ip-dst 192.168.1.1 -i
    > atm0 -j ACCEPT
    >
    > What I'm hoping to accomplish here is to set the broute table to
    > always send its packets to the routing code, EXCEPT for frames with a
    > destination IP of 192.168.1.1.
    >
    > So, am I correct in assuming that any frames with IPv4 destination of
    > 192.168.1.1 will be bridged over to the ATM interface. *So
    > essentially, I can't ping the router's IP?


    No. Since bridging is the normal default action of this chain, the net
    effect of these rules is to route packets not to 192.168.1.1 but to
    keep the normal behavior of all other packets. So if you could ping
    192.168.1.1 before adding these two rules, you still can -- since no
    change is made to those packets. They are ACCEPTed by this chain, just
    as they were before.

    In the BROUTING chain, 'DROP' means to route. 'ACCEPT' means to follow
    the normal process for the bridging interface, which is to bridge
    (possibly to the local machine, since it is also connected to the
    bridge).

    > But I guess my central question is, what's the processing order
    >
    > 1) any rules in the chain and THEN
    > 2) the default policy in the broute table


    Correct.

    > Sorry if I'm not more clear...I'm still trying to wrap my head around
    > this feature, and the man pages only go so far.


    This rules bumps all packets not to the local IP into the routing
    chain. It prevents all non-local packets from being bridged.

    DS

  3. Re: ebtables processing...

    Hello,

    shokwave a écrit :
    >
    > What I'm trying to do are the following setup commands on a router,
    > with IP 192.168.1.1
    >
    > 1) ebtables -t broute -P BROUTING DROP
    > 2) ebtables -t broute -A BROUTING -p IPv4 --ip-dst 192.168.1.1 -i
    > atm0 -j ACCEPT
    >
    > What I'm hoping to accomplish here is to set the broute table to
    > always send its packets to the routing code, EXCEPT for frames with a
    > destination IP of 192.168.1.1.
    >
    > So, am I correct in assuming that any frames with IPv4 destination of
    > 192.168.1.1 will be bridged over to the ATM interface.


    Yes, if atm0 is part of a bridge. May I ask why you want to do this ?

    > So essentially, I can't ping the router's IP?


    Why not ?

    > But I guess my central question is, what's the processing order
    >
    > 1) any rules in the chain and THEN
    > 2) the default policy in the broute table


    Correct.

  4. Re: ebtables processing...

    On Sep 16, 3:42*pm, Pascal Hambourg
    wrote:
    > Hello,
    >
    > shokwave a écrit :
    >
    >
    >
    > > What I'm trying to do are the following setup commands on a router,
    > > with IP 192.168.1.1

    >
    > > 1) *ebtables -t broute -P BROUTING DROP
    > > 2) *ebtables -t broute -A BROUTING -p IPv4 --ip-dst 192.168.1.1 -i
    > > atm0 -j ACCEPT

    >
    > > What I'm hoping to accomplish here is to set the broute table to
    > > always send its packets to the routing code, EXCEPT for frames with a
    > > destination IP of 192.168.1.1.

    >
    > > So, am I correct in assuming that any frames with IPv4 destination of
    > > 192.168.1.1 will be bridged over to the ATM interface.

    >
    > Yes, if atm0 is part of a bridge. May I ask why you want to do this ?
    >
    > > So essentially, I can't ping the router's IP?

    >
    > Why not ?
    >


    Because when I try to set up ebtables on my router to just use a
    default DROP policy, I can no longer ping the router.
    That's what I initially started off with, thinking the following would
    happen

    1) packet comes in
    2) -t broute BROUTING table says "send this up to the routing code"
    3) since the router, at 192.168.1.1 is the one being pinged, the
    loopback should catch this, and the ping should reply

    But it doesn't.

    BUT, if I set the default policy to ACCEPT, the router is pingable
    again.

    btw: eth0 (my client PC connected to router) and atm0 are in br0
    bridge)

  5. Re: ebtables processing...

    On Sep 16, 4:03*pm, shokwave wrote:

    > 1) *packet comes in
    > 2) *-t broute BROUTING table says "send this up to the routing code"
    > 3) *since the router, at 192.168.1.1 is the one being pinged, the
    > loopback should catch this, and the ping should reply
    >
    > But it doesn't.


    Because you disabled the very bridging logic you are relying on to
    make the packet work. You are trying to get IP over Ethernet without
    Ethernet, and that just won't work.

    > BUT, if I set the default policy to ACCEPT, the router is pingable
    > again.


    You have created a bridge, which makes all the Ethernet layer 2 stuff
    (like ARP) work. Then you disabled briding for, among other things,
    ARP packets/

    > btw: *eth0 (my client PC connected to router) and atm0 are in br0
    > bridge)


    Your rule don't make any sense. You may have a sensible layer 3
    policy, but you are utterly busted for layer 2. The mind cannot live
    without the body.

    DS

  6. Re: ebtables processing...

    shokwave a écrit :
    >
    > Because when I try to set up ebtables on my router to just use a
    > default DROP policy, I can no longer ping the router.


    May I ask why on earth do you want to set a default DROP policy in the
    broute/BROUTING chain ? What is your goal ?

    > That's what I initially started off with, thinking the following would
    > happen
    >
    > 1) packet comes in
    > 2) -t broute BROUTING table says "send this up to the routing code"
    > 3) since the router, at 192.168.1.1 is the one being pinged, the
    > loopback should catch this, and the ping should reply


    Are you talking about the loopback interface lo ? If so, what does it
    have to do here ? It only concerns traffic from a host to itself.

    > btw: eth0 (my client PC connected to router) and atm0 are in br0
    > bridge)


    If you try to ping the router's address from the client, packets arrive
    on eth0, not atm0.

    Also, I'm afraid your plan forgot about the ARP protocol, as mentionned
    by David. Here is what probably happens.

    The client wants to send an IP packet with an ICMP echo request (ping)
    to 192.168.1.1. Before it must learn the associated MAC address using
    the ARP protocol, which is distinct from IP. It broadcasts an ARP query
    for 192.168.1.1 on the link. The ARP query arrives at the interface
    eth0, which is part of the bridge br0, so the packet goes through
    ebtables and reaches the BROUTING chain in the broute table. As the
    packet does not match the only rule in that chain, the default policy
    DROP is applied. As you know, DROP in that chain means that the packet
    must be "routed" instead of bridged. So instead of being handed to the
    bridge, it is treated as a regular packet received on eth0. If eth0 is
    bound to the IPv4 stack [1], it is handed to the ARP layer of the
    network stack.

    You can check which interfaces are bound to IPv4 with :
    $ ls /proc/sys/net/ipv4/conf/

    Note that an ethernet interface is not bound to IPv4 stack by default,
    until an IPv4 address is assigned to it. You can bind an interface
    without assigning it an address with :
    $ ifconfig 0.0.0.0

    Let's assume eth0 is bound to the IPv4 stack. So the ARP request is
    handed to the ARP layer. By default the ARP layer sends a reply for
    192.168.1.1 through eth0 with the MAC address of eth0 to the client.

    Now the client can send the IP packet containing the ping request to
    192.168.1.1 using the MAC address of eth0 advertised in the ARP reply.
    The paquet arrives at eth0 and reaches the BROUTING chain in the broute
    table. As the packet matches the only rule in that chain, the target
    ACCEPT is applied, meaning that the packet is handed to the bridge. The
    destination MAC address is known by the bridge as "local", because it
    belongs to one of the bridged interfaces. So the packet is delivered to
    the local IPv4 stack as received on br0.

    Now the router wants to reply to the ping. Its IPv4 routing table tells
    it that the destination is reachable via br0, so the information from
    the previous ARP request received on eth0 is ignored. It broadcasts an
    ARP query on br0, and expects a reply received on br0. But the ARP reply
    won't match the ebtables rule, so it will be "routed" and received on
    eth0 instead of br0. The router does not receive an ARP reply on br0 and
    cannot send the ping reply.

+ Reply to Thread