[c-nsp] Licensing question for ASR9000

[Aaron1]

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/