Showing results for 
Search instead for 
Did you mean: 

NSO GUI requirements

Cisco Employee
Cisco Employee


Hi there,



I keep seeing questions/requests around the NSO GUI. We have a very small GUI development team, and I would like to solicit input from this forum on how we can get maximum impact.



How do we think GUI impacts our sales? Our theory so far has been that our users don’t and wouldn’t use an NSO GUI for order entry. Can we validate that theory? Do we know of any NSO customers that don’t use some other system in front of NSO? How would such a customer be characterised? Certain size? Certain segment?



We could address our effort towards a number of audiences, e.g.



    1. Pre-sales, towards a buying audience:

      1. Cleaning up the current auto-generated GUI in order to enable demo/POC service models to be driven from a GUI (current top candidate)

      1. Example external GUI portal to enable the demo/POC developer to create a simple custom GUI for order entry (the problem with the current virtual MPLS demo is that the demo GUI is not an example of how we would advise our customers to create a GUI)

    1. Post-sales, for IT, for maintaining the NSO system

      1. Improving the admin GUI – how? Cleaning up GUI for users, credentials (internal/external), devices, device groups

    1. Post-sales, for operations

      1. Device management – device templates, policies, compliance?

      1. Cleaning up current auto-generated GUI? Unlikely that this would be used in operations

      1. Example external GUI portal? More likely candidate IMHO


IMHO, I don’t think a self-service portal should interface with NSO – this scenario would require order management functionality, but I’d be interested in your views on this.



Anything else?







Cisco Employee
Cisco Employee





In followup to this question of NSO API choice, could the NSO team comment as to what they would recommend as the “best API” to adopt given current NSO development roadmap? To be specific, this is for the development of a Web UI to present specific use cases based on NSO service models and workflow.



We currently use REST, but have hit some limitations when it comes to closer interaction with NSO for near real-time updates on device/config status. We have spoken with the EMEAR ADT who are using NETCONF, so are considering moving to that API. However, it would be good to get guidance from the NSO team with regard to future development plans, richness of the available APIs etc.



What the "best API" is for a particular project depends on a many factors besides NSO. E.g. what you are integrating with, the skills of the people involved, etc.



If we look at the most "feature rich API", that would (of course) be naked MAAPI, since that is the low level API that all the others are implemented on top of. This API is only available "on the inside" of the system, however, and I guess your question is about protocol-based APIs.



The management agent with the most features supported would be the JSON-RPC API. This is intended for WebUI applications. It is proprietary, which means it's not portable to any other implementations, but it also means it evolves rather quickly as needed. No need to wait for IETF spec updates.



If you're looking for a standards based API, the most features would be in NETCONF. This is intended for all kinds of applications. Since it's standards based, implementations on it are more portable and there are solid specs for how things work.



Because of the popularity of REST in the developer community at large, IETF has been working for many years on a REST-based variant of the NETCONF protocol, called RESTCONF. While not yet in RFC status, we believe it will reach that state "soon". Since one of the foundational ideas in the REST design pattern is a stateless server (which the WG decided to adhere to), some NETCONF features had to be dropped in RESTCONF. Any operation that depends on a session with the server cannot be represented in a stateless fashion. The WG also wanted RESTCONF to be a simpler protocol to use, so some of the more advanced concepts were removed from this interface (no network wide transactions, only a single datastore, limited namespace support, etc).



Best Regards,




Cisco Employee
Cisco Employee





Below are some pros of using Netconf. Do we have any details comparison of features implemented in JSON RPC vs NetConf. As per current understanding as JSON RPC library is developed by NSO team and keep evolving hence this is kind of superset of implementation in NetConf(which is standard based).







  • The Network Configuration Protocol (NETCONF) is a network management protocol developed and standardized by IETF.
  • Support for robust configuration change using transactions involving a number of devices.
  • NETCONF is a session based protocol.
  • Distinction between configuration and state data
  • Multiple configuration data stores (candidate, running, startup)
  • Configuration testing and validation support
  • Selective data retrieval with filtering
  • Streaming and playback of event notifications
  • Extensible procedure call
  • NETCONF is running over SSH and therefore has security built into the transport.


Cisco Employee
Cisco Employee

At my last company, there was a dev/ops manager that was a ccna, ccnd, and some other certs. While many, if not most of feel that the "power" of configurations come mainly from using cli's and using programming for "glue", there is a strong appeal of having a strong GUI for many operations tasks. The dev/ops manager choose to explore Cisco competitors because they had a much stronger GUI and actually replaced some Cisco gear due to this.

I think that the NSO GUI should at least be strong enough in functionality so that an executive making a purchasing decision can see some bling when comparing to competitors products. IE. You should be able to setup a quick PnP demo for example by adding a device (easily by an operator), adding in some IP addressing pools (easily by operator), and maybe creating a simple config template for IOS. It does not have to be doing a really complicated PnP configuration, but something that can demonstrate the power of NSO and also the potential ease of use once fully configured/programmed.

I have taken the beginning NSO classroom course which I thought was really helpful in getting started and working with NSO demo's, IE. --local-install. I have just started working with the --server-install and live devices and found documentation on the transition a little on the weak side. As a newbie to NSO, I may be off quite a bit as I haven't found the most simply path to finding documentation.  

First impressions are important in many things in life, so I think the GUI is the best way to make a good first impression.

Some of the things I think the NSO GUI should do is:

1) Adding a device easily. It is not difficult to add a device through the cli or through the GUI.

     - Currently there are some bugs in the "Add Devices" GUI process that result in an error. _spinner_WriteThPromise

     - Under devices, choosing "+" vs pulldown menu "Add devices" results in two different screens. It looks like one is to add a real device and fails with above error, and the other is to create a dummy device.

     - Adding a device in the cli requires multiple command line to add the device, and add to a device group.

     - Adding multiple devices at once. I had to write a script to and more than one device, fetch key, sync, add a Compliance service. It was not terrible difficult once I understood a little more of the NSO engine under the hood... but I spent a great deal of time sifting through documentation in order to figure out how simple it was.

2) Deleting a device does not work in the GUI. You must remove it from the device group first or it give an obscure error message "illegal reference". After a while you see the ...device-group, and figure it out. The device does not show in the devices list or the device group list (if it hasn't scrolled off the page because the list is too long. See next item.

You then have to revert, go to the device group, and remove from device-list and members, commit and then delete device.

3) Scrolling through the Device groups does not work. If the list of devices in a group is too long, it just disappears off the page

4) Adding a simple service in the GUI and cli.

5) Maybe working towards the PnP integration of other Cisco products as modules would be helpful. For example, I am planning to explore using Cisco's Estore product for order entry, IE ordering a new CVO for example.

6) NSO should make it rather painless to add devices, get some monitoring and add a compliance report.

Being able to build some sort of compliance report along with the adding devices issue would be extremely helpfully in building a rather quick NSO instance that an end user could could add devices to and set up some compliance/monitoring would be pretty cool. What I envision from the GUI:

     - Add a device or 2 that is fully compliant to your configuration standards

     - Sync from the device

     - Create a basic compliance service based on the device(s) configuration with some prompts on things that may be questionably different.

     - Add 1000 of same devices

     - Run a compliance report on all the devices and clearly show where devices are out of compliance

     - Run a report on configuration changes on the devices vs the cdb

7) Reports/logging

     - The GUI should have a Reporting section that has some basic reporting and logging features.

     - Logging - ability to view all the different logs available configured in ncs.conf

     - NSO configuration changes report

     - User reports

     - System/Performance reports

     - Compliance (based on the above)

     - Device Configuration changes

8) Errors clearly identifiable. If a GUI runs into an error, it needs to be clear about what the error is. You don;t want to be associated with Microsoft's famously ubiquitous errors over the past years. These make the product appear amateur and can bring question to the underlying product. If the GUI cannot perform a task properly, fix it or do not not add the function until it works or at least clearly defines the error.

9) The GUI has many quirks that should not be in any GUI today. Having to resize the screen, for example, in order to see what is suppose to be rendered does not look very professional in today's web based world.

The ASA is a good example of a complicated OS where I use both the GUI (ease of quick monitoring check and some other config items) and the cli when I need the granular power it provides. NSO needs to cater to many audiences, Development, Operators, Management, etc. The GUI is what the non-dev teams will see more of and they can all end up being the deciding factor in the product purchase line.

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: