Frequently Asked Questions

What is the meaning of the name 'netYCE'?

The origin of the name netYCE comes from the abbreviation 'YCE' which stands for 'Your Configuration Engine'. YCE is still at the heart of the netYCE framework offering an out-of-the-box solution to schedule and execute network changes to (multi-vendor) networks. And do this in a controllable, automated and data-driven way.  

Over the years the netYCE framework has matured from automating network configuration changes to also managing change processes related to resource inventory, planning, preparations, designs changes, migrations, automation, orchestration and integrations. Now, with netYCE v7.x network engineers,  -designers, -operators, customers and external partners can all work together in a unified way.

What business problems does netYCE solve?

NetYCE solves many problems that Network Service Providers face today. Without going too much detail these are: 

  • Improving time to market for new services and deploying changes in seconds
  • Zero touch deployments for new network devices, updates or automated integrations
  • Guaranteed first time right changes, whether this is for one device or many thousands
  • Improve network quality by enforcing compliance. 'As designed = as deployed'
  • Enable agility, whether this is easy replacements, migrations or deploying design changes
  • Automation and Orchestration of many types of network changes
  • Automated integrations with 3rd party NMS applications
  • Knowledge management, - Sharing and Collaboration
  • Delegation of change control to help-desk staff or even end-users
  • Free up skilled resources for projects and NetDevOps tasks
  • Develop new services and business models
  • Reduce overall TCO


Can you explain netYCE functionality in short?

Think of netYCE as your ultimate framework to support network staff with all their tasks related to 'Design', 'Build' and 'Operate' processes.

The framework incorporates a 'carrier grade' configuration engine (YCE) to send and receive configuration changes in a controlled, smart and data-driven way to multi-vendor network devices. The YCE engine is supported by a range of 'Operate' tools to help engineers streamline and automate configuration changes.

Instead of logging into production devices, jobs can now be scheduled via the netYCE application. Engineers can choose to keep on doing what they do today (device based syntax changes) or make use of the enhanced netYCE features to perform far more 'smarter' and 'data-driven' jobs and scenarios. And deal with automatic rollback scenarios etc.. As such, YCE is best described as your ultimate scripting engine that does not require any software development. We have made it easy for engineers to use in their day to day work.

On top of the YCE engine, there is a logical inventory database, a rich GUI and templating system to support all of the required 'Build' processes. This means making planned changes, prepare migrations, perform reconciliations, keep track of your network administration and store all of your staff's engineering logic. Basically, all your network information and support processes in one place to prepare 'intended' changes before you deploy them. All this works seamlessly with the YCE engine and 'Operate' tools to keep your 'deployed' production network in sync with your intended changes.

On top of the 'Build' layer, sr. engineers and designers can use the 'Design' tools to standardize and enforce design rules, design options, design logic and design changes down to the network. Here your design and automation logic can be modeled. netYCE will automatically hand out all variables and parameters as per your design and keep a full administration of it. So no need for excel files and separate databases.

Finally, all that can be done via the GUI can also be done via the netYCE' API. This will further streamline automation and orchestration with 3rd party systems such for IPAM, DHCP, DNS, OSS or other NMS systems.


What network vendors does netYCE support?

NetYCE already supports vendor modules for Cisco, Juniper, HPE, Avaya, Ciena, Huawei, Checkpoint, Fortinet, Palo Alto, Brocade and much more. Each vendor module supports all devices within that OS 'family'. New vendors are added as we go along based on customer requests.

Typical lead time for a new vendor module is 5-10 days, given that we get (VPN) access to customer specific hardware/software. At the moment we are developing a generic Ansible vendor module to support cloud platforms such as Azure, AWS, Openstack etc.

For more detailed information, please check out our public WIKI. You can get request access via the 'Try-Now' menu.

How can you support a new vendor module for me?

As explained in the earlier FAQ, we add network vendors all the time. The only two criteria whether we can support a new vendor is how we get access to the device (either remotely via VPN or you send us one) and if it supports any CLI or API-based communication protocols. Devices that only support GUI-based configuration changes are more complex to automate. Please reach out to us to see what the options are.

Furthermore, many processes can already be optimized and automated without the need for a new vendor module. The vendor modules only deal with connectivity to the test & production devices (either virtual or physical). For any type of device, it's possible to create a new model in netYCE (so without a supported vendor module) and make use of all of netYCE's functionalities in the 'Build' and 'Design' tools.

How does netYCE manage different vendor syntaxes?

Network engineers can create as much different vendor templates as they want to store any vendor-specific configuration- and engineering design logic. The netYCE templating system offers many extra features to manage configuration generation in a smart way. E.g. by using parameter substitution (from the netYCE database or via API), using relationships or conditionals and many additional functions (to e.g. count or calculate things). 

NetYCE differentiates two types of templates. First, there are the 'Configuration templates' to automatically generate configurations (full or partial). These Configuration templates can be organised in a hierarchical tree structure, calling upon smaller templates with specific functions (VLAN's, ACL, port, etc..). As these templates can be made smart, they can be reused throughout the entire network and will generate specific outcomes per device/customer/etc.

Second are the 'Parsing templates' that can be used to retrieve specific information from production devices (using command parsing) or its configurations (config parsing). These templates can be used in combination with the job scenarios to validate changes on production nodes 'at run time' when deploying the intended/desired change. 


How can netYCE guarantee 'As Designed = as Deployed'?

From a process point of view, the netYCE framework is set up in such a way that you (can) first prepare changes before you deploy anything into production and that what gets Built (prepared) is fully compliant with your design. So you prepare your intended state of the network, based on your design rules and then deploy it to production with automatic validation. All this is done by combining the three layers within netYCE: 'Design', 'Build', 'Operate'.

The 'Build' layer lets you prepare any type of change. You then use the 'Operate' tools to deploy your intended changes to production. Within the 'Operate' tools, you (can) then use 'scenarios' (to be used in combination with each job) to validate production settings as these might be different to what you expect.  So to guarantee that nothing gets broken in production, the scenarios let you define how to automatically roll-back when some criteria are not met.

To guarantee that whatever gets built within the netYCE database is based on your (high- and low-level) design rules, you (can) use the 'Design' tools. Here you set the rules to auto-populate parameters (e.g. handing out IP addresses or VLAN numbers) and automate any sequential number of engineering steps that you could also do through the GUI (or API).

To guarantee 'As Designed = As Deployed', these 3 layers are used in combination, whereby the 'Design' set-up is typically configured once for each network.

Also, these layers can be used separately. So just use the 'Operate' or 'Build' tools. This all depends on your use desired case, experience and/or maturity level as anorganization.


How scalable is netYCE?

You can deploy netYCE is a variety of architectures. 

  • Single Server, running both the FrondEnd and BackEnd servers on one physical or virtual machine
  • Dual Server, High Availability mode with a hot standby of a second server. 
  • Distributed architecture, splitting the FrondEnd server from the BackEnd servers. BackEnd servers will run in High Availability mode and you can add multiple FrondEnd servers depending on the scale you need or depending on your security requirements (per domain). Each FrondEnd server can be configured to deal with thousands of jobs each if needed.

See picture below:

Can you support me in my country?

First, it is important to know that the netYCE application can be downloaded and installed from anywhere in the world. We pride ourselves for our 'one code base' policy, meaning that all customers run the same code base. So software support is quick and simple. Depending on the service contract we can provide 7x24 support. Installations and upgrades can be done by your own staff or by a local partner. Simply download the latest patch or update from our wiki, upload it to the netYCE application and you are ready within seconds.

Second, and most important piece of support is training and consultancy. As each network is different, the requested use-cases and maturity levels might be different. That's why we provide tailored training classes to both Service Providers and local (integration) partners around the world. We typically train engineers on the job during the first project so they can see the platform's capabilities and know how to take it further with only remote application support.

NetYCE is currently based in Asia (Mumbai, Bangalore, Singapore), Europe (Amsterdam, Madrid) and we have partnerships to support customers in USA, LATAM and many other countries in the world. 

We are also expanding rapidly, so stay tuned or contact us at for specific questions.


How can I learn more?

There are many aspects that come into play when you're trying to automate your network. So we get it that this topic might be overwhelming. Over the last 15+ years, we have seen many networks and dealt with hundreds of questions. So there is a good chance that we can address your questions. 

We have conference calls, webex sessions and demo's all the time with customers around the world. Just reach out to us via and we will set an appropriate time to meet.

From a netYCE application perspective, please check out the following resources:

  • Demo video and netYCE application overview
  • Blog series explaining netYCE in more detail (1-3):
    • Blog 1 - General Intro into network automation
    • Blog 2 - How to use netYCE 'Operate' tools as of day 1 without impacting your organization
    • Blog 3 - How to use netYCE 'Build' and 'Design' tools for all the other goodies that netYCE offers
  • In our WIKI, all of netYCE's features and functionalities are described in granular detail including HowTo video's. We will be adding new video's as we go along. These will be added to our WIKI. Just request access here.
Is Intent Based Networking just a rebranded form of SDN?

No. Intent-based networking software helps to plan, design and implement/operate networks. SDN is an architecture for networks. Intent-based network software can “drive” a network that is either SDN-based or non-SDN based (Andrew Lerner, Gartner analyst).

Isn’t Intent Based Networking just a fancy term for advanced automation?

Normal automation solutions typically do not

a) translate what to how

b) mathematically validate that desired intent is being met and

c) continuously ingest a broad set of real-time network state indicators.

A good intent-based networking system will embed advanced automation, but you can do advanced automation without Intent.

Will Intent Based Networking replace people?

Most likely, no. It will simplify things that humans do including validation. It will automate configurations tasks and dynamically remediate. But you need humans to input data into the system. It will certainly shift resources away from mundane networking tasks. There will be less reactive trouble tickets but more proactive notifications to be tended to. Also, with the impending explosion of IoT devices, we will need a better way to manage environments, because current manual and non-automated practices likely won’t scale. Intent certainly helps here.

More to come soon!
--------------- The following will be added soon ---------------------------------
  • netYCE versus custom solutions
  • What are the advantages versus a local supplier
  • What are the challenges in multi-vendor network automation and orchestration?
  • Why should I automate my network and orchestration?
  • How is design driven network automation different from other solutions in the market?
  • What are the benefits of using netYCE?
  • Who is your competition?
  • What does netYCE mean with 'Abstraction'
  • How can you standardize configs, Services & Design
  • What kind of migrations can netYCE offer?
I have another question...?

You have a question that is not listed here? 

Please send us an email at or leave your question here

We will incorporate it in our FAQ, so stay tuned as we are adding more...