# Network design

Published articles for Network design.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## George Washington, the Delaware, and Direct Routes

DevFeed: [George Washington, the Delaware, and Direct Routes](<https://devfeed.tech/articles/george-washington-the-delaware-and-direct-routes-40153.md>)

Original publisher: [Read original article](<https://blog.j2sw.com/inetarch/george-washington-delaware-direct-network-routing/>)

Author: j2sw

Published: 2026-06-30T16:15:53Z

Content type: opinion

Language: en

Sources: [Justin Wilson (j2sw)](<https://devfeed.tech/sources/justin-wilson-j2sw.md>)

Topics: [Network design](<https://devfeed.tech/topics/network-design.md>), [Networks](<https://devfeed.tech/topics/networks.md>), [BGP](<https://devfeed.tech/topics/bgp.md>), [Network](<https://devfeed.tech/topics/network.md>)

Tags: [bgp](<https://devfeed.tech/tags/bgp.md>), [blog](<https://devfeed.tech/tags/blog.md>), [fd-ix](<https://devfeed.tech/tags/fd-ix.md>), [internet-architecture](<https://devfeed.tech/tags/internet-architecture.md>), [ixp](<https://devfeed.tech/tags/ixp.md>), [network-design](<https://devfeed.tech/tags/network-design.md>), [network-peering](<https://devfeed.tech/tags/network-peering.md>), [networks](<https://devfeed.tech/tags/networks.md>), [peering](<https://devfeed.tech/tags/peering.md>), [route](<https://devfeed.tech/tags/route.md>), [routers](<https://devfeed.tech/tags/routers.md>), [routing](<https://devfeed.tech/tags/routing.md>), [traffic](<https://devfeed.tech/tags/traffic.md>), [transit](<https://devfeed.tech/tags/transit.md>)

### 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](<https://devfeed.tech/articles/how-rain-affects-wireless-microwave-links-24-ghz-60-ghz-and-80-ghz-compared-40174.md>)

Original publisher: [Read original article](<https://blog.j2sw.com/netops/wireless/rain-fade-microwave-links/>)

Author: j2sw

Published: 2026-06-15T09:47:43Z

Content type: tutorial

Language: en

Sources: [Justin Wilson (j2sw)](<https://devfeed.tech/sources/justin-wilson-j2sw.md>)

Topics: [Network](<https://devfeed.tech/topics/network.md>), [Network design](<https://devfeed.tech/topics/network-design.md>), [Internet](<https://devfeed.tech/topics/internet.md>), [data centers](<https://devfeed.tech/topics/data-centers.md>)

Tags: [24ghz](<https://devfeed.tech/tags/24ghz.md>), [60ghz](<https://devfeed.tech/tags/60ghz.md>), [80ghz](<https://devfeed.tech/tags/80ghz.md>), [adaptive](<https://devfeed.tech/tags/adaptive.md>), [backhaul](<https://devfeed.tech/tags/backhaul.md>), [capacity](<https://devfeed.tech/tags/capacity.md>), [changes](<https://devfeed.tech/tags/changes.md>), [e-band](<https://devfeed.tech/tags/e-band.md>), [error-correction](<https://devfeed.tech/tags/error-correction.md>), [fiber](<https://devfeed.tech/tags/fiber.md>), [microwave](<https://devfeed.tech/tags/microwave.md>), [network](<https://devfeed.tech/tags/network.md>), [network-design](<https://devfeed.tech/tags/network-design.md>), [perfomance](<https://devfeed.tech/tags/perfomance.md>), [radio](<https://devfeed.tech/tags/radio.md>), [reduction](<https://devfeed.tech/tags/reduction.md>), [rf](<https://devfeed.tech/tags/rf.md>), [wireless](<https://devfeed.tech/tags/wireless.md>), [wireless-networking](<https://devfeed.tech/tags/wireless-networking.md>)

### 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).

## How flat is replacing fat in AWS data center networks

DevFeed: [How flat is replacing fat in AWS data center networks](<https://devfeed.tech/articles/how-flat-is-replacing-fat-in-aws-data-center-networks-7602.md>)

Original publisher: [Read original article](<https://www.amazon.science/blog/how-flat-is-replacing-fat-in-aws-data-center-networks>)

Author: Giacomo Bernardi; Ratul Mahajan; Seshadhri Comandur

Published: 2026-05-28T10:30:00Z

Content type: article

Language: en

Sources: [Amazon Science homepage](<https://devfeed.tech/sources/amazon-science-homepage.md>)

Topics: [networking](<https://devfeed.tech/topics/networking.md>), [Network architectures](<https://devfeed.tech/topics/network-architectures.md>)

Tags: [aws](<https://devfeed.tech/tags/aws.md>), [aws-data-center-network-architecture](<https://devfeed.tech/tags/aws-data-center-network-architecture.md>), [cloud-and-systems](<https://devfeed.tech/tags/cloud-and-systems.md>), [data-center](<https://devfeed.tech/tags/data-center.md>), [fat-tree-network-replacement](<https://devfeed.tech/tags/fat-tree-network-replacement.md>), [flat-network-topology](<https://devfeed.tech/tags/flat-network-topology.md>), [network-design](<https://devfeed.tech/tags/network-design.md>), [networking](<https://devfeed.tech/tags/networking.md>), [networks](<https://devfeed.tech/tags/networks.md>), [quasi-random-network-topology](<https://devfeed.tech/tags/quasi-random-network-topology.md>), [resilience](<https://devfeed.tech/tags/resilience.md>), [routing](<https://devfeed.tech/tags/routing.md>)

### AI overview

The article describes AWS's scalable flat data-center network, using quasi-random topology and ShuffleBoxes to replace conventional fat-tree designs.

### Source excerpt

"Quasi-random" network topologies and new passive optical components called ShuffleBoxes make more-efficient flat networks as practical as traditional "fat-tree" networks.

## Navigating uncertainty in Amazon's middle-mile network

DevFeed: [Navigating uncertainty in Amazon's middle-mile network](<https://devfeed.tech/articles/navigating-uncertainty-in-amazon-s-middle-mile-network-7604.md>)

Original publisher: [Read original article](<https://www.amazon.science/blog/navigating-uncertainty-in-amazons-middle-mile-network>)

Author: Ruth Misener; Hana Ku; Georgios Paschos

Published: 2026-05-06T13:37:38Z

Content type: article

Language: en

Sources: [Amazon Science homepage](<https://devfeed.tech/sources/amazon-science-homepage.md>)

Topics: [amazon](<https://devfeed.tech/topics/amazon.md>), [Network design](<https://devfeed.tech/topics/network-design.md>), [Optimization](<https://devfeed.tech/topics/optimization.md>), [Network](<https://devfeed.tech/topics/network.md>), [networking](<https://devfeed.tech/topics/networking.md>)

Tags: [amazon](<https://devfeed.tech/tags/amazon.md>), [combinatorial-optimization](<https://devfeed.tech/tags/combinatorial-optimization.md>), [demand-forecasting](<https://devfeed.tech/tags/demand-forecasting.md>), [efficiency](<https://devfeed.tech/tags/efficiency.md>), [middle-mile](<https://devfeed.tech/tags/middle-mile.md>), [network-design](<https://devfeed.tech/tags/network-design.md>), [operations-research-and-optimization](<https://devfeed.tech/tags/operations-research-and-optimization.md>), [optimization](<https://devfeed.tech/tags/optimization.md>), [scot](<https://devfeed.tech/tags/scot.md>), [supply-chain](<https://devfeed.tech/tags/supply-chain.md>), [supply-chain-optimization-technologies-scot](<https://devfeed.tech/tags/supply-chain-optimization-technologies-scot.md>), [transportation-planning](<https://devfeed.tech/tags/transportation-planning.md>)

### 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.

## Unlocking large scale AI training networks with MRC (Multipath Reliable Connection)

DevFeed: [Unlocking large scale AI training networks with MRC (Multipath Reliable Connection)](<https://devfeed.tech/articles/unlocking-large-scale-ai-training-networks-with-mrc-multipath-reliable-connection-6539.md>)

Original publisher: [Read original article](<https://openai.com/index/mrc-supercomputer-networking>)

Published: 2026-05-05T10:00:00Z

Content type: article

Language: en

Sources: [OpenAI News](<https://devfeed.tech/sources/openai-news.md>)

Topics: [Artificial Intelligence](<https://devfeed.tech/topics/ai.md>), [networking](<https://devfeed.tech/topics/networking.md>), [Networks](<https://devfeed.tech/topics/networks.md>), [Resilience](<https://devfeed.tech/topics/resilience.md>), [GPU](<https://devfeed.tech/topics/gpu.md>), [Network](<https://devfeed.tech/topics/network.md>), [Protocol (disambiguation)](<https://devfeed.tech/topics/protocol.md>), [OpenAI](<https://devfeed.tech/topics/openai.md>), [Routing (disambiguation)](<https://devfeed.tech/topics/routing.md>), [stargate](<https://devfeed.tech/topics/stargate.md>)

Tags: [ai](<https://devfeed.tech/tags/ai.md>), [ecosystem](<https://devfeed.tech/tags/ecosystem.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [gpu](<https://devfeed.tech/tags/gpu.md>), [infrastructure](<https://devfeed.tech/tags/infrastructure.md>), [network-design](<https://devfeed.tech/tags/network-design.md>), [networking](<https://devfeed.tech/tags/networking.md>), [networks](<https://devfeed.tech/tags/networks.md>), [openai](<https://devfeed.tech/tags/openai.md>), [resilience](<https://devfeed.tech/tags/resilience.md>), [routing](<https://devfeed.tech/tags/routing.md>), [stargate](<https://devfeed.tech/tags/stargate.md>), [systems](<https://devfeed.tech/tags/systems.md>), [technology](<https://devfeed.tech/tags/technology.md>)

### AI overview

OpenAI introduces MRC (Multipath Reliable Connection), a protocol designed to improve performance and resilience in GPU networks supporting large-scale AI model training. Released through the Open Compute Project, MRC uses multi-plane networks, adaptive packet spraying, and static source routing to reduce congestion, tolerate failures, and simplify network design.

### Source excerpt

OpenAI introduces MRC (Multipath Reliable Connection), a new supercomputer networking protocol released via OCP to improve resilience and performance in large-scale AI training clusters.

## Network Design Lesson: Split Functionality Across Devices When Appropriate

DevFeed: [Network Design Lesson: Split Functionality Across Devices When Appropriate](<https://devfeed.tech/articles/must-read-make-two-trips-11016.md>)

Original publisher: [Read original article](<https://blog.ipspace.net/2024/05/worth-reading-make-two-trips/>)

Published: 2024-05-29T06:33:00Z

Content type: opinion

Language: en

Sources: [ipSpace.net blog](<https://devfeed.tech/sources/ipspace-net-blog.md>)

Topics: [Network design](<https://devfeed.tech/topics/network-design.md>), [Network architectures](<https://devfeed.tech/topics/network-architectures.md>)

Tags: [bugs](<https://devfeed.tech/tags/bugs.md>), [network](<https://devfeed.tech/tags/network.md>), [network-design](<https://devfeed.tech/tags/network-design.md>), [worth-reading](<https://devfeed.tech/tags/worth-reading.md>)

### 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](<https://devfeed.tech/articles/bgp-route-reflectors-considered-harmful-11001.md>)

Original publisher: [Read original article](<https://blog.ipspace.net/2024/05/bgp-rr-considered-harmful/>)

Published: 2024-05-28T06:23:00Z

Content type: article

Language: en

Sources: [ipSpace.net blog](<https://devfeed.tech/sources/ipspace-net-blog.md>)

Topics: [BGP](<https://devfeed.tech/topics/bgp.md>), [evpn](<https://devfeed.tech/topics/evpn.md>), [datacenter](<https://devfeed.tech/topics/datacenter.md>), [networking](<https://devfeed.tech/topics/networking.md>), [Network design](<https://devfeed.tech/topics/network-design.md>)

Tags: [bgp](<https://devfeed.tech/tags/bgp.md>), [data-center](<https://devfeed.tech/tags/data-center.md>), [evpn](<https://devfeed.tech/tags/evpn.md>), [network-design](<https://devfeed.tech/tags/network-design.md>), [networking](<https://devfeed.tech/tags/networking.md>)

### 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 ...

## Repost: State of Lisp Implementations (2024)

DevFeed: [Repost: State of Lisp Implementations (2024)](<https://devfeed.tech/articles/repost-state-of-lisp-implementations-2024-11010.md>)

Original publisher: [Read original article](<https://blog.ipspace.net/2024/05/repost-state-of-lisp-implementations/>)

Published: 2024-05-07T06:21:00Z

Content type: opinion

Language: en

Sources: [ipSpace.net blog](<https://devfeed.tech/sources/ipspace-net-blog.md>)

Topics: [Lisp](<https://devfeed.tech/topics/lisp.md>), [Cisco](<https://devfeed.tech/topics/cisco.md>), [Networks](<https://devfeed.tech/topics/networks.md>), [iOS](<https://devfeed.tech/topics/ios.md>), [evpn](<https://devfeed.tech/topics/evpn.md>)

Tags: [cisco](<https://devfeed.tech/tags/cisco.md>), [design](<https://devfeed.tech/tags/design.md>), [development](<https://devfeed.tech/tags/development.md>), [evpn](<https://devfeed.tech/tags/evpn.md>), [ios](<https://devfeed.tech/tags/ios.md>), [lisp](<https://devfeed.tech/tags/lisp.md>), [mobility](<https://devfeed.tech/tags/mobility.md>), [network-design](<https://devfeed.tech/tags/network-design.md>), [networks](<https://devfeed.tech/tags/networks.md>), [routing](<https://devfeed.tech/tags/routing.md>), [software](<https://devfeed.tech/tags/software.md>)

### AI overview

This repost discusses the uncertain state of LISP support, including its removal from IOS XR and concerns about Cisco's future support. It describes the consequences for extreme-mobility and safety-critical networks, including possible parallel LISP and PMIPv6 backbones and the need for supplier and technology diversity.

### Source excerpt

You might remember Béla Várkonyi's use of LISP to build resilient ground-to-airplane networks from last week's repost. It seems he's not exactly happy with the current level of LISP support, at least based on what he wrote as a response to Jeff McLaughlin's claim that "I can tell you that our support for EVPN does not, in any way, indicate the retirement of LISP for SD-Access.": Nice to hear the Cisco intends to support LISP. However, it is removed from IOS XR already. So it is not that clear... If Cisco will stop supporting LISP, then we will be forced to create our own LISP routers, since we need it for extreme mobility environments. Read more ...

## Unintended Consequences of IPv6 SLAAC

DevFeed: [Unintended Consequences of IPv6 SLAAC](<https://devfeed.tech/articles/unintended-consequences-of-ipv6-slaac-10980.md>)

Original publisher: [Read original article](<https://blog.ipspace.net/2024/04/ipv6-slaac-unintended-consequences/>)

Published: 2024-04-16T06:45:00Z

Content type: opinion

Language: en

Sources: [ipSpace.net blog](<https://devfeed.tech/sources/ipspace-net-blog.md>)

Topics: [Network](<https://devfeed.tech/topics/network.md>), [Network design](<https://devfeed.tech/topics/network-design.md>), [Caching](<https://devfeed.tech/topics/caching.md>), [Hardware](<https://devfeed.tech/topics/hardware.md>)

Tags: [cache](<https://devfeed.tech/tags/cache.md>), [cpu](<https://devfeed.tech/tags/cpu.md>), [hardware](<https://devfeed.tech/tags/hardware.md>), [ipv6](<https://devfeed.tech/tags/ipv6.md>), [load](<https://devfeed.tech/tags/load.md>), [network](<https://devfeed.tech/tags/network.md>), [network-design](<https://devfeed.tech/tags/network-design.md>), [performance](<https://devfeed.tech/tags/performance.md>), [tcp](<https://devfeed.tech/tags/tcp.md>)

### 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 ...