Closed jwbensley closed 7 years ago
James,
Can you please check which version of the openconfig model you are using on the client side versus the version supported by the device? The openconfig models switched to the identity definition you have on the client side a while ago, but Cisco platforms do not support that version as yet.
Cheers,
Einar
Issue was tracked with XR defect CSCvb66790. It has been fixed for several weeks now. A more recent XR should have the fix already.
@111pontes I will try to download the latest bleeding edge image and try that.
@einarnn I am using the latest OpenConfig YANG modules from https://github.com/openconfig/public/tree/master/release/models/bgp which haven't been updated in 4 months.
Under https://github.com/openconfig/public/tree/master/release/models the module openconfig-types.yang hasn't been updated for 5 months. Also 5 months for the modules in https://github.com/openconfig/public/tree/master/release/models/interfaces
Looking through the modules they all say yang-version "1" and oc-ext:openconfig-version "2.1.1".
How can I check what is supported on the IOS-XRv device? Is there a command I can run?
Many thanks!
I suspect this is the info you were after @einarnn ;
xr-vm_node0_RP0_CPU0:/opt/cisco/XR/packages/iosxrv-mgbl-3.0.0.0-r62117I/rp/yang$ grep -r "openconfig-version" openconfig*.yang
openconfig-bgp-multiprotocol.yang: oc-ext:openconfig-version "1.1.0";
openconfig-bgp-operational.yang: oc-ext:openconfig-version "1.1.0";
openconfig-bgp-policy.yang: oc-ext:openconfig-version "1.1.0";
openconfig-bgp-types.yang: oc-ext:openconfig-version "1.1.0";
openconfig-bgp.yang: oc-ext:openconfig-version "1.1.0";
openconfig-extensions.yang: extension openconfig-version {
openconfig-if-aggregate.yang: oc-ext:openconfig-version "0.2.0";
openconfig-if-ethernet.yang: oc-ext:openconfig-version "0.2.0";
openconfig-if-ip.yang: oc-ext:openconfig-version "0.2.0";
openconfig-interfaces.yang: oc-ext:openconfig-version "0.2.0";
openconfig-mpls-igp.yang: oc-ext:openconfig-version "0.2.1";
openconfig-mpls-ldp.yang: oc-ext:openconfig-version "0.2.1";
openconfig-mpls-rsvp.yang: oc-ext:openconfig-version "0.2.1";
openconfig-mpls-sr.yang: oc-ext:openconfig-version "0.2.1";
openconfig-mpls-static.yang: oc-ext:openconfig-version "0.2.1";
openconfig-mpls-te.yang: oc-ext:openconfig-version "0.2.1";
openconfig-mpls-types.yang: oc-ext:openconfig-version "0.2.1";
openconfig-mpls.yang: oc-ext:openconfig-version "0.2.1";
openconfig-platform-transceiver.yang: oc-ext:openconfig-version "0.1.0";
openconfig-platform-types.yang: oc-ext:openconfig-version "0.4.0";
openconfig-platform.yang: oc-ext:openconfig-version "0.4.0";
openconfig-policy-types.yang: oc-ext:openconfig-version "1.1.0";
openconfig-routing-policy.yang: oc-ext:openconfig-version "1.1.0";
openconfig-telemetry.yang: oc-ext:openconfig-version "0.2.0";
openconfig-terminal-device.yang: oc-ext:openconfig-version "0.3.1";
openconfig-transport-types.yang: oc-ext:openconfig-version "0.3.1";
openconfig-types.yang: oc-ext:openconfig-version "0.2.0";
openconfig-vlan.yang: oc-ext:openconfig-version "0.1.1";
Can I simply SCP to the IOS-XRv device the newer OC YANG models or is there some backend stuff that needs updating that would prevent that from working?
Having said that, BGP YANG types on the IOS-XRv device (openconfig-bgp-types.yang: oc-ext:openconfig-version "1.1.0") has the same definitions as those on my client side (v2.2.0):
xr-vm_node0_RP0_CPU0:/opt/cisco/XR/packages/iosxrv-mgbl-3.0.0.0-r62117I/rp/yang$ less openconfig-bgp-types.yang
identity IPV4-UNICAST {
base afi-safi-type;
description
"IPv4 unicast (AFI,SAFI = 1,1)";
reference "RFC4760";
}
identity IPV6-UNICAST {
base afi-safi-type;
description
"IPv6 unicast (AFI,SAFI = 2,1)";
reference "RFC4760";
}
James,
Backend stuff is required.
Cheers,
Einar
@einarnn Thanks for confirming, that is what I expected. I assumed that is required so that the JSON formatted data can be ingested into a YANG module and then translated to the IOS-XR internal config data model (or a similar process). So what happens next, since this is "simply" a case of the OpenConfig modules inside IOS-XR being a bit behind do I just need to wait for them to be updated in future versions of IOS-XR?
Let me clarify that the issue you're experiencing here doesn't have to do with the model version. It has to do with a defect (CSCvb66790). XR was encoding the identities as lower case despite the fact that they are case-sensitive and defined in upper case. The defect has been fixed and in the process of being integrated into the next official release. If you have access to pre-release images, you should see the fix in the following weeks.
@111pontes Ah ok, that makes sense. Thank you.
I have access to the beta builds. I will wait for a new build to come out and report back here :)
Fixed. Expected to be released in XR 6.2.1.
NB: This is the gRPC client "grpc_cfg.py" I am using based off of the public Cisco example: https://gist.github.com/jwbensley/cd2f5bfacee321328ca638b5b5523bd9
NB: This is using the IOS-XRv 6.2.1 stable vagrant image from https://devhub.cisco.com/artifactory/appdevci-release/XRv64/6.2.1/ dated 17th Oct 2016
OpenConfig defines the BGP AFI/SAFI types "IPV6_UNICAST" and "IPV4_UNICAST" etc but the IOS-XRv device only accepts "ipv6-unicast" or "ipv4-unicast" so they must be replaced/converted to lower case text of the AFI/SAFI name before the config (serialized as JSON using Pyangbind v0.5.8) can be pushed to the IOS-XRv device.
This:
Needs to be:
From openconfig-bgp-types.yang:
Here is a live example, the same issue but with IPv6. If I change from "IPV6_UNICAST" to "ipv6-unicast" it works fine: