netlab 1.8.3: RIPv2, BGP Route Servers
During the ITNOG8 netlab presentation, I jokingly said something along the lines “all that’s missing is RIPv2 and Babel.” That’s no longer true; someone asked me how hard it would be to add RIPv2 to netlab, and I said, “give me a few days 😎”
Other new features in netlab release 1.8.3 include support for BGP route servers (and route server clients), BGP Link Bandwidth community, and OSPF/BGP validation plugins for Arista EOS, Cumulus Linux and FRR. We also fixed the installation scripts to work with Ubuntu 24.04 and Debian Bookworm.
For more details, read the release notes.
netlab 1.8.3: RIPv2, BGP Route Servers
During the ITNOG8 netlab presentation, I jokingly said something along the lines “all that’s missing is RIPv2 and Babel.” That’s no longer true; someone asked me how hard it would be to add RIPv2 to netlab, and I said, “give me a few days 😎”
Other new features in netlab release 1.8.3 include support for BGP route servers (and route server clients), BGP Link Bandwidth community, and OSPF/BGP validation plugins for Arista EOS, Cumulus Linux and FRR. We also fixed the installation scripts to work with Ubuntu 24.04 and Debian Bookworm.
For more details, read the release notes.
Worth Reading: Cisco SD-Access and IoT Devices
Dan Massameno wrote a series of blog posts describing the challenges you might encounter when connecting Internet-of-Things1 devices to a Cisco SD-Access network. It is an absolute must-read if you have to deal with IoT devices.
-
Reading some of his caveats, you’ll quickly confirm the alternate meaning of the IoT acronym: Internet-of-Trash. ↩︎
Worth Reading: Cisco SD-Access and IoT Devices
Dan Massameno wrote a series of blog posts describing the challenges you might encounter when connecting Internet-of-Things1 devices to a Cisco SD-Access network. It is an absolute must-read if you have to deal with IoT devices.
-
Reading some of his caveats, you’ll quickly confirm the alternate meaning of the IoT acronym: Internet-of-Trash. ↩︎
The Mythical Use Cases: Traffic Engineering for Data Center Backups
Vendor product managers love discussing mythical use cases to warrant complex functionality in their gear. Long-distance VM mobility was one of those (using it for disaster avoidance was Mission Impossible under any real-world assumptions), and high-volume network-based backups seems to be another. Here’s what someone had to say about that particular unicorn in a LinkedIn comment when discussing whether we need traffic engineering in a data center fabric.
When you’re dealing with a large cluster on a fabric, you will see things like inband backup. The most common one I’ve seen is VEEAM. Those inband backups can flood a single link, and no amount of link scheduling really solves that; depending on the source, they can saturate 100G. There are a couple of solutions; IPv6 or eBGP SID has been used to avoid these links or schedule avoidance for other traffic.
It is true that (A) in-band backups can be bandwidth intensive and that (B) well-written applications can saturate 100G server links. However:
The Mythical Use Cases: Traffic Engineering for Data Center Backups
Vendor product managers love discussing mythical use cases to warrant complex functionality in their gear. Long-distance VM mobility was one of those (using it for disaster avoidance was Mission Impossible under any real-world assumptions), and high-volume network-based backups seems to be another. Here’s what someone had to say about that particular unicorn in a LinkedIn comment when discussing whether we need traffic engineering in a data center fabric.
When you’re dealing with a large cluster on a fabric, you will see things like inband backup. The most common one I’ve seen is VEEAM. Those inband backups can flood a single link, and no amount of link scheduling really solves that; depending on the source, they can saturate 100G. There are a couple of solutions; IPv6 or eBGP SID has been used to avoid these links or schedule avoidance for other traffic.
It is true that (A) in-band backups can be bandwidth intensive and that (B) well-written applications can saturate 100G server links. However:
Worth Reading: Not Just Scale
Marc Brooker published an interesting blog post arguing that we need distributed systems for more than just scale.
Keep that in mind the next time someone tries to sell you the beauties of a centralized control plane – an idea that should be dead by now regardless of what ONF keeps preaching but will inevitably reappear in some form or other due to RFC 1925 Rule 11.
Worth Reading: Not Just Scale
Marc Brooker published an interesting blog post arguing that we need distributed systems for more than just scale.
Keep that in mind the next time someone tries to sell you the beauties of a centralized control plane – an idea that should be dead by now regardless of what ONF keeps preaching but will inevitably reappear in some form or other due to RFC 1925 Rule 11.
Worth Exploring: Infrahub by Opsmill
A year or two after Damien Garros told me that “he moved to France and is working on something new” we can admire the results: Infrahub, a version-control-based system that includes a data store and a repository of all source code you use in your network automation environment. Or, straight from the GitHub repository,
A central hub to manage the data, templates and playbooks that powers your infrastructure by combining the version control and branch management capabilities of Git with the flexible data model and UI of a graph database.
I’ve seen an early demo, and it looks highly promising and absolutely worth exploring. Have fun ;)
Fun fact: the OpsMill team includes two guest speakers in the ipSpace.net automation course and a netlab contributor.
Worth Exploring: Infrahub by Opsmill
A year or two after Damien Garros told me that “he moved to France and is working on something new” we can admire the results: Infrahub, a version-control-based system that includes a data store and a repository of all source code you use in your network automation environment. Or, straight from the GitHub repository,
A central hub to manage the data, templates and playbooks that powers your infrastructure by combining the version control and branch management capabilities of Git with the flexible data model and UI of a graph database.
I’ve seen an early demo, and it looks highly promising and absolutely worth exploring. Have fun ;)
Fun fact: the OpsMill team includes two guest speakers in the ipSpace.net automation course and a netlab contributor.
Public Videos: Network Automation 101
You can access the Network Automation 101 videos without registration. Hope you’ll find them useful if you’re just starting your network automation journey.
Worth Reading: ChatGPT Does Not Summarize
I mostly gave up on LLMs being any help (apart from generating copious amounts of bullshit), but I still thought that generating summaries might be an interesting use case. I was wrong.
As Gerben Wierda explains in his recent “When ChatGPT summarises, it actually does nothing of the kind” blog post, you have to understand a text if you want to generate a useful summary, and that’s not what LLMs do. They can generate a shorter version of the text, which might not focus on the significant bits.
Worth Reading: ChatGPT Does Not Summarize
I mostly gave up on LLMs being any help (apart from generating copious amounts of bullshit), but I still thought that generating summaries might be an interesting use case. I was wrong.
As Gerben Wierda explains in his recent “When ChatGPT summarises, it actually does nothing of the kind” blog post, you have to understand a text if you want to generate a useful summary, and that’s not what LLMs do. They can generate a shorter version of the text, which might not focus on the significant bits.
BGP Labs: Graceful Shutdown
Using the typical default router configurations, it can take minutes between a failure of an inter-AS link and the convergence of BGP routes. You can fine-tune that behavior with BGP timers and BFD (and still get pwned by Graceful Restart). While you can’t influence link failures, you could drain the traffic from a link before starting maintenance operations on it, and it would be a shame not to do that considering there’s a standard way to do that – the GRACEFUL_SHUTDOWN BGP community defined in RFC 8326. That’s what you’ll practice in the next BGP lab exercise.
BGP Labs: Graceful Shutdown
Using the typical default router configurations, it can take minutes between a failure of an inter-AS link and the convergence of BGP routes. You can fine-tune that behavior with BGP timers and BFD (and still get pwned by Graceful Restart). While you can’t influence link failures, you could drain the traffic from a link before starting maintenance operations on it, and it would be a shame not to do that considering there’s a standard way to do that – the GRACEFUL_SHUTDOWN BGP community defined in RFC 8326. That’s what you’ll practice in the next BGP lab exercise.
Must Read: Make Two Trips
Tom Limoncelli wrote another must-read masterpiece: sometimes you’ll save time if you make two trips instead of one.
The same lesson applies to network design: cramming too many features into a single device will inevitably result in complex, hard-to-understand configurations and weird bugs. Sometimes, it’s cheaper to split the required functionality across multiple devices.
Must Read: Make Two Trips
Tom Limoncelli wrote another must-read masterpiece: sometimes you’ll save time if you make two trips instead of one.
The same lesson applies to network design: cramming too many features into a single device will inevitably result in complex, hard-to-understand configurations and weird bugs. Sometimes, it’s cheaper to split the required functionality across multiple devices.
BGP Route Reflectors Considered Harmful
The recent IBGP Full Mesh Between EVPN Leaf Switches blog post generated an interesting discussion on LinkedIn focused on whether we need route reflectors (in small fabrics) and whether they do more harm than good. Here are some of the highlights of that discussion, together with a running commentary.
Please note that we’re talking about BGP route reflectors in reasonably small data center fabrics. Large service provider networks with millions of customer VPN routes are a completely different story. As always, what you read in a random blog post might not apply to your network design. YMMV.
BGP Route Reflectors Considered Harmful
The recent IBGP Full Mesh Between EVPN Leaf Switches blog post generated an interesting discussion on LinkedIn focused on whether we need route reflectors (in small fabrics) and whether they do more harm than good. Here are some of the highlights of that discussion, together with a running commentary.
Please note that we’re talking about BGP route reflectors in reasonably small data center fabrics. Large service provider networks with millions of customer VPN routes are a completely different story. As always, what you read in a random blog post might not apply to your network design. YMMV.
Testing Device Configuration Templates
Many network automation solutions generate device configurations from a data model and deploy those configurations. Last week, we focused on “how do we know the device data model is correct?” This time, we’ll take a step further and ask ourselves, “how do we know the device configurations work as expected?”
There are four (increasingly complex) questions our tests should answer: