netdev - Re: [Xen-devel] xen-netback notify DomU to send ARP.

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-next>] [day] [month] [year] [list]

Date:	Tue, 8 Jan 2013 16:00:34 +0000
From:	Ian Campbell <Ian.Campbell@...rix.com>
To:	jianhai luan <jianhai.luan@...cle.com>
CC:	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Subject: Re: [Xen-devel] xen-netback notify DomU to send ARP.

On Tue, 2013-01-08 at 15:40 +0000, jianhai luan wrote:
> 
> On 2013-1-8 21:42, Ian Campbell wrote: 
> > On Tue, 2013-01-08 at 13:13 +0000, Jan Beulich wrote: 
> > > > > > On 08.01.13 at 12:57, jianhai luan <jianhai.luan@...cle.com>
> > > > > > wrote: 
> > > >     When Xen Dom0's network circumstance changed, DomU 
> > > > should be notified in some special condition. For 
> > > > example the below circumstance: 
> > > >     ping from Guest A to DomU: 
> > > >     Guest A --> eth0 - bond0 - xenbr0 --VIF(DOMU) 
> > > >                 eth1 / 
> > > >     when eth0 inactive, and eth1 active. 
> > How is eth0 failing? Are you unplugging it, un-enslaving it or
> > taking 
> > some other sort of administrative action? 
> In my emulation environment, i unplug it or ifdown the interface,

I expect these would behave rather different, since the affect of ifdown
looks rather different to an unplug from the PoV of the switch.

Is the ifdown case something which you are trying to solve or just what
appeared to be a convenient test case? I'd be less inclined to worry
about explict admin actions such as that.

Unplugging the cable should cause:

> > Doesn't this state change cause the switch to which eth0 and eth1
> > are 
> > attached to forget the MAC tables associated with the eth0 port,
> > meaning 
> > that subsequent traffic will be flooded until it learns that eth1 is
> > the 
> > new port? 

Ian


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