[c-nsp] Licensing question for ASR9000

[Mattias Gyllenvarg]

In my experience, the guiding principle for what is included in each tier
is designed to force you to select the most advanced tier or at least one
tier higher then you want too by feature gerrymandering.

Not any actual cost on the vendor's part.

Old man's rant I guess.

/Mattias

On Wed, Oct 29, 2025 at 2:24 PM Phil Bedard via cisco-nsp <
cisco-nsp at puck.nether.net> wrote:

> I don’t think anyone really likes licensing.
>
> At Cisco we tend to change the licensing too often.  We have recently
> brought back perpetual licensing for the XR based products.  SIA/RTU is
> used in pay as you grow, which some folks want to do use, but not everyone.
>
> On features there are three license tiers.  Essential, Advanced, and
> Premier.   There are guides on what’s covered by which one but it’s still a
> bit confusing IMO.   Of course we don’t really enforce it, just send syslog
> messages complaining.   Well there is a limitation you can’t upgrade the
> box if the license is expired.
>
> Thanks,
> Phil
>
> From: cisco-nsp <cisco-nsp-bounces at puck.nether.net> on behalf of Aaron1
> via cisco-nsp <cisco-nsp at puck.nether.net>
> Date: Friday, October 24, 2025 at 7:46 PM
> To: Saku Ytti <saku at ytti.fi>
> Cc: Gert Doering <gert at greenie.muc.de>, c-nsp <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] Licensing question for ASR9000
>
> Juniper is doing similar annoying licensing things these days.  Licenses
> tied to every technology, protocol and bandwidth increment.
>
> Actually in the office right now prepping a couple QFX5130-48C boxes for
> new DC rollout and seeing the typical ospf, ldp CLI messages about license
> required.
>
> Aaron
>
> > On Oct 24, 2025, at 2:38 AM, Saku Ytti via cisco-nsp <
> cisco-nsp at puck.nether.net> wrote:
> >
> > On Fri, 24 Oct 2025 at 09:38, Mark Tinka via cisco-nsp
> > <cisco-nsp at puck.nether.net> wrote:
> >
> >> Unfortunately, Cisco are not alone. Juniper are also quickly going down
> >> this path, especially with their newer MX line.
> >>
> >> I have sensed a linear relationship between this strategy and the
> >> growing silence on c-nsp and j-nsp.
> >>
> >> Operators are losing interest.
> >
> > In principle I am not against licensing. I do sympathise to a degree
> > with vendor's struggling with the business case of providing routers
> > for SP customers.
> >
> > In an ideal world license would help to put cost where demand is, as
> > we constantly do see quite stupid features arriving that some customer
> > with big RFP pushed, which adds fragility, complexity and cost to
> > everyone. But of course in the world we actually live in, licenses are
> > motivated by need to increase revenue, not to distribute it where the
> > use is.
> >
> > Investors love to hear the YRC/MRC story, instead of one off purchase
> > story, and it already feels like we are leasing routers not buying,
> > considering support costs more than the devices over the lifetime. And
> > many of us only pay the support, because software is bad, creating
> > perverse incentive for software quality.
> >
> > Having gotten that rant out of the way. The situation isn't too dire,
> > both Cisco and Juniper allow you to use licenses in such a way that
> > the device doesn't degrade customer services while in service, despite
> > licenses. And I would encourage everyone to reject the notion where
> > license issues cause customer observable issues.
> >
> > I am fine with the process where we /must/ configure call-come, and
> > this call-home should support HTTP (not S) proxy. Where HTTPS proxy
> > then calls the vendor.  The data sent should be human readable, like
> > JSON, YAML with no mystery strings or byte arrays so we can confirm no
> > sensitive data is extracted.
> > And upon license expiration or call-home not working, your account
> > team would make it a business problem, not a technical problem of
> > service users.
> >
> > I know that smart licenses can be set up in such a way that license
> > expiration causes outages, but I've always rejected that solution from
> > Cisco and they do provide alternatives. We've tried to get HTTPS
> > certificates working for +20years and still for most of BCP appears to
> > be 'wait until they expire and you have an outage, then panic and
> > swear it'll be handled properly from now on'.  Idea that we wouldn't
> > have process problems renewing licenses constantly is naive.
> >
> >
> >
> >
> >
> >
> >
> > --
> >  ++ytti
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>


-- 
*Med Vänliga Hälsningar / Best Regards*
*Mattias Gyllenvarg*