On Monday, 05/02/2011 at 11:48 EDT, Mark Wheeler <mwheele...@hotmail.com> 
wrote:
> The situation is that the IPs were registered on one VSWITCH, and passed 
on to 
> real switches in the external network. Later, another host registered 
the same 
> IPs on a different VSWITCH, which failed to pass them on to the external 

> network (rejected because they were dups). The 2nd VSWITCH detected this 
error, 
> but retained the IPs (for itself) anyway. The question is whether the 
2nd 
> VSWITCH should have retained them given it knew they were dups.

There are two cases:
1.  Connected VSWITCH.  I would argue that this is a bug unless the guest 
has told the vNIC to suppress the ARP query (which is there specifically 
to allow almost-hot standby network adapters for IP takeover).  When a 
guest registers an IP in an OSA and does NOT suppress the grat ARP, it has 
the expectation that the OSA will ensure no one else is actively using the 
indicated IP.

2.  Disconnected VSWITCH.  If there is no active connection to the 
network, CP cannot discover the existence of an in-use IP.  If you 
subsequently connect the VSWITCH to the network, CP will register the 
guest IPs in the OSA and get a failure.  But there is no OSA architecture 
to warn host of this after it has already successfully done a SETIP in the 
OSA.  There *is* architecture to summarily revoke a host's ownership of an 
IP in an OSA, but in this case, we have no idea which host is wrong.  So 
in this case, CP should use the no-in-use-IP-addy-detection option when it 
registers the guest IP addresses in the OSA.  The gratuitous ARP *reply* 
that indicates to others IP ownership and interface activation SHOULD be 
issued so that any other host using the same IP address can pop-up 
"Someone else is using my IP address.  Here is his MAC address...."  I've 
seen this happen on Windows.

Alan Altmark

z/VM and Linux on System z Consultant
IBM System Lab Services and Training 
ibm.com/systems/services/labservices 
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

Reply via email to