I usually say that you cannot run netlab on Apple silicon because the vendors don’t provide ARM images. However, when I saw an ARM version of the FRRouting container, I started wondering whether I could run the BGP labs (admittedly only on FRR containers) on my M2 MacBook Pro.
TL&DR: Yes, you can do that.
Now for the recipe:
The March 2024 Internet Protocol Journal has a lengthy article on the history and “future” of Ethernet that might be worth reading (although it’s short on details) if you weren’t around when it all started.
The March 2024 Internet Protocol Journal has a lengthy article on the history and “future” of Ethernet that might be worth reading (although it’s short on details) if you weren’t around when it all started.
What if I tell you that all you need is just a YAML file with just a bunch of lines to create a Network Lab that can run easily on your laptop? You'd call me crazy, right?
Well, in this blog post, I'll walk you through what Containerlab is and how it can simplify creating and managing your labs with ease. Let's dive in.
What we will cover?
Suresh Vina
The official definition is "Containerlab provides a CLI for orchestrating and managing container-based networking labs. It starts the containers, builds a virtual wiring between them to create lab topologies of users choice and manages labs lifecycle."
Simply put, containerlab is a Lab-as-a-code tool that helps you set up and manage your network labs easily. Instead of dealing with complex setups and configurations, containerlab simplifies everything for you. Continue reading
Welcome to Technology Short Take #176! This Tech Short Take is a bit heavy on security-related links, but there’s still some additional content in a number of other areas, so you should be able to find something useful—or at least interesting—in here. Thanks for reading!
Urs Baumann invited me to have a guest lecture in his network automation course, and so I had the privilege of being in lovely Rapperswil last week, talking about the basics of real-life network automation.
Urs published the video recording of the presentation on YouTube; hope you’ll like it, and if you don’t get too annoyed by the overly pushy ads, watch the other videos from his infrastructure-as-code course.
Urs Baumann invited me to have a guest lecture in his network automation course, and so I had the privilege of being in lovely Rapperswil last week, talking about the basics of real-life network automation.
Urs published the video recording of the presentation on YouTube; hope you’ll like it, and if you don’t get too annoyed by the overly pushy ads, watch the other videos from his infrastructure-as-code course.
I recently read a very interesting post on LinkedIn in which Urs Hölzle, one of the original Google network engineers, celebrated twenty years of Google network innovation. He provided links to the recent paper from Google describing how Google developed its datacentre network and how it has evolved since then. The paper describes how Google applied the Clos network topology in its datacentres and the early implementations of software-defined-networking that controlled data flows across the network.
One point that was really interesting, which came up in the comments to the article, is that Google implemented the original network routing code in Python.
Mr. Hölzle also linked to an independant research report that came out at the time. It provided the initial view of what Google was developing and is interesting to read almost 20 years after it was written.
The post History of SDN in Google’s datacentre appeared first on Open-Source Routing and Network Simulation.
We hear a lot about BGP security incidents–but what is really going on? How often do these happen, and how much damage do they do? Doug Madory, who monitors these things for Kentik, joins Russ White and Tom Ammon to talk about BGP security in the wild.
The “should we use the same vendor for fabric spines and leaves?” discussion triggered the expected counterexamples. Here’s one:
I actually have worked with a few orgs that mix vendors at both spine and leaf layer. Can’t take names but they run fairly large streaming services. To me it seems like a play to avoid vendor lock-in, drive price points down and be in front of supply chain issues.
As always, one has to keep two things in mind:
The “should we use the same vendor for fabric spines and leaves?” discussion triggered the expected counterexamples. Here’s one:
I actually have worked with a few orgs that mix vendors at both spine and leaf layer. Can’t take names but they run fairly large streaming services. To me it seems like a play to avoid vendor lock-in, drive price points down and be in front of supply chain issues.
As always, one has to keep two things in mind:
One of my readers was building a private MPLS/VPN backbone and wondered whether they should use their public AS number or a private AS number for the backbone. Usually, it doesn’t matter; the deciding point was the way they want to connect to the public Internet:
We also plan to peer with multiple external ISPs to advertise our public IP space not directly from our PE routers but from dedicated Internet Routers, adding a firewall between our PEs and external Internet routers.
They could either run BGP between the PE routers, firewall, and WAN routers (see BGP as High-Availability Protocol for more details) or run BGP across a bump-in-the-wire firewall:
One of my readers was building a private MPLS/VPN backbone and wondered whether they should use their public AS number or a private AS number for the backbone. Usually, it doesn’t matter; the deciding point was the way they want to connect to the public Internet:
We also plan to peer with multiple external ISPs to advertise our public IP space not directly from our PE routers but from dedicated Internet Routers, adding a firewall between our PEs and external Internet routers.
They could either run BGP between the PE routers, firewall, and WAN routers (see BGP as High-Availability Protocol for more details) or run BGP across a bump-in-the-wire firewall: