[j-nsp] Rock-solid JUNOS for QFX5100

[Nelson, Brian]

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 juniper-nsp at puck.nether.net
>> 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 juniper-nsp at puck.nether.net
> 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
>