Guest

Preview Tool

Cisco Bug: CSCvt75627 - 'YANG framework' detected the 'fatal' condition 'Operation failed'

Last Modified

Sep 02, 2020

Products (1)

  • Cisco ASR 9000 Series Aggregation Services Routers

Known Affected Releases

6.6.2.BASE

Description (partial)

Symptom:
The error message returned by the IOS-XR reflects an issue on the device itself, on elements that are described as leaf-list (=>accepting a list of values) in current yang model while on CLI those elements can only accept one single value (=>leaf)

Conditions:
Enabling no-overwirte on NSO:
admin@ncs(config)# devices global-settings no-overwrite enabled-by-default true

Pushing a second class-map:
admin@ncs(config)# devices device a9k-662 config infra-policymgr-cfg:policy-manager class-maps class-map qos TEST2 class-map-mode-match-any match dscp [ cs2 cs4 ]
admin@ncs(config-class-map-qos/TEST2)# show conf
devices device a9k-662
config
  infra-policymgr-cfg:policy-manager class-maps class-map qos TEST2
   class-map-mode-match-any
   match dscp [ cs2 cs4 ]
  !
!
!
admin@ncs(config-class-map-qos/TEST2)# commit dry-run outformat native
native {
    device {
        name a9k-662
        data <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
                  message-id="1">
               <edit-config xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
                 <target>
                   <candidate/>
                 </target>
                 <test-option>test-then-set</test-option>
                 <error-option>rollback-on-error</error-option>
                 <config>
                   <policy-manager xmlns=" http://cisco.com/ns/yang/Cisco-IOS-XR-infra-policymgr-cfg">;
                     <class-maps>
                       <class-map xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
                                  nc:operation="create">
                         <type>qos</type>
                         <name>TEST2</name>
                         <match>
                           <dscp>cs2</dscp>
                           <dscp>cs4</dscp>
                         </match>
                         <class-map-mode-match-any/>
                       </class-map>
                     </class-maps>
                   </policy-manager>
                 </config>
               </edit-config>
             </rpc>
    }
}
admin@ncs(config-class-map-qos/TEST2)#


Here NSO is setting nc:operation=?create? on the class-map and it makes perfectly sense.
NSO think the class-map TEST2 doesn’t exist on the device (which is the case) but cannot rely on the device transaction-id to be certain of that (because of commit no-overwrite feature)
Instead NSO could do a get-config of class-map list to retrieve the device configuration and compare it to its local database to ensure the class-map list has not been modified ?offline?, but that would be one more netconf request.

Instead NSO is actually optimizing the edit-config call by putting nc:operation=?create? on the class-map list for element ?TEST2?.
The impact of this is: if a TEST2 element in list class-map already exist on the 9k, the 9k is going to reject the config because that’s against the ?nc:operation=create? logic (=> the element should not already exist in the list when we use create)

That match the create definition of the RFC you were referring to:

???
create:  The configuration data identified by the element
            containing this attribute is added to the configuration if
            and only if the configuration data does not already exist in
            the configuration datastore.  If the configuration data
            exists, an <rpc-error> element is returned with an
            <error-tag> value of "data-exists".
???

This block is basically saying: if you try to add and element in the list with tag ?create? and if this element already exist, device will return an rpc-error with <error-tag> equals to ?data-exists?.


So this way of settings nc:operation=?create? by NSO is 100% valid.

But we actually get this error from device:

admin@ncs(config-class-map-qos/TEST2)# commit
Aborted: RPC error towards a9k-662: operation_failed: for ns1:policy-manager/ns1:class-maps/ns1:class-map[type = 'qos' and name = 'TEST2']/ns1:match/ns1:fr-de: 'YANG framework' detected the 'fatal' condition 'Operation failed'
admin@ncs(config-class-map-qos/TEST2)#




Inspecting the netconf logs show the device is not replying with an error-tag ?data-exists? but rather ?operation-failed?:

>>>>out 4-Mar-2020::18:39:50.908 device=a9k-662 session-id=2509828372
<?xml version="1.0" encoding="UTF-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="4">
<edit-config xmlns:nc='urn:ietf:params:xml:ns:netconf:base:1.0'><target><candidate/></target><test-option>test-then-set</test-option><error-option>rollback-on-error</error-option><config>
<policy-manager xmlns=" http://cisco.com/ns/yang/Cisco-IOS-XR-infra-policymgr-cfg"><class-maps><class-map xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="create"><type>qos</type><name>TEST2</name><match><dscp>cs2</dscp><dscp>cs4</dscp></match><class-map-mode-match-any></class-map-mode-match-any></class-map></class-maps></policy-manager></config></edit-config>
</rpc>

>>>>out 4-Mar-2020::18:39:50.909 device=a9k-662 session-id=2509828372
EOM

<<<<in 4-Mar-2020::18:39:51.182 device=a9k-662 session-id=2509828372

#571
<?xml version="1.0"?>
<rpc-reply message-id="4" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error>
  <error-type>application</error-type>
  <error-tag>operation-failed</error-tag>
  <error-severity>error</error-severity>
  <error-path xmlns:ns1=" http://cisco.com/ns/yang/Cisco-IOS-XR-infra-policymgr-cfg">ns1:policy-manager/ns1:class-maps/ns1:class-map[type = 'qos' and name = 'TEST2']/ns1:match/ns1:fr-de</error-path>
  <error-message xml:lang="en">'YANG framework' detected the 'fatal' condition 'Operation failed'</error-message>
</rpc-error>
</rpc-reply>

##




I’m convinced the logic of setting the nc:operation=?create? is valid for a list element because in case of policy-map this is actually working fine:

No policy-map TEST exist on the 9k:

RP/0/RSP0/CPU0:N-ASR9K-PESNG-2#show run policy-map type qos TEST
Wed Mar  4 18:24:41.866 CET
% No such configuration item(s)

RP/0/RSP0/CPU0:N-ASR9K-PESNG-2#



Trying to create one from NSO using the commit-no overwrite feature:
admin@ncs(config)# devices global-settings no-overwrite enabled-by-default true
admin@ncs(config)# devices device a9k-662 config infra-policymgr-cfg:policy-manager policy-maps policy-map qos TEST policy-map-rule class-default qos service-policy policy-name PACK_QOS_XVD4DA_M
admin@ncs(config-policy-map-rule-class-default/qos)# show conf
devices device a9k-662
config
  infra-policymgr-cfg:policy-manager policy-maps policy-map qos TEST
   policy-map-rule class-default qos
    service-policy policy-name PACK_QOS_XVD4DA_M
   !
  !
!
!
admin@ncs(config-policy-map-rule-class-default/qos)# commit dry-run outformat native
native {
    device {
        name a9k-662
        data <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
                  message-id="1">
               <edit-config xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
                 <target>
                   <candidate/>
                 </target>
                 <test-option>test-then-set</test-option>
                 <error-option>rollback-on-error</error-option>
                 <config>
                   <policy-manager xmlns=" http://cisco.com/ns/yang/Cisco-IOS-XR-infra-policymgr-cfg">;
                     <policy-maps>
                       <policy-map xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
                                   nc:operation="create">
                         <type>qos</type>
                         <name>TEST</name>
                         <policy-map-rule>
                           <class-name>class-default</class-name>
                           <class-type>qos</class-type>
                           <service-policy>
                             <policy-name>PACK_QOS_XVD4DA_M</policy-name>
                           </service-policy>
                         </policy-map-rule>
                       </policy-map>
                     </policy-maps>
                   </policy-manager>
                 </config>
               </edit-config>
             </rpc>
    }
}
admin@ncs(config-policy-map-rule-class-default/qos)#



Here again, because of commit no-overwrite, NSO is setting nc:operation=?create?.
But this time the commit is accepted by the device:
admin@ncs(config-policy-map-rule-class-default/qos)# commit
Commit complete.


And the configuration is pushed on the device:

RP/0/RSP0/CPU0:N-ASR9K-PESNG-2#show run policy-map type qos TEST
Wed Mar  4 18:30:10.907 CET
policy-map TEST
class class-default
  service-policy PACK_QOS_XVD4DA_M
!
end-policy-map
!

RP/0/RSP0/CPU0:N-ASR9K-PESNG-2#





 I’m thinking the issue is actually more related to the actual error message we get from the 9k at that path:

ns1:policy-manager/ns1:class-maps/ns1:class-map[type = 'qos' and name = 'TEST2']/ns1:match/ns1:fr-de


As Vidhya was noticing, on the 9k CLI the following match accept only one value:

RP/0/RSP0/CPU0:N-ASR9K-PESNG-2(config-cmap)#match fr-de ?
  <1-1>  FR DE value
RP/0/RSP0/CPU0:N-ASR9K-PESNG-2(config-cmap)#match mpls disposition access-group ipv4 ?
  WORD  Access list name - maximum 32 characters
RP/0/RSP0/CPU0:N-ASR9K-PESNG-2(config-cmap)#match mpls disposition access-group ipv6 ?
  WORD  Access list name - maximum 32 characters
RP/0/RSP0/CPU0:N-ASR9K-PESNG-2(config-cmap)#match atm clp ?
  <0-1>  ATM CLP level
  <cr>
RP/0/RSP0/CPU0:N-ASR9K-PESNG-2(config-cmap)#match access-group ethernet-services ?
  WORD  Access list name - maximum 64 characters



But are all configured as leaf-list in the yang model, which doesn’t make sense:

leaf-list ethernet-services-acl {
leaf-list mpls-disposition-ipv4-access-list {
leaf-list mpls-disposition-ipv6-access-list {
leaf-list fr-de {
leaf-list atm-clp {
Bug details contain sensitive information and therefore require a Cisco.com account to be viewed.

Bug Details Include

  • Full Description (including symptoms, conditions and workarounds)
  • Status
  • Severity
  • Known Fixed Releases
  • Related Community Discussions
  • Number of Related Support Cases
Bug information is viewable for customers and partners who have a service contract. Registered users can view up to 200 bugs per month without a service contract.