Re: Duplicate IPs on VSWITCHes - Feature or Defect
FYI, IBM took requirement MR051355 on this issue. VSWITCHes should drop duplicate IP's, like real switches do. Indeed, the way OSA's do. From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Mark Wheeler Sent: Friday, April 29, 2011 3:49 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Duplicate IPs on VSWITCHes - Feature or Defect Greetings all, We've been pulling our hair out for several days trying to figure out a networking issue involving VSWITCHes. A server (LNXA1) attached to VSWITCHA on VMSYSA can connect to a server (LNXB1) attached to VSWITCHB on VMSYSB but a server (LNXC1) attached to VSWITCHC on VMSYSC cannot. We moved LNXC1 to VSWITCHA on VMSYSA and it worked. All on the same subnet, BTW. Unbeknownst to us, a server (LNXC2) had an interface on VSWITCHC that used the same IP as LNXA1. It couldn't be registered to the outside network because it was already being used, yet it was still registered to VSWITCHC. Hence, anyone else on VSWITCHC would try to connect to LNXC2 when it in fact was trying to connect to LNXA1. Q VSWITCH VSWITCHC DETAILS shows the duplicate IP, identifiable by the Local designation under the list of unicast IP address(es). The VSWITCH is able to detect the fact that this is a duplicate IP. Is this a feature or a defect? Should VSWITCHC drop the IP address when it identifies the duplicate situation? What would a real switch do? Best regards, Mark Wheeler UnitedHealth Group -- Excellence. Always. If Not Excellence, What? If Not Excellence Now, When? Tom Peters, author of The Little BIG Things
Re: Duplicate IPs on VSWITCHes - Feature or Defect
Are these layer 2 or layer 3? If layer 2, then they are (and should be) paying zero attention to the IP address. Layer 2 cares only about MAC addresses. Layer 3 is more subtle. Technically a real switch should attempt only to insert the address in the forwarding table and then the latest entry wins (eg it should eject the previously registered host as ARP entries expire in the communicating guests with cached info about IP to MAC mappings). So, I'd say that if you are using layer 2 switches, it is neither a bug nor a feature. It's working correctly, and it's your problem to avoid this situation. In the layer 3 case, it's arguably doing the right thing, but there is a case for it dropping the first registration when a new host registers the same address. From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Mark Wheeler Sent: Friday, April 29, 2011 3:49 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Duplicate IPs on VSWITCHes - Feature or Defect Greetings all, We've been pulling our hair out for several days trying to figure out a networking issue involving VSWITCHes. A server (LNXA1) attached to VSWITCHA on VMSYSA can connect to a server (LNXB1) attached to VSWITCHB on VMSYSB but a server (LNXC1) attached to VSWITCHC on VMSYSC cannot. We moved LNXC1 to VSWITCHA on VMSYSA and it worked. All on the same subnet, BTW. Unbeknownst to us, a server (LNXC2) had an interface on VSWITCHC that used the same IP as LNXA1. It couldn't be registered to the outside network because it was already being used, yet it was still registered to VSWITCHC. Hence, anyone else on VSWITCHC would try to connect to LNXC2 when it in fact was trying to connect to LNXA1. Q VSWITCH VSWITCHC DETAILS shows the duplicate IP, identifiable by the Local designation under the list of unicast IP address(es). The VSWITCH is able to detect the fact that this is a duplicate IP. Is this a feature or a defect? Should VSWITCHC drop the IP address when it identifies the duplicate situation? What would a real switch do? Best regards, Mark Wheeler UnitedHealth Group -- Excellence. Always. If Not Excellence, What? If Not Excellence Now, When? Tom Peters, author of The Little BIG Things
Re: Duplicate IPs on VSWITCHes - Feature or Defect
David, They're layer 3. 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. Mark Date: Mon, 2 May 2011 10:32:30 -0500 From: dbo...@sinenomine.net Subject: Re: Duplicate IPs on VSWITCHes - Feature or Defect To: IBMVM@LISTSERV.UARK.EDU Are these layer 2 or layer 3? If layer 2, then they are (and should be) paying zero attention to the IP address. Layer 2 cares only about MAC addresses. Layer 3 is more subtle. Technically a real switch should attempt only to insert the address in the forwarding table and then the latest entry wins (eg it should eject the previously registered host as ARP entries expire in the communicating guests with cached info about IP to MAC mappings). So, I’d say that if you are using layer 2 switches, it is neither a bug nor a feature. It’s working correctly, and it’s your problem to avoid this situation. In the layer 3 case, it’s arguably doing the right thing, but there is a case for it dropping the first registration when a new host registers the same address.
Re: Duplicate IPs on VSWITCHes - Feature or Defect
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. I'd argue yes, because the VSWITCH has no way to determine that they are already registered in another switch. There's no existing network protocol to communicate that information between the two switches (nothing like ISL or 802.1q for layer 3). The two VSWITCHes are two separate entities that can't know that the address is already registered elsewhere. Switch to layer 2 if/when you can. It simplifies a lot of things.
Re: Duplicate IPs on VSWITCHes - Feature or Defect
On the 1st VSWITCH, Q VSWITCH ... DETAILS shows: Unicast IP Addresses: snip x.y.z.161MAC: 02-00-00-00-00-3D x.y.z.162MAC: 02-00-00-00-00-3D x.y.z.163MAC: 02-00-00-00-00-3D x.y.z.164MAC: 02-00-00-00-00-3D snip On the 2nd VSWITCH... Unicast IP Addresses: snip x.y.z.161MAC: 02-00-00-00-00-60 Local x.y.z.162MAC: 02-00-00-00-00-60 Local x.y.z.165MAC: 02-00-00-00-00-60 x.y.z.166MAC: 02-00-00-00-00-60 snip It appears that SOMEHOW the 2nd VSWITCH knows that .161 and .162 are dups. Date: Mon, 2 May 2011 10:53:54 -0500 From: dbo...@sinenomine.net Subject: Re: Duplicate IPs on VSWITCHes - Feature or Defect To: IBMVM@LISTSERV.UARK.EDU 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. I’d argue yes, because the VSWITCH has no way to determine that they are already registered in another switch. There’s no existing network protocol to communicate that information between the two switches (nothing like ISL or 802.1q for layer 3). The two VSWITCHes are two separate entities that can’t know that the address is already registered elsewhere. Switch to layer 2 if/when you can. It simplifies a lot of things.
Re: Duplicate IPs on VSWITCHes - Feature or Defect
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
Duplicate IPs on VSWITCHes - Feature or Defect
Greetings all, We've been pulling our hair out for several days trying to figure out a networking issue involving VSWITCHes. A server (LNXA1) attached to VSWITCHA on VMSYSA can connect to a server (LNXB1) attached to VSWITCHB on VMSYSB but a server (LNXC1) attached to VSWITCHC on VMSYSC cannot. We moved LNXC1 to VSWITCHA on VMSYSA and it worked. All on the same subnet, BTW. Unbeknownst to us, a server (LNXC2) had an interface on VSWITCHC that used the same IP as LNXA1. It couldn't be registered to the outside network because it was already being used, yet it was still registered to VSWITCHC. Hence, anyone else on VSWITCHC would try to connect to LNXC2 when it in fact was trying to connect to LNXA1. Q VSWITCH VSWITCHC DETAILS shows the duplicate IP, identifiable by the Local designation under the list of unicast IP address(es). The VSWITCH is able to detect the fact that this is a duplicate IP. Is this a feature or a defect? Should VSWITCHC drop the IP address when it identifies the duplicate situation? What would a real switch do? Best regards, Mark Wheeler UnitedHealth Group -- Excellence. Always. If Not Excellence, What? If Not Excellence Now, When? Tom Peters, author of The Little BIG Things
