Arista netconf time-modified in tag data is invalid

smtimmerman · ‎01-21-2023

Hi all,

I'm trying to do a POC with NSO 6 and some Arista vEOS routers in my lab. When using any Netconf NED on these Arista devices I get this error in NSO:

admin@ncs# devices device spine-11 sync-from
result false
info spine-11: Attribute time-modified in tag data is invalid

I found someone else having this problem as well using netconf with ydk. The response from Arista is the following:

Hello Anderzej,

time-modified attribute isn't defined in the default namespace, so this causes confusion for some clients who looks in the default namespace to find the attribute but cannot find it.

To work around this, we should register a module namespace along the lines of "http://arista.com/yang/arista/datastore", prefix "ards" and register that in this element, e.g.,

<data xmlns:ards="http://arista.com/yang/arista/datastore" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" ards:time-modified="..."</data>

Basically this means adding this attribute to the start element, and changing the "xml:",attr"" tag for time-modified to look like, e.g., TimeModified time.Time xml:"http://arista.com/yang/arista/datastore time-modified,attr"

The XML returned from the Arista device looks like:

<?xml version="1.0"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<data time-modified="2020-07-29T20:33:36.301561073Z">
<interfaces xmlns="http://openconfig.net/yang/interfaces">
<interface>
<name>Ethernet2</name>
<config>
<description/>
<enabled>true</enabled>
<load-interval xmlns="http://arista.com/yang/openconfig/interfaces/augments">300</load-interval>
<loopback-mode>false</loopback-mode>
<mtu>0</mtu>
<name>Ethernet2</name>
<tpid xmlns="http://openconfig.net/yang/vlan" xmlns:oc-vlan-types="http://openconfig.net/yang/vlan-types">oc-vlan-types:TPID_0X8100</tpid>
<type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:ethernetCsmacd</type>
</config>
<ethernet xmlns="http://openconfig.net/yang/interfaces/ethernet">
<config>
<fec-encoding xmlns="http://arista.com/yang/openconfig/interfaces/augments">
<disabled>false</disabled>
<fire-code>false</fire-code>
<reed-solomon>false</reed-solomon>
<reed-solomon544>false</reed-solomon544>
</fec-encoding>
<forwarding-viable xmlns="http://openconfig.net/yang/hercules/interfaces">true</forwarding-viable>
<mac-address>00:00:00:00:00:00</mac-address>
<port-speed>SPEED_UNKNOWN</port-speed>
<sfp-1000base-t xmlns="http://arista.com/yang/openconfig/interfaces/augments">false</sfp-1000base-t>
</config>
<pfc xmlns="http://arista.com/yang/openconfig/interfaces/augments"/>
<switched-vlan xmlns="http://openconfig.net/yang/vlan">
<config>
<access-vlan>200</access-vlan>
<interface-mode>ACCESS</interface-mode>
</config>
</switched-vlan>
</ethernet>
<hold-time>
<config>
<down>0</down>
<up>0</up>
</config>
</hold-time>
<subinterfaces>
<subinterface>
<index>0</index>
<config>
<description/>
<enabled>true</enabled>
<index>0</index>
</config>
<ipv4 xmlns="http://openconfig.net/yang/interfaces/ip">
<config>
<dhcp-client>false</dhcp-client>
<enabled>false</enabled>
<mtu>1500</mtu>
</config>
<unnumbered>
<config>
<enabled>false</enabled>
</config>
</unnumbered>
</ipv4>
<ipv6 xmlns="http://openconfig.net/yang/interfaces/ip">
<config>
<dhcp-client>false</dhcp-client>
<enabled>false</enabled>
<mtu>1500</mtu>
</config>
</ipv6>
</subinterface>
</subinterfaces>
</interface>
</interfaces>
</data>
</rpc-reply>

How to proceed with this? Is there an option in NSO to handle this, or do I need to upload new models to the router?

Thanks a lot for any direction or answer!

davicard · ‎08-01-2023

Hello smtimmerman, how did you solve this?

smtimmerman · ‎08-02-2023

Hi @davicard, I didn't find any solution for it, can you help, or think of any?

davicard · ‎08-02-2023

My only idea now is to update the device OS from 4.25.1F to 4.29.1F which is target for customer and doesn't seem to have the "time-modified" attribute in the yang models

rogaglia · ‎08-02-2023

In NSO there is the option to create licensed NETCONF NEDs for devices with deviations to the standard (which sounds like the case as you need a proprietary attribute). You can contact your Cisco contact to discuss this option rather than using the NETCONF Builder.

rogaglia · ‎08-02-2023

I would say that in any case, this looks like a bug in Arista (as recognized in their answer to the referred post) so my first action course would be to check if them if/when it was fixed.

davicard · ‎08-02-2023

The attribute is defined in a particular yang model, but it's augmenting:

augment "/nc:get-config/nc:output"

and it seems NSO is expecting a "clean" output without the time-modified attribute

smtimmerman · ‎08-02-2023

I've tried two versions, 4.29.1F and 4.30.1F they made a change in 4.30.1F where the time-modified attribute is now namespaced, see the responses below:

vEOS 4.29.1F

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:f1fe8d54-8c23-43fd-908f-97b9b054470b">
  <data time-modified="2023-07-04T08:07:49.945376825Z">
    <lldp xmlns=http://openconfig.net/yang/lldp>
      <config>
        <system-description>Arista Networks EOS version 4.29.1F running on an Arista vEOS-lab</system-description>
      </config>
    </lldp>
  </data>
</rpc-reply>

vEOS 4.30.1F

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:ea82040e-5936-4ab6-9150-3b5403ac98dd">
  <data xmlns:netconf=http://arista.com/yang/rpc/netconf netconf:time-modified="2023-07-04T08:07:52.227291666Z">
    <lldp xmlns=http://openconfig.net/yang/lldp>
      <config>
        <system-description>Arista Networks EOS version 4.30.1F running on an Arista vEOS-lab</system-description>
      </config>
    </lldp>
  </data>
</rpc-reply>

But I have no idea how to make this work with NSO. Do you think compiling the NETCONF NED again based on the vEOS 4.30.1F models is going to make a difference?

Is there another way to instruct NSO to ignore the attribute, maybe there is a way to loosen the validation or ignore certain attributes etc?

rogaglia · ‎08-03-2023

Hi,

I just checked the YANG model that Arista publishes here: https://github.com/aristanetworks/yang/blob/master/EOS-4.30.1F/experimental/eos/models/rpc/arista-rpc-netconf.yang

This is progress as at least they are documenting what they are doing and not just breaking the standard. So, one thing is that a vendor modifies the configuration with vendor-specific extensions and native YANG models. That all clients (like NSO does) should be able to adapt. In this case, what Arista is doing is modifying the IETF base NETCONF RPCs and therefore, although allowed, you cannot assume that all clients will support your proprietary extension (because breaks the basic on why we have standards).

I believe you have three options:

1- Check with Arista if there is a configuration option in their device where this extension is disabled.

2- As mentioned, talk to your Cisco/Partner rep as NSO can craft a special NED that includes this specific Arista extension (not part of NETCONF standard based NED-Builder). This would be a Generic NED which development is documented but typically customers prefer that our team take care of it: https://developer.cisco.com/docs/nso/guides/#!network-element-drivers-neds/generic-ned

3- Go back to Arista CLI NED that is already available (arista-eos).

Roque

Extension definition in Arista YANG models.

extension time-modified {
    description
      "This extension defines an annotation of modification timestamps for
      NETCONF RPC outputs.  When the extension is applied to an RPC's output
      schema node, the data container in the output tree of that RPC is
      annotated with the timestamp of the latest date and time when a value in
      the output tree was modified.  The timestamp is encoded as an attribute
      named 'time-modified' with a value in RFC 3339 format.

      Example:

        <rpc-reply xmlns='urn:ietf:params:xml:ns:netconf:base:1.0' message-id='101'>
          <data xmlns:arnc='http://arista.com/yang/rpc/netconf'
                arnc:time-modified='2006-01-02T15:04:05.999999999Z'>
      ";
  }

  augment "/nc:get-config/nc:output" {
    description
      "Adds time-modified annotation to get-config data.";
    arista-rpc-netconf:time-modified;
  }
}

smtimmerman · ‎08-03-2023

Hi Roque, thanks for the elaborate answer!

About the options you presented, I have explored those but I don't have any leverage as this is not a big project, I was trying to show NSO (which I know from my previous employer) to colleagues and wanted to work with it in my lab in my own time.

I did that, my ticket with them caused the change in 4.30.1F, unfortunately for me that wasn't enough to get it working out of the box. I also hoped for a switch. I was already happy with the response since there's no commercial deal behind this for them, so I don't see them make another change there.
I currently don't have any contacts with Cisco about this since it's not an official project or PoC that warrants them spending time on it.
I would love to use the Arista CLI NED in my lab, but I don't have it (also can't find it being used in any demo environments or sandboxes where I could 'borrow' it from), which is the only reason I went for the NETCONF approach hoping that the open models etc would work.

Kind regards,
Sander.

davicard · ‎08-03-2023

I can't find the "time-modified" augment in 4.29.1F: https://github.com/aristanetworks/yang/blob/master/EOS-4.29.1F/experimental/eos/models/rpc/arista-rpc-netconf.yang

But as per Sander, it seems it's still there. Anyway I'll update the device in the lab and re generate the NED to see how it goes.

smtimmerman · ‎08-28-2023

@rogagliafor argument's sake, RFC7952 describes the yang metadata usage, how/why does the "time-modified" attribute not fit in there making it compliant?

ndmitri · ‎04-27-2024

Hi all! The same problem with vEOS 4.31.2F as well. Does anyone have a working solution for this issue? Thank you.

cohult · ‎04-29-2024

Hi @ndmitri, I hear there is work planned to allow attributes in the data tag to address this issue. No timetable yet. Note that issues not related to NSO could surface once the data tag attribute has been addressed. So I believe your fastest way forward right now is what @rogaglia recommended:

... talk to your Cisco/Partner rep as NSO can craft a special NED that includes this specific Arista extension (not part of NETCONF standard based NED-Builder). This would be a Generic NED which development is documented but typically customers prefer that our team take care of it: https://developer.cisco.com/docs/nso/guides/#!network-element-drivers-neds/generic-ned