Another notch on the belt this week!
(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.
Q: So why not just use an open protocol?
A: The right one often doesn’t exist
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
SDN, or Software Defined Networking, was supposed to be the Next Big Thing(tm) in how networks were built and designed. In reality it often creates more problems than it solves, and never really addresses the Business Needs of what it was conceived to accomplish.
SDN FROM POST-CONCEPTION BECAME ALL ABOUT VENDOR LOCK-IN
One of the problems, as others have pointed out, is that SDN from post-conception became all about vendor lock-in. You were tied to their software, which was tied to their hardware, which was tied to their reference designs, methodologies, features, upgrade cycles, and support systems. All that money you would save (hah!) on expensive network engineers suddenly was diverted into a recurring revenue model with a vendor. You wouldn’t actually save any money at all, instead you would hemorrhage cash flow into companies like Cisco.
Another problem was that for most vendors, their “fancy” SDN software was really only about “solving” a very specific problem, or small set of problems that had limited possibilities. Sure your SDN vendor might throw you a web page with more graphs than a demo grafana dashboard, but under the hood it was no better than a bunch of QBASIC GOTO statements to manage the load balancing and traffic predestination of various WAN links.
At the end of the day, none of this really came together to solve real problems other than propping up $vendor’s quarterly balance sheet.
… and then came Whitebox Networking. No, that’s not a vendor, but a term for taking reference hardware designs from companies like Broadcom, slapping on the network operating system of your choice (Cumulus Networks, Free Range Routing, Snaproute, Vyatta, etc.), and walking out the door with extra cash in hand with virtually unlimited capabilities in the equipment you just purchased. No longer are we tied to a specific all-encompassing vendor to meet our organization’s networking requirements in terms of hardware and software.
Okay, so this helped break the nefarious umbilical cord between organizational IT and $vendor, but we still lacked ways to combine network designs and equipment and software and documentation to meet business needs in a way that didn’t take months or years of methodical planning, creating documentation, change windows, etc. only to realize that something was missed and that the needs of the business aren’t really being solved (and done in real-time, for that matter).
INTENT BASED NETWORKING
Enter Intent-Based-Networking, or IBN.
Ohhh look, another markety thing! Shiny!
All <snark></snark> aside, this is what SDN was really designed to do. In theory in this model one designs not the network, but the needs of a service or application and lets the software design or redesign the existing network in realtime to meet that need.
Let that sink in for a bit. Seriously. Go grab a cup of coffee, tea, water, Kentucky bourbon, or whatever tickles your fancy while you think on this.
Let me say it again:
“… in this model one designs not the network, but the needs of a service or application and lets the software design or redesign the existing network in realtime to meet that need.”
So going a bit deeper into the concept here, you might tell your IBN software that you intend to deploy an application (X) using storage resource (Y), any particular Quality of Service or SLA requirements you have, and then the software will reconfigure your mixed-vendor network to create an environment that meets these needs. This is just one example, but it’s an amazingly powerful concept with real promise.
WITH SDN, YOU GET STUCK TRYING TO IMPLEMENT THEIR CRAP
We’ve all heard stuff like this before in IT – tech that seems too good to be true. “This world-changing tech is a paradigm shift that overlays and merges business acumen with network zeitgeist to create synergy of idea and symmetry in execution.” – or something. Blah, blah blah. 12 months later and a few million $ in the hole, nobody is any happier except for the salesmen (sales-women, sales-person, sales-you, so-on) who made comission on your folly. You get stuck trying to implement their crap, and they take off to the airport in their 2nd or 3rd Ferrari to head to Maldives.
… but this time, it seems to be legit. Much like how x86 / x64, the iPhone, Linux, VMware, and to a lesser extent Ubiquiti (with outdoor wireless and UniFi) changed segments of IT in massive ways, Intent Based Networking has actual promise and real customers.
As covered on a recent packetpushers.net podcast, Apstra has a real product to do this NOW. Yes, it’s young technology, but it’s rapidly developing. Other vendors are getting in on this as well; new, hip software companies as well as the usual suspects of traditional vendors. Both have skin in the game of course, and this will be a long ugly battle before the fog rolls off.
Until then, keep brushing up on your python and your cloud certifications. Automation in the network is just the start.