[Bridge] IP address on physcial interface instead of bridge interface?

Joakim Tjernlund joakim.tjernlund at transmode.se
Mon Mar 29 01:34:26 PDT 2010


Bart De Schuymer <bdschuym at pandora.be> wrote on 2010/03/29 09:46:47:
>
> Joakim Tjernlund wrote:
> > Joakim Tjernlund/Transmode wrote on 2010/03/28 21:04:11:
> >> Joakim Tjernlund/Transmode wrote on 2010/03/28 20:27:10:
> >>> Bart De Schuymer <bdschuym at pandora.be> wrote on 2010/03/28 14:48:52:
> >>>> Stephen Hemminger schreef:
> >>>>> If you read the network receive code path in the kernel, you
> >>>>> will see that there is a special hook used. Basically,
> >>>>>
> >>>>>   if received_interface_is_part_of_bridge(incoming_interface)
> >>>>>   then process_bridged_packet(packet)
> >>>>>
> >>>>> Then bridge looks at packet and decides whether it is local or forwarded.
> >>>>> The problem is with your application if it wants to use eth0 directly.
> >>>>>
> >>>>>
> >>>> The ebtables brouting chain was designed to enable you to do this.
> >>> Can you give me an example?
> >> Found this on the net:
> >> ebtables -t broute -A BROUTING -p 0800  -i eth1 --ip-dst 192.168.1.16 -j DROP
> >> ebtables -t broute -A BROUTING -p 0806  -i eth1 -d 00:06:9C:00:B2:FB -j DROP
> >> ebtables -t broute -A BROUTING -p 0806  -i eth1 --arp-ip-dst 192.168.1.16 -j DROP
> >>
> >> 192.168.1.16 and 00:06:9C:00:B2:FB are the IP and MAC addresses of eth1.
> >>
> >> Then add eth1 to the bridge and it appears to be working as I want.
> >> Are there any "gotcha's" with this method?
> >
> > What about other protocols such as pppoe and OSPF, will these work over eth1 too?
> > Are outgoing pkgs from the host bridged or just sent out over eth1?
> >
> >     Jocke
>
> The ebtables rules in the brouting chain see all traffic arriving on the
> bridge port (currently unless the port is in learning state). So as long
> as your setup is correct it should work with pppoe and OSPF too.

Ah good. So the outgoing traffic will go out over the bridge port too and
thereby be bridged?

Still I wonder about OSPF. This protocol sends pks to multicast IP address
224.0.0.5/6 so how are these picked up by the broute rule?

How is pppoe picked up by the broute rule? The ethertype is different from ipv4
so I don't understand how it manages to do that.

> I already mailed you and the list on 26/03, but that message seems to
> have been ignored by Stephen and you. The message describes the temporal
> loss of connectivity when the bridge brought up and the bridge port is
> in learning state. As mentioned, this is easily fixed with the simple
> patch (in attachment).

Sorry, but I am not familiar enough with the bride code to comment on that.
It is better if Stephen does that who knows the code/function of the bridge much
better than I do.

> <quote>
> Unfortunately this is impossible in the current bridge implementation
> without temporarily losing connectivity because the ebtables BROUTING
> chain isn't traversed while the bridge port is in learning state. But
> with the patch below, the following scenario works without loss of
> connectivity:
> # (Suppose the bridge isn't configured yet)
> ifconfig eth0 $IP
> # (the routing table should be correct now, if not you need to do it
> yourself)
> # (the ebtables rules below will be effective once br0 is up)
> # direct local IP traffic to eth0
> ebtables -t broute -A BROUTING -p ipv4 -i eth0 --ip-dst $IP -j DROP
> # direct arp replies for $MAC_OF_ETH0 to eth0
> ebtables -t broute -A BROUTING -p arp -i eth0 -d $MAC_OF_ETH0 -j DROP
> # direct arp requests for $IP to eth0
> ebtables -t broute -A BROUTING -p arp -i eth0 --arp-ip-dst $IP -j DROP
> brctl addbr br0
> # make sure to bring br0 up before adding the interface
> ifconfig br0 up
> brctl addif br0 eth0
>
> If you don't mind loss of connectivity while the bridge port is in
> learning state, you don't need the patch.
> </quote>
>
>
> --
> Bart De Schuymer
> www.artinalgorithms.be
> --- linux-2.6.33/net/bridge/br_input.c   2010-02-24 19:52:17.000000000 +0100
> +++ linux-2.6.33-uml/net/bridge/br_input.c   2010-03-26 09:21:50.000000000 +0100
> @@ -148,14 +148,13 @@ struct sk_buff *br_handle_frame(struct n
>  forward:
>     switch (p->state) {
>     case BR_STATE_FORWARDING:
> +   case BR_STATE_LEARNING:
>        rhook = rcu_dereference(br_should_route_hook);
>        if (rhook != NULL) {
>           if (rhook(skb))
>              return skb;
>           dest = eth_hdr(skb)->h_dest;
>        }
> -      /* fall through */
> -   case BR_STATE_LEARNING:
>        if (!compare_ether_addr(p->br->dev->dev_addr, dest))
>           skb->pkt_type = PACKET_HOST;
>



More information about the Bridge mailing list