Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configure sessões NETCONF compatíveis com RFC

Quando você usa o NETCONF para gerenciar dispositivos Junos, você pode exigir que o servidor NETCONF aplique certos comportamentos em conformidade com o RFC 4741, protocolo de configuração NETCONF durante a sessão NETCONF. Para aplicar a conformidade com a RFC, configure a rfc-compliant declaração no nível de [edit system services netconf] hierarquia. A configuração da rfc-compliant declaração afeta os seguintes aspectos da sessão NETCONF:

  • Namespaces emitidos em respostas de servidor NETCONF

  • Elementos devolvidos em respostas de <get> RPC e <get-config> operações nos casos em que não haja dados de configuração para retornar

  • O servidor NETCONF responde que devolveria um <ok/> elemento e um <rpc-error> elemento com um nível de alerta de gravidade

  • Respostas do <commit> servidor NETCONF e <validate> operações.

As diferenças são descritas em detalhes nas seções a seguir.

Namespaces

Por padrão, o servidor NETCONF define o espaço de nome padrão para o namespace NETCONF na tag de abertura da resposta do servidor, e os nomes de tags NETCONF não estão qualificados. Por exemplo:

Quando você configura a rfc-compliant declaração, o servidor NETCONF não define um namespace padrão em suas respostas. Em vez disso, o servidor inclui uma declaração de namespace para o namespace NETCONF, que está vinculado ao nc prefixo, e qualifica todas as tags NETCONF em suas respostas com o prefixo. Se você definir o namespace padrão no namespace NETCONF em uma solicitação de RPC, o servidor descarta o namespace padrão e emite sua resposta usando apenas o namespace declarado vinculado ao nc prefixo.

A saída de amostra a seguir mostra a troca de mensagens e recursos do <hello> servidor NETCONF quando a rfc-compliant declaração está configurada. A <hello> tag contém a xmlns:nc declaração, e todas as tags NETCONF incluem o nc prefixo.

A saída a seguir mostra uma resposta de RPC amostral quando a rfc-compliant declaração está configurada:

Começando pelo Junos OS Release 17.2R1, quando você configura a rfc-compliant declaração e solicita dados de configuração em uma sessão NETCONF, o servidor define o espaço de nome padrão para o <configuration> elemento no mesmo espaço de nome que no modelo YANG correspondente.

Mudanças nas operações de <get> e <get-config>

A rfc-compliant declaração afeta as respostas do <get> servidor e <get-config> dos casos em que não há dados de configuração para retornar. Isso pode ocorrer, por exemplo, quando você aplica um filtro para devolver um subconjunto da configuração, e essa parte da configuração está vazia.

Se você executar a operação ou <get-config> a <get> operação e não houver dados de configuração na hierarquia solicitada, então, se a rfc-compliant declaração não estiver configurada, a resposta do RPC contém um elemento vazio <configuration> dentro do <data> elemento.

Se você executar o ou <get-config> a <get> operação e não houver dados de configuração na hierarquia solicitada, então, se a rfc-compliant declaração estiver configurada, a resposta do RPC devolverá um elemento vazio <data> e omite o <configuration> elemento.

< erro derpc> Elementos com um nível de aviso de gravidade nas respostas do RPC

A partir do Junos OS Release 17.4R3, 18.2R2, 18.3R2 e 18.4R1, quando você configura a rfc-compliant declaração, o servidor NETCONF não pode retornar uma resposta de RPC que inclua um <rpc-error> elemento e um <ok/> elemento. Se a operação for bem-sucedida, mas a resposta do servidor incluiria um ou mais <rpc-error> elementos com um nível de aviso de gravidade, além do <ok/> elemento, então os avisos são omitidos. Além disso, a partir do Junos OS Release 21.2R1, quaisquer avisos que sejam omitidos durante uma <commit> operação são redirecionados para o arquivo de log do sistema para rastreamento.

Em versões anteriores ou quando a rfc-compliant declaração não estiver configurada, o servidor NETCONF pode emitir uma resposta de RPC que inclua um <rpc-error> elemento com um nível de aviso de gravidade e um <ok/> elemento. Por exemplo, uma operação de compromisso pode ser bem-sucedida, mas devolva um aviso como na seguinte resposta do servidor NETCONF:

Se você configurar a rfc-compliant declaração, o aviso será omitido.

Resposta do servidor NETCONF às operações de < > > e <validato>

A partir do Junos OS Release 21.2R1, quando você configura a rfc-compliant declaração, a resposta do servidor NETCONF às <commit> operações inclui as seguintes alterações:

  • Se uma operação bem-sucedida <commit> retornar uma resposta com um ou mais avisos, os avisos serão redirecionados para o arquivo de log do sistema, além de serem omitidos da resposta.

  • A resposta do servidor NETCONF emite o <source-daemon> elemento como uma criança do <error-info> elemento em vez do <rpc-error> elemento.

  • Se você também configurar a flatten-commit-results declaração no nível de [edit system services netconf] hierarquia, o servidor NETCONF apenas emite um <ok/> ou <rpc-error> elemento em sua resposta e suprime qualquer <commit-results> sub-árvore XML.

A partir do Junos OS Release 23.2R1, quando você configura a rfc-compliant declaração, o servidor NETCONF emite apenas um <ok/> ou <rpc-error> elemento em resposta às <validate> operações. Em versões anteriores, a resposta do RPC também inclui o <commit-results> elemento.

Tabela de histórico de lançamento
Lançamento
Descrição
23.2R1
A partir do Junos OS Release 23.2R1, quando você configura a rfc-compliant declaração, o servidor NETCONF emite apenas um <ok/> ou <rpc-error> elemento em resposta às <validate> operações. Em versões anteriores, a resposta do RPC também inclui o <commit-results> elemento.
21.2R1
A partir do Junos OS Release 21.2R1, quando você configura a rfc-compliant declaração, a resposta do servidor NETCONF às <commit> operações é modificada.
18.4R1
A partir do Junos OS Release 17.4R3, 18.2R2, 18.3R2 e 18.4R1, quando você configura a rfc-compliant declaração, o servidor NETCONF não pode retornar uma resposta de RPC que inclua um <rpc-error> elemento e um <ok/> elemento.