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-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.
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.