Mobility Field Day has become a staple in my annual calendar. So much so that last year, I even got to be a delegate at MFD13. If you're not familiar with the MFD events (well, all of the Tech Field Day events really), they're a multiday event where companies present their newest products, innovations, and updates to a panel of industry professionals (in my case, we use that term a little lightly), called delegates. These delegates can then ask questions, poke and prod, and give feedback directly to the presenters. The Tech Field Day events run across a variety of major topics. Be sure to check out the TFD website for information on all the events (or to apply to be a delegate!), because there's some amazing content out there! This year I only had time to watch a couple of the presentations live, but plan to go look at the recordings for a couple more.
The biggest interest to me (for a variety of reasons, not the least of which is my MistFits status) this year was the HPE Networking presentation. This was the first event post-acquisition closing. So we got some insights into how the combined forces of Aruba and Juniper were performing. And while it wasn't without a bit of confusion at times, overall it was another solid showing from the mostly-former-Juniper-led team. Overall, I think there was a TON of good content. It varied between the 2 cloud platforms and touched a little on the on-prem side of things. It also bounced between overall informational (like the incredible info from Wes Purvis on 6GHz and Wi-Fi 7 adoption) and new features (see below). And while it was *only* 3.5 hours, it really felt like it could have been 6-8. So let's jump into what I thought were the big takeaways on new features. This isn't necessarily in order of appearance; it's what I consider the biggest announcements.
1. One Team, One Vision, One Execution
Although it's not a technical feature, this item is critical to how things are moving forward at HPE Networking. And it was prevalent throughout the entire presentation. You heard it directly from leadership at the start, and it was reflected in their discussion of the features and functionality being rolled out across both cloud platforms (Aruba Central and Mist). They've combined the previously 2 separate teams and are pushing forward together in everything. What's fantastic to see is the speed at which the teams have been integrated and started working together. We're also already seeing feature cross-pollination between the platforms. For example, the Aruba Central Organizational Insights views have come over to Mist. And Mist's LEM and other AIOps features are coming to central. And moving forward, features are developed such that they can be deployed to both platforms simultaneously.
2. New Dual Platform AP Immediately Available
While this isn't specifically new (we heard it starting at Discover Barcelona last year), per Wes, moving forward, ALL new HPE networking APs will be dual platform. But rather than just giving one of the engineering teams free rein, they built a foundation of requirements of what was critical for an AP, and moved forward with that as the guiding principles. And while both Juniper and Aruba were pretty complete with their Wi-Fi 7 lineups, I think this is one of those trial-run devices to see how things work in preparation for the big launch of Wi-Fi 8 APs in "a couple" years. It's also a change from "it's coming" to "it's here."
So let's chat about the AP-723H (for Hospitality). This follows the more Aruba-legacy naming convention. This is a wallplate/desktop-mount AP with 3 Wi-Fi radios, a couple of downlink ports, IOT radios, and a scanning radio. It lines up pretty well with both Aruba and Mist's existing wall plate APs. The interesting part is the dual platform piece. HPE is addressing this by having the AP reach out to both cloud platforms on first boot to determine where it's registered. Whichever cloud platform replies first, the AP locks to that platform and boots into that platform's code. From then on, it will only operate as an AP on that platform. While there is a mechanism to "reset" the AP so it can be switched to "the other" platform, it's not meant to be a daily occurrence.
3. Inline Microsegmentation with Mist
This feature is the first of 3 security related features tied into Mist Access Assurance. And it's a doozy. One of the big buzzwords in networking that continues to show up these days is microsegmentation. While it's not a new concept, it still pops up frequently. A lot of the reason behind that is that while it's a simple concept, it's not an easy project to deploy at scale. If you're not familiar, microsegmentation is the concept of defining and applying security policies to very small (micro, even!) groups of devices. At its most drawn-out deployment, you're talking about security policy per user per host. From a network perspective, we have been segmenting our network for decades. We've used VLANs to separate different pieces of the network. But a VLAN can still be a large group of devices. And it gets unwieldy (at best) and impossible (at worst) to use VLANs to microsegment a network. And just to make sure I'm clear, VLANs are NOT a security tool. So even if you are to use VLANs to heavily segment your network, you still need security enforcement points. And the farther away from the user that these security enforcement points sit, the less effective they can be. Many microsegmentation tools utilize client-based agents. This is a software package that resides on the client and inserts itself into the network stack. This gives you the ultimate control over how policy is enforced because it's as close to the edge as you can get. But that comes at a price. More and more tools and software packages utilize agents. But, as a company deploys more and more tools for various things, you get more and more agents on the end-user device. Which can start to conflict with each other, bog the computer down, or cause many other fun behaviors. So many companies have looked to reduce the number of agents on their end-user devices. Plus, in Bring Your Own Device networks, having to have someone install a ton of agents on their devices is usually a no-go.
So how can the network help with microsegmentation? The question, as with most networking answers, is "It Depends". To keep this from being a blog post just on microsegmentation (though maybe I should write one of those too someday), let's go with most major networking vendors support proprietary features that can deliver. It usually blends proprietary components with standards-based ones. And then there are usually some specific requirements. If we look at Mist-based wired networks, the IP CLOS-based campus fabric can be a good tool for large campus networks. With this solution, we can leverage Security Group Tags (SGTs) with the VXLAN header to perform smaller than VLAN groupings. When we combine that with a security policy, we get microsegmentation. But that requires the highest level of campus fabric deployment and specific switch models.
But what if the switches could communicate groupings to each other? Similar to how the Mist APs do this for Personal Pre-Shared Key Networks. Well, that's what this announcement is! HPE Networking announced that they're using some switch-to-switch communication to relay a MAC to Group Based Policy (GBP) tag (GBP tag is close enough to be synonymous with SGT) mapping. This allows the policy to then be applied to traffic flows between devices. And this means regardless of if they're on the same VLAN. Which is where macrosegmentation breaks down. And it doesn't require a full network rearchitecture or top-of-the-line switches. This is really cool. So now, on your existing L2/L3 network, you can add policy enforcement, both intra-VLAN and inter-VLAN. Without additional tooling. This is definitely a great move and one that can be used to enhance other toolsets and security layers. Security is NEVER about a single point of enforcement (or shouldn't be). Defense in Depth calls for multiple overlapping layers that support each other and allow for a more robust security posture than a single component can give. And this is just one more tool in the box!
4. Network Access Control (NAC) policy dry run with Access Assurance
Ok, this next one was probably my favorite feature released today. I would have saved it for last, but the last one builds on this, so it makes more sense to put this here. One of the biggest potential issues with NAC, especially when you have complex rulesets, is that when you need to make changes, you have to ensure you put in the right changes in the right place in the policy stack. A wrong rule can grant access you don't want or deny access to people you do want. Or if you put the rule in the wrong spot in the stack, you can overshadow other rules without knowing it. It's why in most NAC deployments we end up with labs, long test plans, and lots of clients to test with. While this new feature doesn't remove all of that, it lets us test the results before making the rule go live (and breaking things). The dry run features let us put a rule in place, tag it as a dry run, and then evaluate live user sessions against it. So if we're making a small tweak to a particular client's access, we can add the dry-run rule and see if it works as expected. And then make sure other users don't match it as well. While this sounds like a "duh, shouldn't everything have this?" kind of feature, it's much less common than you'd think! And it's just one of the many quality-of-life features that Access Assurance has baked into it. Which is why it's such a great NAC tool!
5. NAC policy validation with Access Assurance
Ok, last one for this time. This feature allows us to leverage Marvis's strength to evaluate our NAC policy. We've seen something similar with some firewall vendors, but bringing this to Access Assurance, especially when coupled with the previous dry-run feature, gives us a strong way to maintain our NAC policy stack and keep it running cleanly. One of the problems we see with security policy over time is that it grows and adapts to new needs. But it's not always cleaned up when things are no longer used. It ends up with a lot of rules that aren't clear whether they're still needed. You can't go off of hit count, because maybe it's only needed once a year. Or maybe people have added extra rules that overshadow other rules because they "just need it to work now". Whatever the case, I'm seeing more and more vendors adding policy review methods. And this one for Access Assurance really is a great time saver. You can ask Marvis to review the NAC policy, and it will walk through things (including dry-run rules) and let you know where there might be issues and how to remediate them! You can now build a new rule, set it to dry run, validate the hits against it, and then ask Marvis if that will cause any issues with other rules in the existing policy. This really takes the FUD out of making NAC rule changes.
Bottom Line
This article only touches on what I think are the coolest announcements from HPE Networking at MFD14. If you want to read the official HPE Press Release on the features, you can find it here. There were many more (including a lot of Aruba Central content), and despite some confusion from switching platforms during the talk, it showed HPE Networking is moving full speed ahead with both Aruba and Juniper resources. The usual multi-year lag after acquisition before any integration is non-existent. From new co-released features to cross-pollination features to common hardware, barely months after the ink was dry, we're seeing real results from this team and vision. I wasn't expecting anything less, given the leadership in place. But it was definitely a concern as we waited for the acquisition to close. And some of my customers were in the same boat. I continued recommending Aruba or Juniper during the waiting period (if the use case fit), but I now have even less concern about either solution. I still have my favorites, of course, but that's to be expected ;) Until next time!
