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 [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
