Meraki is deprecating SNMPv1: what to do before your next firmware upgrade

The same announcement from Cisco Meraki showed up in our inbox twice this week. SNMPv1 is being deprecated. Once the firmware releases named in the email ship, MR access points, MX security appliances, and MS switches stop answering v1 polls. SNMPv2c stays around for backward compatibility, and Cisco wants everyone on SNMPv3.

Most shops left v1 behind years ago and can read that email and move on. But v1 hangs on in corners. It lives in old credential profiles, in scripts nobody has opened since the person who wrote them left, and in monitoring appliances whose vendor never changed the defaults. If any of that polls your Meraki gear, this email is a deadline.

What breaks if you ignore this

Nothing breaks at first. The switch takes the firmware upgrade and keeps forwarding traffic, keeps checking in to the dashboard, and nobody using the network notices a thing. What stops is the answer to your poller’s v1 request. The NMS marks the device unresponsive, or the interface graphs go flat, and no alert fires about SNMP, because from the device’s side nothing is wrong. You find out weeks later, in the middle of troubleshooting something else, when you go looking for a graph and it ends on the night of the upgrade.

The deadline is easy to beat, though. All the work in this note happens before the upgrade.

The two emails disagree on the MR firmware version

Here is the odd part. The two copies of the email disagree with each other. One says SNMPv1 support ends at MR 34.1, the other says MR 27.2, and both agree on 27.2 for MX and MS.

MR, MX, and MS firmware run on separate numbering trains, so the email alone cannot tell you which MR number is right. Seeing 27.2 in all three rows, our guess is that someone pasted the MX number into the MR row. But that is a guess, and nobody should schedule an upgrade window around a guess, or around an email that disagrees with itself between two copies.

Why we would skip SNMPv2c

The email offers v2c as the fallback, and for most tools it is the easy change, a version dropdown and the same community string. The community string is the problem, though. v1 and v2c both send it in cleartext with every poll, and the string is the entire credential, so anyone in a position to capture the traffic can read it and start asking your switches questions. What v2c added, back in the nineties, was GetBulk and 64-bit counters. The counters do help, since a 32-bit byte counter on a 1 Gbps link wraps in about 34 seconds and any graph polled slower than that comes out wrong. None of it protects the string.

SNMPv3 does. The poller authenticates as a user, the device checks who is asking, and the traffic is encrypted, so there is no string on the wire to capture.

And this is not the last SNMP migration Cisco has planned. Their program page lists SNMPv2 for removal too, on a slower schedule because so much still runs it. Migrate v1 to v2c today and you get to run this same project again in a few years. Almost every current NMS speaks v3, so go straight there.

How to find what still polls v1

Start in the poller, because the poller keeps records. SolarWinds, PRTG, LibreNMS, Zabbix, whichever you run, each device or group has an SNMP credential profile, and the profile says which version it uses. Pull that list and you have most of your v1 inventory. Then look outside the NMS, because something always polls from outside the NMS: an old script, the UPS vendor’s appliance, a capacity tool left over from a project that ended years ago. Anything with a community string in its config goes on the list.

If anyone disputes the inventory, capture the traffic. Every SNMP packet says which version it is in the header, so a capture on UDP 161 at the poller or at the switch is the tiebreaker: 0 means v1, 1 means v2c, and 3 means v3. Version 0 packets arriving at a Meraki switch mean something is still polling v1, whatever the credential profiles claim.

One Meraki detail before you start clicking: SNMP lives in two places here. The dashboard can answer polls from the cloud, and the devices can answer polls on the LAN. This announcement is about device firmware, so the device-side agent is the one changing. Check both while you are in there, since the v1 question is the same in each spot.

The migration, in order

1. Write down everything that polls Meraki gear over SNMP and the version each one uses.
2. Set up SNMPv3 on the Meraki side, with both authentication and privacy, and load the credentials into the poller.
3. Move one site to the v3 profile and let it run for a few polling cycles to confirm the data keeps flowing.
4. Move the rest, then turn off community-string access so nothing can fall back to it.
5. Approve the firmware upgrade.

The upgrade goes last on purpose. Once it ships, a poller you missed shows up only as monitoring that has stopped, and no alert points at the cause.

More of these emails are coming

The email links to a Cisco program page called Resilient Infrastructure, and the page is worth ten minutes. Cisco plans to remove insecure features across the whole portfolio in three steps: first the software warns you when you configure the feature, then new installs get it disabled by default, then it comes out of the code entirely. New installs will also ship with SNMP, the web server, and guest shell turned off. TACACS+ over TLS and RadSec for RADIUS are on the roadmap, and SNMPv2 is already on the removal list.

So SNMPv1 on Meraki is one line item in a program that will keep producing emails like this one, and other vendors are running similar programs. Our advice is to handle each notice the same way on arrival: confirm the release in the release notes, find what uses the feature, migrate it, verify it, and write it in the change log. That turns the next one from a surprise into an afternoon of scheduled work.

Where to start

Count the v1 entries in your NMS credential profiles today. If the count is zero, confirm it with a capture and archive the email. If it is not, you have a few hours of work per site ahead of you, and doing it now is far easier than diagnosing dead graphs after the upgrade.