I ran the first webinar as an independent author almost exactly fourteen years ago1, with the first ticket sold just before New Year’s Eve. I kept focusing on individual webinars until someone asked me, “Would it be possible to buy access to everything you did?” His question effectively created the ipSpace.net subscription, with the first one sold in late 2010 (I still have the email that triggered the whole process).
My video editor sent me the perfect let’s-wrap-up-this-year video:
I wish you a few quiet days disconnected from the technology and all the best in 2024!
After procrastinating for months, I finally spent a few days cleaning up and organizing OSPF blog posts (it turns out I wrote almost 100 blog posts on the topic in the 18 years of blogging).
After procrastinating for months, I finally spent a few days cleaning up and organizing OSPF blog posts (it turns out I wrote almost 100 blog posts on the topic in the 18 years of blogging).
In the Path Failure Detection on Multi-Homed Servers blog post, I mentioned running BGP on servers as one of the best ways to detect server-to-network failures. As always, things aren’t as simple as they look, as Cathal Mooney quickly pointed out:
One annoyance is what IP address gets used by default by the system for outbound traffic. It would be nice to have a generic OS-level way to say, “This IP on lo0 should be default for outbound IP traffic unless to the connected link subnet itself.”
That’s definitely a tough nut to crack, and Cathal described a few solutions he used in the past:
In the Path Failure Detection on Multi-Homed Servers blog post, I mentioned running BGP on servers as one of the best ways to detect server-to-network failures. As always, things aren’t as simple as they look, as Cathal Mooney quickly pointed out:
One annoyance is what IP address gets used by default by the system for outbound traffic. It would be nice to have a generic OS-level way to say, “This IP on lo0 should be default for outbound IP traffic unless to the connected link subnet itself.”
That’s definitely a tough nut to crack, and Cathal described a few solutions he used in the past:
Here’s a challenge in case you get bored during the Christmas break: merge two networks running BGP (two autonomous systems) without changing anything but the configurations of the routers connecting them (the red BGP session in the diagram). I won’t give you any hints; you can discuss it in the comments or a GitHub discussion.
Hopefully, you won’t have to deal with something similar in real life, but then we know that crazy requirements trump good designs any day of the week.
Here’s a challenge in case you get bored during the Christmas break: merge two networks running BGP (two autonomous systems) without changing anything but the configurations of the routers connecting them (the red BGP session in the diagram). I won’t give you any hints; you can discuss it in the comments or a GitHub discussion.
Hopefully, you won’t have to deal with something similar in real life, but then we know that crazy requirements trump good designs any day of the week.
A while ago, Chris Parker published a nice blog post explaining how to configure unnumbered interfaces with IS-IS in Junos. It’s well worth reading, but like my Unnumbered Ethernet Interfaces blog post, it only covers one network operating system. What if you want to do something similar on another platform?
How about using the collective efforts of the team developing device configuration templates for netlab? As of December 2023 netlab supports:
A while ago, Chris Parker published a nice blog post explaining how to configure unnumbered interfaces with IS-IS in Junos. It’s well worth reading, but like my Unnumbered Ethernet Interfaces blog post, it only covers one network operating system. What if you want to do something similar on another platform?
How about using the collective efforts of the team developing device configuration templates for netlab? As of December 2023 netlab supports:
Eric Hoel published a spot-on analysis of AI disruptiveness, including this gem:
The easier it is to train an AI to do something, the less economically valuable that thing is. After all, the huge supply of the thing is how the AI got so good in the first place.
TL&DR: AI can easily disrupt things that are easy to generate and thus have little value. Seeing investors trying to recoup the billions pouring into the latest fad will be fun.
Eric Hoel published a spot-on analysis of AI disruptiveness, including this gem:
The easier it is to train an AI to do something, the less economically valuable that thing is. After all, the huge supply of the thing is how the AI got so good in the first place.
TL&DR: AI can easily disrupt things that are easy to generate and thus have little value. Seeing investors trying to recoup the billions pouring into the latest fad will be fun.
Gerben Wierda published another AI-buster article describing what exactly “state-of-the-art” means in AI benchmarks.
Hint: you give an AI model 32 step-by-step examples before asking a question, and it still gets it wrong 10% of the time.
Gerben Wierda published another AI-buster article describing what exactly “state-of-the-art” means in AI benchmarks.
Hint: you give an AI model 32 step-by-step examples before asking a question, and it still gets it wrong 10% of the time.
After a brief introduction of how the language models fit into the AI/ML landscape, Javier Antich explained the language model basics, including auto-regression, types of language models, the specifics of large language models, and potential use cases,
After a brief introduction of how the language models fit into the AI/ML landscape, Javier Antich explained the language model basics, including auto-regression, types of language models, the specifics of large language models, and potential use cases,
TL&DR: If you’re using netlab to build labs for your personal use, you can skip this one, but if you plan to use it to create training labs (like my BGP labs project), you might want to keep reading.
Like any complex enough tool, netlab eventually had to deal with inconsistent version-specific functionality and configuration syntax (OK, topology attributes). I stumbled upon this challenge when I wanted to make labs that use two types of configurable devices.
TL&DR: If you’re using netlab to build labs for your personal use, you can skip this one, but if you plan to use it to create training labs (like my BGP labs project), you might want to keep reading.
Like any complex enough tool, netlab eventually had to deal with inconsistent version-specific functionality and configuration syntax (OK, topology attributes). I stumbled upon this challenge when I wanted to make labs that use two types of configurable devices.
A previous BGP lab focused on the customer side of BGP communities: adding them to BGP updates to influence upstream ISP behavior. Today’s lab focuses on the ISP side of the equation: using BGP communities in a routing policy to implement RFC 1998-style behavior.
A previous BGP lab focused on the customer side of BGP communities: adding them to BGP updates to influence upstream ISP behavior. Today’s lab focuses on the ISP side of the equation: using BGP communities in a routing policy to implement RFC 1998-style behavior.