Yes, it’s a Data Cap, a very literal and somewhat sad representation of what our data providers use to shamelessly screw more money out of us all. I’ll keep the rant short, don’t worry.
Today Big Switch is formally announcing availability of their new “Big Cloud Fabric”, touted as “the industry’s first bare metal SDN data center switching fabric.” And that means what? Well, if you like the idea behind the Ethernet fabric solutions out there right now – Cisco’s ACI and FabricPath, Avaya’s Fabric Connect, and Juniper’s QFabric to name but a few – but you don’t like the idea of being tied in to a single vendor’s hardware solution, then this might be just the thing you’re looking for.
Put simply, Big Switch’s proposition is that you can buy your own ‘white box’ switches (from those detailed on the Big Switch Hardware Compatibility List), run the Switch Light OS on those switches, add the Big Cloud Fabric controllers, and violin, you have your very own Ethernet fabric!
Not content to merely play with NETCONF, I have taken a side step briefly to complete another little tool that relies on a REST API and JSON. I’ll come back on the NETCONF script soon, and explain how I’m using YAML for configuration files, but evidently I’m a sucker for punishment as in the last two weeks I’ve been building queries and parsing data structures in XML, YAML and JSON.
Hang in there – the acronyms aren’t nearly as bad as they seem.
In case you don’t follow Ivan Pepelnjak’s blog (and if not, why not?), I was honored – and a little shy – to be asked to talk to him about my “F-Script” and programming in general, as part of his new podcast series “Software Gone Wild”.
To quote Ivan’s post:
John Herbert has started writing network automation tools more than 20 years ago and was willing to share his experiences in Episode 3 of Software Gone Wild in which we initially discussed his journey from simple Perl script to a distributed configuration analysis tool (the F-script, but quickly diverged into all sorts of topics including:
- Support for numerous unique snowflakes (aka customer networks);
- The dismal NETCONF implementations we have to deal with today;
- The need for NETCONF fingerprinting because no two vendors manage to read the – NETCONF standards the same way;
- Multi-platform considerations;
- The challenges of doing everything on your own (including supporting your code indefinitely).
I had a blast talking to Ivan (it’s kind of like being granted an audience with the deity or other idol of your preference), and if you do spend the time listening to the podcast, I hope you get something out of it.
This week a colleague of mine (also a script junkie) was writing a change script to create a VLAN. In this case he was adding the VLAN to a Cisco FabricPath domain, and he observed that this would really be something better accomplished with a script, as it would reduce silly mistakes like missing one of the switches, or accidental inconsistencies between them. This is on our minds because he has just been working on a way to deploy identical firewall changes to multiple clusters at the same time so that the configurations don’t get out of sync.
And so I found myself working on a script to deploy a VLAN on the list of switches that make up the FabricPath, uh, fabric. For speed I am using my old faithful Perl, and because I’m forward-looking or something, I decided that I would not use any form of expect, but instead would configure the switches using NETCONF. That should be easy enough, right?