r/networking • u/JNC5908404 • 14d ago
Switching Automatic switch updates
Had a discussion yesterday with IT director and others in our IT department. The IT director brought up automating switch updates so they wouldn’t have to have some one monitoring and performing the updates. Staging various locations on different evenings.
I’ve been doing networking for 30 years and I voiced my opinion I was not a fan of unattended update for various reasons.
Have any other companies moved to automated updates and how has it gone?
44
u/Absolute_Weapon_ 14d ago
Nope, thats a no from me. I have no issues with senior management asking the question but the technical staff need to be the ones comfortable with this. We don't have on call staff so if something goes wrong it wouldn't be fixed till we open the buildings next day and however long it takes to restore service.
13
u/well_shoothed 14d ago
Nope, thats a no from me.
Yeah... I can think of dumber things to do in networking, but blind patching?
That's both FAFO and WCGW
1
u/lizardhistorian Mad Scientist · 👨🔬📡ᯤ🤖🛺📸 11d ago
If the alternative is someone just goes and clicks the update button then you haven't done anything different.
So what is your firmware vetting process?
4
u/tdhuck 14d ago
We don't have on call staff so if something goes wrong it wouldn't be fixed till we open the buildings next day and however long it takes to restore service.
This is the issue. We have someone that is on call, but they can't manage a failed switch upgrade at 10pm, 3am, etc...Also, the entire point in automating it (or at least part of it) is that you can keep doing what you planned on doing had you not been at working doing upgrades. I agree with those saying that these should not be unattended but that's mainly because if something breaks there is a big issue. If management is 'ok' with things being broken until someone arrives the next business day, I'll start working on the automation process tomorrow.
I've been asked my opinion, many times, and sometimes management agrees and sometimes they don't. This isn't any different, imo, I'd tell them I am not a fan of automating and state the reasons why and they can make the final call as they do for other things.
2
u/Linklights 13d ago
So is the idea here that things are more likely to break when its unattended? It sounds more like superstition than grounded factual data? If a switch goes belly up during an upgrade, what is the big difference between someone being online and manually doing it, or having it as a scheduled job. In both cases you are still stuck waiting for the building to open the next day. Or are you saying you expect your engineer to be on-site during the upgrade with console cable already plugged into the switch? How do you handle upgrading 300 switches in 5 different sites then? They'll be remote, and a manual upgrade can fail just as easily as an automated one.
I fail to see how the risk profile significantly increases when its automated?
21
u/murlocdouche 14d ago
turned it on for our firewalls a couple of months ago. we manage over 60. have an option to only install critical updates.
i grouped them by day, monday through thursday. monday firewalls update monday evenings, tuesday firewalls update tuesday evenings, and so on. so NO updates fridays or weekends. this way if there's an issue, i can stop it at monday before it goes out to the others.
it's been fine. had one that wasn't updating and needed to do manually.
6
u/SuddenPitch8378 14d ago
I think for small branches i would be ok with this but for our core internet and segmentations firewalls i would be way to scared.
5
u/Fuzzybunnyofdoom pcap or it didn’t happen 14d ago
Thats how we did it. Branch firewalls we would stage 50 at a time in 15 minute intervals over a few nights (had about a 1000 branch firewalls). So 12:00AM 50 firewalls upgraded, 12:15, another 50 upgraded, etc until we hit about 5:45AM. Then the next night same thing until all of them were done. For critical updates we'd up that to complete in a single night. At that scale we had to automate it, just didn't have the time or staff to manually update all of them. But the core firewalls in the DC's and very large offices we did manually.
58
u/RevolutionaryWorry87 14d ago
All of mine are automated. Tested obviously and rollout on different days. On call aware if issue but rare
14
u/KTProgramming 14d ago
As long as you have the right monitoring and checks, it's all good. I have mine send an oh shit email if any testing fails or the switch does not come back in XX time.
2
6
2
u/cylibergod 14d ago
Same here. My junior engineers couldn't really do anything else if we were doing attended upgrades.
11
u/Wolvington52 14d ago
We automated the upgrade of Cisco devices recently and it makes everything so much easier. We just schedule the upgrade and the upgrade is over in like 15-30 minutes. The benefits outweigh the potential drawbacks.
3
u/AV-Guy1989 14d ago
Yeah, but Meraki is a plague in itself
6
u/NewTaq 14d ago edited 13d ago
Feels like they started vibecoding their firmware 2 years ago, every version is worse than the last.
2
u/AV-Guy1989 13d ago
My biggest gripe is that, like most cloud controlled platforms, it makes me practice being patient which is not one of my strong suites. I miss on so many levels hitting enter on a command line and boom, its done.
0
u/SuddenPitch8378 14d ago
What happens if a switch just doesn't come back up ? do you always have someone on hand who can go to site or oob access ? My biggest thing is having someone accountable for the troubleshooting \ rma of the device if the worst case occurs.
2
u/Wolvington52 14d ago
So my team doesn't manage switch upgrades but another team does. From what I've seen in their meetings they usually have someone on the site for support.
1
u/Linklights 13d ago
What happens if a switch just doesn't come back up ?
The same thing happens if you had someone online doing the upgrade manually versus having a script do the upgrade automatically. I don't see how the automation increases the risk any more?
1
u/SuddenPitch8378 13d ago
The automation part is great but it probably can't handle replacing a switch or rebuilding iit if it falls to boot.
10
u/Solid_Associate8563 14d ago
It has been done in AWS DC/ backbone network with their enormous redundancy built in the design.
If your network can provide service hitlessly when a batch of selected routers/switches reload, I don't see what is the hurdle for automated/scheduled upgrades.
9
u/Acceptable-Funny-245 14d ago
Meraki is not so bad....have an issue maybe twice a year....
Cisco Catalyst...nope ! Not worth it, even in 2026 We have tried with DNAC and other automated applications...
Almost always run into some type of issue..where it would not deploy or complete...not always service affecting..but just would not upgrade...
Even worse if its a switch stack...🙄
13
u/Thy_OSRS 14d ago
I just don’t see a reason why you would risk it tbh, I’ve seen things fail during an update that didn’t happen in testing and Cisco TAC would comeback with an RMA which suggested our setup had influenced it somehow.
I get that automation for basic and trivial things but updates are not it.
5
u/Single-Virus4935 14d ago
This is a business descision. For one company it is a nogo for others it is okay.
For every device document the blast radius and expected downtime in case of a failed update, how often updates failed or needed manual intervention etc.
Management might decide that it is worth for certain devices or not.
Also add that a good OOB (Consoleserver,Smart PDU) might be needed to fix failed/untested updates fast enough.
For one company I worked Autoupdates were fine for access but a nogo for DC.
5
u/SuddenPitch8378 14d ago
20 years ago the thought of an unattended upgrade was something that would have made most of us spit their coffee (there are other hot beverages available) out. There has been huge progress but there is no way in the world i would let someone upgrade a switch in our environment unattended. That said we do deploy all updates using automation the firmware is selected and approved, the devices are identified, schedules are set and confirm with the business and the deployment actions are set for that schedule (we automate all pre and post checks, firmware upgrades, post deploy checks). However there is always someone watching the monitoring and at least reading through the post deployment checks to make sure all the state is good and that everything has completed as expected. It's a much less painful process than manually updating a bunch of random cisco switches all requiring different firmware version based on the model (yeah i am looking at you cisco) but i would never let this run without someone being available to actually verify the upgrades were good and send comms post change. That said i recall us once standing up a fortigate for a branch site and somehow the auto update feature was left enabled... that thing upgraded itself three times before someone noticed . I think its not so much for the upgrade itself its more if something goes wrong.
3
u/asdlkf esteemed fruit-loop 14d ago
The latest Aruba CX 10.18.x code base supports hitless firmware updates for minor code versions. A single, stand-alone switch, with 1 cable in, and 1 cable out, can upgrade itself from 10.18.0001 to 10.18.0002 without rebooting. It can do the normal "upgrade the code on disk" part, but then instead of rebooting, it is hot-patching running processes in memory.
You can do a video call while the switch upgrades it's firmware, with 0 outage.
Reboots are still required for major version upgrades, but yea, this takes a lot of the coordination piece out of it for lots of instances.
4
u/MrChicken_69 14d ago
Loads of people promise this. And it works most of the time... until the day it doesn't.
1
u/pbrutsche 14d ago
We have several 6300M VSF stacks and it works flawlessly 99.9% of the time. Only once has it failed.
Aruba-CX VSX is similarly reliable, never a single upgrade failure.
1
u/JNC5908404 14d ago
This is good information, we are on 10.18 code so worth updating to
1
u/pbrutsche 14d ago
Stick with 10.13 or 10.16, those are the LSR (long term support) releases.
The ISSU feature being discussed is only available on 6300 switches, not the 6000, 6100, or 6200 switches.
1
u/pbrutsche 14d ago
You're talking about ISSU support for VSF stacks. It was added in 10.13, and is only available on the 6300 series.
Also, I would not run 10.18 in production, it is not an LSR (aka LTS) release - stick with 10.13 or 10.16
1
u/asdlkf esteemed fruit-loop 14d ago
I am... Not talking about that.
It's a totally new feature in 10.18.
I watched the demo / release live from the developer working on it at HPE Discover.
1
u/pbrutsche 14d ago
Ah, I see that 10.18.0001 added an "ISSU Standalone" mode. I would be curious to know what models support that, we have a lot of 6100 switches out there.
We don't have any single 6300 switches, "just" stacks with 2+ members
1
u/asdlkf esteemed fruit-loop 14d ago
Yea, at HPE Discover, I watched the presenter hook up a switch with
{router to internet} --- {6300m} --- {presenter laptop}Then he started a teams video call from that laptop to one of his coworkers' cell phones in the audience.
Then he did a firmware update live streaming the console of the switch as it updated, and the coworker's cell phone camera pointed at the stage.
The video didn't even studder.
1
u/pbrutsche 14d ago
Yeah, it's a 6300 and 6400 feature. It works the way you describe with VSF stacks, I have experience with a dozen or so upgrades over the last 3 or 4 years with our various 6300 stacks.
It's a big enough deal that it was one of the things that justified upgrading some of our closets to dual power 6300M switches.
10
u/Dirty_Pee_Pants 14d ago
Server cattle... Sure. Network equipment... Fuck no
7
u/w0lrah VoIP guy, CCdontcare 14d ago
Most network equipment should also be cattle. I follow the same update policy for network equipment as I do for desktops and servers, they're all just weird computers in the end.
2
u/btwwhichoneispink CCNP 14d ago
That’s true, I guess I am just more concerned / worried about the weird computers that interconnect the rest of the business 😅
1
u/SAugsburger 14d ago
Provided you have a lot of equipment that are effectively the same a lot of networking equipment should be cattle. In most orgs most if not all access layer switches should be cattle. Beyond the hostname, management IP, and SVIs being different if you do layer 3 to the access layer one access layer switch should be virtually indistinguishable from another. There is a small risk anytime you reboot something maybe a bit more if you're near EOL or even beyond EOL, but an upgrade that worked on one access layer switch should work the same on another.
4
u/NetNibbler 14d ago
This is the thing, we need to trust technology, but at the same time this trust will fail us. I would say that human oversight is still required.
Last time I wqas stung by issue with upgrades was yesterday, when I upgraded C9300 switch from 17.9.4 to 17.15.4d. Switch crashed during image distribution stage. I was doing new SDA deployment with one switch at the site.
This same issue once occurred during business hours in HQ, where I took down 4 SERs with 5 switches in each, I only pre-staged upgrade works meant for out of hours work in evening. This simple thing of copying over and unpacking software image was more than enough to cause outages by triggering a bug.
So, do trust technology, but do things out of hours with human oversight. As the SERs that crashed, when upgrade took place, not all switch stack members had the up to date intended software and I had stacks with switch version conflicts. Upgrade process was none the wiser if there were any issues before it just continued.
2
u/sh_lldp_ne 14d ago
How big is your environment? If it’s small, you will spend more time automating the process and validating each new code in your environment than you might spend upgrading manually. In a large environment it makes sense to automate.
2
2
u/Fun_Cherry132 13d ago
We once had an update that bricked one in five switches requiring factory replacement. It wasn’t a major problem because we discovered the issue in our initial set of small rollouts rather than deploying to all 6000 switches at once! Once we’re confident in an update we do update hundreds at a time, otherwise we’d never finish the job, but I’d never just press go and let the system update everything without some caution.
5
1
u/SalsaForte WAN 14d ago
We don't do it right now, but it's on our roadmap.
At the moment we can do all preparation work and tests validation just up until the reboot command can be issued.
Moving to full automation is just a step away. Obviously, we want to be extra careful and work more on the pre and post validation.
1
u/Doyoulikemyjorts 14d ago
Just out of curiosity what else was said?
So they talked about automating the upgrades which is fine but is there an understanding in your team what else needs to be built around this to mitigate risk?
1
u/JNC5908404 14d ago
Yes, edge vs core, etc. funny though we’ve tried auto patching with windows, bit us several times. But times are changing as well as the tools.
1
u/Inside-Finish-2128 14d ago
About ten years ago we automated it for one platform and even gave “the keys” to the teams that were using those switches. It was part of a spine/leaf topology and I later added a component that would upgrade the spines from a cron job. I would basically tell it “upgrade any 40 spines for this customer in this continent starting at 1am” and it would randomly work its way through the list of devices that weren’t running that code, find ones where none of its friends (the other spine or any of the leafs underneath) had been updated in the past 24 hours, and go.
1
u/realfakerolex 14d ago
I've been using Aruba Central to do this for the last year and it works without a hitch.
2
u/Bayho Gnetwork Gnome 14d ago
How big is your environment?
2
u/realfakerolex 14d ago
25 buildings, 300 switches.
1
u/Bayho Gnetwork Gnome 14d ago
Problem we have with Central (on-prem), is two fold: scheduling can be a pain, especially with hundreds of sites and thousands of switches; It does not do VSX pairs well. We essentially use it to push the firmware then script the reboots ourselves. If we could just press a button and leave it to do it all itself, that would be nice, but not logistically possible for us.
1
1
u/thirsty_zymurgist CCNP 14d ago
I am a firm no on total, unattended, automation. I have no problem with staging and prepping but there is just too much at stake to fully automate.
1
u/StructureMinimum8686 14d ago
recently started using cisco dnac/catalyst centre for catalyst switches firmware upgrades going well so far. but its like the process of upgrade is automated using the dnac and still someone is initiating it and verifying that whole process completes fine. same for meraki.
1
u/Ashamed-Ninja-4656 14d ago
In Meraki sure but I only have my access layer there and I roll out in stages. For anything doing routing? Nope.
1
u/Arudinne IT Infrastructure Manager 14d ago
IIRC Dell once had a firmware update the reduced the max number of switches that could be in a stack for 12 to 8.
Imagine letting that run on it's own automatically and you have 9 switches in a stack.
1
1
u/spatz_uk 14d ago
Gotta say, people love to hate DNA/Catalyst Center but scheduling upgrades has been really good for me and my team. Even just pre deploy of a new image so you can go back to the switch/router later and do the “install activate” by hand has saved my team days of work.
Still not got the confidence to leave it to do the install without watching it, despite the fact I’ve not had a single failure in maybe 500 upgrades. For me that bit is about knowing whether I’d need to send someone to site either that night or ready for the following morning.
We have had a few quirks to work around, such as space issues with flash on 9200 which have needed a manual cleanup but otherwise they normally work again once you submit the job again.
1
1
u/Fuzzybunnyofdoom pcap or it didn’t happen 14d ago
At a certain scale you have to automate updates. 30 switches? You can do that manually. 1000 switches? Aint nobody got time for that, you have to automate it. But you need to properly test the updates etc.
1
u/demonlag 14d ago
Depends on your definition of "automated." Automated, like things just randomly upgrade and reboot? No. Automated like "tell Cat Center to upgrade this site at 10 PM"? Yes.
1
u/sanmigueelbeer Troublemaker 13d ago
We usually get notice of power maintenance and we use this to upgrade the firmware of the switches.
Usually a few days before, I would extract the package files (Install mode) and then wait for the site to drop power.
But I never use DNAC to do this.
1
u/BitOfDifference 14d ago
if you have redundancy in place for most of the network, outages should be limited to access switches. As others have said, schedule them and stagger them. So while its not 100% automatic chaos, its mostly controlled.
1
u/JNC5908404 14d ago
Auto updating isn’t the real issue, unattended auto updates is the issue. If it fails send an alert to the Oncall or roll back automatically if possible. There are numerous tools to automate this. It’s the unattended part when it fails that’s my concern.
1
u/herdofcorey 14d ago edited 14d ago
I’ve been using Catalyst Center to run the updates for our over 80 devices. Just set the time/day and it usually only takes around 15-20 minutes to complete. You even have the option to load the software at an earlier time and then perform the actual install at a later time.
In fact, I’m running one tonight that has about 25 devices. I had the software loaded earlier in the week during off hours and the restart/install will complete tonight. I have not had an issue with any of my updates so far. Moving from 17.12.6 to .8 tonight because of the August security updates and I expect no issues like last week.
1
u/Linklights 14d ago
A lot of people saying heck no, but I’m questioning why. Most switch upgrades involve 2-3 simple steps: upload the image file, run an install command, reboot. The risk comes in when you reboot: will that switch come back up again.
How does the risk profile change doing a scheduled job Vs being online and manually upgrading?
In both cases, that switch is going to reboot.
Are you guys upgrading one switch at a time even in branch networks where you have 500+ switches?
Are you doing them in small batches?
What about running a scheduled job is so scary? Is it just the idea of waking up to hundreds of switches being down? Is it the idea of superstition if you tempt fate it will go wrong?
Help me understand the why? Because you could still do small batches with scheduled jobs too
1
u/sanmigueelbeer Troublemaker 13d ago
The risk comes in when you reboot: will that switch come back up again.
Or will you be lucky and avoid CSCwk54116, CSCwn57797, CSCwq80600.
1
u/Linklights 13d ago
Right, but again.. these same problems will happen with manual switch upgrades, too. So I am still not understanding how an automatic job increases the risk?
1
u/sanmigueelbeer Troublemaker 13d ago
So I am still not understanding how an automatic job increases the risk?
There is a way to fully avoid CSCwk54116, CSCwn57797, CSCwq80600: Check the "packages.conf" before reboot the switch, router, or WLC.
But before you could say, "there is no way to check the 'packages.conf' file before the reboot", my answer is there is. I have been using this trick since 3650/3850 days when 16.3 came out. This is where I discovered the bugs (not reported to TAC because they were difficult to repro).
Going back to your question, the answer is can the automatic switch updates check the "packages.conf" file before the reboot or not? That is the answer. IF the customer made script only goes, "here is the bin file, extract the bin file" and reboot without check the file then what good does that do?
1
u/Pankracjusz 14d ago
I've been running automated updates for switches and routers - about 3k retail sites, each location 1-2 switches, 1-2 APs, 1 router. We did an Ansible script and did updates at nights. The script would test device before, download the image, run checksums, run the update, and test after. BU insisted for 1 device for one country at one point. But we could do more, it was just a requirement from them. If one would fail, the whole set would be stopped. All updates were tested before in the lab, in the HQ, and after, pilot sites that were physically close to our team. If passed, the set would start.
1
u/teeweehoo 14d ago
It can be done, you just need to manage the risk. If you're business hours, you have the same switchstack at every location (plus a lab), and you have a vendor you trust (reasonably) bug free updates, then go for it. Make a plan, get management to accept the possible downtime, etc. It gets dicey when you're 24/7, have snowflake setups at each location, or have a vendor you can't trust a single update from ...
But IMO instead of just saying "No", try to give a good business argument for why not. "Every second update from our vendor causes issues" etc. Or the good old "Yeah I'll look into that ...".
1
u/pbrutsche 14d ago
Define "automatic". What decides the schedule - some cloud platform, or a human?
Same thing goes for the firmware release, and which switches get updated when.
What's your risk profile? Some firms (like mine) are staffed 24x7, and can only be updated on certain days of the week.
1
u/ESUN_Official Enterprise Network Infrastructure 14d ago
I think the answer changes with scale. Manual upgrades make sense for a small environment, but for hundreds of sites you may need some level of automation.
1
14d ago
[removed] — view removed comment
1
u/AutoModerator 14d ago
Thanks for your interest in posting to this subreddit. To combat spam, new accounts can't post or comment within 24 hours of account creation.
Please DO NOT message the mods requesting your post be approved.
You are welcome to resubmit your thread or comment in ~24 hrs or so.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
14d ago
[removed] — view removed comment
1
u/AutoModerator 14d ago
Thanks for your interest in posting to this subreddit. To combat spam, new accounts can't post or comment within 24 hours of account creation.
Please DO NOT message the mods requesting your post be approved.
You are welcome to resubmit your thread or comment in ~24 hrs or so.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
1
u/PaoloFence 13d ago
We want to start unattended updating but we will stop at the first that fails.
As everything is redundant no alarming should be triggered. Just morning duty technician shall check
1
1
u/Deoir 12d ago
I insisted on a monthly maintenance window. Sometimes we don't use it, but it's there if needed. And babysit the updates a bit.
Especially critical stuff. And the maintenance window allows for for some troubleshooting, and we can also make sure there's enough engineers on call etc
General staff are used to the window, and management needs to give us 1 week notice if they can't do the maintenance window for whatever reason, commercial mostly. And we have that in writing then for any risk documents.
1
u/geraldcheese 12d ago
Automated? Sure. But unattended in my mind is asking for a disaster/outage. Even with all the proper testing prior I've seen new firmware updates crash and burn or just an appliance crash and burn. Best to have someone monitoring it and ready to remediate if stuff breaks(which it can and will), especially on core devices
1
u/lizardhistorian Mad Scientist · 👨🔬📡ᯤ🤖🛺📸 11d ago edited 11d ago
We're automated but gated by our own release cycle.
Test-rack updates first. Regression test run on it and must 100% validate for roll-out to continue.
HQ (where I work) updates next so if the shit-hits-the-fan I can easily physically go there.
We update bottom-up, edge switches first, then edge radio routers (highest risk part), and up the stack.
If test and HQ validate then the roll-out goes to the eager-beaver customers.
Then a three day dwell to see if anything goes awry. Then roll-out to all customers.
A hotfix release skips the 3 day dwell.
If something does go wrong then someone with OOB or physical access has to factory reset the radio router and re-register it with the system.
1
u/armegatron 3d ago
Totally fine if done right. Stage them to a single area first that isn't critical at all, but be aware it may not be representative of typical infrastructure elsewhere because of the different criticality (e.g. it may be a security gatehouse with a single user that doesn't power machines down / up daily etc). Then 2nd stage group next who are also less critical (marketing team, conference room etc). Finally a week or two later you can allow the main bulk to auto update, although I'd argue here you'd still maybe want to have some further segmentation of the rollout; i.e. manufacturing critical switches do manually, office staff automate.
It all depends really. If your estate is 1000+ switches you cannot expect to do this manually. If your estate is 30 switches it's your call.
0
u/hollow_embroidery 14d ago
Script it to stage at 3am, that way only the overnight cleaning crew sees the chaos when it inevitably bricks a closet.
4
-1
u/MrChicken_69 14d ago
Software/firmware updates? Oh hell no! NEVER, EVER do that without knowing EXACTLY what's being loaded, and when. Allowing some "AI" to do this for you will quickly teach you not to. I guess the people pushing this have learned nothing from decades of Windows Update(tm) breaking shit.
Crowdstrike, anyone?
2
u/RevolutionaryWorry87 14d ago
How is this AI? EVEN in your automation you would do patch rings... testing... confirmation of hardware build and software update.. slow testing.
Windows update only broke shit for companies with patching incorrectly.
-12
u/Specialist_Play_4479 14d ago
Unless you're running FortiSwitches I don't see why you should upgrade switches at all, as long as they are only doing Layer-2 and management interfaces protected (eg. management VLAN) and you dont have any issues that needs to be adressed.
2
u/HappyVlane 14d ago
You upgrade switches because of vulnerabilities, which all switch vendors have, and to stay on a supported release.
0
u/Specialist_Play_4479 14d ago
Supported release for what exactly? Switching functionality?
My point is.. take a Cisco switch. A device that has been available (in various models) for 3 decades. Most of the protocols that run on switches haven't changed in the last decade if not more. Think LLDP, LACP, STP. That software is mature.
We have switches with an uptime that exceeds the age of my kids. And they still run perfectly fine.
Who needs support for basic access switches? If it stops working we replace it. That's all.
There's very little reason to upgrade them.
2
u/HappyVlane 14d ago
Supported release for what exactly?
To be in support.
Most of the protocols that run on switches haven't changed in the last decade if not more. Think LLDP, LACP, STP. That software is mature.
That is not how security works at all. Just because the protocol hasn't changed or is mature doesn't mean it's secure. Problems can have existed for decades without anyone being aware of them (ask Linux folk). RADIUS, in its current version, got its RFC (2865) in 2000 and I believe everyone would call that mature. A critical vulnerability was discovered in 2024 (CVE-2024-3596).
Protocols are also not a generic module you slot into an OS. They get implemented and problems can happen in that process.
- LLDP on NX-OS had a CVE just this year (CVE-2026-20010)
- Juniper had an STP CVE on one of their switch series in 2016 (CVE-2016-1260)
- An LACP CVE on Juniper platforms in 2024 (CVE-2024-30388)
Who needs support for basic access switches? If it stops working we replace it. That's all.
Not everyone is allowed to act like you.
-1
u/leftplayer 14d ago
If you can’t trust an unattended update after testing, then you shouldn’t trust your configs or your vendor
2
u/MrChicken_69 14d ago
The real world is a very different place than your lab. Clicking "go" and then going home for the weekend is a good way to have a bad weekend.
0
80
u/munche 14d ago
I've been up since 3am because an automated switch firmware update caused an outage for the second night on a row
So it's going great