lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 12 May 2009 01:02:01 -0600 From: Daniel Robbins <drobbins@...too.org> To: Cyrill Gorcunov <gorcunov@...nvz.org> Cc: Stephen Hemminger <shemminger@...ux-foundation.org>, netdev@...r.kernel.org, bridge@...ts.linux-foundation.org, davem@...emloft.net, xemul@...nvz.org Subject: Re: [Bridge] [RFC 0/5] bridge - introduce via_phys_dev feature Is this functionality useful for OpenVZ? Do people need the ability to do this? Why/when is it necessary for me to be able to add eth0 to a bridge remotely? I don't quite (yet) understand the usefulness of this feature. You would still be very limited in what you can change with the network if you are remote, right? That's why I don't quite understand the benefit of this feature. How are you planning to use it? When I set up my OpenVZ systems, I like to get the overall network/bridge configuration perfect so that I don't need to make major changes when I am remote. Again, I am not an expert so I am asking purely for my own curiosity. I support the idea of making networking more flexible, but I do not see this particular step addressed by the patch as a common need. That may be due to my own lack of understanding. I am a big fan of OpenVZ though, so if it helps OpenVZ in some way, I'd like to know about it :) -Daniel On Tue, May 12, 2009 at 12:19 AM, Cyrill Gorcunov <gorcunov@...nvz.org> wrote: > On 5/12/09, Daniel Robbins <drobbins@...too.org> wrote: >> 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 >> > Hi Daniel, > > The idea was exactly you described, ie have an ability to configure > remote system as bridge. There was an example how to use it in the > pach (last patch in series). Say we have remote system with eth0 set > up and running. So we may sign in into this system remotely. If we > have to confugure bridge on such a system (that even eth0 has to be > the bridge port) we connect to this system via eth0 then add bridge > br0 and run it via ifconfig br0 up, turn on via_phys_dev feature and > evetually add eth0 as a bridge port. We will have small delay in > session until port get forwarding state but after we could continue > work remotely on the system without reconfiguring routing table. Even > ssh session being used during configuration will continue operate. So > except a delay no session interrupt. I hope, need a good testing ;) > >> On Mon, May 11, 2009 at 5:46 AM, Cyrill Gorcunov <gorcunov@...nvz.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@...il.com> >>> | Date Sat May 9 06:59:16 2009 +0000 >>> >>> Cyrill >>> _______________________________________________ >>> Bridge mailing list >>> Bridge@...ts.linux-foundation.org >>> https://lists.linux-foundation.org/mailman/listinfo/bridge >>> >> > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists