Showing results for 
Search instead for 
Did you mean: 

How to automate port turnup with NSO

Cisco Employee

Do you need to automate port turn up in your network?


If the answer to this question is “yes” then you may have an easy solution through NSO (Network Service Orchestrator). Cisco Advanced Services has developed a NSO-based package that can automate the port turn up process in your network.


What are the supported Platforms?


Currently Cisco IOS (4948E-F), NX-OS (6001, 6004), Arista-DCS (7010) and Juniper (EX4200/4300) have been validated. More platforms including multivendor OS will be validated in future releases.


Available Features:


  1. Open architecture: Generic platform to support device port turn up. More device vendors can be easily added.
  2. Extensible YANG model: Existing YANG model can be extended to support customizations.
  3. Access/trunk port support: Built in support for access and trunk ports.
  4. Custom configuration support: Templates can be easily modified to push customized configurations towards device.
  5. Bulk port turn up support: turn up one or multiple ports towards the same or different devices.


Watch the video where Imran Baig, Solution Architect, explains how this package works.

Full source code for this package is available at:


For further information please contact the Cisco Advanced Services team, Syed Ziaullah (, Solution Architect, Manish Jain (, Director Software Integration and Orchestration and Tushar Tipatre (, Business Architect





Cisco Employee

Hi Imran,


Any reason you created port-turn as a service, you could simply create device-templates to do this job or NSO action if you really need flexibility. It might be creating unnecessary service instances in CDB you may never visit in future.




Cisco Employee

Well @azhasale I wasn't part of creating this service - but there are a few reasons why I would do it:

   1. Better update for the CRUD cycle 

   2. Possiblity to use the stacked-services pattern to include this in more advanced services

   3. More advanced support for check-sync / compliances

   4. Making it easy to change the port-turnup template in the future and updating all the ports it was used on to the new format


Cisco Employee

I ended up deleting 500K+ service instances at customer NSO, where they used service for turning ports up, and never visited those instances in its life cycle. Unnecessary increasing the CDB size. Your points are valid but again it depends on usecase to usecase. Customer needed create and delete, 2 templates with nso actions were good enough but someone created service for that purpose and they are in business of turning up few hundred ports weekly. 

Cisco Employee



Writing an NSO service makes perfect sense when you want to manage that configuration later whether using that service directly or as part of stack service as Victor mentioned. It also helps in reporting what was suppose to be configured and went out of sync. Hence if the use case is config once and forget then you can go towards actions but if the idea is to revisit the config for any reason(manage/reuse/report etc) then service is better candidate.