Interface AdminStatus missing in ygot log output failing verification

[trathod1]

In aggregate_test.go, during verifyInterfaceDUT call, the AdminStatus verification fails. The LogYgot output does not show any data for admin-status or the oper-status, however the manual gnmic query shows proper output ("UP" for interface admin-status) from SRL device.

AdminStatus reported by the script is 0 - aggregate_test.go:360: dut:port2(MVSRLHW15-DUT2:ethernet-1/2) admin-status got out-of-range E_Interface_AdminStatus enum value: 0, want UP

It seems based on below Ygot log output, where admin-status is missing, the above GetAdminStatus call is returning it as unset (value 0, based on enum.go) - Interface_AdminStatus_UNSET E_Interface_AdminStatus = 0

Ygot output have state which is missing admin-status - "openconfig-interfaces:name": "ethernet-1/2", "openconfig-interfaces:state": { "counters": { "carrier-transitions": "0", "in-broadcast-pkts": "1", "in-errors": "0", "in-fcs-errors": "0", "in-multicast-pkts": "8", "in-octets": "850", "in-unicast-pkts": "1", "out-broadcast-pkts": "5", "out-discards": "0", "out-errors": "0", "out-multicast-pkts": "18", "out-octets": "3568", "out-unicast-pkts": "3" }, "description": "dut:port2(MVSRLHW15-DUT2:ethernet-1/2)",

gnmic manual query output which shows the proper admin-status - "state": { "admin-status": "UP", "counters": { "carrier-transitions": "0", "in-broadcast-pkts": "1", "in-errors": "0", "in-fcs-errors": "0", "in-multicast-pkts": "8", "in-octets": "850", "in-unicast-pkts": "1", "out-broadcast-pkts": "5", "out-discards": "0", "out-errors": "0", "out-multicast-pkts": "18", "out-octets": "3568", "out-unicast-pkts": "3" }, "description": "dut:port2(MVSRLHW15-DUT2:ethernet-1/2)",

Can you please help investigate, what could be going wrong here or if I am missing something ?

[wenovus]

This would be strange if gnmic is seeing the admin-status while ondatra is not. I would first see whether ondatra is receiving these messages at all. You can put some log markers around the particular telemetry call that's receiving the interface stats, and then run the test with go test -args -alsologtostderr -v=2 and look for log messages that begin with Received gNMI Update value. These log messages are defined in ondatra/internal/gnmigen/genutil/genutil.go

[trathod1]

I executed the test with the mentioned options, and I collect following Type Noncompliance errors during unmarshalling for admin-status and oper-status -

Type Noncompliance Errors: Unmarshal bool_val:true into elem:{name:"interfaces"} elem:{name:"interface" key:{key:"name" value:"ethernet-1/2"}}: rpc error: code = Unknown desc = path points to a node with non-leaf schema &{0xc000891e00 interface [] [] Directory unset 0xc000882d70 unset map[aggregation:0xc0008c6180 config:0xc0008ca300 ethernet:0xc0008cb680 hold-time:0xc00090b200 name:0xc00090bc80 routed-vlan:0xc00090be00 state:0xc000960f00 subinterfaces:0xc00099c000] name [] 0xc000a03980 [] [] [0xc000a26480 0xc000a26780 0xc000a26a80] [] map[] {false false} [] map[] map[schemapath:/openconfig-interfaces/interfaces/interface structname:Interface] } Unmarshal int_val:0 into elem:{name:"interfaces"} elem:{name:"interface" key:{key:"name" value:"ethernet-1/2"}} elem:{name:"state"} elem:{name:"admin-status"}: rpc error: code = Unknown desc = failed to update struct field AdminStatus in telemetry.Interface with value int_val:0; failed to unmarshal &{0} into enumeration Unmarshal int_val:1 into elem:{name:"interfaces"} elem:{name:"interface" key:{key:"name" value:"ethernet-1/2"}} elem:{name:"state"} elem:{name:"oper-status"}: rpc error: code = Unknown desc = failed to update struct field OperStatus in telemetry.Interface with value int_val:1; failed to unmarshal &{1} into enumeration Value Restriction Noncompliance Errors: None

The log response for admin-status and oper-status query are like -

`I0818 13:35:51.600862 24979 genutil.go:976] Received gNMI Update value int_val: 0 at path: elem: { name: "interfaces" } elem: { name: "interface" key: { key: "name" value: "ethernet-1/2" } } elem: { name: "state" } elem: { name: "admin-status" } I0818 13:35:51.600874 24979 genutil.go:981] Constructed datapoint for update: Value: int_val: 0

Timestamp: 2022-08-18 13:35:39.007718348 -0700 PDT RecvTimestamp: 2022-08-18 13:35:51.600443257 -0700 PDT m=+349.641492924 Path: elem: { name: "interfaces" } elem: { name: "interface" key: { key: "name" value: "ethernet-1/2" } } elem: { name: "state" } elem: { name: "admin-status" } I0818 13:35:51.600907 24979 genutil.go:976] Received gNMI Update value int_val: 1 at path: elem: { name: "interfaces" } elem: { name: "interface" key: { key: "name" value: "ethernet-1/2" } } elem: { name: "state" } elem: { name: "oper-status" } I0818 13:35:51.600918 24979 genutil.go:981] Constructed datapoint for update: Value: int_val: 1

Timestamp: 2022-08-18 13:35:39.007718348 -0700 PDT RecvTimestamp: 2022-08-18 13:35:51.600443257 -0700 PDT m=+349.641492924 Path: elem: { name: "interfaces" } elem: { name: "interface" key: { key: "name" value: "ethernet-1/2" } } elem: { name: "state" } elem: { name: "oper-status" }`

[wenovus]

Thanks, it looks like there is a vendor compliance issue, per the gNMI spec enumerations should be represented as a string: https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md#223-node-values, this is consistent with the RFC7951 JSON representation of enumerations.

My guess is gnmic tolerates integer values for enums during unmarshalling, so that's why you're seeing the difference.

[trathod1]

Thanks with the investigation, this is very helpful to narrow it down. I will take it up with the vendor.