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 > <[email protected]> wrote: > > On Fri, 24 Oct 2025 at 09:38, Mark Tinka via cisco-nsp > <[email protected]> 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 [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
