On 10/25/23 14:42, Saku Ytti via juniper-nsp wrote:
But we can reject licenses that expire in operation and cause an outage. That I think is a very reasonable ask. I know that IOS XE for example will do this, you run out of license and your box breaks. I swapped out from CRS1k to ASR1k because I knew the organisation would eventually fail to fix the license ahead of expiry.
We had this happen to us in 2014 when we recovered a failed server running CSR1000v. The "installation evaluation" license expired after 60 days, and since everyone forgot about it, the box went down.
So as part of our deployment/recovery procedure, we always procure CSR1000v licenses for each installation.
Of course, with things changing to Cat8000v, this could get juicy.
I'm happy if the device calls homes via https proxy, and reports my license use, and the sales droid tells me I'm not compliant with terms. Making it a commercial problem is fine, making it an acute technical problem is not. In your specific case, the ports never worked, you had to procure a license, and the license never dies. So from my POV, this is fine. And being absolutist here will not help, as then you can't even achieve reasonable compromise.
I tend to agree. Mark. _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
