Blog Posts in May 2019
Upcoming Webinars and Events (June 2019)
I’m always amazed at how fast the time flies. I have no idea where May disappeared to, it seems like it was only yesterday when I was writing about webinar plans in 2019… and yet it’s only a month till ipSpace.net Summer Break™.
During June 2019 I’ll continue updating Designing the Private Cloud Infrastructure webinar, and start a new pet project: How Networks Really Work – I’m literally minutes away from traveling to a quiet spot in the middle of nowhere where I’ll work on the materials. In between these webinars you’ll find me in Zurich where I’ll run Microsoft Azure Networking workshop on June 12th in parallel with SIGS Technology Conference.
As you might expect we have plenty of things already lined up for autumn 2019… more about that in a week or two.
Remember: Don’t Panic
I hate listening to “this is what we were doing this year” podcasts as they usually turn into pointless blabbering, self-congratulations and meaningless plans (think New Year resolutions). The Full Stack Journey Episode 28 with Scott Lowe was an amazing deviation from this too-common template.
If you don’t have time to listen to the podcast (but you OUGHT TO do it) here’s what I loved most: “When faced with the onslaught of new technologies, don’t panic. Wait a few months to see which ones survive”.
IPv6 Support in Microsoft Azure
TL&DR: MIA
Six years ago, when I was talking about overlay virtual networks at Interop, I loved to joke that we must be living on a weird planet where Microsoft has the best overlay virtual networking implementation… at least as far as IPv6 goes.
Even then, their data plane implementation which was fully dual-stack-aware on both tenant- and underlay level was way ahead of what System Center could do.
Model Your Network as a Graph not a Set of Boxes
Last week I explained how you could take a typical first attempt at a network automation data model and reduce the amount of duplicate data… but the data model we used was still describing a set of seemingly disconnected boxes.
How about restructuring the whole thing and describing what networks really are - graphs made of nodes (network devices) and links?
It's Time for Another Pet Project
More than a decade ago I decided to start a pet project: a blog describing interesting details of networking technologies. The idea quickly morphed into vendor-neutral webinars - the first one took place in February 2010. A year or two later I had my first guest speaker and as of today we had more than 50 industry experts participating in ipSpace.net webinars and online courses.
In the meantime the ipSpace.net team grew: I had video and audio editors for years, Irena Marčetič took over marketing, logistics, and production in 2018, and we got a team of webinar moderators that will help us with guest speaker webinars (last week we ran the first guest speaker webinar where I didn’t have to be involved - hooray ;)
Worth Reading: Overly Attached
Kate Matsudaira wrote a nice article explaining how to deal with emotional attachment to a project you spent a lot of time working on. While she's focusing on software development, the same fallacies apply to networking - sometimes it's time to let the old pile of **** die and replace it with something created in this decade.
If You Worry About 768K Day, You’re Probably Doing Something Wrong
A few years ago we “celebrated” 512K day - the size of the full Internet routing table exceeded 512K (for whatever value of K ;) prefixes, overflowing TCAMs in some IP routers and resulting in interesting brownouts.
We’re close to exceeding 768K mark and the beware 768K day blog posts have already started appearing. While you (RFC 2119) SHOULD check the size of your forwarding table and the maximum capabilities of your hardware, the more important question should be “Why do I need 768K forwarding entries if I’m not a Tier-1 provider”
How Hard Is It to Manage Your Intent?
This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.
Remember the “every device configuration is really an expression of our intent” discussion? Forgetting the wrong level of abstraction (we mostly don’t want to deal with all the idiosyncratic stuff network devices want to see in their configurations) and box-oriented thinking caused by device-level intent for the moment, let’s focus on another aspect: how hard is it to manage your intent?
Don't Base Your Design on Vendor Marketing
Remember how Arista promoted VXLAN coupled with deep buffer switches as the perfect DCI solution a few years ago? Someone took Arista’s marketing too literally, ran with the idea and combined VXLAN-based DCI with traditional MLAG+STP data center fabric.
While I love that they wrote a blog post documenting their experience (if only more people would do that), it doesn’t change the fact that the design contains the worst of both worlds.
Here are just a few things that went wrong:
Data Deduplication in Network Automation Data Models
One of the toughest challenges in the hands-on part of Building Network Automation Solutions online course is the create a data model describing your service exercise.
Networking engineers never had to think about data models describing their networks or services, and the first attempt often results in something that looks like simplified device configuration in YAML or JSON format.
I wrote a long article describing how you can slowly redesign your box-focused data model into a network-focused one. The first parts describing the problem and initial deduplication are already online.
Microsoft Azure Networking Slide Deck Is Ready
After a few weeks of venting my frustrations on Twitter I finally completed Microsoft Azure Networking slide deck last week and published the related demos on GitHub.
I will use the slide deck in a day-long workshop in Zurich (Switzerland) on June 12th and run a series of live webinar sessions in autumn. If you’re a (paid) subscriber you can already download the slides and it would be great if you’d have time to attend the Zurich workshop – it’s infinitely better to discuss interesting challenges face-to-face than to type questions in a virtual classroom.
Programmable Packet Forwarding Pipelines Using P4 on Software Gone Wild
Every time a new simple programming language is invented, we go through the same predictable cycle:
- Tons of hype;
- Unbounded enthusiasm when people who never worked in target environment realize they could get something simple done in a short time;
- Ever-worsening headaches as the enthusiasts try to get a real job done with the shiny new tool;
- Disappointment;
- A more powerful language is invented to replace the old one.
A few years ago we experienced the same cycle when OpenFlow was the-one-tool-to-bind-them all.
Stop the Low-Level Configuration Manipulation
This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.
Imagine a small bank deciding in their infinite wisdom (in reality: because their CIO attended a conference organized by a database vendor) to implement their banking software by teaching bank tellers how to type SQL transactions by hand.
For example, to transfer money from one account to another account, a bank teller could simply type:
Bathwater and Hyperscalers
Russ White recently wrote an interesting blog post claiming how we should not ignore any particular technology just because it was invented by a hyperscaler illustrating his point with a half-dozen technologies that were first used by NASA.
However, there are “a few” details he glossed over:
Building Fabric Infrastructure for an OpenStack Private Cloud
An attendee in my Building Next-Generation Data Center online course was asked to deploy numerous relatively small OpenStack cloud instances and wanted select the optimum virtual networking technology. Not surprisingly, every $vendor had just the right answer, including Arista:
We’re considering moving from hypervisor-based overlays to ToR-based overlays using Arista’s CVX for approximately 2000 VLANs.
As I explained in Overlay Virtual Networking, Networking in Private and Public Clouds and Designing Private Cloud Infrastructure (plus several presentations) you have three options to implement virtual networking in private clouds:
Automating Brownfield Environments (Using an 802.1x Example)
This is a guest blog post by Albert Siersema, senior network and cloud engineer at Mediacaster.nl. He’s always busy broadening his horizons and helping his customers in (re)designing and automating their infrastructure deployment and management.
This is the second post in a series focused primarily on brownfield automation principles using 802.1x deployments as an example (you might want to read part 1 first).
Before diving into the specifics of the next 802.1x automation phase, let’s take a step back and think about why we’re going through this effort. Automation is a wonderful tool, but it’s not a goal… and neither is 802.1x a goal - it’s just another tool that can help us realize business benefits like:
Worth Reading: Nothing Fails Like Success
I hope I'm still allowed to quote a paragraph from someone else's article (thank you, EU, you did a great job). Here's what Jeffrey Zeldman wrote about startup business models:
A family buys a house they can’t afford. They can’t make their monthly mortgage payments, so they borrow money from the Mob. Now they’re in debt to the bank and the Mob, live in fear of losing their home, and must do whatever their creditors tell them to do.
Read the article and think about how it applies to unicorn-based networking technologies ;)
Feedback: Data Center Interconnects
Got this feedback from a networking engineer watching the Data Center Interconnects webinar:
This webinar is an excellent overview regarding current DCI design challenges. I would highly recommend to watch it for anyone working in the networking and datacenter space. Sober networkers should watch it thoughtfully at least two times. L2 DCI fans should watch it once in a month, until reaching a solid grasp.
If only life would be as easy as that ;) Most people prefer to be blissfully ignorant of the infrastructure supporting their business, while at the same time pretending they know an awful lot about other people's jobs (see also: Dunning-Kruger effect)
Automation Should Prevent Operator Errors
This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.
One of the toughest tasks faced by networking engineers attending our Building Network Automation Solutions course is designing a data model describing network infrastructure or services. They usually think in terms of individual devices (nodes) resulting in tons of duplicated data.
I always point that out when reviewing their solutions and suggest how to minimize or eliminate duplicate data. Not surprisingly, doing that is hard, and one of the attendees started wondering whether the extra effort makes sense:
Real-Life Data Center Meltdown
A good friend of mine who prefers to stay A. Nonymous for obvious reasons sent me his “how I lost my data center to a broadcast storm” story. Enjoy!
Small-ish data center with several hundred racks. Row of racks supported by an end-of-row stack. Each stack with 2 x L2 EtherChannels, one EC to each of 2 core switches. The inter-switch link details don’t matter other than to highlight “sprawling L2 domains."
VLAN pruning was used to limit L2 scope, but a few VLANs went everywhere, including the management VLAN.
Building Automation Device Inventory with Open Source Tools
This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.
One of the common questions we get in the Building Network Automation Solutions online course is “how do I create device inventory if I don’t know (exactly) what devices are in my network?”… prompting one of the guest speakers to reply “could it really be that bad?” (yes, sometimes it is).
Some of the students tried to solve the challenge with Ansible. While that might eventually work (given enough effort), Ansible definitely isn’t the right tool for the job.
What you need to get the job done is a proper toolchain:
Now Boarding: Autumn 2019 Network Automation Online Course
Ladies and gentlemen, our Autumn 2019 Building Network Automation Solutions online course is now ready for boarding. Please make sure you have your boarding passes ready, board at your convenience, and start enjoying the pre-flight perks like over hundred hours of self-study materials.
Our flight will depart on September 3rd with subsequent sessions on September 26th, October 24th and November 12th. The guest speakers will focus on security, inventory managements, and describe their production deployments. More in a few days…
The only thing you have to do at this moment is to register (if you want to get the Enthusiast price… otherwise please feel free to wait ;)
And just in case you’re wondering: yes, I was sitting at an airport while writing this blog post ;))
Worth Reading: Top Ten Things Executives Should Know About Software
Tom Limoncelly wrote another must-read ACM Queue article: Top Ten Things Executives Should Know About Software. If only someone as eloquent as Tom would write a networking equivalent...
Automation Solution: Find Source of STP Topology Changes
Topology changes are a bane of large STP-based networks, and when they become a serious challenge you could probably use a tool that could track down what’s causing them.
I’m sure there’s a network management tool out there that can do just that (please write a comment if you know one); Eder Gernot decided to write his own while working on a hands-on assignment in the Building Network Automation Solutions online course. Like most course attendees he published the code on GitHub and might appreciate pull requests ;)
Wonder what else course attendees created in the past? Here’s a small sample.