xen discuss - Jun 2008 - Please advise: sending out bogus gratuitous ARP packet from vna

I''ve implemented code to send out bogus gratuitous ARP packet from vna
in order to fix CR 6701114. The webrev is at:
http://jurassic.eng/net/consulte.prc/export/build/xvm-6701114/webrev

Some backgroud information (see CR 6701114 for more detail):

During live migration of an xVM domain from one dom0 to another, the
VNIC will be moved from one switch port to another. But, the
corresponding entry in <MAC,port> table on the switch will not be
updated automatically. Thus, all packets to the domU will still be sent
to the original port instead of the current one after the migration.
This situation will last for some time till the domU sends out
something, or the <MAC,port> entry becomes stale. A typical case is,
after live migration of an Windows XP domU, you won''t be able to talk
to
(e.g. ping) it for about a minute.

Note: This problem only happens with HVM domUs without PV frontend nic
driver running inside the domU. PV frontend nic driver will send out a
gratuitous ARP packet after migration anyway.

So, my approach is to send out a gratuitous ARP request packet from vna
after the VNIC is created to teach the switch the new port for the MAC.
A problem with this approach is the packet is sent from dom0 on behalf
of the domU. So, there is no way to know the IP of the domU. Thus, I
simply send an ARP request with IP and MAC field for both src and dst
set to 0.

Is there any flaw with this approach? Your comments are very much
appreciated :).

Thanks,
Max

Max Zhen writes:
> I''ve implemented code to send out bogus gratuitous ARP packet from
vna
> in order to fix CR 6701114. The webrev is at:
> http://jurassic.eng/net/consulte.prc/export/build/xvm-6701114/webrev
I''m not sure what good a SWAN-based webrev is going to do for the
folks on either of these lists ... can you perhaps come up with one on
cr.opensolaris.org?
> So, my approach is to send out a gratuitous ARP request packet from vna
> after the VNIC is created to teach the switch the new port for the MAC.
> A problem with this approach is the packet is sent from dom0 on behalf
> of the domU. So, there is no way to know the IP of the domU. Thus, I
> simply send an ARP request with IP and MAC field for both src and dst
> set to 0.
Why risk confusing ARP speakers by sending a bogus ARP message?

It seems to me that the issue here has nothing to do with ARP at all.
Instead, you need to let the next bridge in line know where you now
are by providing an Ethernet packet with your source MAC address.  It
can be *ANY* Ethernet packet, and doesn''t have to be ARP.

I would instead send an Ethertype 9000 (loopback) to the all-ones
broadcast address, and with arbitrary contents.  (Some systems send
out short semi-humorous text messages.)

-- 
James Carlson, Solaris Networking             
<james.d.carlson-xsfywfwIY+M@public.gmane.org>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

James Carlson wrote:
> Max Zhen writes:
>   
>> I''ve implemented code to send out bogus gratuitous ARP packet
from vna
>> in order to fix CR 6701114. The webrev is at:
>> http://jurassic.eng/net/consulte.prc/export/build/xvm-6701114/webrev
>>     
>
> I''m not sure what good a SWAN-based webrev is going to do for the
> folks on either of these lists ... can you perhaps come up with one on
> cr.opensolaris.org?
>   
Yes, my fault. Thanks for reminding.  Please refer to below link for the 
webrev:
http://cr.opensolaris.org/~cz147101/xvm-6701114/
>   
>> So, my approach is to send out a gratuitous ARP request packet from vna
>> after the VNIC is created to teach the switch the new port for the MAC.
>> A problem with this approach is the packet is sent from dom0 on behalf
>> of the domU. So, there is no way to know the IP of the domU. Thus, I
>> simply send an ARP request with IP and MAC field for both src and dst
>> set to 0.
>>     
>
> Why risk confusing ARP speakers by sending a bogus ARP message?
>
> It seems to me that the issue here has nothing to do with ARP at all.
>   
Right. I just want to pick up a broadcast packet which is well formed 
enough to be happily transferred by any switch :).
> Instead, you need to let the next bridge in line know where you now
> are by providing an Ethernet packet with your source MAC address.  It
> can be *ANY* Ethernet packet, and doesn''t have to be ARP.
>
> I would instead send an Ethertype 9000 (loopback) to the all-ones
> broadcast address, and with arbitrary contents.  (Some systems send
> out short semi-humorous text messages.)
>   
Good idea, I''ll give it a try.

Thanks,
Max

>>
>> I would instead send an Ethertype 9000 (loopback) to the all-ones
>> broadcast address, and with arbitrary contents.  (Some systems send
>> out short semi-humorous text messages.)
>>     
But, this approach can only be applied to ethernet, not others, right?

Max
> _______________________________________________
> networking-discuss mailing list
> networking-discuss@opensolaris.org
>

On (06/18/08 22:45), Max Zhen wrote:
> >>
> >> I would instead send an Ethertype 9000 (loopback) to the all-ones
> >> broadcast address, and with arbitrary contents.  (Some systems
send
> >> out short semi-humorous text messages.)
> >>     
> But, this approach can only be applied to ethernet, not others, right?
but that is also true of the grat-arp solution.

--Sowmini

Max Zhen writes:
> 
> >>
> >> I would instead send an Ethertype 9000 (loopback) to the all-ones
> >> broadcast address, and with arbitrary contents.  (Some systems
send
> >> out short semi-humorous text messages.)
> >>     
> But, this approach can only be applied to ethernet, not others, right?
I''m confused ... the fix you previous showed only works on Ethernet,
because it''s hard-coded that way.  I don''t quite see how that
makes an
ARP-based solution better.

On what other medium does the bridge migration problem occur?  What''s
the problem being solved?

-- 
James Carlson, Solaris Networking             
<james.d.carlson-xsfywfwIY+M@public.gmane.org>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

James Carlson wrote:
> Max Zhen writes:
>   
>>>> I would instead send an Ethertype 9000 (loopback) to the
all-ones
>>>> broadcast address, and with arbitrary contents.  (Some systems
send
>>>> out short semi-humorous text messages.)
>>>>     
>>>>         
>> But, this approach can only be applied to ethernet, not others, right?
>>     
>
> I''m confused ... the fix you previous showed only works on
Ethernet,
> because it''s hard-coded that way.  I don''t quite see how
that makes an
> ARP-based solution better.
>
> On what other medium does the bridge migration problem occur? 
What''s
> the problem being solved?
>   
No, I have no idea.  All the tests I''ve done so far are over ethernet.
It was just a sudden idea that it could be better if we find a MAC 
independent solution.  And yes, the ARP-based solution is no better 
w.r.t. this point, since it''s already bound to ethernet...
Anyway, I''ve tried loopback packet and it works fine :). Thanks!

Max