Что касается NETCONF теги

Question

От одного из докторов, у меня есть ниже:

<?xml version="1.0" encoding="utf-8"?> 
<rpc message-id="${TIMESTAMP}" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
    <get-config> 
    <source> 
    <running></running> 
    </source> 
    <filter> 
    <interface-configurations xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ifmgr-cfg"/> 

    </filter> 
    </get-config> 
</rpc> 

Это фактически извлекает конфигурацию интерфейса из запущенной конфигурации и работает OK

Q1: Как изменить то же самое для получения статистики интерфейса? Какие теги нужно использовать? Как я узнаю?

Q2: Я изменил строку, содержащую пространство имен, на некоторую случайную строку, например 'http://a.b.c.d/check', и это не удалось. Зачем?

Answer 1

Как отредактировать то же самое для получения статистики интерфейса? Какие теги нужно использовать? Как я узнаю?

В вашем примере используется стандартная операция <get-config>, которая извлекает конфигурацию, а не рабочее состояние. Если вы хотите получить последнее, вам необходимо использовать <get/>, который извлекает данные конфигурации и состояния.

<?xml version="1.0" encoding="utf-8"?> 
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="${TIMESTAMP}"> 
    <get> 
    <filter> 
     <interface-configurations xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ifmgr-cfg"/> 
    </filter> 
    </get> 
</rpc> 

Там нет <source> параметра для этого, так как он всегда получает запуск конфигурации плюс рабочее состояние. Самый простой способ познакомиться с NETCONF - это прочитать его specification.

Я изменил строку, содержащую пространство имен, на некоторую случайную строку, такую ​​как 'http://a.b.c.d/check', и она не удалась. Зачем?

Если «несостоявшийся» означает, что вы получили <rpc-error>, это было бы нестандартным поведением. Вы должны получить пустой ответ <data/>, так как нет узлов, соответствующих вашему фильтру. Фильтр требует точного соответствия.

<?xml version="1.0" encoding="utf-8"?> 
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="163"> 
    <data/> 
</rpc-reply> 

NETCONF датасторы в значительной степени зависят от пространства имен, так как это решает наиболее общие проблемы именования. Например, если у вас есть два модуля и они содержат элементы верхнего уровня, которые называются «my-config», у вас не будет проблемы, потому что они однозначно идентифицируются пространствами имен модулей: {uri:a}my-config и {uri:b}my-config.

В вашем примере вы запросили {http://a.b.c.d/check}interface-configurations, которого просто не существует. Не имеет значения, что часть interface-configuration соответствует (местное имя), поскольку вы запросили конкретное interface-configuration из определенного пространства имен.

Пространства имен (типа), такие как домашние адреса. Там может быть множество Джона Смита, но вы можете обратиться к конкретному, указав его полный адрес. Если вы попросите свой местный пост отправить пакет только под именем «Джон Смит» без адреса, сообщение не имеет понятия, какой из них вы имели в виду.

Примечание: если вы имели в виду, что вы изменили линию urn:ietf:params:xml:ns:netconf:base:1.0, тогда проблема будет такой же. Вы попытались выполнить некоторую операцию, неизвестную серверу. Однако этот случай завершился с ошибкой.