New Tool - OS Upgrade Path Finder

New on the Network Tools page: the OS Upgrade Path Finder. You tell it what you’re running and where you want to land, and it figures out the hops.

Why does this exist? Because we got tired of checking all the vendor sites every time we had to plan an upgrade, just to find out what can go to what. We wanted to save ourselves some time, and figured why not share!

Just keep in mind that what’s here isn’t guaranteed to be 100% correct. It’s our best understanding of what the vendors publish, and things can and do change. Be sure to always check with TAC.

So we skimmed all of it, so you don’t have to. 🙂

What we have

Six planners, all reached from one finder page:

• Cisco IOS XE — Catalyst 9000, reload or ISSU, built from Cisco’s own ISSU matrix.
• Cisco IOS XR — Cisco 8000, NCS 540, NCS 5500/5700 and ASR 9000, including SMU advice and the field notices that bite.
• Cisco NX-OS — Nexus 9000/3000 and Nexus 7000/7700. They follow Cisco’s own path logic and have been checked against Cisco’s own page, pair by pair. But hey, “trust me” that we got this right.
• Cisco Secure Firewall — Threat Defense managed by FMC. It puts the Management Center and device upgrades in a safe order and checks FXOS minimums on the 4100/9300, because upgrading the wrong thing first is a classic.
• Juniper Junos — EX, MX, QFX and SRX. SRX paths come straight from Juniper’s own SRX upgrade table, and QFX and SRX get NSSU, ISSU and chassis-cluster upgrades where Juniper documents them.
• Palo Alto PAN-OS — firewalls and Panorama, with the skip-up-to-three-releases rule and your exact model checked against the compatibility matrix.

Fortinet and Arista are on the finder as link-outs, and they’re clearly labelled as leaving this site. Fortinet already has a good tool of its own, so we just point you at it. Arista doesn’t publish a path matrix at all, so you get links to their upgrade docs instead. Meraki, Mist and Aruba Central are cloud-managed, so the dashboard handles it and there’s nothing to plan.

What you get back

• The hop-by-hop path, why each hop exists, and the commands for it.
• Your hardware checked against the vendor’s tables, so it won’t route you through a release your box can’t run.
• Where every release sits in the vendor’s end-of-sale and end-of-support timeline, so you know if you’re about to upgrade into a release that’s already on the way out.
• For Junos, a Backup and fallback section on every plan: save the rescue config, take the snapshot your platform actually supports, and know how to roll back. This one has some fun corners. Some Routing Engines need the VM host snapshot, and Juniper’s own docs say a few models don’t support a device snapshot at all. Better to find that out from a web page than from a failed upgrade.
• Paste your show version and it fills in the platform and release for you, because typing is for suckers.

Where the data comes from

All of it is read from the vendors’ own published tables and docs, and each tool shows a “data checked” date. Everything runs in your browser; nothing you paste goes anywhere.

Docs rot, so a little script on a server checks the vendor pages behind the tools once a month and emails us if one changed or if we haven’t re-verified something in a while. It’s not magic: Cisco blocks automated requests, so for those sources it can only nag us that it’s been a while. Which, honestly, is also how we do most things.

Read this part

It’s a planning aid. Validate the path with the vendor’s support and the release notes for your exact build before you touch anything in production. A few honest gaps:

• Secure Firewall works by release line. The minimum build for each target lives in the release notes, not in the tool.
• Junos doesn’t cover PTX or Junos OS Evolved yet. They’re on the finder as “future”, because we’d rather tell you than pretend.
• Nexus 5000 and 6000 aren’t in. They’re end of life, and we decided they’ve earned their retirement.

Go break a path: fryguy.net/tools-upgrade-path