Re: [j-nsp] IPv6 firewall policy for MX
It's a good start but there are many issues with it. I think you need to take some time to understand IPv6 before implementing. The book examples don't restrict RS/RA to link local, are too open on things like BGP and traceroute. Trio hardware also has payload-protocol available in addition to next-header for matching. The IETF opsec-v6 draft is a useful resource to begin with https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ On Fri, 28 Jun 2019, 20:28 Aaron Gould, wrote: > 2nd edition page 332 "IPv6 RE Protection Filter" > > -Aaron > > > ___ > 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] Link establishment issues with 1Gbps SX/LX SFPs on QFX5110
For anyone interested in this, JTAC released to us 3.5R1-S4.1 for the satellite
devices (I don't believe this will be generally available until tomorrow). This
addresses the issue and confirms that there were 2 or 3 different PRs relating
to the Broadcom chipset being incorrectly programmed by Junos.
Some output, testing with a variety of 1Gbps optics (coded SX, LX, uncoded BX,
LX and SX).
> show chassis hardware satellite
Hardware inventory:
Item Version Part number Serial number Description
FPC 100 REV 27 650-061152 WS37183X QFX5110-48S-4C
PIC 0 REV 27 650-061152 WS37183X 48x10G-4x100G
Xcvr 0 850nm740-011782 F--X SFP-SX
Xcvr 2 1310nm 740-011783 F--X SFP-LX10
Xcvr 4NON-JNPR VS51208X SFP-1000BASE-BX10-D
Xcvr 6NON-JNPR VS60930X SFP-LX10
Xcvr 8NON-JNPR VS50930X SFP-SX
> show interfaces ge-100/0/[02468] terse
Interface Admin Link ProtoLocal Remote
ge-100/0/0 upup
ge-100/0/2 upup
ge-100/0/4 upup
ge-100/0/6 upup
ge-100/0/8 upup
> show configuration interfaces
ge-100/0/0 {
unit 0;
}
ge-100/0/2 {
unit 0;
}
ge-100/0/4 {
unit 0;
}
ge-100/0/6 {
unit 0;
}
ge-100/0/8 {
unit 0;
}
# bcmshell ps 1,3,5,7,9
HW (unit 0)
ena/speed/ link autoSTP lrn inter
max loop
port linkduplex scan neg? state pause discrd ops face
frame back
ge0( 1) up 1G FD HW Yes Forward NoneF GMII
1518
ge1( 3) up 1G FD HW Yes Forward NoneF GMII
1518
ge2( 5) up 1G FD HW Yes Forward NoneF GMII
1518
ge3( 7) up 1G FD HW Yes Forward NoneF GMII
1518
ge4( 9) up 1G FD HW Yes Forward NoneF GMII
1518
We note that now changing the auto-negotiate state in Junos correctly updates
the underlying chipset and link negotiation works correctly. Interface is shown
as GMII which we understand to be correct also.
All-in, pretty terrible that - as far as we can tell - 1Gbps ports have *never
worked* on QFX5110 properly in all the four basic combinations (i.e. SX and LX
at both auto- and no-auto negotiation) until this release. Quite how Juniper
have been shipping the hardware for so long in that state is a mystery to me.
Tim
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IPv6 firewall policy for MX
2nd edition page 332 "IPv6 RE Protection Filter" -Aaron ___ 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?
Adam- Have you accounted for this behavioral change? https://kb.juniper.net/InfoCenter/index?page=content&id=KB32883&pmv=print&actp=LIST&searchid=&type=currentpaging -Michael > -Original Message- > From: juniper-nsp On Behalf Of > adamv0...@netconsultings.com > Sent: Friday, June 28, 2019 9:16 AM > To: juniper-nsp@puck.nether.net > Subject: [j-nsp] RSVP-TE broken between pre and post 16.1 code? > > Hi gents, > > Just wondering if anyone experienced RSVP-TE incompatibility issues when > moving from pre 16.1 code to post 16.1 code. > Didn't get much out of Juniper folks thus far so I figured I'll ask here as > well. > > The problem we're facing is that in case 17 code is LSP head-end and 15 code > is tail-end works, but in the opposite direction 17/15-to-17 (basically > cases where 17 is the LSP tail-end) the LSP signalling fails. > Trace reveals that the 17 gets the PATH message for bunch of LSPs, accepts > it (yes reduction and acks are used), creates the session, then deletes it > right away for some reason. > Our testing suggests there are two workarounds for this: > You might be aware that in 16.1 among other RSVP-TE changes the default > refresh-time (governing generation of successive refresh messages > Path/Resv) > changed to 1200s -so no what you think making it 1200 on 15 side wont do, it > has to be less (e.q. 1999s). > If you want to keep refresh time at 1200 or higher then another option > strangely enough is to disable CSPF on the affected LSPs (didn't know that > SPF/CSPF changes contents of the PATH msg that in one case 17 code is cool > with PATH msg in other case not). > > Would appreciate any pointers. > > > adam > > > ___ > 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] RSVP-TE broken between pre and post 16.1 code?
I have MXs and ACXs all running RSVP, ranging in versions from 13 to 18. I haven't had any issues. What platform are you using? On Fri, Jun 28, 2019 at 7:15 AM wrote: > > Hi gents, > > Just wondering if anyone experienced RSVP-TE incompatibility issues when > moving from pre 16.1 code to post 16.1 code. > Didn't get much out of Juniper folks thus far so I figured I'll ask here as > well. > > The problem we're facing is that in case 17 code is LSP head-end and 15 code > is tail-end works, but in the opposite direction 17/15-to-17 (basically > cases where 17 is the LSP tail-end) the LSP signalling fails. > Trace reveals that the 17 gets the PATH message for bunch of LSPs, accepts > it (yes reduction and acks are used), creates the session, then deletes it > right away for some reason. > Our testing suggests there are two workarounds for this: > You might be aware that in 16.1 among other RSVP-TE changes the default > refresh-time (governing generation of successive refresh messages Path/Resv) > changed to 1200s -so no what you think making it 1200 on 15 side wont do, it > has to be less (e.q. 1999s). > If you want to keep refresh time at 1200 or higher then another option > strangely enough is to disable CSPF on the affected LSPs (didn't know that > SPF/CSPF changes contents of the PATH msg that in one case 17 code is cool > with PATH msg in other case not). > > Would appreciate any pointers. > > > adam > > > ___ > 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] IPv6 firewall policy for MX
Hi, > Is there a good online resource for IPv6 firewall policy/hardening for MX > series routers? I would start with the IPv6 filter example starting on page 336 of Juniper MX Series, 2nd Edition (ISBN: 978-1-4919-3272-8). There are eBook versions available, and o'Reilly Safari gives you online access. See https://www.juniper.net/us/en/training/jnbooks/oreilly-juniper-library/mx-series/. If you have the 1st edition it should be around page 260. Cheers, Sander signature.asc Description: Message signed with OpenPGP ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] IPv6 firewall policy for MX
Is there a good online resource for IPv6 firewall policy/hardening for MX series routers? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] RSVP-TE broken between pre and post 16.1 code?
Hi gents, Just wondering if anyone experienced RSVP-TE incompatibility issues when moving from pre 16.1 code to post 16.1 code. Didn't get much out of Juniper folks thus far so I figured I'll ask here as well. The problem we're facing is that in case 17 code is LSP head-end and 15 code is tail-end works, but in the opposite direction 17/15-to-17 (basically cases where 17 is the LSP tail-end) the LSP signalling fails. Trace reveals that the 17 gets the PATH message for bunch of LSPs, accepts it (yes reduction and acks are used), creates the session, then deletes it right away for some reason. Our testing suggests there are two workarounds for this: You might be aware that in 16.1 among other RSVP-TE changes the default refresh-time (governing generation of successive refresh messages Path/Resv) changed to 1200s -so no what you think making it 1200 on 15 side wont do, it has to be less (e.q. 1999s). If you want to keep refresh time at 1200 or higher then another option strangely enough is to disable CSPF on the affected LSPs (didn't know that SPF/CSPF changes contents of the PATH msg that in one case 17 code is cool with PATH msg in other case not). Would appreciate any pointers. adam ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
