Re: [j-nsp] Difference in "MX204" and "MX204-HW-BASE"?

[Richard McGovern via juniper-nsp]

Hopefully not enforced!! Just FYI, but one of the advantages of Flex SW License 
scheme is ability to move license from one SN to another. In License Portal you 
“should” be able to revoke an applied Flex license and then apply that Flex 
license to another SN. You should then me removing the license from the revoked 
device.

Now as to whether this actually works, especially in all cases, I do not know.

Regards, 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




Juniper Business Use Only
From: chiel 
Date: Thursday, January 11, 2024 at 8:14 AM
To: Richard McGovern , Tom Beecher 
Cc: juniper-nsp@puck.nether.net 
Subject: Re: [j-nsp] Difference in "MX204" and "MX204-HW-BASE"?
[External Email. Be cautious of content]

On 10/01/2024 22:41, Richard McGovern wrote:
Hopefully this helps, and explains a little of the history of how MX got to 
where it is today, and beyond.

Thanks for the insight! this helps :)

As I only need it for spare I will probably just go for the MX204-HW-BASE and 
ignore the warning messages if I ever need to use it. Good to know that its not 
(yet) enforced.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Thanks for all the fish

[Richard McGovern via juniper-nsp]

#1 jewel HPE (Aruba) is interested in is Juniper/MIST AI. MIST AI and ML is 
also being integrated into many other facets of Juniper, one being Apstra. See 
this in announcement - 
https://www.barrons.com/articles/cisco-stock-arista-juniper-hp-enterprise-acquisition-b94d6024

FYI only, 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




Juniper Business Use Only

On 1/10/24, 5:10 PM, "Giuliano C. Medalha"  wrote:
Alexandre,

Goodnight.

JUNIPER has 2 very powerful jewels that don't make any sense for HPe to throw 
them away.

One of them is the JUNOS operating system and now the JUNOS-EVO.

The other thing is related to the JUNIPER NPUs: TRIO and Express ( to compete 
with other vendors - cisco, arista, nokia - and now with nvidia )

The technology of these JUNIPER NPUs is very great. Both shipping and 
manufacturing.  There is the issue today of low energy consumption too.

And there is the entire JUNIPER engineering team that has enormous value.

HPe must have a huge interest in JUNIPER NPUs for High Performance Computing 
(HPC) ... as investments in HPC for AI processing are extremely high today.

And HPe certainly has its eye on this market... being able to supply servers 
with Nvidia's HG100 cards (example) and the entire network part with the 
appropriate NPU to run the necessary communication for AI and ML.

So I don't believe that wasting a huge chance like that, especially in the 
American market, is something they are not thinking about.  Quite the opposite.

Besides 5G and Edge Computing ... and other projects.

At.te

Giuliano


Take a look 


Sharada Yeluri articles:

https://urldefense.com/v3/__https://www.linkedin.com/pulse/gpu-fabrics-genai-workloads-sharada-yeluri-j8ghc?utm_source=share&utm_medium=member_ios&utm_campaign=share_via__;!!NEt6yMaO-gk!HQROn9iGp4UvBkIlPTpyFN3tHCur82IRLhMj2HcS56qjKND36LA46zPvEikfsSpdYFnKJfz3cUTcL6mDjp7THMIoKNxHYZLW$

https://urldefense.com/v3/__https://www.linkedin.com/pulse/chiplets-inevitable-transition-sharada-yeluri?utm_source=share&utm_medium=member_ios&utm_campaign=share_via__;!!NEt6yMaO-gk!HQROn9iGp4UvBkIlPTpyFN3tHCur82IRLhMj2HcS56qjKND36LA46zPvEikfsSpdYFnKJfz3cUTcL6mDjp7THMIoKGpRuQPN$


MIT AI:

https://urldefense.com/v3/__https://people.csail.mit.edu/ghobadi/papers/trio_sigcomm_2022.pdf__;!!NEt6yMaO-gk!HQROn9iGp4UvBkIlPTpyFN3tHCur82IRLhMj2HcS56qjKND36LA46zPvEikfsSpdYFnKJfz3cUTcL6mDjp7THMIoKBhUJIPe$


AKAMAI EDGE:

https://www.juniper.net/us/en/customers/akamai-technologies-case-study.html ( 
JCO400 + MX304 + PTX )



-Original Message-
From: juniper-nsp 
mailto:juniper-nsp-boun...@puck.nether.net>>
 On Behalf Of Alexandre Figueira Guimaraes via juniper-nsp
Sent: Wednesday, January 10, 2024 4:38 PM
To: juniper-nsp@puck.nether.net; Aaron 
Gould mailto:aar...@gvtc.com>>
Subject: Re: [j-nsp] Thanks for all the fish

HPE will turn Juniper just like they turn 3com.

you know the results.



att
Alexandre







De: juniper-nsp 
mailto:juniper-nsp-boun...@puck.nether.net>>
 em nome de Aaron Gould via juniper-nsp 
mailto:juniper-nsp@puck.nether.net>>
Enviado: quarta-feira, 10 de janeiro de 2024 16:30
Para: juniper-nsp@puck.nether.net 
mailto:juniper-nsp@puck.nether.net>>
Assunto: Re: [j-nsp] Thanks for all the fish

https://urldefense.com/v3/__https://newsroom.juniper.net/news/news-details/2024/HPE-to-Acquire-Juniper-Networks-to-Accelerate-AI-Driven-Innovation/__;!!M3gv20Gt!cY_tIELb_GnFbX25Rob0JdOOa-DCsw5rdrDXQLZCHc5pbquwHK0zxmd1eBGJkltMjQg9rRZ5_SLSka5e9RqBfwazhmC0uXDs$

an MX with an HP label on it will seem so weird


On 1/9/2024 2:55 AM, Saku Ytti via juniper-nsp wrote:
> What do we think of HPE acquiring JNPR?
>
>
> I guess it was given that something's gotta give, JNPR has lost to
> dollar as an investment for mor

Re: [j-nsp] Difference in "MX204" and "MX204-HW-BASE"?

[Richard McGovern via juniper-nsp]

Agree sort of. The SW should know if model was MX204 or MX204-P-BASE/ 
MX204-HW-BASE. So it should know if need to enforce a license or not. The 
problem is that some MX204-P-BASE were sold as -IR or -R, etc. and some sold 
with Flex – Transition period.

There is no way for SW to know by which method a MX204-P-BASE was sold. So no 
way to know to enforce or not. That is one reason for “soft” enforcement. 
Customer (and Juniper Sales) can then determine which method was used, and get 
the customer a valid perpetual license at $0 so customer is good to go forever.

Now whether this approach is actually occurring, I don’t know. I service my 
customer base like above on an as needed basis.

FYI only, 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




Juniper Business Use Only
From: Giuliano C. Medalha 
Date: Wednesday, January 10, 2024 at 4:49 PM
To: Gert Doering , Richard McGovern 
Cc: juniper-nsp@puck.nether.net 
Subject: RE: [j-nsp] Difference in "MX204" and "MX204-HW-BASE"?
[External Email. Be cautious of content]


Good evening guys, how are you ?

If I can contribute a little.

Looking from a timeline standpoint... the MX204 passed:

- MX204 with -IR and R licenses ( which were perpetual )

- MX204-P-BASE ( Which was the transition box from -IR and -R to Flex License )

- MX204-HW-BASE ( Advanced and Premium Flex Licenses with 3 years or Perpetual )

Now on the JUNOS 22, Juniper starts requesting that the licenses hashes be 
installed in the box. However, from my point of view, the portal for generating 
router licenses is not yet prepared to take an -IR or -R license and generate 
it in the way that version 22 understands.

For example. If you bought an MX480/MPC7 ago with -IR and -R ... the JUNOS 22 
will ask you to install the hash of a license to enforce the table's software 
(bgp, gre, etc). However, we still haven't figured out how to generate an old 
MX480 or MX204 license for the new standard that JUNIPER is requiring in the 
JUNOS 22...

I think they forgot about that... somehow... and it will need to be resolved.

At.te

Giuliano

-Original Message-
From: juniper-nsp  On Behalf Of Gert 
Doering via juniper-nsp
Sent: Wednesday, January 10, 2024 6:46 PM
To: Richard McGovern 
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Difference in "MX204" and "MX204-HW-BASE"?

Hi,

On Wed, Jan 10, 2024 at 09:41:41PM +, Richard McGovern via juniper-nsp 
wrote:
> Now, unknown to me (they don?t tell SEs any of this info either) there
> could have been ?hard? enforcement added in some newer SW release ? RN
> should point this out (stop laughing please!!!). Juniper internal have
> discussed implementing ?hard? enforcement over the years, and with
> potential change in product management (just happens) that view may
> change. Can?t tell you yah or nah on hard enforcement.

If you do not have enough magenta coloured ink, no BGP for you...

gert
--
Gert Doering - Munich, Germany g...@greenie.muc.de

WZTECH is registered trademark of WZTECH NETWORKS.
Copyright © 2023 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informações deste e-mail e o conteúdo dos eventuais documentos anexos são 
confidenciais e para conhecimento exclusivo do destinatário. Se o leitor desta 
mensagem não for o seu destinatário, fica desde já notificado de que não poderá 
divulgar, distribuir ou, sob qualquer forma, dar conhecimento a terceiros das 
informações e do conteúdo dos documentos anexos. Neste caso, favor comunicar 
imediatamente o remetente, respondendo este e-mail ou telefonando ao mesmo, e 
em seguida apague-o.

CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are 
solely for the intended recipient and may contain confidential or privileged 
information. If you are not the intended recipient, any review, transmission, 
dissemination or other use of this information is prohibited. If you have 
received this communication in error, please notify the sender immediately and 
delete the material from any computer, including any copies.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Difference in "MX204" and "MX204-HW-BASE"?

[Richard McGovern via juniper-nsp]

Ah, I forgot that point. None of the features should be “hard” enforced, no 
matter what SW release you are running. You should receive many error/warning 
messages regarding using a feature for which you do not have a license – “soft” 
enforcement we call it. So no feature should not be able to be configured or 
used because of lack of a license. If a license is needed for testing, reach 
out to your Juniper SE or go through Partner to get a temp license.

Juniper protects against user using features they did not actually pay for via 
EULA – End User License Agreement - 
https://webdownload.juniper.net/swdl/dl/secure/site/1/record/167857.html?pf=QFX5120-32C

A “MX204” hardware and SKU knew nothing about Flex license. That model was 
pre-Flex. That model had no licenses if my memory is right – full Junos which 
was changed at $10K – very good deal I might add!!. That model (IC bus name) 
thinks differently than model with name MX204-HW-Base or MX204-HWBASE-AC-FS (FS 
= Flex Software maybe). Both of these models know about Flex and the 
requirement match of feature being used and license installed.

Now, unknown to me (they don’t tell SEs any of this info either) there could 
have been “hard” enforcement added in some newer SW release – RN should point 
this out (stop laughing please!!!). Juniper internal have discussed 
implementing “hard” enforcement over the years, and with potential change in 
product management (just happens) that view may change. Can’t tell you yah or 
nah on hard enforcement.

Hopefully this helps, and explains a little of the history of how MX got to 
where it is today, and beyond.

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




Juniper Business Use Only
From: chiel 
Date: Wednesday, January 10, 2024 at 4:13 PM
To: Richard McGovern , Tom Beecher 
Cc: juniper-nsp@puck.nether.net 
Subject: Re: [j-nsp] Difference in "MX204" and "MX204-HW-BASE"?
[External Email. Be cautious of content]


On 10/01/2024 18:50, Richard McGovern wrote:
> So basically without some Feature License tied the HW SN via some Flex
> Feature License, it is a good boat anchor!

So why does the MX204 I currently have and doesn't have any license
installed on it is running BGP/OSPF without any problems on version
22.3R3.8? If I lookup the SN on the Juniper website [1] I see "MX204".
If I lookup other SN from "MX204-HW-BASE" I do see "MX204-HW-BASE"
instead of "MX204".

So I guess "MX204" doesn't enforce the license?

I guess another option is not to go above version 22.2R1?

[1] https://entitlementsearch.juniper.net/

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

Re: [j-nsp] Difference in "MX204" and "MX204-HW-BASE"?

[Richard McGovern via juniper-nsp]

Confusing, yes! As chiel wrote, these are just ordering SKU. Neither should be 
used for new orders. Instead “MX204-HWBASE-AC-FS” should be used, but 
“MX204-HW-BASE” is still allowed for legacy ordering. These are both priced the 
same, and basically provide exact same HW parts.

The “difference” is that either SKU above does not contain a [Flex] Feature 
License. Some Feature License, Adv or Prem, at some term (years or perpetual) 
must now be included if you want any MX to do any L3 or above features. So 
basically without some Feature License tied the HW SN via some Flex Feature 
License, it is a good boat anchor!

For information on Flex Licenses go here - 
https://www.juniper.net/documentation/us/en/software/license/juniper-licensing-user-guide/topics/concept/licenses-for-juniper-software.html

This change in how MX and other Juniper products has been driven by Stock 
Analysist and other vendors. “I don’t make the news, I just report it”

For any questions, reach out to either your Juniper Partner or Juniper Account 
team.

FYI Only. Regards, 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




Juniper Business Use Only

On 1/10/24, 10:43 AM, "Tom Beecher"  wrote:
>
> Is there a difference between "MX204" and "MX204-HW-BASE"?
>

Strictly speaking they are just different SKUs, not different models.

MX204 : Chassis + Fan trays + PEMs
MX204-HW-BASE : Base MX204 chassis PLUS perpetual Junos software license

AFAIK , code that has enforcement is limited to specific scaling or more
advanced features, but outside of that, base things just work. Don't take
that as gospel though.

On Wed, Jan 10, 2024 at 8:19 AM chiel via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

> Is there a difference between "MX204" and "MX204-HW-BASE"?
>
> I thought the "MX204" has honored based license, which isn't sold
> anymore. Where the "MX204-HW-BASE" (also end of sale but still widely
> available) enforces the license after version 22.2R1 for BGP. Is this
> assumption correct?
>
> If there is indeed this difference how can I distinguish these two
> platforms from the CLI?
>
> I have a MX204 with version 22.3R3.8 without a license installed on it
> and its doing BGP just fine. So I guess I have the older MX204 model?
>
> I'm asking as I'm looking for a spare (refurb) unit for my current router.
>
> admin@router> show system license
> License usage:
>   Licenses LicensesLicenses
>Feature  Feature Feature
>Feature name   usedinstalled  needed Expiry
>scale-subscriber  0   10 0permanent
>scale-l2tp0 1000 0permanent
>bgp   10 1invalid
>l3static  10 1invalid
>ospf  10 1invalid
>
> Licenses installed: none
>
>
> admin@router> show chassis hardware
> Hardware inventory:
> Item Version  Part number  Serial number Description
> ChassisX JNP204 [MX204]
>
>
>
>
>
> ___
> juniper-nsp mailing list 
> juniper-nsp@puck.nether.net
> https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!HM7gEF_z7P4gJFLCXZHpeRSYZS1CilX2JR5jkx3QzaipAcvbCUR0ST_5k7ofKmP_QjyeiPn4zEkATeJtAPcPNDDDEeJKigAR$
>


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

Re: [j-nsp] Juniper QFX5200-32c and QSFP28 channelized optics

[Richard McGovern via juniper-nsp]

Yes. I forgot about that option. Thanks for bringing that up.

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




Juniper Business Use Only

On 1/9/24, 10:47 AM, "Chriztoffer Hansen"  wrote:
I can confirm using a QSFP+ to SFP+ adapter works, too. (Lane 0 being wired
to the front, lane 1-3 are not used)

With the following configuration

fpc 0 {
pic 0 {
/* Set in groups of four, e.g. 0-3, Here 8-11 */
port 8 {
channel-speed 10g;
}
port 9 {
channel-speed 10g;
}
port 10 {
channel-speed 10g;
}
port 11 {
channel-speed 10g;
}
}
}

With the following type of converter optic. Example -
https://urldefense.com/v3/__https://www.fs.com/de-en/products/72582.html__;!!NEt6yMaO-gk!F7CPnpSnZpSXCLUjJg7ZJZW-4EwnnuO6ZEpuqfTNbXUdi7T4_PbDtVrokE_DOROtLHGyiRFKFH70pDnNdKL9rYBk1FIdvyvw$<https://urldefense.com/v3/__https:/www.fs.com/de-en/products/72582.html__;!!NEt6yMaO-gk!F7CPnpSnZpSXCLUjJg7ZJZW-4EwnnuO6ZEpuqfTNbXUdi7T4_PbDtVrokE_DOROtLHGyiRFKFH70pDnNdKL9rYBk1FIdvyvw$>
  (QSFP+ to 10G SFP+)
https://urldefense.com/v3/__https://www.fs.com/de-en/products/178066.html__;!!NEt6yMaO-gk!F7CPnpSnZpSXCLUjJg7ZJZW-4EwnnuO6ZEpuqfTNbXUdi7T4_PbDtVrokE_DOROtLHGyiRFKFH70pDnNdKL9rYBk1LwF-waO$<https://urldefense.com/v3/__https:/www.fs.com/de-en/products/178066.html__;!!NEt6yMaO-gk!F7CPnpSnZpSXCLUjJg7ZJZW-4EwnnuO6ZEpuqfTNbXUdi7T4_PbDtVrokE_DOROtLHGyiRFKFH70pDnNdKL9rYBk1LwF-waO$>
  (QSFP28 to 25G SFP28)

(This is on 5120-32c)

On Tue, 9 Jan 2024 at 15:39, Richard McGovern via juniper-nsp <
juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>> wrote:

> For 10G support, you need to use a 40G [proper] Optic and channelize this
> to 4 x 10G.
>
> Just FYI. Rih
>
> 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
>
>
>
>
> Juniper Business Use Only
>
> On 12/29/23, 12:44 PM, "Lee Starnes" 
> mailto:lee.t.star...@gmail.com>> wrote:
> Thanks for the info and links Tobias. really helpful. It must just be a
> Juniper thing that it supports only 25G because on Cisco and Mikrotik it
> supports down to 1G. Anyway, at least I have answers and a solution.
>
> Best,
>
> -Lee
>
> On Fri, Dec 29, 2023 at 1:31 AM Tobias Heister via juniper-nsp <
> juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net><mailto:juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>>>
>  wrote:
>
> > Hi,
> >
> > While it sometimes works to let 25G transceivers run at 10G (depending
> > on Transceiver and Device(s)) i think in this case you will need a
> > different transceiver.
> >
> > See e.g. HCT for reference:
> > https://apps.juniper.net/hct/product/?prd=QFX5200-32C
> >
> > the PSM only lists 25 and 100 as being supported:
> > https://apps.juniper.net/hct/model/?component=JNP-QSFP-100G-PSM4
> >
> > For 10G SM Breakout something like
> > https://apps.juniper.net/hct/model/?component=JNP-QSFP-4X10GE-LR would
> > be the way to go.
> >
> >
> > regards
> > Tobias
> >
> > Am 29.12.2023 um 02:38 schrieb Lee Starnes via juniper-nsp:
> > > Hello everyone,
> > >
> > > I am running into an issue on our QFX5200 switches where I have
> > installed a
> > > QSFP-100G-PSM4 optic. This can do 1G/10G/25G on the 4 channels. My
> issue
> > is
> > > that I am not able to get the interfaces to go to 10G even though I
> have
> > > set them as such.
> > >
> > > If setting all 4 channels to 10G only a single interface shows at 100G.
> > If
> > > I set them all to 25G, all 4 show as 25G. Then if I change one of the
> > > channels to 10G, all 4 remain as 25G.
> > >
> > > Is this an issue with how I am setting this up or an issue with the
> type
> > of
> > > Optic being used? Below is the config for the ports in the last state I
> > > tested.
> > >
> > > chassis {
> > >  fpc 0 {
> > >  pic 0 {
> > >  port 0 {
> > >  channel-speed 10g;
> > >  }
> > >  port 1 {
> > >  channel-speed 25g;
> > >  }
> > >  port 2 {
> > >  channel-speed 25g;
> > >  }
> > >  port 3 {
> > >  channel-spe

Re: [j-nsp] Juniper QFX5200-32c and QSFP28 channelized optics

[Richard McGovern via juniper-nsp]

For 10G support, you need to use a 40G [proper] Optic and channelize this to 4 
x 10G.

Just FYI. Rih

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




Juniper Business Use Only

On 12/29/23, 12:44 PM, "Lee Starnes"  wrote:
Thanks for the info and links Tobias. really helpful. It must just be a
Juniper thing that it supports only 25G because on Cisco and Mikrotik it
supports down to 1G. Anyway, at least I have answers and a solution.

Best,

-Lee

On Fri, Dec 29, 2023 at 1:31 AM Tobias Heister via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

> Hi,
>
> While it sometimes works to let 25G transceivers run at 10G (depending
> on Transceiver and Device(s)) i think in this case you will need a
> different transceiver.
>
> See e.g. HCT for reference:
> https://apps.juniper.net/hct/product/?prd=QFX5200-32C
>
> the PSM only lists 25 and 100 as being supported:
> https://apps.juniper.net/hct/model/?component=JNP-QSFP-100G-PSM4
>
> For 10G SM Breakout something like
> https://apps.juniper.net/hct/model/?component=JNP-QSFP-4X10GE-LR would
> be the way to go.
>
>
> regards
> Tobias
>
> Am 29.12.2023 um 02:38 schrieb Lee Starnes via juniper-nsp:
> > Hello everyone,
> >
> > I am running into an issue on our QFX5200 switches where I have
> installed a
> > QSFP-100G-PSM4 optic. This can do 1G/10G/25G on the 4 channels. My issue
> is
> > that I am not able to get the interfaces to go to 10G even though I have
> > set them as such.
> >
> > If setting all 4 channels to 10G only a single interface shows at 100G.
> If
> > I set them all to 25G, all 4 show as 25G. Then if I change one of the
> > channels to 10G, all 4 remain as 25G.
> >
> > Is this an issue with how I am setting this up or an issue with the type
> of
> > Optic being used? Below is the config for the ports in the last state I
> > tested.
> >
> > chassis {
> >  fpc 0 {
> >  pic 0 {
> >  port 0 {
> >  channel-speed 10g;
> >  }
> >  port 1 {
> >  channel-speed 25g;
> >  }
> >  port 2 {
> >  channel-speed 25g;
> >  }
> >  port 3 {
> >  channel-speed 25g;
> >  }
> >
> > Thanks for any info or documents you can point me to.
> >
> > Best,
> >
> > -Lee
> > ___
> > juniper-nsp mailing list 
> > juniper-nsp@puck.nether.net
> > https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!AbnHWywEEDeGUttHzSqPdMr77UVBTZwTxHBmbOc2aX4jAbP3ToR5pp5zbJKE4mWA89WcIYMO_abVAdgp-9LYpIuFQd48K9FI$
> >
> ___
> juniper-nsp mailing list 
> juniper-nsp@puck.nether.net
> https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!AbnHWywEEDeGUttHzSqPdMr77UVBTZwTxHBmbOc2aX4jAbP3ToR5pp5zbJKE4mWA89WcIYMO_abVAdgp-9LYpIuFQd48K9FI$
>


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

Re: [j-nsp] MX204 update from 21.4R3-S4 to 21.4R3-S5

[Richard McGovern via juniper-nsp]

I believe if you cipher is set to one that Juniper no longer supports, i.e. 
that knob selection is depreciated, the upgrade will not complete. The change 
in cipher support is due to new vulnerability findings.

SSH Vulnerability, "Deprecated SSH Cryptographic Settings" with Vulnerability 
Result Type quoting the details of the category under which the alert is 
identified. For eg, if customer monitoring tool reports "Vulnerability Result 
Type Name key_exchange diffie-hellman-group14-sha1 host_key ssh-rsa MAC 
hmac-sha1- MAC hmac-sha1". This means the SRX is using deprecated SSH 
cryptographic settings to communicate.


changes needed under system service ssh to allow only strong ciphers, host key, 
MACs, algorithm



Settings currently considered deprecated (might change later):

+Ciphers using CFB of OFB -Very uncommon, and deprecated because of weaknesses 
compared to newer cipher chaining modes such as CTR or GCM

+RC4 cipher (arcfour, arcfour128, arcfour256) - The RC4 cipher has a 
cryptographic bias and is no longer considered secure

+Ciphers with a 64-bit block size (DES, 3DES, Blowfish, IDEA, CAST) - Ciphers 
with a 64-bit block size may be vulnerable to birthday attacks (Sweet32)

+Key exchange algorithms using DH group 1 (diffie-hellman-group1-sha1, 
gss-group1-sha1-*)- DH group 1 uses a 1024-bit key which is considered too 
short and vulnerable to Logjam-style attacks

+Key exchange algorithm rsa1024sha1 - Very uncommon, and deprecated because of 
the short RSA key size

+MAC algorithm umac-32 - Very uncommon, and deprecated because of the very 
short MAC length


Just FYI. 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




Juniper Business Use Only

On 11/9/23, 4:43 AM, "Muhammad Aamir"  wrote:
*try below and do to upgrade again.*

*deactivate system services ssh ciphers *

*Regards,*
*Aamir*

On Thu, Nov 9, 2023 at 12:28 PM Andreas S. Kerber via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

> Anybody successfully updated MX204 from 21.4R3-S4 to 21.4R3-S5?
> Got a few MX204 and trying to "request vmhost software add" fails
> on each of them.
>
> Anybody got a hint for me?
>
> $ request vmhost software add
> /var/tmp/junos-vmhost-install-mx-x86-64-21.4R3-S5.4.tgz
> Junos Validation begin. Procedure will take few minutes.
> Checking if VirtFS can be used for image install ...
> Required: 7654536554 bytes Available: 21476761600 bytes
> Using VirtFS ...
> {...}
> Hardware Database regeneration succeeded
> Validating against /config/juniper.conf.gz
> mgd: commit complete
> Validation succeeded
> Validating against /config/rescue.conf.gz
> mgd: commit complete
> Validation succeeded
> Verified junos-vmhost-install-mx-x86-64-21.4R3-S5.4 signed by
> PackageDevelopmentECP256_2023 method ECDSA256+SHA256
> Copied the config and other data to the aux disk.
> Transfer junos-host-upgrade.sh
> lost connection
> Transfer Done
> Starting upgrade ...
> sh: /junos/install/junos-host-upgrade.sh: No such file or directory
> rm: cannot remove '/junos/install/junos-host-upgrade.sh': No such file or
> directory
> ... upgrade failed.
> ___
> juniper-nsp mailing list 
> juniper-nsp@puck.nether.net
> https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!G2OaM6xbjo9xBebvYLAFzmsY60TWa1c9CQF9RidbdDfPWspCmb6C2V4jaXCLuuv4CySTSQO7tyumJx2GGqGshQb07zvieFBP$
>


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

Re: [j-nsp] QSA adapters and MTU

[Richard McGovern via juniper-nsp]

Couple of things regarding this thread.

#1 – MX304 MTU: The MTU restriction ONLY applies when the QSA adapter is used 
with 1G Optic in an MX304. For 10G there is no MTU limitation. The reason being:

The 2K MTU limit is very specific to MX304. The MX304 uses the YT trio PFE, 
which does not have native support for a 1GE MAC. Workaround was to implement 
the 1GE in the PHY framer on the board, and this has a very shallow buffer – 
hence the MTU limit.

Advice is to take a simple EX as satellite and use that to aggregate 1G. No MTU 
restriction then.

#2 – MX204 1G speed. I thought MX204 interfaces were SFP+, which in Juniper 
terms equals 1/10 support. I thought the interface should auto-sense the 
installed optic to determine the speed. At the same time, for MX and SRX (but 
not EX/QFX) 1/10 SFP+ capable interfaces always use an interface naming 
designation as xe-. There is no support for ge- interface naming. This was an 
internal Juniper decision for ease of implementation, as original MX (and 
therefore SRX) interfaces were NOT SFP+ (1/10 support) originally. Instead they 
were SFP, which is 1G or 10G support, but not both. Both EX and QFX (and 
others) interfaces were SFP+ from day 1, due to time period they were built and 
the improved technology. To get 1G to work properly in a SFP+ interface, you 
may need to disable auto-neg on that interface. It really depends upon model/SW 
and I do not know all the combinations and details. If not working as expected, 
try this.

Hopefully this helps some and can clear up some things. I am just the 
messenger, . . .

FYI only, 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




Juniper Business Use Only

On 11/3/23, 2:53 PM, "Chris Adams"  wrote:
Once upon a time, Aaron1 via juniper-nsp 
mailto:juniper-nsp@puck.nether.net>> said:
> I recall the MX204 being like that… an XE interface with a 1g speed command 
> on the interface

There it's done under "interface xe-x/y/z gigether-options".  You set
"chassis fpc x pic y port z speed 10g" first, then speed 1g in the
interface.

--
Chris Adams mailto:c...@cmadams.net>>


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

Re: [j-nsp] MX304 - Edge Router

[Richard McGovern via juniper-nsp]

#1, sorry I opened up the Women in STEM discussion, was not meant to 😂

The comment about licenses – agree 100% with what was stated.

“I'd suggest staying very close to our SE's for the desired outcome we
want for this development. As we have seen before, Juniper appear
reasonably open to operator feedback, but we would need to give it to
them to begin with.”

Could not agree more with the above!!!

Regards, 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




Juniper Business Use Only

On 10/26/23, 9:40 AM, "Mark Tinka"  wrote:
So my SE came back to me a short while ago to say that at present,
routing protocols will not be disabled if an MX304 (or some future
box/code designed for the same authorization framework) does not have
the appropriate license installed.

He did add, however, that Juniper are considering enforcing routing
protocol licenses in the future, and that he cannot say, with any
certainty, that this will not become a thing in the future.

I'd suggest staying very close to our SE's for the desired outcome we
want for this development. As we have seen before, Juniper appear
reasonably open to operator feedback, but we would need to give it to
them to begin with.

Mark.

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

Re: [j-nsp] MX304 - Edge Router

[Richard McGovern via juniper-nsp]

I tried to get my daughter (now Sr at Uni) to look at this field. Her response 
was, “I don’t want to do anything like what you do” 😩

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




Juniper Business Use Only
From: J Findley 
Date: Wednesday, October 25, 2023 at 3:00 PM
To: Richard McGovern , Michael Hare 
, Saku Ytti , Aaron1 
Cc: juniper-nsp 
Subject: RE: Re: [j-nsp] MX304 - Edge Router
[External Email. Be cautious of content]

Great time to be a network engineer



Juniper Business Use Only
From: Richard McGovern 
Sent: Wednesday, October 25, 2023 11:54 AM
To: J Findley ; Michael Hare 
; Saku Ytti ; Aaron1 
Cc: juniper-nsp 
Subject: Re: Re: [j-nsp] MX304 - Edge Router

WPI in Worcester, MA is also looking, as are [too] many others.

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




Juniper Business Use Only
From: J Findley 
mailto:jfind...@bluemountainnet.com>>
Date: Wednesday, October 25, 2023 at 2:29 PM
To: Richard McGovern mailto:rmcgov...@juniper.net>>, 
Michael Hare mailto:michael.h...@wisc.edu>>, Saku Ytti 
mailto:s...@ytti.fi>>, Aaron1 
mailto:aar...@gvtc.com>>
Cc: juniper-nsp 
mailto:juniper-nsp@puck.nether.net>>
Subject: RE: Re: [j-nsp] MX304 - Edge Router
[External Email. Be cautious of content]


We are trying to hire network engineers at Blue Mountain Networks and does 
anybody know someone looking for an opportunity. Sorry if I should not ask.


Juniper Business Use Only
-Original Message-
From: juniper-nsp 
mailto:juniper-nsp-boun...@puck.nether.net>>
 On Behalf Of Richard McGovern via juniper-nsp
Sent: Wednesday, October 25, 2023 10:59 AM
To: Michael Hare mailto:michael.h...@wisc.edu>>; Saku 
Ytti mailto:s...@ytti.fi>>; Aaron1 
mailto:aar...@gvtc.com>>
Cc: juniper-nsp 
mailto:juniper-nsp@puck.nether.net>>
Subject: Re: [j-nsp] MX304 - Edge Router

A great story for the power of Apstra [in the DC], which is also multi-vendor!!

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




Juniper Business Use Only

On 10/25/23, 12:48 PM, "Michael Hare" 
mailto:michael.h...@wisc.edu>> wrote:
Re: "In your specific case, the ports never worked, you had to procure a 
license, and the license never dies."

Here's a cool story.  At some point I migrated the perpetual 10G FPC2 SFP+ port 
license on our MX104s from the "request system license add" mantra to "set 
system license" so it was more easily manageable in the config.  The migration 
worked fine in the lab.  I was making the change in production batch using 
automation, using the model of "commit confirmed" followed in a bit with a 
"commit check".  I pushed a set of "commit confirmed" out and got distracted 
by.. something.  I missed the commit check.  The config rolled back, but guess 
what didn't roll back?  The "request system license add".  The SFP+ shut off.  
No truck rolls were needed but it did create a needless outage for some.  Going 
back to Saku's comment about SSL certs; never underestimate a human's ability 
to fail.

-Michael

> -Original Message-
> From: juniper-nsp
> mailto:juniper-nsp-bounces@puck.n
<mailto:juniper-nsp-boun...@puck.nether.net%3cmailto:juniper-nsp-bounces@puck.n%0b>>
 ether.net>> On Behalf Of Saku Ytti via juniper-nsp
> Sent: Wednesday, October 25, 2023 7:43 AM
> To: Aaron1 
> mailto:aar...@gvtc.com<mailto:aar...@gvtc.com%3cmailto:aar...@gvtc.com>>>
> Cc: juniper-nsp
> mailto:juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net%3cmailto:juniper-nsp@puck.nether.net>>>
> Subject: Re: [j-nsp] MX304 - Edge Router
>
> On Wed, 25 Oct 2023 at 15:26, Aaron1 via juniper-nsp
> mailto:juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net%3cmailto:juniper-nsp@puck.nether.net>>>
>  wrote:
>
> > Years ago I had to get a license to make my 10g interfaces work on
> > my
> MX104
>
> I think we need to be careful in what we are saying.
>
> We can't reject licences out right, that's not a fair ask and it won't happen.
>
> But we can reject licenses that expire in operation and cause an
> outage. That I think is a very reasonable ask.  I know that IOS XE for
> example will do this, you run out of license and your box breaks. I
> swapped out from CRS1k to ASR1k because I knew the organisation would
> eventually fail to fix the license ahead of expiry.
>
> I'm happy if the device calls homes via https proxy, an

Re: [j-nsp] MX304 - Edge Router

[Richard McGovern via juniper-nsp]

You should not need a license for MOST features to work, for example L3 
Routing, EVPN, etc. It depend a little on the exact platform and 
feature/function. MACSec is one where you “may” need a license to activate, to 
test/etc. In general, currently licenses are not required for most features to 
function or to be used for testing. In case of testing, Trial/Demo licenses can 
be cut easily.

Just FYI, 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




Juniper Business Use Only

On 10/25/23, 2:38 PM, "Ola Thoresen"  wrote:
On 25.10.2023 19:20, Richard McGovern via juniper-nsp wrote:

> Crist, not quite 100% accurate. Perpetual License are permeant and last 
> forever, but with newer Flex License structure also require a SW Support 
> Contract. Subscription based licenses of course expire at end of the 
> subscription date, but do include SW Support.
>
> Trial and Demo licenses always come with end date, usually 60-90 days in the 
> future. I am not 100% sure about expiration for Lab Licenses.

But the main issue here was whether the licenses are trust based or not.

Which means that even _without_ a license, an MX304 should be able to do
almost anything that requires a license (except bng, macsec and possibly
a few other special use cases) - although it would cause nagging in the
logs and when committing.

I think this was cleared up earlier, that the OP probably experienced
some other bug.

That is what's important for us. That functions don't stop working if a
subscription license expires, and that you can try out a feature without
buying a license first.


/Ola (T)


> FYI Only, 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
>
>
>
>
> Juniper Business Use Only
>
> On 10/25/23, 11:02 AM, "Crist Clark" 
> mailto:cjc+j-...@pumpky.net>> wrote:
> I think the key here is that the OP had evaluation licenses. Those are
> timed and things stop working when they expire. Purchased license are
> permanent and do not expire.
>
> On Wed, Oct 25, 2023 at 6:18 AM Mark Tinka via juniper-nsp <
> juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net><mailto:juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>>>
>  wrote:
>
>>
>> On 10/25/23 14:42, Saku Ytti via juniper-nsp wrote:
>>
>>> But we can reject licenses that expire in operation and cause an
>>> outage. That I think is a very reasonable ask.  I know that IOS XE for
>>> example will do this, you run out of license and your box breaks. I
>>> swapped out from CRS1k to ASR1k because I knew the organisation would
>>> eventually fail to fix the license ahead of expiry.
>> We had this happen to us in 2014 when we recovered a failed server
>> running CSR1000v. The "installation evaluation" license expired after 60
>> days, and since everyone forgot about it, the box went down.
>>
>> So as part of our deployment/recovery procedure, we always procure
>> CSR1000v licenses for each installation.
>>
>> Of course, with things changing to Cat8000v, this could get juicy.
>>
>>
>>> I'm happy if the device calls homes via https proxy, and reports my
>>> license use, and the sales droid tells me I'm not compliant with
>>> terms. Making it a commercial problem is fine, making it an acute
>>> technical problem is not.
>>>
>>>
>>> In your specific case, the ports never worked, you had to procure a
>>> license, and the license never dies. So from my POV, this is fine. And
>>> being absolutist here will not help, as then you can't even achieve
>>> reasonable compromise.
>> I tend to agree.
>>
>> Mark.
>> ___
>> juniper-nsp mailing list 
>> juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net><mailto:juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>>
>> https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!FzL92c-5uCwqrJhu0-QvKEMdS-Z2V2LBDoMIpEp3V-HsTI0CkWW3zc0jzZyDrfa2xzUObBrBBPokCA5uOFi2Mx3YQGF2pQRt$<https://urldefense.com/v3/__https:/puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!FzL92c-5uCwqrJhu0-QvKEMdS-Z2V2LBDoMIpEp3V-HsTI0CkWW3zc0jzZyDrfa2xzUObBrBBPokCA5uOFi2Mx3YQGF2pQRt$><https://urldefense.com/v3/__https:/puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!FzL92c-5uCwqrJhu0-QvKEMdS-Z2V2LBDoMIpEp3V-HsTI0CkWW3zc0jzZyDrfa2xzUOb

Re: [j-nsp] MX304 - Edge Router

[Richard McGovern via juniper-nsp]

WPI in Worcester, MA is also looking, as are [too] many others.

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




Juniper Business Use Only
From: J Findley 
Date: Wednesday, October 25, 2023 at 2:29 PM
To: Richard McGovern , Michael Hare 
, Saku Ytti , Aaron1 
Cc: juniper-nsp 
Subject: RE: Re: [j-nsp] MX304 - Edge Router
[External Email. Be cautious of content]


We are trying to hire network engineers at Blue Mountain Networks and does 
anybody know someone looking for an opportunity. Sorry if I should not ask.


Juniper Business Use Only
-Original Message-
From: juniper-nsp  On Behalf Of Richard 
McGovern via juniper-nsp
Sent: Wednesday, October 25, 2023 10:59 AM
To: Michael Hare ; Saku Ytti ; Aaron1 

Cc: juniper-nsp 
Subject: Re: [j-nsp] MX304 - Edge Router

A great story for the power of Apstra [in the DC], which is also multi-vendor!!

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




Juniper Business Use Only

On 10/25/23, 12:48 PM, "Michael Hare"  wrote:
Re: "In your specific case, the ports never worked, you had to procure a 
license, and the license never dies."

Here's a cool story.  At some point I migrated the perpetual 10G FPC2 SFP+ port 
license on our MX104s from the "request system license add" mantra to "set 
system license" so it was more easily manageable in the config.  The migration 
worked fine in the lab.  I was making the change in production batch using 
automation, using the model of "commit confirmed" followed in a bit with a 
"commit check".  I pushed a set of "commit confirmed" out and got distracted 
by.. something.  I missed the commit check.  The config rolled back, but guess 
what didn't roll back?  The "request system license add".  The SFP+ shut off.  
No truck rolls were needed but it did create a needless outage for some.  Going 
back to Saku's comment about SSL certs; never underestimate a human's ability 
to fail.

-Michael

> -Original Message-
> From: juniper-nsp
> mailto:juniper-nsp-bounces@puck.n
> ether.net>> On Behalf Of Saku Ytti via juniper-nsp
> Sent: Wednesday, October 25, 2023 7:43 AM
> To: Aaron1 mailto:aar...@gvtc.com>>
> Cc: juniper-nsp
> mailto:juniper-nsp@puck.nether.net>>
> Subject: Re: [j-nsp] MX304 - Edge Router
>
> On Wed, 25 Oct 2023 at 15:26, Aaron1 via juniper-nsp
> mailto:juniper-nsp@puck.nether.net>> wrote:
>
> > Years ago I had to get a license to make my 10g interfaces work on
> > my
> MX104
>
> I think we need to be careful in what we are saying.
>
> We can't reject licences out right, that's not a fair ask and it won't happen.
>
> But we can reject licenses that expire in operation and cause an
> outage. That I think is a very reasonable ask.  I know that IOS XE for
> example will do this, you run out of license and your box breaks. I
> swapped out from CRS1k to ASR1k because I knew the organisation would
> eventually fail to fix the license ahead of expiry.
>
> I'm happy if the device calls homes via https proxy, and reports my
> license use, and the sales droid tells me I'm not compliant with
> terms. Making it a commercial problem is fine, making it an acute
> technical problem is not.
>
>
> In your specific case, the ports never worked, you had to procure a
> license, and the license never dies. So from my POV, this is fine. And
> being absolutist here will not help, as then you can't even achieve
> reasonable compromise.
>
> --
>   ++ytti
> ___
> juniper-nsp mailing list
> juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>
> https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/j<https://urldefense.com/v3/__https:/puck.nether.net/mailman/listinfo/j>
> uniper-nsp__;!!NEt6yMaO-gk!FzL92c-5uCwqrJhu0-QvKEMdS-Z2V2LBDoMIpEp3V-H
> sTI0CkWW3zc0jzZyDrfa2xzUObBrBBPokCA5uOFi2Mx3YQGF2pQRt$<https://urldefense.com/v3/__https://urldefe__;!!NEt6yMaO-gk!AmH_FePIAzznfciwJBbAS3_O-47PXK8uQ5b2RDzTX3PVEX5iBOE0hj-AWq6hIq20dgEiMreMDjQJ26UJnD5V3vcSCH0$
> nse.com/v3/__https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!N__;!!NEt6yMaO-gk!AmH_FePIAzznfciwJBbAS3_O-47PXK8uQ5b2RDzTX3PVEX5iBOE0hj-AWq6hIq20dgEiMreMDjQJ26UJnD5V5FSQqjc$
> Et6yMaO-gk!FzL92c-5uCwqrJhu0-QvKEMdS-Z2V2LBDoMIpEp3V-HsTI0CkWW3zc0jzZy
> Drfa2xzUObBrBBPokCA5uOFi2Mx3YQGF2pQRt$>


___
juniper-nsp mailing list juniper-nsp@puck.nether.net 
https

Re: [j-nsp] MX304 - Edge Router

[Richard McGovern via juniper-nsp]

A great story for the power of Apstra [in the DC], which is also multi-vendor!!

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




Juniper Business Use Only

On 10/25/23, 12:48 PM, "Michael Hare"  wrote:
Re: "In your specific case, the ports never worked, you had to procure a 
license, and the license never dies."

Here's a cool story.  At some point I migrated the perpetual 10G FPC2 SFP+ port 
license on our MX104s from the "request system license add" mantra to "set 
system license" so it was more easily manageable in the config.  The migration 
worked fine in the lab.  I was making the change in production batch using 
automation, using the model of "commit confirmed" followed in a bit with a 
"commit check".  I pushed a set of "commit confirmed" out and got distracted 
by.. something.  I missed the commit check.  The config rolled back, but guess 
what didn't roll back?  The "request system license add".  The SFP+ shut off.  
No truck rolls were needed but it did create a needless outage for some.  Going 
back to Saku's comment about SSL certs; never underestimate a human's ability 
to fail.

-Michael

> -Original Message-
> From: juniper-nsp 
> mailto:juniper-nsp-boun...@puck.nether.net>>
>  On Behalf Of
> Saku Ytti via juniper-nsp
> Sent: Wednesday, October 25, 2023 7:43 AM
> To: Aaron1 mailto:aar...@gvtc.com>>
> Cc: juniper-nsp 
> mailto:juniper-nsp@puck.nether.net>>
> Subject: Re: [j-nsp] MX304 - Edge Router
>
> On Wed, 25 Oct 2023 at 15:26, Aaron1 via juniper-nsp
> mailto:juniper-nsp@puck.nether.net>> wrote:
>
> > Years ago I had to get a license to make my 10g interfaces work on my
> MX104
>
> I think we need to be careful in what we are saying.
>
> We can't reject licences out right, that's not a fair ask and it won't happen.
>
> But we can reject licenses that expire in operation and cause an
> outage. That I think is a very reasonable ask.  I know that IOS XE for
> example will do this, you run out of license and your box breaks. I
> swapped out from CRS1k to ASR1k because I knew the organisation would
> eventually fail to fix the license ahead of expiry.
>
> I'm happy if the device calls homes via https proxy, and reports my
> license use, and the sales droid tells me I'm not compliant with
> terms. Making it a commercial problem is fine, making it an acute
> technical problem is not.
>
>
> In your specific case, the ports never worked, you had to procure a
> license, and the license never dies. So from my POV, this is fine. And
> being absolutist here will not help, as then you can't even achieve
> reasonable compromise.
>
> --
>   ++ytti
> ___
> juniper-nsp mailing list 
> juniper-nsp@puck.nether.net
> https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!FzL92c-5uCwqrJhu0-QvKEMdS-Z2V2LBDoMIpEp3V-HsTI0CkWW3zc0jzZyDrfa2xzUObBrBBPokCA5uOFi2Mx3YQGF2pQRt$


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

Re: [j-nsp] MX304 - Edge Router

[Richard McGovern via juniper-nsp]

Crist, not quite 100% accurate. Perpetual License are permeant and last 
forever, but with newer Flex License structure also require a SW Support 
Contract. Subscription based licenses of course expire at end of the 
subscription date, but do include SW Support.

Trial and Demo licenses always come with end date, usually 60-90 days in the 
future. I am not 100% sure about expiration for Lab Licenses.

FYI Only, 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




Juniper Business Use Only

On 10/25/23, 11:02 AM, "Crist Clark"  wrote:
I think the key here is that the OP had evaluation licenses. Those are
timed and things stop working when they expire. Purchased license are
permanent and do not expire.

On Wed, Oct 25, 2023 at 6:18 AM Mark Tinka via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

>
>
> On 10/25/23 14:42, Saku Ytti via juniper-nsp wrote:
>
> > But we can reject licenses that expire in operation and cause an
> > outage. That I think is a very reasonable ask.  I know that IOS XE for
> > example will do this, you run out of license and your box breaks. I
> > swapped out from CRS1k to ASR1k because I knew the organisation would
> > eventually fail to fix the license ahead of expiry.
>
> We had this happen to us in 2014 when we recovered a failed server
> running CSR1000v. The "installation evaluation" license expired after 60
> days, and since everyone forgot about it, the box went down.
>
> So as part of our deployment/recovery procedure, we always procure
> CSR1000v licenses for each installation.
>
> Of course, with things changing to Cat8000v, this could get juicy.
>
>
> > I'm happy if the device calls homes via https proxy, and reports my
> > license use, and the sales droid tells me I'm not compliant with
> > terms. Making it a commercial problem is fine, making it an acute
> > technical problem is not.
> >
> >
> > In your specific case, the ports never worked, you had to procure a
> > license, and the license never dies. So from my POV, this is fine. And
> > being absolutist here will not help, as then you can't even achieve
> > reasonable compromise.
>
> I tend to agree.
>
> Mark.
> ___
> juniper-nsp mailing list 
> juniper-nsp@puck.nether.net
> https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!FzL92c-5uCwqrJhu0-QvKEMdS-Z2V2LBDoMIpEp3V-HsTI0CkWW3zc0jzZyDrfa2xzUObBrBBPokCA5uOFi2Mx3YQGF2pQRt$
>
>


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

Re: [j-nsp] MX304 - Edge Router

[Richard McGovern via juniper-nsp]

I agree with your view 100%, but that sort of decision is well above my pay 
grade. I’d say yes to sort of match EX/QFX/etc. Also see the last line in my 
signature 😂

Purchasing a new MX without some license, is basically purchasing a boat 
anchor! Within Juniper Configurator tool, you can actually NOT create a BOM or 
quote, unless some license is associated with the HW.

Regards, 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




Juniper Business Use Only
From: Michael Hare 
Date: Wednesday, October 25, 2023 at 12:53 PM
To: Richard McGovern , Saku Ytti , Aaron 
Gould 
Cc: Karl Gerhard , juniper-nsp@puck.nether.net 

Subject: RE: Re: [j-nsp] MX304 - Edge Router
[External Email. Be cautious of content]


Richard-

Sorry if this is off topic, but what's the use case for Base license on an MX?  
 Is it just to align the name of the licensing with EX and the ilk?  Are there 
significant customers using hardware as whitebox?  We've been Juniper customer 
since the m40 days and always routed with them.  Thoughts and feelings aside 
about price and licensing management aside, I always found it curious that 
someone would purchase an MX and not need even static routing.  Our ASNs ended 
up in the "Advanced" bucket, which was essentially equivalent for us to the old 
"base".

-Michael

> -Original Message-
> From: juniper-nsp  On Behalf Of
> Richard McGovern via juniper-nsp
> Sent: Wednesday, October 25, 2023 7:51 AM
> To: Saku Ytti ; Aaron Gould 
> Cc: Karl Gerhard ; juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] MX304 - Edge Router
>
> Aaron, what version of Junos are you using on your MX304? This should NOT
> happen and if it did/is, then I suggest you open a Case with JTAC. Minimally
> your account team should be able to get you a temp license to work-around
> this until resolved.
>
> The introduction of newer (well now like 2 years old) Flex licensing all newly
> purchased MX (which would include ALL MX304s) support only L2 in the base
> (free) license. For any L3 (even static) you require some additional level of
> license. For MX those levels are Base/Advanced/Premium -
> https://www.juniper.net/documentation/us/en/software/license/flex/flex-
> license-for-mx-series-routers-and-mpc-service-cards.pdf. Your local Partner or
> Juniper Sales team should be able to help with any questions in this area.
>
> Flex License can be purchased on a Subscription (yearly) basis or Perpetual
> (matches older style) – this is similar/same for almost all vendors in current
> times.
>
> Most (but not ALL!) Juniper license are currently “honor” based. This means
> features that require a license will NOT be turned off if the license is not
> present. Instead warning/error messages will be shown, which will [obviously]
> fill up your logs quickly 😂 MACSec maybe one of those licenses which are
> NOT “honor” based; there are others as well. Of course, Perpetual licenses
> never expire 👍 Subscription licenses have a built-in ‘safety zone’ of
> approximately 30 days after the subscription date expires. This is to provide
> time for renewal of the subscription for those that “forget” 😩
>
> If you have an older subscription license which is no longer valid under newer
> Flex license structure, at renewal the license will automatically be 
> converted by
> Juniper internal renewals team to the new Flex license SKU, at same price as
> the older SKU, if there is a price [increase] difference.
>
> One big advantage of the new Flex license structure is that these licenses are
> transferable. That is, these licenses are not permanently tied to a single 
> device
> SN. This also includes Perpetual Flex Licenses. In the Juniper Agile License 
> Portal
> (https://license.juniper.net/licensemanage/) where one turns a License SKU
> [Entitlement] into a Activation [code] which then is used to create the actual
> loadable license. Here one MUST associate the License with a SN, but that
> License can then be re-called (changed from Activation back to Entitlement)
> and then that Entitlement can be associated with a new SN. The license on the
> old SN is no longer valid.
>
> As for current checks, Juniper is covered by EULA – End User License
> Agreement. In the future Juniper can (and is likely to) add additional
> enforcement checks into their SW – Just an FYI.
>
> FYI only, 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
>
>
>
>
> Juniper Business Use Only
>

Juniper Business Use Only
> On 10/25/23, 2:01 AM, "Saku Ytti" 

Re: [j-nsp] MX304 - Edge Router

[Richard McGovern via juniper-nsp]

No problem. Just FYI, but “Flex License” is often mis-understood within 
Juniper, never mind outside 😭

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




Juniper Business Use Only
From: Aaron1 
Date: Wednesday, October 25, 2023 at 10:07 AM
To: Richard McGovern 
Cc: Saku Ytti , Karl Gerhard , 
juniper-nsp@puck.nether.net , beec...@beecher.cc 

Subject: Re: [j-nsp] MX304 - Edge Router
[External Email. Be cautious of content]

Thanks Richard… et al, I’ll have to go back to my account team and learn more 
about MX304 licensing… from your link, it appears that I have an Advanced 
license and furthermore, of trial duration.  Yes, they have already reissued me 
a new trial one for an additional 60 days.  To Mark’s point, at the moment, I’m 
tshooting to determine if I have another problem.
Aaron


On Oct 25, 2023, at 7:50 AM, Richard McGovern  wrote:

Aaron, what version of Junos are you using on your MX304? This should NOT 
happen and if it did/is, then I suggest you open a Case with JTAC. Minimally 
your account team should be able to get you a temp license to work-around this 
until resolved.

The introduction of newer (well now like 2 years old) Flex licensing all newly 
purchased MX (which would include ALL MX304s) support only L2 in the base 
(free) license. For any L3 (even static) you require some additional level of 
license. For MX those levels are Base/Advanced/Premium - 
https://www.juniper.net/documentation/us/en/software/license/flex/flex-license-for-mx-series-routers-and-mpc-service-cards.pdf.
 Your local Partner or Juniper Sales team should be able to help with any 
questions in this area.

Flex License can be purchased on a Subscription (yearly) basis or Perpetual 
(matches older style) – this is similar/same for almost all vendors in current 
times.

Most (but not ALL!) Juniper license are currently “honor” based. This means 
features that require a license will NOT be turned off if the license is not 
present. Instead warning/error messages will be shown, which will [obviously] 
fill up your logs quickly 😂 MACSec maybe one of those licenses which are NOT 
“honor” based; there are others as well. Of course, Perpetual licenses never 
expire 👍 Subscription licenses have a built-in ‘safety zone’ of approximately 
30 days after the subscription date expires. This is to provide time for 
renewal of the subscription for those that “forget” 😩

If you have an older subscription license which is no longer valid under newer 
Flex license structure, at renewal the license will automatically be converted 
by Juniper internal renewals team to the new Flex license SKU, at same price as 
the older SKU, if there is a price [increase] difference.

One big advantage of the new Flex license structure is that these licenses are 
transferable. That is, these licenses are not permanently tied to a single 
device SN. This also includes Perpetual Flex Licenses. In the Juniper Agile 
License Portal (https://license.juniper.net/licensemanage/) where one turns a 
License SKU [Entitlement] into a Activation [code] which then is used to create 
the actual loadable license. Here one MUST associate the License with a SN, but 
that License can then be re-called (changed from Activation back to 
Entitlement) and then that Entitlement can be associated with a new SN. The 
license on the old SN is no longer valid.

As for current checks, Juniper is covered by EULA – End User License Agreement. 
In the future Juniper can (and is likely to) add additional enforcement checks 
into their SW – Just an FYI.

FYI only, 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




Juniper Business Use Only
On 10/25/23, 2:01 AM, "Saku Ytti"  wrote:
On Tue, 24 Oct 2023 at 22:21, Aaron Gould via juniper-nsp
mailto:juniper-nsp@puck.nether.net>> wrote:

> My MX304 trial license expired last night, after rebooting the MX304,
> various protocols no longer work.  This seems more than just
> honor-based... ospf, ldp, etc, no longer function.  This is new to me;
> that Juniper is making protocols and technologies tied to license.  I
> need to understand more about this, as I'm considering buying MX304's.

Juniper had assured me multiple times that they strategically have
decided to NEVER do this. That it's an actual decision they've
considered at the highest level, that they will not downgrade devices
in operation. I guess 'reboot' is not in-operation?

Notion that operators are able to keep licenses up-to-date and valid
is naive, we can't keep SSL certificates valid and we've had decades
of time to learn, it won't happen. You will learn about the problem,
when shit breaks.

The right solution would be a phone-home, and a vendor sales rep
calling you 'hey you have expired licenses, let's solve this'. Not
breaking the boxes.

Re: [j-nsp] MX304 - Edge Router

[Richard McGovern via juniper-nsp]

Aaron, what version of Junos are you using on your MX304? This should NOT 
happen and if it did/is, then I suggest you open a Case with JTAC. Minimally 
your account team should be able to get you a temp license to work-around this 
until resolved.

The introduction of newer (well now like 2 years old) Flex licensing all newly 
purchased MX (which would include ALL MX304s) support only L2 in the base 
(free) license. For any L3 (even static) you require some additional level of 
license. For MX those levels are Base/Advanced/Premium - 
https://www.juniper.net/documentation/us/en/software/license/flex/flex-license-for-mx-series-routers-and-mpc-service-cards.pdf.
 Your local Partner or Juniper Sales team should be able to help with any 
questions in this area.

Flex License can be purchased on a Subscription (yearly) basis or Perpetual 
(matches older style) – this is similar/same for almost all vendors in current 
times.

Most (but not ALL!) Juniper license are currently “honor” based. This means 
features that require a license will NOT be turned off if the license is not 
present. Instead warning/error messages will be shown, which will [obviously] 
fill up your logs quickly 😂 MACSec maybe one of those licenses which are NOT 
“honor” based; there are others as well. Of course, Perpetual licenses never 
expire 👍 Subscription licenses have a built-in ‘safety zone’ of approximately 
30 days after the subscription date expires. This is to provide time for 
renewal of the subscription for those that “forget” 😩

If you have an older subscription license which is no longer valid under newer 
Flex license structure, at renewal the license will automatically be converted 
by Juniper internal renewals team to the new Flex license SKU, at same price as 
the older SKU, if there is a price [increase] difference.

One big advantage of the new Flex license structure is that these licenses are 
transferable. That is, these licenses are not permanently tied to a single 
device SN. This also includes Perpetual Flex Licenses. In the Juniper Agile 
License Portal (https://license.juniper.net/licensemanage/) where one turns a 
License SKU [Entitlement] into a Activation [code] which then is used to create 
the actual loadable license. Here one MUST associate the License with a SN, but 
that License can then be re-called (changed from Activation back to 
Entitlement) and then that Entitlement can be associated with a new SN. The 
license on the old SN is no longer valid.

As for current checks, Juniper is covered by EULA – End User License Agreement. 
In the future Juniper can (and is likely to) add additional enforcement checks 
into their SW – Just an FYI.

FYI only, 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




Juniper Business Use Only

On 10/25/23, 2:01 AM, "Saku Ytti"  wrote:
On Tue, 24 Oct 2023 at 22:21, Aaron Gould via juniper-nsp
mailto:juniper-nsp@puck.nether.net>> wrote:

> My MX304 trial license expired last night, after rebooting the MX304,
> various protocols no longer work.  This seems more than just
> honor-based... ospf, ldp, etc, no longer function.  This is new to me;
> that Juniper is making protocols and technologies tied to license.  I
> need to understand more about this, as I'm considering buying MX304's.

Juniper had assured me multiple times that they strategically have
decided to NEVER do this. That it's an actual decision they've
considered at the highest level, that they will not downgrade devices
in operation. I guess 'reboot' is not in-operation?

Notion that operators are able to keep licenses up-to-date and valid
is naive, we can't keep SSL certificates valid and we've had decades
of time to learn, it won't happen. You will learn about the problem,
when shit breaks.

The right solution would be a phone-home, and a vendor sales rep
calling you 'hey you have expired licenses, let's solve this'. Not
breaking the boxes. Or 'your phone home hasn't worked, you need to fix
it before we can re-up your support contract'.
--
  ++ytti


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

Re: [j-nsp] Configuring of MACsec for three EX4300 Switches

[Richard McGovern via juniper-nsp]

--- Begin Message ---
Thanks for the clarification. I don’t pretend to know the spec in detail, just 
how most of Juniper functions. I know for EX products running MACsec, some sort 
of tunnel needs to be present in an intermediate switch to work. This is often 
why MACsec over provider network most often will not work. Generally dark fiber 
is required.

Been looking for a solution for intermediate switch(es).

Thanks

Sent from my iPhone

On Nov 6, 2020, at 1:25 AM, Crist Clark  wrote:



[External Email. Be cautious of content]


MACsec (802.1AE) is NOT limited to point-to-point connections.

However, many vendors have partial implementations which do have such 
limitations. Juniper devices' support varies greatly by hardware platform and 
software versions.

On Thu, Nov 5, 2020 at 8:06 AM Richard McGovern via juniper-nsp 
mailto:juniper-nsp@puck.nether.net>> wrote:



-- Forwarded message --
From: Richard McGovern mailto:rmcgov...@juniper.net>>
To: "switch...@tutanota.com<mailto:switch...@tutanota.com>" 
mailto:switch...@tutanota.com>>
Cc: "juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>" 
mailto:juniper-nsp@puck.nether.net>>
Bcc:
Date: Thu, 5 Nov 2020 16:05:20 +
Subject: Re: Configuring of MACsec for three EX4300 Switches
MACSEC is pt-to-pt so is your plan to run MACSEC from Point A to EX4300 and 
then connect same EX4300 to Point B - two different and independent MACSEC 
connections?

If you want pass-through of one session you will need to create some sort of 
tunnel between EX port A to port B -(internal  maybe GRE 'might' work.  This is 
not like say IPSec connections.

Good luck.  Please reply if you find a solution.

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 11/5/20, 6:09 AM, "switch...@tutanota.com<mailto:switch...@tutanota.com>" 
mailto:switch...@tutanota.com>> wrote:

Hi,

following only the required configuration of

https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/macsec-configuring-mx-series.html
for
# Configuring MACsec Using Static Connectivity Association Key (CAK) Mode

works fine for two switches, but with a third EX4300 in the middle not.

Thus, could anyone please help what is required to ensure connectivity 
through
three EX4300?

Even the configuration (A; with several tries) on the outer sides switches 
such as
e.g. given for (one port) per switch
jack@cs2# set security macsec connectivity-association ca1 mka 
eapol-address provider-bridge
jack@cs2# set security macsec connectivity-association ca1 mka 
eapol-address lldp-multicast
jack@cs2# set protocols layer2-control mac-rewrite interface ge-0/0/13 
protocol ieee8021
worked not for the three EX4300.

Tunneling through a EX4200, in the middle (via vlan, snippet see below) 
worked fine, even without the
configuration (A) at the outer sides switches, only with the most important 
commands
given in 
https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/macsec-configuring-mx-series.html.

Any idea why tunneling through the middle EX4300 failed? (Used version: 
17.3R3-S9.3!)

Regards,
Jack


# PS: What is the equivalent code for EX4300 from the EX4200 code
   vlan-id 55;
   dot1q-tunneling {
   layer2-protocol-tunneling {
   all;
       }



Juniper Business Use Only



-- Forwarded message --
From: Richard McGovern via juniper-nsp 
mailto:juniper-nsp@puck.nether.net>>
To: "switch...@tutanota.com<mailto:switch...@tutanota.com>" 
mailto:switch...@tutanota.com>>
Cc:
Bcc:
Date: Thu, 5 Nov 2020 16:05:20 +
Subject: Re: [j-nsp] Configuring of MACsec for three EX4300 Switches
___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp<https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!TBPbxaxjBGsKYU4uKjxPqQpgIOJAXz1rVO5sr5Wa-2g_kI62bxJMe9LEDPQlpMG_Uw$>
--- End Message ---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Configuring of MACsec for three EX4300 Switches

[Richard McGovern via juniper-nsp]

--- Begin Message ---
MACSEC is pt-to-pt so is your plan to run MACSEC from Point A to EX4300 and 
then connect same EX4300 to Point B - two different and independent MACSEC 
connections?

If you want pass-through of one session you will need to create some sort of 
tunnel between EX port A to port B -(internal  maybe GRE 'might' work.  This is 
not like say IPSec connections.

Good luck.  Please reply if you find a solution.

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 11/5/20, 6:09 AM, "switch...@tutanota.com"  wrote:

Hi,

following only the required configuration of

https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/macsec-configuring-mx-series.html
for
# Configuring MACsec Using Static Connectivity Association Key (CAK) Mode

works fine for two switches, but with a third EX4300 in the middle not.

Thus, could anyone please help what is required to ensure connectivity 
through
three EX4300?

Even the configuration (A; with several tries) on the outer sides switches 
such as
e.g. given for (one port) per switch
jack@cs2# set security macsec connectivity-association ca1 mka 
eapol-address provider-bridge
jack@cs2# set security macsec connectivity-association ca1 mka 
eapol-address lldp-multicast
jack@cs2# set protocols layer2-control mac-rewrite interface ge-0/0/13 
protocol ieee8021
worked not for the three EX4300.

Tunneling through a EX4200, in the middle (via vlan, snippet see below) 
worked fine, even without the
configuration (A) at the outer sides switches, only with the most important 
commands
given in 
https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/macsec-configuring-mx-series.html.

Any idea why tunneling through the middle EX4300 failed? (Used version: 
17.3R3-S9.3!)

Regards,
Jack


# PS: What is the equivalent code for EX4300 from the EX4200 code
   vlan-id 55;
   dot1q-tunneling {
   layer2-protocol-tunneling {
   all;
   }



Juniper Business Use Only
--- End Message ---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Junos OS Evolved

[Richard McGovern via juniper-nsp]

--- Begin Message ---
I am thinking (guessing) you will not see EVO on MX for some time.  EVO is 
mainly targeted at Data Center use cases, for which MX is used for DC to DC 
connectivity, but not as a main stay within any DC.

My 2 cents worth.

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 10/11/20, 6:26 AM, "Saku Ytti"  wrote:

On Sun, 11 Oct 2020 at 00:24, Colton Conor  wrote:

> So is Junos OS Evolved available for the MX routers? How would you go 
from regular Junos to Junos OS Evolved on a MX 240/480/960 for example?

It is not, but expect to see it in future MX REs.



--
  ++ytti



Juniper Business Use Only
--- End Message ---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX204 port 1G

[Richard McGovern via juniper-nsp]

--- Begin Message ---
Sorry should have been clearer.  When I said SRX/MX this for HE SRX only, not 
branch (either 2xx or 3xx) and older mid-range; SRX4xxx shows as -xe only.

This is also ONLY for interfaces that support 1/10, not 1 GE only.  Older MX 
interfaces were either 1GE or 10GE only, not 1/10 (SFP+).  Newer MX modules 
with 1/10 support shows as -xe only.

Hopefully this is clearer.

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 10/9/20, 4:55 PM, "aar...@gvtc.com"  wrote:

[External Email. Be cautious of content]


i see ge interfaces in my SRX300 and older SRX240... also I'm pretty sure 
legacy MX use ge for 1 gig inerfaces, and perhaps it's just those newer 
MX204/10003 that don't.

user1@my-srx> show version
Hostname: my-srx
Model: srx300
Junos: 15.1X49-D170.4
JUNOS Software Release [15.1X49-D170.4]

user1@my-srx> show interfaces terse
Interface   Admin Link ProtoLocal Remote
ge-0/0/0upup
ge-0/0/0.0  upup   eth-switch

user1@my-srx240> show version
Hostname: my-srx240
Model: srx240h
JUNOS Software Release [12.1X46-D40.2]

user1@my-srx240> show interfaces terse | grep ^ge
ge-0/0/0upup
ge-0/0/0.0  upup
ge-0/0/1updown
ge-0/0/1.0  updown eth-switch


-Aaron




Juniper Business Use Only
--- End Message ---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX204 port 1G

[Richard McGovern via juniper-nsp]

--- Begin Message ---
Thanks.  So only SRX/MX use xe only for 1/10 capable interfaces.  40/100 are et.

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 10/9/20, 1:08 PM, "aar...@gvtc.com"  wrote:

[External Email. Be cautious of content]


? " For MX/SRX (and I assume PTX and maybe ACX - don't much deal with those 
products ) xe is ONLY name allowed" ?

I see otherwise...

MX... MPC7E-MRATE (however et is the name for 40 gig and 100 gig) xe is 
also used, but with colon notation)
Physical interface: xe-0/1/5:3, Enabled, Physical link is Down
  Link-level type: Ethernet, MTU: 1514, MRU: 1522, LAN-PHY mode, Speed: 
10Gbps, BPDU Error: None, Loop Detect PDU Error: None,

Physical interface: et-1/0/0, Enabled, Physical link is Up
  Link-level type: Flexible-Ethernet, MTU: 9216, MRU: 9224, Speed: 40Gbps, 
BPDU Error: None, Loop Detect PDU Error: None,

Physical interface: et-1/0/2, Enabled, Physical link is Down
  Link-level type: Ethernet, MTU: 1514, MRU: 1522, Speed: 100Gbps, BPDU 
Error: None, Loop Detect PDU Error: None,



ACX has ge, ex, and et (got 1, 10 and 40 gig)
user1@my5048> show system information
Model: acx5048
Family: junos
Junos: 17.4R2-S11
Hostname: my5048
...
ge-0/0/10   upup
ge-0/0/10.0 upup   inet 10.101.14.197/30
xe-0/0/25   upup
xe-0/0/25.0 upup   aenet--> ae5.0
et-0/0/48   upup
et-0/0/48.0 upup   aenet--> ae42.0


-Aaron




Juniper Business Use Only
--- End Message ---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Junos OS Evolved

[Richard McGovern via juniper-nsp]

--- Begin Message ---
I think QFX5200-32C (and some PTX?) are only platforms that have support for 
both a Junos version and an EVO version.  I think once [very hard if not 
impossible] to change.

FYI only

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 10/9/20, 12:38 PM, "Saku Ytti"  wrote:

Hey Colton,

> I was unaware of Junos OS Evolved until recently. At what version did
> regular Junos evolve into Junos OS Evolved? Is there a certain version
> where after that version, everything ongoing is Junos OS Evolved?

I think EVO appeared in 19.1, but in most cases you don't have a
choice, you either install classic or you install evo.  New platforms
already only have EVO options and older platforms only have classic
options.

--
  ++ytti



Juniper Business Use Only
--- End Message ---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX204 port 1G

[Richard McGovern via juniper-nsp]

--- Begin Message ---
If link is up, not L1 (speed negotiation) issue.  What do you get for output of 
show interface xe-0/1/4 extensive?

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 10/9/20, 10:25 AM, "Łukasz Trąbiński"  wrote:


I tried to play with almost all options in gigether-options section without 
any results. Port is UP but it still not working properly.

admin@mx1> show configuration interfaces xe-0/1/4
description TEST;
gigether-options {
no-flow-control;
no-auto-negotiation;
speed 1g;
}
unit 0 {
family inet {
address xx.xx.xx.xx/30;
}
}

When i removed "speed 10g" from chassis section and bounced FPC port was 
DOWN.


> Wiadomość napisana przez Tobias Heister  w dniu 
09.10.2020, o godz. 14:44:
>
> Hi,
>
> Am 09.10.2020 um 13:12 schrieb Łukasz Trąbiński:
>> In Lab I'm trying to set up 1G port on MX204.
>
> You might need to play around with autoneg options. we have a working 1G 
LX SFP running on 18.4R1-S7 on MX204
>
> in our case thats the gigether section:
> gigether-options {
>no-flow-control;
>no-auto-negotiation;
>speed 1g;
> }
>
> Not sure if the Flow Control stuff was mandatory, but without the 
no-auto-negotation the link was not useable. It might also help to check 
autoneg settings on the other end (if you have access).
>
> --
> Kind Regards
> Tobias Heister




Juniper Business Use Only
--- End Message ---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX204 port 1G

[Richard McGovern via juniper-nsp]

--- Begin Message ---
Correct.  Unlike EX/QFX where for 1/10 capable interfaces the name will match 
the insert Optic.  1G Optic shows as ge, 10G Optic shows as xe.  Both ge/xe 
names allowed.

For MX/SRX (and I assume PTX and maybe ACX - don't much deal with those 
products ) xe is ONLY name allowed, and is used to indicate the interface is 
10G capable.  For show interface info, the interface will show the correct 
speed.

NOTE: Please don't ask me the why.  Tried to fight that battle, this will NOT 
be changed.

As for William original question why are you hard coding 1G in the config, and 
setting 10G in the HW (chassis stanza)?  From initial look, that is first place 
to look.  BTW, on MX204, neither should needed.  FPC does not need speed 
setting (default supports 1/10) and auto should work fine at interface config.  
If you needed fixed speed for working with remote device, then set speed at 
interface level only.  If you are going to do both, make them equal, although I 
am guess chassis fpc only has 10G as option.

Did you have issue with auto for interface, which is default setting?

HTH, 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 10/9/20, 8:02 AM, "Łukasz Trąbiński"  wrote:

Hi.

It does not work. according to the documentation it must be xe-

> Wiadomość napisana przez Jackson, William  w 
dniu 09.10.2020, o godz. 13:42:
>
> Rename the interface ge-0/1/4
>
> admin@mx1> show interfaces xe-0/1/4
>Physical interface: xe-0/1/4, Enabled, Physical link is Up
>  Interface index: 154, SNMP ifIndex: 530
>  Description: TEST
>  Link-level type: Ethernet, MTU: 1514, MRU: 1522, LAN-PHY mode,   
 Speed: 10Gbps,
>
> On 09/10/2020, 13:16, "juniper-nsp on behalf of Łukasz Trąbiński" 
 wrote:
>
>Hello
>
>In Lab I'm trying to set up 1G port on MX204.
>
>admin@mx1> show configuration interfaces xe-0/1/4
>description TEST;
>gigether-options {
>speed 1g;
>}
>unit 0 {
>family inet {
>address 192.168.1.138/30;
>}
>}
>
>admin@mx1> show configuration chassis fpc 0 pic 1 port 4
>speed 10g;
>
>Port is UP, but I can’t see any MAC address from remote side or I 
can’t ping remote side.
>
>
>admin@mx1> show interfaces xe-0/1/4
>Physical interface: xe-0/1/4, Enabled, Physical link is Up
>  Interface index: 154, SNMP ifIndex: 530
>  Description: TEST
>  Link-level type: Ethernet, MTU: 1514, MRU: 1522, LAN-PHY mode, 
Speed: 10Gbps,
>  BPDU Error: None, Loop Detect PDU Error: None, MAC-REWRITE Error: 
None,
>  Loopback: None, Source filtering: Disabled, Flow control: Enabled,
>  Speed Configuration: 1G
>
>
>Junos: 18.4R3-S5.4 but also tried on 18.4R3.3. I also setup 
auto-negotiation and fec options but without success.
>
>SFP:
>Xcvr 4   REV 01   740-011614   PJD2XXX   SFP-LX10
>___
>juniper-nsp mailing list juniper-nsp@puck.nether.net
>
https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!T3KOFxazJ51vM0Q41a56Y1mr9YYi0Ruejmyy-NbGRh0FKlipj4DlsqFCEEmmURbUIQ$
>
>




Juniper Business Use Only
--- End Message ---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX80 upgrade path 18.4R

[Richard McGovern via juniper-nsp]

--- Begin Message ---
I believe Juniper has at least slightly modified their view on upgrades.  The 
old "no more than 2 release jumps" was based upon when EEOL type releases 
existed; these do not really exist anymore.

AFAIK, the major issue with BIG SW jumps is with the config.  New SW may have 
depreciated old commands which might be in your config.  From my experience 
(primarily with QFX not MX) the SW upgrade works, but if new SW does not 
recognize some lines in the config, box will likely re-boot into a default 
config.  My suggestion is to test basic config upgrade from whatever code you 
are on to the new code.  If there is a config situation, you can then 
troubleshoot it prior to major multiple device upgrades.

IMHO, if you are going to run into a situation with an upgrade from SW 'X' to 
SW 'Z' you are very likely to find this same situation somewhere along the 
upgrade path of 'X' -> 'Y' -> 'Z', no matter how many 'Y' releases you use.

Better approach to whole subject is to not fall so far behind on Code upgrades. 
 I know, easier said then done.  I'd say more than 2 or 3 behind current is a 
risk, and I am all for "if it's not broken, why change".  So today's code 
stream is 20.x based.  You should at least be on some 17.x, or better yet in 
many cases 18.x.  You better be able to find a stable release in some version 
of these code streams.

My 2 cents worth.

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 6/15/20, 5:01 AM, "nikosi...@gmail.com"  wrote:

Needless to mention here that if you do an upgrade directly to 18.4 ignoring
Juniper recommendations as someone has suggested if something goes wrong you
are on your own.
So I would never suggest this for a massive deployment.

-Original Message-
From: juniper-nsp  On Behalf Of Mark
Tinka
Sent: Monday, June 15, 2020 9:28 AM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MX80 upgrade path 18.4R



On 14/Jun/20 19:16, nikosi...@gmail.com wrote:
> It is true that the official path will tell you that you should follow
> from
> 15 to 16 then 17 then 18 but I did around 30+ upgrades from 16 to 18
> without any problems.
> >From 10 to 15 I guess you should go to 14 first but from 16 you can
> >safely
> move to 18 without any issues. The ones I am talking about are
> non-issue upgrades.

If I have to ring up 2014 again, I think you can go from 10 to 14, then to
16.

Once at 16, you should be able to skip all the way to current.

But yoh, that MX80 will be slow!

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net

https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!VKUfiZ-UmWKaa3h03qaJHoRhCnBhJvbODKqMYyKkAFK8ijlWp8zvgq4VNAbVmNH3aQ$




Juniper Business Use Only
--- End Message ---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] what do do with bug reports

[Richard McGovern via juniper-nsp]

--- Begin Message ---
For 100% sure you should open a JTAC Case, like P3, as you have a current 
workaround.  JTAC should then reproduce your issue, at which time they will 
create a PR for Engg to work on.  PR will be scheduled to be fixed in some 
future release.  JTAC should be able to provide that feedback to you once Engg 
has updated the PR.  Do NOT let JTAC close your case, until you get at least 
this far.  Also make sure that JTAC ties your Case to the PR.  Customer logged 
(CL) PRs have priority over Internal logged (IL) PRs.  You should also now be 
able to view PR via external PR tool.

You can then keep case open until you actually get a fix, or allow JTAC to 
close the case while you wait for the fix.  Case would be 100% in monitor 
during this time.  Case closure time is a top metric for TAC.

If you do nothing, Juniper will also do nothing, as no one outside of you knows 
about this.  If situation is known by Juniper (PR already open) your case can 
be tied to that PR, or new PR can be marked as a duplicate of older PR.

FYI only, 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 6/15/20, 9:28 AM, "Jeffrey Haas"  wrote:



> On Jun 15, 2020, at 2:15 AM, Baldur Norddahl  wrote:
>
>
> What am I supposed to do with glaring bugs? Are Juniper interested in
> knowing those or don't they care?

Treat the following as "I do not speak for official Juniper support policy".

It is to your benefit to open JTAC tickets on issues found.  This means 
that when it becomes a Problem Report (PR) in the internal bug system, it's 
tagged with the impacted customers.  Customers reporting issues will often 
change prioritization of how issues are dealt with vs. some random developer 
filing the PR.

And it absolutely doesn't hurt if you note any PR# that's associated with 
an issue, if one gets back to you.  It means that devs that are watching things 
with some knowledge of the issue may be able to add it to the report.

-- Jeff




Juniper Business Use Only
--- End Message ---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper Case Management down

[Richard McGovern via juniper-nsp]

--- Begin Message ---
You can still use https://support.juniper.net/support/ but then don't select My 
Juniper from banner menu, but instead Case Manager.

FYI only, 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 5/2/20, 2:48 PM, "Aaron Dewell"  wrote:


There should have been a banner up for the last few weeks detailing changes 
that were going to happen May 2 to My Juniper. There may have also been an 
email but I don't recall that myself.
http://casemanager.juniper.net is the place to go for your case management 
needs now.
On May 2 2020, at 11:46 am, Clinton Work  wrote:
> Was there any notification about the Juniper case manager going down for 
scheduled maintenance? The site has been down since last night and we had to 
get temp case # created via the phone.
>
> https://my.juniper.net/#dashboard/overview
> --
> Clinton Work
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> 
https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!RcjstFwPGskxidJ4peqE5AA5odHAhZcK3xC-0FExqamEt_hMp1zNc1le7DbyXGhWEw$
>




Juniper Business Use Only
--- End Message ---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] [EXT] EX4300: Framing error with macsec enabled

[Richard McGovern via juniper-nsp]

--- Begin Message ---
Thanks Chuck

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 4/21/20, 11:53 AM, "Chuck Anderson"  wrote:

[External Email. Be cautious of content]


As I said, I'm not excluding any protocols from MACsec.  With that 
configuration, LLDP apparently doesn't work "outside the tunnel"--I never see 
any directly attached neighbors.  LLDP does work between the MACsec 
endpoints--they show as if they are directly connected neighbors.  I'm fine 
with that result in my case.

The solution to eliminate the spurious framing errors appears to be: Ask 
your carrier to shut off LLDP/CDP/any other L2 protocols running on their 
interfaces directly attached to your MACsec endpoint devices.

On Tue, Apr 21, 2020 at 02:59:53PM +, Richard McGovern wrote:
> Based upon Chuck’s reply:
>
> Well, that was an easy fix on my MX480s:
>
> set protocols lldp interface xe-0/0/1 disable
>
> Now I'm not seeing CRC errors incrementing 2-3 times per minute on 
the EX3400s connected directly to the MX480s.
>
> I'm not excluding any protocols from MACsec--LLDP runs end-to-end 
between the EX3400s just fine.
>
> Don’t exclude LLDP from MACSEC and either stop or block LLDP from the 
Carrier/ISP.  In Chuck’s case the Carrier (to the EX3400s) was his MX.  Then 
EX3400s should see each other via LLDP, but not see the carrier.  I am not sure 
if today, you have an LLDP neighbor with your Carrier/ISP or not?
>
> This is the way I now read his response.
>
> Yes?
>
>
> 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
>
> [signature_1140633420]
>
> From: james list 
> Date: Tuesday, April 21, 2020 at 10:53 AM
> To: Richard McGovern 
> Cc: Chuck Anderson , Juniper List 

> Subject: Re: [j-nsp] [EXT] EX4300: Framing error with macsec enabled
>
> [External Email. Be cautious of content]
>
> Hi Richard
> lldp and lacp are excluded:
>
>   > > @EX4300-A> show configuration security macsec | display set
> > > set security macsec connectivity-association MAC security-mode 
static-cak
> > > set security macsec connectivity-association MAC pre-shared-key 
ckn 
> > > set security macsec connectivity-association MAC pre-shared-key 
cak
> > > "t"
> > > set security macsec connectivity-association MAC exclude-protocol 
lldp
> > > set security macsec connectivity-association MAC exclude-protocol 
lacp
> > > set security macsec interfaces ge-0/0/0 connectivity-association 
MAC
>
> I did not catch the connection with Framing errors counter...
>
> Please detail if you can.
>
> Cheers
>
>
> Il giorno mar 21 apr 2020 alle ore 15:27 Richard McGovern 
mailto:rmcgov...@juniper.net>> ha scritto:
> Chuck, I thought you were running both LLDP and LACP outside the MACSEC 
tunnel, no?
>
> (Optional) Exclude a protocol from MACsec:
> [edit security macsec connectivity-association 
connectivity-association-name]
> user@switch# set exclude-protocol protocol-name
> For instance, if you did not want Link Level Discovery Protocol (LLDP) to 
be secured using MACsec:
>
> [edit security macsec connectivity-association ca-dynamic1]
> user@switch# set exclude-protocol lldp
> When this option is enabled, MACsec is disabled for all packets of the 
specified protocol—in this case, LLDP—that are sent or received on the link.
>
> BEST PRACTICEWe recommend that any protocol other than MACsec being used 
on the MACsec connection, such as LLDP, LACP, STP, or layer 3 routing 
protocols, should be excluded and moved outside of the MACsec tunnel.
>
> Is this not working properly for LLDP?
>
> 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 4/19/20, 7:31 PM, "Chuck Anderson" mailto:c...@wpi.edu>> 
wrote:
>
> Well, that was an easy fix on my MX480s:
>
> set protocols lldp interface xe-0/0/1 disable
>
> Now I'm not seeing CRC errors incrementing 2-3 times per minute on 
the EX3400s connected directly to the MX480s.
>
> I'm not excluding any protocols from MACsec--LLDP runs end-to-end 
between the EX3400s just fine.
>
> Check if the carrier is running LLDP or CDP or similar.
>
>
> On Sun, Apr 19, 2020 at 07:16:46PM -0400, Chuck Anderson wrote:
> > Yes, I see CRC errors on EX3400s with MACsec termination, but only 
on one side.
>

Re: [j-nsp] [EXT] EX4300: Framing error with macsec enabled

[Richard McGovern via juniper-nsp]

--- Begin Message ---
Chuck, I thought you were running both LLDP and LACP outside the MACSEC tunnel, 
no?

(Optional) Exclude a protocol from MACsec:
[edit security macsec connectivity-association connectivity-association-name]
user@switch# set exclude-protocol protocol-name
For instance, if you did not want Link Level Discovery Protocol (LLDP) to be 
secured using MACsec:

[edit security macsec connectivity-association ca-dynamic1]
user@switch# set exclude-protocol lldp
When this option is enabled, MACsec is disabled for all packets of the 
specified protocol—in this case, LLDP—that are sent or received on the link.

BEST PRACTICEWe recommend that any protocol other than MACsec being used on the 
MACsec connection, such as LLDP, LACP, STP, or layer 3 routing protocols, 
should be excluded and moved outside of the MACsec tunnel.

Is this not working properly for LLDP?

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 4/19/20, 7:31 PM, "Chuck Anderson"  wrote:

Well, that was an easy fix on my MX480s:

set protocols lldp interface xe-0/0/1 disable

Now I'm not seeing CRC errors incrementing 2-3 times per minute on the 
EX3400s connected directly to the MX480s.

I'm not excluding any protocols from MACsec--LLDP runs end-to-end between 
the EX3400s just fine.

Check if the carrier is running LLDP or CDP or similar.


On Sun, Apr 19, 2020 at 07:16:46PM -0400, Chuck Anderson wrote:
> Yes, I see CRC errors on EX3400s with MACsec termination, but only on one 
side.
> 
> Here is my topology:
> 
> From A to B:
> 
> [EX3400-A]-->--[push-vlan-tag-on-MX480]-->-L2 
vlan-->-[Carrier-ASR9k-pop-vlan-tag]-->--[EX3400-B]
>   MACsec L2 connection  L2 
xconnectMACsec
> 
> From B to A:
> 
> [EX3400-A]--<--[pop-vlan-tag-on-MX480]--<-L2 
vlan--<-[Carrier-ASR9k-push-vlan-tag]--<--[EX3400-B]
>   MACsec L2 connection  L2 
xconnectMACsec
> 
> I also have a redundant path with EX3400-C (different local switch) and 
EX3400-B (same remote switch).
> 
> I see the CRC errors increasing at a rate of about 2-3 per minute, but 
only on EX3400-A and EXX3400-C.
> 
> All EX3400s were initially running 15.1X53-D57.  Now A and C are running 
18.2R3-S2 and B is running 15.1X53-D592.  But the problem has been consistent 
throughout all releases, no improvement with upgrades.
> 
> I wonder if something the carrier's ASR9k is sending down the VLAN 
towards EX3400-A and -C is causing this?  If not, maybe it is the MX480s 
sending something locally to EX3400-A and -C?
> 
> The following PRs don't seem relevant--I'm not doing anywhere close to 
60% utilization:
> 
> https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR1261567
> 
> And I'm not seeing "runts":
> 
> https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR1469663
> 
> I'm only seeing Framing errors (CRC/Align errors):
> 
> admin@ex3400-a> show interfaces extensive xe-0/2/0 |match 22791 
> Errors: 227911, Drops: 0, Framing errors: 227911, Runts: 0, Policed 
discards: 0, L3 incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 0, 
FIFO errors: 0, Resource errors: 0
> CRC/Align errors2279110
> 
> A few seconds later, it increased to 227913:
> 
>   MAC statistics:  Receive Transmit
> Total octets179536471171563221741316352
> Total packets  13200126465   7010832956
> Unicast packets13194022205   7004785539
> Broadcast packets 52720
> Multicast packets  6098988  6047417
> CRC/Align errors2279130
> FIFO errors  00
> MAC control frames   00
> MAC pause frames 00
> Oversized frames 0
> Jabber frames0
> Fragment frames  0
> VLAN tagged frames 13196813130
> Code violations  0
> 
> Rate is only 24 Mbps, 2200 pps:
> 
> admin@ex3400-a> show interfaces extensive xe-0/2/0 |match "bps|pps" 
>   Link-level type: Ethernet, MTU: 9192, LAN-PHY mode, Speed: 10Gbps, BPDU 
Error: None, Loop Detect PDU Error: None, Ethernet-Switching Error: None, 
MAC-REWRITE Error: None,
>Input  bytes  :   17954037433802 24242136 bps
>Output bytes  :3221749625049  

Re: [j-nsp] Netflow config for MX204

[Richard McGovern via juniper-nsp]

--- Begin Message ---
By any chance does you config/design include LSYS?  If yes export could/will 
have issues, BUT at same time this combination is not officially supported 
together to start with.  So if trying to use these together, you are on your 
own.

https://kb.juniper.net/InfoCenter/index?page=content&id=KB27035&actp=RSS

FYI Only, 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 4/9/20, 3:35 AM, "Timur Maryin"  wrote:



On 09-Apr-20 08:20, Liam Farr wrote:
> Hi,
> 
> changed to a loopback address on one of the VRF's,

...

> Not sure specifically what I am doing wrong here, it seems to be 
collecting
> the flows ok, but exporting is the issue?
> 
> I'd appreciate any advice or pointers thanks :)


maybe this?


https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/routing-instance-edit-forwarding-options-sampling.html




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

Re: [j-nsp] Flex licensing on MPC10

[Richard McGovern via juniper-nsp]

--- Begin Message ---
Yes Flex Licensing allows the license to move from one device, to another.  You 
purchase a Flex license which last for a period of time, and includes support - 
no extra Support SKU is needed.  The license is NOT tie to any hardware!  This 
is different than older original Perpetual License model.  There you purchased 
License (upfront cost) tie to a specific piece of HW, and then paid Support on 
top of this.  if you did not renew Support for the P License SKU, you lost 
ability to use those features, for basically like forever.

At this time many Juniper Licensed features are "honor based" and Juniper uses 
EULA sort of like do not copy on DVDs __  A Flex License can only be used on 
one applicable product, at any moment in time.  If you want multiple products 
to be allowed to run any licensed feature, multiple license would need to be 
purchased.  Now in the future if features (some features are already there) are 
actually restricted without a license, if you move a Flex License from one 
system to another, the feature support moves with in. One major advantage for 
Flex vs Permanent Licenses, if you only want to use a feature for say 1 or 3 
years, you purchase license with that length of time, and at the end you just 
do not renewal the license.  Now 1 or 2 years down the road you determine you 
want that feature back, you just repurchase the license.  With Permanent you 
could stop renewing support after 1 or 3 years, but without continued Support 
Juniper is not required to allow a renewal when years are skipped.  Juniper may 
charge extra for years you skipped support for a P License, or make you 
purchased new License to get support.  The upfront Cost for Permanent plus 
Support is greater than the equivalent for Flex, but then the yearly cost of 
Flex (which includes Support) is greater than P License Renewal cost.  I 
believe based upon some calculations, that on average Permanent is more cost 
effective after like 7/8 years of use, vs Flex.  In todays every changing 
market dynamics, 7/8 years is like a very LONG time.

Hopefully this helps.

Just FYI, 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 3/25/20, 3:32 PM, "Chris Wopat"  wrote:

Hey folks,

Anyone have MPC10's in production yet? Or perhaps any other shiny new Junos
thing that is coming with only "Flex" licensing out of the gate (so not
mx204, mx10k3).

We traditionally keep a warm spare device in the lab + purchase NBD
support, then spare from our lab whiile RMA'ing the faulty hardware. With
flex licensed items, there's the hw cost, support cost, and additional
license.


https://www.juniper.net/documentation/en_US/junos/topics/concept/juniper-flex-program-support-for-hardware-platforms.html#MPC10E

Allegedly one can move the license around, but we're not quite sure how. Is
there a self serve portal for this? Does one have to go through JTAC?

How does the card act when unlicensed? IE we have it slotted in a lab MX
blowing air, but that MX has CoS and other things configured. According to
the link above, it looks like most things won't function without a license.
Does it just throw a red alarm (for now)? Would it be unusable to lab test
on various configs without a license?

Cheers
--Chris



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

Re: [j-nsp] SRX Dynamic VPN License

[Richard McGovern via juniper-nsp]

--- Begin Message ---
yes

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 4/6/20, 8:13 AM, "Mohammad Khalil"  wrote:

Greetings
Hope all is good
I have SRX300 and I used to connect to it using dynamic VPN (Only two
concurrent connections were allowed).
I have purchased dynamic-vpn-5-users - Dynamic VPN , but am limited now to
5 per the new license , does that mean the new license override?

Thanks



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

Re: [j-nsp] QSFP+ to SFP+ adapters

[Richard McGovern via juniper-nsp]

--- Begin Message ---
Chuck is not running Fusion of any kind.

Chuck, I "think" we are going to eventually certify (not re-sell) one of these 
adapters, most likely Mellanox.  We cannot certify all, that is for sure.  
Hopefully at that time, we can add whatever might be needed to get DOM support, 
if possible.

Regards and FYI, 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 3/16/20, 5:15 PM, "Jackson, William"  wrote:

Yes 

We have used the ones from flexoptix

They tend to work correctly, but like you mentioned you lose the DOM and 
also the optic partcode may not display correctly on a show chassis hardware.

Apart from that work quite well.

Note:  don't bother trying to use these for a fusion setup on the satellite 
side as it doesn't work.
They can work on the AD device with a native 10GE port on the satellite, 
but using them on the satellite in a 40/100GE port  as a 10GE uplink, is a no 
go.

will



-Original Message-
From: juniper-nsp  On Behalf Of Chuck 
Anderson
Sent: 16 March 2020 21:06
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] QSFP+ to SFP+ adapters

Has anyone tried using QSFP+ to SFP+ adapters such as this one?  What 
software versions have you tried?

https://www.fs.com/products/72587.html

I'm testing these on QFX10002-36Q with 17.3R3-S7.2 and SFP+ 10G-LR modules. 
 The links come up and pass LLDP and IP traffic, but DOM doesn't work:

{master:0}
root@spine-1> show interfaces diagnostics optics xe-0/0/30:0 Physical 
interface: xe-0/0/30:0
Optical diagnostics   :  N/A

{master:0}
root@spine-1> show interfaces diagnostics optics xe-0/0/31:0 Physical 
interface: xe-0/0/31:0
Optical diagnostics   :  N/A

{master:0}
root@spine-1> show chassis hardware
Hardware inventory:
Item Version  Part number  Serial number Description
  PIC 0   BUILTIN  BUILTIN   36X40G
Xcvr 30   NON-JNPR   UNKNOWN
Xcvr 31   NON-JNPR   UNKNOWN


root@spine-1> show chassis pic fpc-slot 0 pic-slot 0 
FPC slot 0, PIC slot 0 information:
  Type 36X40G
  StateOnline
  PIC version 2.47
  Uptime 26 days, 40 minutes, 44 seconds

PIC port information:
 FiberXcvr vendor   Wave-   
 Xcvr
  Port Cable typetype  Xcvr vendorpart number   length  
 Firmware
  30   unknown cable n/an/a 
 0.0   
  31   unknown cable n/an/a 
 0.0   


{master:0}
root@spine-1> show interfaces terse xe-*
Interface   Admin Link ProtoLocal Remote
xe-0/0/30:0 upup
xe-0/0/30:0.0   upup   inet 10.0.0.1/30 
xe-0/0/30:1 updown
xe-0/0/30:2 updown
xe-0/0/30:3 updown
xe-0/0/31:0 upup
xe-0/0/31:0.0   upup   inet 10.0.0.5/30 
xe-0/0/31:1 updown
xe-0/0/31:2 updown
xe-0/0/31:3 updown
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp



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

Re: [j-nsp] Any red flags on this MX240 configuration...

[Richard McGovern via juniper-nsp]

--- Begin Message ---
I could tell you what that knob is for, but I would need to kill you afterwards 
__

I believe that knob can be set to Enhanced IP even with older SCB.  I have a 
customer with this set, older SCB, no issues.

Just sat, this knob should always be set to Enhanced IP for best 
performance/etc.

I also agree with all the additional comments about RE/memory/64 bit support, 
etc.

FYI only, 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 2/26/20, 9:59 AM, "Dave Bell"  wrote:

The documentation states its supported:


https://www.juniper.net/documentation/en_US/release-independent/junos/topics/concept/enhanced-mx-scb-description-mx960.html

It doesn't support "Enhanced IP/Enhanced Ethernet mode" though
whatever that is...

Dave

On Wed, 26 Feb 2020 at 14:37, Benjamin Collet  wrote:

> On Wed, Feb 26, 2020 at 03:05:16PM +0100, Marcel Bößendörfer wrote:
> > The MPC-3D-16XGE-SFPP even works with a 710-021523 / SCB-MX :-)
>
> On Wed, Feb 26, 2020 at 09:11:50AM -0500, Brendan Mannella wrote:
> > We have MPC-3D-16XGE-SFPP and SCBE working in production. Haven’t 
noticed
> > any issues.
>
> That's good to know. I wonder if there are any limitations whatsoever or
> simply a mistake in the documentation and the Hardware Compatibility
> Tool).
>
> --
> Benjamin Collet
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> 
https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!R46SRRs9euIxe0gY5atGljZf0afP3vCSl3lO7LYoLz1BRc3HoyDW97Plj-FP1M-fIw$
 
>



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

Re: [j-nsp] Any red flags on this MX240 configuration...

[Richard McGovern via juniper-nsp]

--- Begin Message ---
#1, yes 16XGE module works with all varieties if SCB.  I assume you already own 
the equipment list.  I therefore 'think' your question/concern is with such 
equipment, any concern going from 16.2 to some later release, which I am 
guessing might be something like 18.4R2-S3 (TAC recommended I believe).  You 
should have no concerns, that I am aware of.

If the list below is something you are planning to purchase (you must have at 
least 1 x MX, as you have experience with MX on 16.2), I would HIGHLY recommend 
that instead of below, you look at a MX204 instead.  Very likely less cost, 
more performance (400GE capable), and you can pair any 2 MXs for your 
redundancy, as Routing (BGP) is the solution, not HW.  The downside is, if you 
want more 10GE connections, you would need to use a proper 40GE Optic (MX205 4 
x 100GE ports, support either 100GE or 40GE - QSFP+) and then use some sort of 
breakout scheme.  The breakout scheme is generally an external patch panel of 
some sort - plenty [non-Juniper] options for this.

In general, IMHO, if looking to upgrade older MXs, you should always at least 
look at an MX204 solution too.

Just FYI.  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 2/26/20, 8:46 AM, "Alain Hebert"  wrote:

 Beside the RE-S-2000-4096-S being EOL.  My experience with 16.2 was 
pretty solid.

 We're planning to have 3 Full Routes BGP and the MPLS alphabet 
soup, yadi yada.

 We don't want 2 RE since we'll use 2 MX240 and there is no point to 
go for ISSU since the RE is EOL.

1x CHAS-BP-MX240-S
1x FFANTRAY-MX240-HC
1x RE-S-2000-4096-S
1x SCBE-MX-S
2x PWR-MX480-1200-AC
1x MPC-3D-16XGE-SFPP

-- 

-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  
https://urldefense.com/v3/__http://www.pubnix.net__;!!NEt6yMaO-gk!TijPAXAj8Uq34U6lspy0FkJmqZrDYdYw3bJlFWHv-45OdTbxjhuOid7PX8oqg5xrNw$
 Fax: 514-990-9443




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

Re: [j-nsp] [EXT] Re: MX204 MACsec

[Richard McGovern via juniper-nsp]

--- Begin Message ---
This appears to be a SW issue, as MX204 does NOT have any MACsec support.  As 
Chuck said, SW sure error in some manner, like non-supported platform etc.  
Even though the config is allowed, nothing will happen in terms of MACsec - no 
HW support.

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 11/27/19, 2:28 PM, "Anderson, Charles R"  wrote:

Interesting.  I wonder if this falls under "This is implemented, but not 
supported by JTAC."  You'd have to actually try it to see...

On Wed, Nov 27, 2019 at 01:18:29PM -0600, Aaron Gould wrote:
> [edit]
> me@site2-204-3# show | compare
> [edit]
> +  security {
> +  macsec {
> +  connectivity-association my-ca1 {
> +  security-mode static-cak;
> +  mka {
> +  transmit-interval 6000;
> +  key-server-priority 0;
> +  }
> +  replay-protect {
> +  replay-window-size 5;
> +  }
> +  offset 30;
> +  pre-shared-key {
> +  ckn (i removed);
> +  cak "(i removed)"; ## SECRET-DATA
> +  }
> +  exclude-protocol lldp;
> +  }
> +  interfaces {
> +  xe-0/1/0 {
> +  connectivity-association my-ca1;
> +  }
> +  }
> +  }
> +  }
> 
> [edit]
> me@site2-204-3# commit check
> configuration check succeeds
> 
> [edit]
> me@site2-204-3# show security
> macsec {
> connectivity-association my-ca1 {
> security-mode static-cak;
> mka {
> transmit-interval 6000;
> key-server-priority 0;
> }
> replay-protect {
> replay-window-size 5;
> }
> offset 30;
> pre-shared-key {
> ckn (i removed);
> cak "(i removed)"; ## SECRET-DATA
> }
> exclude-protocol lldp;
> }
> interfaces {
> xe-0/1/0 {
> connectivity-association my-ca1;
> }
> }
> }
> 
> [edit]
> me@site2-204-3#
> 
> 
> 
> - Aaron



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

Re: [j-nsp] EX2300 Code

[Richard McGovern via juniper-nsp]

--- Begin Message ---
Use 18.2R3-S2

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 12/9/19, 6:15 AM, "William"  wrote:

Hi,

I am in the process of getting our first stack of EX2300s ready for
production, can anyone recommend any specific versions of junos to run
on them?

I'm not taking advantage of any advance features, just after something
stable :)

Cheers,

William



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

Re: [j-nsp] MX204 MACsec

[Richard McGovern via juniper-nsp]

--- Begin Message ---
So it looks SW allows for the commands, as other MX products do have MACsec 
support.  I am 99.999% sure these commands will do nothing but make your config 
file larger.

Thanks for the input.  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 11/27/19, 11:50 AM, "Aaron Gould"  wrote:

Not knowing much about this, but going from this site's guidance ( I 
stopped halfway down the page ) , 
https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/macsec-configuring-mx-series.html

...i did the following... 

[edit]
me@site2-204-3# show | compare
[edit]
+  security {
+  macsec {
+  connectivity-association my-ca1 {
+  security-mode static-cak;
+  mka {
+  transmit-interval 6000;
+  key-server-priority 0;
+  }
+  replay-protect {
+  replay-window-size 5;
+  }
+  offset 30;
+  pre-shared-key {
+  ckn 
37c9c2c45ddd012aa5bc8ef284aa23ff6729ee2e4acb66e91fe34ba2cd9fe311;
+  cak 
"$9$9Zp0tBIhSrlM8n/0IhcleaZGD.P5T36/tPfIESr8LVwY4UjfTzn9AF3A0BIrlaZGjmfFn/CA0JGjqP5F3evM8X-oJGDHqLx";
 ## SECRET-DATA
+  }
+  exclude-protocol lldp;
+  }
+  interfaces {
+  xe-0/1/0 {
+  connectivity-association my-ca1;
+  }
+  }
+  }
+  }

[edit]
me@site2-204-3# commit check
configuration check succeeds

[edit]
me@site2-204-3#



- Aaron



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

Re: [j-nsp] MX204 MACsec

[Richard McGovern via juniper-nsp]

--- Begin Message ---
Oh, I am sure the commands are there in the CLI as Juniper generally does not 
"hide' non-affecting functions from the CLI, on a per product basis.  If 
actually used you 'might' get a "unsupported on this platform" message, when 
you try to commit.  For sure if used, these commands will do nothing.  I am 
like 99.9% sure of that.

If possible maybe you could config and then perform a commit check to see what 
results you get?  I do not have a MX204 handy to try this.

Thanks and regards, 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 11/27/19, 11:17 AM, "Aaron Gould"  wrote:

I don't know much about this, but, for what it's worth, I do see this on one
of my MX204's...

me@site2-204-3# set security macsec connectivity-association test ?
Possible completions:
  <[Enter]>Execute this command
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  cipher-suite Cipher suite to be used for encryption
> exclude-protocol Configure protocols to exclude from MAC Security
  include-sci  Include secure channel identifier in MAC Security PDU
> mka  Configure MAC Security Key Agreement protocol
properties
  no-encryptionDisable encryption
  offset   Confidentiality offset
> pre-shared-key   Configure pre-shared connectivity association key
  pre-shared-key-chain  Pre-shared key chain name for connectivity
association
> replay-protect   Configure replay protection
> secure-channel   Configure secure channel properties
  security-modeConnectivity association mode
  |Pipe through a command

[edit]
me@site2-204-3# exit
Exiting configuration mode

me@site2-204-3> show system information
Model: mx204
Family: junos
Junos: 18.4R1-S3.1
Hostname: site2-204-3

me@site2-204-3>


-Aaron



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

Re: [j-nsp] MX204 MACsec

[Richard McGovern via juniper-nsp]

--- Begin Message ---
I am fairly certain the original link that Graham posted - 
https://apps.juniper.net/feature-explorer/parent-feature-info.html?pFName=Media%20Access%20Control%20Security%20(MACsec)
  - where it shows that the MX204 has support for Unicast MAC DA for MACsec is 
inaccurate.  One would first need MACsec support to support this extra feature, 
and the MX204 does NOT have MACsec [HW] support, as Roger pointed out.

I will try to get this inaccuracy corrected.

Just FYI, 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 11/26/19, 7:12 PM, "Mohammad Khalil"  wrote:

Thank you very much.

On Tue, 26 Nov 2019 at 22:33, Roger Wiklund  wrote:

> Here you go
>
>
> 
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/understanding_media_access_control_security_qfx_ex.html#jd0e108
>
>
> On Tue, Nov 26, 2019 at 9:29 PM Mohammad Khalil 
> wrote:
>
>> Thanks Roger for the kind feedback.
>> Is there any HW related documentation I can use for this?
>>
>> On Tue, 26 Nov 2019 at 22:28, Roger Wiklund 
>> wrote:
>>
>>> Hi
>>>
>>> MX204 does not support MACsec, it lacks the hardware for it.
>>>
>>>
>>>
>>> On Tue, Nov 26, 2019 at 9:04 PM Mohammad Khalil 
>>> wrote:
>>>
 Thanks Graham for the kind reply.
 But in general that means MACsec standard 802.1ae is not support on
 MX204
 ports?

 Thanks again

 On Tue, 26 Nov 2019 at 21:44, Graham Brown <
 juniper-...@grahambrown.info>
 wrote:

 > Hi Mohammad,
 >
 > The following link displays specific elements pertaining to MACSec
 support
 > on various Juniper platforms, MX204 included:
 >
 
https://apps.juniper.net/feature-explorer/parent-feature-info.html?pFName=Media%20Access%20Control%20Security%20(MACsec)
 >
 >
 > Review the link and ask the customer for clarification on what they
 > require to be supported from the equipment. Depending on what the
 > requirements are, the MX204 may be able to secure the L2 elements for
 your
 > customer.
 >
 > HTH,
 > Graham
 >
 > Graham Brown
 > Twitter - @mountainrescuer 

 > LinkedIn 

 >
 >
 > On Wed, 27 Nov 2019 at 08:39, Mohammad Khalil 
 wrote:
 >
 >> Dears
 >> I am working with a customer and MX204 is in play.
 >> The customer concern is MACsec feature support , I have read around
 >> that MX204 doesn’t Support a real MACSEC, but offers unicast MAC DA
 for
 >> MACsec and MACsec with fallback PSK are which related to allow
 exchanging
 >> and establishing Macsec connections.
 >> So frankly MX204 does not support MACsec or am I missing something?
 >>
 >> Thanks
 >> ___
 >> juniper-nsp mailing list juniper-nsp@puck.nether.net
 >> 
https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!8WoA6RjC81c!UHGI_Mb1oXZlTiCFR8_FUyBeKvhoVEZvYb4AHYnNKMQe2Q7-4YA9vOgO1s-Bo4W0CQ$
 
 >>
 >
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 
https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!8WoA6RjC81c!UHGI_Mb1oXZlTiCFR8_FUyBeKvhoVEZvYb4AHYnNKMQe2Q7-4YA9vOgO1s-Bo4W0CQ$
 

>>>



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

Re: [j-nsp] JunOS on EX4550?

[Richard McGovern via juniper-nsp]

--- Begin Message ---
In my view best stability, used by most people (all of my customers are on 12.3 
only), and no feature set differences. When 15.1 came out initially there were 
some concerns, so IMHO most just stayed on 12.3 once it was announced to have 
continued support.

Just my 2 cents worth.

Sent from my iPhone

On Oct 17, 2019, at 12:01 AM, Josh Baird  wrote:


Thanks, Richard.  Any particular reason why I would be better off using 12.3R12?

On Wed, Oct 16, 2019 at 5:53 PM Richard McGovern 
mailto:rmcgov...@juniper.net>> wrote:
No.  For legacy EX switches, for which EX4500/EX4550 fall into, 15.1 is last 
release.  At the same time, I think you might have best results using 
12.3R12-S[latest] instead.  Both 12.3 and 15.1 will be maintained for life of 
legacy EX switches.

HTH, 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 10/16/19, 1:50 PM, "Josh Baird" 
mailto:joshba...@gmail.com>> wrote:

Is it possible (and recommended) to run anything newer than 15.1 on EX4550
(which is what the JTAC-recommended version currently is).



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

Re: [j-nsp] JunOS on EX4550?

[Richard McGovern via juniper-nsp]

--- Begin Message ---
No.  For legacy EX switches, for which EX4500/EX4550 fall into, 15.1 is last 
release.  At the same time, I think you might have best results using 
12.3R12-S[latest] instead.  Both 12.3 and 15.1 will be maintained for life of 
legacy EX switches.

HTH, 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 10/16/19, 1:50 PM, "Josh Baird"  wrote:

Is it possible (and recommended) to run anything newer than 15.1 on EX4550
(which is what the JTAC-recommended version currently is).



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

Re: [j-nsp] EX2300-C-12P PoE issues

[Richard McGovern via juniper-nsp]

--- Begin Message ---
Chris what is actually happening here is not so much class setting but 
LLDP/LLDP MED.  By default EX switches support LLDP MED POE-Negotiation, and 
use this method 1st.  So whatever wattage the external device requests is taken 
into the total power budget.  Once the switch calculation for these reaches max 
POE for the switch, no additional POE power will be provided.  This is even if 
the device pulls much less power than it negotiated for or asked for.  The 
switch needs to reserve that power calculation as a 'just in case'.  We 
actually reserve more than the value with LLDP MED tlv, to account for 
potential cable loss; this is approximately 10% more.

So if you disable LLDP MED, then class value will take over, and there is no 
need to set static.  Of course setting static is always an option, and if set 
that value is used regardless of other settings.

FYI only, 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 9/5/19, 8:49 PM, "Chris Lee"  wrote:

For the benefit of the archives have found a solution for this, it appears
to come down to power budgets and defaults of class based PoE management.
Have never noticed this before as on all our 24-port EX2300 and 48-port
EX3400 and 4300's there's always at least sufficient total power budget to
allocate 15.4 watts across every interface.

So class 3 devices allocated 15.4watts of power theoretically means you
could effectively only have 9x class 3 ports power up with a total of 138.6
watts, unfortunately I currently don't have enough class 3 PoE devices in
the lab to fully test this theory, and what I saw in the field was the
switch would only provide power to the first 7x ports even though there was
still sufficient power remaining to allocate 2x more ports, maybe it's
something to do with internal power bank architecture/design or additional
power reserves per class 3 device.

The workaround was to define PoE management type as static and set max
power for all interfaces to 12 watts, and then the remaining cameras
interfaces ge-0/0/7 to 9 that previously wouldn't power up all started fine
and are online. Note there's a bit of lag even after committing the
configuration, seems to take a minute or two for the config change to flow
onto the PoE controller and reflect the change from class to static
management with max power of 12 watts defined.

z@z> show configuration poe
management static;
interface all {
maximum-power 12;
}

Regards,
Chris

On Thu, Sep 5, 2019 at 8:34 PM Chris Lee  wrote:

> Hi,
>
> Wondering if anyone is successfully running EX2300-C-12P switches with at
> least 8x PoE devices connected ?
>
> We've just encountered an issue in the last week across 2 of these
> switches at different locations with around 10x PoE CCTV cameras 
connected,
> and only the first 7 ports (ge-0/0/0 to ge-0/0/6) providing PoE power.
>
> One switch is running JUNOS 15.1X53-D591.1 and the other is JUNOS
> 18.1R3-S7.1.
>
> Both have had the PoE firmware controller update done on them that comes
> with releases beyond 15.1X53-D58 I think it was, which when you look at
> firmware detail the PoE version on chassis is  2.1.1.19.3
>
> I have an active JTAC case open for it, I've done PR Search and can't see
> anything against POE or Power for either of those two releases that relate
> to the EX2300/3400 series.
>
> In both cases the PoE cameras on the end of the line are very low power
> bullet / fixed style cameras only drawing around 3 watts each, and the 
most
> I've seen reported on show poe controller is around 25 watts power draw
> which is no where near the EX2300-C-12Ps max power budget of 146watts.
>
> If I deliberately disable PoE on an interface like ge-0/0/0, then after a
> minute or so interface ge-0/0/7 will then magically start providing power,
> and as soon as I rollback the config and commit it will revert right back
> to port ge-0/0/7 providing no power, and ge-0/0/0 powering up.
>
> Thanks,
> Chris
>



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

Re: [j-nsp] multi services

[Richard McGovern via juniper-nsp]

Yes there is no equivalent MX Services to SPC3 at this time, but this is being 
worked on.  This is supposed to be coming in 19.3, via software only; new SW 
architecture.

Many [large] customers are running large scale IPSEC termination, but 5G max, 
from what [little] I know.  If someone needs more throughput, they will bond 
multiple IPSEC tunnels together.

As for failover, any failure should cause a switch to redundant module, 
assuming one is present.

HTH, 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 7/18/19, 8:00 AM, "harbor235"  wrote:

Is anyone using the ms-mpc for large scale IPSEC termination? above 10G?
Data shows 16-24Gps per card 4-6 per NPU.  I am interested in real world
performance with IMIX. The new SPC3 cards look promising - 40Gbps per slot
IMIX juniper marketing data, I dont think these cards are released yet for
the MX series.

Also, is anyone familiar with service sets for IPSEC on the MS-MPC cards,
how is physical interface failures of the inside and outside interfaces
handled?


thanks in advance,


Mike



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

Re: [j-nsp] DF/BDF Election EVPN

[Richard McGovern via juniper-nsp]

Appears to only be on MX, as of today, although I might expect it to be at 
least be in QFX10K configuration.  Potentially not yet supported due to lack of 
testing time.  See here:

https://apps.juniper.net/feature-explorer/feature-info.html?fKey=7906&fn=Preference-based%20DF%20election%20for%20EVPN%20and%20PBB-EVPN

Pathfinder => Feature Explorer is how to look for this sort of stuff.

HTH, 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 7/13/19, 7:52 PM, "Mileto Tales"  wrote:

I'm trying to figure out how to load balance the DF election in a 
production network. From the documentation it's clear that the EVPN type 
4 is used. My scenario is:

- I have several QFX5K acting as VXLAN L2 GW
- I'm using multicast mode ingress node replication
- I have a lot of CE's in a multihoming scenario


In this case I'm not finding how to control the DF/BDF election on QFX. 
On MX you can configure designated-forwarder-preference-least to achieve 
this.


Any help is appreciated.


mt




___
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

[Richard McGovern via juniper-nsp]

Colton, EX Access switches used in Campus Fusion, do NOT run Junos.  The run 
what we call SNOS (Satellite Network OS) instead.  These SW releases, at least 
from a numbering standpoint, are completely different and independent of Junos 
releases.  You can find Satellite SW via this direct link below.  Something 
wrong with Support Web as I am not able to get there via normal login and 
choosing Downloads.  Will look into this.

https://support.juniper.net/support/downloads/?f=fusion

HTH, 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 7/3/19, 12:54 AM, "Eldon Koyle"  wrote:

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://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwIBaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=cViNvWbwxCvdnmDGDIbWYLiUsu8nisqLYXmd-x445bc&m=T6w2urFHFvXBxD29C0gFgfVkJh4B5x15Sv7j8BgLnFE&s=Ju91vnB092BAzzug7RbgIgb5ILmj9TrY-o3J9GQLoSM&e=
 
> >
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwIBaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r

Re: [j-nsp] EVPN - BGP attribute propagation on MXes

[Richard McGovern via juniper-nsp]

Adam, sorry to disagree but I have a number of very successful EVPN/VXLAN 
deployments, all running 18.1R3-S[something].  Yes EVPN is new, but becoming 
more and more a Junos standard deployment every day.  At least IMHO.  
Documentation needs a lot of catching up, so today some form of PS engagement 
by either Juniper [knowledgeable] Partner or Juniper PS often needed.

As for Type 5, this command maybe needed.  This depends on specific platform, 
but can be set on all without any concern:

set routing-options forwarding-table chained-composite-next-hop ingress evpn

This is pre-19.1.  From 19.1forward  this should be a Junos-default setting for 
all platforms that support EVPN.

HTH, 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 7/3/19, 2:36 AM, "adamv0...@netconsultings.com" 
 wrote:

> Guillermo Fernando Cotone
> Sent: Monday, July 1, 2019 3:39 PM
> 
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Drabadan-2Dsajassi-2Dbess-2Devpn-2Dipvpn-2D&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=cViNvWbwxCvdnmDGDIbWYLiUsu8nisqLYXmd-x445bc&m=T6w2urFHFvXBxD29C0gFgfVkJh4B5x15Sv7j8BgLnFE&s=eJazdQ5Wm-axp47OtXLhuRBSVptRcnwDteGnYIacfRg&e=
 
> interworking-02#section-4.2
> 
> I'm not sure if this is actually supported on Juniper. We're running
17.3R3-
> S2.2.
> 
I'm sorry, we discovered too many "you're router might explode TM" bugs in
the recent SURR (again) so nope still don't feel at all comfortable to run
EVPN on Junos in production.
This is our 3rd code upgrade over the years where we're trying to get EVPN
working as its supposed to, but I'm starting to think that Juniper is just
not the right vendor for running EVPN, they will get there eventually, just
not ready, still.

adam




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

Re: [j-nsp] Junos 18.X on QFX5100

[Richard McGovern via juniper-nsp]

Have end-user running 18.1R3-S3, probably looking to move to 18.1R3-S6 down the 
road.  Multiple standalone QFX5100 as L2 VTEP for EVPN/VXLAN, is main reason on 
18.x code.

Rich

Richard McGovern
Sr Sales Engineer, Juniper Networks 
978-618-3342
 

On 5/25/19, 10:38 PM, "Philippe Girard"  wrote:

Greetings

Anyone running production Junos 18.X on QFX5100?

JTAC recommended still says 17.3R3-S4 but I'd really like to jump to 18 for
some new features it offers.

Thanks for your help.

-
Philippe Girard



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

Re: [j-nsp] prsearch missing in inaction

[Richard McGovern via juniper-nsp]

Nathan, not sure what history you are seeking, but if tell me what PR listing 
you seek, I'll see what I can gather.

Richard McGovern
Sr Sales Engineer, Juniper Networks 
978-618-3342
 

On 5/13/19, 9:25 AM, "Nathan Ward"  wrote:


> On 14/05/2019, at 1:17 AM, Nathan Ward  wrote:
> 
> 
>> On 9/05/2019, at 11:52 PM, Richard McGovern mailto:rmcgov...@juniper.net>> wrote:
>> 
>> Nathan, I am not sure what you want to hear, or what would make you 
satisfied, but YES Juniper [IT?] did screw-up, and a restore from back-up 
was/is not possible.  So this situation is now being worked on, unfortunately 
at a not so fast pace.  I hope you decide to stay with Juniper, as I feel there 
are far worse things one could be concerned about than this.
> 
> Well, I was hoping that someone had an archive of it all somewhere.

Actually.

There’s a PR subscription service mentioned in that KB.

If I sub, I only get future. Can you or someone else provide me with a 
history of that?

--
Nathan Ward




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

Re: [j-nsp] prsearch missing in inaction

[Richard McGovern via juniper-nsp]

I cannot agree more, but unfortunately not my area to affect.  BTW, in 40 years 
in networking working for multiple vendors, every company has room (and 
sometime great room) for improvement, . . .

Richard McGovern
Sr Sales Engineer, Juniper Networks 
978-618-3342
 

On 5/9/19, 8:11 AM, "James C Cotton"  wrote:


As someone who has a P1 case open on the QFX10008 (8.4R1.8) [WMU has 
retreated to 8.1R3.3] now sitting at day 15 that produced

three different types of core dumps with issues on the ULC-30Q28,  
ULC-60S-6Q, and MSNOOPD, it would be really nice to go fishing

on the bugs myself.  I have found the equivalent feature at Cisco useful in 
the past.


Perhaps someone could light a fire under the appropriate team.


Perhaps Juniper and Cisco could both learn is that customers want a stable 
support site whose elements don't move around.  We expect

tools to work and documentation links to be available for years...


Jim Cotton

Sr Network Engineer

Western Michigan University





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

Re: [j-nsp] prsearch missing in inaction

[Richard McGovern via juniper-nsp]

Tom, sorry but that is way far-fetched.  Nathan, if TAC will not provide you 
this info, then I am sure your local SE can assist.  I know I can/would for any 
of my accounts.

Rich

Richard McGovern
Sr Sales Engineer, Juniper Networks 
978-618-3342
 

On 5/9/19, 5:02 AM, "Tom Hodgson"  wrote:

>> And regarding PRs delta  between your present release and 17.4R2-S2 
release , JTAC is  not authorised to provide that info. I suggest you to reach 
out to juniper accounts team who can help you on this
> 
> Why? I have no idea, maybe this engineer was just lazy but I’ve had the 
same from someone else too I think. Maybe it’s so sales can hide the really bad 
bugs that might impact a sale? I really cannot understand why this has to be 
done by accounts people otherwise, what’s the difference who does it?

More likely they have been told not to provide this in order to help get 
people to buy PIIR/SURR reports as part of professional services.


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

Re: [j-nsp] prsearch missing in inaction

[Richard McGovern via juniper-nsp]

Nathan, I am not sure what you want to hear, or what would make you satisfied, 
but YES Juniper [IT?] did screw-up, and a restore from back-up was/is not 
possible.  So this situation is now being worked on, unfortunately at a not so 
fast pace.  I hope you decide to stay with Juniper, as I feel there are far 
worse things one could be concerned about than this.

Just my 2 cents worth.  The devil you know, is often better than the devil you 
do not know, . . .

Rich

Richard McGovern
Sr Sales Engineer, Juniper Networks 
978-618-3342
 

On 5/9/19, 7:35 AM, "Timur Maryin"  wrote:

https://kb.juniper.net/KB33515

If i recall correctly what i heard about it.

There is some third party(or smth) search engine which is(was) used and 
it had issues. And there is no way to upgrade/fix that engine as it out 
of support/development.
So i has to be replaced or re-written from scratch.




On 09-May-19 02:37, Nathan Ward wrote:
> 
> Can you shed any light on what on earth is going on, and why? It seems 
crazy that a company would disable this sort of thing intentionally for such a 
long time and with such poor comms and timing info. “Technical issue” sounds 
like an accident - but surely a restore from backup would work, right?
> I cannot think of a scenario here which looks anywhere remotely positive 
for Juniper - every scenario I can consider has a root cause of “complete and 
utter incompetence” somewhere along the chain.
> I really like Juniper, so I’ve searched, but, this is a hard one, help me 
out here..
> 


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

Re: [j-nsp] prsearch missing in inaction

[Richard McGovern via juniper-nsp]

Contacted someone internally and yes this is being worked on.  The time period 
is "end of Q2, hopefully sooner".  In the meantime, if you need comparison 
between 2 releases of same major release, then TAC should be able to generate 
this for you via internal PR DIFF tool.  This only works between release of the 
same major version.

Rich

Richard McGovern
Sr Sales Engineer, Juniper Networks 
978-618-3342
 

On 5/8/19, 3:05 AM, "Rob Foehl"  wrote:

On Tue, 7 May 2019, Nathan Ward wrote:

> Is it actually coming back? Hard to believe the “technical issue” given 
how long it’s been, seems like a pretty big systemic issue rather than a 
technical one. “Actively worked on” seems pretty inactive, to me.

Maybe it runs on Space, and they're just waiting for the web service to 
restart...

Asked the account team about it today.  Doesn't sound like there are any 
definitive answers.

-Rob





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

Re: [j-nsp] EX4600 or QFX5110

[Richard McGovern via juniper-nsp]

I know this thread is quite old, but wanted to respond with some additional 
info.

As for a generic comparison, the EX4600 is exact same internal hardware (PFE) 
as a QFX5100, just different packaging, and potentially feature support.  In 
this case, feature support is "what is tested and officially supported", not 
what the switch is [potentially] capable of.  BTW, EX4600 base unit comes with 
40 x 1/10GE (48 capable), while the QFX5100/5110 base unit includes 48 x 1/10GE.

EX4600 is 'positioned' as a Campus/Ethernet 10GE capable Switch, while QFX5K 
series is positioned as a DC TOR Switch.  So from feature standpoint EX has 
Campus features, while QFX has DC feature set, in general.

There is a price difference between EX4600 and QFX as well.

As Chuck mentioned in one of his responses, Juniper has a product compare 
function:

https://apps.juniper.net/feature-explorer/compare-multiple.html

This link (hopefully works for all!) compares  EX4600&VC/QFX5100&VC/QFX5110 - 
https://apps.juniper.net/feature-explorer/compare-multiple.html#pkey=30504600%7CJunos%20OS%7C%7C30504601%7CJunos%20OS%7C%7C31705100%7CJunos%20OS%7C%7C31705101%7CJunos%20OS%7C%7C31705110%7CJunos%20OS&platforms=EX4600%7CEX4600-VC%7CQFX5100%7CQFX5100-VC%7CQFX5110&stat=0.9677659894813813

QFX5110 DOES support VC, starting with 17.3R1.  Prior SW releases had the 
"capability" but not tested, so not "officially supported".  I "believe" 
QFX5110 does not supported mixed more with EX4300, while QFX5100 and EX4300 
mixed, supported for sure. 

EX4600 DOES NOT support VCF.  Besides ring design vs spine/leaf design for VC 
vs VCF, VCF also supports more members.  VCF supports 20 members max, VC is 10 
members max.

As for EVPN/VXLAN standpoint, Juniper is deploying this network architecture in 
a number of production customer sites.  EX4600 and QFX5100 both support L2 
VXLAN only (VLAN to VNI), while the QFX5110 supports L3 VXLAN, so both VLAN to 
VNI, and VNI to VNI, as well as IP (outside world) to VNI (VXLAN world). Please 
see my other correction email regarding QFX5110 support for IP/VLAN to VNI 
routing.  QFX5110 VC is NOT supported in EVPN/VXLAN use cases.  Should not be 
needed as ESI LAG allows dual or multiple connections to different TOR Leafs. 
QFX5100 does support VC with L2 VXLAN, but not highly recommended. 

MC-LAG is still supported on all of these products, although from a technology 
basis, Juniper (and many others) are moving away from recommending MC-LAG based 
designs, but instead EVPN/VXLAN (or EVPN/MPLS).  Major reasons are EVPN is 
Open, and all MC-LAG types are closed/proprietary. More importantly EVPN can 
scale horizontally (Virtual GW) while MC-LAG is always limited to 2 nodes or 
combinations of 2 nodes. At this time, Juniper is recommending the use of ESI 
LAG over MC-LAG.  VC as the choice is a completely different discussion, at 
least IMHO. 

Hopefully this may help all.

Rich


Richard McGovern
Sr Sales Engineer, Juniper Networks 
978-618-3342


On 3/13/19, 1:37 PM, "Andrey Kostin"  wrote:

   Hi guys,

   My 0.02: we use QFX5100 in VC and it's pretty solid. But. As mentioned, 
   it's a single logical switch and by design it can't run members with 
   different Junos versions that means downtime when you need to upgrade 
   it. There is an ISSU but it has it's own caveats, so be prepared to 
   afford some downtime for reboot. For example, there was an issue with 
   QoS that required both Junos and host OS upgrade, so full reboot was 
   inevitable in that case. Maybe I'm missing something, would like to hear 
   about your best practice regarding VC high-availability.

   For simple L3 routing QFX5100 works well, but when I tried to run PIM on 
   irb interfaces it behaved in strange way so I had to rollback and move 
   PIM to the routers because didn't have time to investigate.
   We run VC with two members only. Tried EX4300 up to 8 members but it was 
   very sluggish. Thankfully for us 96 ports is enough for ToR switch in 
   the most of the cases.
   Regarding VCF, as per reading docs my understanding about it is that 
   it's the same control plane as VC but with Spine-Leaf topology instead 
   of ring. Because we use only 2 member VCs, there is no added value in 
   it. Seems to me that VCF can't eliminate concern about reboot downtime 
   and more switches you have more impact you can get.

   I'm interested to hear about experience of running EVPN/VXLAN, 
   particularly with QFX10k as L3 gateway and QFX5k as spine/leaves. As per 
   docs, it should be immune to any single switch downtime, so might be a 
   candidate to really redundant design. As a downside I see the more 
   complex configuration at least. Adding vlan means adding routing 
   instance etc. There are also other questions, about convergence, 
   scalability, how stable it is and code maturity.
   I'd be appreciated if somebody could share a feedback about operation of 
   EVPN/VXLAN.

   Kind regards,
   Andrey


   Graham Brown писал

Re: [j-nsp] RFC2544 on Juniper SRX300

[Richard McGovern via juniper-nsp]

Yes only MX 
(https://www.juniper.net/documentation/en_US/junos/topics/concept/rfc2544-benchmarking-test-overview.html
 ) and ACX 
(https://www.juniper.net/documentation/en_US/junos/topics/concept/services-rpm-rfc2544-benchmarking-test-overview.html
 ) appear to have generator capabilities.

See also - 
https://apps.juniper.net/feature-explorer/feature-info.html?fKey=6492&fn=RFC%202544-based%20benchmarking%20tests%20for%20Layer%202%20and%20Layer%203%20Ethernet%20services

ACX has built-in loopback capabilities associated with this testing - 
https://apps.juniper.net/feature-explorer/feature-info.html?fKey=7062&fn=Ethernet%20loopback%20support%20for%20RFC%202544-based%20benchmarking%20test

FYI Only.

Richard McGovern
Sr Sales Engineer, Juniper Networks 
978-618-3342
 

On 4/17/19, 11:57 AM, "Emille Blanc"  wrote:

Page 6 of the SRX300 series datasheet states in the fineprint;
16* "Throughput numbers based on UDP packets and RFC2544 test methodology."

That said, I don't see RFC2544 generation and reflection explicitly stated 
anywhere, nor do I see the config syntax supported up to 15.1X49-D160.2

Juniper KB shows ACX and MX as supported platforms, so perhaps you could 
create a loopback on the SRX, or do your tests between routing-instances on the 
MX.

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Matthew Crocker
Sent: Wednesday, April 17, 2019 7:05 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] RFC2544 on Juniper SRX300


Hello,

I have a customer WAN with 20ish SRX300s & 1 MX80 connected and need to 
setup RFC2544 to prove out the WAN circuits.

Is RFC2544 supports on the SRX in later JunOS versions?

I don’t want to go through the process of upgrading the OS and not get 
access to the feature.

Current versions running.


Model: srx300

Junos: 15.1X49-D140.2

JUNOS Software Release [15.1X49-D140.2]


Model: mx80

Junos: 15.1R6.7


___
juniper-nsp mailing list juniper-nsp@puck.nether.net

https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=cViNvWbwxCvdnmDGDIbWYLiUsu8nisqLYXmd-x445bc&m=Zl4v0F03ixB-28jBBONDSH5Cl4fCVCeqQmUmwSzpZqY&s=p8lvnItvZMci6GOFF74QcnY3BKiIweWiFjV5bBsAXis&e=


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

Re: [j-nsp] EVPN-VXLAN: Mixing QFX and EX

[Richard McGovern via juniper-nsp]

Correction - QFX5110 can now route VLAN/IP to VNI via this configuration:

https://www.juniper.net/documentation/en_US/junos/topics/concept/evpn-vxlan-qfx5110-l2-vxlan-l3-logical.html

I was no aware this information had been put out there.  Min SW would be 
17.3R3, but 18.1R3-S[latest, now 4] would be recommended.

Please also note this functionality is not yet 100% supported as a Border Leaf 
for EVPN/VXLAN, so full "support" may not be yet available, despite the 
documentation.  I think this may be major reason this support has not yet been 
announced.  At least as far as I know, outside of this one link, I believe this 
is not announced or documented anywhere else.

Today I am using only 10K or MX as Border Leaf.

FYI


Richard McGovern
Sr Sales Engineer, Juniper Networks 
978-618-3342
 

On 4/16/19, 4:09 PM, "Richard McGovern"  wrote:

5110, can NOT route between VLAN/IP and VXLAN, today.  This is a future 
(some 19.x?).

I do believe that QFX5110 is not really "certified" as a EVPN/VXLAN Spine.  
Your design is what Juniper refers to as CRB - Centralized Route/Bridged.  That 
is, VXLAN L3 at the core, versus the edge.  The core is generally an IP Fabric. 
 

Do matter what, you would need either MX or QFX10K model to talk to outside 
IP world, at least today.  You could talk server to server with your DC, but 
not outside, which I assume is not what you want.

Rich

Richard McGovern
Sr Sales Engineer, Juniper Networks 
978-618-3342
 

On 4/16/19, 9:37 AM, "Vincent Bernat"  wrote:

 ❦ 16 avril 2019 11:04 +00, Ian :

> Thank you, Vincent.
>
> That is weird; it was a very simple layout illustration, I am 
attaching it again.
>
> Ultimate goal is to reduce broadcast domain size while having the
> resources be able to participate in L2 without over-sizing it and
> without using spanning-tree overheads and its risks.

OK. So, the main question is whatever you are expecting to route between
VXLAN (or between a VXLAN and a VLAN). EX4600 is only able to do L2
stuff with VXLAN. 5110 is able to route between VXLAN and may be able
under some conditions to route between a VLAN and a VXLAN.
-- 
10.0 times 0.1 is hardly ever 1.0.
- The Elements of Programming Style (Kernighan & Plauger)





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

Re: [j-nsp] EVPN-VXLAN: Mixing QFX and EX

[Richard McGovern via juniper-nsp]

If you are going to try any code for EVPN/VXLAN testing, I would highly suggest 
using 18.1R3-S4, at least right now.

Rich

Richard McGovern
Sr Sales Engineer, Juniper Networks 
978-618-3342
 

On 4/16/19, 4:21 PM, "Vincent Bernat"  wrote:

 ❦ 16 avril 2019 20:09 +00, Richard McGovern :

> 5110, can NOT route between VLAN/IP and VXLAN, today.  This is a
> future (some 19.x?).

It is believed to be able to do that now:
 
https://www.juniper.net/documentation/en_US/junos/topics/concept/evpn-vxlan-qfx5110-l2-vxlan-l3-logical.html

I was not able to reproduce with 17.4 but I'll try again with 18.1
tomorrow.
-- 
Identify bad input; recover if possible.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [j-nsp] EVPN-VXLAN: Mixing QFX and EX

[Richard McGovern via juniper-nsp]

5110, can NOT route between VLAN/IP and VXLAN, today.  This is a future (some 
19.x?).

I do believe that QFX5110 is not really "certified" as a EVPN/VXLAN Spine.  
Your design is what Juniper refers to as CRB - Centralized Route/Bridged.  That 
is, VXLAN L3 at the core, versus the edge.  The core is generally an IP Fabric. 
 

Do matter what, you would need either MX or QFX10K model to talk to outside IP 
world, at least today.  You could talk server to server with your DC, but not 
outside, which I assume is not what you want.

Rich

Richard McGovern
Sr Sales Engineer, Juniper Networks 
978-618-3342
 

On 4/16/19, 9:37 AM, "Vincent Bernat"  wrote:

 ❦ 16 avril 2019 11:04 +00, Ian :

> Thank you, Vincent.
>
> That is weird; it was a very simple layout illustration, I am attaching 
it again.
>
> Ultimate goal is to reduce broadcast domain size while having the
> resources be able to participate in L2 without over-sizing it and
> without using spanning-tree overheads and its risks.

OK. So, the main question is whatever you are expecting to route between
VXLAN (or between a VXLAN and a VLAN). EX4600 is only able to do L2
stuff with VXLAN. 5110 is able to route between VXLAN and may be able
under some conditions to route between a VLAN and a VXLAN.
-- 
10.0 times 0.1 is hardly ever 1.0.
- The Elements of Programming Style (Kernighan & Plauger)



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

Re: [j-nsp] EVPN/VXLAN experience (was: EX4600 or QFX5110)

[Richard McGovern via juniper-nsp]

Sebastian, a couple of questions.

1.  Your design is pure QFX5100 Leaf/Spine today?  If yes, I assume you maybe 
only have 1 flat VXLAN network, that is you have no L3 VXLAN, yes?
2.  You stated you need 17.4 for improved LACP operation.  Which exact 17.4 are 
you using, and what version were you using previously?  I am wondering if you 
were ever on 17.3-R3-S3?

Many thanks, Rich

Richard McGovern
Sr Sales Engineer, Juniper Networks 
978-618-3342
 

On 3/22/19, 4:39 AM, "Sebastian Wiesinger"  wrote:

* Andrey Kostin  [2019-03-15 20:50]:
> I'm interested to hear about experience of running EVPN/VXLAN, 
particularly
> with QFX10k as L3 gateway and QFX5k as spine/leaves. As per docs, it 
should
> be immune to any single switch downtime, so might be a candidate to really
> redundant design.

All right here it goes:

I can't speak for QFX10k as spine but we have QFX5100 Leaf/Spine
setups with EVPN/VXLAN running right now. Switch downtime is no
problem at all, we unplugged a running switch, shut down ports,
unplugged cables between leaf & spine or leaf & client all while there
was storage traffic (NFS) active in the setup. Worst thing that
happend was that IOPS went down from 400k/s to 100k/s for 1-3 seconds.

What did bother us was that you are limited (at least on QFX5100) in
the amount of "VLANs" (VNIs). We were testing with 30 client
full-trunk ports per leaf and with that amount you can only provision
around 500 VLANs before you get errors and basically it seems you run
out of memory for bridge domains on the switch. This seems to be a
limitation by the chips used in the QFX5100, at least that's what I
got when I asked about it.

You can check if you know where:

root@SW-A:RE:0% ifsmon -Id | grep IFBD
 IFBD   :12884  0

root@SW-A:RE:0% ifsmon -Id | grep Bridge
 Bridge Domain  : 3502   0

These numbers combined need to be <= 16382.

And if you get over the limit these nice errors occur:

dcf_ng_get_vxlan_ifbd_hw_token: Max vxlan ifbd hw token reached 16382
ifbd_create_node: VXLAN IFBD hw token couldn't be allocated for 

Workaround is to decrease VLANs or trunk config.

Also you absolutely NEED LACP from servers to the fabric. 17.4 has
enhancements which will put the client ports in LACP standby when the
leaf gets separated from all spines.

> As a downside I see the more complex configuration at least. Adding
> vlan means adding routing instance etc. There are also other
> questions, about convergence, scalability, how stable it is and code
> maturity.

We have it automated with Ansible. Management access happens over OOB
(Mgmt) ports and everything is pushed by Ansible playbooks. Ansible
generates configuration from templates and pushes it to the switches
via netconf. I never would want to do this by hand. This demands a
certain level of structuring by every team (network, people doing the
cabling, server team) but it works out well for structured setups.

Our switch config looks like this:

--
user@sw1-spine-pod1> show configuration
## Last commit: 2019-03-11 03:13:49 CET by user
## Image name: jinstall-host-qfx-5-flex-17.4R2-S2.3-signed.tgz

version 17.4R1-S3.3;
groups {
/* Created by Ansible */
evpn-defaults { /* OMITTED */ };
/* Created by Ansible */
evpn-spine-defaults { /* OMITTED */ };
/* Created by Ansible */
evpn-spine-1 { /* OMITTED */ };
/* Created by Ansible - Empty group for maintenance operations */
client-interfaces;
}
apply-groups [ evpn-defaults evpn-spine-defaults evpn-spine-1 ];
--

So everything Ansible does is contained in apply-groups and is hidden. You 
can
immediately spot if something is configured by hand.

For code we're currently running on the 17.4 train which works mostly
fine, we had a few problems with third party 40G optics but these
should be fixed in the newest 17.4 service release.

Also we had a problem where new Spine/Leaf links did not come up but
these vanished after rebooting/upgrading the spines.

In daily operations it proves to be quite stable.


Best 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/juni