cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
17641
Views
16
Helpful
23
Replies

Cisco 3650 Show commands via API

mikegrous
Level 3
Level 3

I followed the below link and life is good on pulling info from the config via API. But how would I go about pulling info from the API that exist in show commands? IE get the output of show cdp n or show ip route etc?

Getting Started with NETCONF/YANG – Part 1

1 Accepted Solution

Accepted Solutions

Yes, you need to change the filter too.

Change:

rtr_filter = '''

<filter>

  <IP-FORWARD-MIB xmlns="urn:ietf:params:xml:ns:yang:smiv2:IP-FORWARD-MIB"/>

</filter>

'''

to

rtr_filter = '''

<filter>

<routing-state xmlns="urn:ietf:params:xml:ns:yang:ietf-routing"/>

</filter>

'''


I get lots of output....

{

    "data": {

        "@xmlns": "urn:ietf:params:xml:ns:netconf:base:1.0",

        "@xmlns:nc": "urn:ietf:params:xml:ns:netconf:base:1.0",

        "routing-state": {

            "@xmlns": "urn:ietf:params:xml:ns:yang:ietf-routing",

            "routing-instance": [

                {

                    "name": "Mgmt-vrf",

                    "type": "vrf-routing-instance",

                    "ribs": {

                        "rib": [

                            {

                                "name": "ipv4-default",

                                "address-family": {

                                    "@xmlns:v4ur": "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing",

                                    "#text": "v4ur:ipv4-unicast"

                                },

                                "default-rib": "true",

                                "routes": {

                                    "route": [

                                        {

                                            "destination-prefix": "0.0.0.0/0",

                                            "route-preference": "1",

                                            "metric": "0",

                                            "next-hop": {

                                                "next-hop-address": "10.66.104.65"

                                            },

                                            "source-protocol": "static"

                                        },

                                        {

                                            "destination-prefix": "10.66.104.111/32",

                                            "route-preference": "0",

                                            "metric": "0",

                                            "next-hop": {

                                                "outgoing-interface": "GigabitEthernet0/0"

                                            },

                                            "source-protocol": "direct"

                 <SNIP>    

View solution in original post

23 Replies 23

aradford
Cisco Employee
Cisco Employee

hi Michael,

If you want access to the CDP or routing information there are models to retrieve that via netconf/Yang. This is called operational-data or oper-data.  On a 3650 you need to run 16.5 code for this.  This would give you structured data.

Do you need some help with working out the right model/filter to use to make the request?

For routing state you can do a netconf GET for <routing-state/>.

Adam

I will have to upgrade the switches and then if you have any examples of how to retrieve this information that would be great. I can test and update this thread.

While NETCONF (and RESTCONF) do provide some operational data, it isn't an exact match to what you see in "show" commands.  However, these protocols do provide for some operational data in a structured (i.e., JSON or XML) format.  For example, our devices expose all SNMP MIB data via YANG data models, so they are accessible via NETCONF or RESTCONF.  The attached Python script will dump the contents of the CDP neighbor table in JSON (via NETCONF).  You could use this to then build the "show cdp neighbor" output.

{

    "data": {

        "@xmlns": "urn:ietf:params:xml:ns:netconf:base:1.0",

        "@xmlns:nc": "urn:ietf:params:xml:ns:netconf:base:1.0",

        "CISCO-CDP-MIB": {

            "@xmlns": "urn:ietf:params:xml:ns:yang:smiv2:CISCO-CDP-MIB",

            "cdpCacheTable": {

                "cdpCacheEntry": [

                    {

                        "cdpCacheIfIndex": "1",

                        "cdpCacheDeviceIndex": "2",

                        "cdpCacheAddressType": "ip",

                        "cdpCacheAddress": "wKgBJA==",

                        "cdpCacheVersion": "Cisco IOS Software, C3560 Software (C3560-IPSERVICESK9-M), Version 15.0(2)SE10, RELEASE SOFTWARE (fc2)\nTechnical Support: http://www.cisco.com/techsupport\nCopyright (c) 1986-2016 by Cisco Systems, Inc.\nCompiled Mon 18-Jul-16 02:05 by prod_rel_team",

                        "cdpCacheDeviceId": "jabberwocky.marcuscom.com",

                        "cdpCacheDevicePort": "FastEthernet0/11",

                        "cdpCachePlatform": "cisco WS-C3560V2-24TS",

                        "cdpCacheCapabilities": "AAAAKQ==",

                        "cdpCacheVTPMgmtDomain": "MARCUSCOM",

                        "cdpCacheNativeVLAN": "1",

                        "cdpCacheDuplex": "fullduplex",

                        "cdpCacheLastChange": "1132114"

                    },

                    {

                        "cdpCacheIfIndex": "8",

                        "cdpCacheDeviceIndex": "1",

                        "cdpCacheAddressType": "ip",

                        "cdpCacheAddress": "wKgBLg==",

                        "cdpCacheVersion": "1",

                        "cdpCacheDeviceId": "00180a974f01",

                        "cdpCacheDevicePort": "Port 3",

                        "cdpCachePlatform": "MS220-24P",

                        "cdpCacheCapabilities": "AAAACA==",

                        "cdpCacheVTPMgmtDomain": null,

                        "cdpCacheNativeVLAN": "1",

                        "cdpCacheDuplex": "unknown",

                        "cdpCacheLastChange": "1082893"

                    }

                ]

            }

        }

    }

}

The same can be done with the routing table and the ietf-routing module:

{

    "data": {

        "@xmlns": "urn:ietf:params:xml:ns:netconf:base:1.0",

        "@xmlns:nc": "urn:ietf:params:xml:ns:netconf:base:1.0",

        "routing": {

            "@xmlns": "urn:ietf:params:xml:ns:yang:ietf-routing",

            "routing-instance": [

                {

                    "name": "Mgmt-vrf",

                    "interfaces": {

                        "interface": [

                            "Loopback0",

                            "GigabitEthernet0/0"

                        ]

                    },

                    "routing-protocols": {

                        "routing-protocol": {

                            "type": "static",

                            "name": "1",

                            "static-routes": {

                                "ipv4": {

                                    "@xmlns": "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing",

                                    "route": {

                                        "destination-prefix": "0.0.0.0/0",

                                        "next-hop": {

                                            "next-hop-address": "192.168.1.1"

                                        }

                                    }

                                }

                            }

                        }

                    }

                },

                {

                    "name": "default",

                    "description": "default-vrf [read-only]",

                    "interfaces": null,

                    "routing-protocols": {

                        "routing-protocol": {

                            "type": "static",

                            "name": "1"

                        }

                    }

                }

            ]

        }

    }

}

Not sure if I am doing something wrong or not but...

Here is my route table...

East-Core#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is 10.119.192.6 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 10.119.192.6
      10.0.0.0/8 is variably subnetted, 29 subnets, 4 masks
C        10.119.192.4/30 is directly connected, Vlan10
L        10.119.192.5/32 is directly connected, Vlan10
O        10.119.192.10/32 [110/2] via 10.119.192.42, 22:06:40, Vlan1190
C        10.119.192.11/32 is directly connected, Loopback0
C        10.119.192.16/29 is directly connected, Vlan1192
L        10.119.192.17/32 is directly connected, Vlan1192
C        10.119.192.24/29 is directly connected, Vlan1193
L        10.119.192.25/32 is directly connected, Vlan1193
O        10.119.192.32/29 [110/2] via 10.119.192.42, 22:06:40, Vlan1190
C        10.119.192.40/29 is directly connected, Vlan1190
L        10.119.192.43/32 is directly connected, Vlan1190
C        10.119.193.0/24 is directly connected, Vlan193
L        10.119.193.1/32 is directly connected, Vlan193
O        10.119.194.0/24 [110/2] via 10.119.192.42, 22:06:40, Vlan1190
C        10.119.197.0/24 is directly connected, Vlan197
L        10.119.197.1/32 is directly connected, Vlan197
O        10.119.198.0/24 [110/2] via 10.119.192.42, 22:06:40, Vlan1190
C        10.119.199.0/24 is directly connected, Vlan199
L        10.119.199.1/32 is directly connected, Vlan199
O        10.119.200.0/24 [110/2] via 10.119.192.42, 22:06:40, Vlan1190
C        10.119.205.0/24 is directly connected, Vlan205
L        10.119.205.1/32 is directly connected, Vlan205
O        10.119.206.0/24 [110/2] via 10.119.192.42, 22:06:40, Vlan1190
S        10.119.207.0/24 [1/0] via 10.119.192.18
S        10.119.208.0/24 [1/0] via 10.119.192.18
S        10.119.209.0/24 [1/0] via 10.119.192.18
S        10.119.210.0/24 [1/0] via 10.119.192.18
S        10.119.211.0/24 [1/0] via 10.119.192.18
S        10.119.212.0/24 [1/0] via 10.119.192.18

The script outputs the following:

{

    "data": {

        "@xmlns": "urn:ietf:params:xml:ns:netconf:base:1.0",

        "@xmlns:nc": "urn:ietf:params:xml:ns:netconf:base:1.0",

        "routing": {

            "@xmlns": "urn:ietf:params:xml:ns:yang:ietf-routing",

            "routing-instance": [

                {

                    "name": "Mgmt-vrf",

                    "interfaces": {

                        "interface": "GigabitEthernet0/0"

                    },

                    "routing-protocols": {

                        "routing-protocol": {

                            "type": "static",

                            "name": "1"

                        }

                    }

                },

                {

                    "name": "default",

                    "description": "default-vrf [read-only]",

                    "interfaces": null,

                    "routing-protocols": {

                        "routing-protocol": [

                            {

                                "type": {

                                    "@xmlns:ospf": "urn:ietf:params:xml:ns:yang:ietf-ospf",

                                    "#text": "ospf:ospfv2"

                                },

                                "name": "1",

                                "ospf": {

                                    "@xmlns": "urn:ietf:params:xml:ns:yang:ietf-ospf",

                                    "instance": {

                                        "af": {

                                            "@xmlns:rt": "urn:ietf:params:xml:ns:yang:ietf-routing",

                                            "#text": "rt:ipv4"

                                        },

                                        "nsr": {

                                            "enable": "false"

                                        },

                                        "auto-cost": {

                                            "enable": "false"

                                        },

                                        "redistribution": {

                                            "@xmlns": "urn:ietf:params:xml:ns:yang:cisco-ospf",

                                            "rip": null

                                        }

                                    }

                                }

                            },

                            {

                                "type": "static",

                                "name": "1",

                                "static-routes": {

                                    "ipv4": {

                                        "@xmlns": "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing",

                                        "route": {

                                            "destination-prefix": "0.0.0.0/0",

                                            "next-hop": {

                                                "next-hop-address": "10.119.192.43"

                                            }

                                        }

                                    }

                                }

                            }

                        ]

                    }

                }

            ]

        }

    }

}

wrong filter.

you need to change the body of the filter to

<routing-state xmlns="urn:ietf:params:xml:ns:yang:ietf-routing"/>

When I change the filter I get the below...

Are these filters documented anywhere?

{

    "data": {

        "@xmlns": "urn:ietf:params:xml:ns:netconf:base:1.0",

        "@xmlns:nc": "urn:ietf:params:xml:ns:netconf:base:1.0"

    }

}

Hi Michael,

you can work out the filters from the yang model.

This is the filter statement you need in the python script

rtr_filter = '''

<filter>

<routing-state xmlns="urn:ietf:params:xml:ns:yang:ietf-routing"/>

</filter>

'''

What version of code are you running on your 3650?

The filters are derived from YANG modules.  Currently, all of the Cisco YANG modules can be found at yang/vendor/cisco/xe at master · YangModels/yang · GitHub based on version of code.  I wrote a brief blog write-up at Getting To Know YDK that walks through YANG and the YANG Development Kit.  The first part of this talks about YANG itself.  The pyang tool can be very helpful to show the various codes one can use as filters.

Running 16.5.1a

that is the same as for my switch.

I also have a couple of intro blog posts too.  Part2 talks about operational data.

Getting Started with NETCONF/YANG – Part 1

Getting Started with NETCONF/YANG – Part 2

Adam

If you can't get routing oper data from a 3650 (I just have a CSR handy at the moment), try using the IP-FORWAR-MIB:

<IP-FORWAR-MIB xmlns="urn:ietf:params:xml:ns:yang:smiv2:IP-FORWARD-MIB"/>

works for me on 3850.

maybe need to enable oper-data?

Thanks for all the links I will have to read them in due time.

How do I enable operational data?

<IP-FORWAR-MIB xmlns="urn:ietf:params:xml:ns:yang:smiv2:IP-FORWARD-MIB"/>

yields below.
{
    "data": {
        "@xmlns": "urn:ietf:params:xml:ns:netconf:base:1.0",
        "@xmlns:nc": "urn:ietf:params:xml:ns:netconf:base:1.0"
    }
}

C:\Users\mgrous\Google Drive\Glastonbury Lab\Automation\3650>

I forgot the 'D'.  It should be:

<IP-FORWARD-MIB xmlns="urn:ietf:params:xml:ns:yang:smiv2:IP-FORWARD-MIB"/>.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: