Относительно тегов 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>

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

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 - это прочитать его спецификации.

Я изменил строку, содержащую пространство имен, на какую-то случайную строку, такую ​​как ' 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 линия, то проблема та же. Вы попытались выполнить какую-то операцию, неизвестную серверу. Однако этот случай завершится ошибкой.