×
all 11 comments

[–]Joshua-Graham 1 point2 points  (11 children)

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.

[–]scratchfuryIt's not the network![S] 1 point2 points  (10 children)

The one that annoys us the most is not having global configuration of spanning tree.

[–]Joshua-Graham 1 point2 points  (8 children)

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

[–]scratchfuryIt's not the network![S] 1 point2 points  (7 children)

I thought of asking there but get more eyes here. I'll try 15.1R7. Thanks!

[–]killsudo 2 points3 points  (6 children)

I've been introducing 17.4R1 into production on qfx5100. So far it's been proving stable running ospf/bgp/mpls/vxlan.

[–]Cyric297 1 point2 points  (2 children)

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.

https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR1332515

It may be specific to the 5110 though.. I don't have 5100s to test on.

[–]killsudo 3 points4 points  (1 child)

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.

[–]sudoraymondshow version and haiku 0 points1 point  (0 children)

Great info... Also why are you trying to kill me?

[–]OhMyInternetPoliticsI drink and I route things 0 points1 point  (2 children)

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.

[–]shedgehog 1 point2 points  (0 children)

An old SE from juniper once said to me “friends don’t let friends run R1 releases”

[–]killsudo 0 points1 point  (0 children)

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.