Mailing List Archive

On 20/Jul/20 19:20, Seth Mattinen wrote:
> Does Cisco no longer honor previously purchased perpetual CSR1000V
> licenses now that they're EOS? I had a host die and reinstalling the
> VM (ESXi) from the OVA results in a new serial number my license file
> won't work on, and trying to use the online license manager to rehost
> it claims the new serial number is invalid. I tried opening a case
> online but it's been unanswered for a week now.
>
> Has anyone tried to rehost a CSR1000V after hardware failure and got
> the invalid serial number error, and how did you get that fixed?

Do you know when this capability was EoL'ed?

We recently re-hosted some CSR1000v and ASR1002-X licenses as recently
as August last year.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On 7/20/20 9:58 PM, Mark Tinka wrote:
>
> On 20/Jul/20 19:20, Seth Mattinen wrote:
>> Does Cisco no longer honor previously purchased perpetual CSR1000V
>> licenses now that they're EOS? I had a host die and reinstalling the
>> VM (ESXi) from the OVA results in a new serial number my license file
>> won't work on, and trying to use the online license manager to rehost
>> it claims the new serial number is invalid. I tried opening a case
>> online but it's been unanswered for a week now.
>>
>> Has anyone tried to rehost a CSR1000V after hardware failure and got
>> the invalid serial number error, and how did you get that fixed?
> Do you know when this capability was EoL'ed?
>
> We recently re-hosted some CSR1000v and ASR1002-X licenses as recently
> as August last year.


Someone jumped in and sent me an updated license. As far as why it can't
be done online, I'm not sure. I haven't tried to rehost anything in a while.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On 21/Jul/20 17:34, Seth Mattinen wrote:

>
>
> Someone jumped in and sent me an updated license. As far as why it
> can't be done online, I'm not sure. I haven't tried to rehost anything
> in a while.

The joy of when things just work :-).

We had to because we had some boxes fail in that period. Fair point, the
servers had been nearly 7 years old, so can't blame them.

Nonetheless, glad you're back up and running.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

We don’t buy anything that can’t be managed with a serial connection. That means no fancy web based guis. Licensing is in the same category… A piece of equipment has to do something extraordinary before we’d consider purchasing it, if it implements some sort of license key scheme. We’ve purchased Juniper M series routers in the past and were extremely happy with them (Hey! They actually did what Juniper said they would do without 2 or 3 rounds of hardware upgrades), but I was initially put off because there are license keys embedded in the base software. Then I realized that when the keys expired in 10 years, the boxes would be in the landfill by that time...

Joe


Joe McGuckin
ViaNet Communications

joe@via.net
650-207-0372 cell
650-213-1302 office
650-969-2124 fax



> On Jul 21, 2020, at 8:44 AM, Mark Tinka <mark.tinka@seacom.com> wrote:
>
>
>
> On 21/Jul/20 17:34, Seth Mattinen wrote:
>
>>
>>
>> Someone jumped in and sent me an updated license. As far as why it
>> can't be done online, I'm not sure. I haven't tried to rehost anything
>> in a while.
>
> The joy of when things just work :-).
>
> We had to because we had some boxes fail in that period. Fair point, the
> servers had been nearly 7 years old, so can't blame them.
>
> Nonetheless, glad you're back up and running.
>
> Mark.
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On 21/Jul/20 18:54, joe mcguckin wrote:
> We don’t buy anything that can’t be managed with a serial connection. That means no fancy web based guis.

iLO on servers is pretty reliable. It has helped us out plenty times.


> Licensing is in the same category… A piece of equipment has to do something extraordinary before we’d consider purchasing it, if it implements some sort of license key scheme. We’ve purchased Juniper M series routers in the past and were extremely happy with them (Hey! They actually did what Juniper said they would do without 2 or 3 rounds of hardware upgrades), but I was initially put off because there are license keys embedded in the base software. Then I realized that when the keys expired in 10 years, the boxes would be in the landfill by that time...

Well, pretty much everything shipping these either has or can be
deployed by license.

It is the key way for vendors to implement the same silicon across a
myriad of platforms, without "losing" money.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

ethernet console should be on the list.

On Tue, Jul 21, 2020 at 1:01 PM joe mcguckin <joe@via.net> wrote:

> We don’t buy anything that can’t be managed with a serial connection. That
> means no fancy web based guis. Licensing is in the same category… A piece
> of equipment has to do something extraordinary before we’d consider
> purchasing it, if it implements some sort of license key scheme. We’ve
> purchased Juniper M series routers in the past and were extremely happy
> with them (Hey! They actually did what Juniper said they would do without 2
> or 3 rounds of hardware upgrades), but I was initially put off because
> there are license keys embedded in the base software. Then I realized that
> when the keys expired in 10 years, the boxes would be in the landfill by
> that time...
>
> Joe
>
>
> Joe McGuckin
> ViaNet Communications
>
> joe@via.net
> 650-207-0372 cell
> 650-213-1302 office
> 650-969-2124 fax
>
>
>
> > On Jul 21, 2020, at 8:44 AM, Mark Tinka <mark.tinka@seacom.com> wrote:
> >
> >
> >
> > On 21/Jul/20 17:34, Seth Mattinen wrote:
> >
> >>
> >>
> >> Someone jumped in and sent me an updated license. As far as why it
> >> can't be done online, I'm not sure. I haven't tried to rehost anything
> >> in a while.
> >
> > The joy of when things just work :-).
> >
> > We had to because we had some boxes fail in that period. Fair point, the
> > servers had been nearly 7 years old, so can't blame them.
> >
> > Nonetheless, glad you're back up and running.
> >
> > Mark.
> > _______________________________________________
> > cisco-nsp mailing list cisco-nsp@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@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On 21/Jul/20 18:54, joe mcguckin wrote:
> We don’t buy anything that can’t be managed with a serial connection. That means no fancy web based guis.

iLO on servers is pretty reliable. It has helped us out plenty times.


> Licensing is in the same category… A piece of equipment has to do something extraordinary before we’d consider purchasing it, if it implements some sort of license key scheme. We’ve purchased Juniper M series routers in the past and were extremely happy with them (Hey! They actually did what Juniper said they would do without 2 or 3 rounds of hardware upgrades), but I was initially put off because there are license keys embedded in the base software. Then I realized that when the keys expired in 10 years, the boxes would be in the landfill by that time...

Well, pretty much everything shipping these days either has or can be
deployed by license.

It is the key way for vendors to implement the same silicon across a
myriad of platforms, without "losing" money.

Mark.

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

I'm gonna hate when Flash is EOL. We have servers that use that GUI thing.
I agree, I hate it too.
I don't want to throw out a decent server just because flash no longer
works. I hope Adobe don't have a programmed kill switch.

On Tue, Jul 21, 2020 at 1:21 PM Mark Tinka <mark.tinka@seacom.com> wrote:

>
>
> On 21/Jul/20 18:54, joe mcguckin wrote:
> > We don’t buy anything that can’t be managed with a serial connection.
> That means no fancy web based guis.
>
> iLO on servers is pretty reliable. It has helped us out plenty times.
>
>
> > Licensing is in the same category… A piece of equipment has to do
> something extraordinary before we’d consider purchasing it, if it
> implements some sort of license key scheme. We’ve purchased Juniper M
> series routers in the past and were extremely happy with them (Hey! They
> actually did what Juniper said they would do without 2 or 3 rounds of
> hardware upgrades), but I was initially put off because there are license
> keys embedded in the base software. Then I realized that when the keys
> expired in 10 years, the boxes would be in the landfill by that time...
>
> Well, pretty much everything shipping these days either has or can be
> deployed by license.
>
> It is the key way for vendors to implement the same silicon across a
> myriad of platforms, without "losing" money.
>
> Mark.
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Tue, Jul 21, 2020 at 01:23:12PM -0400, Aaron wrote:
> I'm gonna hate when Flash is EOL. We have servers that use that GUI thing.
> I agree, I hate it too.
> I don't want to throw out a decent server just because flash no longer
> works. I hope Adobe don't have a programmed kill switch.

Supposedly they do in the latest versions. And on a computer I've kept
back in versions that I regularly use, it keeps trying to update its'
flash to the latest version every hour. :-(

Since we currently have well over 100 devices and things needing Flash
for management, and I'm sure there are lots of people in the same
boat. Many of them have no path forward for a non-flash solution. Many to date
don't yet have a non-flash version even available, just promised for the "future"..
And with about 5 months left to the kill switch date....

I'm sure somebody will be developing some packaged solution around old
versions of browsers/flash module/firewall rules to allow us to continue to do management.
Its happened in the past (ie. Java applet versions and browsers that worked together).

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On 7/21/20 09:54, joe mcguckin wrote:
> We don’t buy anything that can’t be managed with a serial connection. That means no fancy web based guis. Licensing is in the same category… A piece of equipment has to do something extraordinary before we’d consider purchasing it, if it implements some sort of license key scheme. We’ve purchased Juniper M series routers in the past and were extremely happy with them (Hey! They actually did what Juniper said they would do without 2 or 3 rounds of hardware upgrades), but I was initially put off because there are license keys embedded in the base software. Then I realized that when the keys expired in 10 years, the boxes would be in the landfill by that time...


The CSR1000V licenses were just so cost effective for building route
reflectors on ESXi compared to the cost of physical hardware. It's a
shame the perpetual licenses are gone in favor of subscriptions.

As a small operator I've had a lot of effectively new off lease
equipment pass through my doors, and expiring license keys don't really
favor that.

~Seth
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Hi,

On Wed, Jul 22, 2020 at 09:44:44AM -0700, Seth Mattinen wrote:
> As a small operator I've had a lot of effectively new off lease
> equipment pass through my doors, and expiring license keys don't really
> favor that.

Works as designed.

"We do not want you to re-use stuff that we're not making money on!".

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de

On 22/Jul/20 18:44, Seth Mattinen wrote:

>
> The CSR1000V licenses were just so cost effective for building route
> reflectors on ESXi compared to the cost of physical hardware. It's a
> shame the perpetual licenses are gone in favor of subscriptions.
>
> As a small operator I've had a lot of effectively new off lease
> equipment pass through my doors, and expiring license keys don't
> really favor that.

Is this part of their new Smart Licensing strategy?

We are still running IOS XE 3.17S on our CSR1000v RR's, and that still
uses the trusty Permanent AX license.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Thu, 23 Jul 2020 at 08:50, Mark Tinka <mark.tinka@seacom.com> wrote:

> Is this part of their new Smart Licensing strategy?
>
> We are still running IOS XE 3.17S on our CSR1000v RR's, and that still
> uses the trusty Permanent AX license.

You can still have SLR
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/smart-licensing/qsg/b_Smart_Licensing_QuickStart/b_Smart_Licensing_QuickStart_chapter_01000.html
and get persistent smart license you install on your device and it'll
never phone home.

You might want to argue an air gapped router to get itt, or if you
have commercial leverage apply that liberally.

For HW routers the process is like this
a) give your implied HW license to license server
b) allocate that from license server back, as SLR file
c) install SLR file, never worry about it again


--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On 23/Jul/20 08:31, Saku Ytti wrote:

> You can still have SLR
> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/smart-licensing/qsg/b_Smart_Licensing_QuickStart/b_Smart_Licensing_QuickStart_chapter_01000.html
> and get persistent smart license you install on your device and it'll
> never phone home.
>
> You might want to argue an air gapped router to get itt, or if you
> have commercial leverage apply that liberally.

Good tip, especially useful since our RR's have no BGP FIB, and as such,
have no way to "call home".

The other option we'd looked at was the SSM (Smart Software Manager)
on-prem, as I'm not keen on having routers make arbitrary calls to some
cloud over at Cisco.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

> On 23 Jul 2020, at 18:10, Mark Tinka <mark.tinka@seacom.com> wrote:
>
> ?
>
>> On 23/Jul/20 08:31, Saku Ytti wrote:
>>
>> You can still have SLR
>> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/smart-licensing/qsg/b_Smart_Licensing_QuickStart/b_Smart_Licensing_QuickStart_chapter_01000.html
>> and get persistent smart license you install on your device and it'll
>> never phone home.
>>
>> You might want to argue an air gapped router to get itt, or if you
>> have commercial leverage apply that liberally.
>
> Good tip, especially useful since our RR's have no BGP FIB, and as such,
> have no way to "call home".
>
> The other option we'd looked at was the SSM (Smart Software Manager)
> on-prem, as I'm not keen on having routers make arbitrary calls to some
> cloud over at Cisco.

That’s the approach we took, with the SSM box part of the IGP so it’s reachable.

Mixture of XE and XR boxes talking to it without issue.

It’s worked well so far for us, barring some weirdness with the SSM itself deciding not to sync with Cisco sometimes.

Chris

>
> Mark.
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On 23/Jul/20 10:28, Chris Jones wrote:
> That’s the approach we took, with the SSM box part of the IGP so it’s reachable.

Yep, exactly. Same view.

We are getting rid of a lot of Cisco gear, but for our CSR1000v RR's,
I'll incur the hassle, as I'm happy with those.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On 23/Jul/20 10:43, Lukas Tribus wrote:

> You just need a route to a HTTP proxy (like tinyproxy) in your FIB,
> just like you already need reachability for monitoring systems, NMS,
> radius servers etc.

All those monitoring systems live in the IGP, which is in FIB.


>
> No default route or full table necessary on any boxes, just IP
> reachability of a single, very simple forwarding proxy.

Things that call home into the cloud tend to be a bit flaky. Adding a
proxy to that can mix things up quite nicely, and I'd prefer to avoid
that altogether.



> - if the Cisco Licensing Cloud suddenly denies valid licenses due to
> temporary technical problems

I would expect that the SSM server has some grace period during which it
can lose communication with the mothership before starting to become a
threat to local operations. Not having that would be bad design, as the
Internet is well, not infallible. Those with SSM can enlighten us.


>
> - if the US gov suddenly imposes sanctions against your country (and
> in the simpliest scenario - you are unable to pay for subscriptions
> because international payments are blocked - this is happening right
> now between RIPE and iranian LIRs)

Well, this affects you even when you don't have an on-prem SSM server, then.

In our case, it helps to have backbone in other continents...

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Thu, 23 Jul 2020 at 11:02, Mark Tinka <mark.tinka@seacom.com> wrote:

> The other option we'd looked at was the SSM (Smart Software Manager)
> on-prem, as I'm not keen on having routers make arbitrary calls to some
> cloud over at Cisco.

You could also use local HTTP proxy, which may be less OPEX to
maintain or may already exist.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Hello,



On Thursday, 23 July 2020, Mark Tinka <mark.tinka@seacom.com> wrote:

>
>
> On 23/Jul/20 10:43, Lukas Tribus wrote:
>
> > You just need a route to a HTTP proxy (like tinyproxy) in your FIB,
> > just like you already need reachability for monitoring systems, NMS,
> > radius servers etc.
>
> All those monitoring systems live in the IGP, which is in FIB.


Same for an on-prem SSM as well as a proxy.



>
> >
> > No default route or full table necessary on any boxes, just IP
> > reachability of a single, very simple forwarding proxy.
>
> Things that call home into the cloud tend to be a bit flaky. Adding a
> proxy to that can mix things up quite nicely, and I'd prefer to avoid
> that altogether.


Yes, as you add variables you add complexity.

It seems to me though that a forward proxy that connects two TCP sockets is
less complex by an order of magnitude than running a full blown licensing
server which probably needs periodic software updates itself just to
continue to be able to talk to the mothership ...




>
>
> > - if the Cisco Licensing Cloud suddenly denies valid licenses due to
> > temporary technical problems
>
> I would expect that the SSM server has some grace period during which it
> can lose communication with the mothership before starting to become a
> threat to local operations. Not having that would be bad design, as the
> Internet is well, not infallible. Those with SSM can enlighten us.


I'm unsure the SSM has grace periods. The end devices are supposed to have
it though, IIRC.




>
> >
> > - if the US gov suddenly imposes sanctions against your country (and
> > in the simpliest scenario - you are unable to pay for subscriptions
> > because international payments are blocked - this is happening right
> > now between RIPE and iranian LIRs)
>
> Well, this affects you even when you don't have an on-prem SSM server,
> then.


Yes, like I said, this is common to *all* subscriptions based services.


Lukas
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On 23/Jul/20 11:08, Lukas Tribus wrote:

> Same for an on-prem SSM as well as a proxy.

Yes.


> Yes, as you add variables you add complexity.
>
> It seems to me though that a forward proxy that connects two TCP
> sockets is less complex by an order of magnitude than running a full
> blown licensing server which probably needs periodic software updates
> itself just to continue to be able to talk to the mothership ...

I'm not immediately sure if that is necessarily complex, given it is
built for purpose and is going what is meant to do.

I'd feel more comfortable visualizing the inner-workings locally. Kind
of like hosting a local RPKI validator, as opposed to using one millions
of miles away :-).


> I'm unsure the SSM has grace periods. The end devices are supposed to
> have it though, IIRC.

Not sure either. Perhaps Chris can tell us, since he has one deployed.


> Yes, like I said, this is common to *all* subscriptions based services.

Which goes back to what Gert was saying. The direction this is taking is
not in-keeping with simplifying lives.

Mark.

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

> On 23 Jul 2020, at 18:59, Mark Tinka <mark.tinka@seacom.com> wrote:
>
> ?
>
>> On 23/Jul/20 10:43, Lukas Tribus wrote:
>>
>> You just need a route to a HTTP proxy (like tinyproxy) in your FIB,
>> just like you already need reachability for monitoring systems, NMS,
>> radius servers etc.
>
> All those monitoring systems live in the IGP, which is in FIB.
>
>
>>
>> No default route or full table necessary on any boxes, just IP
>> reachability of a single, very simple forwarding proxy.
>
> Things that call home into the cloud tend to be a bit flaky. Adding a
> proxy to that can mix things up quite nicely, and I'd prefer to avoid
> that altogether.
>

+1 on that - this is precisely why we went down the SSM route and not “proxy direct to cloud”

>
>> - if the Cisco Licensing Cloud suddenly denies valid licenses due to
>> temporary technical problems
>
> I would expect that the SSM server has some grace period during which it
> can lose communication with the mothership before starting to become a
> threat to local operations. Not having that would be bad design, as the
> Internet is well, not infallible. Those with SSM can enlighten us.

SSM only needs to check in once a year (if I remember correctly) before things REALLY break, and generally once a month if you don’t want it to alarm. So loss of comms doesn’t phase it too much

It’s got an airgapped mode where it can be synced via a “sneaker net” file rather than direct https comms to Cisco, too. Not so much an issue for most SP networks I’d suggest, but I imagine it comes in useful in some circumstances where you’re dealing with a network with no internet access at all.

As a final point the routers also have a grace period (measured in days, but I forget how long - our SSM box stays up without too many issues other than patching) - so losing SSM for a short period of time isn’t going to cause a problem.

>
>
>>
>> - if the US gov suddenly imposes sanctions against your country (and
>> in the simpliest scenario - you are unable to pay for subscriptions
>> because international payments are blocked - this is happening right
>> now between RIPE and iranian LIRs)
>
> Well, this affects you even when you don't have an on-prem SSM server, then.
>
> In our case, it helps to have backbone in other continents...
>
> Mark.
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On 23/Jul/20 11:57, Chris Jones wrote:

> SSM only needs to check in once a year (if I remember correctly) before things REALLY break, and generally once a month if you don’t want it to alarm. So loss of comms doesn’t phase it too much
>
> It’s got an airgapped mode where it can be synced via a “sneaker net” file rather than direct https comms to Cisco, too. Not so much an issue for most SP networks I’d suggest, but I imagine it comes in useful in some circumstances where you’re dealing with a network with no internet access at all.
>
> As a final point the routers also have a grace period (measured in days, but I forget how long - our SSM box stays up without too many issues other than patching) - so losing SSM for a short period of time isn’t going to cause a problem.

Thanks, Chris.

This was my assumption as well.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Saku Ytti wrote on 23/07/2020 10:06:
> On Thu, 23 Jul 2020 at 11:02, Mark Tinka <mark.tinka@seacom.com> wrote:
>
>> The other option we'd looked at was the SSM (Smart Software Manager)
>> on-prem, as I'm not keen on having routers make arbitrary calls to some
>> cloud over at Cisco.
>
> You could also use local HTTP proxy, which may be less OPEX to
> maintain or may already exist.

The whole idea of having your routing stack poll a remote server with a
query which essentially asks "should I continue to operate?" with a
default answer of "No" seems like a unusually stupid way to provision a
network. Regardless of the timeout parameters.

Nick

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Thu, 23 Jul 2020 at 21:08, Nick Hilliard <nick@foobar.org> wrote:

> The whole idea of having your routing stack poll a remote server with a
> query which essentially asks "should I continue to operate?" with a
> default answer of "No" seems like a unusually stupid way to provision a
> network. Regardless of the timeout parameters.

I think it's well done and I can see applications where it adds real
value to customers. For us the OPEX of dealing with licenses is too
much, we want a one-time fire and forget solution, which they offer.
But if I'd install and decom hundreds of CPEs yearly, with varying
level of features and I'd immediately transfer feature costs to
customers, this is really attractive. You buy the boxes without
licenses and you buy licenses separately, and you ship just-in-time
the license you actually need, and you return it to your pool once
you're done. If pools run dry, you get alerts and you procure more.

I also think licenses are a good idea, but often horrible execution.
Not having licenses means you're subsiding people who use features
heavily. Not having licenses also means the vendor doesn't know where
money is pouring in, should they invest in multicast, 6VPE, LISP NRE
or something else? Licenses mean you don't subsidize other players,
you pay for features you use, vendor will understand where to invest
NRE for better return.
Similarly as a metered Internet is a great idea, with almost
universally horrible executions. I am a heavy user, who is being
subsidized by low income moms and pops, doesn't feel fair. For my
electricity I pay separately for transmission and consumption, which
is a great and fair model. Transmission is fixed cost, use or not,
consumption is not. Uncongested Internet would be market driven fact
for metered, because in flat rate Internet dropping packets increases
margins, in metered Internet it reduces.


--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/