There seems to be a common fear amongst network engineers when talking about network automation. In itself this is understandable as network engineers understand the complexities and diversities of networking as no other.
But if you adopt the approach that netYCE offers you, there is really nothing to worry. In fact, it turns out to be risk-free, fully transparent and extremely powerful & scalable. This blog will explain How.
Introduction netYCE
First, it’s important to understand that the netYCE solution is a framework. A framework for orchestrating and automating multi-vendor, multi-domain and multi-technology configuration changes across hybrid networks (wired and unwired).
The netYCE acronym stands for “Your Configuration Engine for the network” and when you pronounce “YCE” quickly it sounds similar to “wise” which is exactly what the netYCE framework offers – a wise approach to networking.
The framework provides many intelligent ways for you to structure your own (existing) knowledge and reuse it over and over again in smarter ways. It uses the same processes that engineers use today to carry out their tasks but everything is done in a structured way with a proven process to enable collaboration and automation.
The framework consists of three main sections (layers) that bridge today’s gaps between Designing, Building and Operating networks. And therefore the ability to automate. See the picture below. Each layer includes a variety of tools that all work seamlessly together, but each can also be used separately.
These layers are:
- Design (Service Design), where you design and model your services and automation rules via an engineering driven web GUI (no software programming required).
- Build, (Service Creation and Administration). This where you prepare and maintain all your network changes in a vendor agnostic database + GUI and combine this with vendor specific templates to generate configs before actually deploying them.
- Operate (Service Operation). This is where you have the tools to centrally deploy parameterised device & service jobs, startup configs and scenario’s. And then schedule orchestrated changes to your production network.
The framework basically comes empty out of the box, so it allows engineers to start on a white sheet of paper. Also, it doesn’t do anything unless you instruct it to do so. The philosophy is that engineers & operators remain fully in charge of their network, so think of it like going from an old car (traditional manual efforts) to a ‘Ferrari’ or better ‘Tesla’ capabilities.
In short, netYCE allows you to standardise, prepare and schedule configuration changes to any type of networking device in an orchestrated and multi-vendor way. The underlying netYCE vendor engine will take care of logging into the production devices and execute the commands based on jobs and scenarios that you have created. All fully transparent. The job log will provide you a full transcript back of the device syntax as if you were working on the CLI (or vendor API) yourself. (See also earlier blog on this topic: ‘Automating Networks – stop talking about technology!’)
Depending on your own level of confidence (and maturity of your network) you can choose to implement your own level of automation. The framework will guarantee that all steps are applied alongside a tried and tested method. As a result, you now cannot only orchestrate (multi-vendor) changes to as many devices you want but also in far more intelligent and controlled ways.
Proven history
The beauty of netYCE is that the platform has matured by using engineering best practice principles over the last 15 years. That’s a lot of experience and lessons learned for a relatively new technology company. Not many firms out there can match this type of experience.
The company netYCE is not your typical startup figuring this stuff out for the first time. The first production release dates back from 2001 when the people behind netYCE were asked byRabobank Netherlands to develop a provisioning solution to transition them from a 3Com to a Cisco WAN. This was done in a very short time period with only a few engineers having Cisco experience.
Since then many different types of networks have been successfully automated using the netYCE software. In a period of 15 years, Rabobank deployed netYCE to manage more than 5,000 nodes, covering multiple advanced networks, topologies, services across LAN, WAN and Service Provider designs.
For example, in 2015 Rabobank transitioned their entire Cisco LAN network to HP (4000 devices across 1600 sites) in a matter of weeks. They also fully automated the service provisioning of all their Data Centre Fabricpath network changes (Cisco) and use netYCE for hundreds of daily maintenance changes for all their Office-, ATM- (money machines) and ISP networks.
Each project added a lot of new functionality to the framework such as multi-vendor support, abstraction, modeling, templating, extra technologies, multi-tenancy, multi-domain, OSS/NMS- API integrations etc.. In 2011 it was decided to spin off from Rabobank and the company netYCE was born. They now work alongside many large Enterprise customers such as Ministry of Defense, large Service providers such as Ziggo and global Managed Service Providers.
Before diving in..
Depending on your own use case or maturity level, you can either choose a Bottom-Up or Top-Down approach within netYCE.
The Bottom-Up approach basically means that you first start to (only) use the ‘Operate’ tools for centrally deploying parameterised and templated jobs. Once you feel more comfortable you can slowly apply more of the ‘Build & Design’ functionalities.
With the Top-Down approach, you start with modeling your deployment and automation options and then use these to update your network abstraction (Build) database. You then prepareall your changes first before sending jobs to the network. The Top Down approach is typically used when deploying new services on top of existing brownfield network (e.g. automating L2/3 IP VPN services on a Carrier Ethernet network) or when deploying new (replacing old) devices.
The Bottom-Up approach is used by customers who first want to centralise, standardise and optimise their operational changes. You can use and mix both approaches if you want. For this blog, we will focus on the Bottom-Up approach, as this is closest to engineers’ existing working procedures and therefore easiest to explain. In the next blog, we will do a full use case on a Top-Down approach.
Let’s dive in!
We’ll focus on the first two capabilities as indicated in the picture below.
On the horizontal ax you see that when you have more context aware information in the netYCE database, the more you can achieve. What’s minimal needed are the login credentials of the devices, which can be imported into netYCE. The first step can be to set the poller to collect the configurations of all your production devices on an hourly, daily or weekly basis. NetYCE will show you what is changed in the production network by highlighting line by line differences per time interval, back up configs and report on them. This allows you to monitor what happens in your production network outside of the changes scheduled via netYCE.
The second step is to start configuring devices centrally. The most versatile tool is the ‘Command Job’ tool, allowing operators to create command sets based on their own CLI syntax with extra support for parameterisation, relations, templates and scenario’s added by netYCE.
Instead of using CLI commands on production devices, any command can now be deployed via the Command Job tools. The netYCE backend will figure out what is the best way to connect (SSH, Telnet, Netconf, vendor API etc), and configure the devices on your behalf. A cultural challenge might arise when changing from a direct to an indirect engineering approach. But while this might feel like a noticeable step, in reality, engineers are doing the same work only in a different place. And remember that the job log will provide a full session transcript as if you were behind the CLI (or vendor API).
NetYCE offers a variety of extra functions to use use within your command syntax that will not affect the vendor CLI syntax once executed. First, instead of typing (error prone) values you can use variables that are substituted using the database with the device as context. You simply reference any information that you have about your devices in the netYCE database (passwords, helpers, VLANs, uplinks, VRF’s, etc) using brackets <…> around their names.
Second, you can use conditionals, your ‘IF” statements. By prepending a command with a conditional, the command will only be executed if the condition is met. Conditions start with the pipe characters (‘|’) and end with the concatenation symbol (‘’). Conditionals can reference any of the variables. For example “|OS version = 12.3| your 12.3-specific commands” will only generate and issue the commands when the OS version of the device is met (or not met by using != symbol, the ‘Else’ statement).
Next are relationships indicated with the @ symbol. e.g <Vlan_id@Vlans_interface> will give you all VLAN id’s from the relation VLANs_interface, indicating the VLANs that are assigned to the given interface. As there can be many results, one single line can generate a whole list of variables. Relations can be defined by the user since the more complex relations are defined by the design (like the bgp neighbours of a PE).
As an example (and showing the concatenation option (‘’), these lines will issue all Cisco style interface VLAN blocks needed (or none when lacking any).
The conditional will ensure that the native VLANs are suppressed since they have no address configured. Using these basic command functions, truly smart templates can be built that are applicable to any device given its role or design.
Customers may also use any type of custom variables. For example, if a customer deployment is at a certain migration phase they can use a specific ‘phase’ variable for different stages managing eg. routing protocol selections. This too can all be automated.
A great benefit is that you can save and share jobs, private or public (with other colleagues). This allows more complex and tested jobs to be reused over and over even if they have been made by others.
The possibilities are endless to structure, save and share your knowledge. You can read the full technical capabilities of all function on the netYCE wiki (simply click on the link to request access, this will also give you online access to the demo application).
Now let’s start using Templates..
The next step is to get away from individual device commands and use smart templates to centralise all your (teams) engineering knowledge. You could have one template for a device, but instead of having one monolithic template, netYCE offers the ability to break it down into main-, sub- and port templates and hook them all together in a template tree to form a full configuration. Every device has a main template which calls upon other templates in a hierarchical fashion. You can organise this any way you want.
This tree offers the ability to manage different nodes & variations in smart ways. For example, core switches can use a tree of sub-templates to establish routing protocols and VRF configurations while at the same time sharing sub-templates with their access switches that define SNMP, banners, network management and ACL’s. And, due to the conditionals in the templates, the generated outcome will be unique for the targeted device.
Templates are revision controlled into historic, planned and production versions. This allows you to test against planned status and then move planned to production while the latest production gets demoted to historic status. There is only one production revision and it’s locked so users cannot modify without the corresponding user permissions.
What’s great is that templates for different vendors can have the same name (indicating its function) each using their vendor-specific CLI commands. Now instead of using the commands in the command box you can issue the name of the template (by using the {…} symbols). When you then want to schedule jobs for a mixed set of devices, netYCE will automatically apply the template of the corresponding vendor. This approach enables a very easy way to apply multi-vendor implementations.
The conditionals, relations, and custom variables again allow you to add logic and exceptions to templates. For more advanced topics a host of functions can be used that e.g. can perform ip-address calculations (with offsets) or validate values and raise errors on missing components.
With growing experience, the template becomes more universal by incorporating additional layers of abstraction for automation. As a result, a smart device template tree (calling conditionally upon sub-templates) now can easily manage hundreds or thousands of configuration variations, all version based and revision-controlled.
And then we have scenario’s
Think of a scenario as ‘mini-scripts’ that go along with every job you schedule to the network. When not specified anything, netYCE will use a basic ‘command_job’ scenario for backing up production configs for rollback in case your job is not successful. In addition you can specify as many different steps you want to have performed on the device.
An example is the ‘diff-config’ scenario that will check your production config, at the time of executing a job, with the production version from e.g. yesterday. You can now pre-define if you want to abort when there are differences (i.e. people have changed something outside of netYCE control ), send a trap, email or just continue.
You can create as many scenario’s as you want for different things like recurring jobs, rollback, node migrations or complex network migrations. You can either save and manage them separately or use them in your (saved) job.
In the example below is a screenshot of a saved job called ‘enable secret update’ that uses parameterised commands (or you just call upon its template name {secret_update} if you want) in combination with a saved scenario that will perform specific checks for this type of job. You can now select as many devices you want and execute this job in mass without any risk as your scenario will deal with the specifics.
How to go from here?
Looking at the Capability slide above, the journey so far has only covered the first two capability blocks, allowing device level commands to be done in a far smarter and central way. This entry level understanding is a prerequisite before using more of the Top-Down approach, as all these tools will use the same functions and abstraction as well, but now in a more structured and automated way.
Now the sweet stuff can start, because you can model automation in combination with the ‘Build (preparation) database that will seamlessly work with all the ‘Operate’ tools. We will do a separate blog on this in detail, but let’s give you a high level explanation of these two extra layers (you can also check this video: overview & demo netYCE platform).
Just think of the Build layer as your abstract network in an open database with an engineering GUI. It allows you to store any type of configuration information in the hierarchy of networking objects that this database manages.
It is important to understand that this is not merely device information but includes the customer and service contexts as well as the roles, topology, and relations. So everything related tohostnames, ports, links, connections, trunks, subnets, VLANs, IP-addresses, VPN’s, VRFs, domains, etc. AND all in relation to clients, sites, profiles, supernets, custom attributes, etc. So essentially full context-aware information.
The ‘Build’ GUI allows you to prepare, create and maintain entries in the database (eg. create a new node, site, customer, change ports, add VLANs, migrate vendors etc). All this can be done by ‘clicking around’ in the GUI and then use this updated information in the Command job tools. The true power comes in when you use the modeling tools from the ‘Design’’ layer.
This basically allows you to easily model any number of changes in the ‘Build’ database. You can do this for anything. So for any change you can prepare by ‘clicking around’ via the GUI, you can now create a ‘service type model’ that will do it for you. You can assign it to a graphical button for any operator to use or invoke it through the API. You can also use this for standardised tasks for things like migrations. All the modeling is done via the GUI especially made for engineers, so no software coding is required.
In summary
Any of these stages of network automation are not to be feared. You can choose where to start depending on your own automation goals, so just give it a go. All your current operational activities remain the same, just structured and automated. And as it’s all focused on automating currently used engineering steps, it is extremely powerful and of interest for engineers who want to extend their NetDevOps skills.
The business benefits are evident. Quick time to deliver and implement new services, error-free changes with first time right guaranteed scenario’s, improved network stability, pre-compliance enforcement and innovations such as self-service portals for end customers and partners. And last but not least efficiency & cost savings.
Blog by Matt Conran from http://network-insight.net interviewing Wim Gerrits, ceo netYCE