Ramblings of an IT madman
(Edit: You’ll have to open the blog post to see the links. Sorry!)
Jeremy Austin sent me a note in our slack chat today about this free O’Reilly Media eBook by Dinesh Dutt. It’s a really good look at modern BGP unnumbered design for a scalable, portable, datacenter architecture. I’m only about halfway through it, but I’m really liking it so far!
Check it out here.
CDP, CEF, DMVPN, DTP, EIGRP, GLBP, HNAP, HSRP, IGRP, IPSLA, ISL, L2FP, LEAP, LRE, PAgP, SSCP, SRP, UDLD, VTP
This alphabet soup of (Cisco) proprietary network protocols is just an example of several of the protocols that, for one reason or another, could lock your organization into their products for many, many years.
Just about no vendor is innocent when it comes to this. Sometimes protocols need to be made before the industry bodies (IEEE, IETF, ISO, ITU-T) can sluggishly convene, digest, banter, and finally agree or disagree on the merits of a given proposal. Other times protocols are designed primarily as a means to bind you to their line of equipment. It can be an incredibly effective tactic for the sales and marketing teams as long as the protocol works.
“Couple your proprietary protocols together with various levels of certifications and halfway competent marketing and sales teams and you too are halfway to becoming your own networking equipment vendor!”
All kidding aside, the idea of companies getting stuck on one vendor for primarily technical reasons is very real. Often times a vendor protocol simply is the best available solution to a problem that can’t be fixed by a change in network topology or by using an existing protocol. In this regard, proprietary protocols are like a drug for your organization. Once you start one, it can often be hard to leave.
Protocols are tools used to solve problems. Sometimes you need a box wrench because a socket won’t fit. Maybe you need a pry bar but all you have is a flathead screwdriver. Without the right tools, it’s hard to build things the way they need to be. Once you’ve gone down that path however, it can be hard to add another vendor’s product to your network that might offer more value to your organization.
Whitebox, whitebox, whitebox. If you’ve been paying any attention what-so-ever to the networking industry in the past few years, this has become a increasingly ubiquitous term. As we’ve discussed before, whitebox is the decoupling of the network hardware and software – you pick your hardware based on the needs of your organization, then you pick the software that has the best set of protocols, features, APIs etc that support the hardware that you purchased. Ala-carte network equipment.
So what the heck does whitebox have to do with EIGRP, DMVPN, etc?
As organizations ween themselves off of Cisco, Juniper, Extreme, Arista, HP, etc they will be moving to platforms (often using the same hardware SoC / ASIC / FPGA) where they are adding the software on top. That software will have a very detailed API to make the stack viable for all kinds of projects like custom integration, automation, and SDN / IBN solutions. That routing/switching software stack will be using open protocols (MSTP, OSPF, BGP, etc.) and is normally running Linux underneath with a full suite of on-device programming language support.
So now we’ve been plucked away from our vendor safe space and tossed into a garage. This garage has everything a professional racing-level mechanic would need to make the most amazing car the planet has ever seen. In the center of the garage, there’s a massive dual turbo v8 mounted to a tube frame with basic racing seats, racing tires, 10 speed transmission, etc. It’s a formidable vehicle for the track, but what if we needed it do do something slightly different? Maybe tow something offroad? It’s a good thing we have this garage and access to all the tools…
I think what we are going to see is an explosion in the development of new open source protocols. I think they’re going to come about due to business need and fear of vendor lock-in now that people have been pulled away from proprietary solutions, and I think they’re going to get developed and implemented faster than the standards bodies (IEEE, IETF, etc.) can keep up. We have the hardware, we have the APIs, we have linux shells on the hardware, we often have programmable silicon, and we have the business need. Add that together with some experienced developers and I think as adoption of whitebox solutions continues we’re going to see some amazing things in this space over the next few years.
So what do you think? Post your comments below and I’ll try to address them as I get the chance.
PS – Work on your python, and netconf