pygnmi/pygnmic no longer working with Cisco IOS-XR 7.10.2 unified-model

[andyjsharp]

Since installing IOS-XR 7.10.2 we noticed that only openconfig get's were working, but any gets to Cisco unified-model failed. Not an option to downgrade the devices for obvious reasons. No problem with gnmic getting the data for the same prefix/path., and the RPCs worked just fine prior to upgrading to 7.10.2 for both openconfig and unified-model..

`pygnmicli -t x.x.x.x:57344 -u xxxx -p 'xxxxxx' -x "/Cisco-IOS-XR-infra-xtc-agent-oper:pcc/peers/peer" -o get -e json_ietf -i

Collecting Capabilities... Collection of Capabilities is successfull Selected encoding 'json_ietf' based on capabilities Collecting Capabilities... Collection of Capabilities is successfull Doing get request to ('x.x.x.x', 57344)... Collecting info from requested paths (Get operation)... GRPC ERROR Host: x.x.x.x:57344, Error: gNMI: invalid YangGetGnmi: rpc error: code = Internal desc = prefix and path origins do not match Traceback (most recent call last): File "/usr/local/lib/python3.10/dist-packages/pygnmi/client.py", line 454, in get gnmi_message_response = self.stub.Get(gnmi_message_request, metadata=self.metadata) File "/usr/local/lib/python3.10/dist-packages/grpc/_channel.py", line 1160, in call return _end_unary_response_blocking(state, call, False, None) File "/usr/local/lib/python3.10/dist-packages/grpc/_channel.py", line 1003, in _end_unary_response_blocking raise _InactiveRpcError(state) # pytype: disable=not-instantiable grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with: status = StatusCode.INVALID_ARGUMENT details = "gNMI: invalid YangGetGnmi: rpc error: code = Internal desc = prefix and path origins do not match" debug_error_string = "UNKNOWN:Error received from peer {grpc_message:"gNMI: invalid YangGetGnmi: rpc error: code = Internal desc = prefix and path origins do not match", grpc_status:3, created_time:"2024-02-21T17:49:40.284732923+00:00"}"`

[akarneliuk]

Hey @andyjsharp , There is a hint in the error message that prefix and path origins do not match. Could you please run in the debug mode to see what's getting sent/received .

[rao-aneesh]

Hi @andyjsharp

This seems to be an XR bug from 7.10.2. The workaround for this currently is to pass the prefix param as the model name. I couldn't find the equivalent pygnmicli command, hence pasting python code.

This fails:

result = gc.get(
    path=[
        "Cisco-IOS-XR-infra-xtc-agent-oper:pcc/peers/peer"
    ],
    datatype="all"
)

This passes:

result = gc.get(
    prefix="Cisco-IOS-XR-infra-xtc-agent-oper://",
    path=[
        "Cisco-IOS-XR-infra-xtc-agent-oper:pcc/peers/peer"
    ],
    datatype="all"
)

[andyjsharp]

Yes, I can confirm that a prefix is now needed. Apparently, these changes were introduced so-as to comply with OC/gNMI spec for default origin of "openconfig". As I understand it, Cisco had communicated that this change was coming 6 months ago, so I don't think that they are looking at this as a bug, more like a feature...

It appears that standard openconfig paths are just fine without the need to include a prefix, but for any of the Cisco YANG paths then a prefix is required. The prefix I was given to use that appears to be working is "cisco_native:" e.g.

result = gc.get(
    prefix="cisco_native:",
    path=[
        "Cisco-IOS-XR-wdsysmon-fd-oper:system-monitoring/cpu-utilization"
    ],
    datatype="all"
)

[akarneliuk]

Thanks @rao-aneesh and @andyjsharp for details