I'm having a rather odd issue. I'm trying to setup a redundant pair of mobility master controllers along with a redundant pair of mobility controllers, all running on a VmWare ESX environment. I'm using the instructions on the Airheads Broadcasting Channel (youtube) as a guideline. My MMs seem to be working fine, they can ping each other, one sees itself as master, the other as backup. From my workstation, I can ping each MM IP address, along with the VRRP IP. No issues. I can fail over, and no issues.
However, when I bring up a VMC, I'm having odd connectivity issues. Sometimes I can ping 1 MM and not the other, sometimes I can ping the 2nd MM and not the first. Of course, sometimes the VRRP IP is pingable, other times not (depending on which MM I can ping and which one is the master).
I've been researching this, to no avail. I've set all the VMWare options (promiscuous mode, mac address changes, forced transmits), but it doesn't make a difference. I've torn down and rebuilt the VMC, sometimes with the port in access mode, other times in trunk mode, no difference.
Anyone have any advice?
Are both of the VRRP's in the same L2 broadcast domain and using the same/or different VRRP ID's?
Yes and yes.
Sorry, I guess I need to clarify. Currently, I just have a redudant pair of MM's. I just have 1 VMC that I am currently test with (before adding in a 2nd VMC). That 1 VMC is having intermittent connectivity issues with the MM's.
Can you provide some logs from the MD? It will be very difficult to speculate what could cause the information as every environment is different. Has any initial troubleshooting been completed already? Under your vmnic have you enabled Promiscuous Mode/Forged Transmits/MAC Address Changes?
It sounds very much like Promiscuous Mode and Forged Trasmits are not enabled on the MMs. The same two settings need to be enabled on the VMC as well, since you plan on doing a second VMC.
Everything I've read points to that as well. However, that is not the case here. Both are enabled on the vswitch as well as the port group.
Have you tried using an other VRRP group (ID)?
I'm currently troubleshooting a similar issue with two VMM, which forms MASTER/BACKUP VRRP states fine, however I'm experiencing intermittent drops on pings towards the VRRP VIP.
I've isolated it to be an issue with VRRP group 1. If I use any other VRRP group it all works fine. I can also reproduce the same problem with VRRPd on a fresh Ubuntu-server in the save VLAN (Portgroup), when I've turned ALL other VMs off in that VLAN (Including the VMMs), so my problem is isolated to VRRP group 1 and VMware and has nothing todo with VMM, but as the symptoms are similar I just wanted to share you the tip to try another VRRP ID just in case.
Just for the record I've solved my VRRP issue with Group 1. It was caused by running on HP c7000 plattform with VirtualConnect modules running in TunnelMode to tunnel all our VLANs from our core network to our VMware environment.
When running VC-modules in TunnelMode, they only have one global MAC-table instead of a separate table per VLAN that normal switches have. That caused VRRP traffic from another customer in a different VLAN using VRRP Group 1 to cause a MAC conflict with my VMM environment on a different VLAN.
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2020 Hewlett Packard Enterprise Development LPAll Rights Reserved.