Entendendo o protocolo de gerenciamento NETCONF XML
Saiba mais sobre o protocolo de configuração de rede (NETCONF) e as vantagens de usar o NETCONF para gerenciar seus dispositivos de rede.
Benefícios do NETCONF
-
NETCONF é um protocolo baseado em padrões que foi desenvolvido especificamente para o gerenciamento de dispositivos de rede.
-
O NETCONF usa sessões seguras e orientadas por conexão que fornecem autenticação, integridade de dados e confidencialidade.
-
O NETCONF é independente de fornecedor, para que você possa usar as mesmas operações de base netconf para gerenciar dispositivos de diferentes fornecedores.
Visão geral do protocolo de gerenciamento NETCONF XML
O protocolo de gerenciamento NETCONF XML é um protocolo baseado em padrões que é especificamente personalizado para comunicação e gerenciamento de dispositivos de rede. A NETCONF usa um modelo de cliente/servidor e comunicação baseada em chamadas de procedimento remoto (RPC). Um cliente NETCONF estabelece uma sessão de conexão e NETCONF com um servidor NETCONF e executa operações no dispositivo. Os dispositivos Junos integram o servidor NETCONF ao OS e, portanto, o servidor não aparece como uma entrada separada em listas de processos.
A NETCONF usa a codificação de dados baseada em XML para os RPCs e dados de configuração. O protocolo NETCONF define operações básicas equivalentes aos comandos de modo de configuração CLI. Os aplicativos do cliente usam as operações de protocolo para exibir, editar e confirmar dados de configuração (entre outras operações), assim como os administradores usam os comandos de modo de configuração CLI para realizar essas operações. Em uma sessão netconf, os aplicativos do cliente também podem executar RPCs equivalentes aos comandos de modo operacional Junos OS.
Conceitualmente, o NETCONF pode ser dividido em 4 camadas. A Tabela 1 descreve as camadas.
| Descrição | da camada do NETCONF |
|---|---|
| Transporte |
A camada de transporte facilita a criação de sessões entre o cliente e o servidor usando vários protocolos. |
| Mensagens |
A camada de mensagens é um mecanismo de enquadramento independente de transporte para codificar RPCs e notificações. As tags incluem:
|
| Operações |
A camada de operações define as operações de protocolo que você pode executar em um dispositivo de rede. As operações incluem operações de protocolo base, por exemplo, |
| Conteúdo |
A camada de conteúdo contém as cargas de solicitação e resposta RPC no formato XML. Essa camada define os dados de configuração e os dados de notificação. |
A comunicação entre o servidor NETCONF e um aplicativo do cliente é baseada em sessão. O servidor e o cliente estabelecem explicitamente uma conexão e sessão antes de trocar dados. Conforme definido pela camada de transporte, a NETCONF pode usar qualquer protocolo de transporte seguro que atenda aos requisitos necessários. Os dispositivos Junos oferecem suporte a sessões netconf sobre SSH, SSH de saída, TLS e HTTPS de saída, bem como sessões de Call Home do NETCONF sobre SSH de saída.
Cada sessão do NETCONF começa com um aperto de mão, no qual as tags de troca <hello> de servidores e clientes que incluem seus recursos NETCONF suportados. Em uma sessão netconf, as mensagens de troca de clientes e servidores, que contêm RPCs, respostas de RPC ou notificações. A camada de operações netconf define as operações de protocolo que um aplicativo cliente pode usar para gerenciar um dispositivo. A camada de conteúdo descreve os parâmetros e dados codificados incluídos nos RPCs. NETCONF e a visão geral da API Junos XML descreve a camada de conteúdo com mais detalhes. Depois que o aplicativo cliente termina de fazer solicitações, ele fecha a sessão e a conexão netconf.
Um cliente da NETCONF envia RPCs ao servidor NETCONF para solicitar informações, executar comandos operacionais ou modificar a configuração em um dispositivo. O servidor NETCONF processa os RPCs e envia respostas de RPC ao cliente. Dependendo da solicitação, o RPC responde às informações solicitadas ou indica o sucesso ou falha da operação solicitada.
Para obter mais informações sobre a NETCONF, veja os seguintes RFCS:
-
RFC 6241, Protocolo de configuração de rede (NETCONF)
-
RFC 6242, usando o protocolo NETCONF sobre Secure Shell (SSH)
Visão geral da NETCONF e da API Junos XML
A API Junos XML é uma representação XML de declarações de configuração do Junos OS e comandos de modo operacional. A API Junos XML define um XML equivalente a todas as declarações na hierarquia de configuração do Junos OS e muitos dos comandos que você emite no modo operacional CLI. Cada comando de modo operacional com uma contraparte do Junos XML mapeia um elemento de tag de solicitação e, se necessário, um elemento de tag de resposta. As tags de solicitação Do Junos XML são equivalentes em função aos comandos de modo operacional correspondentes na CLI.
Os aplicativos clientes NETCONF podem solicitar informações, executar comandos operacionais ou modificar a configuração em um dispositivo Junos. O aplicativo do cliente codifica a solicitação em elementos de tag de API NETCONF e Junos XML e o envia para o servidor NETCONF no dispositivo. O servidor NETCONF direciona a solicitação para os módulos de software apropriados, codifica a resposta em elementos de tags de API NETCONF e Junos XML e retorna o resultado para o aplicativo do cliente.
Quando um cliente NETCONF modifica a configuração do Junos OS, o conteúdo do RPC inclui dados de configuração do Junos XML. Os clientes netconf também podem enviar RPCs operacionais com as tags de solicitação apropriadas para executar comandos operacionais ou recuperar informações. O servidor retorna a resposta usando elementos de API Junos XML incluídos no elemento de tag de resposta correspondente.
Por exemplo, para solicitar informações sobre o status das interfaces de um dispositivo, um aplicativo cliente envia a tag de solicitação de API <get-interface-information/> Junos XML.
<rpc>
<get-interface-information/>
</rpc>
O servidor NETCONF reúne as informações do processo de interface e as devolve no elemento de tag de resposta a API <interface-information> Junos XML.
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/25.2R1/junos"> <interface-information xmlns="http://xml.juniper.net/junos/25.2R1/junos-interface" junos:style="normal"> <physical-interface> <name> ge-0/0/0 </name> <admin-status junos:format="Enabled"> up </admin-status> ... </interface-information> </rpc-reply>
Você pode determinar o conteúdo da API Junos XML de várias maneiras. O Explorador de API XML da Juniper Networks permite que você navegue pelos elementos da API Do Junos XML. Você pode visualizar os elementos de configuração e as tags de solicitação e resposta operacionais suportadas em um determinado SO e versão.
Além disso, em dispositivos Junos, você pode usar o operador de pipe (|) na CLI para visualizar o conteúdo da API do Junos XML. Por exemplo, para recuperar a tag de solicitação operacional para um determinado comando, problema command | display xml rpc na CLI. O exemplo a seguir mostra que a tag de solicitação para o show interfaces comando é <get-interface-information>.
user@host> show interfaces | display xml rpc
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/25.2R1/junos">
<rpc>
<get-interface-information>
</get-interface-information>
</rpc>
<cli>
<banner></banner>
</cli>
</rpc-reply>
Da mesma forma, para recuperar dados de configuração no formato XML, use o show configuration | display xml comando.
user@host> show configuration system services | display xml
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/25.2R1/junos">
<configuration junos:commit-seconds="1747272887" junos:commit-localtime="2025-05-14 18:34:47 PDT" junos:commit-user="admin">
<system>
<services>
<netconf>
<ssh>
</ssh>
</netconf>
<ssh>
<root-login>allow</root-login>
</ssh>
<ftp>
</ftp>
</services>
</system>
</configuration>
<cli>
<banner></banner>
</cli>
</rpc-reply>
Você pode usar o NETCONF e a API Junos XML para gerenciar dispositivos Junos. Você pode escrever aplicativos de clientes para interagir com o servidor NETCONF. Você também pode usar o NETCONF para criar interfaces personalizadas de usuário final para a configuração e recuperação de informações e exibição, como uma interface baseada em navegador da Web.
Vantagens de usar o NETCONF e a API Junos XML
A NETCONF e a API Junos XML documentam totalmente todas as opções para todas as solicitações operacionais do Junos OS e todos os elementos em todas as declarações de configuração do Junos OS. Os nomes de tag indicam claramente a função de um elemento em uma solicitação operacional ou declaração de configuração.
A combinação de nomes de tags significativos e as regras estruturais em um DTD torna mais fácil entender o conteúdo e a estrutura de um conjunto de dados com tags XML. Os elementos de tag NETCONF e Junos XML tornam simples para os aplicativos do cliente analisar a saída do dispositivo para encontrar e exibir informações específicas, conforme descrito nas seções a seguir.
Saída de dispositivo parse
O exemplo a seguir ilustra como a API Junos XML facilita analisar a saída do dispositivo e extrair as informações necessárias. O exemplo compara a saída ascii formatada e com tags XML de um dispositivo que executa o Junos OS. A saída ASCII formatada é:
Physical interface: fxp0, Enabled, Physical link is Up Interface index: 64, SNMP ifIndex: 1
A versão correspondente com tags XML é:
<physical-interface>
<name>fxp0</name>
<admin-status junos:format="Enabled">up</admin-status>
<oper-status>up</oper-status>
<local-index>64</local-index>
<snmp-index>1</snmp-index>
...
</physical-interface>
Quando um aplicativo cliente precisa extrair um valor específico da saída ASCII formatada, ele deve confiar na localização do valor, expresso de forma absoluta ou em relação aos rótulos ou valores em campos adjacentes. Suponha que o aplicativo do cliente queira extrair o índice de interface. Ele pode usar um utilitário de correspondência de expressão regular para localizar strings específicos, mas o número de dígitos no índice de interface não é necessariamente previsível. O aplicativo do cliente não pode simplesmente ler um determinado número de caracteres após o Interface index: rótulo. Em vez disso, ele deve extrair tudo entre o rótulo e o rótulo subsequente, que é:
, SNMP ifIndex
Surge um problema se o formato ou a solicitação da saída mudarem em uma versão posterior do Junos OS. Por exemplo, a saída pode adicionar um Logical index campo após o número do índice de interface.
Physical interface: fxp0, Enabled, Physical link is Up
Interface index: 64, Logical index: 12, SNMP ifIndex: 1
Um aplicativo que extrai o número do índice de interface delimitado pelos Interface index: rótulos agora SNMP ifIndex obtém um resultado incorreto. Neste caso, você deve atualizar o aplicativo para pesquisar manualmente o seguinte rótulo:
, Logical index
Por outro lado, a natureza estruturada da saída com tag XML permite que um aplicativo do cliente recuperar o índice de interface extraindo tudo dentro da tag de abertura <local-index> e da tag de fechamento </local-index> . O aplicativo não precisa depender da posição de um elemento na cadeia de saída. Como resultado, o servidor NETCONF pode emitir os elementos da tag infantil em qualquer ordem dentro do <physical-interface> elemento. Adicionar um novo <logical-index> elemento não afeta a capacidade de um aplicativo de localizar o <local-index> elemento e extrair seu conteúdo.
Saída de dispositivo de exibição
A saída com tags XML também é mais fácil de se transformar em diferentes formatos de display. Por exemplo, você pode querer exibir diferentes quantidades de detalhes sobre um determinado componente do dispositivo em momentos diferentes. Quando um dispositivo retorna a saída ASCII formatada, você deve escrever rotinas especiais e estruturas de dados em seu aplicativo para extrair as informações necessárias para um determinado nível detalhado. Por outro lado, a estrutura inerente da saída XML é uma base ideal para as próprias estruturas de um programa de display. Você pode usar a mesma rotina de extração para vários níveis de detalhes, simplesmente ignorando os elementos de tag que você não precisa ao exibir menos detalhes.