IOSXR "no negotiation auto" Issue

[bjronmork]

I am facing IOSXR issue in getting/generating  "no negotiation auto" command using NSO. 

I am using the same leaf (via grouping) under IOS and IOSXE device with works fine, but for IOSXR devices, it does not works fine.

      grouping Negotiation {
        container negotiation {
          tailf:info "Select autonegotiation mode";
          leaf auto {
            tailf:info "Enable link autonegotiation";
            tailf:cli-boolean-no;
            type boolean;
          }
        }

container IOS-XR {
when "/ncs:devices/ncs:device[ncs:name=current()/../../device]/ncs:platform/ncs:name='ios-xr'";
uses Interface-Choice-IOSXR;
uses Negotiation;
}
}
}

Below XML is generate in the format of NETCONF (for no negotiation auto).

But I am  using CLI and XML. Please suggest.

admin@ncs(config-config)# 
admin@ncs(config-config)# cisco-ios-xr:interface GigabitEthernet 0/0/0/0 
admin@ncs(config-if)# negotiation auto 
admin@ncs(config-if)# commit dry-run outformat native 
native {
    device {
        name IOS-XR
        data interface GigabitEthernet 0/0/0/0
              negotiation auto
             exit
    }
}
admin@ncs(config-if)# commit dry-run outformat xml   
result-xml {
    local-node {
        data <devices xmlns="http://tail-f.com/ns/ncs">
               <device>
                 <name>IOS-XR</name>
                 <config>
                   <interface xmlns="http://tail-f.com/ned/cisco-ios-xr">
                     <GigabitEthernet>
                       <id>0/0/0/0</id>
                       <negotiation>
                         <auto/>
                       </negotiation>
                     </GigabitEthernet>
                   </interface>
                 </config>
               </device>
             </devices>
    }
}
admin@ncs(config-if)# commit no-networking 
Commit complete.
admin@ncs(config-if)# 
admin@ncs(config-if)# no negotiation auto            
admin@ncs(config-if)# 
admin@ncs(config-if)# 
admin@ncs(config-if)# commit dry-run outformat xml
result-xml {
    local-node {
        data <devices xmlns="http://tail-f.com/ns/ncs">
               <device>
                 <name>IOS-XR</name>
                 <config>
                   <interface xmlns="http://tail-f.com/ned/cisco-ios-xr">
                     <GigabitEthernet>
                       <id>0/0/0/0</id>
                       <negotiation>
                         <auto xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
                               nc:operation="delete"/>
                       </negotiation>
                     </GigabitEthernet>
                   </interface>
                 </config>
               </device>
             </devices>
    }
}
admin@ncs(config-if)# commit no-networking 
Commit complete.
admin@ncs(config-if)#

Regards,

BjronM~

[bjronmork]

Hi Expert,

Please suggest.

Thanks
Bjron

[gmuloche]

Hello,

There are a few points that are needed before somebody can start helping you

The following namespace is the one from the NED CLI for ios-xr: 

xmlns="http://tail-f.com/ned/cisco-ios-xr"

So it looks like you are using the CLI NED - can you confirm this? 

The first code snippet shared looks to be a service model where you have a grouping to activate or deactivate auto-negotiation. You mention that it works fine for IOS/IOS-XE - which seems to indicate that you have some service template or code that is used to map the service configuration to the device configuration - is it the case? In that case have you implemented similar logic in your template/code for IOS-XR devices? Maybe sharing what you have been trying, what works for ios and does not for iosxr (if it is ok) could help the community helping you.

If I had to guess I would say that what you are looking for in your template here is to use the tags (refer to NSO documenation on tags template in nso_development guide the "Templates / Basic Principles / Template tag operations" section ) and replace the XR part in your template with:

<negotiation>
  <auto tags="delete"/>
</negotiation>

for the cases where the boolean in your grouping is false

Regards,

[rogaglia]

Hi,

Shouldn't this delete be part of your "pre-modification" logic? That is where you set what you expect as default configuration. You typically want to avoid "deletes" in FastMap.

Roque