Getting Started with NETCONF/YANG – Part 1 - Page 2

aradford · ‎01-04-2017

Introduction

Cisco has recently introduced NETCONF/YANG support across the enterprise network portfolio. This capability is available in the 16.3 XE code for routers and switches. NETCONF/YANG allows programmatic access to network devices using structured data.

I have had a number of questions from customers looking to get started with NETCONF/YANG, which I will address here.

To keep it practical, we will end up using NETCONF/YANG to programmatically change the vlan membership for a switch interface.

Getting Started

Many of you will know that Cisco has had IOS support for NETCONF since 2004. The 2004 version did not really have a data model and was just using NETCONF for transport. You still needed to send/receive CLI chunks as text, which was similar to just SSH-ing into the device and running commands directly. (NOTE: technically there were a few small differences, but I am not going into them here J)

The 2016 version of NETCONF uses YANG to structure the data that is sent and received, which makes is much simpler to work with programatically. In the past, you would need to "screen scrape" CLI with regular expressions to extract specific pieces of information.

To enable the NETCONF, a single command is required. These examples are using a 3850 switch running 16.3.2 code.

3850-remote#conf t

Enter configuration commands, one per line. End with CNTL/Z.

3850-remote(config)#netconf-yang

Testing the transport

NETCONF uses SSH as a transport, so one of the simplest ways to see how it works is to SSH to the device. I can simply use the ssh command and connect to port 830 (the default NETCONF port).

$ ssh -p 830 sdn@10.10.6.2

sdn@10.10.6.2's password:

Enter a password and there will be a large slab of XML in response. This has been <SNIPPED/> for brevity

<?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>

<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://tail-f.com/ns/netconf/extensions</capability>

<capability>urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=report-all</capability>

<capability>urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults?revision=2011-06-01&module=ietf-netconf-with-defaults</capability>

<capability>http://cisco.com/ns/yang/ned/ios?module=ned&revision=2016-09-19&deviations=ned-switching-devs</capability>

16</capability>

<SNIPPED/>

<capability>urn:ietf:params:xml:ns:yang:smiv2:VPN-TC-STD-MIB?module=VPN-TC-STD-MIB&revision=2005-11-15</capability>

</capabilities>

<session-id>19150</session-id></hello>]]>]]>

The key point here is that this is a <hello> message from the NETCONF device, containing a list of <capabilities>. The capabilities contain all of the YANG models that the device supports.

NOTE: the delimiter string ]]>]]> at the end of the response signifies the end of the message. You would need to use this string to indicate the end of any message you send back.

To continue the session, you would need to respond to the hello with a list of capabilities that you support. The simplest response is below. Remember the delimiter string (]]>]]>).

<?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>

</capabilities>

</hello>]]>]]>

You will not see a response, which is expected. You can now send NETCONF commands. The following example will return the running configuration.

<?xml version="1.0"?>

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

message-id="101">

<get-config>

<source>

<running/>

</source>

</get-config>

</rpc>]]>]]>

You will get an XML response that contains the full configuration.

<?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"><device-model-version><major>2</major><minor>1</minor><bug-fix>0</bug-fix></device-model-version><version>16.3</version><boot><system><switch><all><flash>packages.conf</flash></all></switch></system></boot><service><password-recovery>false</password-recovery><timestamps><debug><datetime><msec/></datetime></debug><log><datetime><msec/></datetime></log></timestamps><compress-config/></service><hostname>3850-remote</hostname>

<SNIPPED/>

You can pass this through an XML formatter to get a structured view:

<?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">

            <device-model-version>

                <major>2

                </major>

                <minor>1

                </minor>

                <bug-fix>0

                </bug-fix>

            </device-model-version>

            <version>16.3

            </version>

            <boot>

                <system>

                    <switch>

                        <all>

                            <flash>packages.conf

                            </flash>

                        </all>

                    </switch>

                </system>

            </boot>

            <service>

                <password-recovery>false

                </password-recovery>

                <timestamps>

                    <debug>

                        <datetime>

                            <msec/>

                        </datetime>

                    </debug>

                    <log>

                        <datetime>

                            <msec/>

                        </datetime>

                    </log>

                </timestamps>

                <compress-config/>

            </service>

            <hostname>3850-remote

            </hostname>

<SNIPPED/>

Using a NETCONF tool

There are a number of tools that simplify interacting with NETCONF. One of my favourites (as it still exposes the underlying semantics of the protocol, which I think is important when learning) is netconf-console. You can download it from https://github.com/OpenNetworkingFoundation/configuration/tree/master/netconf-console

The file was renamed to netconf-console.py. In the examples below, an explicit host, username, password and the netconf port were specified. You can edit the netconf-console.py file to change the default username, password and port to make testing easier.

The operation that is being run here is just "hello", so will return a list of capabilities from the device. This will be identical to the first step in the earlier SSH example.

$ ./netconf-console.py --host=10.10.6.2 -u sdn -p password --port 830

--hello

Similar to the earlier example, the get-config command can be used, and this time the XML response will be pretty-printed.

$ ./netconf-console.py --host=10.10.6.2 -u sdn -p password --port 830 --get-config

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

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

<data>

    <native xmlns="http://cisco.com/ns/yang/ned/ios">

      <device-model-version>

<major>2</major>

<minor>1</minor>

<bug-fix>0</bug-fix>

      </device-model-version>

<version>16.3</version>

      <boot>

        <system>

          <switch>

            <all>

<flash>packages.conf</flash>

            </all>

          </switch>

        </system>

      </boot>

<SNIPPED/>

Why Models

The earlier NETCONF responses were XML. This is known as structured data. The reason this is important is it is very easy for software to parse and understand. XML tags are used to mark-up or describe the data they contain. For example <major>2</major> denotes an attribute "major" with a value of 2. NOTE <tag> is the start and </tag> is the end.

XML is also hierarchical, <major>2</major> is contained in the <device-model-version> tag. We know that the device-model-version/major is 2. Other attributes of device-model-version include minor and bug-fix.

Software engineers like hierarchical trees. These are easy to search, sort and scale. XML tags define a tree-like structure, with a root, branches and leaves. In the example above <major>2</major> is a leaf as it only contains data, not other XML constructs. YANG can be mapped easily into XML. We will cover YANG in a future blog.

As seen in the earlier example, a full device configuration may be quite large. In my case it was nearly 3000 lines. Some of this is due to the overhead of XML, but it is still a lot of data. Here is where trees/XML can help due to filtering.

A filter can be used to specify a subset of the configuration. For example, if you are only interested in the configuration of the interfaces on the device. This is achieved with the -x "interfaces" option. "-x" means XPATH for those familiar with XML.

This time only the interface specific configuration is returned (386 lines, vs 3000 lines for full configuration for my example).

$ ./netconf-console.py --host=10.10.6.2 -u sdn -p password --port 830 --get-config -x "interfaces"

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

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

<data>

    <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">

        <interface>

        <name>GigabitEthernet1/0/1</name>

        <description>uplink to router</description>

        <type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:ethernetCsmacd</type>

        <enabled>true</enabled>

        <diffserv-target-entry xmlns="urn:ietf:params:xml:ns:yang:ietf-diffserv-target">

<direction>outbound</direction>

<policy-name>EasyQos-Egress</policy-name>

        </diffserv-target-entry>

        <ipv4 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">

          <address>

            <ip>10.10.6.2</ip>

<netmask>255.255.255.0</netmask>

          </address>

        </ipv4>

        <ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip"/>

      </interface>

      <interface>

        <name>GigabitEthernet1/0/10</name>

        <description>802.1x host</description>

<SNIPPED/>

Filters can be used to drill down as deep as you like. In this example, only the configuration of interface GigabitEthernet1/0/1 is returned. The following filter interfaces/interface[name='GigabitEthernet1/0/1'] achieves this.

"name" is a key, and has a value of "GigabitEthernet1/0/1" [name='GigabitEthernet1/0/1']. NOTE: the name is case sensitive.

For the first time I do not need to truncate the output.

$ ./netconf-console.py --host=10.10.6.2 -u sdn -p password --port 830 --get-config -x "interfaces/interface[name='GigabitEthernet1/0/1']"

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

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

<data>

    <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">

      <interface>

        <name>GigabitEthernet1/0/1</name>

        <description>uplink to router</description>

        <type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:ethernetCsmacd</type>

        <enabled>true</enabled>

        <diffserv-target-entry xmlns="urn:ietf:params:xml:ns:yang:ietf-diffserv-target">

          <direction>outbound</direction>

<policy-name>EasyQos-Egress</policy-name>

        </diffserv-target-entry>

        <ipv4 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">

          <address>

            <ip>10.10.6.2</ip>

            <netmask>255.255.255.0</netmask>

          </address>

        </ipv4>

        <ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip"/>

      </interface>

    </interfaces>

</data>

</rpc-reply>>

This example takes this one step further by just returning the description attribute for a specific interface. NOTE: the "name" attribute is also returned, as it is the key (details on why this is the case will be explained in a future blog).

$ ./netconf-console.py --host=10.10.6.2 -u sdn -p password --port 830 --get-config -x "interfaces/interface[name='GigabitEthernet1/0/1']/description"

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

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

<data>

    <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">

      <interface>

        <name>GigabitEthernet1/0/1</name>

        <description>uplink to router</description>

      </interface>

    </interfaces>

</data>

</rpc-reply>

Another example of the power of filters is restricting to a set of leaves. In this example the search is restricted to get the description for all interfaces. Only interfaces with descriptions are returned.

$ ./netconf-console.py --host=10.10.6.2 -u sdn -p password --port 830 --get-config -x "interfaces/interface/description"

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

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

<data>

    <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">

      <interface>

        <name>GigabitEthernet1/0/1</name>

        <description>uplink to router</description>

      </interface>

      <interface>

        <name>GigabitEthernet1/0/10</name>

        <description>802.1x host</description>

      </interface>

      <interface>

        <name>GigabitEthernet1/0/4</name>

        <description>IP Phone test</description>

      </interface>

    </interfaces>

</data>

</rpc-reply>

This is a great example of why structured data (models) is important. If I was to try to do this from CLI, I could use the following, but i still need to filter/regexp the relevant information:

3850-remote#show run | inc Gigabit|desc

description Topology control

description DHCP snooping, show forward and rest of traffic

description Learning cache ovfl, Crypto Control, Exception, EGR Exception, NFL SAMPLED DATA, Gold Pkt, RPF Failed

description Wireless priority 1

description Wireless priority 2

description Wireless priority 3,4 and 5

description Routing control

description Protocol snooping

interface GigabitEthernet0/0

interface GigabitEthernet1/0/1

description uplink to router

interface GigabitEthernet1/0/2

interface GigabitEthernet1/0/3

interface GigabitEthernet1/0/4

description IP Phone test

interface GigabitEthernet1/0/5

interface GigabitEthernet1/0/6

interface GigabitEthernet1/0/7

interface GigabitEthernet1/0/8

interface GigabitEthernet1/0/9

interface GigabitEthernet1/0/10

description 802.1x host

<SNIPPED/>

How to configure a VLAN?

Notice there is no configuration for vlan membership in the example above. We are using the standard ietf-interfaces model, and this does not (currently) include vlan membership.

More advanced features are modelled in the "native" model. The native model interface structure is slightly different to the standard model. The interface name is very different. Instead of the name being "GigabitEthernet0/0" there is a container for "GigabitEthernet" and the name is simply "0/0".

To get all interfaces, the filter is just "native/interface" instead of "interfaces/interface" with the standard model.

$ ./netconf-console.py --host=10.10.6.2 -u sdn -p sdn123 --port 830 --get-config -x "native/interface"

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

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

<data>

    <native xmlns="http://cisco.com/ns/yang/ned/ios">

      <interface>

        <GigabitEthernet>

          <name>0/0</name>

          <negotiation>

            <auto>true</auto>

          </negotiation>

          <vrf>

<forwarding>Mgmt-vrf</forwarding>

          </vrf>

          <ip>

            <no-address>

<address>false</address>

            </no-address>

          </ip>

        </GigabitEthernet>

        <GigabitEthernet>

<SNIPPED/>

To get the configuration of a specific interface 1/0/10:

$ ./netconf-console.py --host=10.10.6.2 -u sdn -p sdn123 --port 830 --get-config -x "native/interface/GigabitEthernet[name='1/0/10']"

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

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

<data>

    <native xmlns="http://cisco.com/ns/yang/ned/ios">

      <interface>

        <GigabitEthernet>

          <name>1/0/10</name>

          <switchport>

            <access>

              <vlan>

                <vlan>30</vlan>

              </vlan>

            </access>

            <mode>

              <access/>

            </mode>

          </switchport>

          <authentication>

<host-mode>multi-auth</host-mode>

          </authentication>

          <spanning-tree>

            <portfast/>

          </spanning-tree>

          <description>802.1x host</description>

          <service-policy>

<output>EasyQos-Egress</output>

          </service-policy>

</GigabitEthernet>

      </interface>

    </native>

</data>

</rpc-reply>

Looking at interface 1/0/9, there is currently no vlan defined.

$ ./netconf-console.py --host=10.10.6.2 -u sdn -p sdn123 --port 830 --get-config -x "native/interface/GigabitEthernet[name='1/0/9']"

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

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

<data>

    <native xmlns="http://cisco.com/ns/yang/ned/ios">

      <interface>

        <GigabitEthernet>

          <name>1/0/9</name>

          <switchport>

            <mode>

              <access/>

            </mode>

          </switchport>

          <service-policy>

<output>EasyQos-Egress</output>

          </service-policy>

        </GigabitEthernet>

      </interface>

    </native>

</data>

</rpc-reply> </data>

</rpc-reply>

I create a file /tmp/edit with the changes I want to make to interface 1/0/9. I want to change the access vlan to vlan 30.

$ cat /tmp/edit

<native xmlns="http://cisco.com/ns/yang/ned/ios">

      <interface>

        <GigabitEthernet>

          <name>1/0/9</name>

          <switchport>

            <access>

              <vlan>

                <vlan>30</vlan>

              </vlan>

            </access>

          </switchport>

        </GigabitEthernet>

      </interface>

    </native>

This change can be applied by using the edit-config RPC. It returns successfully.

$ ./netconf-console.py --host=10.10.6.2 -u sdn -p password --port 830 --edit-config=/tmp/edit

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

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

<ok/>

</rpc-reply>

I can now verify the switchport/access/vlan configuration for interface 1/0/9. It has been changed to vlan 30.

$ ./netconf-console.py --host=10.10.6.2 -u sdn -p password --port 830 --get-config -x "native/interface/GigabitEthernet[name='1/0/9']/switchport/access/vlan"

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

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

<data>

    <native xmlns="http://cisco.com/ns/yang/ned/ios">

      <interface>

        <GigabitEthernet>

          <name>1/0/9</name>

          <switchport>

            <access>

              <vlan>

                <vlan>30</vlan>

              </vlan>

            </access>

          </switchport>

        </GigabitEthernet>

      </interface>

    </native>

</data>

</rpc-reply>

Summary

This blog post has shown some basic ways to interact with NETCONF/YANG in Cisco IOS-XE 16.3.2. The following concepts have been explored:

- SSH and netconf-console to interact with a network device
- Model driven data access with XPATH filters
- "get-config" and "edit-config" RPC calls.
- IETF standard and "native" configuration models

What Next?

In the meantime, if you would like to learn more about this, you could come hang out with us in The Cisco Devnet DNA Community. We’ll have a continuous stream of blogs like this and you can ask questions and we’ll get you answers.

Future blogs will contain more details of NETCONF/YANG, operational vs configuration data and other tools/python libraries you can use to interface via NETCONF. Check out Getting Started with NETCONF/YANG – Part 2

Thanks for reading,

@adamradford123

sofianecirat · ‎04-16-2017

GREAT POST Adam....Always, on the forefront.

Clear, and concise.

A question. I saw the netconf command on 2960 switches, and other IOS switches, and routers. But I'm reading that netconf is only supported so far, on the IOS XE, NX-IOS, ASR 9000.

Can you elaborate on that.

Thanks,

Jason Belk · ‎04-16-2017

If you look at some of the IOS 15 netconf command examples and try it out on an actual device:

Cisco Networking Services Configuration Guide, Cisco IOS Release 15M&T - NETCONF over SSHv2 [Support] - Cisco

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/cns/configuration/15-s/cns-15-s-book/cns-netconf.html

netconf is there for IOS 15, not XE, but you can only do basic commands like get config etc (see above links, you can also send a NETCONF command to get the advertised list of options, which is tiny). No yang support or advanced granular NETCONF commands until IOS 16.3 or IOS 16.5, unless I am mistaken. The only way to apply yang templates and do programmatic access to traditional IOS devices is through a controller such as NSO or APIC-EM.

aradford · ‎04-16-2017

Netconf has been in IOS since 2005. The challenge was the "old" netconf was just transport, it did not have any of the YANG models. Without a data model (YANG) you just push/receive CLI.

Newer versions of IOS support "netconf-yang" this uses structured YANG models which becomes much more useful as you do not need regular expressions.

Adam

sofianecirat · ‎04-18-2017

Thanks Jason. Great Info.

sofianecirat · ‎04-18-2017

Thanks, Adam.

dimaturana · ‎05-17-2017

Good Morning Jason,

I'm glad to find this community

Actually i'm working with NSO 4.4, i got the connection to my devices by packages Discovery and the specific CLI NED package for each kind of IOS. I can change the configurations by the GUI, etc. I'm just trying with one VRF to start and everything was working OK.

Now, i wanna work with Netconf, so after check a little the options on devices and your comments i realized that not all of my devices will be ready to work on it. I have IOS, IOS-XE and IOS-XR in my lab.

Ther are one link to discuss about NSO specifically? Is NSO a controller to, or just one orchestrator? i'm actually working in my memory to get my master degree.

Thanks from now for your help and comments.

BR

Diego Maturana

dimaturana · ‎05-18-2017

Good morning for everyone,

I'm not so sure if i can make this question here but i didn't see another place...

I'm Working with NSO but i have a doubt, can i manage cisco devices by Netconf in this case or i'm forced to use NED CLI?

I ask that because i can get a connection by netconf from one linux machine but not from my orchestrator NSO 4.4, i got this message:

Device PE2 does not advertise any known YANG modules

Device:

ASR9000

IOS-XR 6.1.2

Thanks from now for your help,

Diego Maturana

Joe Clarke · ‎05-18-2017

This code does support NETCONF with YANG-based models. Do you have the NETCONF server enabled? See Cisco ASR 9000 Series Aggregation Services Router System Security Configuration Guide, Release 5.3.x - Implementing the… for what is required from a config standpoint. Then you should be able to SSH to port 830 (the default) to see the capabilities supported by the device. In fact, all of Adam's blog above would then apply to your 9K.

einarnn · ‎05-18-2017

Diego,

You don't need to use a CLI-based NED with the ASR9000 running IOS-XR 6.1.2 or later.

Once you've configured the device for netconf/yang per the link Joe provided, you still need to build a YANG-model-based NED for NSO. At that point you should be able to manage your ASR9000 from NSO. Please note that some of the openconfig models advertised by the ASR9000 will not correctly compile in NSO, so you will have to exclude them from your NED.

Please refer to NSO user guides for how to build a YANG model NED.

Cheers,

Einar

dimaturana · ‎05-19-2017

Good morning,

Firstly, so thanks for your answers and informations.

1- For the configuration of NETCONF in the ASR9000 is ok, in fact i can get a connection from a Linux Machine to him, but NO from my orchestrator NSO. (Thanks Joseph).

2 - I added my device without the discovery package and i fixed it to device-type NETCONF.

Einar,

When you said that i need to build a YANG-model-based NED for NSO, do you mean that i need to code all the NED?

I ask to you because in the docs that i have i had read this:

When the device supports YANG and NETCONF natively, the device manager is totally automatic. Non-NETCONF devices are integrated using the Network Element Driver (NED) toolkit.

Thanks from now for your comments,

BR

Diego Maturana.

einarnn · ‎05-23-2017

Diego,

There should be no coding required, but I’m not an expert

The process of building a NED for YANG-enabled devices is, I believe, largely automated, but because of some problems with both some of the device models and with NSO, sometimes manual intervention is required to get a NED built.

Cheers,

Einar

dimaturana · ‎05-24-2017

Hi Einar,

Thanks for your time and answers.

For me there are something that i can't see, i've been reading the docs that i have but sadly they don't arrive at a deep level like how do the rights configurations between the node and NSO with NETCONF.

I'm using NSO 4.4 with one ASR9000 with IOS-XR 6.1.2.

If i try to connect to the node from one linux machine i can get the capabilities with the hello message and keep the connection, but with NSO i get just that he don't know the modules YANG advertised by the node (so i think that i got a connection but NSO don't know the Yang models advertised by the node so the session is push to close-session.

Do you know someone that could help me?

I'd love to discuss with more people that are still working with NSO but i can't find the right place or discussion i guess.

Thanks one more time for your comments,

Diego Maturana

einarnn · ‎05-24-2017

Diego,

Try:

https://communities.cisco.com/community/developer/nso-developer-hub

Cheers,

Einar

dimaturana · ‎05-29-2017

Good morning Einar,

So thanks for your link, sadly i don't have the permissions to see it. Can i request the acces to somone?

Thanks for your help and have a nice week.

Diego Maturana

einarnn · ‎06-05-2017

Diego,

That link should be available to anyone registered with developer.cisco.com as far as I am aware. Were you logged in to developer.cisco.com when you tried to access it?

Cheers,

Einar