A pretty generic image for a pretty generic discussion, this is intro course #2 that is going to be centered around Data Models such as NETCONFIG / RESTCONFIG / YANG, so this is a very generic overview of why Data Models are needed.
This does have some relevance in my next Intro to YANG post, specifically how SNMP and MIBs are analogous to NETCONF and YANG, so its probably worth a quick read.
This will basically be “Why Automation was slow to start” and “What we are doing now to kick start Automation” within this article, I’ll try to make it a quick easy read, as I don’t believe there needs to be a whole lot of technical explanation but mostly theory.
SDN was a buzzword 3 years ago – Why is everyone so excited now?
I personally believe the answer is because Cisco is integrating this into their training / certification model, plain and simple, though the answer is obvious to anyone who has gone through a vendor Vulnerability / Emergency Patch situation with hundreds or thousands of devices that need patching immediately – Doing that manually was painful.
SNMP was thought once to be a viable candidate for an Automation like solution as it does both Read and Write on device configs, but thinking about it until the introduction of SNMPv3 with Encryption / Authentication, that running anything but read-only would be extremely dangerous for your network!
Current Hurdles that are hindering adoption of Automation
- Vendor Specific CLI Scripts, that would require a lot of work to maintain different Automation Tools / Languages / Scripts for all different different vendor devices
- Semi-Automation GUI’s for vendor devices, that would allow for a fairly hands free Firmware Upgrade from the Web Gui, or a device like ASDM for Cisco ASA’s that has a Wizard for Firmware updates / Certificate Installs / etc.
- Back to SNMP there is no standardization of SNMP MIBs between vendors, as some vendor device CLI’s refer to interfaces as an “interface” while HP Switches use “port” for their description of an Interface, making it impossible as a solution
Essentially solutions were meant to use CLI configuration between different vendors that used different verbs for defining network components, while the CLI is fairly intuitive or human friendly as it was made to be, it wasn’t intended for Computer Automation.
One major example is adding an interface to a VLAN between an HP Switch and a Cisco Switch, where you must type “switchport access vlan 10” and vlan 10 will create itself if it doesn’t yet exist, whereas HP Switches you must do “port eth gi1/2” “tagged vlan 10” to apply a Dot1Q tag to that particular interface (or as HP calls it a Port).
The solution to Automating a multi-vendor environment – Standard Data Models!
This means taking all the different components of network data, including what we call the interfaces and what format IP Route Tables and ACLs and VLAN Tables are represented in, and finally how to represent that data (Boolean, Integers, Strings, Objects, etc) within the Data Model.
This was a long way of making a short point I believe
I am not sure as that instructor led video kind of went off in unknown directions, but I believe this is an intro to YANG being that “Standardization” of Network Data Models so that NETCONF and RESTCONF are able to speak to the rest of the network.
I really don’t even want to publish this, but on the off chance any of this might tie into a point down the road, I will publish it – Until next time!
The DEVNET GRIND! 