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:
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
...
</capabilities>
<session-id>27700</session-id>
<hello>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/15.1R1/junos">
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.
<nc:hello xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<nc:capabilities>
<nc:capability>urn:ietf:params:netconf:base:1.0</nc:capability>
...
</nc:capabilities>
<nc:session-id>27703</nc:session-id>
</nc:hello>
A saída a seguir mostra uma resposta de RPC amostral quando a rfc-compliant declaração está configurada:
<nc:rpc-reply
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:junos="http://xml.juniper.net/junos/15.1R1/junos">
<nc:data>
<configuration xmlns="http://xml.juniper.net/xnm/1.1/xnm"
junos:changed-seconds="1417554471"
junos:changed-localtime="2014-12-02 13:07:51 PST">
<!--configuration data-->
</configuration>
<database-status-information>
<database-status>
<user>root</user>
<terminal></terminal>
<pid>47868</pid>
<start-time junos:seconds="1417560303">2014-12-02 14:45:03 PST</start-time>
<edit-path></edit-path>
</database-status>
</database-status-information>
</nc:data>
</nc:rpc-reply>
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.
<rpc>
<get-config>
<source>
<running/>
</source>
</get-config>
</rpc>
]]>]]>
<nc:rpc-reply
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:junos="http://xml.juniper.net/junos/17.2R1/junos">
<nc:data>
<configuration
xmlns="http://yang.juniper.net/yang/1.1/jc/configuration/junos/17.2R1.13"
junos:commit-seconds="1493761452"
junos:commit-localtime="2017-05-02 14:44:12 PDT"
junos:commit-user="user">
...
</configuration>
</nc:data>
</nc:rpc-reply>
]]>]]>
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.
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/15.1D0/junos"> <data> <configuration> </configuration> </data> </rpc-reply>
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.
<nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/15.1R1/junos"> <nc:data> </nc:data> </nc:rpc-reply>
< 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:
<nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/17.4R1/junos">
<nc:rpc-error>
<nc:error-severity>warning</nc:error-severity>
<nc:error-message>
uid changed for jadmin (2001->2014)
</nc:error-message>
</nc:rpc-error>
<nc:ok/>
</nc:rpc-reply>
]]>]]>
Se você configurar a rfc-compliant declaração, o aviso será omitido.
<nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/18.4R1/junos"> <nc:ok/> </nc:rpc-reply> ]]>]]>
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-resultsdeclaraçã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.
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.
rfc-compliant declaração, a resposta do servidor NETCONF às
<commit> operações é modificada.
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.