# Network design The physical, virtual, and logical arrangement of infrastructure in an IT network. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Building a reliable cloud native foundation for distributed AI training DevFeed: [Building a reliable cloud native foundation for distributed AI training]() Original publisher: [Read original article]() Author: Abhi Kulkarni and Shishir Jindal, Atlassian Published: 2026-09-11T11:00:00Z Content type: article Language: en Sources: [Cloud Native Computing Foundation]() Topics: [Training AI Models](), [Machine learning](), [distributed-systems](), [GPU](), [cloud-infrastructure](), [Network design](), [Inference]() Tags: [ai-training](), [blog](), [distributed-training](), [gpu](), [infrastructure](), [storage]() ### AI overview The article explains how to make multi-node AI training reliable by treating inter-node communication, shared storage, hardware placement, network topology, and validation as platform concerns. It identifies RDMA for GPU-node communication and Lustre for concurrent training-data and checkpoint access. ### Source excerpt AI workloads are changing what platform teams need from infrastructure. Provisioning GPUs and standing up a cluster no longer makes a platform "AI-ready." Once training spans more than one node, the bottlenecks show up in places... ## Crypto Agility: Why PQC Is Not a One-Time Upgrade DevFeed: [Crypto Agility: Why PQC Is Not a One-Time Upgrade]() Original publisher: [Read original article]() Author: Hugo Vliegen Published: 2026-09-03T15:00:56Z Content type: article Language: en Sources: [Security @ Cisco Blogs]() Topics: [Cryptography](), [networking](), [Network design](), [Vulnerabilities]() Tags: [cisco-sd-wan](), [cryptographic](), [cryptography](), [infrastructure](), [network-security](), [networks](), [post-quantum](), [quantum-computing](), [sd-wan-security](), [security](), [security-for-ai]() ### AI overview The article explains why crypto agility is essential for long-lived network infrastructure adopting post-quantum cryptography. It argues that organizations should design systems to update cryptography continuously as standards, threats, and implementations evolve. ### Source excerpt Learn why crypto agility is essential for PQC-ready networks--and how adaptable infrastructure helps organizations keep pace with evolving threats. ## George Washington, the Delaware, and Direct Routes DevFeed: [George Washington, the Delaware, and Direct Routes]() Original publisher: [Read original article]() Author: j2sw Published: 2026-06-30T16:15:53Z Content type: opinion Language: en Sources: [Justin Wilson (j2sw)]() Topics: [Network design](), [Networks](), [BGP](), [Network]() Tags: [bgp](), [blog](), [fd-ix](), [internet-architecture](), [ixp](), [network-design](), [network-peering](), [networks](), [peering](), [route](), [routers](), [routing](), [traffic](), [transit]() ### AI overview This commentary compares George Washington's direct route across the Delaware with network peering. It argues that direct connections between networks can reduce transit dependencies, router hops, and latency compared with longer BGP-selected transit paths. ### Source excerpt I originally posted this over on the FD-IX Bloghttps://blog.fd-ix.com/george-washington-the-delaware-and-direct-routes/ When George Washington crossed the Delaware River on Christmas night in 1776, the goal was simple. Reach the objective by the most effective path while avoiding unnecessary delays and giving the opposing force as little warning as possible. The crossing was risky, but it created a ... Read more The post George Washington, the Delaware, and Direct Routes appeared first on Justin Wilson (j2sw). ## How Rain Affects Wireless Microwave Links: 24 GHz, 60 GHz, and 80 GHz Compared DevFeed: [How Rain Affects Wireless Microwave Links: 24 GHz, 60 GHz, and 80 GHz Compared]() Original publisher: [Read original article]() Author: j2sw Published: 2026-06-15T09:47:43Z Content type: tutorial Language: en Sources: [Justin Wilson (j2sw)]() Topics: [Network](), [Network design](), [Internet](), [data centers]() Tags: [24ghz](), [60ghz](), [80ghz](), [adaptive](), [backhaul](), [capacity](), [changes](), [e-band](), [error-correction](), [fiber](), [microwave](), [network](), [network-design](), [perfomance](), [radio](), [reduction](), [rf](), [wireless](), [wireless-networking]() ### AI overview This article explains how rain fade affects wireless microwave links, with emphasis on 24 GHz, 60 GHz, and 80 GHz bands. It describes how precipitation reduces signal strength, causes adaptive modulation and throughput reductions, and can eventually cause a link to drop when fade margin is exhausted. ### Source excerpt Rain can have a major impact on wireless microwave links, especially as frequencies increase. Learn how rain fade affects 24 GHz, 60 GHz, and 80 GHz circuits, and why fade margin is critical for reliable network design. The post How Rain Affects Wireless Microwave Links: 24 GHz, 60 GHz, and 80 GHz Compared appeared first on Justin Wilson (j2sw). ## Navigating uncertainty in Amazon's middle-mile network DevFeed: [Navigating uncertainty in Amazon's middle-mile network]() Original publisher: [Read original article]() Author: Ruth Misener; Hana Ku; Georgios Paschos Published: 2026-05-06T13:37:38Z Content type: article Language: en Sources: [Amazon Science homepage]() Topics: [amazon](), [Network design](), [Optimization](), [Network](), [networking]() Tags: [amazon](), [combinatorial-optimization](), [demand-forecasting](), [efficiency](), [middle-mile](), [network-design](), [operations-research-and-optimization](), [optimization](), [scot](), [supply-chain](), [supply-chain-optimization-technologies-scot](), [transportation-planning]() ### AI overview Amazon engineers and scientists describe how they optimize the company's middle-mile delivery network under uncertainty. The article covers demand and travel-time variability, network design, routing, inventory positioning, and mixed-integer optimization across many facilities and products. ### Source excerpt Amazon engineers and scientists have created new tools to optimize delivery networks under uncertainty -- and keep them adapting without missing a beat. ## Homelab Hardware DevFeed: [Homelab Hardware]() Original publisher: [Read original article]() Author: EduuhMuraya Published: 2026-01-14T00:00:00Z Content type: article Language: en Sources: [EduuhMuraya]() Topics: [Homelab](), [Hardware](), [Network design](), [Kubernetes]() Tags: [amd](), [cost](), [cpu](), [devices](), [firewall](), [hardware](), [home-lab](), [homelab](), [intel](), [kubernetes](), [network](), [opnsense](), [pc](), [performance](), [proxmox](), [self-hosted](), [storage]() ### AI overview An account of the mini PCs used in a homelab, covering their specifications, costs, roles, power efficiency, physical footprint, and the network changes made after part of the Kubernetes cluster was removed. ### Source excerpt The three mini PCs I bought for a Kubernetes homelab, what they cost, and what is left of them eighteen months later. ## Changing Colors and Line Styles in netlab Graphs DevFeed: [Changing Colors and Line Styles in netlab Graphs]() Original publisher: [Read original article]() Published: 2025-09-22T05:38:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [Graphs](), [Network design](), [SVG](), [Command-line interface]() Tags: [github](), [graph](), [graphs](), [netlab](), [network](), [svg](), [terminal](), [web]() ### AI overview A tutorial on styling network topology graphs generated from netlab lab topologies. It shows how to use graph attributes and groups to change node colors and link widths across GraphViz and D2 outputs, and how to map a custom text-color attribute to GraphViz. ### Source excerpt Last week, I explained how to generate network topology graphs (using GraphViz or D2 graphing engines) from a netlab lab topology. Let's see how we can make them look nicer (or at least more informative). We'll work with a simple leaf-and-spine topology with four nodes1: Baseline leaf-and-spine topology defaults.device: frr provider: clab nodes: [ s1, s2, l1, l2 ] links: [ s1-l1, s1-l2, s2-l1, s2-l2 ] This is the graph generated by netlab create followed by dot graph.dot -T png -o graph.png: Read more ... ## Finding End-to-End Paths: Topology and Endpoints DevFeed: [Finding End-to-End Paths: Topology and Endpoints]() Original publisher: [Read original article]() Published: 2025-06-06T05:51:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [Routing (disambiguation)](), [Network design]() Tags: [arp](), [bridging](), [dhcp](), [discovery](), [ipv4](), [ipv6](), [network](), [networking-fundamentals](), [router](), [routing]() ### AI overview This article explains how networks discover topology and endpoints, build forwarding tables, and adapt end-to-end paths when links or nodes fail. It contrasts complete topology views in link-state protocols with local-neighbor knowledge in distance-vector protocols, and describes learning mechanisms including bridging, ARP, DHCP, and ICMPv6 Neighbor Discovery. ### Source excerpt We know there are three main ways to move packets across a network. However, before we can start forwarding packets, someone has to populate the forwarding tables in the intermediate devices or build the sequence of nodes to traverse in source routing. Usually, whoever is responsible for the contents of the forwarding tables must first discover the network topology. Let's start there, using the following network diagram to illustrate the discussion. Read more ... ## Network Design Lesson: Split Functionality Across Devices When Appropriate DevFeed: [Network Design Lesson: Split Functionality Across Devices When Appropriate]() Original publisher: [Read original article]() Published: 2024-05-29T06:33:00Z Content type: opinion Language: en Sources: [ipSpace.net blog]() Topics: [Network design](), [Network architectures]() Tags: [bugs](), [network](), [network-design](), [worth-reading]() ### AI overview The article argues that network designs can be simpler and less costly when required functionality is divided across multiple devices instead of being crammed into one device. ### Source excerpt 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 in Small EVPN Data Center Fabrics DevFeed: [BGP Route Reflectors in Small EVPN Data Center Fabrics]() Original publisher: [Read original article]() Published: 2024-05-28T06:23:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [BGP](), [evpn](), [datacenter](), [networking](), [Network design]() Tags: [bgp](), [data-center](), [evpn](), [network-design](), [networking]() ### AI overview This article examines whether BGP route reflectors are necessary in reasonably small EVPN data center fabrics. It compares route-reflector and full-mesh designs, discussing scalability, configuration consistency, update timing, and the operational challenges of using dedicated or virtualized route reflectors. ### Source excerpt 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. Read more ... ## Unintended Consequences of IPv6 SLAAC DevFeed: [Unintended Consequences of IPv6 SLAAC]() Original publisher: [Read original article]() Published: 2024-04-16T06:45:00Z Content type: opinion Language: en Sources: [ipSpace.net blog]() Topics: [Network](), [Network design](), [Caching](), [Hardware]() Tags: [cache](), [cpu](), [hardware](), [ipv6](), [load](), [network](), [network-design](), [performance](), [tcp]() ### AI overview The article explains how IPv6 SLAAC privacy address rotation, long-running TCP sessions, and device reconnections can increase neighbor-discovery cache usage. When hardware forwarding devices exhaust that cache, packets may be handled by the CPU or dropped, reducing performance. It outlines tradeoffs involving interface limits, RFC 7217 identifiers, and DHCPv6 address allocation. ### Source excerpt One of my friends is running a large IPv6 network and has already experienced a shortage of IPv6 neighbor cache on some of his switches. Digging deeper into the root causes, he discovered: In my larger environments, I see significant neighbor table cache entries, especially on network segments with hosts that make many long-term connections. These hosts have 10 to 20 addresses that maintain state over days or weeks to accomplish their processes. What's going on? A perfect storm of numerous unrelated annoyances: Read more ... ## Network booted, home initialized DevFeed: [Network booted, home initialized]() Original publisher: [Read original article]() Published: 2020-01-17T15:25:24Z Content type: article Language: en Sources: [Jessie Frazelle]() Topics: [Homelab](), [Network design](), [Ethernet](), [gateway]() Tags: [ethernet](), [gateway](), [home-lab](), [like](), [network](), [setup](), [unifi]() ### AI overview The article describes building an office network based on the author's home-lab setup. It covers a 48-port switch, UniFi equipment, Cat7 cabling, a Dream Machine gateway, wireless access points, cameras, and an isolated AmpliFi Alien network for lab equipment or other devices. ### Source excerpt I had a lot of fun writing blog posts in the past about my home lab and some of my personal infrastructure so I thought I would do the same as we built out our office. Much like moving into a new place, the first thing I always plan to have setup on move-in day is internet. We did the same with our office as well. Before we even had any real furniture, we made sure that we had a network connection. You may recognize that furniture from the garage. For the office I really wanted our network infrastructure to be off-the-charts good. Everyone knows shitty internet is a productivity killer. Since I use UniFi for my network setup at home, we used the same for the office. Here's what we got: 48 Port Switch Dream Machine 2 Wifi APs A couple of cameras Amplifi Alien The Switch We have a hard line coming from the 48 port switch to each section of desks. I cabled all this myself. As we grow we will likely segment this off to each desk having its own little 4- or 8-port network switch but for now this works. The Cables All the cables running to the desks are Cat7s from Monoprice. Every type of cable has a maximum distance. For ethernet cables, the maximum distance is the maximum upload/download speed. Cat7 gets praised for its 100 Gbps speed, but that will only work for distances up to 15 meters (slightly over 49 feet). From 15 meters up to 50 meters, a Cat7 cable downgrades to 40 Gbps. Beyond that, it drops to the same 10 Gbps speed of Cat6 and Cat6a, however it still retains its superior 600 Mhz bandwidth. We use 100ft cables to the desks and 50ft cables wherever we can reach to maximize speed. The Router The Dream Machine is acting as our gateway and controller. Before we got the other 2 APs, it was our only access point and did a great job of that. The Access Points We have a large warehouse with a lot of square feet, while the Dream Machine does have coverage to every corner, it's nice to have a strong signal from anywhere in the office. As we grow we will have more and m ## Networking: Using Linux Traffic Control for Fun and Profit Loss Prevention DevFeed: [Networking: Using Linux Traffic Control for Fun and Profit Loss Prevention]() Original publisher: [Read original article]() Author: Wordbitly Published: 2013-11-19T19:43:00Z Content type: article Language: en Sources: [Bitly]() Topics: [networking](), [Hadoop](), [migration](), [Network design](), [Ethernet](), [Linux]() Tags: [ethernet](), [hadoop](), [infrastructure](), [linux](), [migration](), [network](), [networking]() ### AI overview A Bitly technical account of migrating a physical Hadoop cluster and the resulting network overload. A fast distcp transfer generated enough cross-cabinet traffic to cause errors, timeouts, and failed internal DNS queries for website users and API clients. ### Source excerpt Here at bitly, we are big fans of data, tubes and especially tubes that carry data. This is a story about asking tubes to carry too much data. A physical hadoop cluster has been a significant part of bitly's infrastructure and a core tool of the bitly Data Science and Ops/Infra teams for some time. Long enough that we needed to cycle in a new cluster, copy data, and fold the old into the new. Branches were opened, work was done, servers provisioned and the new cluster was stood up. Time to take a step back from the story and flesh out some technical details: bitly operates at a consequential scale of data: At the time of this migration the hadoop cluster was just over 150TB consumed disk space of compressed stream data, that is data that is the valuable output of our various applications after having been manipulated and expanded on by other applications. bitly's physical presence is collocated with our data center partner. There are three physical chassis classes (application, storage and database) racked together in contiguous cabinets in rows. At the time of this story each chassis had three physical 1Gb Ethernet connections (each logically isolated by VLANs), frontlink, backlink and lights-out (for out of band management of the server chassis). Each connection, after a series of cabinet specific patch panels and switches, connects to our core switches over 10Gb glass in a hub and spoke topology. While bitly also operates at a consequential physical scale (hundreds of physical server chassis), we depend on our data center partner for network infrastructure and topology. This means that within most levels of the physical networking stack, we have severely limited control and visibility. Back to the story: The distcp tool bundled with hadoop allowed us to quickly copy data from one cluster to the other. Put simply, distcp tool creates a mapreduce job to shuffle data from one hdfs cluster to another, in a many to many node copy. Distcp was fast, which was good. bitl