ArubaOS 8.x MM Virtual vs. Hardware

[MLWeiner]

I'm just curious how common the hardware MM is vs. the VA.  I'm considering upgrading my 6.5.x deployment to 8.x this summer, but am leaning strongly towards a hardware MM setup due to the amount of unpleasant hackery that has to be done to vSphere to make the VA happy.

Anyone else elect not to use the VA for this reason and go hardware?  If the hardware isn't common I'd likely elect to stand by and wait for the 8.x codebase to continue to revise and hope that maybe a later release will require less ripping and tearing on vSphere's network configuration.  I don't want to get stuck with something that only a small minority are running that doesn't get as much in the way of attention.

[soarvet]

I don't see an need to waste the hardware on a MM.  It's only really managing the controllers as far as configs, etc..  It's barely consuming any resources.  I'd hate to waste hardware on something that takes up so littel resources especially if you're going to do a redundancy with dual MM's. The AP's still terminate on the controllers.  Unless you have the resources and rack space to stand up a dedicated hardware MM I'd stick with Virtual.

[MLWeiner]

It's not so much the resources on vSphere that concern me, it's all the nasty stuff you have to do to the network stack to make the VM work, like enabling promiscuous mode and doing LACP through multiple vSwitches and sending all the VLANs up to it that I don't like. 

If it were "upload OVA, assign NIC to VLAN, power up" I'd be fine with it.  It's the "enable forged transmits, enable promiscuous mode, trunk it all VLANs" and all that which I'm not okay with.  I have to put a lot of trust in that software not to behave badly.

[justink84]

Just keep in mind that the purpose of MM is more then just pushing configs. MM starts to remove controlplane services from the controllers that terminate AP's like client-match, UCC, ARM (Airmatch), and Airgroup. These services are now centralized by MM vs running independently. 

Since these services are centralized, design issues like salt-and-pepper, are no longer a major design issue. Client-match is a chatty process and it performs updates every 3 seconds. This means that the AP's are constantly sending data back to MM so it can be processed. Airgroup is also a chatty protocol and it can be run both centralized or distributed. One of the percs about centralized is that you no longer have to deal with different airgroup domains and you have a single place you need to go to look and review. 

Another perc about MM is that there is a loadable service module which allows centralized services to be upgraded if needed. This way your not foced to perform a maint window to apply a patch to fix an issue with client-match. 

With all of the controlplane services now starting to get migrated. It really means that MM is much more imporant piece of the enviornment when comparing it to a master thats sole responsiblity was configs, licensing, CPSEC / RAP whitelist, local-userdb. 

[MLWeiner]

I'm not hurting for bandwidth, CPU, or any of that in vSphere. My sole issue is the networking requirements that the appliance forces you to set up in your environment. If I had the hardware unit it'd be plug in and power up like my existing controllers. I've read every piece of documentation I can get my hands on and I'm not even sure why the appliance requires half the configuration changes it does.


#AirheadsMobile

[justink84]

Please eloborate on the networking requirements your concerned about. MM doesn't force you to setup a 802.3ad or LACP. There isn't anything stoping you from using a single interface setup as an access port. 

Each customer design is different, and one customer may consider an interface failover somewhat "ok" as there is a backup MM server and it will just take over. Some other customers may not want an upstream interface failure to create a failover and thats were port redudnancy may become an important aspect. 

[MLWeiner]

I'm just going by the setup requirements in the documentation. One issue is disabling all the vSwitch security. IMO that's a bit risky, alongside trunking all the VLANs to the appliance, which I'm not fond of either, also for security reasons. Then it says I have to set up two links on two discrete vSwitches, which you say isn't necessary, I have 10 gig vSwitch link redundancy on the host so I should be good there. I won't be using VRRP, my routers are a bit intolerant of it in a "hello broadcast storm, goodbye datacenter" sort of way. I'll probably layer 3 cluster to another VM in my hot site if I can get the first one to work without wrecking the place. There are so many gotchas and caveats in the documentation "just a heads up, do this wrong and we'll take down your host or broadcast storm your network to death" but at the same time being ambiguous and contradictory as to what actually needs to be done. Ive seen a webinar where one data interface is used, but the manual says you need two or it won't work. Maybe I've read too much documentation. It wants three network interfaces, I'm assuming first is management, which is the same as the OOB management on the hardware controllers. If I can disable the third, the second becomes the primary link that the rest of the environment talks to and where the web configuration portal resides? Can I just give it one VLAN and not wory about port group 4095 and tagging traffic? If that's the case, this is really nearly identical to my 7220s, just more or less mapped to a VM?


#AirheadsMobile

[justink84]

I cant explain in detail on some of the items you had listed, although if you had concerns with disabling the vSwich security I would recommened opening a TAC case or reaching out to your local SE and asking to validate why. Just because the detail explaination may not be listed in the user-guides it doesn't mean you cant find out why. 

If the reasons as to why the features need to be disabled do not fit with your security needs; then you can always fallback to the hardware deployment model. 

L2 vs L3 redundancy with MM has its pro's and con's. In this case VRRP is used for only L2. I dont see how you would have an issue with your routers as your not trying to route the traffic. VRRP provides a faster failover as it uses the same concepts as master/redundancy. L3 failover takes around 15-20 minutes to failover, and only sync's its databases every 2 hours (lowest value supported). This includes configs, whitelist, etc. 

When you refer to multiple interfaces, its similar to any other virtual networking appliance. Just because the interfaces are required to perform an install, it doesn't mean your forced to use all of them. If you dont use an OOB interface, then just disable it. 

When you refer to making the interface as a trunk and tagging all the vlans. Im not sure as to your reasons behind this. You have to remember that the Mobility Master is there for centralization of mgmt-plane and control-plane functionality. The data-plane functionality still exists at the MD's itself. 

Services like Wired Airgroup devices would still work the same way by extending the broadcast domain to the MD, or using multicast-aggregation from the AP (L3 vlan that doesn't reside locally). Openflow is used to extend the control-palne functionality on the MM. There isn't a need to extend this vlan to the MM in order to utilize Airgroup. 

My recomendation would be to reach out to your local SE and obtain some evals so you can get the gear setup in the lab. VMC's can be used to terminate AP's and you can go through the security features you have concerns about in detail. 

[MLWeiner]

The problem is more or less I'm on my own. You are the only person I've gotten any actual information from. Everything else has been manuals, TIDs, and webinar recordings. I stopped when it seemed like things stopped making sense and the setup requirements were going off the rails. I reached out to my account team and got back in essence "I don't know what you're complaining about." I reached out to an HPE partner for help and was told "oh man, you're going for 8? Good luck, we are still doing 6.5 deployments!" So, I'm trying to wing it off the documentation on my own because I haven't been able to get clarification on anything. This was my last attempt to get answers before I gave up and just stayed with 6.5. My boss wasn't keen on the price premium for the hardware appliance unless it was absolutely necessary. The VA installation manuals say trunk the VLANs, so did one of the webinars, so that's what I assumed I had to do. When I get back to the office I can reference the exact document and page. My routers run VRRP for their redundancy and appear to be a bit territorial about it, I had to take it off my controllers because it killed my entire datacenter, so no VRRP. I can't risk that again. My SE said I should be fine without it. I'm a small organization in a very cramped building, my "lab" is a few VLANS carved off my datacenter in the basement, if this is done it's more or less done semi-hot, so I have to be very careful.


#AirheadsMobile

[cjoseph]

You should only require a single ip address for an MM (not a trunk).  There is an option to port channel more ports for additional bandwidth, but that is not necessary.  You can deploy a VRRP on and MM and give it a password on each side so that it does not conflict with HSRP or any other broadcast-based redundancy.  If you only deploy a single MM, you will not have a way to configure your controllers if it fails.  That is why you deploy a redundant MM.

Some people want to deploy an physical appliance because that is how they deploy physical servers.  If you wanted to deploy it on VMWARE, that is fine, as well.  You would only need to allow forged transmits etc. so that the server can see  and send VRRP advertisements, etc.

Please let us know if you have any more questions so that we can guide you.