Can anyone recommend QFX5100 code above 14 that is stable with virtual chassis? It would be nice to have a version of Junos that matches all our other gear, but Juniper is still recommending 14.
A lot of times any code stability concerns around VC have to do with upgrades (NSR, GRES, etc) working without an issue. What features are you lacking right now that you'd like to pick up in later releases? Just asking because then you go with whatever code chain has those features, and go with the latest GA build of that code chain. Unless it's brand spanking new, like 18.1R1, in the which case you have to know you are signing up to potential issues and the new features are absolute must haves and trump stability concerns.
The one that annoys us the most is not having global configuration of spanning tree.
Yeah, Junos 14.1X53-D46 is the recommended stable release for the QFX5100, but your right, you don't get global STP config options until 15.1. If you are determined to get that feature, go with 15.1R7. It was just released last week. All of the other code trains that are newer than 15.1 (16, 17, or 18) don't have as recent updates, or they are frankly not mature enough for most situations.
Edit - FYI, for Juniper specific questions, you'll also have more luck hitting up r/Juniper
I thought of asking there but get more eyes here. I'll try 15.1R7. Thanks!
I've been introducing 17.4R1 into production on qfx5100. So far it's been proving stable running ospf/bgp/mpls/vxlan.
Be careful here, I have a qfx5110 pair in a VC, running 17.4r3 I believe. There is a bug in that firmware that results in the virtual chassis members being unable to communicate if either or both members are rebooted. Fix isn't due until August, but it is fixed in 18.1r1.
It may be specific to the 5110 though.. I don't have 5100s to test on.
I run evpn to specifically avoid VC but keep my lacp bundles spread across multiple leaf switches. With 17.4 evpn got a crucial enhancement that ties the lacp state to bgp to prevent blackholes in overlays when bgp isnt running preventing the local mac table from populating.
So far since 2015 I'm still happy with the choice.
Great info... Also why are you trying to kill me?
An R1 release? Are you insane? I would NOT ever put a R1 release on any network unless there's an absolutely needed feature in that release.
An old SE from juniper once said to me “friends don’t let friends run R1 releases”
I would normally agree very much so on Pre 15.x code. But the code trains seemed to have changed and if your watching the PR's you'll notice that ALOT of bugs are present in all code trains like 18.1R1 back to 14.1x53DXX. Now not all bugs and some versions end up with an odd quirk but it seems like the code trains are more similar then different. Especially with the jump to FreeBSD10 and the new junos bsd kernel.
Basically, you need to do your homework and lab test the hell out of any release you pick against your feature requirements regardless of its magic version number.
Routers, switches and firewalls. Network blogs, news and network management articles. Cisco, Juniper, Brocade and more all welcome.