Re: [j-nsp] EVPN - BGP attribute propagation on MXes
❦ 1 juillet 2019 16:38 +02, Guillermo Fernando Cotone : > Does anyone have implemented BGP attribute propagation using EVPN route > type-5? > We're trying to get BGP community propagation over an EVPN L3VNI, but so > far we had no luck. I've no idea if there's any knob to enable this. > > Our use-case is to connect BGP islands through an EVPN backbone, and we > expect BGP attributes, such as communities, to be propagated over the > backbone. Pretty much standard IP-VPN behavior. Also referenced here: > https://tools.ietf.org/html/draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02#section-4.2 > > I'm not sure if this is actually supported on Juniper. We're > running 17.3R3-S2.2. We didn't had any luck either with 18.1R3-S5 on QFX. I didn't push the issue to JTAC as we have found another way to implement what we wanted. -- He jests at scars who never felt a wound. -- Shakespeare, "Romeo and Juliet, II. 2" ___ 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
That is a fusion satellite device software version for an 18.x release.
--
Eldon
On Tue, Jul 2, 2019, 14:05 Colton Conor wrote:
> Do you know when this will be fixed in the mainline releases? I have no
> clue what 3.5R1-S4.1 is?
>
> On Fri, Jun 28, 2019 at 2:22 PM Timothy Creswick
> wrote:
>
> > 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
> >
> ___
> 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 had that issue between QFX5110's and MX's.Some feature at the time forced me to run 17.4 on the QFX's and they wouldn't establish LSP's with older MX80's in our fleet that were still running 14.2. I had to either downgrade the QFX's to 15.1 or upgrade the MX's to 16.1 or greater. I ended up grading the MX's as they were overdue anyway. Simon. On Fri, 28 Jun 2019 at 22:15, 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 > -- Dicko. ___ 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
Do you know when this will be fixed in the mainline releases? I have no
clue what 3.5R1-S4.1 is?
On Fri, Jun 28, 2019 at 2:22 PM Timothy Creswick
wrote:
> 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
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EVPN - BGP attribute propagation on MXes
Hi folks, Does anyone have implemented BGP attribute propagation using EVPN route type-5? We're trying to get BGP community propagation over an EVPN L3VNI, but so far we had no luck. I've no idea if there's any knob to enable this. Our use-case is to connect BGP islands through an EVPN backbone, and we expect BGP attributes, such as communities, to be propagated over the backbone. Pretty much standard IP-VPN behavior. Also referenced here: https://tools.ietf.org/html/draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02#section-4.2 I'm not sure if this is actually supported on Juniper. We're running 17.3R3-S2.2. Best, Guillermo ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
