[c-nsp] Licensing question for ASR9000

Shawn L shawn at rmrf.us
Fri Oct 24 10:06:37 EDT 2025


It would be really nice if Cisco (and their TAC engineers) actually knew
how to setup call-home in different environments.  Admittedly it's been a
while, but we had a 9K (9901) that we needed to add licensing to before we
trucked it out to a site.  Our plan was to setup management, upgrade to the
latest recommended firmware, get licensing setup and then put the needed
config on it.  Do some basic bench testing to make sure the interfaces came
up, etc.

Come to find out, you can't do call-home from the physical management
interface (that took TAC an hour or 2 to figure out).  I guess it should
have been obvious, since you can't add a default route to the physical
management interface.  So, hook one of the 'regular' interfaces up to an
internet connection, put some temporary config in place, call-home now
works.  Then tear that all out, put in the actual config.  It's not a huge
deal.  Just kind of a pain.

On Fri, Oct 24, 2025 at 3:37 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/
>


More information about the cisco-nsp mailing list