netdev - Re: [Bridge] [RFC 0/5] bridge - introduce via_phys

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090512162432.GA12820@lenovo>
Date:	Tue, 12 May 2009 20:24:32 +0400
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	Daniel Robbins <drobbins@...too.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

[Daniel Robbins - Tue, May 12, 2009 at 01:02:01AM -0600]
|
| 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?
| 

As far as I know (fix me if I'm wrong) you're not able to configure
bridge remotely from the scratch via active port (say eth0) without
interrupting the session and recreating routing table. Of course you
could have a script which will do all work for you. (or you could
be having a machine with 3/4/5/10 NIC's and one of them could be
just reserved to be used remote access only with proper routing
table, etc...). But in case if all nics are to be used as bridge
ports and you still need to access such a machine remotely i believe
via_phys_dev could be our friend :)

So, Daniel, i think the right question is -- do I ever need to
configure/setup bridge remotely? I suppose yes, it happens.
(at least I had a machine with lack of input device except a few
 NICs :-)

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

This feature already was in OpenVZ 2.6.24 kernel. I'm more intiresting in
usefulness of this feature for the mainline. (in short -- we use it for bridging
VEs with eth0 as a master device so all works without needing to
reconfigure routing table). Moreover, since bridge already support
namespacing the feature could be usefull for lxc as well (though
didn't check to be fair).

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

That is why it's RFC so people could decide should it be included
into mainline or not. Worth it so or not.

|
| I am a big fan of OpenVZ though, so if it helps OpenVZ in some way,
| I'd like to know about it :)
|

Yes it helps to bridge VE's without reconstructing routing table
on HW node.

| 
| -Daniel
| 

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