subject:"\[j\-nsp\] MX304 \- Edge Router"




On 10/26/23 16:10, Aaron Gould wrote:
After tshooting with JTAC yesterday, they've determined the built-in 
FPC to be a problem.  They are doing RMA.


Strange that when the 60-day trail license expired, I decided to 
reboot to see what would happen.  I rebooted "request system reboot 
both-routing-engines" and that's when the router never worked after 
that.  Strange that this would "fry" the FPC.  Maybe there was already 
something wrong with it... I don't know. Perhaps I'll try to reproduce 
it after the new chassis comes back.


-Aaron

I wonder if the "request vmhost reboot routing-engine both" would've 
done anything differently


According to the documentation, re1 is also seen as fpc0 if you put an 
LMIC in it. Would have been good to troubleshoot by putting an LMIC in 
the re1 slot to see if that works. But since re1 is fpc0/pic2, then it 
probably wouldn't work if JTAC are saying it's an FPC failure.


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

Re: [j-nsp] MX304 - Edge Router

2023-10-26 Thread Aaron Gould via juniper-nsp

After tshooting with JTAC yesterday, they've determined the built-in FPC 
to be a problem.  They are doing RMA.


Strange that when the 60-day trail license expired, I decided to reboot 
to see what would happen.  I rebooted "request system reboot 
both-routing-engines" and that's when the router never worked after 
that.  Strange that this would "fry" the FPC.  Maybe there was already 
something wrong with it... I don't know. Perhaps I'll try to reproduce 
it after the new chassis comes back.


-Aaron

I wonder if the "request vmhost reboot routing-engine both" would've 
done anything differently



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

Re: [j-nsp] MX304 - Edge Router





On 10/26/23 15:47, Saku Ytti wrote:

I urge everyone to give them the same message as I've given.

Any type of license, even timed license, after it expires will not
cause an outage. And enforcement would be 'call home' via 'http(s)'
proxy, which reports the license-use data to Juniper sales, making it
a commercial problem between Juniper and you.

Proxy, so that you don't need Internet access on the device.
Potentially you could ask for encryption-less mode, if you want to log
on the proxy what is actually being sent to the vendor. I don't give
flying or any other method of locomotion fuck about leaking
information.

I believe this is a very reasonable give/take compromise which is
marketable, but if we try to start punching holes through esoteric
concerns, we'll get boxes which die periodically because someone
forgot to re-up. This is a real future that may happen, unless we
demand it must not.


I agree.

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

Re: [j-nsp] MX304 - Edge Router

2023-10-26 Thread 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

2023-10-26 Thread Saku Ytti via juniper-nsp

On Thu, 26 Oct 2023 at 16:40, Mark Tinka via juniper-nsp
 wrote:

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

I urge everyone to give them the same message as I've given.

Any type of license, even timed license, after it expires will not
cause an outage. And enforcement would be 'call home' via 'http(s)'
proxy, which reports the license-use data to Juniper sales, making it
a commercial problem between Juniper and you.

Proxy, so that you don't need Internet access on the device.
Potentially you could ask for encryption-less mode, if you want to log
on the proxy what is actually being sent to the vendor. I don't give
flying or any other method of locomotion fuck about leaking
information.

I believe this is a very reasonable give/take compromise which is
marketable, but if we try to start punching holes through esoteric
concerns, we'll get boxes which die periodically because someone
forgot to re-up. This is a real future that may happen, unless we
demand it must not.

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

Re: [j-nsp] MX304 - Edge Router

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





On 10/26/23 08:02, Saku Ytti wrote:

Even if you believe/think this, it is not in your best interest to
communicate anything like this, there is nothing you can win, and
significant downside potential.


As you can probably tell, I am not terribly politically correct :-). The 
coddle culture we live in today only ends up creating a generation that 
will not be competitive in the open market, because whether we like it 
or not, only competence gets compensated.


You really can't force people to give you their money for a poor, 
expensive job done, much as we may believe it should be the case. 8th 
place trophies should never be a model.

I believe the question is not about what data says, the question is,
why does the data say that. And the thesis/belief is, data should not
say that, that there is no fundamental reason why the data would say
so. The question is, is the culture reinforcing this from day0,
causing people to believe it is somehow inherent/natural.


The reason the data should not say that is because there has been a 
serious amount of investment in creating scientists, engineers, 
mathematicians, technologists, CEO's and inventors from the female 
community over the past couple of decades. And yet, all the metrics 
still show that women are "under-represented" in these areas.


So the explanation ends up going back to "upbringing, cultural 
socialization, oppression by men, e.t.c.". After all, if a woman has the 
opportunity to do male-dominated jobs or study male-dominated subjects, 
why wouldn't she, for whatever reason that may or may not be useful to 
her own person? After all, nothing screams equality like doing exactly 
what men can do, or what women can do.


In other words, the idea that women (and little girls) may not have any 
personal interest in things that men are inherently interested in is 
completely inconceivable.

>From scientific POV, we currently don't have any real reason to
believe there are unplastic differences in the brain from birth which
cause this. There might, but science doesn't know that. Scientifically
we should today expect very even distribution, unless culturally
biased.


When we refuse to believe that, in general, men prefer building things 
and women prefer dealing with people, we are essentially trying to fix 
innately biological differences with culture. And while culture, on 
paper, sounds and feels good because it either elicits emotion (instead 
of logic) or results in censorship (instead of discourse), more often 
than not, biology always wins out. It's a bit like weight loss... you 
may starve yourself to lose excess body fat, but eventually, hunger 
always wins. So you need another strategy, one which maximizes weight 
loss, but without leaving your ravenous.


The sad part is that by the time biology takes over, it is too late for 
the individual to benefit from a different decision they could have 
taken, earlier on in life. And what is worse for the next generation, is 
that those poor outcomes that afflict the individuals in their mid-40's 
or later, are never communicated down to the kids... because if that 
happens, the simulation that culture trumps biology would inevitably 
crumble. And that's just bad for business...



But of course inequality, inequitability is everywhere, not an
hyperbole, but you can't compare anything on how we choose who does
what and come up with anything that resembles fair distribution. Zip
code has a lot of predictive power where you'll end up in your life,
and that is hardly your fault or merit. Top level managers are not
just disproportionately men, but they are disproportionately men with
+1.5SD height, and there is no scientific reason to believe zip code
or height suggests stronger ability.

It is just a really unfair world to live in, but luckily I am on the
beneficiary side of the unfairness, which I am strong enough to
accept.


Well, the problem comes with how we define "fairness". If we say 
fairness is both men and women should have access to the same 
opportunities, that is fine. But if we say that fairness is both men and 
women should have the same outcomes, that becomes problematic. If equal 
outcome worked, half of all CEO's would be women, as much as half of all 
coal miners would be women. It's not like there is a shortage of 
corporations or mining companies looking to fill half of their staff 
with women... and yet they do not. Instead of looking deeply into why 
that is, popular culture will simply chalk it down to anything other 
than "opportunity" and "personal interest", e.g., being passed over, 
sexism, racism, pay gap, e.t.c.


Moreover, since the "pay gap" suggests that women will earn less than 
men in any field where both are employable, you'd think that those 
companies would be 90% female-dominated, as they would be a lower 
cost-to-company. But again, that is not happening... why? It certainly 
can't be the combination of personal interest + meritocracy, can it :-)?

I have

Re: [j-nsp] MX304 - Edge Router

2023-10-26 Thread Saku Ytti via juniper-nsp

On Thu, 26 Oct 2023 at 07:45, Mark Tinka via juniper-nsp
 wrote:

> While there are some women who enjoy engineering, and some men who enjoy
> nursing, most women don't enjoy engineering, and most men don't enjoy
> nursing. I think we would move much farther ahead if we accepted this,

> If you look at the data, on average, 70% of new enrollments at
> university are women, and 60% of all graduands are women. And yet, 90%
> of all STEM students are men, while 80% of all psychology students are
> women. Perhaps there is a clue in there :-)...

Even if you believe/think this, it is not in your best interest to
communicate anything like this, there is nothing you can win, and
significant downside potential.

I believe the question is not about what data says, the question is,
why does the data say that. And the thesis/belief is, data should not
say that, that there is no fundamental reason why the data would say
so. The question is, is the culture reinforcing this from day0,
causing people to believe it is somehow inherent/natural.

>From scientific POV, we currently don't have any real reason to
believe there are unplastic differences in the brain from birth which
cause this. There might, but science doesn't know that. Scientifically
we should today expect very even distribution, unless culturally
biased.

But of course inequality, inequitability is everywhere, not an
hyperbole, but you can't compare anything on how we choose who does
what and come up with anything that resembles fair distribution. Zip
code has a lot of predictive power where you'll end up in your life,
and that is hardly your fault or merit. Top level managers are not
just disproportionately men, but they are disproportionately men with
+1.5SD height, and there is no scientific reason to believe zip code
or height suggests stronger ability.

It is just a really unfair world to live in, but luckily I am on the
beneficiary side of the unfairness, which I am strong enough to
accept.

I have a curious anecdote about discriminatory outcomes, without any
active discrimination. I think it's easier to discuss as it doesn't
include any differences in the groups of people really. In Finland a
minority natively speaks Swedish, majority Finnish. After 1000 years,
the minority continues to statistically have better education, live
longer, have more savings and higher salary. For this particular
example, only rationale I've come up, which could explain it, is that
the Swedish speaking minority choose other Swedish speaking people as
their peers, so they feel lower sense of accomplishment performing at
Finnish speaker mean level, which causes them to push themselves
little bit further to achieve same satisfaction level as Finnish
speaking majority would feel at lower level of accomplishment. Causing
it to perpetuate indefinitely despite having 'fixed' all active
discriminatory biases since forever. That is, if you ever create,
through any mechanism at all, some biasing between groups, this bias
will never completely go away.

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

Re: [j-nsp] MX304 - Edge Router




On 10/25/23 21:02, Richard McGovern via juniper-nsp wrote:


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” 


At the risk of derailing this thread, one item that is generally 
programmed into an agenda of your favourite NOG conference is "Women In 
Tech". For over 10 years, the agenda has always been the same... why 
aren't there more women in our field, what can we do about it, and what 
is the experience of those few women that are in the field?


After 10 years, I finally asked the question at a recent meeting earlier 
this year - could it be that we may be ignoring and/or underestimating 
the value and power of personal choice and interest?


While there are some women who enjoy engineering, and some men who enjoy 
nursing, most women don't enjoy engineering, and most men don't enjoy 
nursing. I think we would move much farther ahead if we accepted this, 
and stopped trying to force-feed people stuff that does not interest 
them. That way, we give a real chance to those that are interested and 
make sure we don't risk people's future by placing them in subjects and 
fields where they will not be able to compete fairly with those who 
really want to be there.


If you look at the data, on average, 70% of new enrollments at 
university are women, and 60% of all graduands are women. And yet, 90% 
of all STEM students are men, while 80% of all psychology students are 
women. Perhaps there is a clue in there :-)...


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

Re: [j-nsp] MX304 - Edge Router

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, and reports my
> license use, and the sales droid

Re: [j-nsp] MX304 - Edge Router

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

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 
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://urldefense.com/v3/__https://puck.nether.net/mailman/listi

Re: [j-nsp] MX304 - Edge Router

2023-10-25 Thread Ola Thoresen via juniper-nsp

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" 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

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<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$>


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

Re: [j-nsp] MX304 - Edge Router

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

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"  wrote:
> On Tue,

Re: [j-nsp] MX304 - Edge Router

2023-10-25 Thread Michael Hare via juniper-nsp

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
> 
> 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 lice

Re: [j-nsp] MX304 - Edge Router

2023-10-25 Thread Michael Hare via juniper-nsp

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  On Behalf Of
> Saku Ytti via juniper-nsp
> Sent: Wednesday, October 25, 2023 7:43 AM
> To: Aaron1 
> Cc: juniper-nsp 
> Subject: Re: [j-nsp] MX304 - Edge Router
> 
> On Wed, 25 Oct 2023 at 15:26, Aaron1 via juniper-nsp
>  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://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX304 - Edge Router

2023-10-25 Thread Aaron Gould via juniper-nsp


22.2R3.15

On 10/25/2023 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.



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

Re: [j-nsp] MX304 - Edge Router




On 10/25/23 16:00, Gert Doering wrote:


What is "high-touch edge" for you?

Most things we could come up with do work, with the notable exception
of MAC accounting (or inclusion of MAC addresses in sflow/ipfix) - but
here the ASR9000 is one of the few platforms on the market that can
actually do it.  So more of a chip limitation.

We don't do extremely demanding QoS things, but basic shaping and policing
works fine on the new J2c+ boxes.  So not sure where the limits are.

Of course it's merchant silicon boxes, but the J2c chips have become
really impressive.


Good to hear.

The main things that have typically been an issue for us on 
Broadcom-based boxes have been:


    - Egress policing (trTCM).
    - uRPF (IPv4/IPv6).
    - Ingress/Egress marking (Policy Map a la Junos).
    - EVC + VLAN Tag Rewrite (push, pop, swap).
    - IPv4/IPv6 interface ACL's (should be pretty doable now).
    - LDPv6 (not chip related, just code).

Has your experience on Arista been that all those work?

We have a ton of Arista hardware, but we just use it purely for Layer 2 
switching.


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

Re: [j-nsp] MX304 - Edge Router

2023-10-25 Thread Crist Clark via juniper-nsp

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://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX304 - Edge Router

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 solv

Re: [j-nsp] MX304 - Edge Router

2023-10-25 Thread Gert Doering via juniper-nsp

Hi,

On Wed, Oct 25, 2023 at 03:44:57PM +0200, Mark Tinka via juniper-nsp wrote:
> > Did I mention Arista is not spending valuable engineer time on all this
> > license shit, but on actually making great products?
> 
> What is the current experience of the code for IP/MPLS functions that go
> beyond simply peering and transit, i.e., high-touch edge?

What is "high-touch edge" for you?

Most things we could come up with do work, with the notable exception
of MAC accounting (or inclusion of MAC addresses in sflow/ipfix) - but
here the ASR9000 is one of the few platforms on the market that can 
actually do it.  So more of a chip limitation.

We don't do extremely demanding QoS things, but basic shaping and policing
works fine on the new J2c+ boxes.  So not sure where the limits are.

Of course it's merchant silicon boxes, but the J2c chips have become
really impressive.

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

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

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

Re: [j-nsp] MX304 - Edge Router

2023-10-25 Thread Eric Harrison via juniper-nsp

Yes indeed having dhcp-relay by default trigger scale-l2tp -- a licensed
subscriber management feature -- is quite annoying.

"set forwarding-options dhcp-relay forward-only" will turn off that
licensing requirement.  IIRC there were scalpel knobs to accomplish the
same, we opted for the hammer knob.



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

> On Wed, Oct 25, 2023 at 03:12:29PM +0200, Mark Tinka via juniper-nsp wrote:
> > On 10/25/23 10:57, Sebastian Wiesinger via juniper-nsp wrote:
> > > Yeah it depends. Our MX204 also needed licenses for subscriber
> > > managment. Some options would produce a license warning and some other
> > > stuff just failed silently which was worse. Also noone at Juniper
> > > seemed to know WHICH licenses we needed for our usecase.
> > >
> > > In the end our license list looked like this:
> > >
> > > subscriber-accounting
> > > subscriber-authentication
> > > subscriber-address-assignment
> > > subscriber-vlan
> > > subscriber-ip
> > > scale-subscriber
> > > scale-l2tp
> > > l2tp-inline-lns
> > >
> > > So yeah.. that wasn't a nice experience at all.
> >
> > Subscriber Management has always required real licenses on the MX since
> > it started shipping BNG code.
> >
> > You got 1,000 subscribers as standard, and then needed an enforceable
> > license after that.
>
> This caused us heartburn for our Campus LAN when we upgraded as we had
> been using "forwarding-options helpers bootp" and were told that it
> was deprecated and we needed to move to "forwarding-options
> dhcp-relay" which is a BNG feature that requires a subscriber
> license--a ridiculous requirement for a Campus LAN.  It turns out that
> "helpers bootp" still worked, and may still work today, but I'm no
> longer working in that environment so I'm not sure.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


-- 
Eric Harrison
Network Services
Cascade Technology Alliance / Multnomah Education Service District
office: 503-257-1554   cell: 971-998-6249   NOC 503-257-1510
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX304 - Edge Router





On 10/25/23 15:36, Gert Doering via juniper-nsp wrote:


There goes another vendor...

Now, if the base price would have been *lowered* by the amount the
L3 features of a *MX router* cost extra now, this might have been an
option... but for my understanding, the base MX304 is already insanely
pricey, and then add licenses on top...  nah, taking our money elsewhere.


Based on quotes we've seen so far, 75% of the list price of an MX304 is 
just the license for the entire chassis (separate from the line cards 
and without support).



Did I mention Arista is not spending valuable engineer time on all this
license shit, but on actually making great products?


What is the current experience of the code for IP/MPLS functions that go 
beyond simply peering and transit, i.e., high-touch edge?


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

Re: [j-nsp] MX304 - Edge Router

2023-10-25 Thread Gert Doering via juniper-nsp

Hi,

On Wed, Oct 25, 2023 at 12:50:33PM +, Richard McGovern via juniper-nsp 
wrote:
> 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.

There goes another vendor...

Now, if the base price would have been *lowered* by the amount the
L3 features of a *MX router* cost extra now, this might have been an
option... but for my understanding, the base MX304 is already insanely
pricey, and then add licenses on top...  nah, taking our money elsewhere.

Did I mention Arista is not spending valuable engineer time on all this
license shit, but on actually making great products?

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

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

Re: [j-nsp] MX304 - Edge Router

2023-10-25 Thread Chuck Anderson via juniper-nsp

On Wed, Oct 25, 2023 at 03:12:29PM +0200, Mark Tinka via juniper-nsp wrote:
> On 10/25/23 10:57, Sebastian Wiesinger via juniper-nsp wrote:
> > Yeah it depends. Our MX204 also needed licenses for subscriber
> > managment. Some options would produce a license warning and some other
> > stuff just failed silently which was worse. Also noone at Juniper
> > seemed to know WHICH licenses we needed for our usecase.
> >
> > In the end our license list looked like this:
> >
> > subscriber-accounting
> > subscriber-authentication
> > subscriber-address-assignment
> > subscriber-vlan
> > subscriber-ip
> > scale-subscriber
> > scale-l2tp
> > l2tp-inline-lns
> >
> > So yeah.. that wasn't a nice experience at all.
> 
> Subscriber Management has always required real licenses on the MX since 
> it started shipping BNG code.
> 
> You got 1,000 subscribers as standard, and then needed an enforceable 
> license after that.

This caused us heartburn for our Campus LAN when we upgraded as we had
been using "forwarding-options helpers bootp" and were told that it
was deprecated and we needed to move to "forwarding-options
dhcp-relay" which is a BNG feature that requires a subscriber
license--a ridiculous requirement for a Campus LAN.  It turns out that
"helpers bootp" still worked, and may still work today, but I'm no
longer working in that environment so I'm not sure.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX304 - Edge Router





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://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX304 - Edge Router





On 10/25/23 10:57, Sebastian Wiesinger via juniper-nsp wrote:

Yeah it depends. Our MX204 also needed licenses for subscriber
managment. Some options would produce a license warning and some other
stuff just failed silently which was worse. Also noone at Juniper
seemed to know WHICH licenses we needed for our usecase.

In the end our license list looked like this:

subscriber-accounting
subscriber-authentication
subscriber-address-assignment
subscriber-vlan
subscriber-ip
scale-subscriber
scale-l2tp
l2tp-inline-lns

So yeah.. that wasn't a nice experience at all.


Subscriber Management has always required real licenses on the MX since 
it started shipping BNG code.


You got 1,000 subscribers as standard, and then needed an enforceable 
license after that.


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

Re: [j-nsp] MX304 - Edge Router





On 10/25/23 08:01, Saku Ytti via juniper-nsp wrote:


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'.


I spoke to my SE about this today, and he checked with the PLM. While a 
license can be purchased to quiet the logs, it is not necessary for 
routing protocols to work.


If you buy your MX304 from Juniper, you will pay for a license anyway.

He thinks the issue the OP experienced where routing protocols did not 
work after the reboot is an unrelated issue to licenses.


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

Re: [j-nsp] MX304 - Edge Router