At VMware Explore 2026, Broadcom detailed what's coming in VMware Cloud Foundation 9.1: more flexible transit gateways, smarter workload placement across clusters, and native EVPN VXLAN support in the physical fabric — all built on the public-cloud-style VPC model that VCF 9.0 layered over NSX's tier-0 and tier-1 gateways.
That's genuinely good engineering. It's also another two or three layers between a user clicking Save and a packet arriving at a server: VXLAN tunnels over a routed underlay, gateways inside gateways, and a control plane that can reconverge in ways that look like intermittent flakiness rather than a clean outage.
Which raises the question every IT manager should ask before admiring the roadmap: when something in that stack breaks, how fast do you know — and how fast do you know where? For most teams the honest answer is: a user tells you, then someone spends 45 minutes hopping between vSphere Client, NSX Manager, two SSH sessions, and a helpdesk tab trying to find which layer is lying.
The network is getting more sophisticated every year. Network visibility at most shops hasn't moved since the last Visio refresh.
The Problem: Every New Layer Is Another Place to Lose a Packet — and Another Console You Don't Have
Walk through a scenario that's already familiar to anyone running NSX today, and will get more common as EVPN VXLAN spreads into the physical fabric. A VM in a VPC can suddenly reach some destinations but not others. Where's the fault? Could be the vNIC, the port group, a distributed firewall rule, the tier-1 gateway, the VXLAN encapsulation, a ToR uplink, a spine link, the BGP EVPN session, or an MTU mismatch buried in the underlay. Each candidate lives in a different console, owned by a different person, running on a different tool.
And the existing tooling fails quietly, in specific and recognizable ways:
- Ping-only monitoring reports "up" while users report "down." A device happily answers ICMP while its uplink is flapping and dropping a third of production traffic. Or EVPN reconverges around a failure, the ping stays green, and nobody notices the degraded path until the ticket queue fills up. Latency and loss don't show up in a poll that only asks "are you alive?"
- Your network map is a quarterly guess. Discovery scans that run every 90 days, plus a Visio diagram from the last audit, miss the new IP camera cluster, the unmanaged switch a vendor left under a desk, and the printer that moved floors. When the incident starts, the map is a work of fiction.
- RMM only sees what has an agent. IP cameras, HVAC controllers, IoT devices, and that stray switch don't exist to an agent-based tool — which means they can't be alerted on, ticketed, or placed on a map.
- The helpdesk has zero network context. Ticket #4471 says "internet is slow." Nothing links it to the flapping uplink your network tool detected 20 minutes earlier, so the tech starts from scratch and the user gets the "have you tried turning it off and on" treatment.
- Everything is siloed by architecture, not by choice. The network team's SNMP tool, the server team's RMM, the standalone helpdesk, the PSA — no shared object model means no correlation, and no correlation means every incident is a manual join across five tabs and four logins.
The business impact is boring and brutal. Connectivity incidents that a topology-aware alert would catch in one notification become 45-minute multi-console investigations plus a dozen duplicate tickets. SLAs get missed not because anyone was slow, but because the first 30 minutes were spent establishing basic facts. The 2 a.m. page says "host unreachable" without saying why or what else was attached to that switch, so the on-call tech wakes up half the team to be safe. And the server team and network team burn goodwill on each other in an endless "works on my machine" loop.
For an MSP running a NOC, multiply that: a dozen client environments, each with its own quirks and its own half-accurate inventory. Every "is it the network?" ticket is 30–40 minutes of triage across consoles with separate logins. That's not a tooling annoyance — that's margin walking out the door.
How AlertMonitor Closes the Visibility Gap
AlertMonitor starts from a different assumption: you can't monitor a network you haven't discovered. So discovery is continuous, not scheduled. SNMP, ARP, and active scanning build a live inventory of every switch, firewall, access point, printer, IP camera, and unmanaged endpoint — including the devices that will never run an agent.
That inventory feeds a live topology map that reflects the network's state right now. When a switch goes offline, a link drops, or a new device appears, an alert fires instantly — with full network context attached. Not "host down." Instead: "Uplink Te1/0/24 on CORE-SW-02 went down; here are the 14 devices downstream, here's where this link sits in the topology, here's its flap history."
Compare the workflows:
The old way: User complains → ticket created in the helpdesk → tech remotes in → checks the VM → opens NSX Manager → SSHes to a switch → asks in chat if anyone changed anything → eventually finds the flapping uplink. Forty-five minutes, five tools, one frustrated user.
The AlertMonitor way: Link-drop alert fires with topology context and downstream impact → tech opens the alert → sees exactly which uplink, which devices, and which users already have tickets → fixes or fails over → the linked ticket updates automatically. Minutes, one console.
Because monitoring, RMM, helpdesk, and patch management live in the same platform, the chain doesn't break at the alert. The alert links to the device. The device links to the endpoints behind it, their agent state, their patch status, and the open tickets from affected users. When Broadcom ships AI for networking inside the VMware stack, that will be great for NSX-internal decisions — but your observability still has to span the physical fabric, the overlay, and every unmanaged device in between. That span is exactly what a unified platform is for.
The measurable result: connectivity MTTR drops from ~45 minutes to single-digit minutes, page volume drops because state-change alerts are precise instead of ping-derived guesses, and the "is it the network?" argument dies because everyone is looking at the same live map.
Practical Steps You Can Take Today
1. Find out how wrong your current inventory is. Run a fresh discovery pass and diff it against your CMDB or diagram. You will find devices nobody mapped. That gap is your current blind spot.
2. Make sure SNMP is actually enabled on your Windows endpoints — otherwise any discovery engine is blind to them:
$servers = Get-Content .\servers.txt
Invoke-Command -ComputerName $servers -ScriptBlock {
Get-Service -Name SNMP -ErrorAction SilentlyContinue |
Select-Object PSComputerName, Status, StartType
}
Install it where it's missing:
Invoke-Command -ComputerName $servers -ScriptBlock {
if (-not (Get-Service -Name SNMP -ErrorAction SilentlyContinue)) {
Install-WindowsFeature SNMP-Service -IncludeManagementTools
}
}
3. Ask your switches directly what's going on. Pull interface status with snmpwalk and show only the ports that aren't up:
snmpwalk -v2c -c "$COMMUNITY" "$SWITCH_IP" IF-MIB::ifOperStatus | grep -v "up(1)"
Then check the counters ping will never show you — errors and discards on supposedly healthy links:
snmpwalk -v2c -c "$COMMUNITY" "$SWITCH_IP" IF-MIB::ifInErrors
snmpwalk -v2c -c "$COMMUNITY" "$SWITCH_IP" IF-MIB::ifInDiscards
If this output disagrees with what your monitoring platform claims, you've just located your gap.
4. Test MTU along your VXLAN paths before EVPN makes it matter more. VXLAN encapsulation adds roughly 50 bytes of overhead, and VMware recommends the physical underlay carry at least 1600-byte frames. A marginal path shows up as exactly the intermittent connectivity users love to report:
ping 10.20.0.50 -f -l 1550
bash ping -M do -s 1550 10.20.0.50
If 1472 bytes succeeds but 1550 fails, something in the path is fragmenting or dropping — find it now, before a VCF 9.1 fabric depends on it.
5. Stop doing this by hand. Each check above is useful once and worthless as a habit, because the network changes faster than any audit schedule. The goal is turning discovery, mapping, and state-change alerting into a continuous process — which is precisely what AlertMonitor does: continuous SNMP/ARP/active discovery feeding a live topology map, instant alerts with full network context, and that data wired into the helpdesk, RMM, and patch management so the alert, the device, and the fix path are one object instead of five tabs.
VCF 9.1 will make VMware's networks smarter. Make sure your visibility keeps up — because your users certainly won't wait for your next quarterly scan to find out it hasn't.
Related Resources
AlertMonitor Network Monitoring & Visibility
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.