Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

YANG bridge-domain membership configuration breaks cli config assumptions #28

Open
sebageek opened this issue Nov 28, 2019 · 1 comment

Comments

@sebageek
Copy link
Collaborator

YANG and the cli do seem to have different opinions on how interface members work and should be represented.

  1. It looks like YANG assumes that per interface (that is not a BD-VIF) only one service instance can be member of the bridge
  2. Interfaces are treated case-sensitive in YANG, while they are treated case-INsensitive by the cli

Assume the following device state:

QA-DE-1b-asr11-cp090#show run bridge-domain 2023
Building configuration...

Current bridge-domain configuration:
 2023 
 member Port-channel1 service-instance 4598
 member Port-channel1 service-instance 4628
 member Port-channel1 service-instance 4656
 member Port-channel1 service-instance 4670
 member Port-channel1 service-instance 4674
 member Port-channel1 service-instance 4690
 member Port-channel1 service-instance 4711
 member Port-channel1 service-instance 6345
 member BD-VIF 560
 member BD-VIF 574
[...]

Via YANG we get the following

          <member>
            <member-interface>
              <interface>Port-Channel1</interface>
              <service-instance>4711</service-instance>
            </member-interface>
            <member-interface>
              <interface>Port-channel1</interface>
              <service-instance>6345</service-instance>
            </member-interface>
            <BD-VIF>
              <name>502</name>
            </BD-VIF>
            <BD-VIF>
              <name>532</name>
            </BD-VIF>

So all other instances are no longer reachable via the YANG api.

When we now reconfigure one of the portchannels we can see that it is replaced in YANG

<bridge-domain>
<brd-id xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-bridge-domain">
<bridge-domain-id>2023</bridge-domain-id>
<member>
<member-interface>
 <interface>Port-channel1</interface>
 <service-instance>4598</service-instance>
</member-interface>
</member>
</brd-id>
</bridge-domain>

</native> </config> </edit-config> </rpc>
          <member>
            <member-interface>
              <interface>Port-Channel1</interface>
              <service-instance>4711</service-instance>
            </member-interface>
            <member-interface>
              <interface>Port-channel1</interface>
              <service-instance>4598</service-instance>
            </member-interface>

In the device log we can see that YANG just issues a command to add this service instance to the port-channel:

Nov 28 12:11:21.882: %HA_EM-6-LOG: catchall: configure terminal lock 
Nov 28 12:11:21.882: %HA_EM-6-LOG: catchall: bridge-domain 2023 
Nov 28 12:11:21.883: %HA_EM-6-LOG: catchall: member Port-channel1 service-instance 4598
Nov 28 12:11:21.884: %HA_EM-6-LOG: catchall: end 

Same goes for a replace operation, e.g.

<member-interface operation="replace">
 <interface>Port-channel1</interface>
 <service-instance>4628</service-instance>
</member-interface>

No service-instance is actually removed from the device, even when we try to replace it.

For the driver migration I need some means to manage these members:

  • we MUST see all interface members
  • we MUST have a way to delete or replace member-interface stanzas that are no longer needed
  • ideally we would have the option to replace all member-interfaces for one interface name with a new stanza.

Also, YANG does not normalize the interface name and creates one entry for each differently cased/named interface

            <member-interface>
              <interface>PoRt-ChAnNeL1</interface>
              <service-instance>4711</service-instance>
            </member-interface>
            <member-interface>
              <interface>Port-channel0x00001</interface>
              <service-instance>4598</service-instance>
            </member-interface>
            <member-interface>
              <interface>Port-channel1</interface>
              <service-instance>4628</service-instance>
            </member-interface>
@sebageek
Copy link
Collaborator Author

Tested with new image version V1612_1A_ES1. TL;DR:

  • information in yang is duplicated (service-instance-list items vs service-instance tag)
  • service-instance-list vs service-instance behave differently, two interfaces exist
  • service-instance-list tag is presented once for each instance, while each service instance should be contained in a single list
  • member interface name normalization has not been fixed.

Information in YANG is duplicated

Consider the following device configuration:

bridge-domain 9000 
 member Port-channel2 service-instance 6383

Retrieving this via YANG will result in the following XML

<rpc-reply message-id="urn:uuid:9fe3ae18-3b12-416e-8c12-32339af5c172" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
  <data>
    <native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
      <bridge-domain>
        <brd-id xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-bridge-domain">
          <bridge-domain-id>9000</bridge-domain-id>
          <member>
            <member-interface>
              <interface>Port-CHANnel2</interface>
              <service-instance-list>
                <instance-id>6383</instance-id>
              </service-instance-list>
              <service-instance>6383</service-instance>
            </member-interface>
            <member-interface>
              <interface>Port-channel2</interface>
              <service-instance-list>
                <instance-id>6383</instance-id>
              </service-instance-list>
              <service-instance>6383</service-instance>
            </member-interface>
          </member>
        </brd-id>
      </bridge-domain>
    </native>
  </data>
</rpc-reply>

The service-instance here is presentet two times. Once in <service-instance>6383</service-instance> and once in the <service-instance-list> tags. I would expect it to be only present in one place.

service-instance-list vs service-instance behave differently, two interfaces exist

There now seem be two ways to configure the same attribute:

  • When I configure <service-instance> the previous service instance gets replaced. This now behaves as there can for each port-channel only be one service instance in a bridge (which is NOT how the CLI behaves).
  • When I use <service-instance-list><instance-id>XXXX</instance-id></service-instance-list> they get added, just as the CLI does.

My questions:

  • Are these different values in the YANG database and will these collide with each other?
  • Can I build my driver with the expectation that when writing <service-instance> the instance will always be replaced? This needs to be defined behaviour for me.

service-instance-list tag is presented once for each instance, while each service instance should be contained in a single list

Consider this config on the CLI

bridge-domain 9000 
 member Port-channel2 service-instance 6379
 member Port-channel2 service-instance 6383

When querying this bridge domain it looks like this

      <bridge-domain>
        <brd-id xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-bridge-domain">
          <bridge-domain-id>9000</bridge-domain-id>
          <member>
            <member-interface>
              <interface>Port-channel2</interface>
              <service-instance-list>
                <instance-id>6379</instance-id>
              </service-instance-list>
              <service-instance-list>
                <instance-id>6383</instance-id>
              </service-instance-list>
              <service-instance>6379</service-instance>
            </member-interface>
          </member>
        </brd-id>
      </bridge-domain>

Apart from the duplication with <service-instance> I would expect that there is a single list with multiple elements, e.g. not like this

# wrong / how it is on the device
              <service-instance-list>
                <instance-id>6379</instance-id>
              </service-instance-list>
              <service-instance-list>
                <instance-id>6383</instance-id>
              </service-instance-list>

but like this

# how I would expect it to be
<service-instance-list>
  <instance-id>6379</instance-id>
  <instance-id>6383</instance-id>
</service-instance-list>

member interface name normalization has not been fixed

Interface name normalization still is something that is not happening. If Cisco is not intending to fix this please tell me so I can stop testing these things.
Consider this config on the CLI

bridge-domain 9000 
 member Port-channel2 service-instance 6379
 member Port-channel2 service-instance 6383

We now configure a Port-channel2 interface with a service-instance, but with a differently cased name:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <edit-config>
<target><running/></target>
<config>
<native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native" xmlns:ios-bgp="http://cisco.com/ns/yang/Cisco-IOS-XE-bgp">
<bridge-domain>
<brd-id xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-bridge-domain">
<bridge-domain-id>9000</bridge-domain-id>
<member>
            <member-interface>
              <interface>Port-CHANnel2</interface>
             <service-instance>6383</service-instance>
            </member-interface>
</member>
</brd-id>
</bridge-domain>
</native>
</config>
</edit-config>
</rpc>

When we now retrieve the bridge-domain we can see that in the YANG config db this is an extra entry, while on the device it stays the same.

      <bridge-domain>
        <brd-id xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-bridge-domain">
          <bridge-domain-id>9000</bridge-domain-id>
          <member>
            <member-interface>
              <interface>Port-CHANnel2</interface>
              <service-instance-list>
                <instance-id>6383</instance-id>
              </service-instance-list>
              <service-instance>6383</service-instance>
            </member-interface>
            <member-interface>
              <interface>Port-channel2</interface>
              <service-instance-list>
                <instance-id>6379</instance-id>
              </service-instance-list>
              <service-instance-list>
                <instance-id>6383</instance-id>
              </service-instance-list>
              <service-instance>6379</service-instance>
            </member-interface>
          </member>
        </brd-id>
      </bridge-domain>

The interface name should get normalized to Port-channel2 in this case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant