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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 12 May 2009 10:19:20 +0400
From:	Cyrill Gorcunov <gorcunov@...nvz.org>
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

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ