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

417
Views
0
Helpful
3
Replies
khgrant
Cisco Employee

Service redeploy

Hi team,

 

During customer demo rehearsal I ran into a problem with service redeploy.

 

NSO version 4.1, mpls-vpn demo from installation file.

 

 

I’d deployed a l3vpn service and then changed device configuration through CLI. I wanted to simulate situation when someone altered device configuration out-of-band and accidentally broke service.

 

Obviously NSO CDB and device config were out-of-sync. I synchronised CDB with device to retain new configuration (sync-from). Next I check discrepancies:

 

 

admin@ncs(config)# vpn l3vpn volvo deep-check-sync outformat cli cli {
device {
name ce4
data  devices {
device ce4 {
  config {
  ios:router {
+ bgp 65103 {
+ neighbor 192.168.1.18 {
+ remote-as 100;
+ activate;
+ }
+ address-family {
+ ipv4 unicast {
+ neighbor 192.168.1.18 {
+ activate;
+ }
+ network 10.8.8.0 {
+ mask 255.255.255.0;
+ }
+ }
+ }
+ }
  }
  }
}
}
}
}

Then I gave a try to redeploy the service:

1 ACCEPTED SOLUTION

Accepted Solutions
khgrant
Cisco Employee

Hello,

 

Currently check-sync and re-deploy dry-run share the same behaviour answering the question "what would happen if we were to re-deploy the service".

 

Redeploying the service creates a new transaction, deletes everything the service did and runs the service again. The net effect of this is shown in "dry-run"

 

 

In the same time deep-check-sync only applies a forward diff, to the configuration answering the question "were there any changes down on the device to what we applied previously?".

 

The deep-check-sync reads the device data into a transaction and applies the forward diff to it. The net effect of this is shown.

 

 

So having performed 'sync-from'

 

 

Doing:

 

devices device * compare-config

 

 

should show nothing.

 

 

"deep-check-sync" should show the out of band changes as should "re-deploy dry-run"

 

Try the outformat xml as well to see if there are any differences.

 

 

If the above is not true it sound like a bug

View solution in original post

3 REPLIES 3
khgrant
Cisco Employee

Hello,

 

Currently check-sync and re-deploy dry-run share the same behaviour answering the question "what would happen if we were to re-deploy the service".

 

Redeploying the service creates a new transaction, deletes everything the service did and runs the service again. The net effect of this is shown in "dry-run"

 

 

In the same time deep-check-sync only applies a forward diff, to the configuration answering the question "were there any changes down on the device to what we applied previously?".

 

The deep-check-sync reads the device data into a transaction and applies the forward diff to it. The net effect of this is shown.

 

 

So having performed 'sync-from'

 

 

Doing:

 

devices device * compare-config

 

 

should show nothing.

 

 

"deep-check-sync" should show the out of band changes as should "re-deploy dry-run"

 

Try the outformat xml as well to see if there are any differences.

 

 

If the above is not true it sound like a bug

khgrant
Cisco Employee

thanks for pointer. It helped.

khgrant
Cisco Employee

when in doubt go to the YANG

 

 

from tailf-ncs-service.yang:

 

 

     tailf:action deep-check-sync {

 

       tailf:info "Check if device config is according to the service";

 

       description

 

"Check if this service has been undermined on the device itself.

 

          The action 'check-sync' compares the output of the service

 

          code to what is stored in CDB locally. This action retrieves the

 

configuration from the devices touched by the service and compares

 

          the forward diff set of the service to the retrieved data. This

 

          is thus a fairly heavy weight operation. As opposed to the check-sync

 

          action that invokes the FastMap code, this action re-applies the

 

          forward diff-set. This is the same output you see when inspecting

 

          the 'get-modifications' operational field in the service instance.

 

 

          If the device is in sync with CDB, the output of this action

 

          is identical to the output of the cheaper check-sync action";

 

 

compared to:

 

 

     tailf:action check-sync {

 

       tailf:info "Check if device config is according to the service";

 

       description

 

"Check if this service has been undermined, i.e., if this service

 

          was to be re-deployed, would it do anything. This action will

 

          invoke the FastMap code to create the change set that is compared

 

          to the existing data in CDB locally.

 

 

          If outformat is boolean, 'true' is returned if the service is

 

          in sync, i.e., a re-deploy would do nothing. If outformat is

 

          cli or xml, the changes that the service would do to the

 

          network if re-deployed are returned.";

Create
Recognize Your Peers
Content for Community-Ad