cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1603
Views
0
Helpful
3
Replies

re-deploy from upper layer doesn't re-store the service in rfs-node

erdemk
Level 1
Level 1
Dear community members,



May someone help me on the following : 



I was making some tests in order to understand the behavior of lsa architecture. 
I am using 22-layered-service-architecture in examples folder.

Let me first ask my question : when i modify rfs-service , is it not possible to re-store the service in rfs-node by help of re-deploying service in cfs-node ? 
note : When i modify rfs-service by help of device-manager in rfs-node, re-deploy from cfs-node re-stores the servcie in rfs-node.


Here is the procedure i followed : 

I have committed cfs-vlan service from upper-nso. i am not putting here commit-dry-run as this is from examples :

set cfs-vlan v1 a-router ex0 z-router ex5 \
> iface eth3 unit 3 vid 77

Then, i modify service from rfs-node:
admin@lower-nso-1(config)# vlan v1       
admin@lower-nso-1(config-vlan-v1)# unit 4
admin@lower-nso-1(config-vlan-v1)# commit

Now, when i request deep-check-sync in cfs-node for this service, i see the diff for the change i made :
admin@upper-nso% request cfs-vlan v1 deep-check-sync outformat cli                 
cli {
    local-node {
        data  devices {
                   device lower-nso-1 {
                       config {
                           vlan v1 {
              -                unit 4;
              +                unit 3;
                           }
                       }
                   }
               }
    }
}

Ok, now i want to re-deploy my service, but re-deploy doesn't restore the service :
admin@upper-nso% request cfs-vlan v1 re-deploy dry-run { outformat cli }
cli {
}
[ok][2021-05-10 18:50:54]



Thanks and regards.
1 Accepted Solution

Accepted Solutions

gmuloche
Cisco Employee
Cisco Employee

Hello, I see you never got an answer.

 

[I am using NSO 5.5 here but _should_ work the same for earlier versions]

 

Couple of points:

>> when i modify rfs-service , is it not possible to re-store the service in rfs-node by help of re-deploying service in cfs-node ? 

Yes it is possible

 

In your scenario above there is something quite not clear to me yet - once you have modified the service on the lower-node-1, your upper node should now see lower-node-1 as Out of sync like:

admin@upper-nso> request cfs-vlan v1 re-deploy dry-run { outformat cli }
Error: Network Element Driver: device lower-nso-1: out of sync
[error][2021-07-30 11:07:22]
admin@upper-nso> *** ALARM out-of-sync: Device lower-nso-1 is out of sync

Are you doing anything specific in the configuration (I followed the example setup in example 22 btw)

 

A solution to go around this is to sync-from lower-node-1 from the upper node and then when I run the re-deploy dry-run command:

 

admin@upper-nso> request cfs-vlan v1 re-deploy dry-run { outformat cli }
cli {
    local-node {
        data  ncs:devices {
                   device lower-nso-1 {
                       config {
                           services {
                               vlan v1 {
              -                    unit 4;
              +                    unit 3;
                               }
                           }
                       }
                   }
               }

    }
    lsa-node {
        name lower-nso-1
        data  devices {
                   device ex0 {
                       config {
                           sys {
                               interfaces {
                                   interface eth3 {
              +                        unit 3 {
              +                            enabled;
              +                            description "Interface owned by CFS: v1";
              +                            vlan-id 77;
              +                        }
              -                        unit 4 {
              -                            enabled;
              -                            description "Interface owned by CFS: v1";
              -                            vlan-id 77;
              -                        }
                                   }
                               }
                           }
                       }
                   }
               }
               rfs-vlan:services {
                   vlan v1 {
              -        unit 4;
              +        unit 3;
                   }
               }

    }
}
[ok][2021-07-30 11:08:26]

[NOTE: deep-check-sync ignore OOS here]

 

View solution in original post

3 Replies 3

gmuloche
Cisco Employee
Cisco Employee

Hello, I see you never got an answer.

 

[I am using NSO 5.5 here but _should_ work the same for earlier versions]

 

Couple of points:

>> when i modify rfs-service , is it not possible to re-store the service in rfs-node by help of re-deploying service in cfs-node ? 

Yes it is possible

 

In your scenario above there is something quite not clear to me yet - once you have modified the service on the lower-node-1, your upper node should now see lower-node-1 as Out of sync like:

admin@upper-nso> request cfs-vlan v1 re-deploy dry-run { outformat cli }
Error: Network Element Driver: device lower-nso-1: out of sync
[error][2021-07-30 11:07:22]
admin@upper-nso> *** ALARM out-of-sync: Device lower-nso-1 is out of sync

Are you doing anything specific in the configuration (I followed the example setup in example 22 btw)

 

A solution to go around this is to sync-from lower-node-1 from the upper node and then when I run the re-deploy dry-run command:

 

admin@upper-nso> request cfs-vlan v1 re-deploy dry-run { outformat cli }
cli {
    local-node {
        data  ncs:devices {
                   device lower-nso-1 {
                       config {
                           services {
                               vlan v1 {
              -                    unit 4;
              +                    unit 3;
                               }
                           }
                       }
                   }
               }

    }
    lsa-node {
        name lower-nso-1
        data  devices {
                   device ex0 {
                       config {
                           sys {
                               interfaces {
                                   interface eth3 {
              +                        unit 3 {
              +                            enabled;
              +                            description "Interface owned by CFS: v1";
              +                            vlan-id 77;
              +                        }
              -                        unit 4 {
              -                            enabled;
              -                            description "Interface owned by CFS: v1";
              -                            vlan-id 77;
              -                        }
                                   }
                               }
                           }
                       }
                   }
               }
               rfs-vlan:services {
                   vlan v1 {
              -        unit 4;
              +        unit 3;
                   }
               }

    }
}
[ok][2021-07-30 11:08:26]

[NOTE: deep-check-sync ignore OOS here]

 

Gmuloche hi,

Thank you very much for your reply.. this is something still remaining open for me..  i need to do some testing to reply, but currently i do have time for this, i will be able to reply mid to late next week.

kind regards

Gmuloche hello,



Sorry for being late to conclude this.. I did some more reading and testing.. 
I am using nso-5.3.3.. i agree, behaviour would be same with at least other nso-5.x versions.


a small clarification :
gmuloche: In your scenario above there is something quite not clear to me yet - once you have modified the service on the lower-node-1, your upper node should now see lower-node-1 as Out of sync like:
erdem: when "devices global-settings out-of-commit-behaviour" is set to accept, then NSO doesn't show OOS while re-deploy ing the service. Default value is reject, and in example 22 default value is used. So, service can be re-deployed from upper-nso to lower-nso. I used accept in my testing at that time.

Solution :
As you suggested sync-from lower-nso-1 from upper-nso solves the problem and re-deploying service from upper-nso to lower-nso is then possible. 



Actually, as far as i understand, before doing any re-deploy from upper-nso, sync-from lower-nso from upper-nso would be the way-forward . Below is a fun-fact related to this.

fun-fact :    ( set "out-of-commit-behaviour = accept" )  ( based on example-22 )

> When we change vlan-id(vid) from 77 to 78 by help of vlan-service on lower-nso-1"cfs-vlan v1 re-deploy dry-run" dosn't show any diff.
> but, when we change vlan-id(vid) from 77 to 78 by help of device-manager on lower-nso-1"cfs-vlan v1 re-deploy dry-run" shows the diff.
> note: after sync-from lower-nso-1 from upper-nso, the diff is shown in either cases.

reason for this is that ( as far as i interpret it), nso assumes sync conditions between upper-nso and lower-nso, and hence while doing "cfs-vlan v1 re-deploy dry-run" from upper-nso, upper-nso sends netconf edit-config message only with vlan=v1 (see below netconf message extract) and tries to see if there is a change in device-manager level in lower-nso by "by help of a dry-run transaction"... And s there is no difference between (vlan v1) service and device-manager, no diff is sent back.. On the other hand, when we change vid-78 from device-manager level,the diff is sent back.:

    (only relevant parts included for simplicity..)
    <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

    <start-transaction>

    <edit-config><config><vlan><name>v1</name></vlan></config></edit-config>
    <prepare-transaction><dry-run><outformat>cli</outformat>
    <rpc-reply><dry-run-result><cli></cli></dry-run-result></rpc-reply>                 <-- see, there is no diff

    <abort-transaction>
    <close-session/>

Also see, when there is change in lower-nso-1 by help of vlan service, and we sync-from lower-nso-1 from upper-nso, while doing "cfs-vlan v1 re-deploy dry-run", upper nso sends the modified parameter as part of edit-config message : 

    <edit-config><config>
    <vlan><name>v1</name><vid>77</vid></vlan></config></edit-config>



screen outputs :

case-1 :  modifying vlan service on lower-nso-1 by help of vlan-service..
- change the service in lower-nso-1 with "vlan v1 vid 78"
- re-deploy dry-run from upper-nso
admin@upper-nso(config)# cfs-vlan v1 re-deploy dry-run 
cli {                                                                              <-- diff is not shown
}

- re-deploy dry-run from upper-nso, after sync-from lower-nso-1 from upper-nso
admin@upper-nso(config)# devices device lower-nso-1 sync-from
result true
admin@upper-nso(config)# cfs-vlan v1 re-deploy dry-run       
cli {
    local-node {
        data  devices {
                   device lower-nso-1 {
                       config {
                           vlan v1 {
              -                vid 78;
              +                vid 77;
                           }
                       }
                   }
               }
    }
    lsa-node {
        name lower-nso-1
        data  devices {
                   device ex0 {
                       config {
                           sys {
                               interfaces {
                                   interface eth3 {
                                       unit 3 {
              -                            vlan-id 78;
              +                            vlan-id 77;
                                       }
                                   }
                               }
                           }
                       }
                   }
               }
               vlan v1 {
              -    vid 78;
              +    vid 77;
               }
    }
}

case-2 :  modifying vlan service on lower-nso-1 by help of device-manager..
- change the service on lower-nso-1 by help of "devices device ex0 config sys interfaces interface eth3 unit 3 vlan-id 78"
- re-deploy dry-run from upper-nso
admin@upper-nso(config)# cfs-vlan v1 re-deploy dry-run 
cli {
    lsa-node {
        name lower-nso-1
        data  devices {
                   device ex0 {
                       config {
                           sys {
                               interfaces {
                                   interface eth3 {
                                       unit 3 {
              -                            vlan-id 78;
              +                            vlan-id 77;
                                       }
                                   }
                               }
                           }
                       }
                   }
               }  
    }
}

- re-deploy dry-run from upper-nso after  sync-from lower-nso-1 from upper-nso
admin@upper-nso(config)# cfs-vlan v1 re-deploy dry-run
cli {
    lsa-node {
        name lower-nso-1
        data  devices {
                   device ex0 {
                       config {
                           sys {
                               interfaces {
                                   interface eth3 {
                                       unit 3 {
              -                            vlan-id 78;
              +                            vlan-id 77;
                                       }
                                   }
                               }
                           }
                       }
                   }
               }              
    }
}


Thanks and regards gmuloche.
Polls
AI-powered tools for network troubleshooting are likely to be part of everyone’s workflow sooner or later. What is the single biggest challenge or concern you see with adopting these tools in your organization?