Arista Pre-Announced a Wave of Advisories — Here's How to Keep Your On-Call Out of the Alert Storm

Arista Networks just did something unusual: it warned customers in advance that a wave of security advisories is coming next week. CTO Kenneth Duda and CISO Jason Bevis explained that AI-driven changes to Arista's vulnerability detection processes mean an elevated volume of advisories and batched releases — across Arista EOS and VeloCloud — for at least the next few months. The advance notice is meant to help customers plan.

That transparency is genuinely welcome. But be honest about what it means for the people running the network: a batch of updates for core infrastructure, landing on your calendar, likely outside business hours — and a very real chance that the night you patch 30 switches is the night your monitoring tool pages your on-call tech 40 times for a change you scheduled yourself.

If you've lived through a patch wave with a legacy NMS, you know the pattern. You book the window, you execute the change cleanly, and you still spend the next morning apologizing to whoever was on call, triaging 150 alerts that were really three root events, and figuring out which tickets were noise. The advisory wave isn't the operational problem. Your alert pipeline is.

The Problem in Depth

Alert storms during planned changes. You're upgrading EOS on the distribution stack. The upgrade takes 20 minutes per switch. A traditional SNMP poller on a 5-minute cycle watches each switch drop and fires an alert, then watches 60 downstream devices go unreachable and fires 60 more, then logs recovery notices and a fresh round of flap warnings. One well-executed maintenance window generates well over a hundred alerts. Every single one routes to the same phone.

Maintenance windows that don't propagate. The change is on the calendar. It's in the PSA. But the monitoring tool doesn't read either, so suppression is manual: a tech disables alerting per device before the window. They'll miss one — probably a VeloCloud edge added last month that never made the suppression list — and on-call gets an 11:47 PM page for a device rebooting exactly as planned. The opposite failure is worse: alerting gets disabled, nobody re-enables it, and a genuine outage three weeks later goes silent.

No deduplication, no root-cause collapse. When a core switch reboots, the real event count is one. What most tools display is one alert per affected child device, per severity rule, per poll cycle. Without topology awareness, the tool can't know those 60 "device down" alerts are symptoms of a single planned reboot. Your on-call tech does that correlation manually, at 1 AM, from memory.

Tool sprawl turns triage into archaeology. The NMS says the device is down. The helpdesk holds the change ticket. Firmware status lives in a vendor portal or a spreadsheet. The tech supporting 40 client sites has to cross-reference four systems to answer one question: "Is this planned?" And every vendor advisory wave — like the one Arista just pre-announced — means manually exporting inventories to figure out which client runs which EOS version on which hardware.

What it costs. Mean time to acknowledge stretches from minutes to half an hour because on-call has learned that most pages are noise. Industry surveys have long put alert noise and duplicate volume at 30% or more of everything a monitoring stack emits — and anyone who has run on-call knows that estimate is optimistic. SLA reports become indefensible because ticket clocks started on the first symptom alert, not the understood incident. And there's the quiet attrition problem: the senior network engineer who is done being woken up for your own change windows, and who takes the other job.

How AlertMonitor Solves This

AlertMonitor was designed around a specific insight: alert fatigue isn't a volume problem — it's a signal quality problem. You don't survive a patch wave by muting everything. You survive it by making sure every alert that reaches a human carries full context and collapses to the real event.

Maintenance window suppression that actually works. Schedule the window once — "Arista EOS patch wave, Friday 23:00–03:00" — and apply it to a device group or tag covering every affected switch and VeloCloud edge, across all clients if you run an MSP. Suppression is scoped and expires on its own. No per-device disabling, nothing to remember at 3 AM. Genuine critical failures during a suppressed window still follow your escalation policy, so you choose whether true emergencies break through or queue for morning review.

Smart deduplication collapses the cascade. When the core switch drops mid-window, AlertMonitor correlates the downstream failures into a single incident anchored to the root device. On-call sees one meaningful signal — "SW-DIST-01 down, 62 devices unreachable downstream, inside scheduled maintenance window" — not 60 pages of noise.

Full context on every alert. Every alert carries the device, the client, what changed, and what healthy looks like. The 2 AM tech doesn't need four browser tabs to answer "is this planned?" — the incident itself says so, and links straight to the change ticket.

Multi-level on-call routing. Real issues route by severity and category. A network-critical alert pages the network on-call on a short acknowledgment timer and escalates to secondary if unacknowledged. Low-severity flap warnings from the same window queue for the morning shift instead of waking anyone.

Topology mapping makes impact predictable. Before the window, you can see exactly what sits downstream of each device you're about to reboot — so you sequence the change correctly, warn the right stakeholders, and your monitoring's expected behavior matches the maintenance plan.

Integrated helpdesk closes the loop. The change ticket auto-links to the incident timeline. Post-window verification confirms every device came back healthy, the incident auto-resolves, and the ticket closes with a complete audit trail — which, for an MSP, becomes the client report you used to assemble by hand.

The practical difference: a patch night that used to mean three hours of triage, 150 alerts, and one resentful engineer becomes a scheduled window, one collapsed incident, automated verification, and a closed ticket.

Practical Steps

Get ahead of the Arista advisory wave — or any vendor batch release — this week.

1. Build your exposure inventory first. Before the advisories drop, know exactly which devices run which EOS version:

#!/bin/bash
# Pull EOS version and model from a list of Arista switches
SWITCHES="sw-core-01 sw-core-02 sw-agg-01 sw-dist-01 sw-branch-01"
for sw in $SWITCHES; do
  echo "=== $sw ==="
  ssh -o ConnectTimeout=5 admin@${sw} \
    "show version | include image version|Model name" 2>/dev/null
done

In AlertMonitor, tag and group every affected device — by vendor, model, and site — so the maintenance window and suppression apply to all of them in one action instead of 30 separate ones.

2. Snapshot server health before the window. If switch or VeloCloud reboots will briefly interrupt branch connectivity, capture a baseline on affected servers so post-change issues are obvious:

# Pre-maintenance health snapshot for servers affected by the patch window
$servers = "file01","sql01","rdsgw01"
Invoke-Command -ComputerName $servers -ScriptBlock {
    [PSCustomObject]@{
        Host           = $env:COMPUTERNAME
        CDiskFreeGB    = [math]::Round((Get-Volume C).SizeRemaining/1GB,1)
        PendReboot     = Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'
        StoppedAutoSvc = (Get-Service | Where-Object {
            $_.StartType -eq 'Automatic' -and $_.Status -ne 'Running'
        }).Name -join ', '
    }
} | Format-Table -AutoSize

3. Schedule the maintenance window in AlertMonitor — once. Create the window, apply it to the tagged device group, set start and end times. Suppression is scoped and self-expiring; there is no manual re-enable step to forget.

4. Review your escalation policy before the window, not during. Confirm that genuine network-critical alerts still route to a human on a short acknowledgment timer, and that low-severity flap noise from the same window queues instead of paging. Five minutes of policy review saves the whole night.

5. Verify recovery before closing the ticket. After the upgrades, sweep the fleet and confirm every device is reachable and answering:

# Post-maintenance verification sweep for patched devices
$devices = Get-Content .\arista_switches.txt
$results = foreach ($d in $devices) {
    [PSCustomObject]@{
        Device  = $d
        PingOK  = (Test-Connection -ComputerName $d -Count 2 -Quiet)
        SSHOpen = (Test-NetConnection -ComputerName $d -Port 22 `
                    -WarningAction SilentlyContinue).TcpTestSucceeded
    }
}
$results | Export-Csv .\post_patch_verification.csv -NoTypeInformation
# Print only failures — this should be an empty list
$results | Where-Object { -not $_.PingOK -or -not $_.SSHOpen }

Attach that CSV to the change ticket in AlertMonitor's helpdesk, and the audit trail — window, suppression, incident timeline, verification — is complete without a single manual status update.

6. Review what actually paged. After the window, check the incident list. If anything outside the deduplicated root incident reached a human, that's your cue to tighten a threshold or re-scope a group. Run this loop after every batch release and one clean patch night becomes an operationally quiet quarter.

Arista is doing its part by giving you a heads-up. The rest — turning that warning into planned, quiet maintenance instead of a 2 AM alert storm — comes down to your alerting architecture. If next week's advisory wave makes your on-call rotation flinch, that's the tool's fault, not the team's.

Related Resources

AlertMonitor Alert Management & On-Call Operations AlertMonitor Platform Overview Book a Demo Alert Management & On-Call Operations Resources