cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Community Helping Community

88
Views
2
Helpful
10
Replies
Cisco Employee

NSO outperform native

Which options do we have with NCS to generate the native device config, e.g. CLI “commit dry-run outperform native” ?

In a CPE deployment use case without PNP alá CloudVPN a field technician may still be required to at least configure the very basic stuff like interface IP and ssh for NCS to log into the CPE.

For this we would need the ability to generate the native config from the service model (e.g. assuming the service is sitting in NCS with CPE in “southbound-locked” state).

Everyone's tags (4)
1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Re: NCS outperform native

> Hello,

> which options do we have with NCS to generate the native device

> config, e.g. CLI “commit dry-run outperform native” ?

Together with reactive Fastmap and e.g PnP and allocations and NFvs, not much  - today

>

> In a CPE deployment use case without PNP alá CloudVPN a field

> technician may still be required to at least configure the very basic

> stuff like interface IP and ssh for NCS to log into the CPE.

> For this we would need the ability to generate the native config from

> the service model (e.g. assuming the service is sitting in NCS with

> CPE in “southbound-locked” state).

I'd say that in the case with a pre-configured CPE, i.e configured manually - on site - and no call home proto in place at all, we'd do is this:

case 1.

Service is configured without cpe in place, but CPE is there, in CDB, maybe without IP, but in soubound locaked mode

Once CPE is there, enter IP, and do sync-from, and then redeploy on the service, this will push service cfg to CPE

case 2

CPE is already there when service is instantiated, just go ahead and provision. IP entered manually (or from portal, or whatever)

Now, the question -

Generating the service config on the CPE MUST be done from NSO, from the service. Not dryrun and then manually entered, redeploy is the tool here.

Background:

A service redeploy will run the service provisioning code again.

Normally this is idempotent, to it twice and nothing happens on the second run. The redeploy runs Fastmap, by

1. undoing all the service ever did.

2. Calls the service code again

3. commits

If there were actual changes on the device since last time we ran, these changes will be overwritten by redeploy. Thus redeploy is like "mending"

the service after a sync-from when somebody logged in to CLI on device and destroyed the service.

More info in NSO Userguide.

View solution in original post

10 REPLIES 10
Cisco Employee

Re: NCS outperform native

> Hello,

> which options do we have with NCS to generate the native device

> config, e.g. CLI “commit dry-run outperform native” ?

Together with reactive Fastmap and e.g PnP and allocations and NFvs, not much  - today

>

> In a CPE deployment use case without PNP alá CloudVPN a field

> technician may still be required to at least configure the very basic

> stuff like interface IP and ssh for NCS to log into the CPE.

> For this we would need the ability to generate the native config from

> the service model (e.g. assuming the service is sitting in NCS with

> CPE in “southbound-locked” state).

I'd say that in the case with a pre-configured CPE, i.e configured manually - on site - and no call home proto in place at all, we'd do is this:

case 1.

Service is configured without cpe in place, but CPE is there, in CDB, maybe without IP, but in soubound locaked mode

Once CPE is there, enter IP, and do sync-from, and then redeploy on the service, this will push service cfg to CPE

case 2

CPE is already there when service is instantiated, just go ahead and provision. IP entered manually (or from portal, or whatever)

Now, the question -

Generating the service config on the CPE MUST be done from NSO, from the service. Not dryrun and then manually entered, redeploy is the tool here.

Background:

A service redeploy will run the service provisioning code again.

Normally this is idempotent, to it twice and nothing happens on the second run. The redeploy runs Fastmap, by

1. undoing all the service ever did.

2. Calls the service code again

3. commits

If there were actual changes on the device since last time we ran, these changes will be overwritten by redeploy. Thus redeploy is like "mending"

the service after a sync-from when somebody logged in to CLI on device and destroyed the service.

More info in NSO Userguide.

View solution in original post

Cisco Employee

Re: NCS outperform native

thanks for the feedback.

We¹re indeed discussing case 1 here with CPE in CBD + SB locked and service sent to NSO.

The re-deploy function is known, but the manual preparation for it to work will be huge.

For NSO to finally be able to log into the CPE, the field technician needs

to:

- configure WAN interface

- configure static route towards PE

- configure AAA / Tacacs

- configure line settings, e.g. telnet or ssh

Is there a technical reason when re-deploy MUST/SHOULD be used for CPE config?

IMHO even with manual CPE provisioning sync-from + re-deploy would result in a consistent state for network and NSO.

Of course this largely limits NSO¹s highlights to service modification and removal, but we should also avoid burdening the technicians with more manual work then they currently have (their current tool produces a copy&paste config for both PE and CPE).

Cisco Employee

Re: NCS outperform native

GREAT, many thanks!

Step 4 is exactly what I needed. I wasn’t aware that I can access the target config for a SB locked device this way.

Of course the NED prefix is a bit annoying (need to work with XR, IOS, Junos and OneAccess), but maybe a post-commit or command script can help the write the config without prefix info to the disk.

We are in sync regarding 6 and 7:

We should let NSO handle both base and service relevant config. I just needed to extract the base stuff to enable the field technician in first place.

Cisco Employee

Re: NCS outperform native

I could be wrong, but I would be surprised if customers would allow field-techs who deploy CPE to have access to NCS command line. This is a good start, but probably need a web interface with REST/NETCONF to handle authentication and formatting of the config files ?

Cisco Employee

Re: NCS outperform native

Hi Chris,

interesting point of view, but I was rather thinking about dumping the CLI cfg to .txt when the service data hits NCS.

The field-tech should put that file on hit notebook before driving to the customer; or staging the router before driving out.

This seems to come closest to the approach DT is using for their legacy IP backbone.

Highlighted

Re: NCS outperform native

You may use device template configuration, and not service models, to generate day-0 configurations for a device.

Either using device templates or service models, you can preview the configuration in native format using the ncs_cli command:

commit dry-run outformat native

Best regards, Gustavo

Cisco Employee

Re: NCS outperform native

Hello team,

as Klacke seems to either be on PTO or overloaded I’m wondering whether the remaining part of the community already dealt with a similar task:

I’m using a command script to dump the device config, but the “sed” part of the command is ignored.

I appreciate any pointer.

Regards

Mike

Cisco Employee

Re: NCS outperform native

Hi Mike,

Can you try adding the ―get-io option to the ncs-maapi command?

-Dan

Cisco Employee

Re: NCS outperform native

Thanks Dan!

This solved it:

    ncs-maapi --clicmd "show running-config devices device $string config"

--get-io | sed 's/ios://g'

Regards

Mike

Cisco Employee

Re: NCS outperform native

Great!

Content for Community-Ad
FusionCharts will render here
This widget could not be displayed.