Practical netconf-yang example using Devnet sandboxes

• provide efficient and easy to use tooling for consumption. i.e. (programming libraries)
• support extensible and open interfaces (REST-based, NETCONF, and others)
• support different encoding formats such as XML and JSON
• support different transports, such as SSH, HTTP, HTTPS

Therefore the *core components of the complete device API includes:

• transport configuration payloads to a device, and a particular configuration datastore on that device.
• retrieve config data when queried
• support notifications, often based on SNMP trap definitions

Netconf views two classes of data, config data (rw) and state data (ro)

NETCONF protocol can be viewed as split in four layers:

NETCONF uses XML Namespaces. They:

• provide a means to mitigate element name conflicts
• defined with the attribute *xmlns:prefix="URI"; where prefix is used as abbreviation of the namespace in the tag.
• having a default namespace using xmlns=url eliminates the need to have an attribute in each tag.

From Cisco training: "Namespaces are present in both, requests and responses. They are especially important inside configuration elements. It is quite possible that there would never be a conflict of XML tags when working with network devices, but you may want to create custom XML objects. In doing so, you have the ability to create a namespace; it essentially becomes an identifier for each XML element. That way, you can read data from more than one source. You can create a larger object and not overwrite an object, because they would still be accessible by their separate namespace."

NETCONF defines datastore that hold config data. They are:

1. running config datastore (the only mandatory one) Holds the complete configuration of what is currently active.
2. candidate config datastore - a workspace before committing.
   • can be altered before commit -ting to running using "<discard-changes>" command.
   • commit takes candidate config datastore into running config datastore.
3. startup config datastore (is read after a reboot)
   • need to explicitly copy running startup
4. backup config datastore
5. others, such as backup-candidate or others….

The existence of these datastore is one of the items described by the device in the cababilites exchange at the beginning of a NETCONF session.

The HELLO message also handles the Capabilities Exchange between the NETCONF server and NETCONF client.

When you start a NETCONF session, you send a HELLO, and exchange capabilities and uses SSH. ~ The server agent will send a "hello" back that looks like some xml with a bunch of capabilities of the remote agent. These will be the YANG models it supports, plus the versions of Netconf it supports.

You could also use python to ask it to "get capabilities". See the script below.

1. Client connects to the NETCONF SSH subsystem.
   • ssh -p 830 cisco@csr-core1 -s netconf
2. Server responds with hello that includes NETCONF-supported capabilities.

   <?xml version="1.0" encoding="UTF-8"?>
   <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:capability:writable-running:1.0</capability>
       <capability>urn:ietf:params:netconf:capability:xpath:1.0</capability>
       <capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
       <capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability>
       <capability>urn:ietf:params:netconf:capability:notification:1.0</capability>
       <capability>urn:ietf:params:netconf:capability:interleave:1.0</capability>
       <capability>http://tail-f.com/ns/netconf/actions/1.0</capability>
       <capability>http://cisco.com/ns/yang/ned/ios?module=ned&amp;revision=2016-06-20</capability>
       <... output omitted ...>
   </capabilities>
   <session-id>203499</session-id></hello>]]>]]>
   

   Notice that ALL messages to and from a NETCONF server end with ]]>]]> This is the NETCONF end of message delimiter.

3. Client responds with a hello too, with supported capabilities to establish a connection.

   <?xml version="1.0"?>
   <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <capabilities>
       <capability>urn:ietf:params netconf:base:1.0</capability>
     </capabilities>
     </hello>]]>]]>
   

4. Client issues a NETCONF request (rpc/operation/content). Right away the client can start sending messages to the server:

   <?xml version="1.0"?>
   <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get>
           <filter type="subtree">
               <native xmlns="http://cisco.com/ns/yang/ned/ios">
                <interface>
                 <GigabitEthernet>
                  <name>1</name>
                 </GigabitEthernet>
                </interface>
               </native>
           </filter>
       </get>
   </rpc>
   ]]>]]>
   

5. Server issues a response or performs operation.

   <?xml version="1.0" encoding="UTF-8"?>
   <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
       <data>
           <native xmlns="http://cisco.com/ns/yang/ned/ios">
             <interface>
              <GigabitEthernet>
               <name>1</name>
               <negotiation>
                 <auto>true</auto>
               </negotiation>
               <ip>
                <address>
                 <primary>
                  <address>192.168.1.11</address>
                  <mask>255.255.255.0</mask>
                 </primary>
                </address>
               </ip>
              </GigabitEthernet>
             </interface>
           </native>
       </data>
   </rpc-reply>]]>]]>
   

Credentials are almost always needed, so I wrote several scripts that can also be called by other scripts as modules, as examples of gaining API programmatica access to Cisco devnet devices.

ncclient is a full Netconf client built on python. ncclient handles keeping track of the message ids for you, handles authentication, handles RPC, and operations. Uses all raw XML.

Within the RPCs they have a bunch of standard operations:

• <get> allows retrieving running and operational data (device state)
• <get-config> allows to get all or part of a configuration data store.
• <edit-config> loads all or part of a configuration data store.
• <copy-config> replace an entire config datastore with another
• <delete-config> delete a config datastore
• <commit> Copy candidate datastore to running datastore
• <lock> / <unlock> so two people won't step on each other's toes in a device
• <close-session> Close the config session gracefully.
• <kill-session> if your buddy went home without unlocking

  Sample python script using the ncclient. (NOT YDK)

  import env_user_zp
  from ncclient import manager
  
  if __name__ == '__main__':
      with manager.connect(host=env_user_zp.IOS_XE1["address"],
               port=env_user_zp.IOS_XE1["port"],
               username=env_user_zp.IOS_XE1["username"],
               password=env_user_zp.IOS_XE1["password"],
               hostkey_verify=False) as m:
  
      print("Here are the NETCONF Capabilities")
      for capability in m.server_capabilities:
          print(capability)
  
  

  A more simple example, that then goes on to download the ietf-ip YANG model:

  from ncclient import manager
  
  m = manager.connect(host='172.24.11.1', port=830, username='admin',
              password='admin', device_params={'name': 'csr'})
  
  print m.server_capabilities
  
  schema = m.get_schema('ietf-ip')
  print(schema)
  
  # but that is just a dump of some XML.  To load that nicer try:
  import xml.etree.ElementTree as ET
  root = ET.fromstring(schema.xml)
  yang_text = list(root)[0].text
  write_file('ietf-ip.yang', yang_text)
  

  With a file now containing the ietf-ip YANG model, we can use pyang to convert the YANG model in this file into another format (among many)

  • pyang -f tree ietf-ip.yang | head -

  From the output you will see that the ietf-ip augments or extends the interface model. It adds new configurable (rw) containers with a list of IP prefixes to be assigned to an interface. Another thing we can see is that this model cannot be used on its own, since it doesn’t specify the name of the interface it augments.

  This model can only be used together with ietf-interfaces YANG model which models the basic interface properties like MTU, state and description. In fact ietf-ip relies on a number of YANG models which are specified as imports at the beginning of the model definition.

  module ietf-ip {
   namespace "urn:ietf:params:xml:ns:yang:ietf-ip";
   prefix ip;
   import ietf-interfaces {
     prefix if;
   }
   import ietf-inet-types {
     prefix inet;
   }
   import ietf-yang-types {
     prefix yang;
   }
  

Each import statement specifies the model and the prefix by which it will be referred later in the document. These prefixes create a clear separation between namespaces of different models.

Remember that the xml config data layout comes from the specific yang data model that we choose to use, in this case the ietf standards yand model.

 from ncclient import manager
 import xmltodict

 # use the filter to narrow down what we are actually looking to retrieve
 interface_filter = """
 <filter>
   <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
     <interface>
       <name>{int_name}</name>
     </interface>
   </interfaces>
 </filter>
 """

with manager.connect(host=core1_ip,
           username=username,
           password=password,
           hostkey_verify=False) as m:

    filter = interfadce_filter.format(int_name = "GigabitEthernet2")
    r = m.get_config("running", filter)

    # process the XML data into Python dictionary and use
    interface = xmltodict.parse(r.xml)
    interface = interface["rpc-repl"]["data"]["interfaces"]["interface"]

    print("The inteface {x} has ip address {y}/{z}".format(
      x = interface["name"]["#text"]
      y = interface["ipv4"]["address"]["ip"]
      z = interface["ipv4"]["address"]["netmask"]
      )
    )

Remember that the xml config data layout comes from the specific yang data model that we choose to use, in this case the ietf standards yand model.

  from ncclient import manager
  import xmltodict

  config_data = """<config>
  <interfaces xmlns="urn:ietf:params:mxl:ns:yang:ietf-interfaces">
     <interface>
    <name>{int_name}</name>
    <description>{description}</description>
    <type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
          ianaift:softwareLoopback
    </type>
    <enabled>true</enabled>
    <ipv4 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
      <address>
        <ip>{ip}</ip>
        <netmask>{netmask}</netmask>
      </address>
    </ipv4>
      </interface>
   </interfaces>
   </config>
   """

# new loobpack info
loopback = {"int_name": Loopback16,
    "description": "Demo looback added using NETCONF",
    "ip": "10.1.1.4",
    "netmask": "255.255.255.0"}

 with manager.connect(host=core1_ip,
        username=username,
        password=password,
        hostkey_verify=False) as m:

     # create desired NETCONF config payload, and aply using "edit_config"
     # remember that config_data is just my template.  I combine that template
     # with the fields from the loobpack dictionary, replacing the curly braces
     # variables in the template with the corresponding values from loopback
     config = config_data.format(**looback)
     r = m.edit_config(target = "running", config = config)

     # print the status message back
     print(f" NETCONF RPC OK: {r.ok}")
     interface = interface["rpc-repl"]["data"]["interfaces"]["interface"]

     print("The inteface {x} has ip address {y}/{z}".format(
       x = interface["name"]["#text"]
       y = interface["ipv4"]["address"]["ip"]
       z = interface["ipv4"]["address"]["netmask"]
       )
     )

—

pyang There may be other tools to pull yang models from devices, but Using pyang is quick and dirty (and efficeint).

You can examine pyang closer now, using python help as follows:

>>> import pyang
>>> dir(pyang)
...
>>> help(pyang.subroutine)  where subroutine is one of the functions
    listed in the output from dir(pyang)
>>> help(pyang.statements)  These are some examples:
>>> help(pyang.types)
>>> help(pyang.grammar)
>>> help(pyang.string)
>>> help(pyang.types)
>>> help(pyang.util)
>>> help(pyang.xpath)

These are like man pages. :) i.e. dir(pyang) while in python.

With pyang installed, you can display a YANG data model to study it. Once you study it you will find the data structure and naming convention you need to accomplish your automation task ( i.e. python code ). From the command line:

pyang -f tree ietf-intefaces.yang pyang -f tree ietf-intefaces.yang # text mode for human consumption

pyang -f jtox ietf-intefaces.yang pyang -f jtox ietf-intefaces.yang # 1 long string that is json format

pyang -f sample-=xml-skeleton ietf-intefaces.yang pyang -f sample-xml-skeleton ietf-intefaces.yang # 1 xml format

pyang -f yin ietf-intefaces.yang pyang -f yin ietf-intefaces.yang # xml format (has some weird "discontinuities" ?

pyang -f jsonxsl ietf-intefaces.yang pyang -f jsonxsl ietf-intefaces.yang # json (was giving me grief on ietf-ospf

I used the output of the jtox command as an input into this interactive python session, so I could convert the yang model as json data.

x = '{"modules": {"ietf-interfaces": ["if",    ...'
y = json.loads(x)
type(y) 
dict
print(y)  etc.

-f FORMAT, –format=FORMAT Convert to FORMAT. Supported formats are: yang, yin, dsdl, omni, tree, jstree, flatten, uml, identifiers, sample-xml-skeleton, capability, jsonxsl, depend, jtox, name

pyang is written in python and can be used in python, but pyang is also a shell command.

A good, straight-foward way of displaying YANG data models is

• pyang -f tree ietf-intefaces.yang which shows the data as text
• pyang -f jstree ietf-interfaces.yang which shows the data as html.

To get a subset of the whole tree you can use:

• pyang -f tree --tree-path=/interfaces/interface gietf-intefaces.yang
• pyang -f tree --tree-path=/interfaces/interface gietf-intefaces.yang
• pyang -f tree --tree-path=/interfaces/interface gietf-intefaces.yang

Please notice in the following example, that this YANG model has two containers, One called ietf-interfaces the other called interface-state

Please also notice that in the first container we have a list of interfaces, that are read-write, rw And, in the second container we have a list of statistics that are read-only, ro This shows how we can separate configuration and operational information inside of YANG

The list is designated by the [] - which contains the key. So we can differentiate one entry in a list from another. Here we key off of "name".

Note that in YANG Data Models, "Leaf" means something else to "Leaf Switch". Leaf here really means only *

A ? means it is an optional attributes.

Finally, notice that every leaf has a specified data type, eg. string, boolean, int32, date-and-time

% pyang -f tree ietf-interfaces.yang 

module: ietf-interfaces
+--rw interfaces       
|  +--rw interface* [name]
|     +--rw name                        string
|     +--rw description?                string
|     +--rw type                        identityref
|     +--rw enabled?                    boolean
|     +--rw link-up-down-trap-enable?   enumeration {if-mib}?
|     +--ro admin-status                enumeration {if-mib}?
|     +--ro oper-status                 enumeration
|     +--ro last-change?                yang:date-and-time
|     +--ro if-index                    int32 {if-mib}?
|     +--ro phys-address?               yang:phys-address
|     +--ro higher-layer-if*            interface-ref
|     +--ro lower-layer-if*             interface-ref
|     +--ro speed?                      yang:gauge64
|     +--ro statistics
|        +--ro discontinuity-time    yang:date-and-time
|        +--ro in-octets?            yang:counter64
|        +--ro in-unicast-pkts?      yang:counter64
|        +--ro in-broadcast-pkts?    yang:counter64
|        +--ro in-multicast-pkts?    yang:counter64
|        +--ro in-discards?          yang:counter32
|        +--ro in-errors?            yang:counter32
|        +--ro in-unknown-protos?    yang:counter32
|        +--ro out-octets?           yang:counter64
|        +--ro out-unicast-pkts?     yang:counter64
|        +--ro out-broadcast-pkts?   yang:counter64
|        +--ro out-multicast-pkts?   yang:counter64
|        +--ro out-discards?         yang:counter32
|        +--ro out-errors?           yang:counter32
x--ro interfaces-state
   x--ro interface* [name]
      x--ro name               string
      x--ro type               identityref
      x--ro admin-status       enumeration {if-mib}?
      x--ro oper-status        enumeration
      x--ro last-change?       yang:date-and-time
      x--ro if-index           int32 {if-mib}?
      x--ro phys-address?      yang:phys-address
      x--ro higher-layer-if*   interface-state-ref
      x--ro lower-layer-if*    interface-state-ref
      x--ro speed?             yang:gauge64
      x--ro statistics
         x--ro discontinuity-time    yang:date-and-time
         x--ro in-octets?            yang:counter64
         x--ro in-unicast-pkts?      yang:counter64
         x--ro in-broadcast-pkts?    yang:counter64
         x--ro in-multicast-pkts?    yang:counter64
         x--ro in-discards?          yang:counter32
         x--ro in-errors?            yang:counter32
         x--ro in-unknown-protos?    yang:counter32
         x--ro out-octets?           yang:counter64
         x--ro out-unicast-pkts?     yang:counter64
         x--ro out-broadcast-pkts?   yang:counter64
         x--ro out-multicast-pkts?   yang:counter64
         x--ro out-discards?         yang:counter32
         x--ro out-errors?           yang:counter32
/Users/zintis/bin/python/netprog_basics/network_device_apis/yang/yang/standard/ietf/RFC[61] % 

Better to use a picture:

YANG Model a clickable link to a picture. This is the same thing inline:

Or from my pyang outputed ietf-interfaces.yang file

You can also see a graphical map of YANG models at https://yangcatalog.org/

I have created a python virtual environment called "venv-yang". There I have pip install pyang Then activate venv-pang Then realize there is a pyang binary in the venv bin file Create alias pyng that points to pyang in .cshrc Open http://www.yang-central.org/twiki/pub/Main/YangTools/pyang.1.html#man.1.pyang.output_formats and open http://www.yang-central.org/twiki/pub/Main/YangTools/pyang.1.html

to see the pyang options

using the alias, run pyang -f tree top.yang (and whatever else .yang file you want) Also see that emacs does a nice job highlightin the .yang syntax files as well.

NETCONF as a protocol only supports XML as the data format.

The "Agent" running on the device is typically called netconfd and is so on cisco devices.

Insert these notes:

Netconf actaully uses ssh RFCs and Drafts NETCONF RFC 6241 RFC 4741 YANG RFC 7950 RFC 6020 RESTCONF RFC 8040 gRPC grpc.io

m = manager.connect(host=env_lab.IOSXE1["host"], port=env_lab.IOSXE1["netconf_port"], username=env_lab.IOSXE1["username"], password=env_lab.IOSXE1["password"], hostkey_verify=False )

• simplify app development
• abstract transport, encoding, modeling language
• API generated from the YANG model
• one to one correspondence between model and class heirarchy
• multiple languages (Python, C++, Ruby, Go …)
• client side validations

YDK consists of a core package that defines services and providers, plus one or more module bundles that are based on YANG models.

Each module bundle is generated using a bundle profile with YDK-gen and contains definitions for data objects.

The key is that YDK combines data objects with services and providers

So YDK has:

1. Models that group Python objects created for each YANG model (autogenerated)
2. Services perform operations on model objects using providers
3. Providers implement services over different protocols.

This allows one to isolate the code for a provider (i.e. implementation) from code for a service (i.e. operations). So you can create a python script for netconf and quite easily swap it out for restconf. The code should not need to change much.

(Alternative approaches is to use Ansible Netconf modules. But that is not what I am covering here.)

The best place to start is https://developer.cisco.com/site/ydk/ You will see a great example python script that uses YDK: (and netconf actually)

# A YDK Hello World!
# import models, services and providers (mnemonic: model service provider)
from ydk.models.cisco_ios_xr import Cisco_IOS_XR_shellutil_oper \
    as xr_operator_model
from ydk.services import CRUDService
from ydk.providers import NetconfServiceProvider

from datetime import timedelta

if __name__ == "__main__":
    """Main execution path"""

    # create system time object using MODEL
    system_time = xr_operator_model.SystemTime()

    # create CRUD service using SERVICE
    crud = CRUDService()

    # create NETCONF session using PROVIDER
    provider = NetconfServiceProvider(address="10.0.0.1",
                      port=830,
                      username="admin",
                      password="admin",
                      protocol="ssh")
    # read system time from device
    system_time = crud.read(provider, system_time)

    # Print system time
    print("System uptime is " +
      str(timedelta(seconds=system_time.uptime.uptime)))

    # close NETCONFIG session and exit
    provider.close()
    exit()

Let's see that same file in a native file type: file:///Users/zintis/bin/python/bin/ydk-hello-world.py

YDK lets you feed it a YANG model and have it generate sample code. Of note:

• from ydk.services import CRUDService
• from ydk.providers import NetconfServiceProvider
• from ydk.models.cisco_ios_xr import Cisco_IOS_XR_shellutil_oper as xr_operator_model

And

• zprovider = NetconfServiceProvider(address="10.0.0.1", port=830, username...)
• zpservice = CRUDService()
• mytime = zpservice.read(provider, system_time)

From developer.cisco.com I have copied the crucial description here:

The generated YDK APIs have three main components:

Models: Class hierarchies that mirror the hierarchies that the YANG models specify. We bundle models (e.g. Cisco IOS XR, OpenConfig, IETF, etc) in separate packages, so users can have granular control of the model families that they install.

Services: Classes that perform an action on model objects. They include a CRUD (create, read, update, delete) service that abstracts management protocols, services that provide direct access to protocols (e.g. NETCONF and RESTCONF), a service to encode and decode (serialize and deserialze) data, plus others.

Providers: Classes that implement a service. A provider can implement multiple services and multiple providers can implement a service.

See it in action in file:///Users/zintis/bin/python/bin/netconf-example1.py I did NOT install this large YDK package on my laptop. Rather, I took the advice of the README file in the /ydk directory of the docker container I booted up. To run the docker container run ~docker run -it ydkdev/ydk-py

• docker run -it ydkdev/ydk-py

The catalyst / nexus cisco switch has to have netconf-yang configured before any netconf clients will be able to access the cisco netconf server:

netconf-yang —> Enable NETCONF/YANG globally. (~ 90 seconds to initialize)

username cisco1 privilege 15 password 0 cisco1 —> Username/password used for NETCONF-SSH access

3850-1# show running-config

snmp-server community <string> RW

netconf-yang cisco-ia snmp-community-string <string>

snmp-server trap link ietf

snmp-server enable traps snmp authentication linkdown linkup

snmp-server enable traps syslog

snmp-server manager

this configuration must be present for the Data Model Interface (DMI) on the Catalyst 3850 to have the ability to generate NETCONF notifications defined in RFC 5277 when Syslog messages are generated by IOSd on the Catalyst 3850.

logging history debugging

logging snmp-trap emergencies

logging snmp-trap alerts logging snmp-trap critical logging snmp-trap errors logging snmp-trap warnings logging snmp-trap notifications logging snmp-trap informational logging snmp-trap debugging

this configuration is required to generate NETCONF notifications. In IOS-XE 16.3.1 software a maximum of 10 SNMP traps can be configured to generate NETCONF notificationss but this restriction will be removed in a future release. Notification generation for SNMP traps is enabled by default. To disable generating SNMP trap notifications use this CLI no netconf-yang cisco-ia snmp-trap-control global-forwarding”

netconf-yang cisco-ia snmp-trap-control trap-list 1.3.6.1.6.3.1.1.5.3

netconf-yang cisco-ia snmp-trap-control trap-list 1.3.6.1.6.3.1.1.5.4

netconf-yang cisco-ia snmp-trap-control trap-list 1.3.6.1.4.1.9.9.41.2.0.1

1. Network Connectivity Configuration of the Catalyst 3850 Used in this Example

The Catalyst 3850 management interface GigabitEthernet0/0 is used to connect to the network and to the centralized management platform (a laptop will be used) in this example. Dynamic Host Configuration Protocol (DHCP) has been used to assign IP address 172.16.167.175 to this interface. Alternate configurations can be used on the Catalyst 3850 as long as the laptop can reach the Catalyst 3850 on the Network.

3850-1# show running-config 

vrf definition Mgmt-vrf 
 ! 
 address-family ipv4 
 exit-address-family 
 ! 
 address-family ipv6 
 exit-address-family 

interface GigabitEthernet0/0 
 vrf forwarding Mgmt-vrf 
 ip address dhcp 
 negotiation auto 

ip route vrf Mgmt-vrf 0.0.0.0 0.0.0.0 172.16.167.161 

3850-1# show ip interface brief  

Interface              IP-Address      OK? Method Status Protocol 
Vlan1                  1.1.1.1         YES NVRAM  up     up  
Vlan10                 10.10.10.1      YES NVRAM  up     up  
Vlan20                 20.20.20.1      YES NVRAM  up     up  
GigabitEthernet0/0     172.16.167.175  YES DHCP   up     up  
Fo1/1/1                unassigned      YES unset  down   down  
Fo1/1/2                unassigned      YES unset  down   down  
GigabitEthernet1/0/1   unassigned      YES manual up     up  
GigabitEthernet1/0/2   unassigned      YES unset  up     up  
GigabitEthernet1/0/3   unassigned      YES unset  down   down  
GigabitEthernet1/0/4   unassigned      YES unset  down   down  
GigabitEthernet1/0/5   unassigned      YES unset  down   down 

Verify NETCONF/YANG on the Catalyst 3850

1. From the Command Line Interface (CLI) of the Catalyst 3850, this command can be used to ensure that the software processes required to support the Data Model Interface (DMI) on the Catalyst 3850 run once netconf-yang is configured.

3850-1# show platform software yang-management process

• confd : Running
• nesd : Running
• syncfd : Running
• ncsshd : Running
• dmiauthd : Running
• vtyserverutild : Running
• opdatamgrd : Running
• ngnix : Running

  The next steps are performed from the centralized management platform. In this example, a laptop (Apple MacBook Pro running macOS Sierra 10.12.2) is used that has network access to the Catalyst 3850. The commands are issued from a terminal prompt on the laptop. There is no special application loaded on the laptop at this point.

• Ensure that the centralized management platform (laptop) can reach the Catalyst 3850 (172.16.167.175) on the network. (ping should do)

USER1-M-902T:~ USER1$ ping 172.16.167.175  

PING 172.16.167.175 (172.16.167.175): 56 data bytes 
64 bytes from 172.16.167.175: icmp_seq=0 ttl=247 time=3.912 ms 
64 bytes from 172.16.167.175: icmp_seq=1 ttl=247 time=6.917 ms 
64 bytes from 172.16.167.175: icmp_seq=2 ttl=247 time=4.063 ms 
64 bytes from 172.16.167.175: icmp_seq=3 ttl=247 time=4.371 ms 
^C

1. Verify SSH connectivity to the Catalyst 3850 (172.16.167.175 in this example) from the centralized management platform (laptop) with the username and password (cisco1/cisco1) from the above Catalyst 3850 configuration. The response will be a long list of NETCONF capabilities from the Catalyst 3850 followed by a hello message. TCP port 830 = netconf-ssh.

   Tip: If this SSH test does not work, ensure that any firewall in between the

   laptop and Catalyst 3850 permits TCP port 830 (reference RFC 4742: https://tools.ietf.org/html/rfc4742).

USER1-M-902T:~ USER1$ ssh -s cisco1@172.16.167.175 -p 830 netconf 
cisco1@172.16.167.175’s password: cisco1
<?xml version="1.0" encoding="UTF-8"?>
<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>
<capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
<capability>urn:ietf:params:netconf:capability:xpath:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
<capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability
--snip--
</capabilities>
<session-id>2870</session-id></ hello>]]>]]>

 Use < ^C > to exit