Comware Based
cancel
Showing results for 
Search instead for 
Did you mean: 

vmotion+virtualconnect+10508 Chassis+comware 7+ icmp/arp issue

Tobias L.
Occasional Advisor

vmotion+virtualconnect+10508 Chassis+comware 7+ icmp/arp issue

Hi,

at first the firmware versions.

10508: R2111P02 (Comware 7)
VC: 4.31 Version
vsphere 5.5u3

Setup:

10508 Chassis -> 2x2x10G LACP -> Blade Chassis 1 VC Active/Passive
10508 Chassis -> 2x2x10G LACP -> Blade Chassis 2 VC Active/Passive
Config Link-Aggregation to both VCs:
interface bridge-aggregation17
port link-type trunk
prot trunk permit vlan all
link-aggregation mode dynamic
stp edged-port


VC: SUS
vsphere: Notify Switches on vSwitch is active

Problem:

If I migrate a VM from Blade Chassis 1 to 2 I the vm is losing ICMP Requests until the ARP/MAC table on the 10508 Chassis is updated. If I migrate inside the blade chassis there isn't any packet loss.
The weird thing is I have two directly (no LACP, just plain port configuration, no VC) connected vpshere hypervisors (same esx version) to the 10508 chassis and vmotion is working flawlessy without any packet loss.

It look likes the vmotions rarp packets from esx host through Virtualconnect and to the H3c chassis gets lost or dropped?

The same thing happens if I migrate from a Dell Chassis with I/O Aggregator (L2-Switch) to or from the Blade Chassis with VC. All link-aggregations are configured the same way.

Any ideas?

Just a update: With hyperv live migration I dont have these problems. On all my devices/vms the L3 switch is the default gateway (int vlan). AND only the switch ip isn't available after vmotion for four to five icmp requests. So this must be an ARP issue on the switch itself. Other devices are responding after the migration without any packet loss.

 

4 REPLIES
Tobias L.
Occasional Advisor

Re: vmotion+virtualconnect+10508 Chassis+comware 7+ icmp/arp issue

Another update: I am able to workaround the issue if I reset the arp cache on the source interface (the interface on which the vm was before vmotion) with "reset arp interface $interfacenumber".

The arp aging timer is set to 20 minutes.

I don't know if this is a vmware problem or a switch/hp problem.

 

Tobias L.
Occasional Advisor

Re: vmotion+virtualconnect+10508 Chassis+comware 7+ icmp/arp issue

Another update: The cli command mac-address mac-move fast-update fixed the issue for directly connected hypervisors. Finally there is no outage between vm moves between directly connected esx hypervisors. But if there is a vc between and I try to move between the blade chassis, there is still an outage.

Vince-Whirlwind
Honored Contributor

Re: vmotion+virtualconnect+10508 Chassis+comware 7+ icmp/arp issue

I'm not a server guy, but I recall years ago our server guys were having a similar issue with a 30-second outage when swapping hosts.

I asked them for their doco on the server and found that it specifically called for a static MAC to be entered on the core switch, pointing at a virtual MAC instead of the physical hosts' MAC address.

The other thing that is meant to prevent this sort of thing is a "gratuitous ARP". Maybe you can configure your system to kick one of them off?

Tobias L.
Occasional Advisor

Re: vmotion+virtualconnect+10508 Chassis+comware 7+ icmp/arp issue

I have just investigated further. It seems like a problem on mac updating on a bridge aggregation with or without LACP. If I reset the arp table while I am doing vmotion it works.

What still works is vmotion between my directly connected hosts without the requirement to reset the arp table.

It is very confusing that there is no problem with hyper-v live migration

So I don't know what I could try next except updating the firmware of the 10508 core switch.

Anyone, any other ideas?