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

[Bart De Schuymer <bdschuym@pandora.be>]

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

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

[-- Attachment #2: patch_brouting_while_learning.diff --]
[-- Type: text/x-patch, Size: 591 bytes --]

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