Re: [j-nsp] PFE forwarding bug - PR1380183
Yes, I would say in general that staying on the same R release is safest as no new features will be introduced, and yes it is often with new feature development that bugs get created. I have found that often times affecting not the new feature, but other standard features. This is IMHO, not necessarily the opinion of Juniper as a company. That release number explanation is from 2010, and things have changed dramatically since then. Currently the numbering for XX.YR#-S# is: XX = the year Y equals the quarter (y = 1, 2, 3 or 4) R is release number. Now with each R release, new features are generally introduced. R changes are no longer SW improvements only, but a combination of SW improvements and new features for feature acceleration. This is needed with the rate of change within the industry. S is now the SW improvement only vehicle - replaced the old R, which under prior guidelines, could not include new features . Therefore S something is now like 90+% of the time the JTAC recommended version to use. My suggest is pick the XX.YR# you want, go to SR pulldown, and ALWAYS use the latest S release for that stream. I also suggest listening to your account SE, more than anyone else -__ Rich PS - X releases are a branch from the mainline, and are specific to a product family. Done generally to release a new product where XX.Y is not on time or too late to support, or for specific work for some product family stability. X streams will always eventually branch back into the mainline at some point in time. 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/20/19, 9:28 AM, "Aaron Gould" wrote: Thanks Rich, similar to the guidance from my Juniper account SE. ...also 17.4R3 is being released in September but I understand that once you jump R releases, you get into new features with potential for new bugs correct ? In other words, am I correct that the next S (service) release is the safest and least changes as possible to the existing train of code you are currently running ? (I just read this as a refresher for my understanding) https://forums.juniper.net/t5/Junos/Current-JUNOS-Release-numbers-explained/td-p/58396 -Aaron ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Kerberos authentication
Greetings all I was looking for document to validate if Juniper EX2300 supports Kerberos authentication with no luck Any ideas? Thanks! ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] PFE forwarding bug - PR1380183
Thanks Rich, similar to the guidance from my Juniper account SE. ...also 17.4R3 is being released in September but I understand that once you jump R releases, you get into new features with potential for new bugs correct ? In other words, am I correct that the next S (service) release is the safest and least changes as possible to the existing train of code you are currently running ? (I just read this as a refresher for my understanding) https://forums.juniper.net/t5/Junos/Current-JUNOS-Release-numbers-explained/td-p/58396 -Aaron ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] QFX5100 and BGP graceful-shutdown in 19.1
Hi, JunOS 19.1 brings support for the BGP graceful shutdown mechanism (RFC8326): https://tools.ietf.org/html/rfc8326 https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/graceful-shutdown-edit-protocols-bgp.html While you could always do this by hand I was happy to see it implemented in the platform because it might simplify policy handling. I tried it on QFX5100 but couldn't get it to work. While the sender part seems okay (set protocols bgp graceful-shutdown sender adds the community to all outgoing routes), the receiver part does not work. set protocols bgp graceful-shutdown receiver does nothing on my setup. I tried to specify it in every BGP group which did do nothing and I tried to explicitly set it to local-pref 0 which also does nothing. Support for the feature is advertised in the group overview: > show bgp group spines detail Group Type: External Local AS: 420011 Name: spines Index: 0 Flags: Export: [ bgp-redist-direct bgp-redist-from-upstream deny-everything ] Options: Holdtime: 0 Graceful Shutdown Receiver local-preference: 0 Total peers: 2Established: 2 172.25.1.0+179 172.25.2.0+179 Route Queue Timer: unset Route Queue: empty Table inet.0 Active prefixes: 6 Received prefixes:6 Accepted prefixes:6 Suppressed due to damping:0 Advertised prefixes: 2 But routes are unaffected: > show route 10.210.128.128/25 detail inet.0: 13 destinations, 16 routes (13 active, 0 holddown, 0 hidden) 10.210.128.128/25 (2 entries, 1 announced) *BGPPreference: 170/-101 Next hop type: Router, Next hop index: 0 Address: 0xba56a10 Next-hop reference count: 4 Source: 172.25.2.0 Next hop: 172.25.1.0 via et-0/0/48.0 Session Id: 0x0 Next hop: 172.25.2.0 via et-0/0/49.0, selected Session Id: 0x0 State: Local AS: 420011 Peer AS: 420010 Age: 19:55 Validation State: unverified Task: BGP_420010.172.25.2.0 Announcement bits (3): 0-KRT 1-BGP_RT_Background 2-BGP_RT_Background AS path: 420010 420012 I Accepted Multipath Localpref: 100 Router ID: 172.25.255.2 BGPPreference: 170/-101 Next hop type: Router, Next hop index: 1739 Address: 0xba25c90 Next-hop reference count: 4 Source: 172.25.1.0 Next hop: 172.25.1.0 via et-0/0/48.0, selected Session Id: 0x0 State: Inactive reason: Active preferred Local AS: 420011 Peer AS: 420010 Age: 10:41 Validation State: unverified Task: BGP_420010.172.25.1.0 AS path: 420010 420012 I > Communities: graceful-shutdown Accepted MultipathContrib > Localpref: 100 Router ID: 172.25.255.1 Has anyone else tested this? Regards Sebastian -- GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
