Wireless Access

We're deploying a Mobility Master (v. 8.2.0.0 in VMware), and we can't get the device to show up on our network.  We called TAC, which was not able to fix the problem.  Here's where we're at:

 

-We have one interface active (g 0/0/0 - showing up/up) in Access mode.  We have verified that this is the correct interface in VMware - bouncing the 'connected' setting in VMware shows the interface bounces in the MM (via show interface g 0/0/0).

-The port is in vlan 1, which has an IP address assigned in the VLAN interface.  This VLAN interface is up/up.

-The default gateway is set correctly, as is the 'controller-ip vlan 1' setting.

 

TAC suggested it might be a VMware problem, but we have the Promiscuous mode, MAC address changes, and Forged Transmits turned on for the switch group as per the installation documentation.

 

The MM is not pingable from other hosts, on the same subnet and elsewhere.  

 

Any suggestions?

 

Can the MM ping it's gateway? What is the VMWare deployment, single ESX host, part of a cluster using dVswitch? Is this a converged platform with a separate network stack (Bladecenter, etc)? Are there any other VMs in the same vSwitch/Portgroup that have network access on the same VLAN?

 

If it's a standalone server and the MM cannot ping its gateway, then there's a disconnect with the vSwitch, physical adapter, etc.

The MM cannot ping its gateway. It's a distributed vswitch. Other VMs have access to the same port group, and behave fine.

dVSwitch requires a number of additional setup variables outlined in the VMM/VMC installation guide. VMM and VMCs are a lot different from normal server or desktop OSes that get virtualized, in that their macaddr is not the physical vmnic but is further up, and requires additional settings for DVS over and above promisuous mode, forged transmits, and mac changing.

I don't see any other instructions in the guide: here - could you kindly point out what additional setup variables you're talking about?

 

Thanks for your help with this!

Not sure where that was linked from, but that is incredibly out of date (mid to late 2016 from the first release). Please check the most recent installation guides

 

https://support.arubanetworks.com/Documentation/tabid/77/DMXModule/512/Command/Core_ViewDetails/Default.aspx?EntryId=34196

I don't see anything relevant that has changed in the newer documentation.  We were on another TAC call today, and the engineer recommended the 'ReversePathFwdCheckPromisc' enabled (set to '1').  However, this does not resolve the issue.  An annoying feature of this software is that changes to the configuration do not appear in the 'show configuration', even when we issue the 'write mem'.

I am pleased to report that the problem was all ours.  The VLAN tagging for the port group was set incorrectly.  Oddly, when testing with another port group that was known to work, we still didn't get any action.  Thanks very much for your help!

No worries, glad you got it working! ANd yea, the 'magic' that exists between the VM and the physical network when traversing VMWare network stack is a nightmare to dig in to :)