[j-nsp] Rock-solid JUNOS for QFX5100

[Andrey Kostin]

Hi Ross,

We are on 14.1X53 for our prod QFX5100. Don't do BGP, VRRP and PIM on 
them but other features are similar to yours (tried PIM once in a while 
but it behaved weird and decided just don't do it). The only problem we 
saw with them is few third-party QSFP issues, but resolved them by 
manipulating auto-negotiation iirc.
I'm currently looking to 18.2R3 as potential candidate for next step and 
testing it on QFX5110 atm, according to release notes it has a bunch of 
fixes for bugs that were discovered in 17.x releases. Also 17.4R3 is 
going to be released in August, waiting for it for subscriber-management 
routers but it will have recent fixes for QFXs as well. In your case 
though it'll be interesting to know JTAC findings. If it's a new bug 
then it may take some time until it will be resolved.
I'm also very suspicious when S-releases are shown as "recommended". I 
may be mistaken, but in my understanding S-releases don't undergo full 
testing routine and verified only for implemented bugfixes.
Please share you investigation results with JTAC.

Kind regards,
Andrey Kostin


Ross Halliday писал 2019-08-12 09:19:
> Dear List,
> 
> I'm curious if anybody can recommend a JUNOS release for QFX5100 that
> is seriously stable. Right now we're on the previously-recommended
> version 17.3R3-S1.5. Everything's been fine in testing, and suddenly
> out of the blue there will be weird issues when I make a change. I
> suspect maybe they are related to VSTP or LAG, or both.
> 
> 1. Add a VLAN to a trunk port, all the access ports on that VLAN
> completely stopped moving packets. Disable/delete disable all of the
> broken interfaces restored function. This happened during the day. I
> opened a JTAC ticket and they'd never heard of an issue like this, of
> course we couldn't reproduce it. I no longer recall with confidence,
> but I think the trunk port may have been a one-member LAG (replacement
> of a downstream switch).
> 
> 2. New trunk port (a two-port LACP LAG) not sending VSTP BPDUs for
> some VLANs. I'm not sure if it was coincidence or always broken as I
> had recently began feeding new VSTP BPDUs (thus the root bridge
> changed) before I even looked at this. Other trunk ports did not
> exhibit the same issue. Completely deleted the LAG and rolled back to
> fix. This was on a fresh turnup and luckily wasn't in a topology that
> could form a loop.
> 
> Features I'm using include:
> 
> - BGP
> - OSPF
> - PIM
> - VSTP
> - LACP
> - VRRP
> - IGMPv2 and v3
> - Routing-instance
> - CoS for multicast
> - CoS for unicast
> - CoS classification by ingress filter
> - IPv4-only
> - ~7k routes in FIB (total of all tables)
> - ~1k multicast groups
> 
> 
> There are no automation features, no MPLS, no MC-LAG, no EVPN, VXLAN,
> etc. These switches are L3 boxes that hand off IP to an MX core.
> Management is in the default instance/table, everything else is in a
> routing instance.
> 
> These boxes have us scared to touch them outside of a window as
> seemingly basic changes risk blowing the whole thing up. Is this a
> case where an ancient version might be a better choice or is this
> release a lemon? I recall that JTAC used to recommend two releases,
> one being for if you didn't require "new features". I find myself
> stuck between the adages of "If it ain't broke, don't fix it" and
> "Software doesn't age like wine". Given how poorly multicast seems to
> be understood by JTAC I'm very hesitant to upgrade to significantly
> newer releases.
> 
> If anybody can give advice or suggestions I would appreciate it 
> immensely!
> 
> Thanks
> Ross
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp