Mailing List Archive

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

On Thu, 26 Oct 2023 at 16:40, Mark Tinka via juniper-nsp
<juniper-nsp@puck.nether.net> 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

#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" <mark@tinka.africa> 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

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

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

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

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

Oh they aren't?

https://www.arista.com/en/support/product-documentation/eos-feature-licensing

Arista will almost certainly move towards a licensing model similar to
other vendors at some point once their growth curve slows and they need to
start squeezing more revenue out of what they are selling.



On Wed, Oct 25, 2023 at 9:36?AM Gert Doering via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

> Hi,
>
> On Wed, Oct 25, 2023 at 12:50:33PM +0000, 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
> gert@greenie.muc.de
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Hi,

On Thu, Oct 26, 2023 at 12:09:39PM -0400, Tom Beecher wrote:
> > Did I mention Arista is not spending valuable engineer time on all this
> > license shit, but on actually making great products?
>
> Oh they aren't?
>
> https://www.arista.com/en/support/product-documentation/eos-feature-licensing

There are licenses, and they do expect you to actually buy them (which
I do not particularily object to, as long as the license price is not
like 5x the price of the hardware).

But there is no single line of code *anywhere* that deals with licensing,
not only "no enforcement" but actually no way to even enter any sort of
licensing thing into the device itself.

As I said, their engineers are busy making good products. Other vendors
prefer to build convoluted license checking/enforcement schemes, and
neglect overall software quality. We've made our choice.

> Arista will almost certainly move towards a licensing model similar to
> other vendors at some point once their growth curve slows and they need to
> start squeezing more revenue out of what they are selling.

We'll see. Maybe there will be someone else then who is not intent on
annoying their customers, but on actually building a good working
relationship.

(I do seem to remember that at a time Juniper had the reputation on
very high quality software, and a good TAC, and 'that other vendor'
started doing the licensing bullshit, driving customers away... seems
someone in product marketing misunderstood the "market leader" bullshit
from 'that other vendor' in a big way)

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 gert@greenie.muc.de

Base licensing is useful if you self-spare, such that the capital invested
in cold spares sitting in a warehouse is significantly less than the full
cost of the device with licensing.

On Wed, Oct 25, 2023 at 9:53?AM Michael Hare via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

> 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 <juniper-nsp-bounces@puck.nether.net> On Behalf Of
> > Richard McGovern via juniper-nsp
> > Sent: Wednesday, October 25, 2023 7:51 AM
> > To: Saku Ytti <saku@ytti.fi>; Aaron Gould <aaron1@gvtc.com>
> > Cc: Karl Gerhard <karl_gerh@gmx.at>; 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" <saku@ytti.fi> wrote:
> > On Tue, 24 Oct 2023 at 22:21, Aaron Gould via juniper-nsp
> > <juniper-nsp@puck.nether.net<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
> _______________________________________________
> 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