Brian Krebs wrote an interesting analysis of CIA’s Wikileaks report. In a nutshell, they were a victim of “move fast to get the mission done” shadow IT.
It could have been worse. Someone with a credit card could have started deploying stuff in AWS ;))
Not that anyone would learn anything from the PR nightmare that followed.
A while ago Russ White invited me to be a guest on his fantastic History of Networking podcast, and we spent almost an hour talking about networking in 1980s and 1990s in what some people love to call “behind iron curtain” (we also fixed that misconception).
One of the readers commenting the ideas in my Disaster Recovery and Failure Domains blog post effectively said “In an active/passive DR scenario, having L3 DCI separation doesn’t protect you from STP loop/flood in your active DC, so why do you care?”
He’s absolutely right - if you have a cold disaster recovery site, it doesn’t matter if it’s bombarded by a gazillion flooded packets per second… but how often do you have a cold recovery site?
Michael Mullany analyzed 20 years of Gartner hype cycles and got some (expected but still interesting) conclusions including:
Enjoy the reading, and keep these lessons in mind the next time you’ll be sitting in a software-defined, intent-based or machine-learning $vendor presentation.
I claimed that “EVPN is the control plane for layer-2 and layer-3 VPNs” in the Using VXLAN and EVPN to Build Active-Active Data Centers interview a long long while ago and got this response from one of the readers:
To me, that doesn’t compute. For layer-3 VPNs I couldn’t care less about EVPN, they have their own control planes.
Apart from EVPN, there’s a single standardized scalable control plane for layer-3 VPNs: BGP VPNv4 address family using MPLS labels. Maybe EVPN could be a better solution (opinions differ, see EVPN Technical Deep Dive webinar for more details).
This blog post was initially sent to the subscribers of my SDN and Network Automation mailing list. Subscribe here.
In late 2018 Juniper started aggressively promoting Network Reliability Engineering - the networking variant of concepts of software-driven operations derived from GIFEE SRE concept (because it must make perfect sense to mimic whatever Google is doing, right?).
There’s nothing wrong with promoting network automation, or infrastructure-as-code concepts, and Matt Oswalt and his team did an awesome job with NRE Labs (huge “Thank you!” to whoever is financing them), but is that really all NRE should be?
In early May 2020 I wrote a blog post introducing SuzieQ, a network observability platform Dinesh Dutt worked on for the last few years. If that blog post made you look for more details, you might like the Episode 111 of Software Gone Wild in which we went deeper and covered these topics:
Regular readers of my blog probably remember the detailed explanations Erik Auerswald creates while solving hands-on exercises from our Networking in Public Cloud Deployments online course (previous ones: create a virtual network, deploy a web server).
This time he documented the process he went through to develop a Terraform configuration file that deploys full-blown AWS networking infrastructure (VPC, subnets, Internet gateway, route tables, security groups) and multiple servers include an SSH bastion host. You’ll also see what he found out when he used Elastic Network Interfaces (spoiler: routing on multi-interface hosts is tough).
A network architect friend of mine sent me a series of questions trying to figure out how he should approach network automation, and how deep he should go.
There is so much focus right now on network automation, but it’s difficult for me to know how to apply it, and how it all makes sense from an Architect’s PoV.
A network architect should be the bridge between the customer requirements and the underlying technologies, which (in my opinion) means he has to have a good grasp of both as opposed to fluffy opinions glanced from vendor white papers, or brushed off so-called thought leaders.
There’s one thing no cloud vendor ever managed to change: virtual machines running on top of cloud infrastructure expect to have Ethernet interfaces.
It doesn’t matter if the virtual Ethernet Network Interface Cards (NICs) are implemented with software emulation of actual hardware (VMware emulated the ancient Novell NE1000 NIC) or with paravirtual drivers - the virtual machines expect to send and receive Ethernet frames. What happens beyond the Ethernet NIC depends on the cloud implementation details.
A long while ago I decided to write an article explaining how you could run VMware NSX on ESXi servers with redundant connections to two top-of-rack switches on top of a layer-3-only fabric (a fabric with IP subnets and VLANs limited to a single top-of-rack switch). Turns out that’s Mission Impossible, so I put the article on the back burner and slowly forgot about it.
Well, not exactly. Every now and then my subconsciousness would kick it up and I’d figure out yet-another reason why it’s REALLY hard to do it right. After a while, I decided to try again, and completely rewrote the article. The first part is already online, more details coming (hopefully) soon.
Every few years someone within the ITU-T (the standard organization that mattered when we were still dealing with phones, virtual circuits and modems) realizes how obsolete they are and tries to hijack and/or fork the Internet protocol development. Their latest attempt is the “New IP” framework, and Geoff Huston did a great job completely tearing that stupidity apart in his May 2020 ISP column. My favorite quote:
It’s really not up to some crusty international committee to dictate future consumer preferences. Time and time again these committees with their lofty titles, such as “the Focus Group on Technologies for Network 2030” have been distinguished by their innate ability to see their considered prognostications comprehensively contradicted by reality! Their forebears in similar committees missed computer mainframes, then they failed to see the personal computer revolution, and were then totally surprised by the smartphone.
Enjoy!
Donal O Duibhir was trying to get me to present at INOG for ages, and as much as I’d love to get to Ireland we always had a scheduling conflict.
Last week we finally made it work - unfortunately only in a virtual event, so I got none of the famous Irish beer - and the video about alternate universes of public cloud networking is already online.
Maximilian Wilhelm had great fun turning my usual black-and-white statements into tweets, here’s a selection of them:
CloudFlare launched yet another service: transfer speed- and latency measurements done from a web browser. While it’s pretty obvious how you could measure transfer speed (start an asynchronous transfer, register for the JavaScript onreadystatechange event to notice out when it has completed, and compute the transfer rate), measuring latency seems like a bit of black magic. After all, you can’t do a ping from a web browser, can you?
IPv6 is old enough to buy its own beer (in US, not just in Europe), but there are still tons of naysayers explaining how hard it is to deploy. That’s probably true if you’re forced to work with decades-old boxes, or if you handcrafted your environment with a gazillion clicks in a fancy GUI, but if you used Terraform to deploy your application in AWS, it’s as hard as adding a few extra lines in your configuration files.
Nadeem Lughmani did a great job documenting the exact changes needed to get IPv6 working in AWS VPC, including adjusting the IPv6 routing tables, and security groups. Enjoy ;)
On May 14th 2020, Marcel Gamma, tech industry journalist, and editor-in-chief at inside-it.ch and inside-channels.ch, published an article discussing several glaring security vulnerabilities in Silver Peak’s SD-WAN products on inside-it.ch. The original article was written in German; Marcel was kind enough to translate it into English and get permission from his publisher to have the English version published on ipSpace.net.
Security researchers make serious accusations against SD-Wan manufacturer Silver Peak. The latter disagrees. Swiss experts are analyzing the case.
By Marcel Gamma,
Silver Peak is accused of laxity in dealing with security issues and in dealing with security researchers who act within the framework of Responsible Disclosure.
One of the attendees in our Building Network Automation Solutions online course sent me this question:
While building an automation tool using Python for CLI provisioning, is it a good idea to use SDK provided by device vendor, or use simple SSH libraries Netmiko/Paramiko and build all features (like rollback-on-failure, or error handling, or bulk provisioning) yourself.
The golden rule of software development should be “don’t reinvent the wheel”… but then maybe you need tracks to navigate in the mud and all you can get are racing slicks, and it might not make sense to try to force-fit them into your use case, so we’re back to “it depends”.
Loved the article from Philip Laplante about environmental antipatterns. I’ve seen plenty of founderitis and shoeless children in my life, but it was worshipping the golden calf that made me LOL:
In any environment where there is poor vision or leadership, it is often convenient to lay one’s hopes on a technology or a methodology about which little is known, thereby providing a hope for some miracle. Since no one really understands the technology, methodology, or practice, it is difficult to dismiss. This is an environmental antipattern because it is based on a collective suspension of disbelief and greed, which couldn’t be sustained by one or a few individuals embracing the ridiculous.
That paragraph totally describes the belief in the magical powers of long-distance vMotion, SDN (I published a whole book debunking its magical powers), building networks like Google does it, intent-based whatever, machine learning…
Pete Lumbis started his Cumulus Linux 4.0 update with an overview of differences between Cumulus Linux on hardware switches and Cumulus VX, and continued with an in-depth list of ASIC families supported by Cumulus Linux.
You can watch his presentation, as well as the more in-depth overview of Cumulus Linux concepts by Dinesh Dutt, in the recently-updated What Is Cumulus Linux All About video.
It’s amazing how sometimes people fond of sharing their opinions and buzzwords on various social media can’t answer simple questions. Today’s blog post is based on a true story… a “senior network architect” fully engaged in a recent hype cycle couldn’t answer a simple question:
Why exactly would you need VXLAN and EVPN?
We could spend a day (or a week) discussing the nuances of that simple question, but all I have at the moment is a single web page, so here we go…