Disclaimer
Anuta Networks page at TechFieldDay.com with videos of their presentations
Anuta's promise with NCX is to provide a vendor and platform agnostic network provisioning tool with a slick user interface and powerful management / provisioning features.
I was skeptical, especially after seeing the impossibly long list of supported platforms.
Impossible!
Network device configurations are complicated! They've got endless features, each of which is tied to others the others in unpredictable ways. Sure, seasoned network ops folks have no problem hopping around a text configuration to discover the ways in which ACLs, prefix lists, route maps, class maps, service policies, interfaces, and whatnot relate to one another... But capturing these complicated relationships in a GUI? In a vendor independent way?
I left the presentation with an entirely different perspective, and a desire to try it out on a network I manage. Seriously, I have a use case for this thing. Here's why I was wrong:
Not a general purpose UI
Okay, so it's a provisioning system, not a general purpose UI. Setup is likely nontrivial because it requires you to consider the types of services and related configurations you deploy in your network, and then express those possibilities in a simple form. Examples of things you might choose to express are:
- For an MPLS PE device, are we 8021.Q tagging the traffic at the customer handoff? If so, what tag? That's a checkbox and a text field.
- For a DMVPN router, do we want to allow direct internet access, or backhaul everything to HQ? A checkbox.
- For various WAN interfaces, choose from a list of provider types in order to get the correct QoS templates applied
Pre-built Templates
NCX ships with understanding of how to do lots of things (create a VLAN, configure spanning tree, define a BGP neighbor) on lots of different platforms. Much of the work is already done. We're not inventing the wheel with Ansible here.
Vendors and Features
The vendor list was huge, but let's just consider a Cisco for the moment. What does it mean for Cisco platforms to be "supported" by NCX? Apparently everything in the IWAN deployment guide is supported. That's a pretty complete list of features: routing protocols, QoS, PBR, security, etc... I'm sure they don't have crazy corner case stuff (using appletalk, are you?) but that's okay because...
Extensibility
Need to use a feature that NCX doesn't know about? The toolkit for defining your own features, exposing them in the UI and getting them expressed as device configuration looked pretty straightforward. It boiled down to expressing a YANG model of the feature in question and then mapping that to device specific NETCONF/CLI/REST/whathaveyou configuration directives.
Final Fragments
- Offline devices which have missed several cycles of updates do not receive that series of individual updates when they come back online. NCX somehow flattens the queued changes into a single update prior to delivering it. Frankly, this blows my mind. It suggests a surprising level intimacy with the device configuration. Imagine, for example, if one of the updates included the bgp upgrade-cli directive. NCX would anticipate the result and merge subsequent address-family ipv4 directives? Maybe I misunderstood the answer to my question on this topic :)
- NCX knows about its management path to the devices in question, and is careful not to lock itself out. I didn't get a lot of clarity about how this works, but there's no question the guys behind it are thoughtful and clever.
[Chris]: Offline devices which have missed several cycles of updates do not receive that series of individual updates when they come back online. NCX somehow flattens the queued changes into a single update prior to delivering it. Frankly, this blows my mind. It suggests a surprising level intimacy with the device configuration. Imagine, for example, if one of the updates included the bgp upgrade-cli directive. NCX would anticipate the result and merge subsequent address-family ipv4 directives? Maybe I misunderstood the answer to my question on this topic.
ReplyDelete[Anuta] In NCX, device configuration is represented as a config tree based on a yang model. The config trees for all devices are kept up-to-date through active reconciliation of NCX config database and device config. One or more config operations can be performed against the config tree and after a commit is issued, the changes done to the config tree are converted to native Device level operations, CLI, API or other interface and communicated over the appropriate transport, Telnet/SSH/NETCONF/HTTP(s)/etc.
Changes can be made to the config tree in the NCX while the device is offline. Device could be offline by design (first time provisioning of a CPE, Switch etc.,) or for operational reasons (temporary network reachbility or other reason). In such cases two possibilities arise:
1. NCX Has config that the device is not aware of - In this case, NCX will push this config when device comes online later.
2. Device has newer configuration - NCX will update the device config-db (Device config changes are valid) or NCX will reconcile the device to NCX config-state (device changes are accidential, possibly human errors or other issue).
This capability in NCX is referred to as active configuration audit & reconciliation and is available for all vendors supported by NCX (35+). This capability is also used for Service compliance (such as L3 VPN, Site configs, Application container configs etc.,) and Device compliance (such as Standard IPSec compliance rules and enforcement).
[Chris] NCX knows about its management path to the devices in question, and is careful not to lock itself out. I didn't get a lot of clarity about how this works, but there's no question the guys behind it are thoughtful and clever.
[Anuta] NCX can utilize out-of-band access to recover from data connectivity issues. In addition, the device's inherent transaction capability rules out this problem, as the prior change will be rolled back and connectivity will be restored. Further, NCX supports Re-IPing of the device, in which case, after rediscovering the same device with a new IP, NCX compares serial numbers with Old-IP and pushes the remaining config changes . However, there could be few cases where device may be unreachable because of config changes done in the routing or other issues outside of NCX control.