In my last blog, I explained why automating networks doesn’t have to be scary. I showed you how to centralise all your multi-vendor configuration- & OS changes and how to use variable substitution, templates, conditionals and relationships to standardize and automate.
For this, you simply use the ‘Operate’ tools within the netYCE framework (see picture below) and netYCE will take care of logging into each vendor’s CLI or API and execute your jobs the same way you normally would, but now in a scheduled and automated way.
This is a good way to get started, but so far this approach only dealt with ‘device’ based automation. The next step, and the focus for this blog is to show you how to orchestrate and automate ‘Intent based’ network- and service changes. And how easy it is to use this approach with OSS integrations. Many network providers struggle with this, but as you will see it’s very straightforward and again fully transparent for network engineers.
We will focus on the capabilities within the other two layers of the netYCE framework, the ‘Build’ and ‘Design’ layer. Let’s start off with the middle ‘Build’ layer as that contains the network abstraction database and all the tools to Prepare, Build and Maintain ‘intended’ changes.
From Device- to Network- and Service Orchestration & Automation
If you take a helicopter view, it’s not hard to realise that you need more information than just device information as a network consists of many types of devices. Each can be used in various roles (e.g. Core-, Access-, Aggregation-, WAN-, LAN- and Data Centre- devices) and it’s the specific design and implementation that determine how everything is connected, what is configured, what ports are used, for what, at what speed, with what services, etc… The same applies to services that cross all these devices and networks.
So we need to store more information? Yes, but not only that. The information also needs to be ‘context aware’, in order to get the most out of your automation efforts. What this means is that you need to know the context, scope, and function of each variable used. Let me explain why.
Context-aware information
Many of the same types of parameters can be used throughout your network and services. An obvious example is a vlan number. E.g. ‘vlan 401’ can occur multiple times throughout your network. But each will have its unique and distinguished scope spanning their own set of devices. And many will have different functions.
For example, an engineer might have decided that vlans in range 401-450 are used for IPT, 451-500 for Internet and 501-550 for guest access. Typically, this kind of logic is only implicitly known by engineers. This mean that you cannot determine the vlans’ scope or function by looking at the deployed configuration itself. Only engineers who designed it can analyze the config and deduce its meaning. The same goes for many other parameters such as ip-ranges, qos-labels, routing-ids, tunnel-ids, tags, etc.
It is crucial to managing the scope, function, and range of each variable. Otherwise, it’s impossible to automate and orchestrate changes across your networks. So the question becomes: How to store and manage this information in a vendor agnostic way while it can be used and managed easily?. This is where the concept of a network abstraction database comes in. Let’s dive in and see why this is so useful and powerful.
Network abstraction database
The concept is really simple. Think of administering all your network information in a database with a full vendor agnostic view of a hierarchical model. With everything that belongs (or should belong) together. Take a look at this picture that represents the netYCE’ network abstraction model on a high level.
There are objects and relationships with detailed information for all your clients, supernets, sites, services, subnets, vlans, devices, ports, topology, etc… And as ports from one device connect to ports on another device, a full mapping can be made for all information that belongs to customers, networks or services. All this information is not tight to any vendor, it’s simply how your network is build up. In fact, it is the input for the vendor’s configurations with their own syntax.
Structuring your network information in such a way is extremely powerful for standardization and automation purposes. You now know the scope, function and relation of each variable. This is extremely handy when using the templates, jobs and scenarios.
It is now possible to give each variable a meaningful name and use this when creating jobs and configs. Instead of using ‘vlan 401’ or ‘vlan 503’, you can now just use the reference ‘User_vlan’ or ‘IPT_vlan’ as a building block of this design (or architecture). This not only makes troubleshooting far easier when looking at a production config, you can now also use these references in templates and jobs. As netYCE knows their context, you can simply use the functional names and netYCE will apply the correct set of values from the database when processing your template.
There are many reasons why the use of a network abstraction database is so powerful. Let’s zoom in.
Why network abstraction is so powerful… 1+1=5 !
1. You finally have one place where you can store all your network information needed for generating configs and config changes. No need for excel sheets or analyzing your production devices. Even troubleshooting can partially be done with this information without disrupting your network.
2. As all your network- and service information is now totally vendor agnostic, you can simply assign a different vendor template and automatically generate a Cisco-, Juniper-, HP- or any other vendor configuration. It also allows you to migrate effortlessly from one vendor to the other or from one service to another, or from one type of network to another. The possibilities are endless. This not only makes you far more independent from network vendors, but it will significantly increase the maturity of your network operations by centralizing all your engineering knowledge.
3. This is most applicable for this blog. As the database not only stores your network information in an abstract way, you can also Prepare, Build and Maintain ‘intended‘ changes in the abstraction database before deploying anything to production. In fact, it allows you to completely define your intended new state of the network and prepare production changes. You can even prepare complex migration scenarios.
You can do this with multiple team members and with full control, transparency and traceability. Once you are happy with what you have prepared and intended, you simply schedule it to go out for production, either device-by-device based or via one orchestrated job using a scenario.
4. The netYCE abstraction database can either be used as the ‘leading source’ for all your network inventory or it can be used as an intermediate broker. This comes in handy when integrating with OSS- or other systems that already store your network inventory. So depending on how you set up netYCE, you can choose whether netYCE or another system is leading in storing and maintaining your inventory information.
The reason that this is very useful is because inventory systems typically lack specific ‘state’, ‘scope’ and detailed network information. And it might sometimes not be wise to store all customer and network information in one place. Customer orders and billing records have their own world and purpose compared to network information for configurations and provisioning. So the ability to segregate or combine this information makes your systems far more flexible and modular.
5. Because the abstraction database is fully integrated with all the other tools in the netYCE framework, all the information can now be used within all the templates, scenarios and deployment tools from the ‘Operate’ layer. See my earlier blog for a detailed explanation on this.
Finally… time for network & service modeling
By now, you might ask yourself: How can you (automatically) fill the network abstraction database? This is where the ‘Design’ layer and its modeling capabilities come in. Let’s take a closer look at that.
First of all, let me clarify what netYCE means with ‘modeling’ has nothing to do with things like device communication, vendor models, Yang models, Mibs or anythingsof that nature. This is all dealt with by the netYCE scheduler and vendor engine within the ‘Operate’ layer, where the communication with devices, API’s, Netconf/Yang models, EMS systems or even SDN/NFV integration is done.
What netYCE means with modeling is: “Creating automated building blocks, design rules and engineering steps to standardize and prepare network changes in an abstract and flexible way.”
In simple terms this means you can create models for any type of change or sequence of changes that you can also prepare manually using the ‘Build’ and ‘Operate’ tools via the web GUI.
So whether you want to create anything new (like a new client, site, service, subnet, vlan, device, port, topology, etc..), whether you want to apply a rule for e.g. finding the first free IP address in a range OR whether you want to change, delete, update or migrate networks and services, you can simply create a model to do it for you. The same goes for creating jobs with templates & scenario’s to be scheduled to your production network.
Sounds interesting, right! Let’s look at an example. Below you see a screenshot of the netYCE application showing you a ‘service type’ model that takes 25 steps to add aanNNI Service vlan across a Carrier Ethernet network. Without going into all the details, these steps are basically the same steps an engineer would take to make this kind of change manually. So 25 steps from finding the right devices, ports and topology to assigning a free vlan ID from a certain range, assigning ports to subnets to adding the VRF ID’s, etc.. And all done in a generic, parameterised and executable way.
You now have a generic service model called ‘AddServiceVlan’ that can be executed over and over again and that will update your intended network state in the database each time you apply this for a specific customer or situation. And the nice thing is that these service types can either be invoked through netYCE’ northbound API or delegated to less skilled operators via the graphical GUI.
So, to resume, as netYCE enables you to create any type of model (Network-, Service- or even IPAM models), executing these models will automatically update your network abstraction database (i.e. your intended network state).
Last step… How to get from intended (‘as designed’) to production (‘as deployed)
The journey so far has explained how you can centrally orchestrate automated and intent-based changes to your multi vendor network. The final step is to guarantee that nothing gets disrupted in production while making these changes. This can be fully controlled by using ‘scenarios’.
More details on this can be found on my earlier blog, but in this context it’s important to understand that you can fully determine yourself whether you want to send ‘fire & forget’ jobs to the network or whether you want to use sophisticated scenarios to deal with automated roll-back, diff- checks, migration steps or even parse and validate production configs at runtime (available in netYCE 7.1).
And if you don’t feel confident at first to schedule jobs to your production network, you can, of course, also use netYCE to just prepare jobs and use the output as guidance for making production changes yourself, the old fashioned way. I can guarantee, once you try it, you never want to go back!
Bringing it all together – an OSS integration use case
The beauty is that you now have an engineering approach to automate and orchestrate network- and service changes without the need for software programming. Engineers can simply use the web GUI to structure and model engineering steps so things can be automated easily. These models can then be used by others or invoked via the northbound API by third party systems.
As promised in the title of this blog, you can integrate all this easily with other OSS systems. To show you how, I have put together a video where you can see the netYCE application in action. The use case is an automated provisioning of a L2/L3VPN for one new customer with 3 sites across a Carrier Ethernet network with Cisco PE’s, an MPLS core and Cienna devices in multiple rings.
The demo start 21:10 minutes into the video below. If you want to get a full explanation of the netYCE platform, you can watch the entire video.
Endless possibilities
I hope, by now you grasp the endless possibilities the netYCE platform offers you. Different networks with their own ‘Snowflakes’ can now be automated by using ‘Lego’ blocks that netYCE offers you. All based on your own engineering & design rules. And all done within one framework where you can also can define user roles for people with different roles and responsibilities.
In the upcoming blogs, I will demonstrate more use cases that can be automated with netYCE, such as Data Centre/Fabricpath automation, centrally managed LANs and WANs and a Managed Service Provider case where netYCE is used to delegated standardized tasks to operations people around the globe. So stay tuned...