When I’ve seen my good friends Christopher Werny and Enno Rey talk about IPv6 security at RIPE78 meeting, another bit of one of my puzzles fell in place. I was planning to do an update of the IPv6 security webinar I’d done with Eric Vyncke, and always wanted to get it done by a security practitioner focused on enterprise networks, making Christopher a perfect fit.

As it was almost a decade since we did the original webinar, Christopher started with an overview of IPv6 security challenges (TL&DR: not much has changed).

After describing the FRRouting architecture, as well as recent performance optimizations and usability enhancements, Donald Sharp concluded the FRRouting webinar with detailed deployment guidelines.

After decades of riding the Moore’s law curve the networking bandwidth should be (almost) infinite and (almost) free, right? WRONG, as I explained in the Bandwidth Is (Not) Infinite and Free video (part of How Networks Really Work webinar).

There are still pockets of Internet desert where mobile- or residential users have to deal with traffic caps, and if you decide to move your applications into any public cloud you better check how much bandwidth those applications consume or you’ll be the next victim of the Great Bandwidth Swindle. For more details, watch the video.

After covering configuration and performance optimizations introduced in recent FRRouting releases, Donald Sharp focused on some of the recent usability enhancements, including BGP BestPath explanations, BGP Hostname, BGP Failed Neighbors, and improved debugging.

After the “shocking” revelation that a network can never be totally reliable, I addressed another widespread lack of common sense: due to laws of physics, the client-server latency is never zero (and never even close to what a developer gets from the laptop’s loopback interface).

After introducing FRRouting architecture, Donald Sharp dived deep into configuration and performance optimizations, including asynchronous data plane, next hop groups, and commit-and-rollback.

After introducing the fallacies of distributed computing in the How Networks Really Work webinar, I focused on the first one: the network is (not) reliable.

While that might be understood by most networking professionals (and ignored by many developers), here’s an interesting shocker: even TCP is not always reliable (see also: Joel Spolsky’s take on Leaky Abstractions).

After a brief overview of FRRouting suite Donald Sharp continued with a deep dive into FRR architecture, including the various routing daemons, role of Zebra and ZAPI, interface between RIB (Zebra) and FIB (Linux Kernel), sample data flow for route installation, and multi-threading in Zebra and BGP daemons.

What better way to start How Networks Really Work webinar than with fallacies of distributed computing… and that’s exactly what I did in late August 2019.

In October 2019, Donald Sharp did a short webinar describing FRRouting, the hottest open-source routing suite.

As always, he started with an overview of what FRRouting is, and where you could use it.

In late spring 2019, Matthias Luft and Florian Barth presented a short webinar on cloud concepts, starting with the obvious topic: cloud models, layers, and responsibilities.

You need Free ipSpace.net Subscription to watch the video, and the Standard ipSpace.net Subscription to register for a deeper dive into cloud security with Matthias Luft (next live session on December 10th: Identity and Access Management).

Original TCP/IP and OSI network stacks had relatively clean layered architecture (forgetting the battle scars for the moment) and relied on end-to-end principle to keep the network core simple.

As always, no good deed goes unpunished - “creative” individuals trying to force-fit their mis-designed star-shaped pegs into round holes, and networking vendors looking for competitive advantage quickly destroyed the idea with tons of middlebox devices, ranging from firewalls and load balancers to NAT, WAN optimization, and DPI monstrosities.

You need free ipSpace.net subscription to watch the video, or a paid ipSpace.net subscriptions to watch the whole How Networks Really Work webinar.

The previous videos from the How Networks Really Work webinar covered an overview of networking challenges and the importance of networking layers.

Now it’s time to put it all together.

You need free ipSpace.net subscription to watch the video, or a paid ipSpace.net subscriptions to watch the whole webinar.

Grouping the features needed in a networking stack in bunch of layered modules is a great idea, but unfortunately it turns out that you could place a number of important features like error recovery, retransmission and flow control in a number of different layers, from data link layer dealing with individual network segments to transport layer dealing with reliable end-to-end transmissions.

So where should we put those modules? As always, the correct answer is it depends, in this particular case on transmission reliability, latency, and cost of bandwidth. You’ll find more details in the Retransmissions and Flow Control part of How Networks Really Work webinar.

You need free ipSpace.net subscription to watch the video, or a paid ipSpace.net subscriptions to watch the whole webinar.

After identifying some of the challenges every network solution must address (part 1, part 2, part 3) we tried to tackle an interesting question: “how do you implement this whole spaghetti mess in a somewhat-reliable and structured way?”

The Roman Empire had an answer more than 2000 years ago: divide-and-conquer (aka “eating the elephant one bite at a time”). These days we call it layering and abstractions.

In the Need for Network Layers video I listed all the challenges we have to address, and then described how you could group them in meaningful modules (called networking layers).

You need free ipSpace.net subscription to watch the video, or a paid ipSpace.net subscriptions to watch the whole webinar.