Yep, holding at 14.1X53 for production QFX5100 also. These were sold as east/west datacenter Layer 2 switches. If they can't figure out port init and connection, I am wondering what purpose these switches are supposed to serve.
Seeing the same connection issues in EX2300/4300 with 10Gb ports in JunOS 15/16/17. Just upgraded some flaky switches to 18.1R3-S6. Let's see if they have it right this time. Maybe when the access switches stop acting autistic, I will think about the QFX5100. Brian Nelson On 8/12/19 8:49 AM, Andrey Kostin wrote: > 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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fjuniper-nsp&data=02%7C01%7Cbrian.nelson%40utdallas.edu%7C46dc3d3102a24da6321108d71f2becf6%7C8d281d1d9c4d4bf7b16e032d15de9f6c%7C0%7C0%7C637012145848697458&sdata=JDN54e8K6xG5Fh0EfTolJWr0qsVaCs6Q1GKwuYWSi2A%3D&reserved=0 > _______________________________________________ > juniper-nsp mailing list [email protected] > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fjuniper-nsp&data=02%7C01%7Cbrian.nelson%40utdallas.edu%7C46dc3d3102a24da6321108d71f2becf6%7C8d281d1d9c4d4bf7b16e032d15de9f6c%7C0%7C0%7C637012145848697458&sdata=JDN54e8K6xG5Fh0EfTolJWr0qsVaCs6Q1GKwuYWSi2A%3D&reserved=0 > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
