# route Published articles for route. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## 【Istio 控制面】Linkerd 对照：非 xDS 的控制面机制 DevFeed: [【Istio 控制面】Linkerd 对照：非 xDS 的控制面机制]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-11T00:00:00Z Content type: article Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [istio](), [linkerd](), [API](), [proxy]() Tags: [api](), [control-plane](), [destination-controller](), [envoy](), [go](), [identity](), [istio](), [istiod](), [kubernetes](), [linkerd](), [mechanism-comparison](), [network](), [policy](), [proxy](), [route](), [rust](), [service](), [serviceaccount](), [sidecar](), [xds]() ### AI overview This article compares Linkerd's control-plane architecture with Istio's istiod and xDS model. It describes Linkerd's separately deployed destination, identity, and proxy-injector components; its proxy-specific gRPC APIs; and its CSR-based identity issuance, contrasting these with Istio's consolidated control plane and xDS/SDS resource model. It explicitly avoids declaring either system superior without workload-specific evidence. ### Source excerpt 以官方文档为准，对照 Linkerd destination/identity 控制面与 Istio istiod/xDS 的机制差异：资源模型、订阅形状、身份签发路径；只讲机制边界，不判定优劣。 ## Paul Klein on collapsing the agent stack into one platform DevFeed: [Paul Klein on collapsing the agent stack into one platform]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-08-05T23:22:36Z Content type: article Language: en Sources: [WorkOS Blog]() Topics: [Artificial Intelligence](), [browser](), [API](), [Caching](), [Structured-data](), [Routing (disambiguation)]() Tags: [agent](), [agents](), [ai](), [api](), [browser](), [browsers](), [caching](), [model](), [route](), [routing](), [search](), [speed]() ### AI overview Browserbase founder and CEO Paul Klein discusses the company's effort to combine browser infrastructure, search, fetching, models, routing, and caching into one platform for web-browsing agents. The article also covers the launch of Browserbase agents, a prebuilt harness intended to reduce the work required to build such agents. ### Source excerpt Browserbase founder Paul Klein on collapsing the agent stack into one platform, pointing cheap models at simple sites, and why speed is the last constraint. ## A Polyline Is Not a Route DevFeed: [A Polyline Is Not a Route]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-08-03T00:00:00Z Content type: tutorial Language: en Sources: [CodeName One]() Topics: [API](), [Routing (disambiguation)](), [Open Source](), [Self-hosted](), [Server]() Tags: [api](), [backend](), [code](), [implementation](), [open-source](), [route](), [routing](), [self-hosted](), [server]() ### AI overview This article explains a Codename One maps routing API that converts coordinates into road-following routes and provides geometry, distance, duration, alternatives, legs, and step instructions. It describes the callback behavior, encoded geometry support, and use of OSRM as the default service, while noting that the public demonstration server is unsuitable for production and that applications can use a self-hosted or other provider. ### Source excerpt The new Codename One maps routing API turns coordinates into road-following geometry, distance, duration, legs, and steps through OSRM or an application-defined service. ## Understanding BGP Route Types: Full Routes vs Partial vs Default vs Customer Routes DevFeed: [Understanding BGP Route Types: Full Routes vs Partial vs Default vs Customer Routes]() Original publisher: [Read original article]() Author: j2sw Published: 2026-07-24T16:28:00Z Content type: article Language: en Sources: [Justin Wilson (j2sw)]() Topics: [BGP](), [networking](), [Routing (disambiguation)](), [Internet](), [gateway](), [Networks]() Tags: [bgp](), [cpu](), [flexibility](), [internet-architecture](), [isp](), [memory](), [network-engineering](), [network-operations](), [route](), [router](), [routing](), [routing-policy](), [routing-table](), [traffic-engineering](), [visibility]() ### AI overview This article explains BGP route choices, comparing default routes, full routes, partial routes, and customer routes. It describes the tradeoffs between small routing tables, Internet visibility, traffic engineering control, and router resource requirements. ### Source excerpt 5 minute read time.Justin Wilson j2sw.com When you configure a BGP session, one of the first questions is what routes you actually want to receive. If you have ever filled out a questionnaire with Hurricane Electric or another transit provider, they ask you what "kind" of routes you want. In this article, I plan to ... Read more The post Understanding BGP Route Types: Full Routes vs Partial vs Default vs Customer Routes appeared first on Justin Wilson (j2sw). ## RFC 10005: BGP Community for link capacity DevFeed: [RFC 10005: BGP Community for link capacity]() Original publisher: [Read original article]() Author: j2sw Published: 2026-07-01T13:31:00Z Content type: article Language: en Sources: [Justin Wilson (j2sw)]() Topics: [BGP](), [standard](), [Load Balancing](), [Network]() Tags: [bgp](), [capacity](), [internet](), [load-balancing](), [network](), [network-operations](), [rfc](), [rfc-10005](), [route](), [routers](), [routing](), [standard](), [traffic]() ### AI overview RFC 10005 defines a BGP extended community for carrying link bandwidth information in routes. When multiple BGP paths are eligible, routers can use the value to weight traffic according to link capacity, while normal best-path policy still determines route eligibility. The RFC is currently a draft. ### Source excerpt RFC 10005 defines a BGP extended community that lets a router attach link bandwidth information to a route. Another router can use that value when it spreads traffic across multiple BGP paths. RFC 10005 matters because links are not always of the same capacity. This RFC provides routers with a standard way to carry bandwidth ... Read more The post RFC 10005: BGP Community for link capacity appeared first on Justin Wilson (j2sw). ## 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). ## Example BGP Configuration on the Alta Labs Route10 DevFeed: [Example BGP Configuration on the Alta Labs Route10]() Original publisher: [Read original article]() Author: j2sw Published: 2026-06-17T03:44:45Z Content type: tutorial Language: en Sources: [Justin Wilson (j2sw)]() Topics: [BGP](), [Routing (disambiguation)](), [configuration](), [networking](), [Command-line interface]() Tags: [alta-labs-configuration](), [alta-labs-route-10](), [bgp](), [bgp-example](), [bgp-tutorial](), [cisco](), [configuration](), [eos](), [frr](), [frrouting](), [frrrouting](), [interface](), [linux](), [network-engineering-resources](), [peer](), [route](), [route-10-bgp](), [routing]() ### AI overview A configuration guide for using BGP on the Alta Labs Route10, which provides dynamic routing through an FRR-style shell. It covers private ASNs, example prefix advertisement, interface addressing, access to the configuration shell, and session verification. ### Source excerpt The Alta Labs Route10 includes dynamic routing support through FRRouting (FRR). This article walks through a complete BGP configuration example using private ASNs, a test prefix advertisement, inbound community tagging, and route filtering. It also covers where to access the FRR shell within the Route10 interface and how to verify that the BGP session is operating correctly. The post Example BGP Configuration on the Alta Labs Route10 appeared first on Justin Wilson (j2sw). ## Eliminating Kubernetes Image Signature Replication DevFeed: [Eliminating Kubernetes Image Signature Replication]() Original publisher: [Read original article]() Author: The Kubernetes Authors Published: 2026-06-05T00:00:00Z Content type: article Language: en Sources: [Kubernetes Contributors Blog]() Topics: [Kubernetes](), [Replication](), [container images](), [Routing (disambiguation)](), [Latency](), [Google]() Tags: [cloud](), [container-images](), [cosign](), [kubernetes](), [latency](), [manifest](), [oidc](), [registry](), [replication](), [route](), [routing](), [sha256](), [signing](), [verify]() ### AI overview This article explains how Kubernetes eliminated replication of image signatures across 22 regional registries. Because signatures are small and regional latency is negligible, archeio now routes signature requests to a canonical registry while image layers continue using geo-routing. ### Source excerpt The image promoter rewrite laid the groundwork for simplifying how Kubernetes delivers container image signatures. One of the rewrite phases (Phase 6) separated image signing from signature replication into distinct pipeline stages. This follow-up covers the next step: eliminating signature replication entirely. The problem After promoting container images to registry.k8s.io, the promoter signs them using cosign with keyless (OIDC) signatures. These signatures are stored as OCI artifacts alongside the images, tagged with the convention sha256-.sig and sha256-.att. The registry.k8s.io domain is backed by archeio , a thin redirector that routes container image requests to the nearest regional Google Artifact Registry backend. When a user in Europe pulls an image, archeio redirects them to europe-west2-docker.pkg.dev; a user in Asia gets redirected to asia-east1-docker.pkg.dev, and so on across 22 regional backends. This geo-routing is great for image layers, where download locality matters for performance. But it created a problem for signatures: if the promoter only wrote a signature to one region, cosign verify would fail for users redirected to any other region. The solution was a dedicated replication pipeline that copied every .sig and .att tag to all 22 regional backends. This pipeline ran as a periodic Prow job every 2 hours on weekdays, performing thousands of API calls per run: listing tags across all repositories, diffing what existed where, and copying the missing signatures. The insight Signatures and attestations are small metadata artifacts, typically a few kilobytes each. Unlike image layers where geo-locality provides meaningful download performance improvements, fetching a signature from a non-local region adds negligible latency. The entire replication pipeline existed to optimize for a latency difference that users would never notice. The solution Instead of replicating signatures everywhere, archeio was taught to route signature req ## EVPN Centralized Routing with Arista EOS DevFeed: [EVPN Centralized Routing with Arista EOS]() Original publisher: [Read original article]() Published: 2026-06-03T05:44:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [evpn](), [Routing (disambiguation)](), [networking](), [VXLAN]() Tags: [arp](), [cache](), [evpn](), [implementation](), [netlab](), [route](), [router](), [routing](), [vxlan]() ### AI overview This article examines which EVPN routes Arista EOS generates in a centralized routing design where a spine switch acts as the router and leaf switches operate at Layer 2. It explains that the central router does not advertise MAC+IP routes for hosts attached to its VLANs, routers must perform their own ARP resolution, and minimal configuration can cause routed traffic to be flooded. ### Source excerpt A month ago, I described ARP issues in EVPN centralized routing design, and Naveen Kumar Devaraj was kind enough to add some Arista EOS implementation details. Today, let's explore what EVPN routes Arista EOS generates in that scenario. We'll use a very simple lab topology with a spine switch acting as a router. The leaf switches are layer-2 switches. Packet forwarding in centralized routing design Read more ... ## Strange route with Jio and GTT as adjacency DevFeed: [Strange route with Jio and GTT as adjacency]() Original publisher: [Read original article]() Published: 2026-04-30T19:42:16Z Content type: article Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [BGP](), [Network](), [clickhouse](), [Internet]() Tags: [as3257](), [as55836](), [bgp](), [clickhouse](), [gtt](), [internet](), [jio](), [network](), [route]() ### AI overview The article investigates a strange BGP route announcement involving Jio (AS55836), GTT (AS3257), Tata Comm (AS6453), Airtel (AS9498), and Brazilian networks. Querying a ClickHouse table of route-collector data showed the route only at collectors in Rio de Janeiro and Fortaleza, and the author could not determine which of three Brazilian ASNs generated it. ### Source excerpt Last month (on 18th April 2026), I saw an alert for a strange route announcement: Prefix AS Path Origin ASN 117.120.58.0/23 262427 262761 263444 6453 3257 55836 9498 134863 134863 Background While this specific alert triggered because it had three large Indian backbones - Tata Comm (AS6453), Jio (AS55836) and Airtel (AS9498) and normally this would appear just as a leak by Jio for routes learnt from Airtel (a known peer of Jio), but AS3257 before Jio makes it strange and interesting. AS3257 is a known transit-free network GTT. Jio is not known to be connected to them at all. Jio does have a mix of transit & peering internationally via AS64049 but not via AS55836. When they started, they had some transit via Tata Comm (AS4755) for a few early days of the launch. After that AS55836 only has peering with Tata Comm (AS4755) and Airtel (AS9498), besides technically transit via their own AS64049 which takes transit from Arelion (AS1299), Cogent (AS174) and NTT (AS2914) and a mix of transit/peering relations with Lumen (AS3356). Who possibly caused it? The AS_PATH here: 262427 262761 263444 6453 3257 55836 9498 134863 can be read backwards to understand the announcement: SP Internet (134863) > Airtel (9498) > Jio (55836) > GTT (AS3257) > Tata Comm (AS6453) > Open X Tecnologia (AS263444) > Sinal Br Telecom (AS262761) > Invista Net Provedor (AS262427). As mentioned in a post last year, I hold recent routes in a Clickhouse table from various route collectors. This makes it easy to query a large number of routes quickly. SELECT count(*) FROM bgp.table Query id: df33f954-7fbd-41a3-8de2-184990ca06d4 ┌─────count()─┐ 1. │ 68882920533 │ -- 68.88 billion └─────────────┘ 1 row in set. Elapsed: 0.034 sec. Let's ask this table of 68.88 billion routes for routes matching AS_PATH: 3257 55836: SELECT timestamp, prefix, as_path, collector FROM bgp.table WHERE arrayExists(i -> ((i < length(as_path)) AND ((as_path[i]) = 3257) AND ((as_path[i + 1]) = 55836)), arrayEnumerate(as_path)) Query id ## Putting the Tech in Fintech: How We Use FIX to Execute Trades at Scale DevFeed: [Putting the Tech in Fintech: How We Use FIX to Execute Trades at Scale]() Original publisher: [Read original article]() Author: Grace Sun Published: 2026-04-22T00:27:03Z Content type: article Language: en Sources: [Wealthfront]() Topics: [distributed-systems](), [networking](), [Transactions](), [Back end](), [IP routing](), [TCP/IP]() Tags: [architecture](), [backend](), [distributed](), [financial](), [infrastructure](), [networking](), [route](), [scale](), [systems](), [tcp-ip](), [tech](), [technology](), [trading](), [transactions](), [wealthfront-engineering]() ### AI overview Wealthfront explains the distributed-systems infrastructure it uses to route and execute large volumes of stock trades. The article describes broker networking, IP routing, the FIX protocol, and the application layers supporting automated, low-latency trade execution. ### Source excerpt At Wealthfront, the "tech" in financial technology isn't just a buzzword--it's the foundation of everything we build. Beneath the intuitive frontend our clients interact with lies a complex ecosystem of distributed systems. One of the most critical pieces of that backend architecture is the engine that enables us to route massive volumes of trades efficiently. ... Read more ## Lab: Distributing Level-2 IS-IS Routes into Level-1 Areas DevFeed: [Lab: Distributing Level-2 IS-IS Routes into Level-1 Areas]() Original publisher: [Read original article]() Published: 2026-01-21T07:06:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [IS-IS](), [GitHub]() Tags: [browser](), [github](), [infrastructure](), [is-is](), [netlab](), [ospf](), [route]() ### AI overview This lab explains how IS-IS handles inter-area routes differently from OSPF. It explores distributing level-2 IS-IS routes into level-1 areas, including the default behavior and its consequences. ### Source excerpt One of the major differences between OSPF and IS-IS is their handling of inter-area routes. Non-backbone OSPF intra-area routes are copied into the backbone area and later (after the backbone SPF run) copied into other areas. IS-IS does not copy level-2 routes into level-1 areas; level-1 areas (by default) behave like totally stubby OSPF areas with the level-1 routers using the Attached (ATT) bit of level-1-2 routers in the same area to generate the default route. Read more ... ## Lab: Multilevel IS-IS Deployments DevFeed: [Lab: Multilevel IS-IS Deployments]() Original publisher: [Read original article]() Published: 2025-12-12T10:45:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [IS-IS](), [Scalability](), [GitHub](), [browser]() Tags: [browser](), [github](), [infrastructure](), [is-is](), [netlab](), [ospf](), [route](), [router](), [scalability]() ### AI overview This lab tutorial explains multilevel IS-IS, including its Level 1, Level 2, and Level 1-2 router roles and its scalability relationship to OSPF areas. It directs readers to a Multilevel IS-IS Deployments lab that can be started in a browser using GitHub Codespaces or local infrastructure with netlab. ### Source excerpt Like OSPF, IS-IS was designed when router memory was measured in megabytes and clock speeds in megahertz. Not surprisingly, it includes a scalability mechanism similar to OSPF areas. An IS-IS router could be a level-1 router (having in-area prefixes and a default route), a level-2 router (knowing just inter-area prefixes), or a level-1-2 router (equivalent to OSPF ABR). Even though multilevel IS-IS is rarely used today, it always makes sense to understand how things work, and the Multilevel IS-IS Deployments lab exercise created by Dan Partelly gives you a perfect starting point. Read more ... ## Lab: IS-IS Route Redistribution DevFeed: [Lab: IS-IS Route Redistribution]() Original publisher: [Read original article]() Published: 2025-11-28T06:45:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [IS-IS](), [GitHub](), [browser]() Tags: [browser](), [github](), [infrastructure](), [is-is](), [netlab](), [route](), [router]() ### AI overview This lab examines route redistribution into IS-IS, including how redistributed prefixes are included in router LSPs and how implementations use metric bits and TLVs. It also provides a safe environment for exploring LSP database contents. ### Source excerpt Route redistribution into IS-IS seems even easier than its OSPFv2/OSPFv3 counterparts. There are no additional LSAs/LSPs; the redistributed prefixes are included in the router LSP. Things get much more interesting once you start looking into the gory details and exploring how different implementations use (or do not) the various metric bits and TLVs. You'll find more details (and the opportunity to explore the LSP database contents in a safe environment) in the IS-IS Route Redistribution lab exercise. Read more ... ## Multi-Pod EVPN Troubleshooting: Route Targets DevFeed: [Multi-Pod EVPN Troubleshooting: Route Targets]() Original publisher: [Read original article]() Published: 2025-11-25T05:49:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [evpn](), [BGP](), [Network](), [Network design]() Tags: [bgp](), [evpn](), [netlab](), [network](), [route](), [troubleshooting]() ### AI overview This fourth post in a Multi-Pod EVPN troubleshooting series explains why LA does not recognize LB as a remote VTEP after BGP next hops are corrected. The cause is a mismatch between the route target exported by LB and the route target imported by LA. The post presents adding remote import route targets or configuring consistent import and export route targets across autonomous systems as fixes. ### Source excerpt Last week, we fixed the incorrect BGP next hops in our sample multi-pod EVPN fabric. With that fixed, every PE device should see every other PE device as a remote VTEP for ingress replication purposes. However, that's not the case; let's see why and fix it. Note: This is the fourth blog post in the Multi-Pod EVPN series. If you stumbled upon it, start with the design overview and troubleshooting overview posts. More importantly, familiarize yourself with the topology we'll be using; it's described in the Multi-Pod EVPN Troubleshooting: Fixing Next Hops. Ready? Let's go. Here's our network topology: Read more ... ## Multi-Pod EVPN Troubleshooting: Fixing Next Hops DevFeed: [Multi-Pod EVPN Troubleshooting: Fixing Next Hops]() Original publisher: [Read original article]() Published: 2025-11-18T06:27:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [evpn](), [BGP](), [Network](), [configuration]() Tags: [bgp](), [configuration](), [evpn](), [evpn-designs](), [netlab](), [network](), [route](), [troubleshooting]() ### AI overview This tutorial demonstrates troubleshooting a multi-pod EVPN network by checking BGP route propagation and inclusive multicast routes. It identifies an incorrect EVPN next-hop change across an EBGP session and explains how to trace the responsible configuration. ### Source excerpt Last month, I wrote about the specifics of troubleshooting multi-pod EVPN designs. Today, I'd like to start a journey through an example in which (channeling my inner CCIE preparation lab instructor) I broke as many things as I could think of. Here's the lab topology we'll use (and as usual, the corresponding netlab topology file and device configurations are on GitHub). Our network has two sites (pods), each with a spine switch, a leaf switch, and a host attached to the leaf switch. The inter-pod link is connected to the spine switches to minimize the number of devices. Read more ... ## Using BIRD BGP Daemon as a BGP Route Reflector DevFeed: [Using BIRD BGP Daemon as a BGP Route Reflector]() Original publisher: [Read original article]() Published: 2025-10-03T05:51:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [BGP](), [GitHub](), [configuration]() Tags: [autonomous](), [bgp](), [browser](), [container](), [github](), [netlab](), [route]() ### AI overview A challenge lab guides readers through configuring the BIRD daemon in a container as a BGP route reflector in a transit autonomous system. It uses GitHub Codespaces or a local lab setup, with netlab commands to build the BIRD container and start the lab. ### Source excerpt In this challenge lab, you'll configure a BIRD daemon running in a container as a BGP route reflector in a transit autonomous system. You should be familiar with the configuration concepts if you completed the IBGP lab exercises, but will probably struggle with BIRD configuration if you're not familiar with it. Click here to start the lab in your browser using GitHub Codespaces (or set up your own lab infrastructure). After starting the lab environment, change the directory to challenge/01-bird-rr, build the BIRD container with netlab clab build bird if needed, and execute netlab up. ## -\> BGP handling bug causes widespread internet routing instability DevFeed: [-\> BGP handling bug causes widespread internet routing instability]() Original publisher: [Read original article]() Published: 2025-05-28T13:06:04Z Content type: article Language: en Sources: [BGPexpert]() Topics: [BGP](), [Routing (disambiguation)](), [incident](), [networking](), [Internet Traffic]() Tags: [bgp](), [bug](), [eos](), [incident](), [internet-traffic](), [juniper](), [network](), [route](), [router](), [routing](), [servers]() ### AI overview The article analyzes a May 20, 2025 BGP incident in which a corrupt BGP Prefix-SID attribute containing zeroed internal data interacted with JunOS and Arista EOS behavior. JunOS propagated the message, while Arista EOS devices reset sessions, causing routing instability and potentially brief connectivity loss for some networks. ### Source excerpt benjojo reports: At 7AM (UTC) on Tuesday May 20th 2025 a BGP message was propagated that triggered surprising (to many) behaviours with two major BGP implementations that are often used for carrying internet traffic. This caused a large number of "internet facing" BGP sessions to automatically shut down, causing at the very least some routing instability, and at worst brief loss of connectivity for some networks. BGP implementations failing in various ways after seeing something incorrect/unexpected is definitely not a new thing... ## OSPF Loop Prevention with Area Range Summary LSAs DevFeed: [OSPF Loop Prevention with Area Range Summary LSAs]() Original publisher: [Read original article]() Published: 2025-05-06T06:17:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [Networks](), [Network]() Tags: [networks](), [ospf](), [route](), [router]() ### AI overview This article examines how OSPF prevents summarized area-range LSAs from being reinserted into the area from which they originated. It explains that the prevention depends on the area range being configured and active, and describes the related discard route behavior and a link-shutdown scenario. ### Source excerpt In a previous blog post, I described how OSPF route selection rules prevent a summary LSA from being inserted back into an area from which it was generated. That works nicely for area prefixes turned directly into summary LSAs, but how does the loop prevention logic work for summarized prefixes (what OSPF calls area ranges)? TL&DR: It doesn't, unless... ;) Read more ... ## How Linux ARP Behavior Can Break Static-Route Tests with Multiple Next Hops DevFeed: [How Linux ARP Behavior Can Break Static-Route Tests with Multiple Next Hops]() Original publisher: [Read original article]() Published: 2025-04-22T05:55:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [Linux](), [Network](), [Ethernet]() Tags: [arp](), [ethernet](), [experiment](), [linux](), [netlab](), [network](), [route](), [tests](), [validation]() ### AI overview The article investigates a netlab integration-test failure involving static routes with two next hops. It finds that default ARP behavior on a multi-subnet Linux host can cause Linux to send an ARP request using the IP address of another interface, while Junos does not answer it, causing the ping test to fail until the ARP cache is warmed. ### Source excerpt The amount of weird stuff we discover in netlab integration tests is astounding, or maybe I have a knack for looking into the wrong dark corners (my wife would definitely agree with that). Today's special: when having two next hops kills a static route. TL&DR: default ARP settings on a multi-subnet Linux host are less than optimal. We use these principles when creating netlab integration tests: They should contain a single device-under-test and a bunch of attached probes. They should test a single feature. They should not rely on the device-under-test. All validation has to be done on probes. How do you test static routes under these restrictions? Here's what we did: Read more ... ## iBGP Local-AS Next Hop Requirements DevFeed: [iBGP Local-AS Next Hop Requirements]() Original publisher: [Read original article]() Published: 2025-04-08T06:08:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [BGP](), [Network](), [Protocol (disambiguation)]() Tags: [bgp](), [configuration](), [network](), [operating-systems](), [route](), [router](), [test]() ### AI overview This article examines the requirements and caveats of using BGP local-as to simulate an iBGP session between different autonomous systems. Integration testing across multiple platforms found that neighbor next-hop-self is required because the next hop is not changed on an iBGP session and may otherwise be unreachable without an underlying IGP. ### Source excerpt Did you know you could use the neighbor local-as BGP functionality to fake an iBGP session between different autonomous systems? I knew Cisco IOS supported that monstrosity for ages (supposedly "to merge two ISPs that have different AS numbers") and added the appropriate tweaks1 into netlab when I added the BGP local-as support in release 1.3.1. Someone couldn't resist pushing us down that slippery slope, and we ended with IBGP local-as implemented on 18 platforms (almost a dozen network operating systems). I even wrote a related integration test, and all our implementations passed it until I asked myself a simple question: "But does it work?" and the number of correct implementations that passed the test without warnings dropped to zero. Read more ... ## Use BGP Outbound Route Filters (ORF) for IP Prefixes DevFeed: [Use BGP Outbound Route Filters (ORF) for IP Prefixes]() Original publisher: [Read original article]() Published: 2025-01-24T07:11:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [BGP](), [browser](), [GitHub]() Tags: [bgp](), [cpu](), [cycles](), [filter](), [ip](), [mpls](), [netlab](), [route]() ### AI overview This tutorial explains how BGP Outbound Route Filters (ORF) for IP prefixes can reduce unnecessary BGP updates and CPU use compared with inbound filtering. It points readers to a practical lab exercise using a browser-based GitHub Codespace and netlab. ### Source excerpt When a BGP router cannot fit the whole BGP table into its forwarding table (FIB), we often use inbound filters to limit the amount of information the device keeps in its BGP table. That's usually a waste of resources: The BGP neighbor has to send information about all prefixes in its BGP table The device with an inbound filter wastes additional CPU cycles to drop many incoming updates. Wouldn't it be better for the device with an inbound filter to push that filter to its BGP neighbors? Read more ... ## React Router 7: Nested Routes DevFeed: [React Router 7: Nested Routes]() Original publisher: [Read original article]() Author: Robin Wieruch Published: 2025-01-06T05:52:52Z Content type: tutorial Language: en Sources: [Robin Wieruch]() Topics: [React Router](), [Tutorial](), [Routing (disambiguation)]() Tags: [how-to](), [react](), [react-router](), [react-router-7](), [react-router-nested-routes](), [react-router-tutorial](), [route](), [router](), [routing]() ### AI overview A step-by-step tutorial on using nested routes with React Router 7. It demonstrates tab-like navigation within a user page, explains index and fallback routes, and shows how to map nested paths to Route components. ### Source excerpt How to: Nested Routes in React Router 7. A step by step example on Nested Routes with React Router ... ## React Router 7: Example DevFeed: [React Router 7: Example]() Original publisher: [Read original article]() Author: Robin Wieruch Published: 2025-01-06T05:52:49Z Content type: tutorial Language: en Sources: [Robin Wieruch]() Topics: [React Router](), [Tutorial](), [Code]() Tags: [code](), [component](), [components](), [layout](), [links](), [react](), [react-router](), [react-router-7](), [react-router-example](), [route](), [router](), [tutorial]() ### AI overview A brief React Router 7 tutorial demonstrates matching routes with links, layout and index routes, no-match fallback handling, and active links. It also points to advanced topics including nested, dynamic, descendant, protected, and authentication routes. ### Source excerpt A brief React Router 7 example to get you started ... [Next page]()