Configurar NETCONF/YANG para plataformas Cisco IOS XE 16.X
Introdução
Este documento descreve como configurar NETCONF/YANG em plataformas baseadas no Cisco IOS® XE 16.x.
Pré-requisitos
Requisitos
NETCONF/YANG é suportado a partir do software Cisco IOS® XE 16.3.1.
Componentes Utilizados
As informações neste documento são baseadas nestas versões de software e hardware:
Neste exemplo, um switch WS-C3850-12X48U autônomo executando o Cisco IOS XE 16.3.3 é usado como o servidor NETCONF. Este é o dispositivo que é configurado e do qual os dados (saída do comando show) são coletados via NETCONF/YANG.
Um laptop (Apple MacBook Pro executando o MacOS Sierra 10.12.2 e o navegador Google Chrome) é usado como o cliente NETCONF. Ele atua como a plataforma de gerenciamento centralizado e usa o aplicativo Yang Explorer. É o dispositivo que cria as solicitações formatadas YANG que são enviadas ao Catalyst 3850 através de mensagens NETCONF RPC (Remote Procedure Call) para configurar e coletar dados do Catalyst 3850.
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Informações de Apoio
O exemplo dado neste documento concentra-se em testes de laboratório com o Catalyst 3850, no entanto, as informações fornecidas também se aplicam a outras plataformas Cisco IOS XE 16.x, como os roteadores da série Cisco ASR 1000.
Modelos de dados - Configuração e monitoramento programáticos e baseados em padrões
Os modelos de dados fornecem uma maneira alternativa e centralizada de configurar dispositivos Cisco (em vez de usar a Interface de Linha de Comando (CLI) da Cisco ou o Simple Network Management Protocol (SNMP)) e coletar dados operacionais (comandos show) de dispositivos Cisco. Como os modelos de dados são padrões baseados no mesmo procedimento e também podem ser usados para configurar ou coletar dados de dispositivos que não são da Cisco, isso os torna ideais para clientes que oferecem suporte a vários fornecedores. Uma plataforma de gerenciamento centralizada (por exemplo, um laptop) pode ser usada para configurar ou coletar dados de vários dispositivos Cisco e a arquitetura do modelo de dados permite automatizar esses procedimentos através de scripts Python (dois benefícios adicionais importantes).
Mais uma linguagem de modelagem de dados de próxima geração (YANG) (RFC 6020)
YANG é uma linguagem de modelagem de dados baseada em padrões usada para criar solicitações de configuração de dispositivos ou solicitações de dados operacionais (comando show). Ele tem um formato estruturado semelhante a um programa de computador que é legível por humanos. Há vários aplicativos disponíveis que podem ser executados em uma plataforma de gerenciamento centralizada (por exemplo, um laptop) para criar essas solicitações de dados operacionais e de configuração.
Há modelos de dados YANG padrão (comuns) que se aplicam a todos os fornecedores (por exemplo, uma solicitação para desativar ou desligar uma interface ethernet pode ser idêntica para dispositivos Cisco e não Cisco), bem como modelos de dados de dispositivo (nativos, específicos do fornecedor) que facilitam a configuração ou coleta de dados operacionais associados a recursos proprietários do fornecedor.
Protocolo de configuração de rede (NETCONF) (RFC 6241)
O NETCONF é um protocolo baseado em padrões e codificado em Extensible Markup Language (XML) que fornece o transporte para comunicar a configuração formatada YANG ou a solicitação de dados operacionais de um aplicativo que é executado em uma plataforma de gerenciamento centralizada (por exemplo, um laptop) para o dispositivo Cisco que um usuário deseja configurar ou solicitar dados operacionais (comando show). Ele fornece serviços baseados em transações, como abortar toda a solicitação de configuração quando uma parte dessa solicitação de configuração falha. O NETCONF usa um mecanismo simples baseado em Remote Procedure Call (RPF) para facilitar a comunicação entre um cliente (script ou aplicativo de plataforma de gerenciamento centralizado) e um servidor (switch ou roteador da Cisco). Ele usa Shell Seguro (SSH) como a camada de transporte através dos dispositivos de rede. Algumas operações NETCONF incluem get, get-config, edit-config e rpc.
Configurar
1. Configuração Básica de um Catalyst 3850 Executando o Software Cisco XE 16.3.3 para Suporte à Modelagem de Dados NETCONF/YANG
3850-1# show running-config
netconf-yang -------------------------------------> Enable NETCONF/YANG globally. It may take up to 90 seconds to initialize
username cisco1 privilege 15 password 0 cisco1 ---> Username/password used for NETCONF-SSH access
aaa new-model
aaa authorization exec default local -------------> Required for NETCONF-SSH connectivity and edit-config operations
2. Configuração Adicional (Opcional) para Permitir o Syslog NETCONF/YANG e o Monitoramento de Eventos SNMP
Essas configurações do servidor snmp devem estar presentes para permitir a geração de notificações NETCONF (RFC 5277 - Ferramentas 5277) para mensagens de Syslog e para qualquer interceptação SNMP configurada para também gerar notificações NETCONF.
Observação: embora essas sejam as entradas mínimas necessárias, entradas snmp-server enable adicionais também podem estar presentes. Um cliente (plataforma de gerenciamento centralizado) registra-se para receber o fluxo de notificação NETCONF de um servidor (Catalyst 3850) e enviar uma assinatura RPC específica (consulte a seção 3 de Configurando a Plataforma de Gerenciamento Centralizado (Laptop)).
3850-1# show running-config
snmp-server community <string> RW ------------------------------> SNMP gateway in DMI requires community public prior to 16.5.1. A configurable community is supported on 16.5.1 and later.
netconf-yang cisco-ia snmp-community-string <string> -----------> Configure the same community string to enable SNMP MIB access for both NETCONF and RESTCONF.
snmp-server trap link ietf -------------------------------------> enable traps for IETF link up/down
snmp-server enable traps snmp authentication linkdown linkup ---> enable traps for link up/down
snmp-server enable traps syslog --------------------------------> enable traps for Syslog so notifications can be generated
snmp-server manager --------------------------------------------> enable snmp-server
Para o Syslog, essa configuração deve estar presente para que a Data Model Interface (DMI) no Catalyst 3850 tenha a capacidade de gerar notificações NETCONF definidas no RFC 5277 quando mensagens de Syslog são geradas pelo Ciscod no Catalyst 3850.
logging history debugging -------> required for the generation of any NETCONF notification messages for Syslog
logging snmp-trap emergencies ---> configure 1 or more of the following to control which levels of Syslog messages are returned as notifications
logging snmp-trap alerts
logging snmp-trap critical
logging snmp-trap errors
logging snmp-trap warnings
logging snmp-trap notifications
logging snmp-trap informational
logging snmp-trap debugging
Para traps SNMP, essa configuração é necessária para gerar notificações NETCONF. No software Cisco XE 16.3.1, um máximo de 10 interceptações SNMP pode ser configurado para gerar notificações NETCONF, mas essa restrição pode ser removida em uma versão futura. A geração de notificação para interceptações SNMP está ativada por padrão. Para desativar a geração de notificações de interceptação (trapping) SNMP, use esta CLI, no netconf-yang cisco-ia snmp-trap-control global-forwarding.
netconf-yang cisco-ia snmp-trap-control trap-list 10.3.6.1.6.3.1.1.5.3 --------> LinkDown trap
netconf-yang cisco-ia snmp-trap-control trap-list 10.3.6.1.6.3.1.1.5.4 --------> LinkUp trap
netconf-yang cisco-ia snmp-trap-control trap-list 10.3.6.1.4.1.9.9.41.2.0.1 ---> Syslog generated notification trap
3. Configuração de Conectividade de Rede do Catalyst 3850 Usada neste Exemplo
A interface de gerenciamento do Catalyst 3850 GigabitEthernet0/0 é usada para se conectar à rede e à plataforma de gerenciamento centralizada (um laptop pode ser usado) neste exemplo. O Dynamic Host Configuration Protocol (DHCP) foi usado para atribuir o endereço IP 172.16.167.175 a essa interface. Configurações alternativas podem ser usadas no Catalyst 3850 desde que o laptop possa alcançar o Catalyst 3850 na rede.
3850-1# show running-config
vrf definition Mgmt-vrf
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
interface GigabitEthernet0/0
vrf forwarding Mgmt-vrf
ip address dhcp
negotiation auto
ip route vrf Mgmt-vrf 0.0.0.0 0.0.0.0 172.16.167.161
3850-1# show ip interface brief
Interface IP-Address OK? Method Status Protocol
Vlan1 10.1.1.1 YES NVRAM up up
Vlan10 10.10.10.1 YES NVRAM up up
Vlan20 10.20.20.1 YES NVRAM up up
GigabitEthernet0/0 172.16.167.175 YES DHCP up up
Fo1/1/1 unassigned YES unset down down
Fo1/1/2 unassigned YES unset down down
GigabitEthernet1/0/1 unassigned YES manual up up
GigabitEthernet1/0/2 unassigned YES unset up up
GigabitEthernet1/0/3 unassigned YES unset down down
GigabitEthernet1/0/4 unassigned YES unset down down
GigabitEthernet1/0/5 unassigned YES unset down down
Verificar NETCONF/YANG no Catalyst 3850
1. A partir da Interface de Linha de Comando (CLI - Command Line Interface) do Catalyst 3850, este comando pode ser usado para garantir que os processos de software necessários para suportar a Interface de Modelo de Dados (DMI - Data Model Interface) no Catalyst 3850 sejam executados assim que o netconf-yang for configurado.
3850-1# show platform software yang-management process
confd : Running
nesd : Running
syncfd : Running
ncsshd : Running
dmiauthd : Running
vtyserverutild : Running
opdatamgrd : Running
ngnix : Running
As próximas etapas são realizadas a partir da plataforma de gerenciamento centralizado. Neste exemplo, é usado um laptop (Apple MacBook Pro executando macOS Sierra 10.12.2) com acesso à rede para o Catalyst 3850. Os comandos são emitidos a partir de um prompt do terminal no laptop. Não há nenhum aplicativo especial carregado no laptop neste ponto.
2. Certifique-se de que a plataforma de gerenciamento centralizado (laptop) possa acessar o Catalyst 3850 (172.16.167.175) na rede.
USER1-M-902T:~ USER1$ ping 172.16.167.175
PING 172.16.167.175 (172.16.167.175): 56 data bytes
64 bytes from 172.16.167.175: icmp_seq=0 ttl=247 time=3.912 ms
64 bytes from 172.16.167.175: icmp_seq=1 ttl=247 time=6.917 ms
64 bytes from 172.16.167.175: icmp_seq=2 ttl=247 time=4.063 ms
64 bytes from 172.16.167.175: icmp_seq=3 ttl=247 time=4.371 ms
^C
3. Verifique a conectividade SSH com o Catalyst 3850 (172.16.167.175 neste exemplo) a partir da plataforma de gerenciamento centralizado (laptop) com o nome de usuário e senha (cisco1/cisco1) desta configuração do Catalyst 3850. A resposta pode ser uma longa lista de recursos NETCONF do Catalyst 3850 seguida por uma mensagem de saudação. Porta TCP 830 = netconf-ssh.
USER1-M-902T:~ USER1$ ssh -s cisco1@172.16.167.175 -p 830 netconf
cisco1@172.16.167.175’s password: cisco1
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:base:1.1</capability>
<capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
<capability>urn:ietf:params:netconf:capability:xpath:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
<capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability
--snip--
</capabilities>
<session-id>2870</session-id></ hello>]]>]]>
Use < ^C > to exit
Configurar a plataforma de gerenciamento centralizado (laptop)
1. Instalar o Aplicativo Yang Explorer em um Laptop
Neste exemplo, o aplicativo Yang Explorer é usado em um laptop (Apple MacBook Pro executando MacOS Sierra 10.12.2, navegador Google Chrome) para atuar como a plataforma de gerenciamento centralizado. O Yang Explorer permite que o usuário faça isso:
· Carregar / Compilar modelos de dados YANG a partir da interface do usuário ou da linha de comando
· Criar RPCs NETCONF (Chamadas de Procedimento Remoto)
· Executar RPC em um servidor NETCONF real (Catalyst 3850)
· Salvar RPCs criados em coleções para uso posterior
· Procurar árvores de modelos de dados e inspecionar propriedades YANG
2. Usar o Aplicativo Yang Explorer
Inicie o Aplicativo Yang Explorer - a partir de um prompt de terminal no laptop, execute o comando ./start.sh do diretório yang-explorer.
USER1-M-902T:~ USER1$ cd yang-explorer
USER1-M-902T:yang-explorer USER1$ ./start.sh &
Starting YangExplorer server ..
Use http://localhost:8088/static/YangExplorer.html
Performing system checks...
System check identified no issues (0 silenced).
January 19, 2017 - 23:12:20
Django version 1.8.3, using settings 'server.settings'
Starting development server at http://localhost:8088/
Quit the server with CONTROL-C.
Iniciar a GUI do Yang Explorer - Inicie a GUI do aplicativo Yang Explorer e faça login na GUI do aplicativo Yang Explorer como convidado/convidado no canto superior direito do menu principal da GUI do aplicativo (consulte a captura de tela).
Recuperar recursos do Catalyst 3850. Insira os detalhes do Catalyst 3850 (endereço IP, nome de usuário/senha, porta TCP 830 para ssh-netconf) e clique em Capabilities para recuperar a lista de capacidades operacionais YANG do software Catalyst 3850.
Carregar Modelos de Dados Yang - Vários modelos de dados YANG podem ser assinados em Gerenciar Modelos. Depois de inscritos, eles aparecem na caixa do Explorer à esquerda. Esses modelos YANG permitem que o aplicativo Yang Explorer crie mensagens formatadas NETCONF Remote Procedure Calls (RPC) YANG (que são enviadas ao Catalyst 3850 para configurá-lo ou recuperar dados dele) sem a necessidade de ter conhecimento profundo da YANG. Exemplos de como fazer isso são abordados na próxima seção Operacional Básica de NETCONF/YANG
Examples:
3. Assinar as Notificações NETCONF (Opcional)
Um cliente (plataforma de gerenciamento centralizado) registra-se para receber fluxos de notificação NETCONF de um servidor (Catalyst 3850) enviando esta mensagem RPC NETCONF formatada por YANG. O Catalyst 3850 envia notificações NETCONF de forma assíncrona para cada cliente que assina. Antes de concluir esta tarefa, certifique-se de que a configuração correta esteja no lugar no Catalyst 3850 para suportar as Notificações NETCONF (consulte a seção 2) de Configuração de NETCONF/YANG no Catalyst 3850. O servidor NETCONF (Catalyst 3850) começa a enviar as notificações de evento ao cliente NETCONF (Plataforma de gerenciamento centralizado) à medida que os eventos ocorrem no sistema. Essas notificações de evento podem continuar a ser enviadas até que a sessão NETCONF seja encerrada ou a assinatura seja encerrada por algum outro motivo. Consulte RFC 5277 para obter mais detalhes relacionados às opções de assinatura Tools 5277.
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<stream>snmpevents</stream>
</create-subscription>
</rpc>
Para fazer isso, você precisa recortar e colar isso na GUI do aplicativo Yang Explorer como um RPC personalizado.
Em seguida, Run é selecionado para enviar a mensagem RPC personalizada para o Catalyst 3850 via NETCONF. O Catalyst 3850 responde com uma mensagem ok para informar ao usuário que a operação foi bem-sucedida.
Exemplos Operacionais Básicos de NETCONF/YANG
Agora que o Catalyst 3850 e a plataforma de gerenciamento centralizado estão configurados e começaram a se comunicar, vamos ver alguns exemplos operacionais básicos.
Os exemplos podem demonstrar que as mensagens RPC NETCONF formatadas por YANG enviadas via NETCONF do aplicativo Plataforma de Gerenciamento Centralizado (Laptop) Yang Explorer para o Catalyst 3850 são convertidas para o Cisco IOS CLI padrão pelo processo de software confd no Catalyst 3850. Além disso, os dados CLI do Cisco IOS (show command data) são convertidos em dados formatados YANG pelo processo de software confd no Catalyst 3850 antes de serem enviados como mensagem RPC NETCONF para a aplicação Yang Explorer da Plataforma de Gerenciamento Centralizado (Laptop). Isso significa que a CLI regular ainda pode ser usada no Catalyst 3850 para configurar o switch e coletar dados do comando show além de usar NETCONF/YANG para fazer o mesmo.
1. Exemplo de Recuperação de Dados
Solicite uma lista de nomes de interface do Catalyst 3850
A operação desejada pode ser selecionada na seção do lado esquerdo Explorer da GUI do aplicativo Yang Explorer. Nesse caso, os dados do nome da interface devem ser recuperados do Catalyst 3850 e, portanto, Oper (para operação) é selecionado seguido por get-config na lista suspensa do nome da interface. O RPC é selecionado a seguir para gerar o NETCONF RPC formatado YANG (legível por humanos) que deve ser enviado ao Catalyst 3850 via NETCONF para recuperar esses dados do Catalyst 3850.
Depois que a mensagem NETCONF RPC formatada por YANG é gerada, Run é selecionado para enviá-la ao Catalyst 3850. O Catalyst 3850 responde com uma lista formatada YANG (legível por humanos) dos nomes de interface do Catalyst 3850 (GigabitEthernet1/1/1, GigabitEthernet1/1/2 e assim por diante).
2. Exemplo de Configuração
Desligar uma interface Ethernet no Catalyst 3850
A operação desejada é selecionada no lado esquerdo da seção Explorer da GUI do aplicativo Yang Explorer. Nesse caso, é necessário configurar uma interface (desligar uma interface) no Catalyst 3850 e, portanto, Config (para configuração) é selecionado, seguido pelos parâmetros operacionais exigidos nos menus suspensos da interface. RPC é selecionado em seguida para gerar o NETCONF RPC formatado YANG (legível por humanos) que deve ser enviado ao Catalyst 3850 via NETCONF para executar a tarefa de configuração.
Depois que a mensagem NETCONF RPC formatada por YANG é gerada, Run é selecionado para enviá-la ao Catalyst 3850. O Catalyst 3850 responde com uma mensagem formatada YANG (legível por humanos) que indica que a operação de configuração foi bem-sucedida (ok).
Para confirmar que a alteração ocorreu, a configuração pode ser verificada. Uma operação get-config (Oper) pode ser usada onde o Catalyst 3850 responde que a configuração GigabitEthernet 1/0/16 da interface foi ativada = false agora, o que significa que a interface foi desativada.
Depois que a mensagem NETCONF RPC formatada por YANG é gerada, Run é selecionado para enviá-la ao Catalyst 3850. O Catalyst 3850 responde com uma mensagem formatada YANG que afirma que a configuração da interface GigabitEthernet 1/0/16 foi ativada = false agora, o que significa que a interface foi desativada.
Exibição CLI do Catalyst 3850 da Configuração de Interface Antes e Depois da Alteração de Configuração NETCONF/YANG Anterior
No momento da operação anterior de alteração de configuração do Yang Explorer, esta é a saída do CLI do Catalyst 3850. A interface GigabitEthernet 1/0/16 estava no estado no shutdown padrão até que a mensagem NETCONF RPC fosse recebida, conforme visto na mensagem de log no Catalyst 3850. Depois que a mensagem NETCONF RPC for recebida, contendo a solicitação formatada YANG para desligar a interface, a operação será concluída, a interface será desligada e a configuração atual será modificada para refletir isso. Isso também demonstra como o processo de software confd no Catalyst 3850 converte a mensagem NETCONF RPC formatada YANG recebida na CLI padrão do Cisco IOS. Isso significa que um usuário ainda pode usar a CLI regular do Cisco IOS para modificar a configuração e executar comandos show, além de usar NETCONF/YANG para fazer o mesmo.
3850-1# show running-config interface gigabitEthernet 1/0/16
Building configuration...
Current configuration : 39 bytes
!
interface GigabitEthernet1/0/16
end
3850-1# show startup-config | begin 1/0/16
interface GigabitEthernet1/0/16
!
*Jan 5 17:05:55.345: %DMI-5-CONFIG_I:Switch 1 R0/0: nesd: Configured from NETCONF/RESTCONF by cisco1, transaction-id 31332
*Jan 5 17:05:57.335: %LINK-5-CHANGED: Interface GigabitEthernet1/0/16, changed state to administratively down
3850-1# show running-config interface gigabitEthernet 1/0/16
Building configuration...
Current configuration : 49 bytes
!
interface GigabitEthernet1/0/16
shutdown -------------------------> the interface is shutdown now
end
3850-1#
3850-1# show startup-config | begin 1/0/16
interface GigabitEthernet1/0/16
!
Salvar a Configuração em um Catalyst 3850
A configuração atual pode ser salva na configuração de inicialização no Catalyst 3850, enviando esta mensagem NETCONF RPC formatada por YANG para o Catalyst 3850 via NETCONF.
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<cisco-ia:save-config xmlns:cisco-ia="cisco/yang/cisco-ia"
</rpc>
Isso é feito quando você recorta e cola no aplicativo Yang Explorer como um RPC personalizado.
Executar é selecionado para enviar a mensagem RPC personalizada ao Catalyst 3850 via NETCONF. O Catalyst 3850 responde com uma mensagem de êxito.
Exibição da CLI do Catalyst 3850 da Configuração de Inicialização Salva Após a Operação de Salvamento da Configuração NETCONF/YANG Anterior
A configuração de inicialização agora corresponde à configuração de execução:
3850-1# show running-config interface gigabitEthernet 1/0/16
Building configuration...
Current configuration : 49 bytes
!
interface GigabitEthernet1/0/16
shutdown
end
3850-1# show startup-config | begin 1/0/16
interface GigabitEthernet1/0/16
shutdown
!
Configurar o Catalyst 3850 a partir do CLI
Como mencionado anteriormente, a CLI regular do Catalyst 3850 ainda pode ser usada para configurar o switch e coletar dados do comando show, além de usar NETCONF/YANG para fazer o mesmo. Quando a CLI do Catalyst 3850 é usada em vez de NETCONF/YANG para configurar o switch, a nova configuração em execução é sincronizada com a Interface de Modelo de Dados (DMI) no Catalyst 3850 através do processo de software syncfd.
3850-1# show running-config interface gigabitEthernet 1/0/16
Building configuration...
Current configuration : 49 bytes
!
interface GigabitEthernet1/0/16
shutdown
end
3850-1# config t
Enter configuration commands, one per line. End with CNTL/Z.
3850-1(config)# interface gigabitEthernet 1/0/16
3850-1(config-if)#no shutdown
3850-1(config-if)# exit
3850-1(config)# exit
3850-1#
*Jan 24 16:39:09.968: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/16, changed state to down
*Jan 24 16:39:13.479: %SYS-5-CONFIG_I: Configured from console by console
*Jan 24 16:39:15.208: %DMI-5-SYNC_START:Switch 1 R0/0: syncfd: External change to running configuration detected. The running configuration can be synchronized to the DMI data store.
*Jan 24 16:39:43.290: %DMI-5-SYNC_COMPLETE:Switch 1 R0/0: syncfd: The running configuration has been synchronized to the DMI data store.
3850-1#
Na próxima vez que o aplicativo Yang Explorer solicitar uma cópia da configuração da interface após a alteração da CLI, a alteração será refletida corretamente na saída YANG.
Run é selecionado para enviar a mensagem get-config RPC para GigabitEthernet1/0/16 para o Catalyst 3850 via NETCONF. O Catalyst 3850 responde com a configuração de interface GigabitEthernet1/0/16 que mostra enabled = true.
3. Verificar quais Dados Operacionais de SNMP MIB estão Disponíveis via Operações de Solicitação GET
Os dados SNMP MIB que podem ser retornados com operações NETCONF GET não são configuráveis pelo usuário. Todas as MIBs SNMP suportadas que são convertidas em dados estruturados definidos por modelos de dados YANG fazem parte do software Cisco XE no Catalyst 3850. Para descobrir quais dados MIB estão disponíveis nas solicitações GET, há três opções declaradas. Todas as MIBs suportadas podem incluir smiv2 na resposta de capacidade.
Opção 1. O botão Capabilities pode ser selecionado na GUI do aplicativo Yang Explorer. O Catalyst 3850 responde de volta com sua lista de capacidade que contém entradas MIB smiv2.
Opção 2. Essa mensagem RPC NETCONF formatada por YANG pode ser enviada ao Catalyst 3850 via NETCONF para recuperar a lista de recursos que inclui modelos MIB smiv2 disponíveis.
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<get>
<filter type="subtree">
<ncm:netconf-state xmlns:ncm="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<ncm:capabilities/>
</ncm:netconf-state>
</filter>
</get>
</rpc>
Isso é feito quando você recorta e cola no aplicativo Yang Explorer como um RPC personalizado.
Executar é selecionado para enviar a mensagem RPC personalizada ao Catalyst 3850 via NETCONF. O Catalyst 3850 responde com uma lista de recursos que inclui os MIBs smiv2 suportados.
Opção 3. Uma lista de modelos MIB disponíveis pode ser visualizada nas capacidades NETCONF e na mensagem Hello retornada pelo Catalyst 3850 em resposta a uma conexão SSH da Plataforma de Gerenciamento Centralizado (Laptop).
USER1-M-902T:~ USER1$ ssh -s cisco1@172.16.167.175 -p 830 netconf
cisco1@172.16.167.175’s password: cisco1
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:base:1.1</capability>
<capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
<capability>urn:ietf:params:netconf:capability:xpath:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
<capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability
--snip--
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-CONFIG-MAN-MIB?module=CISCO-CONFIG-MAN-MIB&revision=2007-04-27</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-CONTEXT-MAPPING-MIB?module=CISCO-CONTEXT-MAPPING-MIB&revision=2008-11-22</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-DATA-COLLECTION-MIB?module=CISCO-DATA-COLLECTION-MIB&revision=2002-10-30</capability>
--snip--
</capabilities>
<session-id>2870</session-id></ hello >]]>]]>
Use < ^C > to exit
Carregar Modelos de Dados YANG Adicionais
Este link contém arquivos adicionais do modelo de dados YANG. Esses arquivos permitem que operações adicionais sejam executadas via NETCONF/YANG que se relaciona a outros recursos do Catalyst 3850, como configurar o roteamento unicast IPv4, QoS e assim por diante.
Os modelos padrão (comuns, Internet Engineering Task Force (IETF)) que se aplicam a todos os fornecedores podem ser encontrados escolhendo-se standard, ietf, rfc. Isso fornece os modelos de dados YANG baseados em padrões obtidos de publicações RFC pelo corpo de padrões IETF.
Padrão Mestre de Árvore de Modelos Yang do GitHub
Os modelos nativos da Cisco (dispositivo, específico do fornecedor) podem ser encontrados selecionando-se fornecedor, cisco, xe, 1632. Isso fornece os modelos de dados YANG proprietários para o software Cisco IOS XE versão 16.3.2 para o Catalyst 3850.
Fornecedor Mestre de Árvore Yang dos Modelos GitHub Yang
Esses arquivos podem ser baixados na plataforma de gerenciamento centralizado (laptop) e, em seguida, carregados no aplicativo Yang Explorer. Existem duas maneiras de fazer isso. O primeiro é carregar os vários arquivos de modelo de dados YANG individualmente, o segundo é um carregamento em massa de todos os arquivos.
1. Carregue os vários arquivos de modelo de dados YANG individualmente
Neste exemplo, cisco-ethernet.yang já foi baixado do github para a plataforma de gerenciamento centralizado (laptop). Aqui estão as etapas para carregar o arquivo na GUI do aplicativo Yang Explorer e, em seguida, Inscrever-se para que ele seja carregado na seção Explorer da ferramenta.
2. Carregamento em Massa de Todos os Arquivos de Modelo de Dados YANG de uma Vez
Este procedimento também é mencionado na seção 5.2.2 aqui: github.
De um prompt de terminal na plataforma de gerenciamento centralizado (laptop - Apple MacBook Pro executando macOS Sierra 10.12.2):
USER1-M-902T:~ USER1$ cd yang-explorer
USER1-M-902T:yang-explorer USER1$ cd server
USER1-M-902T:server USER1$ python manage.py bulkupload --user guest --git https://github.com/YangModels/yang.git --dir vendor/cisco/xe/1632
Git upload ..
Cloning into '/Users/USER1/yang-explorer/server/data/session/tmpk7V4O6'...
remote: Counting objects: 5610, done.
remote: Total 5610 (delta 0), reused 0 (delta 0), pack-reused 5610
Receiving objects: 100% (5610/5610), 11.80 MiB | 2.34 MiB/s, done.
Resolving deltas: 100% (3159/3159), done.
Checking out files: 100% (3529/3529), done.
Cleaning up /Users/USER1/yang-explorer/server/data/session/tmpk7V4O6
Compiling : user: guest, file: /Users/USER1/yang-explorer/server/data/session/tmpHTAEP3/cisco-acl-oper.yang
DEBUG:root:Compiling session dependency ...
//anaconda/bin/pyang
DEBUG:root:Rebuilding dependencies for user guest
--snip--
Todos os modelos de dados Yang agora são vistos na GUI do aplicativo Yang Explorer. Os arquivos associados aos recursos de interesse podem ser selecionados quando você clica em Inscrever, que os adiciona à seção Explorer da ferramenta.
Outras tarefas agora podem ser concluídas, como gerar o RPC NETCONF/YANG necessário para salvar a configuração no Catalyst 3850. Isso é feito quando você seleciona o RPC save-conf na seção Explorer no lado esquerdo do aplicativo Yang Explorer. Em seguida, RPC é selecionado para gerar o RPC NETCONF com formato YANG que pode ser enviado ao Catalyst 3850 via NETCONF para salvar a configuração no Catalyst 3850.
Executar é selecionado para enviar a mensagem RPC personalizada ao Catalyst 3850 via NETCONF. O Catalyst 3850 responde com uma mensagem de êxito.
Modelos de dados YANG notáveis
Modelo de dados cisco-ia.yang
Aqui estão alguns exemplos de RPC para o modelo de dados cisco-ia.yang. Eles são notáveis porque envolvem operações como salvar a configuração do Catalyst 3850, sincronizar a configuração atual do Catalyst 3850 com o armazenamento de dados local da Interface de Modelo de Dados (DMI - Data Model Interface) e redefinir a interface DMI no Catalyst 3850.
O primeiro passo é Inscrever o modelo de dados cisco-ia.yang para que ele apareça na seção Explorer à esquerda da GUI do aplicativo do YANG Explorer.
Uma vez que o modelo de dados cisco-ia é expandido na seção Explorer à esquerda da GUI do aplicativo YANG Explorer, as várias opções operacionais são vistas. Como exemplo, para usar uma das opções de modelo de dados cisco-ia.yang disponíveis, a operação save-config é selecionada e o RPC associado é gerado quando você seleciona o botão RPC.
Em seguida, Run é selecionado para enviar a mensagem RPC ao Catalyst 3850 via NETCONF. O Catalyst 3850 responde com uma mensagem de êxito para informar ao usuário que a operação foi bem-sucedida.
Todas as várias operações do modelo de dados cisco-ia.yang são descritas aqui:
sync-from - Esse RPC faz com que a interface NETCONF no Catalyst 3850 sincronize a representação do armazenamento de dados NETCONF do dispositivo executando a configuração com a configuração em execução no dispositivo. Ambos existem no próprio Catalyst 3850.
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<cisco-ia:sync-from xmlns:cisco-ia
</rpc>
O comportamento padrão desse RPC é executar uma sincronização sem padrões, o que faz com que a saída de um comando show running-config enviado ao dispositivo seja sincronizada com o armazenamento de dados NETCONF. Se sync-defaults estiver presente, a interface NETCONF também lerá as informações de configuração padrão fornecidas pelo código de recurso. Na maioria dos casos, essa opção não é usada. Normalmente, isso só seria usado se o usuário da interface NETCONF quisesse usar os comandos NETCONF replace para substituir seções completas da configuração do dispositivo.
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<cisco-ia:sync-from xmlns:cisco-ia/>
<cisco-ia:sync-defaults/>
</cisco-ia:sync-from>
</rpc>
save-config - Este RPC executa um comando write memory (copy running-config startup-config) para salvar a configuração atual em execução do dispositivo na configuração de inicialização do dispositivo.
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<cisco-ia:save-config xmlns:cisco-ia
</rpc>
checkpoint - Esse RPC faz com que a interface NETCONF salve a configuração atual em um armazenamento não volátil usando o recurso de arquivo de configuração interno do Cisco IOSd.
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<cisco-ia:checkpoint xmlns:cisco-ia
</rpc>
rollback - Esse RPC faz com que a interface NETCONF reverta a configuração atual do dispositivo para uma configuração atual salva com o RPC de ponto de verificação ou qualquer outra configuração atual válida salva no dispositivo.
target-url string (name of the saved checkpoint file)
verbose? Boolean (show detail during rollback process)
nolock? Boolean (lock configuration)
revert-on-error? Empty (if error occurs during rollback, leave running unchanged)
revert-timer? int16 (time in seconds before revets to the original configuration)
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<cisco-ia:rollback xmlns:cisco-ia=
<cisco-ia:target-url>saved-config</cisco-ia:target-url>
<cisco-ia:verbose>true</cisco-ia:verbose>
<cisco-ia:nolock>true</cisco-ia:nolock>
<cisco-ia:revert-on-error></cisco-ia:revert-on-error>
<cisco-ia:revert-timer>10</cisco-ia:revert-timer>
</cisco-ia:rollback>
</rpc>
revert - Esse RPC faz com que a interface NETCONF altere o temporizador de reversão do RPC de reversão. Isso cancela a reversão programada e aciona a reversão imediatamente ou redefine parâmetros para a reversão programada.
now? empty
timer? int16
idle? int16
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<cisco-ia:revert xmlns:cisco-ia
<cisco-ia:now/>
<cisco-ia:timer>10</cisco-ia:timer>
<cisco-ia:idle>60</cisco-ia:idle>
</cisco-ia:revert>
</rpc>
reset - A interface NETCONF pode ser reiniciada com este RPC. Se a reinicialização for verdadeira, a interface NETCONF limpará todas as informações de estado que existem no datastore gravável em execução. Se false (o padrão), as informações de estado do armazenamento de dados de configuração do NETCONF serão preservadas.
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<cisco-ia:reset xmlns:cisco-ia
<cisco-ia:reinitialize>true</cisco-ia:reinitialize>
</cisco-ia:reset>
</rpc>
<nc:rpc-error xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<nc:error-type>application</nc:error-type>
<nc:error-tag>operation-failed</nc:error-tag>
<nc:error-severity>error</nc:error-severity>
<nc:error-path xmlns:cisco-ia
<nc:error-message lang="en" xmlns="https://www.w3.org/XML/1998/namespace">Reset not supported</nc:error-message>
<nc:error-info>
<nc:bad-element>reset</nc:bad-element>
</nc:error-info>
</nc:rpc-error>
Modelo de Dados de Ned.yang
Os modelos de dados do Network Elements Driver (NED), como o end.yang, fornecem a maior potência em termos de configuração do dispositivo Cisco (Catalyst 3850). Aqui estão algumas capturas de tela que demonstram isso.
O primeiro passo é Assinar o modelo de dados end.yang para que ele apareça na seção Explorer à esquerda da GUI do aplicativo YANG Explorer.
Percorrendo as opções disponíveis na seção Explorer no lado esquerdo do aplicativo YANG Explorer, a GUI mostra uma longa lista de recursos configuráveis do Catalyst 3850 no modelo de dados end.yang.
Como exemplo, essas capturas de tela demonstram como exibir a configuração de roteamento OSPF do Catalyst 3850 depois de rolar pela primeira vez a lista de opções de configuração de modelo de dados end.yang disponíveis na seção Explorer no lado esquerdo da GUI do aplicativo YANG Explorer. A subopção ospf está localizada dentro da opção de roteador. O RPC get-config associado é gerado quando você seleciona o botão RPC.
Em seguida, Run é selecionado para enviar a mensagem RPC ao Catalyst 3850 via NETCONF. O Catalyst 3850 responde com sua configuração de roteamento OSPF.
Esta é uma expansão da configuração de roteamento OSPF retornada pelo Catalyst 3850 em resposta à operação get-config RPC.
<rpc-reply message-id="urn:uuid:0e2c04cf-9119-4e6a-8c05-238ee7f25208" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<native xmlns>
<router>
<ospf>
<id>100</id>
<redistribute>
<connected>
<redist-options>
<subnets/>
</redist-options>
</connected>
</redistribute>
<network>
<ip>10.10.0.0</ip>
<mask>0.0.255.255</mask>
<area>0</area>
</network>
<network>
<ip>10.20.0.0</ip>
<mask>0.0.255.255</mask>
<area>0</area>
</network>
<network>
<ip>10.100.0.0</ip>
<mask>0.0.255.255</mask>
<area>0</area>
</network>
</ospf>
</router>
</native>
</data>
</rpc-reply>
A configuração de roteamento OSPF formatada pelo YANG que foi recuperada do Catalyst 3850 através do NETCONF é legível por humanos e corresponde ao que é visto quando você observa a configuração do Catalyst 3850 através da CLI do Catalyst 3850.
3850-1# show running-config | section ospf
router ospf 100
redistribute connected subnets
network 10.10.0.0 0.0.255.255 area 0
network 10.20.0.0 0.0.255.255 area 0
network 10.100.0.0 0.0.255.255 area 0
3850-1#
Se desejado, o modelo de dados end.yang também pode ser usado para modificar a configuração de roteamento OSPF. Neste exemplo, novos parâmetros de rede são adicionados à configuração de roteamento OSPF existente no Catalyst 3850, primeiro inserindo os parâmetros desejados na seção Explorer da GUI do aplicativo Yang Explorer à esquerda (o ID de roteador OSPF 100 também foi inserido, mas não é visto devido à rolagem da tela do Explorer) e, em seguida, gerando o RPC formatado YANG associado e pressionando o botão RPC.
Em seguida, Run é selecionado para enviar a mensagem RPC ao Catalyst 3850 via NETCONF. O Catalyst 3850 responde com uma mensagem ok para informar ao usuário que a operação foi bem-sucedida.
Essa operação de RPC NETCONF/YANG para modificar a configuração de roteamento OSPF através do modelo de dados end.yang é refletida na configuração do Catalyst 3850 conforme vista através da CLI do Catalyst 3850. Há também uma mensagem de syslog no Catalyst 3850 que indica que uma alteração de configuração foi feita via NETCONF.
3850-1#
*Jan 30 14:13:41.659: %DMI-5-CONFIG_I:Switch 1 R0/0: nesd: Configured from NETCONF/RESTCONF by cisco1, transaction-id 23143
3850-1# show running-config | section ospf
router ospf 100
redistribute connected subnets
network 10.10.0.0 0.0.255.255 area 0
network 10.20.0.0 0.0.255.255 area 0
network 10.30.0.0 0.0.255.255 area 0 ------> new line added to OSPF configuration
network 10.100.0.0 0.0.255.255 area 0
3850-1#
Consulte a operação save-config mencionada na seção anterior do Modelo de Dados cisco-ia.yang para obter detalhes sobre como salvar a configuração atual na configuração de inicialização do Catalyst 3850 via NETCONF/YANG.
Script Python
Gerar um script Python a partir da GUI do aplicativo Yang Explorer
A GUI do aplicativo Yang Explore também pode ser usada para gerar um script Python para uma determinada operação NETCONF/YANG. Um benefício chave do script Python é que ele permite a orquestração e a automação de operações NETCONF/YANG.
Neste exemplo, uma operação save-config é selecionada na janela do Explorer no lado esquerdo da GUI do aplicativo Yang Explorer na plataforma de gerenciamento centralizado (laptop). Em seguida, o botão Script é selecionado para gerar o script Python. O botão Copy pode ser selecionado para copiar o script de modo que ele possa ser colado em um arquivo que possa ser salvo na plataforma de gerenciamento centralizado (laptop) com uma extensão de arquivo Python .py. Para este exemplo, (não mostrado) este arquivo foi nomeado example.py.
Esta é uma expansão do script Python que foi gerado e copiado e colado em um arquivo chamado example.py na plataforma de gerenciamento centralizado (laptop).
"""
Netconf python example by yang-explorer (https://github.com/CiscoDevNet/yang-explorer)
Installing python dependencies:
> pip install lxml ncclient
Running script: (save as example.py)
> python example.py -a 172.16.167.174 -u cisco1 -p cisco1 --port 830
"""
import lxml.etree as ET
from argparse import ArgumentParser
from ncclient import manager
from ncclient.operations import RPCError
payload = """ <save-config xmlns
"""
if __name__ == '__main__':
parser = ArgumentParser(description='Usage:')
# script arguments
parser.add_argument('-a', '--host', type=str, required=True,
help="Device IP address or Hostname")
parser.add_argument('-u', '--username', type=str, required=True,
help="Device Username (netconf agent username)")
parser.add_argument('-p', '--password', type=str, required=True,
help="Device Password (netconf agent password)")
parser.add_argument('--port', type=int, default=830,
help="Netconf agent port")
args = parser.parse_args()
# connect to netconf agent
with manager.connect(host=args.host,
port=args.port,
username=args.username,
password=args.password,
timeout=90,
hostkey_verify=False,
device_params={'name': 'csr'}) as m:
# execute netconf operation
try:
response = m.dispatch(ET.fromstring(payload)).xml
data = ET.fromstring(response)
except RPCError as e:
data = e._raw
# beautify output
print(ET.tostring(data, pretty_print=True))
Execute um script Python a partir da plataforma de gerenciamento centralizado (laptop)
Esta é a verificação da CLI do Catalyst 3850 antes de executar o script Python example.py que pode salvar a configuração atual na configuração de inicialização. Nesse ponto, o comando shutdown está na configuração atual, mas não na configuração de inicialização da interface GigabitEthernet1/0/10.
3850-1# show running-config interface gigabitEthernet 1/0/10
Building configuration...
Current configuration : 49 bytes
!
interface GigabitEthernet1/0/10
shutdown
end
3850-1# show startup-config | begin 1/0/10
interface GigabitEthernet1/0/10
!
interface GigabitEthernet1/0/11
!
interface GigabitEthernet1/0/12
!
interface GigabitEthernet1/0/13
!
A partir de um prompt de terminal regular na plataforma de gerenciamento centralizado (laptop), o arquivo Python example.py que foi gerado pela GUI do aplicativo Yang Explorer é primeiro copiado para o diretório yang-explore no laptop.
USER1-M-902T:~ USER1$ pwd
/Users/USER1
USER1-M-902T:~ USER1$ cp /Users/USER1/Desktop/example.py /Users/USER1/yang-explorer
USER1-M-902T:~ USER1$ cd yang-explorer
USER1-M-902T:yang-explorer USER1$ ls -l
total 112
-rw-r--r-- 1 USER1 staff 11358 Jan 4 17:59 LICENSE
-rw-r--r-- 1 USER1 staff 13635 Jan 4 17:59 README.md
drwxr-xr-x 12 USER1 staff 408 Jan 4 17:59 YangExplorer
drwxr-xr-x 7 USER1 staff 238 Jan 4 17:59 default-models
drwxr-xr-x 3 USER1 staff 102 Jan 4 17:59 docs
-rw-r--r-- 1 USER1 staff 72 Jan 4 17:59 env.sh
-rw-r--r--@ 1 USER1 staff 1990 Jan 30 17:50 example.py
-rw-r--r-- 1 USER1 staff 207 Jan 4 17:59 requirements.txt
drwxr-xr-x 11 USER1 staff 374 Jan 5 14:37 server
-rwxr-xr-x 1 USER1 staff 4038 Jan 4 17:59 setup.sh
-rwxr-xr-x 1 USER1 staff 640 Jan 4 17:59 start.sh
drwxr-xr-x 5 USER1 staff 170 Jan 4 18:00 v
USER1-M-902T:yang-explorer USER1$
Em seguida, a partir de um prompt de terminal regular na plataforma de gerenciamento centralizado (laptop), estes dois comandos são executados que foram fornecidos na seção de comentários no início do arquivo example.py que foi gerado pela GUI do aplicativo Yang Explorer (consulte a seção anterior, Gerando um script Python a partir da GUI do aplicativo Yang Explorer).
USER1-M-902T:yang-explorer USER1$ pip install lxml ncclient
Collecting lxml
Downloading lxml-3.7.2.tar.gz (3.8MB)
100% |████████████████████████████████| 3.8MB 328kB/s
Collecting ncclient
Downloading ncclient-0.5.3.tar.gz (63kB)
100% |████████████████████████████████| 71kB 3.5MB/s
Requirement already satisfied: setuptools>0.6 in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages (from ncclient)
Collecting paramiko>=1.15.0 (from ncclient)
Downloading paramiko-2.1.1-py2.py3-none-any.whl (172kB)
100% |████████████████████████████████| 174kB 3.1MB/s
Collecting six (from ncclient)
Using cached six-1.10.0-py2.py3-none-any.whl
Collecting cryptography>=1.1 (from paramiko>=1.15.0->ncclient)
Using cached cryptography-1.7.2-cp27-cp27m-macosx_10_6_intel.whl
Collecting pyasn1>=0.1.7 (from paramiko>=1.15.0->ncclient)
Using cached pyasn1-0.1.9-py2.py3-none-any.whl
Collecting cffi>=1.4.1 (from cryptography>=1.1->paramiko>=1.15.0->ncclient)
Using cached cffi-1.9.1-cp27-cp27m-macosx_10_10_intel.whl
Collecting enum34 (from cryptography>=1.1->paramiko>=1.15.0->ncclient)
Using cached enum34-1.1.6-py2-none-any.whl
Collecting ipaddress (from cryptography>=1.1->paramiko>=1.15.0->ncclient)
Using cached ipaddress-1.0.18-py2-none-any.whl
Collecting idna>=2.0 (from cryptography>=1.1->paramiko>=1.15.0->ncclient)
Using cached idna-2.2-py2.py3-none-any.whl
Collecting pycparser (from cffi>=1.4.1->cryptography>=1.1->paramiko>=1.15.0->ncclient)
Downloading pycparser-2.17.tar.gz (231kB)
100% |████████████████████████████████| 235kB 2.6MB/s
Installing collected packages: lxml, six, pycparser, cffi, pyasn1, enum34, ipaddress, idna, cryptography, paramiko, ncclient
Running setup.py install for lxml ... -
done
Running setup.py install for pycparser ... done
Running setup.py install for ncclient ... done
Successfully installed cffi-1.9.1 cryptography-1.7.2 enum34-1.1.6 idna-2.2 ipaddress-1.0.18 lxml-3.7.2 ncclient-0.5.3 paramiko-2.1.1 pyasn1-0.1.9 pycparser-2.17 six-1.10.0
USER1-M-902T:yang-explorer USER1$
O segundo comando executa o script Python example.py no Catalyst 3850 no endereço IP 172.16.167.174 com o nome de usuário/senha cisco1/cisco1 pela porta TCP 830 (netconf-ssh). O Catalyst 3850 envia uma resposta de RPC à plataforma de gerenciamento centralizado (laptop) informando que a operação save-config foi bem-sucedida.
USER1-M-902T:yang-explorer USER1$ python example.py -a 172.16.167.174 -u cisco1 -p cisco1 --port 830
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:31e0fdee-b72f-4695-9e03-91ec771b37f5"><result xmlns>Save running-config successful
</result>
</rpc-reply>
USER1-M-902T:yang-explorer USER1
Esta é a verificação da CLI do Catalyst 3850 depois que você executa o script Python example.py que salvou a configuração atual na configuração inicial. O comando shutdown agora está presente na configuração atual e na configuração de inicialização da interface GigabitEthernet1/0/10 devido à operação save-config NETCONF/YANG bem-sucedida.
3850-1# show running-config interface gigabitEthernet 1/0/10
Building configuration...
Current configuration : 49 bytes
!
interface GigabitEthernet1/0/10
shutdown
end
3850-1# show startup-config | begin 1/0/10
interface GigabitEthernet1/0/10
shutdown
!
interface GigabitEthernet1/0/11
!
interface GigabitEthernet1/0/12
!
interface GigabitEthernet1/0/13
!
Troubleshooting
Esta seção fornece informações que podem ser usadas para o troubleshooting da sua configuração.
Mensagens de erro NETCONF
O protocolo NETCONF define um conjunto de operações e mensagens que são trocadas entre o cliente NETCONF (plataforma de gerenciamento centralizado (laptop)) e a implementação NETCONF no dispositivo de servidor (Catalyst 3850). As operações NETCONF mais usadas incluem:
<get>, <get-config>, <edit-config> e <rpc>
O formato e outras restrições no conteúdo da mensagem NETCONF são definidos pelos modelos de dados YANG. O Cliente e o Servidor NETCONF interagem enviando RPCs.
Se houver um erro no formato da mensagem NETCONF, ou o conteúdo da mensagem não corresponder às definições nos modelos de dados YANG implementados pelo dispositivo, o servidor NETCONF no dispositivo pode retornar um erro RPC.
<error-type>application</error-type>
Esses erros RPC não indicam que a interface NETCONF não está funcionando, esses erros indicam que o cliente está tentando executar uma operação que não é suportada pelos modelos de dados YANG implementados no dispositivo do servidor. Os usuários devem rever os modelos de dados YANG implementados no dispositivo do servidor para identificar e resolver as causas desses erros.
Exemplo de Erro RPC
Neste exemplo, um tipo de interface incorreto ianaift:fastEtherFX é usado para gerar a mensagem RPC <edit-config> NETCONF formatada YANG para enviar via NETCONF para o Catalyst 3850.
Quando Run é selecionado para enviar a mensagem RPC ao Catalyst 3850, o Catalyst 3850 responde com uma mensagem de erro.
Este é o erro retornado pelo Catalyst 3850. Observe que ele contém uma marca de erro "operation-failed" e mais detalhes sobre o erro dizem "Unsupported - value must be ethernetCsmacd or softwareLoopback"</nc:error-message>".
<nc:rpc-error xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<nc:error-type>application</nc:error-type>
<nc:error-tag>operation-failed</nc:error-tag>
<nc:error-severity>error</nc:error-severity>
<nc:error-path xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces">/rpc/edit-config/config/if:interfaces/if:interface[if:name='GigabitEthernet1/0/16']/if:type</nc:error-path>
<nc:error-message lang="en" xmlns="https://www.w3.org/XML/1998/namespace">/interfaces/interface[name='GigabitEthernet1/0/16']/type: "Unsupported - value must be ethernetCsmacd or softwareLoopback"</nc:error-message>
<nc:error-info>
<nc:bad-element>type</nc:bad-element>
</nc:error-info>
</nc:rpc-error>
Em seguida, vamos corrigir o erro e especificar o tipo de interface correto ianaift:ethernetCsmacd em A mensagem RPC enviada ao Catalyst 3850 de modo que o Catalyst 3850 responda com uma mensagem ok em vez de um erro.
Desta vez, depois que Run é selecionado para enviar a mensagem RPC ao Catalyst 3850, o Catalyst 3850 responde com uma mensagem ok para indicar que a operação foi bem-sucedida.
Quando Run é selecionado para enviar a mensagem RPC ao Catalyst 3850, o Catalyst 3850 responde com a configuração de interface formatada YANG, que mostra que o tipo de interface é ianaift:ethernetCsmacd.
Outros Exemplos de Tipo de Erro RPC
1. Mensagem de Resposta de Erro RPC "Em Uso" (config-locked)
Esta é uma resposta de erro NETCONF para uma solicitação <edit-config>. O <error-tag> indica "em uso". A resposta indica que o dispositivo de servidor (Catalyst 3850) NETCONF executando o armazenamento de dados está bloqueado no momento e que a operação <edit-config> NETCONF não pôde ser executada no momento. Isso não indica um erro na implementação da interface NETCONF. Se um cliente NETCONF tentar uma gravação no armazenamento de dados em execução do NETCONF quando o armazenamento de dados estiver em uso, o cliente receberá essa resposta RPC. O cliente NETCONF pode repetir a mensagem edit-config do NETCONF. Essa resposta pode ser recebida quando o dispositivo estiver executando uma operação interna de sincronização a partir do dispositivo para sincronizar o armazenamento de dados em execução NETCONF com a configuração IOSd do dispositivo.
Resposta NETCONF do servidor (Catalyst 3850) para o cliente (Plataforma de gerenciamento centralizado (Laptop)).
<?xml version="1.0" encoding="utf-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="3">
<rpc-error>
<error-type>application</error-type>
<error-tag>in-use</error-tag>
<error-severity>error</error-severity>
<error-app-tag>config-locked</error-app-tag>
<error-info>
<session-id>0</session-id>
</error-info>
</rpc-error>
</rpc-reply>
2. Mensagem de Resposta de Erro RPC "Dados Ausentes"
Neste exemplo, um <edit-config> RPC foi enviado ao Catalyst 3850 para uma interface de loopback que não foi configurada. Um erro foi retornado, pois você não pode configurar uma interface que não existe no Catalyst 3850.
<?xml version="1.0" encoding="utf-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="3">
<rpc-error>
<error-type>application</error-type>
<error-tag>data-missing</error-tag>
<error-severity>error</error-severity>
<error-path xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces">/rpc/edit-config/config/if:interfaces/if:interface[if:name='Loopback1111']/if:type</error-path>
<error-message xml:lang="en">/interfaces/interface[name='Loopback1111']/type is not configured</error-message>
<error-info>
<bad-element>type</bad-element>
</error-info>
</rpc-error>
</rpc-reply>
3. Mensagem de Resposta de Erro RPC "Modelo de Dados Ausente"
Se for feita uma solicitação para um modelo de dados que não existe no Catalyst 3850 ou uma solicitação for feita para uma folha que não está implementada em um modelo de dados, o Servidor (Catalyst 3850) responderá com uma resposta de dados vazia. Este é um comportamento esperado.
<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"/>
4. Mensagem de Resposta de Erro RPC de "Valor Inválido"
Em alguns casos, uma mensagem NETCONF pode conter conteúdo que é válido com base nos modelos de dados YANG; no entanto, o dispositivo (Catalyst 3850) não é capaz de implementar o que é solicitado. Quando a interface NETCONF no Catalyst 3850 envia configurações ao IOSd que o IOSd não pode aplicar com êxito, uma resposta de erro RPC específica é retornada ao cliente NETCONF.
Neste exemplo, um valor inválido de logging buffered de falso é enviado na mensagem RPC ao Catalyst 3850. O error-tag na resposta do Catalyst 3850 indica um valor inválido. A mensagem de erro indica que o analisador do Catalyst 3850 IOS não foi capaz de configurar o nível de gravidade de registro armazenado em buffer como falso, já que este não é um valor válido.
<?xml version="1.0" encoding="utf-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="6">
<rpc-error>
<error-type>application</error-type>
<error-tag>invalid-value</error-tag>
<error-severity>error</error-severity>
<error-message xml:lang="en">inconsistent value: Device refused command "logging buffered bogus" at column 20 </error-message>
</rpc-error>
</rpc-reply>
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
3.0 |
21-Dec-2023 |
Requisitos de marca, ortografia e formatação atualizados. |
2.0 |
01-Dec-2022 |
PII removido.
Texto Alt adicionado.
Informações de RPC de Reversão corrigidas.
Título atualizado, Introdução, tradução automática, fundamentos, requisitos de estilo e formatação. |
1.0 |
17-Sep-2021 |
Versão inicial |
Feedback