# 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 ```bash 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 ```bash sudo apt install python3-virtualenv ``` #### Preparação NSO ```bash 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 ```bash ssh spvlnet@172.31.0.212 ``` - Ter acesso aos modelos do device ConfD e disponibilizá-los no ambiente do NSO - Acessar o /home/${USER} ```bash 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` ```bash 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 ```bash 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` ```bash 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` ```bash 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 ```bash ./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): ```bash 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. ```bash cat ~/nso-5.3/packages/neds/padtec-spvlhb/package-meta-data.xml ``` ```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.** ```bash # 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:** ```bash 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. ```bash ncs_cli -C -u admin ``` **2. Entre no "modo de configuração" com o comando config.** ```bash 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:** ```bash 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.** ```bash 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. ```bash 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.** ```bash 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:** ```bash 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.** ```bash 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:** ```bash 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.** ```bash 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.** ```bash 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.** ```bash 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:** ```bash 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).* ```bash admin@ncs# devices device my-device-175 sync-from result true ``` **3. Verifique a configuração de execução do NSO dos dispositivos novamente.** ```bash 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 ```bash 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*.** ```bash 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. ```bash $ tree loopback-service/ ``` OUTPUT: ```bash loopback-service/ ├── package-meta-data.xml ├── src │   ├── Makefile │   └── yang │   └── loopback-service.yang ├── templates │   └── loopback-service-template.xml └── test ├── internal │   ├── lux │   │   ├── basic │   │   │   ├── Makefile │   │   │   └── run.lux │   │   └── Makefile │   └── Makefile └── Makefile ``` **3. Visualize o conteúdo de *loopback-service/src/yang/loopback-service.yang* e *loopback-service/templates/loopback-service-template.xml*.** ```bash cat loopback-service/src/yang/loopback-service.yang ``` ```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; } } } ``` ```bash cat loopback-service/templates/loopback-service-template.xml ``` ```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:** ```bash 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: ```xml 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):** ```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>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>`**: ```bash cd ~/nso-instance/packages/ vim loopback-service/templates/loopback-service-template.xml ``` Edite: ```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> <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:** ```bash {/linecard} : string {/channel} : uint32 {/mode} : oc-opt-types:loopback-mode-type ``` ```bash cd ~/nso-instance/packages/loopback-service/src/yang vim loopback-service/src/yang/loopback-service.yang ``` ```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: ```bash cd nso-instance/packagesloopback-service/src vim Makefile ``` Editar o Makefile: ```make YANGPATH += ../../padtec-spvlhb/src/ncsc-out/modules/yang ``` Compilar: ```bash 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:** ```bash 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:** ```bash 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. ```bash 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:** ```bash 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: ```bash 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. ```bash 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) ```bash sudo apt-get install libxml2-utils ``` - python-paramiko(PULAR) ```bash source ~/Vpy27/bin/activate pip install paramiko deactivate ``` Se não estiver no virtualenv: ```bash source ~/Vpy27/bin/activate ``` Verificando a config de loopback: ```bash (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 <?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:** ```bash (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: ```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: ```bash (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. ```xml <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. ```bash 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:** ```bash 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.** ```bash admin@ncs# devices sync-from dry-run admin@ncs# devices sync-from ``` OUTPUT: ```bash 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.** ```bash admin@ncs# conf admin@ncs(config)# loopback-service test re-deploy dry-run admin@ncs(config)# loopback-service test re-deploy ``` OUTPUT: ```bash 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.** ```bash 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"!