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

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

[Joakim Tjernlund]

Currently it isn't possible to to have an IP address on one of interfaces
attached to a bridge, one must always put the IP address on the bridge interface itself.

I wonder if there is a technical reason for that? I would love to be able
to be able to chose any ONE interface attached to the bridge.
Example:
Assume br0 bridge with two interfaces attached, eth0 and eth1.
Then I would like to assign the IP address to eth0 instead of
br0. Ideally one should be able to just attach eth0 with an existing IP address
to br0.

    Jocke

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

[richardvoigt]

On Thu, Mar 25, 2010 at 11:42 AM, Joakim Tjernlund
<joakim.tjernlund@transmode.se> wrote:
>
> Currently it isn't possible to to have an IP address on one of interfaces
> attached to a bridge, one must always put the IP address on the bridge interface itself.
>
> I wonder if there is a technical reason for that? I would love to be able
> to be able to chose any ONE interface attached to the bridge.
> Example:
> Assume br0 bridge with two interfaces attached, eth0 and eth1.
> Then I would like to assign the IP address to eth0 instead of
> br0. Ideally one should be able to just attach eth0 with an existing IP address
> to br0.

Migrating existing configuration to the bridge at the time a port is
added (and back to one member when the bridge is dissolved) has been
discussed quite a bit recently, and is completely different from
trying to independently configure L3 state of bridge ports at
arbitrary times.


>
>    Jocke
>
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge
>

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

[Joakim Tjernlund]

"richardvoigt@gmail.com" <richardvoigt@gmail.com> wrote on 2010/03/25 18:03:34:
>
> On Thu, Mar 25, 2010 at 11:42 AM, Joakim Tjernlund
> <joakim.tjernlund@transmode.se> wrote:
> >
> > Currently it isn't possible to to have an IP address on one of interfaces
> > attached to a bridge, one must always put the IP address on the bridge
> interface itself.
> >
> > I wonder if there is a technical reason for that? I would love to be able
> > to be able to chose any ONE interface attached to the bridge.
> > Example:
> > Assume br0 bridge with two interfaces attached, eth0 and eth1.
> > Then I would like to assign the IP address to eth0 instead of
> > br0. Ideally one should be able to just attach eth0 with an existing IP address
> > to br0.
>
> Migrating existing configuration to the bridge at the time a port is
> added (and back to one member when the bridge is dissolved) has been
> discussed quite a bit recently, and is completely different from
> trying to independently configure L3 state of bridge ports at
> arbitrary times.

Sorry but I could not find that discussion but it doesn't sound as
what I was after. Basically I want the eth0 I/F keeping its IP address
and take over the roll of the br0 I/F when it has an IP address.

 Jocke

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

[Nicolas de Pesloüan]

Joakim Tjernlund wrote:
[...]
> 
> Sorry but I could not find that discussion but it doesn't sound as
> what I was after. Basically I want the eth0 I/F keeping its IP address
> and take over the roll of the br0 I/F when it has an IP address.

Can you please try to explain the reason why you would like the bridge members to have an IP, 
instead of the br0 interface ?

What is the expected result ? Until now, you described a solution (having an IP address on the 
bridge members), but not the real problem you are trying to solve.

Basically, a bridge is a level 2 link between the bridge members. An IP address is not required for 
the bridge to provide L2 connectivity between the members. But, if the host hosting the bridge need 
to be able to send/receive packets to/from bridge members, then it use the br0 interface. Using br0 
to send packets let the bridge decide on which members to forward each packets. Using br0 to receive 
packets allow you not to listen on every members at the same time. For this reason, it is normal to 
give an IP address to th br0 interface and to leave the bridge members without any IP address.

HTH

	Nicolas.

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

[Joakim Tjernlund]

Nicolas de Pesloüan <nicolas.2p.debian@free.fr> wrote on 2010/03/25 22:03:06:
>
> Joakim Tjernlund wrote:
> [...]
> >
> > Sorry but I could not find that discussion but it doesn't sound as
> > what I was after. Basically I want the eth0 I/F keeping its IP address
> > and take over the roll of the br0 I/F when it has an IP address.
>
> Can you please try to explain the reason why you would like the bridge members
> to have an IP,
> instead of the br0 interface ?

Sure, our app sometimes just uses eth0 as an normal eth I/F and in some
configs eth0 needs to be bridged with other I/Fs. Moving the IP address from eth0 to
the br0 I/F is painful once the system has booted. There are services already running
on eth0 then once a user decides he needs bridged system all services needs to be restarted.

>
> What is the expected result ? Until now, you described a solution (having an
> IP address on the
> bridge members), but not the real problem you are trying to solve.
>
> Basically, a bridge is a level 2 link between the bridge members. An IP
> address is not required for
> the bridge to provide L2 connectivity between the members. But, if the host
> hosting the bridge need
> to be able to send/receive packets to/from bridge members, then it use the br0
> interface. Using br0
> to send packets let the bridge decide on which members to forward each
> packets. Using br0 to receive
> packets allow you not to listen on every members at the same time. For this
> reason, it is normal to
> give an IP address to th br0 interface and to leave the bridge members without
> any IP address.

All true, but adding an interface that is already in use to a bridge and then moving your IP address
to the br0 I/F without loosing connectivity is hard, probably impossible, with the current
bridge impl.

       Jocke

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

[Bart De Schuymer]

Joakim Tjernlund wrote:
> Nicolas de Pesloüan <nicolas.2p.debian@free.fr> wrote on 2010/03/25 22:03:06:
>   
>> Joakim Tjernlund wrote:
>> [...]
>>     
>>> Sorry but I could not find that discussion but it doesn't sound as
>>> what I was after. Basically I want the eth0 I/F keeping its IP address
>>> and take over the roll of the br0 I/F when it has an IP address.
>>>       
>> Can you please try to explain the reason why you would like the bridge members
>> to have an IP,
>> instead of the br0 interface ?
>>     
>
> Sure, our app sometimes just uses eth0 as an normal eth I/F and in some
> configs eth0 needs to be bridged with other I/Fs. Moving the IP address from eth0 to
> the br0 I/F is painful once the system has booted. There are services already running
> on eth0 then once a user decides he needs bridged system all services needs to be restarted.
>
>   
Hi,

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.

Stephen, please consider applying the patch below.

cheers,
Bart


Process the brouting decision while the bridge port is in learning state.

Signed-off-by: Bart De Schuymer <bdschuym@pandora.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;
 

-- 
Bart De Schuymer
www.artinalgorithms.be

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

[Joakim Tjernlund]

Nicolas de Pesloüan <nicolas.2p.debian@free.fr> wrote on 2010/03/25 22:03:06:
>
> Joakim Tjernlund wrote:
> [...]
> >
> > Sorry but I could not find that discussion but it doesn't sound as
> > what I was after. Basically I want the eth0 I/F keeping its IP address
> > and take over the roll of the br0 I/F when it has an IP address.
>
> Can you please try to explain the reason why you would like the bridge members
> to have an IP,
> instead of the br0 interface ?
>
> What is the expected result ? Until now, you described a solution (having an
> IP address on the
> bridge members), but not the real problem you are trying to solve.
>
> Basically, a bridge is a level 2 link between the bridge members. An IP
> address is not required for
> the bridge to provide L2 connectivity between the members. But, if the host
> hosting the bridge need
> to be able to send/receive packets to/from bridge members, then it use the br0
> interface. Using br0
> to send packets let the bridge decide on which members to forward each
> packets. Using br0 to receive
> packets allow you not to listen on every members at the same time. For this
> reason, it is normal to
> give an IP address to th br0 interface and to leave the bridge members without
> any IP address.

Figure a small picture will help so here it is:

Before adding eth0 to br0:
eth0    br0
 |
 |
HW controller

after adding eth0 to br0:
eth0
  \
   \
     br0
   /
  /
HW controller

  Jocke

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

[Nicolas de Pesloüan]

Joakim Tjernlund wrote:

> Figure a small picture will help so here it is:
> 
> Before adding eth0 to br0:
> eth0    br0
>  |
>  |
> HW controller
> 
> after adding eth0 to br0:
> eth0
>   \
>    \
>      br0
>    /
>   /
> HW controller

I don't understand your ascii art. What is HW controller ? eth0 is an hardware controller !?

	Nicolas.

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

[Joakim Tjernlund]

Nicolas de Pesloüan <nicolas.2p.debian@free.fr> wrote on 2010/03/26 21:39:33:

> From: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
> To: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> Cc: bridge@lists.linux-foundation.org
> Date: 2010/03/26 21:39
> Subject: Re: [Bridge] IP address on physcial interface instead of bridge interface?
>
> Joakim Tjernlund wrote:
>
> > Figure a small picture will help so here it is:
> >
> > Before adding eth0 to br0:
> > eth0    br0
> >  |
> >  |
> > HW controller
> >
> > after adding eth0 to br0:
> > eth0
> >   \
> >    \
> >      br0
> >    /
> >   /
> > HW controller
>
> I don't understand your ascii art. What is HW controller ? eth0 is an hardware
> controller !?
>
>    Nicolas.

eth0 is the I/F IP stack will see/use. HW controller is the ethernet HW controller,
the PCI HW if you like.

 Jocke

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

[Nicolas de Pesloüan]

Joakim Tjernlund a écrit :
> 
> Nicolas de Pesloüan <nicolas.2p.debian@free.fr> wrote on 2010/03/26 21:39:33:
> 
>> From: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
>> To: Joakim Tjernlund <joakim.tjernlund@transmode.se>
>> Cc: bridge@lists.linux-foundation.org
>> Date: 2010/03/26 21:39
>> Subject: Re: [Bridge] IP address on physcial interface instead of bridge interface?
>>
>> Joakim Tjernlund wrote:
>>
>>> Figure a small picture will help so here it is:
>>>
>>> Before adding eth0 to br0:
>>> eth0    br0
>>>  |
>>>  |
>>> HW controller
>>>
>>> after adding eth0 to br0:
>>> eth0
>>>   \
>>>    \
>>>      br0
>>>    /
>>>   /
>>> HW controller
>> I don't understand your ascii art. What is HW controller ? eth0 is an hardware
>> controller !?
>>
>>    Nicolas.
> 
> eth0 is the I/F IP stack will see/use. HW controller is the ethernet HW controller,
> the PCI HW if you like.

I tested the following setup:

# eth0 setup:

ip addr add $IP dev eth0
ip link set up dev eth0
ip route add default via $DEF_ROUTE

# bridge setup:

brctl addbr br0
brctl setfd br0 0

Then I tested the following migration sequence to move the IP addresse to br0:

ip addr add $IP dev br0
ip link set up dev br0

brctl addif br0 eth0
ip addr del $IP dev eth0
ip route add default via $DEF_ROUTE

Thanks to "brctl setfd br0 0", this migration cause no trouble to active connections.

So I cannot find a good reason to try and use eth0 as the "main" bridge interface.

Do you have a process really linked to eth0 ?

	Nicolas.

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

[Joakim Tjernlund]

Nicolas de Pesloüan <nicolas.2p.debian@free.fr> wrote on 2010/03/26 22:35:40:
> Joakim Tjernlund a écrit :
> >
> > Nicolas de Pesloüan <nicolas.2p.debian@free.fr> wrote on 2010/03/26 21:39:33:
> >
> >> From: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
> >> To: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> >> Cc: bridge@lists.linux-foundation.org
> >> Date: 2010/03/26 21:39
> >> Subject: Re: [Bridge] IP address on physcial interface instead of bridge interface?
> >>
> >> Joakim Tjernlund wrote:
> >>
> >>> Figure a small picture will help so here it is:
> >>>
> >>> Before adding eth0 to br0:
> >>> eth0    br0
> >>>  |
> >>>  |
> >>> HW controller
> >>>
> >>> after adding eth0 to br0:
> >>> eth0
> >>>   \
> >>>    \
> >>>      br0
> >>>    /
> >>>   /
> >>> HW controller
> >> I don't understand your ascii art. What is HW controller ? eth0 is an hardware
> >> controller !?
> >>
> >>    Nicolas.
> >
> > eth0 is the I/F IP stack will see/use. HW controller is the ethernet HW controller,
> > the PCI HW if you like.
>
> I tested the following setup:
>
> # eth0 setup:
>
> ip addr add $IP dev eth0
> ip link set up dev eth0
> ip route add default via $DEF_ROUTE
>
> # bridge setup:
>
> brctl addbr br0
> brctl setfd br0 0
>
> Then I tested the following migration sequence to move the IP addresse to br0:
>
> ip addr add $IP dev br0
> ip link set up dev br0
>
> brctl addif br0 eth0
> ip addr del $IP dev eth0
> ip route add default via $DEF_ROUTE
>
> Thanks to "brctl setfd br0 0", this migration cause no trouble to active connections.
>
> So I cannot find a good reason to try and use eth0 as the "main" bridge interface.
>
> Do you have a process really linked to eth0 ?

Thanks, I will play with this after the week end.

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

[Joakim Tjernlund]

Nicolas de Pesloüan <nicolas.2p.debian@free.fr> wrote on 2010/03/26 22:35:40:
>
> Joakim Tjernlund a écrit :
> >
> > Nicolas de Pesloüan <nicolas.2p.debian@free.fr> wrote on 2010/03/26 21:39:33:
> >
> >> From: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
> >> To: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> >> Cc: bridge@lists.linux-foundation.org
> >> Date: 2010/03/26 21:39
> >> Subject: Re: [Bridge] IP address on physcial interface instead of bridge interface?
> >>
> >> Joakim Tjernlund wrote:
> >>
> >>> Figure a small picture will help so here it is:
> >>>
> >>> Before adding eth0 to br0:
> >>> eth0    br0
> >>>  |
> >>>  |
> >>> HW controller
> >>>
> >>> after adding eth0 to br0:
> >>> eth0
> >>>   \
> >>>    \
> >>>      br0
> >>>    /
> >>>   /
> >>> HW controller
> >> I don't understand your ascii art. What is HW controller ? eth0 is an hardware
> >> controller !?
> >>
> >>    Nicolas.
> >
> > eth0 is the I/F IP stack will see/use. HW controller is the ethernet HW controller,
> > the PCI HW if you like.
>
> I tested the following setup:
>
> # eth0 setup:
>
> ip addr add $IP dev eth0
> ip link set up dev eth0
> ip route add default via $DEF_ROUTE
>
> # bridge setup:
>
> brctl addbr br0
> brctl setfd br0 0
>
> Then I tested the following migration sequence to move the IP addresse to br0:
>
> ip addr add $IP dev br0
> ip link set up dev br0
>
> brctl addif br0 eth0
> ip addr del $IP dev eth0
> ip route add default via $DEF_ROUTE
>
> Thanks to "brctl setfd br0 0", this migration cause no trouble to active connections.
>
> So I cannot find a good reason to try and use eth0 as the "main" bridge interface.
>
> Do you have a process really linked to eth0 ?

So I did a quick test and it did seem to work for the simple case. However
there may be other routes connected to eth0 than just the default route so
one have to scan the whole route table. There is also the another problem,
now the I/F is named br0 and all config/status ops related to eth0 must
be changed to use br0 instead.
The routing daemon(Quagga) also needs to update its config to use br0 instead.
All in all, using br0 instead of eth0 works on a technical level but
all apps dealing with routes and interfaces needs to be updated and this
is not trivial nor wanted.

Allowing eth0 be used as I suggested would really help in these
configurations. Would such a change be welcomed and is it
hard to impl. ?

   Jocke

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

[Stephen Hemminger]

On Sun, 28 Mar 2010 17:19:13 +0200
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:

> Nicolas de Pesloüan <nicolas.2p.debian@free.fr> wrote on 2010/03/26 22:35:40:
> >
> > Joakim Tjernlund a écrit :
> > >
> > > Nicolas de Pesloüan <nicolas.2p.debian@free.fr> wrote on 2010/03/26 21:39:33:
> > >
> > >> From: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
> > >> To: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> > >> Cc: bridge@lists.linux-foundation.org
> > >> Date: 2010/03/26 21:39
> > >> Subject: Re: [Bridge] IP address on physcial interface instead of bridge interface?
> > >>
> > >> Joakim Tjernlund wrote:
> > >>
> > >>> Figure a small picture will help so here it is:
> > >>>
> > >>> Before adding eth0 to br0:
> > >>> eth0    br0
> > >>>  |
> > >>>  |
> > >>> HW controller
> > >>>
> > >>> after adding eth0 to br0:
> > >>> eth0
> > >>>   \
> > >>>    \
> > >>>      br0
> > >>>    /
> > >>>   /
> > >>> HW controller
> > >> I don't understand your ascii art. What is HW controller ? eth0 is an hardware
> > >> controller !?
> > >>
> > >>    Nicolas.
> > >
> > > eth0 is the I/F IP stack will see/use. HW controller is the ethernet HW controller,
> > > the PCI HW if you like.
> >
> > I tested the following setup:
> >
> > # eth0 setup:
> >
> > ip addr add $IP dev eth0
> > ip link set up dev eth0
> > ip route add default via $DEF_ROUTE
> >
> > # bridge setup:
> >
> > brctl addbr br0
> > brctl setfd br0 0
> >
> > Then I tested the following migration sequence to move the IP addresse to br0:
> >
> > ip addr add $IP dev br0
> > ip link set up dev br0
> >
> > brctl addif br0 eth0
> > ip addr del $IP dev eth0
> > ip route add default via $DEF_ROUTE
> >
> > Thanks to "brctl setfd br0 0", this migration cause no trouble to active connections.
> >
> > So I cannot find a good reason to try and use eth0 as the "main" bridge interface.
> >
> > Do you have a process really linked to eth0 ?
> 
> So I did a quick test and it did seem to work for the simple case. However
> there may be other routes connected to eth0 than just the default route so
> one have to scan the whole route table. There is also the another problem,
> now the I/F is named br0 and all config/status ops related to eth0 must
> be changed to use br0 instead.
> The routing daemon(Quagga) also needs to update its config to use br0 instead.
> All in all, using br0 instead of eth0 works on a technical level but
> all apps dealing with routes and interfaces needs to be updated and this
> is not trivial nor wanted.
> 
> Allowing eth0 be used as I suggested would really help in these
> configurations. Would such a change be welcomed and is it
> hard to impl. ?

The bridge code is becoming a mess as everyone implements there favorite
rework. I prefer to have custom modifications handled by netfilter (the all purpose
packet patch kit). 

I am considering some patches to allow a "master interface" but this solves a different
issue, which relates to booting in virtual environments.

You can always rename interfaces.

ip li set dev eth0 name eth0_link
ip li set dev br0 name eth0




-- 

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

[Joakim Tjernlund]

Stephen Hemminger <shemminger@linux-foundation.org> wrote on 2010/03/28 18:03:21:
>
> On Sun, 28 Mar 2010 17:19:13 +0200
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>
> > Nicolas de Pesloüan <nicolas.2p.debian@free.fr> wrote on 2010/03/26 22:35:40:
> > >
> > > Joakim Tjernlund a écrit :
> > > >
> > > > Nicolas de Pesloüan <nicolas.2p.debian@free.fr> wrote on 2010/03/26 21:39:33:
> > > >
> > > >> From: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
> > > >> To: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> > > >> Cc: bridge@lists.linux-foundation.org
> > > >> Date: 2010/03/26 21:39
> > > >> Subject: Re: [Bridge] IP address on physcial interface instead of
> bridge interface?
> > > >>
> > > >> Joakim Tjernlund wrote:
> > > >>
> > > >>> Figure a small picture will help so here it is:
> > > >>>
> > > >>> Before adding eth0 to br0:
> > > >>> eth0    br0
> > > >>>  |
> > > >>>  |
> > > >>> HW controller
> > > >>>
> > > >>> after adding eth0 to br0:
> > > >>> eth0
> > > >>>   \
> > > >>>    \
> > > >>>      br0
> > > >>>    /
> > > >>>   /
> > > >>> HW controller
> > > >> I don't understand your ascii art. What is HW controller ? eth0 is an hardware
> > > >> controller !?
> > > >>
> > > >>    Nicolas.
> > > >
> > > > eth0 is the I/F IP stack will see/use. HW controller is the ethernet HW
> controller,
> > > > the PCI HW if you like.
> > >
> > > I tested the following setup:
> > >
> > > # eth0 setup:
> > >
> > > ip addr add $IP dev eth0
> > > ip link set up dev eth0
> > > ip route add default via $DEF_ROUTE
> > >
> > > # bridge setup:
> > >
> > > brctl addbr br0
> > > brctl setfd br0 0
> > >
> > > Then I tested the following migration sequence to move the IP addresse to br0:
> > >
> > > ip addr add $IP dev br0
> > > ip link set up dev br0
> > >
> > > brctl addif br0 eth0
> > > ip addr del $IP dev eth0
> > > ip route add default via $DEF_ROUTE
> > >
> > > Thanks to "brctl setfd br0 0", this migration cause no trouble to active
> connections.
> > >
> > > So I cannot find a good reason to try and use eth0 as the "main" bridge interface.
> > >
> > > Do you have a process really linked to eth0 ?
> >
> > So I did a quick test and it did seem to work for the simple case. However
> > there may be other routes connected to eth0 than just the default route so
> > one have to scan the whole route table. There is also the another problem,
> > now the I/F is named br0 and all config/status ops related to eth0 must
> > be changed to use br0 instead.
> > The routing daemon(Quagga) also needs to update its config to use br0 instead.
> > All in all, using br0 instead of eth0 works on a technical level but
> > all apps dealing with routes and interfaces needs to be updated and this
> > is not trivial nor wanted.
> >
> > Allowing eth0 be used as I suggested would really help in these
> > configurations. Would such a change be welcomed and is it
> > hard to impl. ?
>
> The bridge code is becoming a mess as everyone implements there favorite

Sure, I understand that but I felt this was general enough to be a standard
feature.

> rework. I prefer to have custom modifications handled by netfilter (the all purpose
> packet patch kit).

hmm, not sure I follow here. Are you saying I can do this by using netfilter?
I don't see how netfilter can do this.

>
> I am considering some patches to allow a "master interface" but this solves a different
> issue, which relates to booting in virtual environments.

Perhaps my suggestion would work for that case too?

>
> You can always rename interfaces.
>
> ip li set dev eth0 name eth0_link
> ip li set dev br0 name eth0

Possibly, but to rename an I/F I have to bring it down first. Then communication
stops and all routes are deleted so that doesn't feel like a viable solution.

 Jocke

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

[richardvoigt]

On Fri, Mar 26, 2010 at 3:48 PM, Joakim Tjernlund
<joakim.tjernlund@transmode.se> wrote:
>
>
> Nicolas de Pesloüan <nicolas.2p.debian@free.fr> wrote on 2010/03/26 21:39:33:
>
>> From: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
>> To: Joakim Tjernlund <joakim.tjernlund@transmode.se>
>> Cc: bridge@lists.linux-foundation.org
>> Date: 2010/03/26 21:39
>> Subject: Re: [Bridge] IP address on physcial interface instead of bridge interface?
>>
>> Joakim Tjernlund wrote:
>>
>> > Figure a small picture will help so here it is:
>> >
>> > Before adding eth0 to br0:
>> > eth0    br0
>> >  |
>> >  |
>> > HW controller
>> >
>> > after adding eth0 to br0:
>> > eth0
>> >   \
>> >    \
>> >      br0
>> >    /
>> >   /
>> > HW controller
>>
>> I don't understand your ascii art. What is HW controller ? eth0 is an hardware
>> controller !?
>>
>>    Nicolas.
>
> eth0 is the I/F IP stack will see/use. HW controller is the ethernet HW controller,
> the PCI HW if you like.

No!

br0 does NOT sit between eth0 and the NIC.  eth0 still represents the
NIC.  br0 sits on top, and represents the combined traffic stream from
eth0 and all other bridge ports.  By adding eth0 to the bridge, you
told it to forward all incoming frames to br0 which is the next higher
layer in the virtual interface hierarchy.

>
>  Jocke
>
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge
>

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

[Joakim Tjernlund]

"richardvoigt@gmail.com" <richardvoigt@gmail.com> wrote on 2010/03/26 22:42:52:
>
> On Fri, Mar 26, 2010 at 3:48 PM, Joakim Tjernlund
> <joakim.tjernlund@transmode.se> wrote:
> >
> >
> > Nicolas de Pesloüan <nicolas.2p.debian@free.fr> wrote on 2010/03/26 21:39:33:
> >
> >> From: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
> >> To: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> >> Cc: bridge@lists.linux-foundation.org
> >> Date: 2010/03/26 21:39
> >> Subject: Re: [Bridge] IP address on physcial interface instead of bridge interface?
> >>
> >> Joakim Tjernlund wrote:
> >>
> >> > Figure a small picture will help so here it is:
> >> >
> >> > Before adding eth0 to br0:
> >> > eth0    br0
> >> >  |
> >> >  |
> >> > HW controller
> >> >
> >> > after adding eth0 to br0:
> >> > eth0
> >> >   \
> >> >    \
> >> >      br0
> >> >    /
> >> >   /
> >> > HW controller
> >>
> >> I don't understand your ascii art. What is HW controller ? eth0 is an hardware
> >> controller !?
> >>
> >>    Nicolas.
> >
> > eth0 is the I/F IP stack will see/use. HW controller is the ethernet HW controller,
> > the PCI HW if you like.
>
> No!
>
> br0 does NOT sit between eth0 and the NIC.  eth0 still represents the
> NIC.  br0 sits on top, and represents the combined traffic stream from
> eth0 and all other bridge ports.  By adding eth0 to the bridge, you
> told it to forward all incoming frames to br0 which is the next higher
> layer in the virtual interface hierarchy.

Of course the above isn't how the bridge works today. I was trying
to described a new feature which would let me use eth0 as my normal
IP interface even after it was added to the bridge.
The above would emulate connecting the eth0 I/F to an external HW bridge.

   Jocke

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

[Stephen Hemminger]

On Sat, 27 Mar 2010 11:50:23 +0100
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:

> "richardvoigt@gmail.com" <richardvoigt@gmail.com> wrote on 2010/03/26 22:42:52:
> >
> > On Fri, Mar 26, 2010 at 3:48 PM, Joakim Tjernlund
> > <joakim.tjernlund@transmode.se> wrote:
> > >
> > >
> > > Nicolas de Pesloüan <nicolas.2p.debian@free.fr> wrote on 2010/03/26 21:39:33:
> > >
> > >> From: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
> > >> To: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> > >> Cc: bridge@lists.linux-foundation.org
> > >> Date: 2010/03/26 21:39
> > >> Subject: Re: [Bridge] IP address on physcial interface instead of bridge interface?
> > >>
> > >> Joakim Tjernlund wrote:
> > >>
> > >> > Figure a small picture will help so here it is:
> > >> >
> > >> > Before adding eth0 to br0:
> > >> > eth0    br0
> > >> >  |
> > >> >  |
> > >> > HW controller
> > >> >
> > >> > after adding eth0 to br0:
> > >> > eth0
> > >> >   \
> > >> >    \
> > >> >      br0
> > >> >    /
> > >> >   /
> > >> > HW controller
> > >>
> > >> I don't understand your ascii art. What is HW controller ? eth0 is an hardware
> > >> controller !?
> > >>
> > >>    Nicolas.
> > >
> > > eth0 is the I/F IP stack will see/use. HW controller is the ethernet HW controller,
> > > the PCI HW if you like.
> >
> > No!
> >
> > br0 does NOT sit between eth0 and the NIC.  eth0 still represents the
> > NIC.  br0 sits on top, and represents the combined traffic stream from
> > eth0 and all other bridge ports.  By adding eth0 to the bridge, you
> > told it to forward all incoming frames to br0 which is the next higher
> > layer in the virtual interface hierarchy.
> 
> Of course the above isn't how the bridge works today. I was trying
> to described a new feature which would let me use eth0 as my normal
> IP interface even after it was added to the bridge.
> The above would emulate connecting the eth0 I/F to an external HW bridge.

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.




-- 

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

[Joakim Tjernlund]

Stephen Hemminger <shemminger@linux-foundation.org> wrote on 2010/03/28 05:17:52:
>
> On Sat, 27 Mar 2010 11:50:23 +0100
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>
> > "richardvoigt@gmail.com" <richardvoigt@gmail.com> wrote on 2010/03/26 22:42:52:
> > >
> > > On Fri, Mar 26, 2010 at 3:48 PM, Joakim Tjernlund
> > > <joakim.tjernlund@transmode.se> wrote:
> > > >
> > > >
> > > > Nicolas de Pesloüan <nicolas.2p.debian@free.fr> wrote on 2010/03/26 21:39:33:
> > > >
> > > >> From: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
> > > >> To: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> > > >> Cc: bridge@lists.linux-foundation.org
> > > >> Date: 2010/03/26 21:39
> > > >> Subject: Re: [Bridge] IP address on physcial interface instead of
> bridge interface?
> > > >>
> > > >> Joakim Tjernlund wrote:
> > > >>
> > > >> > Figure a small picture will help so here it is:
> > > >> >
> > > >> > Before adding eth0 to br0:
> > > >> > eth0    br0
> > > >> >  |
> > > >> >  |
> > > >> > HW controller
> > > >> >
> > > >> > after adding eth0 to br0:
> > > >> > eth0
> > > >> >   \
> > > >> >    \
> > > >> >      br0
> > > >> >    /
> > > >> >   /
> > > >> > HW controller
> > > >>
> > > >> I don't understand your ascii art. What is HW controller ? eth0 is an hardware
> > > >> controller !?
> > > >>
> > > >>    Nicolas.
> > > >
> > > > eth0 is the I/F IP stack will see/use. HW controller is the ethernet HW
> controller,
> > > > the PCI HW if you like.
> > >
> > > No!
> > >
> > > br0 does NOT sit between eth0 and the NIC.  eth0 still represents the
> > > NIC.  br0 sits on top, and represents the combined traffic stream from
> > > eth0 and all other bridge ports.  By adding eth0 to the bridge, you
> > > told it to forward all incoming frames to br0 which is the next higher
> > > layer in the virtual interface hierarchy.
> >
> > Of course the above isn't how the bridge works today. I was trying
> > to described a new feature which would let me use eth0 as my normal
> > IP interface even after it was added to the bridge.
> > The above would emulate connecting the eth0 I/F to an external HW bridge.
>
> 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.

Right, what seems to be missing is at similar hook for TX path?
If a TX hook existed(I am guessing there isn't one) then it would
be relative simple to redirect pks from the IP stack to the bride
instead instead of the HW driver?

 Jocke

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

[Bart De Schuymer]

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.

-- 
Bart De Schuymer
www.artinalgorithms.be

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

[Joakim Tjernlund]

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?

 Jocke

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

[Joakim Tjernlund]

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?

 Jocke

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

[Joakim Tjernlund]

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

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

[Bart De Schuymer]

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

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

[Joakim Tjernlund]

Bart De Schuymer <bdschuym@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@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;
>

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

[Bart De Schuymer]

Joakim Tjernlund wrote:
> Bart De Schuymer <bdschuym@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@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?

If you want the ingoing traffic to go through eth1 I assume you want the
accompanying outgoing traffic to go through eth1 too. Your routing table
should be routing 192.168.1.0/24 to eth1. If this is not how you want it
to work, please explain.

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

You'll need additional ebtables rules.


-- 
Bart De Schuymer
www.artinalgorithms.be

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

[Joakim Tjernlund]

Bart De Schuymer <bdschuym@pandora.be> wrote on 2010/03/29 10:51:26:
>
> Joakim Tjernlund wrote:
> > Bart De Schuymer <bdschuym@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@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?
>
> If you want the ingoing traffic to go through eth1 I assume you want the
> accompanying outgoing traffic to go through eth1 too. Your routing table
> should be routing 192.168.1.0/24 to eth1. If this is not how you want it
> to work, please explain.

I want eth1 to act as if was br0. Instead of having to set an IP address
on br0 and eth1 to 0.0.0.0 I want to keep the IP address on eth1 and br0
should be 0.0.0.0.

>
> > 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.
> >
>
> You'll need additional ebtables rules.

Ah, but say I add
 ebtables -t broute -A BROUTING -p 0800  -i eth1 --ip-dst 224.0.0.5 -j DROP
then only the host receives these pkgs and the other members
in the bridge wont get the multicast pkg?

     jocke

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

[Bart De Schuymer]

Joakim Tjernlund wrote:
> Bart De Schuymer <bdschuym@pandora.be> wrote on 2010/03/29 10:51:26:
>> Joakim Tjernlund wrote:
>>> Bart De Schuymer <bdschuym@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@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?
>> If you want the ingoing traffic to go through eth1 I assume you want the
>> accompanying outgoing traffic to go through eth1 too. Your routing table
>> should be routing 192.168.1.0/24 to eth1. If this is not how you want it
>> to work, please explain.
> 
> I want eth1 to act as if was br0. Instead of having to set an IP address
> on br0 and eth1 to 0.0.0.0 I want to keep the IP address on eth1 and br0
> should be 0.0.0.0.

OK, that's how it will work. But note that this means the outbound IP
and ARP traffic isn't 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.
>>>
>> You'll need additional ebtables rules.
> 
> Ah, but say I add
>  ebtables -t broute -A BROUTING -p 0800  -i eth1 --ip-dst 224.0.0.5 -j DROP
> then only the host receives these pkgs and the other members
> in the bridge wont get the multicast pkg?

Yes. I guess an ebtables module like the iptables TEE target could help
here, but it's not implemented.

But there's probably an easier solution to your problem: just never use
eth1 directly.
The case where you don't have a bridge is then replaced by using a
bridge (br0) with only one port member: eth1. The second case is then
simply achieved by adding another port to the bridge. All your
applications always use br0 as interface. This will have some inpact on
speed, though, because the incoming traffic is queued twice.

cheers,
Bart


-- 
Bart De Schuymer
www.artinalgorithms.be

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

[Joakim Tjernlund]

Bart De Schuymer <bdschuym@pandora.be> wrote on 2010/03/29 11:31:27:
>
> Joakim Tjernlund wrote:
> > Bart De Schuymer <bdschuym@pandora.be> wrote on 2010/03/29 10:51:26:
> >> Joakim Tjernlund wrote:
> >>> Bart De Schuymer <bdschuym@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@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?
> >> If you want the ingoing traffic to go through eth1 I assume you want the
> >> accompanying outgoing traffic to go through eth1 too. Your routing table
> >> should be routing 192.168.1.0/24 to eth1. If this is not how you want it
> >> to work, please explain.
> >
> > I want eth1 to act as if was br0. Instead of having to set an IP address
> > on br0 and eth1 to 0.0.0.0 I want to keep the IP address on eth1 and br0
> > should be 0.0.0.0.
>
> OK, that's how it will work. But note that this means the outbound IP
> and ARP traffic isn't bridged.

But I don want the outbound traffic(and ARP) to 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.
> >>>
> >> You'll need additional ebtables rules.
> >
> > Ah, but say I add
> >  ebtables -t broute -A BROUTING -p 0800  -i eth1 --ip-dst 224.0.0.5 -j DROP
> > then only the host receives these pkgs and the other members
> > in the bridge wont get the multicast pkg?
>
> Yes. I guess an ebtables module like the iptables TEE target could help
> here, but it's not implemented.
>
> But there's probably an easier solution to your problem: just never use
> eth1 directly.

Not that easy to do as we have legacy and also let linux via
it cmdline set the IP address so there won't be a br0 I/F until later.

> The case where you don't have a bridge is then replaced by using a
> bridge (br0) with only one port member: eth1. The second case is then
> simply achieved by adding another port to the bridge. All your
> applications always use br0 as interface. This will have some inpact on
> speed, though, because the incoming traffic is queued twice.

Tried the below script and can at least ping/telnet
to the node after that:

#eth1 has IP 192.168.1.16
brctl addbr br0
brctl setfd br0 0
ifconfig br0 192.168.1.16
brctl addif br0 eth1
ifmetric eth1 5

Not sure what the implications are yet though.

   Jocke