Learn NSO: The Easy Way by Padtec

Este material é uma adaptação do original publicado pela Cisco em https://developer.cisco.com/learning/lab/learn-nso-the-easy-way/step/1.

O curso original é composto por 10 capítulos.

Este curso adapata as etapas 1, 2, 3, 6, 9 e 10 para um cenário de dispositivo ConfD Padtec.

Os textos originais foram traduzidos de EN-US para PT-BR via https://translate.google.com com pouca ou nenhuma revisão manual.

Recursos utilizados:

Servidor NSO: instalação local em 172.31.0.212.
Dispositivo Netconf/ConfD: SPVL rodando a aplicação superviser em 172.30.0.175.

Resumo do conteúdo:

Etapa 1 apresenta o NSO resumidamente.
Etapa 2 demontra como realizar uma instalação local e prepara o NSO para controlar um dispositivo. O NSO já está instalado no server 172.31.0.212, portanto, não é necessário executar os comandos relacionados à instalação.
Etapa 3 consiste em instanciar o dispositivo e carregar sua configuração para a instância NSO.
Etapa 6 demonstra o uso de templates.
Etapa 9 trata da criação de serviços, utilizando como exemplo a configuração do loopback-mode.
Etapa 10 explora a reimplantação do serviço numa situação out-of-sync.

Durante a execução do tutorial, você poderá querer acompanhar as modificações via web-ui: http://172.31.0.212:8080

Visualizadores online de arquivos .md:
https://dillinger.io
https://pandao.github.io/editor.md/en.html

Visite:
https://www.cisco.com/c/en/us/products/cloud-systems-management/network-services-orchestrator/index.html
https://developer.cisco.com/site/nso/

Etapa 1: Introdução

O NSO coleta, analisa e armazena o estado de configuração dos dispositivos de rede que gerencia em um banco de dados de configuração (CDB). Os usuários e outros aplicativos podem pedir ao NSO para criar, ler, atualizar ou excluir a configuração de forma programática, seja ad hoc ou por meio de serviços de rede personalizáveis.

A NSO usa pacotes de software chamados Network Element Drivers (NEDs) para facilitar as interações de telnet, SSH ou API com os dispositivos que gerencia. O NED fornece uma camada de abstração que lê a configuração de execução do dispositivo e a analisa em um instantâneo validado por modelo de dados no CDB.

Os NEDs também permitem o inverso, criando configuração de rede a partir de entradas de dados CDB e, em seguida, enviando as configurações aos dispositivos de rede. Existem centenas de NEDs cobrindo todas as plataformas Cisco (incluindo IOS-XE, IOS-XR, NX-OS e ASA) e também todas as principais plataformas não Cisco.

Objetivos

Ao concluir este laboratório, você será capaz de:

Configurar uma instância NSO a partir de uma instalação local.
Conectar-se a dispositivos de rede com NSO, configurando-os e enviando comandos show.
Usar o NSO com alguns casos de uso básicos

Pré-requisitos

Tenha uma instalação NSO local ou use a sandbox Cisco NSO reservável.

Etapa 2: Configurando o NSO

A System Install é usada ao instalar o NSO para uma finalidade de nível de produção centralizada e "sempre ativa". Ele é configurado como um daemon do sistema que iniciaria e terminaria com o sistema operacional subjacente. As credenciais padrão e os locais de instalação do aplicativo se alinham com uma função típica de aplicativo Linux.

A Local Install é usada para fins de desenvolvimento, laboratório e avaliação. Ele descompacta todos os componentes do aplicativo, incluindo documentação e exemplos, e permite ao usuário instanciar e iniciar instâncias do NSO sob demanda. Uma instalação local em uma única estação de trabalho pode ser usada por um engenheiro para executar várias instâncias não relacionadas de NSO para diferentes laboratórios e demonstrações. Esta instalação inclui credenciais padrão para facilidade de uso e normalmente é instalada em uma pasta facilmente acessível.

Este laboratório se concentrará na instalação local do NSO, pois é mais fácil para os novos usuários navegar e executar localmente em seus laptops.

Instalação

Tools

sudo apt update -y
sudo apt install curl
sudo apt-get install -y xsltproc
sudo apt install default-jre --fix-missing
sudo apt-get install ant

Python 2 e 3

https://linuxconfig.org/install-python-2-on-ubuntu-20-04-focal-fossa-linux
https://linuxize.com/post/how-to-install-pip-on-ubuntu-20.04/
https://stackoverflow.com/questions/4340873/how-do-you-switch-between-python-2-and-3-and-vice-versa

sudo apt install python3-virtualenv

Preparação NSO

virtualenv -p /usr/bin/python2.7 Vpy27
source Vpy27/bin/activate
sh nso-5.3.linux.x86_64.signed.bin
mkdir ~/nso-5.3
sh nso-5.3.darwin.x86_64.installer.bin --local-install ~/nso-5.3
deactivate

Uma instalação local do NSO descompacta e prepara seu sistema para executar o NSO, mas na verdade não o inicializa. Uma instalação local permite que o engenheiro crie uma "instância" NSO vinculada a um projeto, o que ainda não foi feito.

Usando ncs-setup para criar uma instância NSO

Um dos scripts incluídos na instalação do NSO é o ncs-setup, que torna muito fácil criar instâncias do NSO a partir de uma instalação local. Você pode consultar o –help para obter todos os detalhes, mas as duas opções que precisamos saber são:

–dest define o diretório onde você deseja configurar o NSO (se o diretório não existir, ele será criado)

–package define os NEDs que você deseja que esta instância NSO tenha instalado. Você pode especificar essa opção várias vezes.

1. Vá em frente e execute este comando para configurar uma instância NSO no diretório atual com o NED padtec-spvlhb-nc.

Neste ponto, os requisitos são:

Ter acesso a um ambiente com instalação local do NSO

ssh spvlnet@172.31.0.212

Ter acesso aos modelos do device ConfD e disponibilizá-los no ambiente do NSO

Acessar o /home/${USER}

cd ~
spvlnet@nso-esi-212:~$

Baixar os modelos do repositório de artefatos http://172.16.1.150/artifactory/build/sandbox.erlang.superviser/<BUILD-ID>/models-<DATE>-<BUILD-ID>*.tar.gz

spvlnet@nso-esi-212:~$ wget --user spvlnet --password **PASSWORD** http://172.16.1.150/artifactory/build/sandbox.erlang.superviser/190/models-202009091259-190.tar.gz

Descompactar os modelos

  tar -xvzf models-202009091259-190.tar.gz
  # os arquivos estarão no diretório ~/yang

Ter um device ConfD ativo (exemplo SPVL 172.30.0.175)

Execute os seguintes passos para rodar manualmente a aplicação e o ConfD.

App: superviser-<DATE>-<BUILD-ID>*.tar.gz

  cd ~/superviser_dist
  wget --user spvlnet --password **PASSWORD** http://172.16.1.150/artifactory/build/sandbox.erlang.superviser/190/superviser-202009091259-190.tar.gz
  tar -xzvf superviser-202009091259-190.tar.gz

ConfD: versão 7.4

  cd ~/superviser_dist
  export ECONFD_OC_DIR=`pwd`/lib/econfd_oc-0.1.0
  confd -c ${ECONFD_OC_DIR}/priv/confd/etc/confd/confd-7.4-nso.conf --addloadpath ${CONFD_DIR}/etc/confd --addloadpath ${ECONFD_OC_DIR}/priv/models/fxs

Executar a aplicação

  ./bin/superviser console

Você desejará usar o nome da pasta NED em **${NCS_DIR}/packages/neds ** para a versão mais recente do NED instalada para a plataforma de destino. Você pode usar a guia completa depois de começar a digitar um caminho (ou apenas copiar e colar, embora verifique se os números da versão NED abaixo correspondem aos que estão atualmente na sandbox para evitar um erro de sintaxe):

source ~/nso-5.3/ncsrc
# adicionar um novo device
cd ~/nso-5.3/packages/neds/
ncs-make-package --netconf-ned ~/yang padtec-spvlhb
cd padtec-spvlhb/src
make
cd -
# configurar uma instância
ncs-setup --no-netsim --package ./padtec-spvlhb --generate-ssh-keys --dest ~/nso-instance
ls -l ~/nso-instance

Verifique o xml de metadados. O ned-id gerado é padtec-spvlhb-nc-1.0 e estará disponível para instanciar devices quando o NSO for iniciado.

cat ~/nso-5.3/packages/neds/padtec-spvlhb/package-meta-data.xml

?xml version="1.0"?>
<!-- This file has been generated. Do NOT edit it.
     For changes edit the original instead.
-->
<ncs-package xmlns="http://tail-f.com/ns/ncs-packages">
  <name>padtec-spvlhb-nc-1.0</name>
  <package-version>1.0</package-version>
  <description>Generated netconf package</description>
  <ncs-min-version>5.3</ncs-min-version>
  <component>
    <name>padtec-spvlhb</name>
    <ned>
      <netconf>
        <ned-id xmlns:id="http://tail-f.com/ns/ned-id/padtec-spvlhb-nc-1.0">id:padtec-spvlhb-nc-1.0</ned-id>
      </netconf>
      <device>
        <vendor>Acme</vendor>
      </device>
    </ned>
  </component>
</ncs-package>

2. Se você verificar o diretório nso-instance agora, verá que vários novos arquivos e pastas foram criados. Não vamos passar por todos eles em detalhes agora, mas alguns são úteis para conhecer.

ncs.conf é o arquivo de configuração do aplicativo NSO. Usado para personalizar aspectos da instância NSO (alterar portas, habilitar / desabilitar recursos, etc.). Os padrões geralmente são perfeitos para projetos como este.
packages/ é o diretório que possui links simbólicos para os NEDs que referenciamos nos argumentos –package na configuração.
logs/ é o diretório que contém todos os logs do NSO. Este diretório é útil para solucionar problemas.

3. Agora você precisa "iniciar" sua instância NSO. Navegue até o diretório nso-instance e digite o comando ncs. A execução levará alguns segundos e você não obterá nenhuma saída explícita, a menos que haja um problema.

# ncs --stop
ncs --with-package-reload

4. Você pode verificar se o NSO está sendo executado usando o comando ncs –status | grep status, que tem uma grande quantidade de informações, então usamos grep apenas para pesquisar o status:

ncs --status | grep status
status: started
        db=running id=31 priority=1 path=/ncs:devices/device/live-status-protocol/device-type

Etapa 3: Preencher sua instância NSO

Agora que você tem uma instância local do NSO criada e em execução, precisa de mais algumas coisas antes de começar a automatizar:

Um grupo de autenticação que ativa a autenticação de credencial do dispositivo.
Informações do dispositivo para preencher a lista de dispositivos.
Os grupos de dispositivos são úteis, mas não obrigatórios.

Configurando a autenticação do dispositivo (IGNORAR)

Com o NSO em execução, agora você precisa adicionar seus dispositivos ao seu inventário. Isso permite que o NSO leia e grave dados. NSO usa grupos de autenticação para configurar credenciais de acesso ao dispositivo. Você configurará um grupo de autenticação simples para sua rede.

1. Insira sua instância NSO com o comando admin ncs_cli -C -u. Este comando possui várias opções. Este exemplo usa -C para especificar uma interface de linha de comando "estilo Cisco" (o padrão é um estilo Juniper) e -u admin para fazer login como o usuário "admin".

Nota:
Você pode emitir o comando ncs_cli -C -u admin de qualquer lugar no devbox quando o NSO estiver em execução, não apenas no diretório nso-instance. Este é o comando mais comumente usado que você usará com o NSO.

ncs_cli -C -u admin

2. Entre no "modo de configuração" com o comando config.

admin@ncs# config
Entering configuration mode terminal
admin@ncs(config)#

3. Você configurará um novo grupo de autenticação chamado labadmin. Este grupo usará uma combinação de nome de usuário/senha padrão para dispositivos, com uma senha secundária de Padtec. Use os seguintes comandos:

devices authgroups group spvlnet
default-map remote-name padtec
default-map remote-password padtec
default-map remote-secondary-password admin

4. Inserir esta configuração no NSO a "prepara", mas a configuração não é enviada ao sistema até que você use o comando commit. Antes de fazer isso, volte ao início do modo de configuração e revise a configuração atualmente preparada com show config.

top
show config

Esta é uma maneira conveniente de ver qual configuração está pronta para ser confirmada antes de finalizá-la. Observe que o NSO usa um modelo de criptografia local para armazenar as credenciais em seu banco de dados.

Agora commit a configuração para efetuar as alterações.

commit

Adicionando dispositivos ao Cisco NSO

Com o seu authgroup configurado (ou não), vamos prosseguir e adicionar seus dispositivos ao inventário. Para adicionar um dispositivo, você precisará das seguintes informações:

O endereço IP ou FQDN do dispositivo.
O protocolo (ssh / telnet) e a porta (se não padrão) para conectar ao dispositivo.
O grupo de autenticação a ser usado para o dispositivo (que deve ser confirmado antes de adicionar dispositivos).
O NED (driver de dispositivo) que você usará para se conectar ao dispositivo.

Neste exercício, você percorrerá a adição do primeiro dispositivo passo a passo e, em seguida, adicionará em massa o restante deles.

1. Permaneça no modo de configuração em NSO dentro do ncs_cli.

admin@ncs(config)#

2. Adicione my-device-175 usando esta informação:

IP Address: 172.30.0.175
NED: padtec-spvl

Você desativará a verificação da chave do host SSH (em sistemas de produção, você pode configurar a chave do host ou apenas "pesquise" para aprender)

3. Insira a seguinte configuração no NSO. Sinta-se à vontade para copiar e colar ou usar o preenchimento de tabulação:

admin@ncs(config)# devices device my-device-175
admin@ncs(config-device-my-device-175)# address 172.30.0.175
admin@ncs(config-device-my-device-175)# port 12052
admin@ncs(config-device-my-device-175)# authgroup default
admin@ncs(config-device-my-device-175)# local-user admin
admin@ncs(config-device-my-device-175)# device-type netconf ned-id padtec-spvlhb
admin@ncs(config-device-my-device-175)# ssh host-key-verification none
admin@ncs(config-device-my-device-175)# ned-settings use-confirmed-commit false

4. Agora commit a configuração para o NSO.

admin@ncs(config-device-my-device-175)# commit
Commit complete.

5. Verifique se você ainda está no contexto CLI para o dispositivo. Você saberá disso pelo prompt (my-device-175) ou verificando com pwd:

admin@ncs(config-device-my-device-175)# pwd
  Current submode path: devices device my-device-175
admin@ncs(config-device-my-device-175)#

6. Use o comando de conexão para determinar se você pode se conectar ao dispositivo com NSO.

admin@ncs(config-device-my-device-175)# connect
result false
info Device my-device-175 is southbound locked

A saída mostra que você está bloqueado no momento. O modo padrão do NSO para dispositivos é um estado bloqueado que impede o NSO de manipular um dispositivo antes que o administrador da rede esteja pronto. Essa habilidade também pode ser usada para desativar um dispositivo que está atualmente em manutenção para evitar que o NSO atue sobre ele.

7. Desbloqueie o dispositivo alterando seu estado de administrador e confirme a alteração.

admin@ncs(config-device-my-device-175)# state admin-state unlocked
admin@ncs(config-device-my-device-175)# commit
Commit complete.

8. Agora tente se conectar novamente.

admin@ncs(config-device-my-device-175)# connect
result true
info (admin) Connected to my-device-175 - 172.30.0.175:12052

Estado da rede atual - "aprendizagem" (sync-from)

Agora o NSO pode se conectar com sucesso à rede, mas não "aprendeu" a configuração de rede atual implantada nos dispositivos. Vamos consertar isso.

1. Verifique se não há nenhuma configuração de nível de dispositivo real dentro do NSO ainda olhando para um dispositivo com o comando show:

admin@ncs(config-device-my-device-175)# top
admin@ncs(config)# exit
admin@ncs# show running-config devices device my-device-175 config
% No entries found.

2. O comando NSO sync-from permite que os dispositivos de rede "aprendam" a configuração atual.
Certifique-se de NÃO inserir device sync-to por engano. O NSO tentará sobrescrever a configuração nos dispositivos com a configuração "em branco" que o NSO tem atualmente para os dispositivos. Isso seria ruim aqui (embora haja situações em que você pode querer fazer isso).

admin@ncs# devices device my-device-175 sync-from
result true

3. Verifique a configuração de execução do NSO dos dispositivos novamente.

admin@ncs# show running-config devices device my-device-175 config devices device linecard0_4 terminal-device logical-channels channel 101
devices device my-device-175
 config
  devices device linecard0_4
   terminal-device logical-channels channel 101
    config index          101
    config trib-protocol  PROT_NONE
    config logical-channel-type PROT_UNDEFINED
    config loopback-mode  NONE
    config logical-channel-stage STAGE_UNDEFINED
   !
  !
 !
!

Material original das Etapas 1-3

https://developer.cisco.com/learning/lab/learn-nso-the-easy-way/step/1
https://developer.cisco.com/learning/lab/learn-nso-the-easy-way/step/2
https://developer.cisco.com/learning/lab/learn-nso-the-easy-way/step/3

Etapa 6: Templates

https://developer.cisco.com/learning/lab/learn-nso-the-easy-way/step/6

config
devices template SET-TRIB-PROTOCOL-NONE
ned-id padtec-spvlhb-nc-1.0
config
devices device linecard0_2
terminal-device logical-channels channel 101
config trib-protocol pad-opt-types:PROT_NONE
terminal-device logical-channels channel 201
config trib-protocol pad-opt-types:PROT_NONE
devices device linecard0_4
terminal-device logical-channels channel 101
config trib-protocol pad-opt-types:PROT_NONE
terminal-device logical-channels channel 201
config trib-protocol pad-opt-types:PROT_NONE
commit
devices device my-device-175 apply-template template-name SET-TRIB-PROTOCOL-NONE
commit

Exercício: device-groups

Etapa 9: Serviços

https://developer.cisco.com/learning/lab/learn-nso-the-easy-way/step/9

O "S" em NSO significa serviços. O Network Services Orchestrator tem um mecanismo de configuração de serviço muito poderoso. Os serviços NSO são usados para criar instâncias de serviços para implantar em sua rede. Você pode definir qualquer conjunto arbitrário de modelos de configuração e um conjunto de variáveis para conectar a esses modelos que são aplicados a um ou mais dispositivos de rede. A NSO também controla esses serviços, de modo que, se você remover essas instâncias de serviço, ele apenas removerá ou atualizará a configuração relacionada ao serviço e não qualquer coisa extra. Uma instância de serviço pode ser um cliente, um locatário, um id de site ou qualquer coisa que você quiser.

Os serviços também permitem que você exponha a funcionalidade da rede de uma forma abstrata para outras equipes de rede ou outras partes interessadas.

Vamos vê-lo em ação e depois voltar um pouco à teoria.

Criação do pacote de serviço

NSO usa um sistema de gerenciamento de pacote embutido para lidar com NEDs e pacotes personalizados, como pacotes de serviço. Os pacotes de serviço são uma coleção de arquivos e pastas estruturados que o NSO carrega no aplicativo para estender o NSO com novas funcionalidades.

Uma ferramenta CLI bash integrada chamada ncs-make-package gera automaticamente uma estrutura de esqueleto de arquivos e pastas para a criação de um pacote de serviço. Você vai começar com isso.

1. Não inicie o NSO CLI ainda. Em vez disso, mude para o diretório nso-instance/packages (é onde o NSO procura por novos pacotes.) E primeiro olhe todas as opções disponíveis usando o comando ncs-make-package -h. Em seguida, crie um esqueleto de serviço usando o comando ncs-make-package –service-skeleton template loopback-service.

source ~/nso-5.3/ncsrc
cd ~/nso-instance/packages/
ls
ncs-make-package -h
ncs-make-package --service-skeleton template loopback-service
cat loopback-service/src/yang/loopback-service.yang

2. Use o comando tree para ver a estrutura da pasta.

Os principais arquivos que você editará são loopback-service/src/yang/loopback-service.yang e loopback-service/templates/loopback-service-template.xml. Os serviços também podem codificar a lógica, mas neste exemplo simples, você usará apenas os recursos mais básicos.

$ tree loopback-service/

OUTPUT:

loopback-service/
├── package-meta-data.xml
├── src
│&nbsp;&nbsp; ├── Makefile
│&nbsp;&nbsp; └── yang
│&nbsp;&nbsp;     └── loopback-service.yang
├── templates
│&nbsp;&nbsp; └── loopback-service-template.xml
└── test
    ├── internal
    │&nbsp;&nbsp; ├── lux
    │&nbsp;&nbsp; │&nbsp;&nbsp; ├── basic
    │&nbsp;&nbsp; │&nbsp;&nbsp; │&nbsp;&nbsp; ├── Makefile
    │&nbsp;&nbsp; │&nbsp;&nbsp; │&nbsp;&nbsp; └── run.lux
    │&nbsp;&nbsp; │&nbsp;&nbsp; └── Makefile
    │&nbsp;&nbsp; └── Makefile
    └── Makefile

3. Visualize o conteúdo de loopback-service/src/yang/loopback-service.yang e loopback-service/templates/loopback-service-template.xml.

cat loopback-service/src/yang/loopback-service.yang

module loopback-service {
  namespace "http://com/example/loopbackservice";
  prefix loopback-service;

  import ietf-inet-types {
    prefix inet;
  }
  import tailf-ncs {
    prefix ncs;
  }

  list loopback-service {
    key name;

    uses ncs:service-data;
    ncs:servicepoint "loopback-service";

    leaf name {
      type string;
    }

    // may replace this with other ways of refering to the devices.
    leaf-list device {
      type leafref {
        path "/ncs:devices/ncs:device/ncs:name";
      }
    }

    // replace with your own stuff here
    leaf dummy {
      type inet:ipv4-address;
    }
  }
}

cat loopback-service/templates/loopback-service-template.xml

<config-template xmlns="http://tail-f.com/ns/config/1.0"
                 servicepoint="loopback-service">
  <devices xmlns="http://tail-f.com/ns/ncs">
    <device>
      <!--
          Select the devices from some data structure in the service
          model. In this skeleton the devices are specified in a leaf-list.
          Select all devices in that leaf-list:
      -->
      <name>{/device}</name>
      <config>
        <!--
            Add device-specific parameters here.
            In this skeleton the service has a leaf "dummy"; use that
            to set something on the device e.g.:
            <ip-address-on-device>{/dummy}</ip-address-on-device>
        -->
      </config>
    </device>
  </devices>
</config-template>

Os arquivos criados já possuem alguns detalhes preenchidos a título de sugestão.

O arquivo Yang tem uma lista (list loopback-service) para controlar todas as instâncias de serviço (mais sobre isso mais tarde).
Dentro da definição de serviço, existem alguns nomes de variáveis folha inseridos, nome, dispositivo e fictício. Uma folha é simplesmente uma única chave: entrada de valor.
– A variável name é a consulta de chave exclusiva da instância de serviço (mais sobre isso também).
– A variável device é uma referência dinâmica no NSO CDB para a lista de dispositivos.
– A variável dummy é uma entrada de amostra para usar em um modelo de dispositivo, com um tipo de variável de endereço IP.

O arquivo XML é a configuração que o NSO usará para aplicar aos seus dispositivos de rede. Você conecta os nomes das variáveis de seu arquivo Yang aqui para ter uma configuração dinâmica. Você também pode usar vários arquivos Yang (mais frequentemente com lógica de código Python ou Java extra).
A parte importante do arquivo XML que você usará está entre as tags <config> e </config>, que agora tem um comentário XML.

NSO usa Yang para definir os nomes de variáveis e restrições nessas variáveis (como a variável é um inteiro, endereço IP ou string). Isso pode ser confuso para alguns novos usuários, já que muitas pessoas costumam associar Yang a NETCONF ou RESTCONF. Neste caso, Yang está sendo usado para modelar os dados que estão sendo inseridos no serviço, e não está sendo usado especificamente em conjunto com NETCONF ou RESTCONF

A NSO usa XML nos bastidores para representar a configuração de cada dispositivo. Se você não está familiarizado com XML, não se preocupe, o NSO permite que você exiba a configuração nativa em XML usando ncs_cli, que você pode copiar e colar.

Agora você precisa obter algum XML para conectar a esse arquivo de modelo.

1. Abra o NSO CLI e entre no modo de configuração. Vamos obter a configuração do device my-device-175 primeiro. Crie um loopback com os seguintes comandos, mas não confirme:

ncs_cli -C -u admin
config
devices device my-device-175 config devices device linecard0_2 terminal-device logical-channels channel 101 config loopback-mode FACILITY
top
show configuration
commit dry-run outformat xml

2. Agora visualize a configuração pendente e, em seguida, visualize a saída de simulação em formato XML:

OUTPUT:

result-xml {
    local-node {
        data <devices xmlns="http://tail-f.com/ns/ncs">
               <device>
                 <name>my-device-175</name>
                 <config>
                   <devices xmlns="http://padtec.com.br/yang/padtec-device"> <<-----
                     <device>
                       <name>linecard0_2</name>
                       <terminal-device>
                         <logical-channels>
                           <channel>
                             <index>101</index>
                             <config>
                               <loopback-mode>FACILITY</loopback-mode>
                             </config>
                           </channel>
                         </logical-channels>
                       </terminal-device>
                     </device>
                   </devices>                                                <<------
                 </config>
               </device>
             </devices>
    }
}

3. Agora que você tem a saída XML, deseja copiar e colar apenas os snippet entre as tags de configuração (apenas a parte da interface):

<devices xmlns="http://padtec.com.br/yang/padtec-device">
  <device>
    <name>linecard0_2</name>
    <terminal-device>
      <logical-channels>
        <channel>
          <index>101</index>
          <config>
            <loopback-mode>FACILITY</loopback-mode>
          </config>
        </channel>
      </logical-channels>
    </terminal-device>
  </device>
</devices>

4. Fora do NSO, em um editor de texto, edite loopback-service/templates/loopback-service-template.xml e adicione o snippet XML nas tags <config>:

cd ~/nso-instance/packages/
vim loopback-service/templates/loopback-service-template.xml

Edite:

<config-template xmlns="http://tail-f.com/ns/config/1.0"
                 servicepoint="loopback-service">
  <devices xmlns="http://tail-f.com/ns/ncs">
    <device>
      <!--
          Select the devices from some data structure in the service
          model. In this skeleton the devices are specified in a leaf-list.
          Select all devices in that leaf-list:
      -->
      <name>{/device}</name>
      <config>
        <devices xmlns="http://padtec.com.br/yang/padtec-device">
          <device>
            <name>{/linecard}</name>
            <terminal-device>
              <logical-channels>
                <channel>
                  <index>{/channel}</index>
                  <config>
                    <loopback-mode>{/mode}</loopback-mode>
                  </config>
                </channel>
              </logical-channels>
            </terminal-device>
          </device>
        </devices>
      </config>
    </device>
  </devices>
</config-template>

5. Agora adicione as variáveis ao modelo de configuração, respeitando os os tipos:

{/linecard} : string
{/channel} : uint32
{/mode} : oc-opt-types:loopback-mode-type

cd ~/nso-instance/packages/loopback-service/src/yang
vim loopback-service/src/yang/loopback-service.yang

module loopback-service {
  namespace "http://com/example/loopbackservice";
  prefix loopback-service;

  import ietf-inet-types {
    prefix inet;
  }
  import tailf-ncs {
    prefix ncs;
  }

  import openconfig-transport-types {
    prefix oc-opt-types;
  }

  list loopback-service {
    key name;

    uses ncs:service-data;
    ncs:servicepoint "loopback-service";

    leaf name {
      type string;
    }

    // may replace this with other ways of refering to the devices.
    leaf-list device {
      type leafref {
        path "/ncs:devices/ncs:device/ncs:name";
      }
    }

    // replace with your own stuff here
    leaf linecard {
      type string;
    }
    leaf channel {
      type uint32;
    }
    leaf mode {
     type oc-opt-types:loopback-mode-type;
    }
  }
}

6. Salve o arquivo e saia da sessão de configuração, descartando as alterações.

7. Em seu terminal bash, navegue até o diretório loopback-service/src/ e emita o comando make para compilar o modelo de dados Yang.

Edite o Makefile para informar o path dos modelos:

cd nso-instance/packagesloopback-service/src
vim Makefile

Editar o Makefile:

YANGPATH += ../../padtec-spvlhb/src/ncsc-out/modules/yang

Compilar:

make
mkdir -p ../load-dir
/home/spvlnet//nso-5.3/bin/ncsc  `ls loopback-service-ann.yang  > /dev/null 2>&1 && echo "-a loopback-service-ann.yang"` \
             --yangpath ../../padtec-spvlhb/src/ncsc-out/modules/yang -c -o ../load-dir/loopback-service.fxs yang/loopback-service.yang

8. Agora que o XML está atualizado e o Yang compilado, você pode carregar o novo pacote de serviço. Volte para a NSO CLI e emita os seguintes comandos:

ncs_cli -C -u admin
admin@ncs# packages reload
>>> System upgrade is starting.
>>> Sessions in configure mode must exit to operational mode.
>>> No configuration changes can be performed until upgrade has completed.
>>> System upgrade has completed successfully.
reload-result {
    package loopback-service
    result true
}
reload-result {
    package padtec-spvlhb-nc-1.0
    result true
}

| packages reload is used for reloading all the packages when there is a NED update or a new service package. There also is an optional argument force which sometimes is needed to migrate data models. |

Etapa 10: Instanciando Serviços

https://developer.cisco.com/learning/lab/learn-nso-the-easy-way/step/10

1. No NSO CLI, entre no modo de configuração e use o ponto de interrogação para descobrir a nova opção CLI do pacote recém-carregado:

 admin@ncs# config
 Entering configuration mode terminal
 admin@ncs(config)#
 admin@ncs(config)# loo?
 Possible completions:
   loopback-service
 admin@ncs(config)# loo

2. Use o novo comando loopback-service para criar uma instância de serviço com um nome chamado test e preencher:

device: my-device-175
linecard: linecard0_2
channel: 101
mode: FACILITY

Brinque com o '?' para ver as opções disponíveis. Observe também que, como o NSO conhece os tipos de dados para as variáveis do modelo Yang, ele irá sugerir que tipo de entrada fornecer e validar se está em conformidade com esses tipos de dados antes de salvar os valores. Já que você vinculou a variável de device ao CDB, ele irá sugerir automaticamente a partir de '?' da lista de dispositivos.

admin@ncs(config-loopback-service-test)# device my-device-175
admin@ncs(config-loopback-service-test)# linecard linecard0_2
admin@ncs(config-loopback-service-test)# channel 101
admin@ncs(config-loopback-service-test)# mode FACILITY

3. Visualize a configuração do serviço a ser enviada ao dispositivo e confirme a alteração com os seguintes comandos:

 admin@ncs(config-loopback-service-test)# top
 admin@ncs(config)# commit dry-run outformat native
 admin@ncs(config)# show configuration
 admin@ncs(config)# commit

OUTPUT:

admin@ncs(config-loopback-service-test)# top
admin@ncs(config)# commit dry-run outformat native
native {
    device {
        name my-device-175
        data <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
                  message-id="1">
               <edit-config xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
                 <target>
                   <candidate/>
                 </target>
                 <test-option>test-then-set</test-option>
                 <error-option>rollback-on-error</error-option>
                 <config>
                   <devices xmlns="http://padtec.com.br/yang/padtec-device">
                     <device>
                       <name>linecard0_2</name>
                       <terminal-device>
                         <logical-channels>
                           <channel>
                             <index>101</index>
                             <config>
                               <loopback-mode>FACILITY</loopback-mode>
                             </config>
                           </channel>
                         </logical-channels>
                       </terminal-device>
                     </device>
                   </devices>
                 </config>
               </edit-config>
             </rpc>
    }
}
admin@ncs(config)# show configuration
loopback-service test
 device   [ my-device-175 ]
 linecard linecard0_2
 channel  101
 mode     FACILITY
!
admin@ncs(config)# commit
Commit complete.

Verifique.

config
admin@ncs(config)# show configuration running  devices device my-device-175 config devices device linecard0_2 terminal-device logical-channels channel 101 config loopback-mode
devices device my-device-175
 config
  devices device linecard0_2
   terminal-device logical-channels channel 101
    config loopback-mode FACILITY
   !
  !
 !
!

Re-deploy de Serviço

Vamos supor que alguém vá até seu dispositivo de rede e faça uma alteração. Essa alteração é uma alteração out-of-band que a NSO desconhece e que está em conflito com o seu serviço. O que você faz?

1. Saia do NSO e volte para o terminal bash.

2. Verifique a config de loopback no device:

Neste passo, vamos utilizar o netconf-console para ler e modificar a config corrente de loopback diretamente no dispositivo.

Nota: foi necessário instalar libxml2-utils e a lib python-paramiko. Pule os passos se o ambiente já estiver configurado.

libxml-utils (PULAR)

sudo apt-get install libxml2-utils

python-paramiko(PULAR)

source ~/Vpy27/bin/activate
pip install paramiko
deactivate

Se não estiver no virtualenv:

source ~/Vpy27/bin/activate

Verificando a config de loopback:

(Vpy27) spvlnet@nso-esi-212:/home/spvlnet/nso-instance/packages/loopback-service/src$ netconf-console --host=172.30.0.175 --port=12052 --db running --get-config -x '/devices/device[name="linecard0_2"]/terminal-device/logical-channels/channel[index=101]/config/loopback-mode'

OUTPUT:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <data>
    <devices xmlns="http://padtec.com.br/yang/padtec-device">
      <device>
        <name>linecard0_2</name>
        <terminal-device>
          <logical-channels>
            <channel>
              <index>101</index>
              <config>
                <loopback-mode>FACILITY</loopback-mode>
              </config>
            </channel>
          </logical-channels>
        </terminal-device>
      </device>
    </devices>
  </data>
</rpc-reply>

3. Crie um arquivo de config para modificar o valor de loopback-mode:

(Vpy27) spvlnet@nso-esi-212:/home/spvlnet/nso-instance/packages/loopback-service/src$ vim loopback-mode-none.xml

Adicione e salve o arquivo loopback-mode-none.xml:

<devices xmlns="http://padtec.com.br/yang/padtec-device">
  <device>
    <name>linecard0_2</name>
    <terminal-device>
      <logical-channels>
        <channel>
          <index>101</index>
          <config>
            <loopback-mode>NONE</loopback-mode>
          </config>
        </channel>
      </logical-channels>
    </terminal-device>
  </device>
</devices>

Agora, use o netconf-console para modificar o valor do loopback-mode:

(Vpy27) spvlnet@nso-esi-212:/home/spvlnet/nso-instance/packages/loopback-service/src$ netconf-console --host=172.30.0.175 --port=12052 --db running --edit-config='loopback-mode-none.xml'

OUTPUT:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <ok/>
</rpc-reply>

Verifique utilizando o netconf-console.

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <data>
    <devices xmlns="http://padtec.com.br/yang/padtec-device">
      <device>
        <name>linecard0_2</name>
        <terminal-device>
          <logical-channels>
            <channel>
              <index>101</index>
              <config>
                <loopback-mode>NONE</loopback-mode>
              </config>
            </channel>
          </logical-channels>
        </terminal-device>
      </device>
    </devices>
  </data>
</rpc-reply>

Saia do virtualenv.

deactivate

4. Entre novamente no NSO CLI e veja o entendimento do NSO sobre o dispositivo. Ele ainda não está ciente da mudança; o Loopback ainda está presente no CDB do dispositivo:

ncs_cli -C -u admin
admin@ncs# show running-config devices device my-device-175 config devices device linecard0_2 terminal-device logical-channels channel 101 config loopback-mode
devices device my-device-175
 config
  devices device linecard0_2
   terminal-device logical-channels channel 101
    config loopback-mode FACILITY
   !
  !
 !
!

5. Visualize e execute sync-from para que o NSO possa reaprender a configuração do dispositivo atualizado.

 admin@ncs# devices sync-from dry-run
 admin@ncs# devices sync-from

OUTPUT:

admin@ncs# devices sync-from dry-run
sync-result {
    device my-device-175
    cli  config {
              devices {
                  device linecard0_2 {
                      terminal-device {
                          logical-channels {
                              channel 101 {
                                  config {
         -                            loopback-mode FACILITY;
         +                            loopback-mode NONE;
                                  }
                              }
                          }
                      }
                  }
              }
          }

}
admin@ncs# devices sync-from
sync-result {
    device my-device-175
    result true
}

6. Entre no modo de configuração e veja uma simulação do serviço sendo reimplantado para ver o Loopback ser adicionado novamente. Em seguida, reimplante-o.

 admin@ncs# conf
 admin@ncs(config)# loopback-service test re-deploy dry-run
 admin@ncs(config)# loopback-service test re-deploy

OUTPUT:

admin@ncs(config)# loopback-service test re-deploy dry-run
cli {
    local-node {
        data  devices {
                   device my-device-175 {
                       config {
                           devices {
                               device linecard0_2 {
                                   terminal-device {
                                       logical-channels {
                                           channel 101 {
                                               config {
              -                                    loopback-mode NONE;
              +                                    loopback-mode FACILITY;
                                               }
                                           }
                                       }
                                   }
                               }
                           }
                       }
                   }
               }

    }
}
admin@ncs(config)# loopback-service test re-deploy
admin@ncs(config)#
System message at 2020-09-09 23:40:39...
Commit performed by admin via ssh using cli.

7. Saia do NSO CLI e verifique se o loopback está presente agora, usando o netconf-console para ler a config do device.

source ~/Vpy27/bin/activate
netconf-console --host=172.30.0.175 --port=12052 --db running --get-config -x '/devices/device[name="linecard0_2"]/terminal-device/logical-channels/channel[index=101]/config/loopback-mode'
deactivate

Conclusão

Os serviços geralmente incluem muita lógica extra, incluindo (incluindo código Java/Python):

Ações de garantia e verificação para certificar-se de que a configuração teve o efeito desejado na rede.
Auto-provisionamento de endereços IP de um pool.
Configuração em vários dispositivos e tipos de dispositivos em uma única instância de serviço.
Integrações de API com outros aplicativos, como catálogos de serviços ou mecanismos de fluxo de trabalho.
Existem muitos outros recursos em relação às APIs e serviços da NSO. Cada recurso do NSO é exposto em cada API, portanto, automatizar com o NSO é uma delícia!

Parabéns! Você concluiu "Learn NSO the Easy Way by Padtec"!