Rant: Don’t Ever Compare Enterprise IT Shenanigans with Apollo 13

Here’s a recent tweet by my friend Joe Onisick that triggered this blog post:

My favorite people are the ones that start with “how could we make that work?” Before jumping into all of their preconceived bs on why it won’t work.

I couldn’t agree more with that sentiment. The number of people who would invent all sorts of excuses just to avoid turning on their brains and keep to their cozy old methods is staggering. Unfortunately, someone immediately had the urge to switch into what I understood to be a heroic MacGyver mode (or maybe it was just my lack of caffeine, in which case I apologize for the misquote… but you might still like the rest of the rant):

Worth Reading: Internet of Trash

I love the recent Internet of Trash article by Geoff Huston, in particular this bit:

“Move fast and break things” is not a tenable paradigm for this industry today, if it ever was. In the light of our experience with the outcomes of an industry that became fixated on pumping out minimally viable product, it’s a paradigm that heads towards what we would conventionally label as criminal negligence.

Of course it’s not just the Internet-of-Trash. Whole IT is filled with examples of startups and “venerable” companies doing the same thing and boasting about their disruptiveness. Now go and read the whole article ;)

Worth Reading: Internet of Trash

I love the recent Internet of Trash article by Geoff Huston, in particular this bit:

“Move fast and break things” is not a tenable paradigm for this industry today, if it ever was. In the light of our experience with the outcomes of an industry that became fixated on pumping out minimally viable product, it’s a paradigm that heads towards what we would conventionally label as criminal negligence.

Of course it’s not just the Internet-of-Trash. Whole IT is filled with examples of startups and “venerable” companies doing the same thing and boasting about their disruptiveness. Now go and read the whole article ;)

Worth Reading: Advice(s) for Engineering Managers

Just in case you were recently promoted to be a team leader or a manager: read these somewhat-tongue-in-cheek advices:

• How do I feel worthwhile as a manager when my people are doing all the implementing? by Charity Majors
• The Non-psychopath’s Guide to Managing an Open-source Project by Kode Vicious.

Need more career advice? How about The Six Year Rule by Bryan Sullins… or you could go and reread my certifications-related blog posts.

Worth Reading: Advice(s) for Engineering Managers

Just in case you were recently promoted to be a team leader or a manager: read these somewhat-tongue-in-cheek advices:

• How do I feel worthwhile as a manager when my people are doing all the implementing? by Charity Majors
• The Non-psychopath’s Guide to Managing an Open-source Project by Kode Vicious.

Need more career advice? How about The Six Year Rule by Bryan Sullins… or you could go and reread my certifications-related blog posts.

Video: Cisco SD-WAN Policies Review

The second part of the Cisco SD-WAN webinar focused on design considerations and trade-offs in several scenarios. David Penaloza briefly reviewed the types of policies and their capabilities before discussing what to keep in mind when designing the solution.

Video: Cisco SD-WAN Policies Review

The second part of the Cisco SD-WAN webinar focused on design considerations and trade-offs in several scenarios. David Penaloza briefly reviewed the types of policies and their capabilities before discussing what to keep in mind when designing the solution.

Repost: On the Importance of Line-Rate Switching of Small Packets

I made a flippant remark in a blog comment…

While it’s academically stimulating to think about forwarding small packets (and applicable to large-scale VoIP networks), most environments don’t have to deal with those. Looks like it’s such a non-issue that I couldn’t find recent data; in the good old days ~50% of the packets were 1500 byte long.

… and Minh Ha (by now a regular contributor to my blog) quickly set me straight with a lengthy comment that’s too good to be hidden somewhere at the bottom of a page. Here it is (slightly edited). Also, you might want to read other comments to the original blog post for context.

Repost: On the Importance of Line-Rate Switching of Small Packets

I made a flippant remark in a blog comment…

While it’s academically stimulating to think about forwarding small packets (and applicable to large-scale VoIP networks), most environments don’t have to deal with those. Looks like it’s such a non-issue that I couldn’t find recent data; in the good old days ~50% of the packets were 1500 byte long.

… and Minh Ha (by now a regular contributor to my blog) quickly set me straight with a lengthy comment that’s too good to be hidden somewhere at the bottom of a page. Here it is (slightly edited). Also, you might want to read other comments to the original blog post for context.

State Consistency in Distributed SDN Controller Clusters

Every now and then I get a question along the lines of “why can’t we have a distributed SDN controller (because resiliency) that would survive network partitioning?” This time, it’s not the incompetency of solution architects or programmers, but the fundamental limitations of what can be done when you want to have consistent state across a distributed system.

TL&DR: If your first thought was CAP Theorem you’re absolutely right. You can probably stop reading right now. If you have no idea what I’m talking about, maybe it’s time you get fluent in distributed systems concepts after you’re finished with this blog post and all the reference material linked in it. Don’t know where to start? I put together a list of resources I found useful.

State Consistency in Distributed SDN Controller Clusters

Every now and then I get a question along the lines of “why can’t we have a distributed SDN controller (because resiliency) that would survive network partitioning?” This time, it’s not the incompetency of solution architects or programmers, but the fundamental limitations of what can be done when you want to have consistent state across a distributed system.

TL&DR: If your first thought was CAP Theorem you’re absolutely right. You can probably stop reading right now. If you have no idea what I’m talking about, maybe it’s time you get fluent in distributed systems concepts after you’re finished with this blog post and all the reference material linked in it. Don’t know where to start? I put together a list of resources I found useful.

Demonstrate Small Automation Wins

Long long time ago in a country far far away when traveling was still a thing I led an interesting data center fabric design workshop. We covered tons of interesting topics, including automating network services deployments (starting with VLAN self-service for server admins).

As was often the case in my workshops, we had representatives from multiple IT teams sitting in the room, and when I started explaining how I’d automate VLAN deployments, the server administrator participating in the workshop quickly chimed in: “that’s exactly how I implemented self-service for some of our customers, it makes perfect sense to use the same approach for server port and VLAN provisioning”, and everyone else in the room agreed… apart from the networking engineer, who used a counter-argument along the lines of “we only provision a new VLAN or server port every few days, we can do it by hand” and no amount of persuasion would move him.

Demonstrate Small Automation Wins

Long long time ago in a country far far away when traveling was still a thing I led an interesting data center fabric design workshop. We covered tons of interesting topics, including automating network services deployments (starting with VLAN self-service for server admins).

As was often the case in my workshops, we had representatives from multiple IT teams sitting in the room, and when I started explaining how I’d automate VLAN deployments, the server administrator participating in the workshop quickly chimed in: “that’s exactly how I implemented self-service for some of our customers, it makes perfect sense to use the same approach for server port and VLAN provisioning”, and everyone else in the room agreed… apart from the networking engineer, who used a counter-argument along the lines of “we only provision a new VLAN or server port every few days, we can do it by hand” and no amount of persuasion would move him.

OMG, It’s Graphs Everywhere

One of the subscribers watching the Graph Algorithms in Networks webinar found the webinar had an interesting impact on his perspective (according to his feedback):

This is genuine content that I haven’t seen anywhere else. It helps to get up to speed on computer science topics that are relevant to network professionals. After attending this webinar, I couldn’t unsee the graphs anymore that are almost everywhere in networking.

This webinar is available with Standard ipSpace.net Subscription as are other webinars by Rachel Traylor including Network Connectivity, Graph Theory, and Reliable Network Design, Queuing Theory and Reliability Theory: Networking through a Systems Analysis Lens. She’ll be back next week starting a series of deep dives into reliability topics. Hope you’ll enjoy them as much as our subscriber did the Graph Algorithms webinar.

OMG, It’s Graphs Everywhere

One of the subscribers watching the Graph Algorithms in Networks webinar found the webinar had an interesting impact on his perspective (according to his feedback):

This is genuine content that I haven’t seen anywhere else. It helps to get up to speed on computer science topics that are relevant to network professionals. After attending this webinar, I couldn’t unsee the graphs anymore that are almost everywhere in networking.

This webinar is available with Standard ipSpace.net Subscription as are other webinars by Rachel Traylor including Network Connectivity, Graph Theory, and Reliable Network Design, Queuing Theory and Reliability Theory: Networking through a Systems Analysis Lens. She’ll be back next week starting a series of deep dives into reliability topics. Hope you’ll enjoy them as much as our subscriber did the Graph Algorithms webinar.

Worth Reading: Visualizing BGP-LS Tables

When I’d first seen BGP-LS I immediately thought: “it would be cool to use this to fetch link state topology data from the network and build a graph out of it”. In those days the only open-source way I could find to do it involved Open DayLight controller’s BGP-LS-to-REST-API converter, and that felt like deploying an aircraft carrier to fly a kite.

Things have improved dramatically since then. In Visualizing BGP-LS Tables, HB described how he solved the challenge with GoBGP, gRPC interface to GoBGP, and some Python code to parse the data and draw the topology graph with NetworkX. Enjoy!

Worth Reading: Visualizing BGP-LS Tables

When I’d first seen BGP-LS I immediately thought: “it would be cool to use this to fetch link state topology data from the network and build a graph out of it”. In those days the only open-source way I could find to do it involved Open DayLight controller’s BGP-LS-to-REST-API converter, and that felt like deploying an aircraft carrier to fly a kite.

Things have improved dramatically since then. In Visualizing BGP-LS Tables, HB described how he solved the challenge with GoBGP, gRPC interface to GoBGP, and some Python code to parse the data and draw the topology graph with NetworkX. Enjoy!

Worth Reading: Finding Bugs in C and C++ Compilers

Something to keep in mind before you start complaining about the crappy state of network operating systems: people are still finding hundreds of bugs in C and C++ compilers.

One might argue that compilers are even more mission-critical than network devices, they’ve been around for quite a while, and there might be more people using compilers than configuring network devices, so one would expect compilers to be relatively bug-free. Still, optimizing compilers became ridiculously complex in the past decades trying to squeeze the most out of the ever-more-complex CPU hardware, and we’re paying the price.

Keep that in mind the next time a vendor dances by with a glitzy slide deck promising software-defined nirvana.

Worth Reading: Finding Bugs in C and C++ Compilers

Something to keep in mind before you start complaining about the crappy state of network operating systems: people are still finding hundreds of bugs in C and C++ compilers.

One might argue that compilers are even more mission-critical than network devices, they’ve been around for quite a while, and there might be more people using compilers than configuring network devices, so one would expect compilers to be relatively bug-free. Still, optimizing compilers became ridiculously complex in the past decades trying to squeeze the most out of the ever-more-complex CPU hardware, and we’re paying the price.

Keep that in mind the next time a vendor dances by with a glitzy slide deck promising software-defined nirvana.

Video: Finding Paths Across the Network

Regardless of the technology used to get packets across the network, someone has to know how to get from sender to receiver(s), and as always you have multiple options:

• Almighty controller
• On-demand dynamic path discovery (example: probing)
• Participation in a routing protocol

For more details, watch Finding Paths Across the Network video.