关于netconf xml文件的yang模型

时间:2016-10-05 15:17:54

标签: ietf-netmod-yang

队 我有以下xml文件:

<?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:这个netconf xml文件是否有阳模型?

Q2:如何访问此xml文件的底层阳模型(文件)?

1 个答案:

答案 0 :(得分:4)

  

Q1:这个netconf xml文件是否有阳模型?

您可以轻松确定设备是否使用YANG来根据其<hello>消息对其内容进行建模。兼容设备通告他们支持的YANG模块。对于YANG 1和YANG 1.1,广告的功能会有所不同。

对于YANG 1(RFC6020),这是规范所说的(5.6.4.1):

  
    

服务器通过<hello>指示支持的模块的名称        信息。模块名称空间被编码为基本URI        功能字符串,模块名称编码为&#34;模块&#34;        基URI的参数。

         

服务器必须公布它实现的所有模块的所有修订版。

         

例如,此<hello>消息通告一个模块&#34; syslog&#34;。

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <capability>
   http://example.com/syslog?module=syslog&amp;revision=2008-04-01
 </capability>
</hello>
  

对于YANG 1.1(RFC7950),在5.6.4中:

  
    

NETCONF服务器必须宣布它实现的模块(参见        第5.6.5节)通过实施YANG模块&#34; ietf-yang-library&#34;        在[RFC7895]中定义并列出了所有已实现的模块        &#34; /模块状态/模块&#34;列表。

         

服务器还必须在广告中宣传以下功能        <hello>消息(换行符和空格用于格式化        原因):

urn:ietf:params:netconf:capability:yang-library:1.0?
   revision=<date>&module-set-id=<id>
         

参数&#34; revision&#34;具有与修订日期相同的值        &#34; ietf-yang-library&#34;由服务器实现的模块。这个        参数必须存在。

         

参数&#34; module-set-id&#34;与叶子具有相同的价值        &#34; /模块状态/模块设置ID&#34;来自&#34; ietf-yang-library&#34;。这个        参数必须存在。

         

通过这种机制,客户端可以缓存支持的模块       服务器,只有&#34; module-set-id&#34;才更新缓存。价值在       <hello>消息更改。

  

似乎找不到停止上述blockquote的方法,因此

  

Q2:如何访问此xml文件的底层阳模型(文件)?

设备制造商通常会在其网站上提供下载页面,您可以在其中获取其YANG文件。请注意,并非所有设备都支持YANG。 NETCONF没有specify建模的内容;可能是一堆XSD架构,YANG,RelaxNG等,虽然YANG的设计考虑到了这个目的(最初)。

还定义了一个名为<get-schema>的可选标准操作,它是ietf-netconf-monitoring YANG模块的一部分。您首先发现可用的架构,然后获取它们。由于它是可选的,并非所有设备都支持它。

<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
  <get>
    <filter type="subtree">
      <ncm:netconf-state xmlns:ncm="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
        <ncm:schemas/>
      </ncm:netconf-state>
    </filter>
  </get>
</rpc>

<?xml version="1.0" encoding="utf-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
  <data>
    <netconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
      <schemas>
        <schema>
          <identifier>ietf-inet-types</identifier>
          <version>2013-07-15</version>
          <format>yang</format>
          <namespace>urn:ietf:params:xml:ns:yang:ietf-inet-types</namespace>
          <location>NETCONF</location>
        </schema>
        <!-- ... -->
      </schemas>
    </netconf-state>
  </data>
</rpc-reply>

<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="8">
  <get-schema xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
    <identifier>ietf-interfaces</identifier>
    <version>2014-05-08</version>
    <format>yang</format>
  </get-schema>
</rpc>

<?xml version="1.0" encoding="utf-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="8">
  <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">module ietf-interfaces {

  namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces";
  prefix if;

  // ...
  }
  </data>
</rpc-reply>