Re: [j-nsp] ACX Questions

[Eldon Koyle]

I don't think there are many SEs on this list.  I also think your questions
would take a lot of time to research, and an SE on this list would likely
have to research that on their own time.

You are far more likely to get an answer by asking the SE for your account.

-- 
Eldon

On Fri, Apr 9, 2021, 11:53 Colton Conor  wrote:

> For the ACX line, what is the Maximum number of MPLS labels in a packet’s
> label stack (push, pop, and swap operations)? Specifically, mostly
> interested in the ACX5048 and ACX2200's
>
> I found the following chart for the QFX line, and it was extremely helpful.
> I haven't been able to find the same information for the ACX Line however:
>
> https://www.juniper.net/documentation/en_US/junos/topics/reference/general/mpls-scaling-values-qfx-series.html
>
>
> Can anyone confirm or deny if the ACX5048's hardware is identical to the
> QFX5100? My understanding is they run a different JUNOS load on them, but
> hardware wise they are extremely similar. On the hardware side, is there
> anything in the ACX5048 that would allow more  MPLS labels in a packet’s
> label stack than the QFX5100?
>
> For the ACX line, do they support streaming telemetry? I am not sure
> exactly what to look for on the streaming telemetry support for the ACX. I
> basically just want to see realtime interface and optical stats. Which JTI
> feature is that?
>
> For the ACX5000, there are only 3 items listed under the Junos Telemetry
> Interface section.
>
>
> https://apps.juniper.net/feature-explorer/select-platform.html?category=Routing=1#family==10105000=ACX5000=20.4R1=1093=0.42180881218269106=Junos%20OS
>
> For comparison, the QFX 5100 shows 21 different features under the JTI
> Section:
>
> https://apps.juniper.net/feature-explorer/select-platform.html?category=Switching=1#family==31705100=QFX5100=20.4R1=1093=0.566764714896294=Junos%20OS
>
> Which feature am I looking for? Yes, I know this will require a collector
> of some sort.
> ___
> 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] MX204: 802.3ad LAG 2 x 1 G with a Palo Alto firewall

[Eldon Koyle]

We have noticed issues with autonegotiation 1G links on mx10003 which
caused one side to be up while the other is down.  Disabling
autonegotiation allowed the link to come up.

We have not attempted link aggregation on gig ports, though.

-- 
Eldon

On Thu, Mar 18, 2021, 07:51 Emmanuel Halbwachs 
wrote:

> Thank you very much to all for your replies, public or private.
>
> I should have said that we do not use LACP. Remote firewall admins
> confirmed that there is no LACP, there wasn't LACP on the previous MX5
> and when I put the 10G switch in beetween, there is no LACP configured
> (I should check if there is not LACP behind the curtain by default).
>
> So this is plain 802.3ad LAG, without LACP.
>
> Multiple answers said that LAG is not supported at 1G and here is a
> link [1] (thanks Adrien Desportes) that says:
>
> On MX10003 and MX204 routers, Link Aggregation Group (LAG) is
> supported on 10-Gbps speed only. It is not supported on 1-Gbps
> speed.
>
> [1]
> https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/speed-gigether-options.html
>
> I wasn't aware of this limitation. So I'm puzzled by Alexandre
> Snarskii's reply who shows a working 1G LACP LAG on 18.4R3-S6.3.
>
> I'm running 19.4R1.10.
>
> I'll try a LAG with my switch first to be sure of it.
>
> Thanks again to everybody,
>
> --
> Emmanuel Halbwachs  DIO/CASTORS/Resp. Réseau,Sécurité
> Observatoire de Paris ✆ +33 1 45 07 75 54
> Campus Paris  : 61 av. de l'Observatoire   F 75014 PARIS
> Campus Meudon : 11 av. Marcellin Berthelot F 92190 MEUDON
> ___
> 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] Why local learned ARP in EVPN has "permanent remote" flags

[Eldon Koyle]

As I understand it, this is because ARP learning is handled by EVPN
(including aging) and not the normal ARP handling mechanism.

Marking it as permanent in the ARP table prevents race conditions between
EVPN and normal ARP processing.  EVPN will delete the permanent entry when
the mac-ip entry ages out of the EVPN table (whether it was learned locally
or from a remote device).

-- 
Eldon

On Sun, Dec 13, 2020, 20:43 Chen Jiang  wrote:

> Hi! Experts
>
> Sorry for disturbing, I am curious why local learned ARP in EVPN also has
> "permanent remote" flags? if it is learned from remote VTEP then makes
> sense, cause it is learned from BGP. but why local learned ARP also has
> these flags.
>
> lab@qfx5110> show arp no-resolve
> MAC Address   Address InterfaceFlags
> fe:00:00:00:00:80 128.0.0.16  bme0.0   permanent
> 84:b5:9c:ce:b9:71 192.168.0.0 xe-0/0/46.0  none
> b8:c2:53:ad:e1:03 192.168.1.1 em2.32768none
> 7e:13:0b:56:e5:c0 192.168.1.16em2.32768none
> 5c:5e:ab:6b:d5:81 192.168.5.1 em0.0none
> 64:87:88:b8:55:43 192.168.100.10  irb.100 [ae1.0]  permanent remote
>
> Thanks for your help.
>
> --
> BR!
>
>
>
>James Chen
> ___
> 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] SRX300 Sudden Reboot

[Eldon Koyle]

You should be able to use "file copy  " if the device has
internet access.

You can also scp the file directly to the device or use file copy to pull
it from a management device.

The customary place to put firmware files is /var/tmp/ before installing.

https://www.juniper.net/documentation/en_US/junos/topics/topic-map/install-software-on-srx.html

-- 
Eldon

On Wed, Oct 28, 2020, 11:14 Mohammad Khalil  wrote:

> Can I use the web generated link to send the file to the SRX box?
>
> https://cdn.juniper.net/software/junos/15.1X49-D230/junos-srxsme-15.1X49-D230-domestic.tgz?SM_USER=xx...@bluezonejordan.com&__gda__=1603804883_8b2ff7114f49ebd48787c32ba78d7720
>
> On Wed, 28 Oct 2020 at 19:42, Mohammad Khalil  wrote:
>
> > Hi Nicolas
> > The device is remote from my side so I will have to upload the image
> > remotely , what is the best way to do that?
> >
> >
> > On Mon, 26 Oct 2020 at 01:41, Nicholas Oas 
> wrote:
> >
> >> Yes do an upgrade, that code is ancient. Anything below 15.1X49-D150 is
> >> pretty crummy. Watch out for whatever changes they made with config
> stanza,
> >> vlans, and dhcp services. Do an upgrade within 15.1X49 first.
> >>
> >> Once you're past those 15.1X49 milestones its pretty solid. Stay off of
> >> 17.x I'm happily on 20.3R1.8.
> >>
> >>
> >>
> >> On Sun, Oct 25, 2020 at 4:46 PM Mohammad Khalil 
> >> wrote:
> >>
> >>> Thanks all for the kind replies.
> >>> Adding to that , the FW got hanged and I cannot access it remotely
> unless
> >>> it is rebooted manually.
> >>> It keeps working for couple of days and then it is back again to hang
> >>> status.
> >>> Current SW version is 15.1X49
> >>>
> >>> Any recommendations ? Should I do an upgrade?
> >>>
> >>> BR,
> >>> Mohammad
> >>>
> >>> On Fri, 23 Oct 2020 at 01:31,  wrote:
> >>>
> >>> > I'd check for any firmware bugs that may have been triggered and
> >>> caused a
> >>> > reboot.
> >>> >
> >>> > On Oct 22, 2020 15:22, Emille Blanc 
> >>> wrote:
> >>> >
> >>> > What was the reported reboot reason?
> >>> > You will find that in 'show chassis routing-engine'
> >>> >
> >>> > -Original Message-
> >>> > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On
> >>> Behalf
> >>> > Of Mohammad Khalil
> >>> > Sent: Thursday, October 22, 2020 3:13 PM
> >>> > To: Juniper List
> >>> > Subject: [j-nsp] SRX300 Sudden Reboot
> >>> >
> >>> > Greetings
> >>> > I have SRX300 which is running normally for long time except for the
> >>> last
> >>> > two weeks where I have suffered from sudden reboot.
> >>> > Model: srx300
> >>> > Junos: 15.1X49-D70.3
> >>> > JUNOS Software Release [15.1X49-D70.3]
> >>> >
> >>> > Nothing has been changed or added and nothing in the log messages is
> >>> > related to this.
> >>> > As well , no active alrams and temperature levels are fine:
> >>> > tbzadmin@FW-PB-NEW# run show chassis environment
> >>> > Class Item   Status Measurement
> >>> > Temp  Routing Engine OK 45 degrees C / 113
> >>> degrees
> >>> > F
> >>> >   Routing Engine CPU OK 58 degrees C / 136
> >>> degrees
> >>> > F
> >>> > Power Power Supply 0 OK
> >>> >
> >>> > What could be the issue?
> >>> >
> >>> > Much appreciated.
> >>> > ___
> >>> > 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
> >>>
> >>
> ___
> 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] MX10K3 Experiences, ~2 years later

[Eldon Koyle]

Replace absurd with unexpected, then.

-- 
Eldon

On Sat, Dec 21, 2019, 02:15 Saku Ytti  wrote:

> Many absurd things will become reasonable and logical when they are
> sufficiently understood.
>
> On Fri, 20 Dec 2019 at 17:22, Eldon Koyle
>  wrote:
> >
> > My biggest complaint about the mx10003 is the absurd port restrictions.
> If
> > you use pic-level config, you can run all ports at 40G or 4x10G, but if
> you
> > want to use port-level speed config you have to set one of every 4 ports
> to
> > 100G on pic 1 in each slot to be able to use all of the ports.
> >
> > Be sure to check your desired config for compatibility:
> > https://apps.juniper.net/home/port-checker/index.html
> >
> > --
> > Eldon
> >
> > On Thu, Dec 19, 2019, 01:05 Mark Tinka  wrote:
> >
> > >
> > >
> > > On 18/Dec/19 19:47, Jason Lixfeld wrote:
> > > > Hi,
> > > >
> > > > I wanted to follow up on a thread from a couple of years ago about
> the
> > > MX10003
> > > >
> > > > https://lists.gt.net/nsp/juniper/63670?search_string=mx10003
> > > >
> > > > We’ve got a bunch of MX204s that we use for peering and transit over
> LDP
> > > based L3VPN pinned up with IS-IS and BFD.  We’re quite happy with these
> > > boxes from a cost, density and feature perspective.  We’ve had no
> issues
> > > with them at all so far in the few months that they’ve been in the
> field.
> > > >
> > > > Now, we’re looking for something to use in the same role, but with
> > > higher 100G port density.  The MX10003 seems like a good fit from a
> cost
> > > perspective verses something like an MX240, but also from a feature and
> > > performance perspective because it uses the same hardware as the MX204
> in
> > > terms of EA Trios and CPU on the MPC, along with the CPU and memory on
> the
> > > RE (except the MX204 has 32GB on the RE as opposed to 64GB on the
> MX10003).
> > > >
> > > > Wondering how folks are feeling about these boxes a couple of years
> > > later.
> > >
> > > We like the MX10003 as a 100Gbps edge router. It comes with the
> > > additional port density and hardware redundancy that the MX204 doesn't
> > > have, so it does have a role to play.
> > >
> > > For customers that want 100Gbps ports, we will dump them on the
> MX10003.
> > >
> > > Mark.
> > > ___
> > > 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
>
>
>
> --
>   ++ytti
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX10K3 Experiences, ~2 years later

[Eldon Koyle]

My biggest complaint about the mx10003 is the absurd port restrictions.  If
you use pic-level config, you can run all ports at 40G or 4x10G, but if you
want to use port-level speed config you have to set one of every 4 ports to
100G on pic 1 in each slot to be able to use all of the ports.

Be sure to check your desired config for compatibility:
https://apps.juniper.net/home/port-checker/index.html

-- 
Eldon

On Thu, Dec 19, 2019, 01:05 Mark Tinka  wrote:

>
>
> On 18/Dec/19 19:47, Jason Lixfeld wrote:
> > Hi,
> >
> > I wanted to follow up on a thread from a couple of years ago about the
> MX10003
> >
> > https://lists.gt.net/nsp/juniper/63670?search_string=mx10003
> >
> > We’ve got a bunch of MX204s that we use for peering and transit over LDP
> based L3VPN pinned up with IS-IS and BFD.  We’re quite happy with these
> boxes from a cost, density and feature perspective.  We’ve had no issues
> with them at all so far in the few months that they’ve been in the field.
> >
> > Now, we’re looking for something to use in the same role, but with
> higher 100G port density.  The MX10003 seems like a good fit from a cost
> perspective verses something like an MX240, but also from a feature and
> performance perspective because it uses the same hardware as the MX204 in
> terms of EA Trios and CPU on the MPC, along with the CPU and memory on the
> RE (except the MX204 has 32GB on the RE as opposed to 64GB on the MX10003).
> >
> > Wondering how folks are feeling about these boxes a couple of years
> later.
>
> We like the MX10003 as a 100Gbps edge router. It comes with the
> additional port density and hardware redundancy that the MX204 doesn't
> have, so it does have a role to play.
>
> For customers that want 100Gbps ports, we will dump them on the MX10003.
>
> Mark.
> ___
> 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] LAG/ECMP hash performance

[Eldon Koyle]

On Thu, Aug 29, 2019 at 2:52 AM James Bensley
 wrote:

> Different parameters may or may not change the diffusion density, but
> they may increase the range of results, i.e. perfect diffusion over
> 2^2 outcomes vs. perfect diffusion over 2^6 outcomes.
>
> Also, ASR9Ks use a CRC32 on Typhoon cards but not of the whole frame,
> "Post IOS-XR 4.2.0, Typhoon NPUs use a CRC based calculation of the
> L3/L4 info and compute a 32 bit hash value." So actually, your results
> below should have good diffusion in theory if this was an ASR9K
> (although I'm sure that's not the case in reality). Is the Juniper
> taking (1) the whole frame into the CRC function (2) all the headers
> but no payload, or (3) just the specific headers fields (S/D
> MAC/IP/Port/Intf)?


I think 802.3ad and ECMP both require a given connection to hash to
the same link to prevent out-of-order delivery.

Taking full frames or even full headers into your hashing algorithm
would likely break the expectation of in-order delivery (unless your
have the same vendor on both sides with something proprietary).
Ignoring that requirement, you could ditch hashing altogether and go
for round-robin.  Standards-compliant hashing implementations can only
look at header fields that don't change for a flow, namely src/dest
mac, ip, protocol, and port for TCP/UDP (maybe adding in certain MPLS,
VLAN, etc. fields or interface ids or other proprietary information
available to the chip that satisfies that requirement).

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

Re: [j-nsp] SRX dynamic vpn with Pulse Secure client - MacOS Apple laptop not working

[Eldon Koyle]

I was not impressed with the Palo Alto VPN solution when I looked into it a
couple years ago.

I think it was designed to be an always-on VPN solution to protect
corporate devices that are on the road, which is not our use case.

They did not support all of the major platforms we needed at the time,
however it looks like they have added a lot in recent versions.

-- 
Eldon

On Wed, Aug 14, 2019, 07:52 Aaron Gould  wrote:

> OK so yesterday I heard from other Juniper sources that this is not really
> recommended anymore... that Juniper acquired Pulse Secure years ago, but
> later, got rid of the Pulse Secure company and no longer really recommends
> this dynamic/remote access vpn solution... and furthermore, that Juniper is
> actually coming out with a newer Remote Access VPN solution soon (I
> heard 3Q2019).  Does anyone know anything about this?
>
> Perhaps I should just look at better remote access vpn solutions.
>
> I'm replacing old HA Active/Standby ASA5520's, which have also been my
> remote access appliance for getting into the network remotely.
>
> I've heard Palo Alto are good.
>
> -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

[Eldon Koyle]

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] Link establishment issues with 1Gbps SX/LX SFPs on QFX5110

[Eldon Koyle]

And a TSB:

TSB17538
<https://kb.juniper.net/InfoCenter/index?page=content=TSB17538=SUBSCRIPTION>
Traffic
drop is seen on EX4300 when 10G Fiber port is using 1 Gigabit Ethernet SFP
optics with Auto Negotiation enabled

-- 
Eldon


On Tue, Jun 25, 2019, 23:01 Eldon Koyle 
wrote:

> Here is a sampling of PRs (there have been a _lot_ in the PR subscription
> emails recently):
>
>
> (EX4300)
> PR1420343
> <https://prsearch.juniper.net/InfoCenter/index?page=prcontent=PR1420343=SUBSCRIPTION>
>  When
> using 1G SFP in 10G ports, neet to configure interface as no-autoneg
>
> PR1422958
> <https://prsearch.juniper.net/InfoCenter/index?page=prcontent=PR1422958=SUBSCRIPTION>
>  QFX5100-48T
> 10G interface might be auto-negotiated at 1G speed instead of 10G
>
> PR1411852
> <https://prsearch.juniper.net/InfoCenter/index?page=prcontent=PR1411852=SUBSCRIPTION>
>  V44
> QFX5110 : auto-negotiation is not disabled in hardware after setting
> no-auto-negotiation option in cli
>
> --
> Eldon
>
> On Tue, Jun 25, 2019, 09:13 Anderson, Charles R  wrote:
>
>> The same problem exists on 18.x on EX4300 standalone or VC (not Fusion).
>>
>> On Mon, Jun 24, 2019 at 09:49:45PM +, Timothy Creswick wrote:
>> > Hi All,
>> >
>> > We've been battling with a number of issues getting 1G Base-X links to
>> work on a batch of new QFX5110-48S switches, in use as Fusion devices
>> connected to MX204.
>> >
>> > No problems with a variety of 10G and 100G connections. A lot of 1G
>> works fine but we seem to have issues with auto-negotiate with both SX and
>> LX optics. JTAC are a bit lost and we've tried a variety of firmwares with
>> varying success. Turning auto-negotiate off on both sides seems to fix most
>> of this, but that's not viable in a lot of cases where there's a 3rd party
>> involved.
>> >
>> > Anyone seen similar and aware of a fix?
>> >
>> > Regards,
>> >
>> > 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

Re: [j-nsp] Link establishment issues with 1Gbps SX/LX SFPs on QFX5110

[Eldon Koyle]

Here is a sampling of PRs (there have been a _lot_ in the PR subscription
emails recently):


(EX4300)
PR1420343

When
using 1G SFP in 10G ports, neet to configure interface as no-autoneg

PR1422958

QFX5100-48T
10G interface might be auto-negotiated at 1G speed instead of 10G

PR1411852

V44
QFX5110 : auto-negotiation is not disabled in hardware after setting
no-auto-negotiation option in cli

-- 
Eldon

On Tue, Jun 25, 2019, 09:13 Anderson, Charles R  wrote:

> The same problem exists on 18.x on EX4300 standalone or VC (not Fusion).
>
> On Mon, Jun 24, 2019 at 09:49:45PM +, Timothy Creswick wrote:
> > Hi All,
> >
> > We've been battling with a number of issues getting 1G Base-X links to
> work on a batch of new QFX5110-48S switches, in use as Fusion devices
> connected to MX204.
> >
> > No problems with a variety of 10G and 100G connections. A lot of 1G
> works fine but we seem to have issues with auto-negotiate with both SX and
> LX optics. JTAC are a bit lost and we've tried a variety of firmwares with
> varying success. Turning auto-negotiate off on both sides seems to fix most
> of this, but that's not viable in a lot of cases where there's a 3rd party
> involved.
> >
> > Anyone seen similar and aware of a fix?
> >
> > Regards,
> >
> > 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

Re: [j-nsp] QSFP28 oddities between Arista and QFX after upgrade

[Eldon Koyle]

I had this happen between an mx and a Palo Alto firewall a few days ago
(after upgrading the firmware on the firewall).  I ended up rebooting the
pic on the mx to get it back up.

On Sat, May 11, 2019, 08:09 Jason Lixfeld  wrote:

> No dice for either reed-solomon/fec91 or no error-correction encoding/fec
> none.
>
> > On May 11, 2019, at 9:28 AM, Tim Jackson  wrote:
> >
> > Check FEC settings. Try turning FEC on or off on both sides.
> >
> > Arista: (config-if)#error-correction encoding reed-solomon
> >
> > Juniper: set interfaces et-0/0/1 gigether-options fec fec91
> >
> > On Sat, May 11, 2019, 6:32 AM Jason Lixfeld  > wrote:
> > I had no idea auto-negotiation was still a thing with 100G, but in any
> event, toggling auto negotiation didn’t work.
> >
> > > On May 11, 2019, at 2:21 AM, Eric Krichbaum  e...@telic.us>> wrote:
> > >
> > > I had a similar issue with 18.x and MX204. Did you try turning off
> auto-negotiation?
> > >
> > > set interfaces et-4/0/52 ether-options no-auto-negotiation
> > >
> > > I had a similar issue with QFX5100/EX4300 and 40G and this fixed the
> issue oddly enough.
> > >
> > > Eric
> > >
> > > -Original Message-
> > > From: juniper-nsp  juniper-nsp-boun...@puck.nether.net>> On Behalf Of Jason Lixfeld
> > > Sent: Friday, May 10, 2019 6:13 PM
> > > To: juniper-nsp  juniper-nsp@puck.nether.net>>
> > > Subject: [j-nsp] QSFP28 oddities between Arista and QFX after upgrade
> > >
> > > Hey,
> > >
> > > I have a QFX5110 in the lab which I upgraded from 17.something to 18.4
> to resolve some ISIS weirdness.  ISIS weirdness resolved, but now the
> previously working link between this QFX and an Arista 7280SR no longer
> comes up, despite light levels on both sides being within norms.  I went
> from 18.4 to 19.1 just for the hell of it, and still no bueno.
> > >
> > > The QSFP28 in the QFX comes up if it’s looped to itself, as does the
> QSFP28 in the Arista.  The Arista QSFP28 links to another Arista, or an
> MX204.  The QFX QSFP28 links to the same MX204 as well (no other QSFP28
> gear to test with otherwise) so it seems to be a weird compatibility issue
> between the Arista and the QFX?
> > >
> > > Does this sort of thing smell familiar to anyone?  I’ve had pretty
> good luck with 100G compatibility in general so far, so I’m not overly
> familiar with any knobs to work around any compatibility issues that may
> creep up here or there, so happily accept some pointers if anyone has some
> clue.
> > >
> > > Thanks!
> > > ___
> > > juniper-nsp mailing list juniper-nsp@puck.nether.net  juniper-nsp@puck.nether.net>
> https://puck.nether.net/mailman/listinfo/juniper-nsp <
> https://puck.nether.net/mailman/listinfo/juniper-nsp>
> > >
> > >
> > > ---
> > > This email has been checked for viruses by Avast antivirus software.
> > > https://www.avast.com/antivirus 
> > >
> >
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net  juniper-nsp@puck.nether.net>
> > https://puck.nether.net/mailman/listinfo/juniper-nsp <
> 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] EVPN all-active toward large layer 2?

[Eldon Koyle]

On Fri, Apr 19, 2019 at 5:06 AM  wrote:
>
> > Tarko Tikan
> > Sent: Thursday, April 18, 2019 10:14 AM
> >
> > hey,
> >
> > > You have effectively created L2 loop over EVPN, so to cut it you need
> > > a link between bridged network and EVPN to be a single link. There is
> > > no STP in EVPN.
> >
> > To be fair it's not a full loop but only BUM traffic will loop back to
> other PE.
> >
> Yes but there should be an MPLS label associated with that traffic that says
> to the other PE -do not send this traffic back to LAN -cause it's the same
> site.

The problem is actually in the other side: the LAN would send BUM
traffic sourced from the router back to the other router port, and BUM
traffic sourced from the LAN to both router ports.  Two sites
configured like this in an evpn would cause such traffic to loop
infinitely, since Ethernet has no TTL.  Three sites would get you to
the point of exponential packet duplication where a single broadcast
packet could fill your pipes and keep them full until you intervene
(or something dies).

Allowing a MAC to appear on multiple ports would add a _lot_ of
complexity to ethernet (current hardware doesn't support it), and
could often result in traffic taking a suboptimal path (since switches
only know they saw this source MAC on that port -- not how far away it
is).  You would need a routing protocol running at layer 2 to solve
these issues.

Remember that ethernet was initially designed using shared media, and
the MAC address was used to allow your NIC to ignore traffic that was
being sent to other hosts (to save CPU).  The fact that they managed
to shoehorn switching in there without re-writing the protocol is
magical, but we are still living with some inherent limitations.

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

Re: [j-nsp] Old JunOS upgrade path

[Eldon Koyle]

Many (most?) network operating systems are an image file that the
switch either writes over a partition (ie. block-level copy) or boots
directly (ie. initrd/initramfs) with a separate partition for a config
file.  Junos is a full BSD operating system that installs packages to
partitions on the device, runs upgrade scripts, etc.

-- 
Eldon

On Fri, Mar 8, 2019 at 12:28 PM Gert Doering  wrote:
>
> Hi,
>
> On Fri, Mar 08, 2019 at 10:38:16AM +0100, "Rolf Hanßen" wrote:
> > usually they say not more than 2 major releases in one step (i.e. 13 -> 15
> > -> 17).
>
> So why is that?
>
> Genuinely curious, as I do not have much JunOS upgrade experience - and
> my Cisco IOS experience so far has been "you can go from wherever you
> are to wherever you want to go" - when going up, you can hit warnings
> about "old config syntax", and when going down, you might lose config
> bits that are "new" - but besides this, things generally work.
>
> gert
>
> --
> "If was one thing all people took for granted, was conviction that if you
>  feed honest figures into a computer, honest figures come out. Never doubted
>  it myself till I met a computer with a sense of humor."
>  Robert A. Heinlein, The Moon is a Harsh Mistress
>
> Gert Doering - Munich, Germany g...@greenie.muc.de
> ___
> 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] Junos and single IPv6 link-local address per IFL

[Eldon Koyle]

He showed fe80::206:aff:fe0e:fffb/64 in his second example with the same
result.

-- 
Eldon

On Tue, Jan 22, 2019, 07:11 Anderson, Charles R  Link-Local addresses should be in fe80::/64, not fe80::/10.  Try
> configuring a second one that meets this criteria, such as:
>
> > +   address fe80::206:aff:fe0e:fffb/64;
>
> On Tue, Jan 22, 2019 at 03:42:43PM +0200, Martin T wrote:
> > Hi,
> >
> > looks like Junos allows to have only a single IPv6 link-local address.
> > For example, here I tested with Junos 18.2R1.9:
> >
> > root@vmx1# show | compare
> > [edit interfaces ge-0/0/9 unit 0 family inet6]
> > address fe80::206:aff:fe0e:fffa/64 { ... }
> > +   address fe80:1::206:aff:fe0e:fffa/64;
> >
> > [edit]
> > root@vmx1# commit check
> > [edit interfaces ge-0/0/9 unit 0 family inet6]
> >   'address fe80:1::206:aff:fe0e:fffa/64'
> >  Link Local address exists
> > error: configuration check-out failed
> >
> > [edit]
> > root@vmx1#
> >
> > ..or:
> >
> > root@vmx1# show | compare
> > [edit interfaces ge-0/0/9 unit 0 family inet6]
> > address fe80::206:aff:fe0e:fffa/64 { ... }
> > +   address fe80::206:aff:fe0e:fffb/64;
> >
> > [edit]
> > root@vmx1# commit check
> > [edit interfaces ge-0/0/9 unit 0 family inet6]
> >   'address fe80::206:aff:fe0e:fffb/64'
> >  Link Local address exists
> > error: configuration check-out failed
> >
> > [edit]
> > root@vmx1#
> >
> > Just out of curiosity, why there is this limitation? For example
> > FreeBSD 11, which Junos 18.2R1.9 is based on, does not have this
> > limitation:
> >
> > root@FreeBSD-11:~ # ifconfig em0 inet6
> > em0: flags=8843 metric 0 mtu
> > 1500
> >
>  options=209b
> > inet6 fe80::fc69:d3ff:feec:7741%em0 prefixlen 64 scopeid 0x1
> > inet6 fe80::fc69:d3ff:feec:7740%em0 prefixlen 64 scopeid 0x1
> > nd6 options=21
> > root@FreeBSD-11:~ #
> ___
> 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] SRX WAN DHCP

[Eldon Koyle]

I think the commands to check on the dhcp client are show dhcp client
binding and show dhcp client statistics.

There are a lot of bugs in -D70.

-- 
Eldon

On Mon, Dec 10, 2018 at 8:42 AM Mohammad Khalil  wrote:

> I cannot do the upgrade right now as I have to do the setup so quickly
> What features should I enable ?
>
> On Mon, 10 Dec 2018 at 17:40, Eldon Koyle <
> ekoyle+puck.nether@gmail.com> wrote:
>
>> The firmware that ships on the SRX is missing a lot of features.  I would
>> recommend upgrading to the latest version in that code train, which is
>> 15.1X49-D150.
>>
>> --
>> Eldon
>>
>> On Mon, Dec 10, 2018 at 1:00 AM Mohammad Khalil 
>> wrote:
>>
>>> Hello all
>>> I have an old SRX which I configured it is WAN IP address using the below
>>> command:
>>> set interfaces ge-0/0/0 unit 0 family inet address dhcp
>>>
>>> Now , I have replaced the box with a newer one (srx300 15.1X49-D70.3)
>>> but I
>>> cannot find the command itself
>>> I have tried the below:
>>> set interfaces ge-0/0/0 unit 0 family inet dhcp-client
>>> With no luck !
>>> When I try to check :
>>> show system services ? (no DHCP option is available)
>>> I have configured:
>>> set security zones security-zone untrust interfaces ge-0/0/0.0
>>> host-inbound-services dhcp
>>>
>>> Any ideas guys?
>>>
>>> BR,
>>> Mohammad
>>> ___
>>> 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] SRX WAN DHCP

[Eldon Koyle]

The firmware that ships on the SRX is missing a lot of features.  I would
recommend upgrading to the latest version in that code train, which is
15.1X49-D150.

-- 
Eldon

On Mon, Dec 10, 2018 at 1:00 AM Mohammad Khalil  wrote:

> Hello all
> I have an old SRX which I configured it is WAN IP address using the below
> command:
> set interfaces ge-0/0/0 unit 0 family inet address dhcp
>
> Now , I have replaced the box with a newer one (srx300 15.1X49-D70.3) but I
> cannot find the command itself
> I have tried the below:
> set interfaces ge-0/0/0 unit 0 family inet dhcp-client
> With no luck !
> When I try to check :
> show system services ? (no DHCP option is available)
> I have configured:
> set security zones security-zone untrust interfaces ge-0/0/0.0
> host-inbound-services dhcp
>
> Any ideas guys?
>
> BR,
> Mohammad
> ___
> 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] Opinions on fusion provider edge

[Eldon Koyle]

We are looking at a mix of QFX5100-48S and EX4300-32F (somewhere between 6
and 10 devices total).  It looks like the QFX supports EVPN, but Juniper
doesn't seem to have any relatively inexpensive 1Gbe devices with EVPN
support.

We are planning on dual-homing most of our buildings (strictly L2, using
active-active EVPN or MC-LAG) to a pair of MXes with QSFP ports and fiber
breakout panels, however we have some odds and ends that don't make sense
there due to optic requirements (a few bidi and a few ER) and cost (just
can't justify upgrading to 10Gbe hardware in many locations).

One other concern is that licensing costs can add up quickly.  In general,
would this end up requiring the AFL?

-- 
Eldon

On Tue, Nov 6, 2018 at 10:20 AM Richard McGovern 
wrote:

> I might suggest you look at an EVPN based design instead.  This is going
> to be Juniper's #1 go to in the future.  I believe things like Junos Fusion
> and MC-LAG, etc. may still be supported, but secondary to EVPN and
> associated features.
>
> What is your planned SD devices?  QFX5???
>
> Richard McGovern
> Sr Sales Engineer, Juniper Networks
> 978-618-3342
>
>
> On 11/5/18, 8:32 PM, "Eldon Koyle" 
> wrote:
>
> What kind of experiences (good or bad) have people had with Juniper's
> Fusion Provider edge?  Are there any limitations I should be aware of?
>
> I'm looking at it to simplify management in a campus network
> environment
> and to use features that are only available on the MX currently.
>
> --
> Eldon
> --
> I don't think the universe wants me to send this message
>
>
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Opinions on fusion provider edge

[Eldon Koyle]

What kind of experiences (good or bad) have people had with Juniper's
Fusion Provider edge?  Are there any limitations I should be aware of?

I'm looking at it to simplify management in a campus network environment
and to use features that are only available on the MX currently.

-- 
Eldon
-- 
I don't think the universe wants me to send this message
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp