Относительно тегов netconf

Из одного из документов у меня есть следующее:

<?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', и это не удалось. Почему?


person fsociety    schedule 05.10.2016    source источник


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

person predi    schedule 06.10.2016
comment
спасибо за подробный ответ ... также нужно подтвердить, что какие бы теги netconf (как показано выше в форме xml) мы не писали, существует соответствующая базовая модель yang для того же? Эта модель yang используется для проверки xml-файла netconf. Это правильное понимание? Если да, то как я могу получить соответствующую модель Ян для вышеуказанного xml? - person fsociety; 06.10.2016
comment
YANG используется для моделирования содержимого, которое отправляется между сервером и клиентом. Вы можете представить это как контракт между одноранговыми узлами, который гарантирует отсутствие неожиданностей во время связи, таких как неизвестные элементы, текстовые значения и т. д. Он касается только четвертый уровень протокола, уровень контента. Вам нужно будет проконсультироваться с производителем соответствующего устройства, чтобы получить соответствующую модель YANG. Некоторые устройства поддерживают необязательную операцию <get-schema> (модуль ietf-netconf-monitoring), позволяющую получать файлы YANG. - person predi; 06.10.2016
comment
*четвертый и третий слой, а не только первый. - person predi; 06.10.2016
comment
попробовал операцию ‹get›, однако я по-прежнему получаю только данные конфигурации... нет ничего похожего на данные состояния (которые, как я предполагаю, будут чем-то вроде статистики интерфейса сортировки, очереди ввода/вывода и т. д.) - person fsociety; 06.10.2016
comment
Это может просто означать, что конкретная ветка, которую вы выбираете, не имеет определенных узлов состояния. Попробуйте вообще удалить фильтр - это даст вам все на устройстве. - person predi; 06.10.2016
comment
Пробовал и получил ‹?xml version=1.0?› ‹rpc-reply message-id=1475748932 xmlns=urn:ietf:params:xml:ns:netconf:base:1.0› ‹rpc-error› ‹error-type›application‹ /error-type› ‹error-tag›operation-not-supported‹/error-tag› ‹error-severity›error‹/error-severity› ‹error-message xml:lang=en›get операция без фильтра не поддерживается с помощью этой реализации. ‹/error-message› ‹/rpc-error› ‹/rpc-reply› Вот о чем я спрашиваю… как узнать, когда передавать параметры, а когда нет… когда именно в какое пространство имен. .например, как новичок узнает точное пространство имен - person fsociety; 06.10.2016
comment
Мне жаль это говорить, но ваше устройство является одним из старых устройств Cisco, которые далеки от совместимости с NETCONF. Я сталкивался с ними раньше, и вы мало что можете с ними сделать - насколько это касается NETCONF. Проверьте, можете ли вы обновить прошивку. - person predi; 06.10.2016