Re: [j-nsp] vMX and SR-IOV, VFP xml dump

[Chris]

Hi,

On 19/08/2019 6:59 pm, adamv0...@netconsultings.com wrote:

Wondering if anyone would share their xml dump from VFP -the interface
config for a working SR-IOV setup please. (not sure if vCPU related info is
needed as well, probably if cpu pinning is used)


Sure. This is with 4 x Intel X710 NIC's passed through with SR-IOV.

vmx.conf: https://pastebin.com/raw/eFrXT9au
Resulting virsh XML: https://pastebin.com/raw/zK2xnHUW
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] PCS errors with PTX box

[Clinton Work]

I have a similar issue with a PTX1000 (Junos 17.3R3) , but I'm using Juniper 
optics (QSFP-100GBASE-LR4 on PTX1000 and CFP2-100GBASE-LR4 for the PTX5000).   
All the hardware has been swapped (including the PTX1000 chassis) and the 
errors are still incrementing.   If we move the fibers from PTX1000 port 
et-0/0/25 to et-0/0/13 (spare 100G port) then the errors go away.   

--
Clinton Work

On Mon, Aug 19, 2019, at 8:21 AM, Luis Balbinot wrote:
> Hey.
> 
> Anyone here using PTX1Ks with multiple 100G LR4 links and third party optics?
> 
> We recently started deploying a few PTX1K routers in some locations
> and we are getting some weird PCS errored blocks on LR4 interfaces. We
> haven't tested with the official Juniper QSFP28 module yet, but we
> tried with two different brands. Apparently the issue only happens
> with LR4 interfaces.
> 
> We are on JunOS 17.4R2-S2.3. JTAC didn't find anything yet and our SE
> even suggested replacing the box but we get that same issue with
> multiple boxes. If we play around with the interfaces (i.e. change
> from port 25 to 67) sometimes we get rid of the errors on that link.
> 
> Thanks.
> 
> Luis
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] PFE forwarding bug - PR1380183

[Richard McGovern]

Unless you need some feature/function that is in some 18.x or 19.x, and 
everything else in 17.4 is good for you, then I would suggest using 
17.4R2-S[latest], which is S6 right now.  S2 and above contain the fix for this 
PR.

My 2 cents worth.

Rich

Richard McGovern
Sr Sales Engineer, Juniper Networks 
978-618-3342
 
I’d rather be lucky than good, as I know I am not good
I don’t make the news, I just report it
 

On 8/19/19, 11:36 AM, "Aaron Gould"  wrote:

I hit PR1380183 last week on an MX960.

 

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

=PR1380183

 

I currently run 17.4R2-S1.2 on all my MX960's.

 

The PR mentions a fix in 5 different versions of Junos.

 

Should I stick with the current train I'm in ?

 


Resolved In


Release

junos


18.4R1

x


18.4R2

x


17.4R3

x


19.1R1

x


17.4R2-S2

x

 

...17.4R2-S2 is closest to what I'm currently using.

 

- Aaron

 




___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] PFE forwarding bug - PR1380183

[Aaron Gould]

I hit PR1380183 last week on an MX960.

 

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

=PR1380183

 

I currently run 17.4R2-S1.2 on all my MX960's.

 

The PR mentions a fix in 5 different versions of Junos.

 

Should I stick with the current train I'm in ?

 


Resolved In


Release

junos


18.4R1

x


18.4R2

x


17.4R3

x


19.1R1

x


17.4R2-S2

x

 

...17.4R2-S2 is closest to what I'm currently using.

 

- Aaron

 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] PCS errors with PTX box

[Pennington, Scott]

Not saying this is or isn't your issue, but check out KB34777.   I found this 
the hard way with JTAC.  The particular article is specific to the 3K, but the 
1K may have a similar issue, and it may give you some troubleshooting leads.


From: juniper-nsp  on behalf of Luis 
Balbinot 
Sent: Monday, August 19, 2019 10:20 AM
To: jnsp list 
Subject: [j-nsp] PCS errors with PTX box

Hey.

Anyone here using PTX1Ks with multiple 100G LR4 links and third party optics?

We recently started deploying a few PTX1K routers in some locations
and we are getting some weird PCS errored blocks on LR4 interfaces. We
haven't tested with the official Juniper QSFP28 module yet, but we
tried with two different brands. Apparently the issue only happens
with LR4 interfaces.

We are on JunOS 17.4R2-S2.3. JTAC didn't find anything yet and our SE
even suggested replacing the box but we get that same issue with
multiple boxes. If we play around with the interfaces (i.e. change
from port 25 to 67) sometimes we get rid of the errors on that link.

Thanks.

Luis
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] PCS errors with PTX box

[Luis Balbinot]

Hey.

Anyone here using PTX1Ks with multiple 100G LR4 links and third party optics?

We recently started deploying a few PTX1K routers in some locations
and we are getting some weird PCS errored blocks on LR4 interfaces. We
haven't tested with the official Juniper QSFP28 module yet, but we
tried with two different brands. Apparently the issue only happens
with LR4 interfaces.

We are on JunOS 17.4R2-S2.3. JTAC didn't find anything yet and our SE
even suggested replacing the box but we get that same issue with
multiple boxes. If we play around with the interfaces (i.e. change
from port 25 to 67) sometimes we get rid of the errors on that link.

Thanks.

Luis
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Rock-solid JUNOS for QFX5100

[Karl Gerhard]

Just here to tell you that we've had an issue that sounds close to what you saw:
After a commit, a LAG would stop moving packets. Renaming the LAG (i.e. from 
ae24 to ae35) would fix the issue. Renaming it back to ae24 would trigger the 
issue again.

Happened on a device that was only used for switching, no IP addresses were 
configured apart form the management port. A reboot fixed the issue. This was 
before we used them in prod and since then we've upgraded to 17.3R3-S1 and 
never saw that issue again. What you experienced sounds scary. If this happens 
to us outside of a maintenance window we'll have to throw out all of our 
QFX5100. :/

Regards
Karl

--
*From:* Ross Halliday [mailto:ross.halli...@wtccommunications.ca]
*Sent:* Monday, August 12, 2019, 3:19 PM
*To:* juniper-nsp@puck.nether.net
*Subject:* [j-nsp] Rock-solid JUNOS for QFX5100

> 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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] vMX and SR-IOV, VFP xml dump

[adamv0025]

Hi folks,

Wondering if anyone would share their xml dump from VFP -the interface
config for a working SR-IOV setup please. (not sure if vCPU related info is
needed as well, probably if cpu pinning is used)

The juniper script is useless in my opinion as I'd like to understand the
xml settings.

adam

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] RSVP-TE broken between pre and post 16.1 code?

[adamv0025]

> From: Nathan Ward 
> Sent: Friday, August 16, 2019 11:20 AM
> 
> Weird that the refresh timer <1200 triggers it. Do you mean the refresh timer
> in the time values object is 1200 - i.e. 1.2s? JunOS default is 30,000 (30s), 
> 1200
> seems very short, or very long? Certainly it sounds like a bug, but, I’m 
> curious
> why you’d have timers like that..
> 
The refresh timer is in seconds,
The idea was to change the refresh timer from 30s to 1200s among other settings 
to match with the post 16.1 defaults, so when there's time to upgrade these 
settings would match for better interop -but in this case it totally backfired. 

adam

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp