Inicie uma sessão NETCONF

O servidor NETCONF e o aplicativo do cliente começam emitindo um <hello> elemento de tag para especificar quais operações ou recursos eles suportam entre os definidos na especificação NETCONF. O <hello> elemento de tag inclui o <capabilities> elemento e o <session-id> elemento, que especifica o ID de processo UNIX (PID) do servidor NETCONF para a sessão. Dentro do <capabilities> elemento, cada <capability> um define uma função suportada.

O aplicativo do cliente deve emitir o <hello> elemento de tag antes de qualquer outro elemento durante a sessão NETCONF e não deve emitê-lo mais de uma vez.

Cada recurso definido na especificação NETCONF é representado em um <capability> elemento por um nome de recurso uniforme (URN). Os recursos definidos por fornecedores individuais são representados por identificadores uniformes de recursos (URIs), que podem ser URNs ou URLs. O protocolo de gerenciamento NETCONF XML emite um <hello> elemento semelhante à saída de amostra a seguir (alguns <capability> elementos aparecem em várias linhas apenas para legibilidade):

As URIs do <hello> elemento indicam os seguintes recursos suportados, o que não é uma lista exaustiva:

• urn:ietf:params:netconf:base:1.0— O servidor NETCONF oferece suporte às operações e elementos básicos definidos na especificação NETCONF base.

• urn:ietf:params:netconf:capability:candidate:1.0— O servidor NETCONF oferece suporte às operações em uma configuração de candidato.

• urn:ietf:params:netconf:capability:confirmed-commit:1.0— O servidor NETCONF oferece suporte a operações de compromisso confirmadas. Para obter mais informações, consulte Confirmar a configuração do candidato somente após a confirmação usando o NETCONF.

• urn:ietf:params:netconf:capability:validate:1.0— O servidor NETCONF oferece suporte à operação de validação, que verifica a correção sintática de uma configuração sem realmente o comprometer. Para obter mais informações, consulte Verificar a sintaxe de configuração do candidato usando o NETCONF.

• urn:ietf:params:netconf:capability:url:1.0?protocol=http,ftp,file— O servidor NETCONF aceita dados de configuração armazenados em um arquivo. Ele pode recuperar arquivos de seu sistema de arquivos local (indicado pela opção file na URN) e de máquinas remotas usando o Hypertext Transfer Protocol (HTTP) ou FTP (indicado pela http e ftp opções na URN). Para obter mais informações, consulte dados de configuração de upload e formato em uma sessão NETCONF.

• http://xml.juniper.net/netconf/junos/1.0— O servidor NETCONF oferece suporte às operações definidas na API Junos XML para solicitação e alteração de informações operacionais (os elementos de tag na referência operacional do desenvolvedor operacional da API Junos XML). O servidor NETCONF também oferece suporte a operações no protocolo de gerenciamento Junos XML para solicitar ou alterar informações de configuração.

  Os aplicativos de cliente NETCONF devem usar apenas operações nativas de protocolo de gerenciamento NETCONF XML e extensões suportadas disponíveis no protocolo de gerenciamento Junos XML para funções de configuração. A semântica das operações de protocolo Junos XML correspondentes e as operações de protocolo NETCONF XML não são necessariamente idênticas, portanto, o uso de operações de configuração de protocolo Junos XML que não sejam as extensões documentadas podem levar a resultados inesperados.

• http://xml.juniper.net/dmi/system/1.0— O servidor NETCONF oferece suporte às operações definidas na especificação da Interface de Gerenciamento de Dispositivos (DMI).

Por padrão, o servidor NETCONF não anuncia módulos YANG suportados na troca de recursos NETCONF. Para anunciar módulos YANG suportados, configure uma ou mais das seguintes declarações no nível de [edit system services netconf hello-message yang-module-capabilities] hierarquia:

• advertise-custom-yang-modules— Anuncie módulos YANG de terceiros instalados no dispositivo.
• advertise-native-yang-modules— Anuncie módulos YANG nativos do Junos OS.
• advertise-standard-yang-modules— Anuncie módulos YANG padrão suportados pelo dispositivo, por exemplo, módulos OpenConfig.

Para cumprir a especificação netconf, o aplicativo do cliente também emite um <hello> elemento para definir os recursos que oferece suporte. Ele não inclui o <session-id> elemento:

A sessão continua quando o aplicativo do cliente envia uma solicitação ao servidor NETCONF. O servidor NETCONF não emite nenhum elemento após a inicialização da sessão, exceto em resposta às solicitações do aplicativo do cliente.

A troca de <hello> elementos de tag permite que um aplicativo do cliente e o servidor NETCONF determinem se eles oferecem suporte aos mesmos recursos. Além disso, recomendamos que o aplicativo do cliente determine a versão do Junos OS em execução no servidor NETCONF. Após emitir sua <hello> tag, o aplicativo do cliente emite o <get-software-information> elemento tag em um <rpc> elemento de tag:

O servidor NETCONF devolve o <software-information> elemento de tag, que inclui os <host-name> elementos de tag e <product-name> um <package-information> elemento de tag para cada módulo Junos OS. O <comment> elemento de tag dentro do <package-information> elemento de tag especifica o número de versão do Junos OS (no exemplo a seguir, 8.2 para o Junos OS Release 8.2) e a data de criação no formato YYYYMMDD (ano, mês, dia — 12 de janeiro de 2007, no exemplo a seguir). Alguns elementos de tag aparecem em várias linhas, apenas para legibilidade:

Normalmente, a versão é a mesma para todos os módulos Junos OS em execução no dispositivo (recomendamos essa configuração para desempenho de roteamento previsível). Portanto, verificar o número da versão de apenas um módulo geralmente é suficiente.

O aplicativo do cliente é responsável por determinar como lidar com quaisquer diferenças de versão ou recursos. Para um desempenho totalmente automatizado, inclua código no aplicativo do cliente que determina se ele oferece suporte aos mesmos recursos e à versão Junos OS do servidor NETCONF. Decida quais das seguintes opções são apropriadas quando há diferenças e implemente a resposta correspondente:

• Ignore as diferenças de recursos e a versão do Junos OS e não altere o comportamento do aplicativo do cliente para acomodar o servidor NETCONF. Uma diferença nas versões do Junos OS não necessariamente torna o servidor e o cliente incompatíveis, portanto, essa é muitas vezes uma abordagem válida. Da mesma forma, é uma abordagem válida se os recursos que o aplicativo cliente não suporta são operações que são sempre iniciadas por um cliente, como a validação de uma configuração e o commit confirmado. Nesse caso, o cliente mantém a compatibilidade por não iniciar a operação.

• Altere o comportamento padrão para ser compatível com o servidor NETCONF. Se o aplicativo do cliente estiver executando uma versão posterior do Junos OS, por exemplo, ele pode optar por emitir apenas elementos de tag NETCONF e Junos XML que representam os recursos de software disponíveis na versão do servidor NETCONF do Junos OS.

• Termine a sessão NETCONF e encerre a conexão. Isso é apropriado se você decidir que não é prático acomodar a versão ou os recursos do servidor NETCONF. Para obter instruções, consulte Encerrar uma sessão NETCONF e fechar a conexão.