Someone told me some (or many?) of the links are broken to the History of Networking recordings. I went through the S3 bucket and renamed all the files so there are no spaces (because S3 buckets don’t always work right with spaces), and then checked them all to make certain they work. Along the way I found three or four episodes that were recorded and not on the HoN page, so I added them.
Check out the corrected listing here.
I think I have one more recording that was never edited and published; I will probably put it in the Hedge stream in the next month or two just so it’s out there.
This post is also available in 日本語, 한국어, Deutsch, Français, Español.
Cloudflare’s network spans more than 310 cities in over 120 countries, where we interconnect with over 13,000 network providers in order to provide a broad range of services to millions of customers. The breadth of both our network and our customer base provides us with a unique perspective on Internet resilience, enabling us to observe the impact of Internet disruptions. Thanks to recently released Cloudflare Radar functionality, this quarter we have started to explore the impact from a routing perspective, as well as a traffic perspective, at both a network and location level.
The first quarter of 2024 kicked off with quite a few Internet disruptions. Damage to both terrestrial and submarine cables caused problems in a number of locations, while military action related to ongoing geopolitical conflicts impacted connectivity in other areas. Governments in several African countries, as well as Pakistan, ordered Internet shutdowns, focusing heavily on mobile connectivity. Malicious actors known as Anonymous Sudan claimed responsibility for cyberattacks that disrupted Internet connectivity in Israel and Bahrain. Maintenance and power outages forced users offline, resulting in observed drops in traffic. And in Continue reading
When designing the netlab VRF configuration module, I tried to make it as flexible as possible while using the minimum number of awkward nerd knobs. As is often the case1, the results could be hard to grasp, so let’s walk through the various scenarios of using global and node VRFs.
netlab allows you to define a VRF in the lab topology vrfs dictionary (global VRF) or in a node vrfs dictionary (node VRF). In most cases, you’d define a few global VRFs and move on.
When designing the netlab VRF configuration module, I tried to make it as flexible as possible while using the minimum number of awkward nerd knobs. As is often the case1, the results could be hard to grasp, so let’s walk through the various scenarios of using global and node VRFs.
netlab allows you to define a VRF in the lab topology vrfs dictionary (global VRF) or in a node vrfs dictionary (node VRF). In most cases, you’d define a few global VRFs and move on.
Many vendors offer MLAG features, that is, the ability to form a PortChannel (some vendors call it trunk or bond) towards two separate devices. In this post, I will cover the following:
On Cisco Nexus switches, virtual Port Channel (vPC) has been a highly used feature for many years. It has been used towards other network devices such as firewalls, routers, and switches, but also towards hosts running hypervisors such as ESX.
As opposed to other technologies such as Virtual Switching System (VSS) or StackWise Virtual, it does not require the two switches to become one to provide the ability to do MLAG. Instead, the two devices appear as one in PDUs such as LACP, STP, and IGMP, by using a vPC system MAC address as the source MAC. With MLAG features, the two switches need to verify the other is alive and also synchronize state and perform consistency checking. This is done by connecting them with a vPC peer keepalive link, and Continue reading
In a traditional Layer 2 network, switches forward Intra-VLAN data traffic based on the destination MAC address of Ethernet frames. Therefore, hosts within the same VLAN must resolve each other's MAC-IP address bindings using Address Resolution Protocol (ARP). When a host wants to open a new IP connection with a device in the same subnet and the destination MAC address is unknown, the connection initiator generates an ARP Request message. In the message, the sender provides its own MAC-IP binding information and queries the MAC address of the owner of the target IP. The ARP Request messages are Layer 2 Broadcast messages with the destination MAC address FF:FF:FF:FF:FF:FF.
EVPN Fabric is a routed network and requires a solution for Layer 2 Broadcast messages. We can select either BGP EVPN-based Ingress-Replication (IR) solution or enable Multicast routing in Underlay network. This chapter introduces the latter model. As in previous Unicast Routing section, we follow the Multicast deployment workflow of Nexus Dashboard Fabric Controller (NDFC) graphical user interface.
Figure 2-4 depicts the components needed to deploy Multicast service in the Underlay network. The default option for selecting “RP mode” is ASM (Any-Source Multicast). ASM is Continue reading
Listen in as Geoff Huston, Tom, and Russ discuss how the IETF, governments, and political movements interact when creating standards and guiding the future of the Internet.
Tier1 and aspiring Tier2 providers interconnect only in large metropolitan areas, due to commercial incentives and politics. They won’t often peer with smaller providers, because why peer with a potential customer? Due to this, it’s entirely likely that traffic between two parties in Thessaloniki is sent to Frankfurt or Milan and back.
One possible antidote to this is to connect to a local Internet Exchange point. Not all ISPs have access to large metropolitan datacenters where larger internet exchanges have a point of presence, and it doesn’t help that the datacenter operator is happy to charge a substantial amount of money each month, just for the privilege of having a passive fiber cross connect to the exchange. Many Internet Exchanges these days ask for per-month port costs and meter the traffic with policers and rate limiters, such that the total cost of peering starts to exceed what one might pay for transit, especially at low volumes, which further exacerbates the problem. Bah.
This is an unfortunate market effect (the race to the bottom), where transit providers are continuously lowering their prices to compete. And while transit providers can make up to some extent due to economies of scale, at Continue reading
You probably know I hate posting links to walled gardens or sites that try really hard to make you sign up. Sometimes, I have to make an exception: Roman Pomazanov wrote a great (and humorous) article comparing how easy it is to set up simple labs with GNS3, containerlab, and netlab.
You probably know I hate posting links to walled gardens or sites that try really hard to make you sign up. Sometimes, I have to make an exception: Roman Pomazanov wrote a great (and humorous) article comparing how easy it is to set up simple labs with GNS3, containerlab, and netlab.
I found some old C code of mine from around 2001 or so. I vaguely remember trying to make it as optimized as possible. Sure, I was still a teenager, so it’s not state of the art. But it’s not half bad. I vaguely suspect I could do better with better optimization for cache lines, but it’s pretty good.
On my current laptop it does about 12 million passwords per second, single threaded.
Because I’m learning Rust, I decided to port it, and see how fast rust is.
Imagine my surprise when even the first version in Rust was faster. (Yes, I rebuilt the old C code with a modern compiler and its optimizations)
The first Rust version was about 13 million passwords per second.
Why is that? It’s basically the same as the C code. Maybe Rust can take advantage of knowing there’s no pointer aliasing (the reason usually quoted for why Fortran can be faster than C)? Or maybe the memory layout just happened to become more cache friendly?
In any case, I think we can already say that Rust is at least as fast as C.
The code is on github.
I realized, of Continue reading
I saw a recent post on LinkedIn from Alex Henthorn-Iwane that gave me pause. He was talking about how nearly 2/3rds of Github projects are maintained by one or two people. He also quoted some statistics around how projects are maintained by volunteers and unpaid members as opposed to more institutional support from people getting paid to do the work. It made me reflect on my own volunteering journey and how the parallels between open source and other organizations aren’t so different after all.
Most of my readers know that one of my passion projects outside of Tech Field Day and this humble blog is the involvement of my children in Scouting. I spend a lot of my free time volunteering as a leader and organizer for various groups. I get to touch grass quite often. At least I do when I’m not stuck in meetings or approving paperwork.
One of the things that struck me in Alex’s post was how he talked about the lack of incoming talent to help with projects as older maintainers are aging out. We face a similar problem in scouting. Rather than our volunteers getting too old to do the Continue reading
Microsegmentation represents a transformative approach to enhancing network security within Kubernetes environments. This technique divides networks into smaller, isolated segments, allowing for granular control over traffic flow and significantly bolstering security posture. At its core, microsegmentation leverages Kubernetes network policies to isolate workloads, applications, namespaces, and entire clusters, tailoring security measures to specific organizational needs and compliance requirements.
The fundamental advantage of microsegmentation through network policies lies in its scalability and flexibility. Kubernetes’ dynamic, label-based selection process facilitates the addition of new segments without compromising existing network infrastructure, enabling organizations to adapt to evolving security landscapes seamlessly.
Workload isolation, a critical component of microsegmentation, emphasizes the importance of securing individual microservices within a namespace or tenant by allowing only required and approved communication. This minimizes the attack surface and prevents unauthorized lateral movement.
Namespace isolation further enhances security by segregating applications into unique namespaces, ensuring operational independence and reducing the impact of potential security breaches. Similarly, tenant isolation addresses the needs of multi-tenant environments by securing shared Kubernetes infrastructure, thus protecting tenants from each other Continue reading
Image 2-1 illustrates the components essential for designing a Single-AS, Multicast-enabled OSPF Underlay EVPN Fabric. These components need to be established before constructing the EVPN fabric. I've grouped them into five categories based on their function.
The model presented in Figure 2-1 outlines the steps for configuring an EVPN fabric using the Continue reading