Cornelis Networks just closed a $205 million round to fund an idea that would have sounded like science fiction a decade ago: a network fabric that doesn't just move packets between endpoints, but computes on them while they're in flight. The company — spun out of Intel in 2020 by the team behind Omni-Path — calls the architecture Active Compute Fabric, and it targets AI and HPC environments where every microsecond of idle compute is money burned.
Good for them. But read that story while you're on call and it produces a very specific kind of whiplash. At the bleeding edge, the network is becoming an active, programmable participant in the workload. In the average corporate or MSP-managed environment, the network is still a black box — discovered by quarterly scans, documented in a Visio diagram that survived three office moves, and diagnosed by walking the floor with a laptop and a console cable.
Here's the uncomfortable question that $205M raise should prompt for every IT manager: if the network can now compute, why can't your monitoring stack tell you what's plugged into access switch 3?
The Real Problem: Your Tools Watch Boxes. Nobody Watches the Network.
Most IT shops run some combination of an RMM platform for servers and endpoints, a ping-based monitor for "is it up," and a standalone helpdesk for complaints. Each tool sees a slice of the environment. None of them sees the graph — the actual topology of what connects to what, and everything that breaks when a single link drops.
That gap is most visible in discovery. In most organizations, network discovery is a batch job that runs quarterly — if it runs at all. The output lands in a spreadsheet that's out of date the moment someone plugs in an access point. The RMM knows the servers. The helpdesk knows the complaints. Nobody owns the map, so nobody can answer the only question that matters during an outage: what is actually affected, and where is it?
Walk through what happens when an access switch power supply dies at 6:52 AM on a Tuesday:
- No useful alert fires. The switch might be ping-monitored, but the alert lands in a mailbox that gets checked twice a day — or the switch was never onboarded after the last office move.
- 23 users can't authenticate. Ticket #1 arrives at 6:58 AM. By 7:15 there are 19 more, all variations of "the internet is down."
- Your tech plays detective. Remote into a domain controller, check DHCP leases, RDP into a workstation on the affected VLAN, run
arp -a, ping the management IP of every switch you can remember, guess at cabling. - Fifty minutes later, someone is standing in a comms cabinet with a laptop and a console cable, confirming what a live topology map would have said in the first ten seconds.
- And here's the part that stings: nobody knows what else was behind that switch. The badge reader's controller, the warehouse label printer, a vendor's NAS that never made it into documentation — those devices stay down for days, because no map says they were ever there.
Why These Gaps Exist
It's not negligence — it's architecture:
- Discovery was designed as a batch job. Most discovery engines were built in the 2000s, when "scan everything once a quarter" was an acceptable answer. Networks change daily; the tooling model never caught up.
- RMM vendors treat the network as an afterthought. Endpoint management pays the bills, so network visibility ships as a bolt-on module that pings devices and calls it monitoring.
- The helpdesk has zero network context. Tickets and topology live in different databases, so the service desk takes outage calls before the network team even knows there's an outage — or vice versa.
- Tool sprawl multiplies the blind spots. Five tools means five inventories, five dashboards, five definitions of "critical," and no single source of truth.
What It Costs
An hour of unplanned network downtime routinely costs a mid-sized organization thousands in lost productivity — and that's before the follow-on effects: the warehouse label printer that stays down for four days because it wasn't on any map, the IP camera controller nobody associated with that switch, the compliance question you can't answer ("what devices were on the network last month?") because discovery last ran in March.
For an MSP, the math is worse: one undetected switch failure is two tech-hours of detective work, a response-time SLA breach, and a client conversation you didn't want to have. Multiply that across 30 clients over a quarter and you get the real cost — burned-out techs who quit, and margins that quietly evaporate.
How AlertMonitor Turns the Network From a Black Box Into a Live Map
AlertMonitor starts from a different assumption: the network model should be continuous, not scheduled.
- Continuous discovery across every device class. Using SNMP, ARP, and active scanning, AlertMonitor discovers and maps switches, firewalls, access points, printers, IP cameras, and unmanaged endpoints — not just the servers your RMM agent happens to live on. New gear appears on the map without anyone "onboarding" it.
- A live topology map, always current. When a switch goes offline, a link drops, or a new device appears, an alert fires instantly — with full network context attached: which device, which switch and port, which uplink path, which downstream endpoints just went dark, which VLAN and users are affected.
- New-device alerts that catch problems before they become tickets. An unknown MAC appearing on a port — vendor lookup included — is how you catch the rogue access point under the conference room table and the forgotten NAS before they cause an outage or a security review.
The Workflow, Before and After
Old way: user ticket at 6:58 → remote session → pinging things → console cable at 7:40 → fix at 7:45 → 23 tickets closed individually with no shared root cause.
AlertMonitor way: alert fires at 06:52:10 — CORE-ACC-03 unreachable, 14 downstream devices impacted → open the live map → see exactly which endpoints and users are affected → one tech dispatched to a known target → switch back online at 07:05 → alerts clear, auto-linked tickets resolve with the full timeline attached.
That's the difference between an hour of detective work and a ninety-second, targeted response. Teams running live topology with context-rich alerts typically cut network-related MTTR from the 45–60 minute routine to under ten minutes — because the first hour gets spent fixing, not locating.
And because monitoring, helpdesk, RMM, and patch management run on one platform, the chain doesn't stop at the alert: the alert creates the ticket, the ticket links to the device, remote actions happen from the same console, and your SLA report finally reconciles — because it's all one database, not four systems arguing with each other.
What You Can Do Today
You don't need new budget to start closing this gap tonight. Build a baseline of what's actually on your network and watch it for changes:
1. Snapshot and diff your LAN (PowerShell, scheduled every 15 minutes):
# lan-baseline.ps1 — snapshot reachable ARP neighbors and flag new devices
$Baseline = "C:\IT\NetBaselines\arp-neighbors.csv"
$Current = Get-NetNeighbor -State Reachable, Stale, Permanent -ErrorAction SilentlyContinue |
Where-Object {
$_.IPAddress -notmatch '^(224\.|239\.|127\.|169\.254\.)' -and
$_.IPAddress -notmatch ':'
} |
Select-Object IPAddress, LinkLayerAddress, InterfaceAlias, State
if (-not (Test-Path $Baseline)) {
$Current | Export-Csv $Baseline -NoTypeInformation
Write-Host "Baseline created with $($Current.Count) devices."
return
}
$Known = Import-Csv $Baseline
$NewOnes = Compare-Object $Known $Current -Property IPAddress, LinkLayerAddress |
Where-Object SideIndicator -eq '=>'
if ($NewOnes) {
Write-Warning "New devices on the LAN since the last run:"
$NewOnes | Select-Object IPAddress, LinkLayerAddress | Format-Table -AutoSize
# Pipe this into your alerting/notification channel
}
$Current | Export-Csv $Baseline -NoTypeInformation -Force
2. Build a 30-second triage script so your first responder stops guessing which layer failed:
# triage-network.ps1 — is it the WAN, the core, or one access switch?
$Targets = [ordered]@{
'ISP Gateway' = '203.0.113.1'
'Firewall WAN' = '203.0.113.2'
'Core Switch' = '10.10.0.1'
'Access SW-03' = '10.10.0.13'
'DHCP Server' = '10.10.0.10'
}
foreach ($t in $Targets.GetEnumerator()) {
$up = Test-Connection -ComputerName $t.Value -Count 2 -Quiet
$status = if ($up) { 'UP' } else { 'DOWN <-- start here' }
'{0,-14} {1,-15} {2}' -f $t.Key, $t.Value, $status
}
3. If you live in Linux land, the same neighbor-watch pattern works with iproute2:
#!/usr/bin/env bash
# lan-watch.sh — flag devices that appeared on the LAN since the last run
# Cron: */15 * * * * /usr/local/bin/lan-watch.sh
BASELINE="/var/local/lan-neighbors.txt"
ip neigh show | awk '$2 != "FAILED" && $2 != "INCOMPLETE" && $1 !~ /:/ {print $1, $5}' | sort > /tmp/current-neigh.txt
if [ -f "$BASELINE" ]; then NEW_DEVICES=$(comm -13 "$BASELINE" /tmp/current-neigh.txt) if [ -n "$NEW_DEVICES" ]; then echo "New LAN devices detected:" echo "$NEW_DEVICES" # Hook into your notification channel here fi fi
cp /tmp/current-neigh.txt "$BASELINE"
4. Then stop doing it by hand. These scripts are stopgaps — they tell you that something changed, but not where it sits in your topology or what else is affected. That's the job AlertMonitor does continuously: enable discovery on your core infrastructure, let the live topology map build itself, set alert policies on link drops and new-device events, and wire network alerts into helpdesk auto-ticketing so the first alert and the first ticket arrive in the same second.
The Takeaway
Cornelis is betting $205 million that the network should be an active participant in the workload instead of a dumb pipe. Your users are making a similar bet every morning — that someone is an active participant in watching the network instead of finding out from a complaint. A live, continuously discovered topology map with context-rich alerts is the cheapest possible way to win that bet.
Related Resources
AlertMonitor Network Monitoring & Visibility AlertMonitor Platform Overview Book a Demo Network Monitoring & Visibility Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.