cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
113
Views
5
Helpful
10
Replies
Highlighted
Cisco Employee

How to decode netconf data when NSO connect with ASR9k ?

 

Dear Expert

 

 

As we know, when use NSO connect with ASR9k by netconf, all data transport by SSH.

 

So we couldn’t check whether ASR9k respond correct or incorrect data.

 

Do we have any ways to decode the netconf packets?

 

 

 

  For your convenience I have include my contact details below.
However, please do not hesitate in contacting me if you have any further questions.

Thanks!
Best Regards!

Yong Zhao

Everyone's tags (4)
10 REPLIES 10
Cisco Employee

Re: How to decode netconf data when NSO connect with ASR9k ?

 

Including Jim Gindley since he was testing Yang/Netconf on ASR9k. AFAIK you can use pyang to do.

 

 

BR,

 

Bostjan

 

Cisco Employee

Re: How to decode netconf data when NSO connect with ASR9k ?

 

Hi Frank,

 

 

The only way would be to perform “debug ssh traffic”. Unfortunately this will affect all traffic. If you are accessing the system via ssh for other purposes (e.g. As normal access method). You will end up debugging your debug output.

 

 

You could use the netconf traces and debugs, but I doubt, that they will be convenient to read / decipher for your purpose.

 

 

E.G. The output of netconf-yang backend provides the information, which sysdb information is used. (see below), but does not include the real values.

 

 

Nevertheless you can query the system yourself (with tools like netconf-commander, …) or (if you have the hello & queries handy (in chunked format) directly connecting via ssh "Ssh <user>@<host>  -p 830 –s netconf”.

 

 

Here is a sample request and the netconf-yang debug for the backend module:

 

Request in chunked form (including hello):

 

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

 

  <capabilities>

 

    <capability>urn:ietf:params:netconf:base:1.1</capability>

 

  </capabilities>

 

</hello>]]>]]>

 

#548

 

<?xml version="1.0" encoding="utf-8"?>

 

<rpc message-id="47474747" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

 

    <get-config>

 

        <source>

 

            <running/>

 

        </source>

 

        <filter type="subtree">

 

            <interface-configurations xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ifmgr-cfg">

 

              <interface-configuration>

 

                <interface-name>HundredGigE0/0/0/0</interface-name>

 

              </interface-configuration>

 

            </interface-configurations>

 

        </filter>

 

    </get-config>

 

</rpc>

 

##

 

Device response:

 

#1239

 

<?xml version="1.0"?>

 

<rpc-reply message-id="47474747" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

 

<data>

 

  <interface-configurations xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ifmgr-cfg">

 

   <interface-configuration>

 

    <active>act</active>

 

    <interface-name>HundredGigE0/0/0/0</interface-name>

 

    <description>100G to IXIA 3/1</description>

 

    <mtus>

 

     <mtu>

 

      <owner>HundredGigE</owner>

 

      <mtu>9200</mtu>

 

     </mtu>

 

    </mtus>

 

    <ipv6-network xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ipv6-ma-cfg">

 

     <addresses>

 

      <regular-addresses>

 

       <regular-address>

 

        <address>2003:123a:10:1::1</address>

 

        <prefix-length>96</prefix-length>

 

        <zone>0</zone>

 

       </regular-address>

 

      </regular-addresses>

 

     </addresses>

 

    </ipv6-network>

 

    <ethernet xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-drivers-media-eth-cfg">

 

     <carrier-delay>

 

      <carrier-delay-up>10000</carrier-delay-up>

 

      <carrier-delay-down>0</carrier-delay-down>

 

     </carrier-delay>

 

    </ethernet>

 

    <statistics xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-statsd-cfg">

 

     <load-interval>30</load-interval>

 

    </statistics>

 

   </interface-configuration>

 

  </interface-configurations>

 

 

#22

 

</data>

 

</rpc-reply>

 

 

##

 

 

Output of "debug netconf-yang yfw component bk trace”

 

RP/0/RSP0/CPU0:Jul 11 02:18:42.602 : netconf[1120]: DBG: YFW: ctx=1000a924,Log level set to TRACE for BK general

 

RP/0/RSP1/CPU0:Jul 11 02:18:42.601 : netconf[1120]: DBG: YFW: ctx=1000a924,Log level set to TRACE for BK general

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.247 : netconf[1120]: DBG: YFW: ctx=1000bf44,Processing find-data request

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.247 : netconf[1120]: TRC: YFW: ctx=1000bf44,Finding sysdb data with path prefix '/cfg/if/pre/HundredGigE0_0_0_0/'.

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.249 : netconf[1120]: WRN: YFW: ctx=1000bf44,sysdb_find_data returned an error: 'sysdb' detected the 'warning' condition 'A SysDB client tried to access a nonexistent item or list an empty directory', sysdb_path: 'cfg/if/pre/HundredGigE0_0_0_0/'

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.249 : netconf[1120]: DBG: YFW: ctx=1000bf44,Directory not found (path: cfg/if/pre/HundredGigE0_0_0_0/)

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.249 : netconf[1120]: DBG: YFW: ctx=1000bf44,tid=0x8,Request(1779ca14, op find-data) processed, sending response(2075590c).

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.249 : netconf[1120]: DBG: YFW: ctx=1000bf44,Processing find-data request

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.249 : netconf[1120]: TRC: YFW: ctx=1000bf44,Finding sysdb data with path prefix '/cfg/if/act/HundredGigE0_0_0_0/'.

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.251 : netconf[1120]: DBG: YFW: ctx=1000bf44,Backend find data success.

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.251 : netconf[1120]: DBG: YFW: ctx=1000bf44,tid=0x8,Request(1779ca14, op find-data) processed, sending response(2075590c).

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.251 : netconf[1120]: TRC: YFW: ctx=1000bf44,Next result set item: '/cfg/if/act/HundredGigE0_0_0_0/aa/description' (size: 17 B, datatype: 3).

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.251 : netconf[1120]: TRC: YFW: ctx=1000bf44,Next result set item: '/cfg/if/act/HundredGigE0_0_0_0/aza' (size: 4 B, datatype: 1).

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.251 : netconf[1120]: TRC: YFW: ctx=1000bf44,Next result set item: '/cfg/if/act/HundredGigE0_0_0_0/mtu/HundredGigE' (size: 4 B, datatype: 1).

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.251 : netconf[1120]: TRC: YFW: ctx=1000bf44,Next result set item: '/cfg/if/act/HundredGigE0_0_0_0/ipv6/mae/address/cfg/ord_b/regular/2003123a001000010000000000000001' (size: 29 B, datatype: 5).

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.251 : netconf[1120]: DBG: YFW: ctx=1000bf44,Processing find-subdata request

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.251 : netconf[1120]: TRC: YFW: ctx=1000bf44,Finding subdata on sysdb path '/cfg/if/act/HundredGigE0_0_0_0/ipv6/mae/address/cfg/ord_b/regular/2003123a001000010000000000000001' (datatype: 5).

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.251 : netconf[1120]: TRC: YFW: ctx=1000bf44,Decoding whole structure of the pack, format: '%d%2S%d', mask=0x3, pack ctx=19f53838.

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.251 : netconf[1120]: TRC: YFW: ctx=1000bf44,Structured decoding of the pack succeeded, num. of present packed elements=2, pack ctx=19f53838.

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.251 : netconf[1120]: DBG: YFW: ctx=1000bf44,Backend find sub data success.

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.251 : netconf[1120]: DBG: YFW: ctx=1000bf44,tid=0x8,Request(19ea4710, op find-subdata) processed, sending response(20755790).

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.252 : netconf[1120]: TRC: YFW: ctx=1000bf44,Pack ctx=19f53838 next element data (index=0, type=d): 96

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.252 : netconf[1120]: TRC: YFW: ctx=1000bf44,Next result set item: '/cfg/if/act/HundredGigE0_0_0_0/ipv6/mae/address/cfg/ord_b/regular/2003123a001000010000000000000001`0' (size: 4 B, datatype: 1).

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.252 : netconf[1120]: TRC: YFW: ctx=1000bf44,Pack ctx=19f53838 next element data (index=1, type=s): '0'

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.252 : netconf[1120]: TRC: YFW: ctx=1000bf44,Next result set item: '/cfg/if/act/HundredGigE0_0_0_0/ipv6/mae/address/cfg/ord_b/regular/2003123a001000010000000000000001`1' (size: 2 B, datatype: 3).

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.252 : netconf[1120]: TRC: YFW: ctx=1000bf44,Pack ctx=19f53838: no more packed elements present in the pack.

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.252 : netconf[1120]: TRC: YFW: ctx=1000bf44,No more items in the result set (result set type: 1, path prefix: '/cfg/if/act/HundredGigE0_0_0_0/ipv6/mae/address/cfg/ord_b/regular/2003123a001000010000000000000001').

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.252 : netconf[1120]: TRC: YFW: ctx=1000bf44,Next result set item: '/cfg/if/act/HundredGigE0_0_0_0/ether/carrierdelay' (size: 28 B, datatype: 5).

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.252 : netconf[1120]: DBG: YFW: ctx=1000bf44,Processing find-subdata request

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.252 : netconf[1120]: TRC: YFW: ctx=1000bf44,Finding subdata on sysdb path '/cfg/if/act/HundredGigE0_0_0_0/ether/carrierdelay' (datatype: 5).

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.252 : netconf[1120]: TRC: YFW: ctx=1000bf44,Decoding whole structure of the pack, format: '%d%d', mask=0x3, pack ctx=21f66f38.

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.252 : netconf[1120]: TRC: YFW: ctx=1000bf44,Structured decoding of the pack succeeded, num. of present packed elements=2, pack ctx=21f66f38.

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.252 : netconf[1120]: DBG: YFW: ctx=1000bf44,Backend find sub data success.

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.252 : netconf[1120]: DBG: YFW: ctx=1000bf44,tid=0x8,Request(1779ca14, op find-subdata) processed, sending response(2075590c).

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.252 : netconf[1120]: TRC: YFW: ctx=1000bf44,Pack ctx=21f66f38 next element data (index=0, type=d): 10000

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.252 : netconf[1120]: TRC: YFW: ctx=1000bf44,Next result set item: '/cfg/if/act/HundredGigE0_0_0_0/ether/carrierdelay`0' (size: 4 B, datatype: 1).

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.252 : netconf[1120]: TRC: YFW: ctx=1000bf44,Pack ctx=21f66f38 next element data (index=1, type=d): 0

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.252 : netconf[1120]: TRC: YFW: ctx=1000bf44,Next result set item: '/cfg/if/act/HundredGigE0_0_0_0/ether/carrierdelay`1' (size: 4 B, datatype: 1).

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.253 : netconf[1120]: TRC: YFW: ctx=1000bf44,Pack ctx=21f66f38: no more packed elements present in the pack.

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.253 : netconf[1120]: TRC: YFW: ctx=1000bf44,No more items in the result set (result set type: 1, path prefix: '/cfg/if/act/HundredGigE0_0_0_0/ether/carrierdelay').

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.253 : netconf[1120]: TRC: YFW: ctx=1000bf44,Next result set item: '/cfg/if/act/HundredGigE0_0_0_0/statsd/load-interval' (size: 4 B, datatype: 1).

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.253 : netconf[1120]: TRC: YFW: ctx=1000bf44,No more items in the result set (result set type: 0, path prefix: '/').

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.253 : netconf[1120]: TRC: YFW: ctx=1000bf44,Processing cache-flush.

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.253 : netconf[1120]: TRC: YFW: ctx=1000bf44,Flushing bag cache.

 

RP/0/RSP0/CPU0:Jul 11 02:18:53.253 : netconf[1120]: TRC: YFW: ctx=1000bf44,Cleaning up all bag processing contexts

 

 

Cheers,

 

 

Michael

 

 

 

Cisco Employee

Re: How to decode netconf data when NSO connect with ASR9k ?

 

Hello Frank,

 

 

What I  can recommend you is to use IOS-XR NED  to talk with the ASR9K device and then you can easily get NED trace to see what is going on between the NSO and the end device.

 

 

Please correct me if I am wrong.

/Tamal

 

Cisco Employee

Re: How to decode netconf data when NSO connect with ASR9k ?

 

Hi,

 

 

You can enable the NED trace for individual devices.

 

 

set devices device (device name) trace pretty  -- to see in better format

 

set devices device (device name)trace raw –to see in raw format.

 

 

After enabling the NED trace you can go and check it in  /var/log/ncs folder.

 

 

Please let me know if you need any further help for this.

 

/Tamal

Cisco Employee

Re: How to decode netconf data when NSO connect with ASR9k ?

 

Yes, with the  southbound trace we can see this:
(netconf-<devicename>.trace will be the file name)

cat netconf-xrv.trace | more

>>>>out 11-Jul-2016::20:13:28.232 device=xrv
<hello xmlns=
"urn:ietf:params:xml:ns:netconf:base:1.0">
   <capabilities>
     <capability>
urn:ietf:params:netconf:base:1.0</capability>
     <capability>urn:ietf:params:netconf:base:1.1</capability>
   </capabilities>
</hello>

<<<<in 11-Jul-2016::20:13:28.450 device=xrv
<hello xmlns=
"urn:ietf:params:xml:ns:netconf:base:1.0">
   <capabilities>
     <capability>
urn:ietf:params:netconf:base:1.1</capability>
     <capability>urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring?deviation=cisco-xr-netconf-monitoring-deviations</capability>
     <capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
     <capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability>
     <capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
     <capability>urn:ietf:params:netconf:capability:confirmed-commit:1.1</capability>

 


Thanks,
Tomo

 

Cisco Employee

Re: How to decode netconf data when NSO connect with ASR9k ?

 

Thanks Michael and Tamal and all !

 

 

Yes, as Tamal said, NED trace that is I want at NSO side !

 

In fact, in order to troubleshooting netconf issue or understand communication interactive by netconf, we need identified whether devices sent or receive correct netconf, I think have follow way:

 

 

1. Capture SSH packets by sniffer, and decode the packets, but that looks like very difficult.

 

 

After google, found have ssh_decoder in follow web:

 

https://www.cr0.org/progs/sshfun/

 

 

But when I capture packets by tcpick, dump crash…, don’t know why now.

 

 

ot@frank ssh_decoder-1.0]# tcpick -i ens32 -wR

 

Starting tcpick 0.2.1 at 2016-07-11 16:56 CST

 

Timeout for connections is 600

 

tcpick: listening on ens32

 

1      SYN-SENT       10.75.13.138:43556 > 10.75.13.16:netconf-ssh

 

1      SYN-RECEIVED   10.75.13.138:43556 > 10.75.13.16:netconf-ssh

 

1      ESTABLISHED    10.75.13.138:43556 > 10.75.13.16:netconf-ssh

 

Segmentation fault (core dumped)

 

 

2. Capture netconf content after SSH decipher on NSO or ASR9k, now base on Tamal’s mail, we can see that in NSO.

 

Btw, I found the trace couldn’t create again after rm -rf netconf-asr9001-1.trace, how to resolve that?

 

 

Above is NSO trace, do we have similar function on ASR9k?

 

 

Thanks

 

Yong

 

Cisco Employee

Re: How to decode netconf data when NSO connect with ASR9k ?

 

Hi,

> Btw, I found the trace couldn’t create again after
rm -rf netconf-asr9001-1.trace, how to resolve that?

 

This can be solved by reconfiguring the trace.

cisco@ncs# file list ./logs/ | include netconf-xrv
cisco@ncs# config
Entering configuration mode terminal
cisco@ncs(config)# devices device xrv
cisco@ncs(config-device-xrv)# no trace
cisco@ncs(config-device-xrv)# commit
Commit complete.
cisco@ncs(config-device-xrv)# trace pretty
cisco@ncs(config-device-xrv)# commit
Commit complete.
cisco@ncs(config-device-xrv)# end
cisco@ncs# devices device xrv sync-from
result true
cisco@ncs# file list ./logs/ | include netconf-xrv
netconf-xrv.trace

Thanks,
Tomo

 

Cisco Employee

Re: How to decode netconf data when NSO connect with ASR9k ?

 

Hi,

 

 

Just re-start NSO.

 

 

Roque

 

Cisco Employee

Re: How to decode netconf data when NSO connect with ASR9k ?

 

>

 

> 2. Capture netconf content after SSH decipher on NSO or ASR9k, now

 

> base on Tamal’s mail, we can see that in NSO.

 

> Btw, I found the trace couldn’t create again after rm -rf

 

> netconf-asr9001-1.trace,*how to resolve that?*

 

 

NSO will continue to log to the same fd, just because you rm the file, the inode doesn't disappear. Actually this is a major feature, this is the functionality that enables logrotate.

 

 

To tell NSO to reopen logfiles, do

 

 

Either:

 

 

$ ncs --reload

 

 

or

 

 

$ ncs_cmd -c reopen_logs

 

 

 

Relevant snippet from man page

 

 

$ man ncs

 

....

 

       --reload

 

           Reload the NCS daemon configuration. All log files are closed and

 

reopened, which means that ncs --reload can be used from e.g.

 

logrotate(8), but it is more efficient to use ncs_cmd -c

 

reopen_logs for this purpose. Note: If we update a .fxs file it is

 

           not enough to do a reload; the "packages reload" action must be

 

           invoked, or the daemon must be restarted with the

 

--with-package-reload option.

 

 

 

/klacke

 

 

Cisco Employee

Re: How to decode netconf data when NSO connect with ASR9k ?

 

Hi, Roque, Tomonobu, Klacke and all

 

 

Thanks your kindly help for the questions on NSO side.

 

Yes, just reload the NSO that fix trace log issue.

 

 

Thanks

 

Yong

 

Content for Community-Ad
August's Community Spotlight Awards