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

Message-ID: <1357652541.7989.179.camel@zakaz.uk.xensource.com>
Date:	Tue, 8 Jan 2013 13:42:21 +0000
From:	Ian Campbell <Ian.Campbell@...rix.com>
To:	Jan Beulich <JBeulich@...e.com>
CC:	jianhai luan <jianhai.luan@...cle.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [Xen-devel] xen-netback notify DomU to send ARP.

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?

Which bonding mode are you using?

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?

> >    Guest A --> eth0   bond0 - xenbr0 --VIF(DOMU)
> >                eth1 /
> >    Guest A will don't reach to DomU. After Guest A
> >    send ARP request and DomU respond, Guest A will
> >    reach DomU. But some more second will be elapsed.
> >                eth0   bond0 - xenbr0 --VIF(DOMU)
> >    Guest A --> eth1/
> 
> Isn't a change to the availability of the bonds supposed to be
> transparent to Guest A _and_ DomU? I.e. aren't you trying to fix
> an eventual problem here in the wrong place?

In non-virtualised bonding the bonding drive can take care of some of
this because it knows its own MAC address and can send appropriate
gratuitous frames (depends on the bonding mode) to paper over things. In
the virtualised case it (most likely) doesn't know VIF(DOMU)s MAC
address.

> > If Xen netback watch the network change, will notify
> > DomU by change it own status. So netfront will watch
> > netback's change, and DomU send ARP initiative.
> 
> Your patch is, at least according to what I see, completely
> unusable - line breaks dropped, line order reversed, and
> (guessing) some UTF-16/UCS-2 characters inserted at the top.
> Please attach patches as plain ASCII.

>From the name it looks to me like it is the vi temp file created while
you have the file open rather than the actual patch file...

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