Linux Ethernet Bridging - May 2009 - [Bridge] [RFC 0/5] bridge - introduce via_phys_dev feature

Hi,

here is RFC for new via_phys_dev bridge feature.
In short -- it allows to use some bridge port as
bridge itself with already configured routing table.

More details with example you may found in patches.

Please review. Any (including _complains_) comments are
highly appreciated!

The series is on top of current -net-next-2.6

	| commit ed9b58bc443a1210b5be1ded6421b17e015bf985
	| Author Richard Genoud <richard.genoud at gmail.com>
	| Date Sat May 9 06:59:16 2009 +0000

Cyrill

An embedded and charset-unspecified text was scrubbed...
Name: net-br-use-is_multicast
Url:
http://lists.linux-foundation.org/pipermail/bridge/attachments/20090511/f1dd3ac4/attachment.txt

An embedded and charset-unspecified text was scrubbed...
Name: net-br-via_phys
Url:
http://lists.linux-foundation.org/pipermail/bridge/attachments/20090511/fe0c0b36/attachment.txt

An embedded and charset-unspecified text was scrubbed...
Name: net-br-introduce-skb-brmark
Url:
http://lists.linux-foundation.org/pipermail/bridge/attachments/20090511/2c318027/attachment.txt

An embedded and charset-unspecified text was scrubbed...
Name: net-br-hard-xmit-hook
Url:
http://lists.linux-foundation.org/pipermail/bridge/attachments/20090511/0c095528/attachment.txt

An embedded and charset-unspecified text was scrubbed...
Name: net-br-via-func
Url:
http://lists.linux-foundation.org/pipermail/bridge/attachments/20090511/3d917c25/attachment.txt

Note: I am not a bridge guru but I'm interested in understanding this
new functionality better. What is the larger benefit of this feature?
Does this make it possible to configure a bridge setup on a remote
system without losing connectivity? I can't do many kinds of network
changes remotely without risking losing connectivity (ie. changing IP
address, messing with routing, etc. -- it would be likely that you'd
lose network connectivity :) ) Therefore, I don't know if this is a
benefit unless it is needed for a particular application. Is this
useful for OpenVZ in some way?

Regards,

Daniel

On Mon, May 11, 2009 at 5:46 AM, Cyrill Gorcunov <gorcunov at openvz.org>
wrote:
> Hi,
>
> here is RFC for new via_phys_dev bridge feature.
> In short -- it allows to use some bridge port as
> bridge itself with already configured routing table.
>
> More details with example you may found in patches.
>
> Please review. Any (including _complains_) comments are
> highly appreciated!
>
> The series is on top of current -net-next-2.6
>
> ? ? ? ?| commit ed9b58bc443a1210b5be1ded6421b17e015bf985
> ? ? ? ?| Author Richard Genoud <richard.genoud at gmail.com>
> ? ? ? ?| Date Sat May 9 06:59:16 2009 +0000
>
> Cyrill
> _______________________________________________
> Bridge mailing list
> Bridge at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge
>

On Mon, 11 May 2009 15:46:39 +0400
Cyrill Gorcunov <gorcunov at openvz.org> wrote:
> Hi,
> 
> here is RFC for new via_phys_dev bridge feature.
> In short -- it allows to use some bridge port as
> bridge itself with already configured routing table.
> 
> More details with example you may found in patches.
> 
> Please review. Any (including _complains_) comments are
> highly appreciated!
> 
> The series is on top of current -net-next-2.6
> 
> 	| commit ed9b58bc443a1210b5be1ded6421b17e015bf985
> 	| Author Richard Genoud <richard.genoud at gmail.com>
> 	| Date Sat May 9 06:59:16 2009 +0000
> 
> Cyrill
> --
> To unsubscribe from this list: send the line "unsubscribe netdev"
in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Do not really like this patch set. It adds more complexity to solve a problem
that looks like it can be solved by other means.

Looking back at this. What if the API was simpler:

Instead of:
> Typical session looks like
> 
> | s... at 10.10.0.160$ brctl addbr br0
> | s... at 10.10.0.160$ ifconfig br0 up
> | s... at 10.10.0.160$ echo 1 > /sys/class/net/bridge/br0/via_phys_dev
> | s... at 10.10.0.160$ brctl addif br0 eth0
> | (...waiting a bit...)
> | s... at 10.10.0.160$
Why not:
  1. Setup bridge (and any other interfaces except eth0); includes bringing br0
up
  2. Add eth0 to bridge with new flag to inherit
       a. brctl addif br0 eth0 inherit

Inherit functionality would need to move address (Ether, IP, IPv6)
and routes from eth0 to br0.
I will see about doing it as much as possible in userspace.

On Fri, Feb 26, 2010 at 10:18 AM, Stephen Hemminger
<shemminger at linux-foundation.org> wrote:
> Looking back at this. What if the API was simpler:
>
> Instead of:
>> Typical session looks like
>>
>> | s... at 10.10.0.160$ brctl addbr br0
>> | s... at 10.10.0.160$ ifconfig br0 up
>> | s... at 10.10.0.160$ echo 1 >
/sys/class/net/bridge/br0/via_phys_dev
>> | s... at 10.10.0.160$ brctl addif br0 eth0
>> | (...waiting a bit...)
>> | s... at 10.10.0.160$
>
> Why not:
> ?1. Setup bridge (and any other interfaces except eth0); includes bringing
br0 up
> ?2. Add eth0 to bridge with new flag to inherit
> ? ? ? a. brctl addif br0 eth0 inherit
>
> Inherit functionality would need to move address (Ether, IP, IPv6)
> and routes from eth0 to br0.
> I will see about doing it as much as possible in userspace.
How about inheriting the up/down status as well, this way the bridge
can be left down until the settings are inherited, and will come up
with the inherited MAC address, IP address, and routing table instead
of changing while live?
> _______________________________________________
> Bridge mailing list
> Bridge at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge
>

On Fri, 26 Feb 2010 10:52:52 -0600
"richardvoigt at gmail.com" <richardvoigt at gmail.com> wrote:
> On Fri, Feb 26, 2010 at 10:18 AM, Stephen Hemminger
> <shemminger at linux-foundation.org> wrote:
> > Looking back at this. What if the API was simpler:
> >
> > Instead of:
> >> Typical session looks like
> >>
> >> | s... at 10.10.0.160$ brctl addbr br0
> >> | s... at 10.10.0.160$ ifconfig br0 up
> >> | s... at 10.10.0.160$ echo 1 >
/sys/class/net/bridge/br0/via_phys_dev
> >> | s... at 10.10.0.160$ brctl addif br0 eth0
> >> | (...waiting a bit...)
> >> | s... at 10.10.0.160$
> >
> > Why not:
> > ?1. Setup bridge (and any other interfaces except eth0); includes
bringing br0 up
> > ?2. Add eth0 to bridge with new flag to inherit
> > ? ? ? a. brctl addif br0 eth0 inherit
> >
> > Inherit functionality would need to move address (Ether, IP, IPv6)
> > and routes from eth0 to br0.
> > I will see about doing it as much as possible in userspace.
> 
> How about inheriting the up/down status as well, this way the bridge
> can be left down until the settings are inherited, and will come up
> with the inherited MAC address, IP address, and routing table instead
> of changing while live?
Ok.

--