OpenConfig YANG

This chapter contains the following topics:

About OpenConfig YANG

OpenConfig YANG supports modern networking principles, such as declarative configuration and model-driven management and operations. OpenConfig provides vendor-neutral data models for configuration and monitoring of the network, as well as helping with moving from a pull model to a push model, with subscriptions and event update streaming.

The switch supports a broad range of functional areas, including BGP, OSPF, Interface L2 and L3, VRFs, VLANs, and TACACS.

For more information about OpenConfig YANG, see About OpenConfig YANG.

For the OpenConfig models, see YANG Models. OpenConfig YANG models are grouped by Cisco NX-OS releases, so when the Cisco NX-OS release number changes, the last digits in the URL change.

Guidelines and Limitations for OpenConfig YANG

OpenConfig YANG has the following guidelines and limitations:

  • The following OpenConfig YANG limitations exist for OC-BGP-POLICY:

    • Action type is always permit for community-set and as-path-set, which applies to the following containers:

      • /bgp-defined-sets/community-sets/community-set/

      • /bgp-defined-sets/as-path-sets/as-path-set/

      In OpenConfig YANG, there is no action type concept as there is in the CLI for community-set and as-path-set. Therefore, the action type is always permit for community-set and as-path-set.

    • The following OpenConfig YANG limitation applies to this container: /bgp-defined-sets/community-sets/community-set/

      In the CLI, community-list can have two different types: standard and expanded. However, in the OpenConfig YANG model, community-set-name has no such differentiation.

      When you create the community-set-name through OpenConfig YANG, the following things happen internally:

      • The _std suffix is appended after community-set-name if community-member is in the standard form (AS:NN).

      • The _exp suffix is appended after community-set-name if community-member is in the expanded form (regex): 

        <community-set>
    <community-set-name>oc_commset1d</community-set-name>
    <config>
        <community-set-name>oc_commset1d</community-set-name>
        <community-member>0:1</community-member>
        <community-member>_1_</community-member>
    </config>
</community-set>

        The preceding OpenConfig YANG configuration is mapped to the following CLI:

        ip community-list expanded oc_commset1d_exp seq 5 permit "_1_"
ip community-list standard oc_commset1d_std seq 5 permit 0:1

    • The following OpenConfig YANG limitation applies to this container: /bgp-conditions/match-community-set/config/community-set/

      OpenConfig YANG can only map to one community-set, while the CLI can match to multiple instances of the community-set:

      • In the CLI:

        ip community-list standard 1-1 seq 1 permit 1:1 
  ip community-list standard 1-2 seq 1 permit 1:2
  ip community-list standard 1-3 seq 1 permit 1:3
route-map To_LC permit 10
  match community 1-1 1-2 1-3

      • The corresponding OpenConfig YANG payload follows:

        <config>
  <routing-policy xmlns="http://openconfig.net/yang/routing-policy">
    <defined-sets>
      <bgp-defined-sets xmlns="http://openconfig.net/yang/bgp-policy">
        <community-sets>
          <community-set>
            <community-set-name>cs</community-set-name>
            <config>
              <community-set-name>cs</community-set-name>
              <community-member>1:1</community-member>
              <community-member>1:2</community-member>
              <community-member>1:3</community-member>
            </config>
          </community-set>
        </community-sets>
      </bgp-defined-sets>
    </defined-sets>
    <policy-definitions>
      <policy-definition>
        <name>To_LC</name>
        <statements>
          <statement>
            <name>10</name>
            <conditions>
              <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
                <match-community-set>
                  <config>
                    <community-set>cs</community-set>
                  </config>
                </match-community-set>
              </bgp-conditions>
            </conditions>
          </statement>
        </statements>
      </policy-definition>
    </policy-definitions>
  </routing-policy>
</config>

      As a workaround, create one community with multiple statements through OpenConfig YANG:

      ip community-list standard cs_std seq 5 permit 1:1 
  ip community-list standard cs_std seq 10 permit 1:2
  ip community-list standard cs_std seq 15 permit 1:3
route-map To_LC permit 10
  match community cs_std

    • The following OpenConfig YANG limitation applies to this container: /bgp-conditions/state/next-hop-in

      In OpenConfig YANG, the next-hop-in type is an IP address, but in the CLI, it is an IP prefix.

      While creating the next-hop-in through OpenConfig YANG, the IP address is converted to a "/32" mask prefix in the CLI configuration. For example:

      • Following is an example of next-hop-in in the OpenConfig YANG payload: 

        <policy-definition>
    <name>sc0</name>
    <statements>
        <statement>
            <name>5</name>
            <conditions>
                <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
                    <config>
                        <next-hop-in>2.3.4.5</next-hop-in>
                    </config>
                </bgp-conditions>
            </conditions>
        </statement>
    </statements>
</policy-definition>

      • Following is an example of the same information in the CLI:

        ip prefix-list IPV4_PFX_LIST_OPENCONFIG_sc0_5 seq 5 permit 2.3.4.5/32
route-map sc0 permit 5
  match ip next-hop prefix-list IPV4_PFX_LIST_OPENCONFIG_sc0_5

  • The following NX-OS limitations exist for OC-BGP-POLICY:

    • /bgp-actions/set-community/config/method enum "REFERENCE" is not supported.

    • enum "SELF", which is supported in the OpenConfig YANG model for /bgp-actions/config/set-next-hop, is not supported.

  • For OC-BGP-POLICY, /bgp-conditions/match-community-set/config/community-set get mapped only to match community <community-set>_std, so only standard community is supported. Match to expanded community set is not supported.

  • There is a limitation in replacing match-tag-set because defined sets for tag-sets are not currently implemented.

    Currently, replacing match-tag-set appends the values. To replace match-tag-set, delete it, then create it again.

  • The following guidelines and limitations apply to OSPF OpenConfig YANG:

    • If you configure and remove an area configuration in OSPF, the deleted areas (stale entries) are still shown in DME. Those stale area entries are shown in the GETCONFIG/GET output in OpenConfig YANG.

    • Only one area is supported in OpenConfig YANG in the OSPF policy match ospf-area configuration. In the CLI, you can configure to match multiple areas, such as match ospf-area 100 101. However, in OpenConfig YANG, you can configure only one area (for example, match ospf-area 100).

    • The area virtual-link and area interface configurations payload cannot go under the same area list. Split the area container payload as Virtual link area and interface area in the same payload.

    • The MD5 authentication string cannot be configured in OSPF OpenConfig YANG.

      In the OSPF model, Authentication-type is defined for the Authentication: 

      leaf authentication-type {
  type string;
  description
    "The type of authentication that should be used on this
    interface";
}

      OSPF OpenConfig YANG does not support an option for authentication password.

    • The OSPF area authentication configuration is not supported. For example, area 0.0.0.200 authentication message-digest cannot be configured from OpenConfig YANG.

    • The OSPF/BGP instance configuration that falls under default VRF (for example, router ospf 1/router bgp 1) will not get deleted when you delete the Protocols container with the default network instance.

  • The following are guidelines and limitations for VLAN configuration between the OpenConfig payload and the Cisco Nexus 3400-S interfaces:

    • When you attempt to simultaneously configure a trunk-mode interface and trunk VLANs in the same OpenConfig payload, the configuration does not complete successfully. However, when you split the payload so that the trunk-mode interface is sent first, then the trunk VLANs are sent, the configuration completes successfully.

      On Cisco NX-OS interfaces the default interface mode is access . To implement any trunk-related configurations, you must first change the interface mode to trunk , then configure the trunk VLAN ranges. Do these configurations in separate payloads.

      The following examples show the separate payloads for the configuring trunk mode and VLAN ranges.

      Example 1, payload configuring the interface to trunk mode.

      <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
  <edit-config>
    <target>
      <running/>
    </target>
    <config>
      <interfaces xmlns="http://openconfig.net/yang/interfaces">
        <interface>
          <name>eth1/47</name>
          <subinterfaces>
            <subinterface>
              <index>0</index>
              <config>
                <index>0</index>
              </config>
            </subinterface>
          </subinterfaces>
          <ethernet xmlns="http://openconfig.net/yang/interfaces/ethernet">
            <switched-vlan xmlns="http://openconfig.net/yang/vlan">
              <config>
                <interface-mode>TRUNK</interface-mode>
              </config>
            </switched-vlan>
          </ethernet>
        </interface>
      </interfaces>
    </config>
  </edit-config>
</rpc>
      Example 2, payload configuring the VLAN ranges.
      <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
  <edit-config>
    <target>
      <running/>
    </target>
    <config>
      <interfaces xmlns="http://openconfig.net/yang/interfaces">
        <interface>
          <name>eth1/47</name>
          <subinterfaces>
            <subinterface>
              <index>0</index>
              <config>
                <index>0</index>
              </config>
            </subinterface>
          </subinterfaces>
          <ethernet xmlns="http://openconfig.net/yang/interfaces/ethernet">
            <switched-vlan xmlns="http://openconfig.net/yang/vlan">
              <config>
                <native-vlan>999</native-vlan>
                <trunk-vlans xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="delete">1..4094</trunk-vlans>
                <trunk-vlans>401</trunk-vlans>
                <trunk-vlans>999</trunk-vlans>
              </config>
            </switched-vlan>
          </ethernet>
        </interface>
      </interfaces>
    </config>
  </edit-config>
</rpc>

    • Because of the design of OpenConfig YANG, when you configure VLANs, there must be no overlap between the VLANs in the payload and the VLANs already configured on an interface. If an overlap exists, the configuration through OpenConfig is not successful. Make sure that the VLANs configured on an interface are different from the VLANs in the OpenConfig payload. Pay particular attention to the starting and ending VLANs in a range.

Understanding Deletion of BGP Routing Instance

With OpenConfig YANG network-instance (OCNI), when attempting to delete only the BGP configuration of the default VRF instead of deleting the entire BGP routing instance, BGP information might not be deleted at the protocols/BGP level. In this situation, when the delete is at the protocols or BGP level with the autonomous system number in the payload, only the configuration of the default VRF is deleted instead of removing the entire BGP routing instance.

Following is an example payload that would be used to delete the configuration under the default VRF in BGP.

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
  <edit-config>
    <target>
      <running/>
    </target>
    <config>
      <network-instances xmlns="http://openconfig.net/yang/network-instance">
        <network-instance>
          <name>default</name>
          <protocols>
            <protocol>
              <identifier>BGP</identifier>
              <name>bgp</name>
              <bgp xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="delete">
                <global>
                  <config>
                    <as>100</as>
                  </config>
                </global>
              </bgp>
            </protocol>
          </protocols>
        </network-instance>
      </network-instances>
    </config>
  </edit-config>
</rpc>

Expected Behavior: The BGP routing instance itself should be deleted, which is the equivalent to no router bgp 100 .

Actual Behavior: Only the BGP configuration under the default VRF is deleted. No equivalent single CLI configuration exists.

Following is the running configuration before the delete operation:

router bgp 100
  router-id 1.2.3.4
  address-family ipv4 unicast
  vrf abc
    address-family ipv4 unicast
      maximum-paths 2

And following is the running configuration after the delete operation:

router bgp 100
  vrf abc
    address-family ipv4 unicast
      maximum-paths 2