RE: [Xen-devel] Stimulating domains to send gratuitous ARPs

["Graham, Simon" <Simon.Graham@xxxxxxxxxxx>]

> > Whilst I might agree that from a purist point of view having netfront
> do
> > this is a violation of layering, it's already accepted in some other
> > upstream drivers
> 
> It's pretty clear it's not going to be accepted in the netfront that
> goes into upstream Linux, at least not without sedating various LKML
> folk first :)
> 

Fine (well, not fine at all really, but I understand ;-).

> For bond case you described, you don't need to send ARPs, you just need
> to send any packet with the right src MAC to cause the switches to
> reconfigure. Since the bond driver likely already maintains a list of
> MAC addrs its operating on behalf of this is easy.
> 

Well, the bonding module itself doesn't track this at all actually; when a 
failover is done, it sends gratuitous ARPs for the following:
1. The IP address associated with the bond itself
2. The IP addresses associated with an VLANs above the bond (suitably 
encapsulated in the VLAN header).

In addition, I donât think that 'any old frame' will work -- it needs to be a 
link-level broadcast frame to ensure that all the switches update their 
forwarding tables -- in the example I cited of bonding for availability, it's 
entirely possible (in fact it's desirable) to plug the two NICs that are bonded 
into different switches. 

This is really exactly the same as the migration case (which also doesn't need 
to be an ARP from the point of view of updating ARP caches, it just needs to be 
a link level broadcast frame). So I think we both need a Dom0 based mechanism!

Assuming the netfront approach is dead, we need to identify a link level 
broadcast frame that can be safely sent to update the bridge forwarding tables 
with no other side effects... perhaps a RARP rq since this is deprecated anyway 
now, so it will probably get no answer and even if it does, the answer should 
be ignored???

Simon

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel