cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
88
Views
0
Helpful
11
Replies
Highlighted
Cisco Employee

NSO system-installation behaviour

 

Hi everyone,

 

I have an urgent question!

 

See the output below from system-installed NSO 4.1 (the output is from my lab setup for testing, already deployed packages in live customer network give the exactly same output):

 

admin@ncs# show services l2vpn CE0 GigabitEthernet 0/0/4 2000 device-modifications
% No entries found.

admin@ncs# show services l2vpn CE0 device-modifications
                                           INTERFACE  VLAN  DEVICE
DEVICE  INTERFACE TYPE   INDEX      ID    MODIFICATIONS

---------------------------------------------------------

CE0     Port-channel     41         2003  -

CE0     GigabitEthernet  0/0/4      2000  -

CE0     GigabitEthernet  0/0/4      3200  -

CE0     GigabitEthernet  0/1/1      2001  -

 

This works in local install NSO 4.1 with same packages and neds, giving all the output of the actual configuration changes.

 

device-modifications  devices {

                          device ASR903 {

                              config {

                                  ios:bridge-domain {

                    +                bridge-domain-list 2000 {

                     +                    member {

                     +                        interface-list GigabitEthernet0/0/4 {

                     +                            service-instance 3;

                     +                        }

                     +                    }

                     +                }

……

 

Why doesn’t the output work in a system-install NSO 4.1?

 

 

Kind Regards,

 

Mikael Tidemar

 

 

 

11 REPLIES 11
Cisco Employee

Re: NSO system-installation behaviour

 

Hi Daniel,

 

I was worried about the permissions, are there any specific parts of ncs.conf I should set up differently to make this work?

 

I have added users admin and root as group members in the group ncsadmin, setup nacm accordingly.

 

Kind Regards,

Mikael

 

Cisco Employee

Re: NSO system-installation behaviour

 

On RHEL look for these and change as appropriate in ncs.conf

 

    <pam>

      <enabled>true</enabled>

      <service>system-auth</service>

    </pam>

    <external-authentication>

      <enabled>false</enabled>

      <executable>my-test-auth.sh</executable>

    </external-authentication>

<local-authentication>

      <enabled>true</enabled>

    </local-authentication>

For the first one in RED you might need check that module exists in the pam.d directory as below in red. I have a feeling it might differ on non-Redhat systems.  I recall “common-auth” being on some.

[root@localhost ~]# cd /etc/pam.d/

[root@localhost pam.d]# ls

chfn                 other             ppp                smtp                  su-l

chsh                 passwd            remote             smtp.postfix          system-auth

config-util          password-auth     rhn_register       sshd                  system-auth-ac

crond                password-auth-ac  runuser            su                    systemd-user

fingerprint-auth     polkit-1          runuser-l          subscription-manager  vlock

fingerprint-auth-ac  postlogin         smartcard-auth     sudo

login                postlogin-ac      smartcard-auth-ac  sudo-I

 

Could be something else of course

 

 

Cisco Employee

Re: NSO system-installation behaviour

 

Hi Daniel,

PAM and external authentication are disabled in our ncs.conf. We only use local authentication.

One thing though, what is the relationship with seeing "no etries found" and authentication ?

 

Regards,

-Fatih

 

Cisco Employee

Re: NSO system-installation behaviour

 

Hi Fatih – just a hunch based on my own system install and what I could see prior to correcting the config and having no other info.  I don’t have another answer given you turned local-auth on already – and hence why I left my original response off-list hoping you’d get a better answer.

 

Cisco Employee

Re: NSO system-installation behaviour

 

Hi Daniel,

I understand and appreciate the comment. A further input from our deploymeny is that our system-install was done with "--run-as-user admin", which might be another consideration which has already caused on us some care on ncs-backup and logrotate and more care on file ownership.

However, the issue that Mikael posted appears to me not really relevant to this.

 

Regards,

-Fatih

 

Cisco Employee

Re: NSO system-installation behaviour

 

Hi Team,

 

 

In system-install, when I set /services/global-settings/collect-forward-diff true and after re-creating services, then I could display device-modifications.

 

In local-install, that is already enabled:

 

admin@ncs> show configuration services global-settings collect-forward-diff

 

collect-forward-diff true;

 

[ok][2016-03-06 16:16:37]

 

admin@ncs>

 

 

Regards,

 

-Fatih

 

Cisco Employee

Re: NSO system-installation behaviour

 

Hi team,

 

Great catch Fatih, another very important feature setting to use for current and future deployments.

 

 

Kind Regards,

 

Mikael

 

Cisco Employee

Re: NSO system-installation behaviour

 

On 2016-03-06 13:18, Fatih Ayvaz (faayvaz) wrote:

 

> Hi Team,

 

>

 

> In system-install, when I set /services/global-settings/collect-forward-diff true and after re-creating services, then I could display device-modifications.

 

> In local-install, that is already enabled:

 

> admin@ncs> show configuration services global-settings

 

> collect-forward-diff collect-forward-diff true;

 

> [ok][2016-03-06 16:16:37]

 

> admin@ncs>

 

 

There is no difference between local-install and system-install in this respect, the default is 'false' - as per the YANG model

 

(tailf-ncs-services.yang) - in both for current versions. However the default used to be 'true', and was apparently changed to 'false' as of the NSO-4.0.1 and NSO-4.1 releases. Unfortunately it seems this was neither reflected in the CHANGES file nor in the YANG revision history.

 

 

--Per

 

Cisco Employee

Re: NSO system-installation behaviour

 

Thanks Per,

 

Customer is asking the impact of setting this true.

 

Is there any performance related concern or any best practice for why to set this true or leave it as false?

 

 

Please note, we will need to re-create existing services (some hundreds) to have this in effect. So, please kindly share any information or pointers if there will be any impact if we set this true.

 

 

Regards,

-Fatih

 

Cisco Employee

Re: NSO system-installation behaviour

 

From the YANG file tailf-ncs-services.yang:

 

 

      leaf collect-forward-diff {

 

         tailf:info "Toggle the collection of service data";

 

description

 

"When creating a service instance we can choose to also

 

            collect the forward diff.  I.e., remember what the service

 

did.  This drives the formatting of the runtime statistics

 

'get-modifications' for a service. We always collect the

 

            reverse for a service instance, that is the basis for the

 

            FastMap algoritm.  This consumes quite a bit of extra

 

            memory per service instance, so if we have huge amounts of

 

services it may be worthwhile to turn this off.";

 

         type boolean;

 

         default false;

 

       }

 

 

Think of it this way, if a service creates a tree with 6000 items the forward diff needs to collect these 6000 items. The reverse diff only needs to keep one delete.

 

 

Normally the forward diff takes time to collect and consumes space. It is only used in the actions 'get-modifications' and 'check-sync'.

 

 

Why is it important for the customer to have the forward diff?

 

 

/Dag

 

Cisco Employee

Re: NSO system-installation behaviour

 

Hi Dag,

 

 

Customer's initial concern was seeing this diff set in lab but not in production, and hence something might have been wrong with in creating services. Well, not directly related to this thread, but we have an open RT ticket (22067), where we observed that service creation went well but the id-allocator does not show the allocation.

 

We could use this fwd diff to double check the id-pool allocation whether is part of the service. In our case in particular, "show resource-pools id-pool" is showing an allocation but the "show id-allocator pool" does not. I wonder what get-modifications action would display, and I will test this soon.

 

 

Regards,

 

-Fatih

 

Content for Community-Ad
August's Community Spotlight Awards
This widget could not be displayed.