netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: jianhai luan <jianhai.luan@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: xen-netback notify DomU to send ARP.
Date: Tue, 08 Jan 2013 23:40:45 +0800	[thread overview]
Message-ID: <50EC3DFD.8060206@oracle.com> (raw)
In-Reply-To: <1357652541.7989.179.camel@zakaz.uk.xensource.com>


[-- Attachment #1.1: Type: text/plain, Size: 2657 bytes --]


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@oracle.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, while 
eth0 maybe wrong in productive environment.
>
> Which bonding mode are you using?
Bond running in active-backup mode.
>
> 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 you have know all ip and mac before modprobe bond, you can 
configure the bond argument. But you don't know all ip and mac before 
start new virtual.
   If bond want to know all DomU's ip and mac which pass through, it 
must check all skb. it's not good idea.
>
>>> 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.
>
Thanks,
Jason


[-- Attachment #1.2: Type: text/html, Size: 5439 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2013-01-08 15:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-08 11:57 xen-netback notify DomU to send ARP jianhai luan
2013-01-08 13:13 ` [Xen-devel] " Jan Beulich
2013-01-08 13:42   ` Ian Campbell
2013-01-08 15:40     ` jianhai luan [this message]
2013-01-08 16:00       ` Ian Campbell
2013-01-09  1:07         ` Jason Luan
2013-01-09 12:03           ` [Xen-devel] " Ian Campbell
2013-01-09  7:39         ` jianhai luan
2013-01-09 10:06           ` Jan Beulich
2013-01-09 12:28             ` jianhai luan
2013-01-09 13:44               ` Jan Beulich
2013-01-09 15:37                 ` Jason Luan
2013-01-09 15:44                   ` [Xen-devel] " Jan Beulich
     [not found]                     ` <50ED950A.6010203@163.com>
     [not found]                       ` <50EDA80002000078000B427B@nat28.tlf.novell.com>
     [not found]                         ` <50EDA624.1010008@163.com>
2013-01-10  7:00                           ` jianhai luan
     [not found]                             ` <50EF7106.7000302@oracle.com>
     [not found]                               ` <50FCED9F.1050708@oracle.com>
     [not found]                                 ` <50FD3AB202000078000B7CD5@nat28.tlf.novell.com>
     [not found]                                   ` <1358770987.3279.196.camel@zakaz.uk.xensource.com>
2013-01-21 12:38                                     ` [V2] " Jason Luan
  -- strict thread matches above, loose matches on Subject: below --
2013-01-09 15:07 Jason Luan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50EC3DFD.8060206@oracle.com \
    --to=jianhai.luan@oracle.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=konrad.wilk@oracle.com \
    --cc=netdev@vger.kernel.org \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).