# OSPF Published articles for OSPF. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## The Never-Ending IPv6 Loopback Prefix Saga DevFeed: [The Never-Ending IPv6 Loopback Prefix Saga]() Original publisher: [Read original article]() Published: 2026-08-17T06:02:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [Network](), [Hardware](), [datacenter](), [BGP]() Tags: [bgp](), [datacenter](), [hardware](), [ios](), [ipv6](), [is-is](), [netlab](), [network](), [ospf](), [vxlan]() ### AI overview The article examines the IPv6 loopback-prefix problem in high-speed routers and data-center switches. OSPFv3 requires loopbacks to be advertised as /128s, which can increase forwarding hardware demands when /64 addressing is preferred. It compares vendor behaviors and suggests IS-IS or BGP as possible alternatives. ### Source excerpt Remember the sage advice to simplify your life and use the IPv6 /64 prefixes everywhere? Not only does it make your life simpler (and wastes immesuarably less address space than the crazy "let's assign /64 to every device" stupidity), it also reduces the hardware requirements in your high-speed routers layer-3 switches. You see, doing lookups on 64 bits uses half the silicon it takes to do lookups on 128 bits. Alas, some people never got the memo. OSPFv3 standard clearly states in one of the bullets in section 4.4.3.9 that the loopback prefixes should always be advertised as /128s regardless of what's configured on the interface. Read more ... ## netlab 26.07: GRE, Wireguard, Graceful Restart, and Scale-Out Labs DevFeed: [netlab 26.07: GRE, Wireguard, Graceful Restart, and Scale-Out Labs]() Original publisher: [Read original article]() Published: 2026-07-13T06:23:00Z Content type: release Language: en Sources: [ipSpace.net blog]() Topics: [releases](), [BGP](), [Server](), [evpn](), [VXLAN](), [configuration](), [GitHub]() Tags: [bgp](), [configuration](), [evpn](), [getting-started](), [github](), [gre](), [guide](), [installation](), [netlab](), [ospf](), [policy](), [release](), [releases](), [router](), [upgrade](), [vxlan]() ### AI overview The netlab 26.07 release adds scale-out labs through a multiserver plugin, GRE and WireGuard tunnel support, graceful restart capabilities, BGP policy roles, and expanded BIRD, FortiOS, MikroTik RouterOS, and OpenBSD functionality. It also removes the VirtualBox provider, makes BIRD v3 the default, and changes MikroTik RouterOS 7 BGP template syntax. ### Source excerpt The highlights of netlab release 26.07 include: The multiserver plugin by @muddyblack distributes containerlab devices across multiple servers. The GRE tunnel plugin supports GRE tunnels on Cisco IOS, FRR, VyOS, and Junos (vSRX and vJunos-router) (most device implementations done by @ssasso and @jbemmel). The WireGuard tunnel plugin by @jbemmel supports WireGuard tunnels on FRR. The bgp.session plugin and the OSPF module support graceful restart on Arista EOS, BIRD, FortiOS, and FRR (by @jbemmel and @a-v-popov) The bgp.policy plugin supports the bgp.role attribute on FRR and BIRD (by @jbemmel). But wait, there's more ;) Read more ... ## No Lab, No Problem: Record CML2 Devices into pyATS Mocks for CI DevFeed: [No Lab, No Problem: Record CML2 Devices into pyATS Mocks for CI]() Original publisher: [Read original article]() Author: Brent Leekley Published: 2026-06-27T00:00:00Z Content type: tutorial Language: en Sources: [brent.leekley.me blog]() Topics: [GitHub Actions](), [Testing](), [GitHub](), [Network]() Tags: [ci](), [ci-cd](), [cisco](), [cisco-modeling-labs](), [cml](), [cml2](), [genie](), [github-actions](), [mock-devices](), [network-automation](), [network-testing](), [ospf](), [playback](), [pyats](), [record-and-replay](), [testing](), [unicon]() ### AI overview This tutorial explains how to record responses from real Cisco Modeling Labs 2 devices with pyATS and unicon, commit the recordings, and replay the same test suite in GitHub Actions. Replay allows the tests to run offline without booting or connecting to the lab. ### Source excerpt Develop against the live CML2 lab, then record it once with unicon playback and replay the exact same pyATS suite in GitHub Actions with no lab to license or reach. Point the testbed at an unreachable address and the suite still passes, because replay never opens a socket. Includes a real companion repo with a green Actions run. Fourth in a pyATS + CML2 network programmability series. ## The Snapshot Machine: genie learn and diff as a Change-Validation Safety Net on CML2 DevFeed: [The Snapshot Machine: genie learn and diff as a Change-Validation Safety Net on CML2]() Original publisher: [Read original article]() Author: Brent Leekley Published: 2026-06-22T00:00:00Z Content type: tutorial Language: en Sources: [brent.leekley.me blog]() Topics: [networking](), [Cisco](), [Routing (disambiguation)](), [Structured-data](), [Command-line interface]() Tags: [change-validation](), [cisco](), [cisco-modeling-labs](), [cli](), [cml2](), [genie](), [genie-diff](), [genie-learn](), [maintenance-window](), [network-automation](), [network-testing](), [ospf](), [pyats](), [routing-table](), [snapshot](), [structured](), [validation]() ### AI overview This tutorial demonstrates using Cisco Modeling Labs 2 with Genie learn and diff to validate network changes. It snapshots structured operational state before and after a maintenance change, then compares the snapshots to reveal side effects that routine show commands may miss. The source summary reports that a changed OSPF cost reroutes three destinations while adjacencies remain FULL. ### Source excerpt Snapshot a CML2 fabric with genie learn before and after a maintenance change, then genie diff the structured state. One fat-fingered OSPF cost quietly reroutes three destinations while every adjacency stays FULL. Structured before-and-after diffs catch the side effects that show commands miss. ## SR-MPLS with OSPFv2 DevFeed: [SR-MPLS with OSPFv2]() Original publisher: [Read original article]() Published: 2026-06-15T06:12:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [SR-MPLS](), [networking](), [Routing (disambiguation)](), [Protocol (disambiguation)](), [IS-IS](), [GitHub]() Tags: [container](), [github](), [is-is](), [mpls](), [netlab](), [ospf](), [protocol](), [routing](), [sr-mpls]() ### AI overview A hands-on tutorial showing how to configure and inspect SR-MPLS over OSPFv2 with netlab. It explains the OSPFv2 opaque LSAs used to advertise SR-MPLS information and notes that the resulting MPLS forwarding table matches the comparable IS-IS example. ### Source excerpt I started my part of the Segment Routing workshop @ ITNOG10 exploring SR-MPLS with IS-IS (simple SR-MPLS, dual-stack SR-MPLS, SR-MPLS over unnumbered IPv4 interfaces). Next step: let's change the routing protocol to OSPF while using the same network topology: Read more ... ## From Intent to Reality: Driving pyATS Tests from NetBox Against a CML2 Fabric DevFeed: [From Intent to Reality: Driving pyATS Tests from NetBox Against a CML2 Fabric]() Original publisher: [Read original article]() Author: Brent Leekley Published: 2026-06-15T00:00:00Z Content type: tutorial Language: en Sources: [brent.leekley.me blog]() Topics: [NetBox](), [Network](), [Cisco](), [data](), [Structured-data]() Tags: [cisco-modeling-labs](), [cml](), [cml2](), [custom-fields](), [genie](), [ids](), [intent-based-networking](), [netbox](), [network](), [network-automation](), [network-testing](), [ospf](), [pyats](), [pynetbox](), [router-id](), [source-of-truth](), [spine-leaf](), [structured](), [testbed]() ### AI overview This tutorial shows how to store declared OSPF router-IDs in NetBox and use Cisco pyATS to compare them with the router-IDs on a live CML2 spine-leaf fabric. The comparison turns network intent validation into a pass-or-fail test. ### Source excerpt NetBox holds the intent (declared OSPF router-IDs), a CML2 spine-leaf is the network under test, and pyATS is the judge. Close the loop and prove the live network matches what you said it should be, with real pass and fail output. ## Build the Lab Once, Test It Forever: A CML2 Spine-Leaf Wired for pyATS DevFeed: [Build the Lab Once, Test It Forever: A CML2 Spine-Leaf Wired for pyATS]() Original publisher: [Read original article]() Author: Brent Leekley Published: 2026-06-14T00:00:00Z Content type: tutorial Language: en Sources: [brent.leekley.me blog]() Topics: [Network](), [Testing](), [Cisco](), [Code](), [API](), [Parser]() Tags: [api](), [cisco](), [cisco-modeling-labs](), [cml](), [cml2](), [code](), [genie](), [iol-xe](), [network-automation](), [network-testing](), [ospf](), [parsing](), [pyats](), [spine-leaf](), [testbed](), [virl2-client]() ### AI overview This tutorial describes a four-node spine-leaf lab in Cisco Modeling Labs 2 (CML2) that generates a Cisco pyATS testbed from the CML API. The approach treats the lab definition as the source of truth so regenerated inventories remain aligned with topology changes, and uses an OSPF underlay with a management network. ### Source excerpt Stop hand-maintaining your pyATS testbed. Build a four-node spine-leaf in CML2 as code, then generate the testbed straight from the CML API so it never drifts from the lab, with live Genie-parsed proof over a System Bridge management network. ## Cisco IOS/XR OSPFv2 Not-So-Passive Interfaces DevFeed: [Cisco IOS/XR OSPFv2 Not-So-Passive Interfaces]() Original publisher: [Read original article]() Published: 2026-02-19T06:46:00Z Content type: opinion Language: en Sources: [ipSpace.net blog]() Topics: [Cisco](), [Testing](), [Network](), [Protocol (disambiguation)]() Tags: [cisco](), [linux](), [netlab](), [network](), [open](), [ospf](), [script](), [test](), [testing]() ### AI overview The article reports that Cisco IOS/XR 25.2.1 sends two OSPFv2 hello packets shortly after configuration on an interface marked passive, then stops sending them. This behavior caused a netlab integration test to fail with a neighbor in the Init state; the author worked around it by clearing the OSPF neighbor on the connected FRRouting container. ### Source excerpt What's wrong with me? Why do I have to uncover another weirdness every single time I run netlab integration tests on a new platform? Today, it's Cisco IOS/XR (release 25.2.1) and its understanding of what "passive" means. According to the corresponding documentation, the passive interface configuration command is exactly what I understood it to be: Use the passive command in appropriate mode to suppress the sending of OSPF protocol operation on an interface. However, when I ran the OSPFv2 passive interface integration test with an IOS/XR container, it kept failing with neighbor is in Init state (the first and only time I ever encountered such an error after testing over two dozen platforms). 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 ... ## Do You Need IS-IS Areas? DevFeed: [Do You Need IS-IS Areas?]() Original publisher: [Read original article]() Published: 2026-01-14T07:45:00Z Content type: opinion Language: en Sources: [ipSpace.net blog]() Topics: [IS-IS](), [networking](), [migration]() Tags: [github](), [is-is](), [network](), [networks](), [ospf](), [routing]() ### AI overview The article explains when IS-IS areas are useful. Most networks can likely operate with a single area, but hierarchy can help with fault isolation and route summarization, especially on constrained hardware. It recommends checking device capabilities because some implementations may not support inter-level prefix propagation. ### Source excerpt TL&DR: Most probably not, but if you do, you'd better not rely on random blogs for professional advice #justSaying 😜 Here's an interesting question I got from a reader in the midst of an OSPF-to-IS-IS migration: Why should one bother with different [IS-IS] areas when the routing hierarchy is induced by the two levels and the appropriate IS-IS circuit types on the links between the routers? Well, if you think you need a routing hierarchy, you're bound to use IS-IS areas because that's how the routing hierarchy is implemented in IS-IS. However... 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 ... ## netlab 25.12: Cisco IOS/XR Configuration Modules, More VXLAN Goodies DevFeed: [netlab 25.12: Cisco IOS/XR Configuration Modules, More VXLAN Goodies]() Original publisher: [Read original article]() Published: 2025-12-08T06:16:00Z Content type: release Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [Cisco](), [releases](), [BGP](), [Release notes](), [VXLAN](), [configuration]() Tags: [bgp](), [bugs](), [cisco](), [configuration](), [improvements](), [ipv6](), [netlab](), [ospf](), [release](), [release-notes](), [replication](), [routing](), [validation](), [vxlan]() ### AI overview The netlab 25.12 release improves Cisco IOS/XR configuration support and adds VXLAN-over-IPv6 on Arista EOS, VXLAN ingress replication on Cisco Catalyst 8000v, larger BGP community lists, and changes to validation test handling. ### Source excerpt netlab release 25.12 (25.12.02 to be exact - I had a few PEBCAK moments) was published last Friday. Here are the highlights: Significantly improved Cisco IOS/XR support. With the netlab release 25.12, you can configure VLANs, VRFs, static routes, route redistribution, OSPF default routes, BGP confederations, and BGP local-as VXLAN-over-IPv6 on Arista EOS VXLAN with ingress replication on Cisco Catalyst 8000v The shutdown link/interface attribute can be used to start labs with interfaces turned off Large BGP community lists, implemented on Arista EOS, FRR, and Junos. You can use standard- or large community lists in routing policies The netlab validate command will reread validation tests from a modified lab topology file every time you run it. It can also read validation tests from a separate file. Read more ... ## OSPFv3 Router ID Documentation on Arista EOS DevFeed: [OSPFv3 Router ID Documentation on Arista EOS]() Original publisher: [Read original article]() Published: 2025-11-27T06:27:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [Network](), [Documentation]() Tags: [configuration](), [errors](), [ospf](), [reference](), [technical]() ### AI overview This article reviews inaccuracies in Arista EOS documentation for the OSPFv3 router-id command and describes implementation gotchas involving missing or removed router IDs and IPv4 addresses. It notes that the EOS documentation was fixed around release 4.36.0F. ### Source excerpt When I published a blog post making fun of the ridiculously incorrect Cisco IOS/XE OSPFv3 documentation, an engineer working for Cisco quickly sent me an email saying, "Well, the other vendors are not much better." Let's see how well Arista EOS is doing; this is their description of the router-id command (taken from EOS 4.35.0F documentation; unchanged for at least a dozen releases): 2026-04-14: The EOS documentation has been fixed around release 4.36.0F. Thanks a million! Read more ... ## IOS/XR Route Redistribution Configuration Mess DevFeed: [IOS/XR Route Redistribution Configuration Mess]() Original publisher: [Read original article]() Published: 2025-11-24T06:43:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [Cisco](), [Routing (disambiguation)](), [configuration](), [Network](), [BGP](), [IS-IS](), [networking]() Tags: [bgp](), [boot](), [cisco](), [configuration](), [is-is](), [netlab](), [network](), [ospf](), [protocol](), [routing](), [syntax](), [tests]() ### AI overview This article examines route redistribution on Cisco IOS/XR, showing that OSPFv2/OSPFv3, IS-IS, and BGP use inconsistent syntax for the source protocol in redistribute commands. The inconsistencies make reusable configuration templates more difficult to create. ### Source excerpt One would hope that the developers of a network operating system wouldn't feel the irresistible urge to reinvent what should have been a common configuration feature for every routing protocol. Alas, the IOS/XR developers failed to get that memo. I decided to implement route redistribution (known as route import in netlab) for OSPFv2/OSPFv3, IS-IS, and BGP on IOS/XR (Cisco 8000v running IOS/XR release 24.4.1) and found that each routing protocol uses a different syntax for the source routing protocol part of the redistribute command. Read more ... ## netlab: Test IPv6 IGP Deployment DevFeed: [netlab: Test IPv6 IGP Deployment]() Original publisher: [Read original article]() Published: 2025-11-10T06:45:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [Routing (disambiguation)](), [Deployment](), [Protocol (disambiguation)](), [Testing]() Tags: [container](), [container-image](), [containers](), [deployment](), [github](), [guide](), [install](), [installation](), [ipv6](), [is-is](), [netlab](), [ospf](), [protocol](), [router](), [routing](), [testing]() ### AI overview This tutorial shows how to use netlab to test IPv6 IGP deployments in a virtual lab. It explains how to add IPv6 prefixes while limiting OSPF deployment to OSPFv2 instead of configuring both OSPFv2 and OSPFv3, using a global address-family parameter. It also describes running the example with Arista cEOS containers or FRRouting in GitHub Codespaces. ### Source excerpt Imagine you have an IPv4-only network1 and want to try out how to deploy a routing protocol for IPv6. netlab is a pretty good tool for the job as it: Creates an addressing scheme for you Designs a routing protocol deployment (OSPF, IS-IS) based on just a few bits of information Deploys ready-to-run router configurations to a virtual lab. Read more ... ## The Curious Case of Default OSPF Interface Timers DevFeed: [The Curious Case of Default OSPF Interface Timers]() Original publisher: [Read original article]() Published: 2025-11-04T06:14:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [Network](), [configuration](), [Logging]() Tags: [configuration](), [devices](), [implementation](), [logging](), [netlab](), [network](), [ospf](), [platform](), [tests](), [validation]() ### AI overview The article explains why OSPF adjacency tests can fail between FRRouting and Arista EOS when only the hello interval is configured. FRRouting derives the dead interval as four times the hello interval, while Arista EOS retains its default unless configured. It describes a netlab release 25.11 fix that calculates the missing timer value. ### Source excerpt We run two types of integration tests before shipping a netlab release: device integration tests that check whether we correctly implemented netlab features on all supported devices, and platform integration tests that check whether rarely-used core functionality works as expected. I want to have some validation included in the platform integration tests to ensure the lab devices are started, and that the links and the management network work as expected. The simplest way to get that done is to start OSPF with short hello intervals (to get adjacency up in no time), for example: Read more ... ## Cisco IOS IPv6 documentation incorrectly described automatic OSPFv3 router ID selection DevFeed: [Cisco IOS IPv6 documentation incorrectly described automatic OSPFv3 router ID selection]() Original publisher: [Read original article]() Published: 2025-10-28T06:52:00Z Content type: opinion Language: en Sources: [ipSpace.net blog]() Topics: [Cisco](), [networking](), [Routing (disambiguation)](), [Documentation](), [OpenAI]() Tags: [automatic](), [cisco](), [documentation](), [ipv6](), [opinion](), [ospf](), [router]() ### AI overview The article criticizes inaccurate Cisco IOS IPv6 documentation about OSPFv3 router ID selection. It explains that the OSPFv3 process does not start without an IPv4 address or a configured router ID, and notes that Cisco later corrected the documentation. ### Source excerpt Found this incredible gem1 hidden in the Usage Guidelines for the OSPFv3 router-id configuration command part of the Cisco IOS IPv6 reference guide. The whole paragraph seems hallucinated2, but that couldn't be because the page was supposedly last updated in 2019, and LLMs weren't good enough to write well-structured nonsense at that time: 2026-04-14: The router-id description in the Cisco IOS IPv6 Reference Guide has been fixed. Thank you! It's so nice to see we can make the world a better place (one snark at a time). Read more ... ## Adding a Syslog Server to a netlab Lab Topology DevFeed: [Adding a Syslog Server to a netlab Lab Topology]() Original publisher: [Read original article]() Published: 2025-10-27T06:23:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [Logging](), [Containers](), [Ansible](), [Open Source]() Tags: [ansible](), [configuration](), [container](), [containers](), [github](), [json](), [logging](), [logs](), [netlab](), [ospf](), [router](), [server](), [storage](), [tcp](), [udp]() ### AI overview A tutorial shows how to add an Rsyslog-based Syslog server to a netlab lab topology. It configures a collector container to receive logs over TCP and UDP, adds Arista cEOS router nodes, applies logging configuration through templates, and verifies the resulting log files. ### Source excerpt netlab does not support a Syslog server (yet), but it's really easy to add one to your lab topology, primarily thanks to the Rsyslog team publishing a ready-to-run container. Let's do it ;) Adding a Syslog Server Rsyslog is an open-source implementation of a Syslog server (with many bells and whistles, most of which we won't use) that can (among other things) log incoming messages to a file. Even better (for our use case), the Rsyslog team regularly publishes Rsyslog containers; we'll use the rsyslog/rsyslog-collector container because it can "receive logs via UDP, TCP, and optionally RELP, and can send them to storage backends or files." Read more ... ## OSPF Router ID and Loopback Interface Myths DevFeed: [OSPF Router ID and Loopback Interface Myths]() Original publisher: [Read original article]() Published: 2025-10-21T06:14:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [Networks](), [Cisco]() Tags: [cisco](), [configuration](), [id](), [interface](), [ipv4](), [networks](), [ospf](), [router]() ### AI overview The article explains that an OSPF router ID is a 32-bit identifier rather than inherently an IPv4 address. It recounts Cisco's historical router ID selection behavior, including the later use of loopback addresses for greater stability and the router-id command, and discusses Cisco IOS handling of duplicate router IDs. ### Source excerpt Daniel Dib wrote a nice article describing the history of the loopback interface1, triggering an inevitable mention of the role of a loopback interface in OSPF and related flood of ancient memories on my end. Before going into the details, let's get one fact straight: an OSPF router ID was always (at least from the days of OSPFv1 described in RFC 1133) just a 32-bit identifier, not an IPv4 address2. Straight from the RFC 1133: Read more ... ## Lab: Hide Transit Subnets in IS-IS Networks DevFeed: [Lab: Hide Transit Subnets in IS-IS Networks]() Original publisher: [Read original article]() Published: 2025-10-17T05:46:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [IS-IS](), [Networks](), [IP routing]() Tags: [browser](), [github](), [ipv4](), [ipv6](), [is-is](), [netlab](), [networks](), [ospf]() ### AI overview A lab exercise demonstrates how to configure IS-IS to exclude IPv4 and IPv6 transit-link subnets from router PDUs and network-wide IP routing tables. The lab can be run with a supported device, GitHub Codespaces, or self-managed infrastructure using netlab. ### Source excerpt Sometimes you want to assign IPv4/IPv6 subnets to transit links in your network (for example, to identify interfaces in traceroute outputs), but don't need to have those subnets in the IP routing tables throughout the whole network. Like OSPF, IS-IS has a nerd knob you can use to exclude transit subnets from the router PDUs. Want to check how that feature works with your favorite device? Use the Hide Transit Subnets in IS-IS Networks lab exercise. Read more ... ## How Cisco IOS/XE and Arista EOS Handle Multiple IP Addresses in "ip host" Configuration DevFeed: [How Cisco IOS/XE and Arista EOS Handle Multiple IP Addresses in "ip host" Configuration]() Original publisher: [Read original article]() Published: 2025-09-11T07:51:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [Cisco](), [IP routing]() Tags: [cisco](), [ethernet](), [ip](), [ip-routing](), [mapping](), [netlab](), [networking](), [ospf](), [router]() ### AI overview The article examines how Cisco IOS Classic, Cisco IOS/XE, and Arista EOS handle multiple IP addresses in the ip host configuration command. It reports differing behavior in host displays, ping target selection, and address ordering, based on a two-router OSPF lab. ### Source excerpt Since time immemorial, I have used the ip host router configuration command to get host-to-IP mappings in networking labs without going through the hassle of setting up a DNS server. Some devices even accepted multiple IP addresses in the ip host command, allowing you to list all router interfaces in a single command and get reverse (IP-to-host) mapping working like a charm. Or so I thought 🤦♂ It turns out I'm too old, and what I know is sometimes no longer true. It seems that the last implementation working as I expected is Cisco IOS Classic ☹ Read more ... ## Always Check Your Tests Against Faulty Inputs DevFeed: [Always Check Your Tests Against Faulty Inputs]() Original publisher: [Read original article]() Published: 2025-07-21T05:19:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [Testing](), [Network]() Tags: [automation](), [blog](), [blog-post](), [false-negative](), [false-positive](), [false-positives](), [netlab](), [network](), [ospf](), [testing](), [tests]() ### AI overview The article explains that tests must be checked with faulty inputs, not only under correct conditions. It uses a netlab integration test for mismatched OSPF network types as an example of a test that could miss the targeted error, and warns that false positives can be more harmful than false negatives. ### Source excerpt A while ago, I published a blog post proudly describing the netlab integration test that should check for incorrect OSPF network types in netlab-generated device configurations. Almost immediately, Erik Auerswald pointed out that my test wouldn't detect that error (it might detect other errors, though) as the OSPF network adjacency is always established even when the adjacent routers have mismatching OSPF network types. I made one of the oldest testing mistakes: I checked whether my test would work under the correct conditions but not whether it would detect an incorrect condition. Read more ... ## Cisco IOS/XE Hates Redistributed Static IPv6 Routes DevFeed: [Cisco IOS/XE Hates Redistributed Static IPv6 Routes]() Original publisher: [Read original article]() Published: 2025-07-18T05:41:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [Cisco](), [BGP](), [networking](), [IP routing]() Tags: [bgp](), [cisco](), [ipv6](), [netlab](), [network](), [ospf](), [router](), [routing](), [tests]() ### AI overview The article examines the difficulty of testing network device configuration, focusing on route redistribution into BGP on Cisco IOS/XE. It reports that OSPF routes were redistributed successfully, while adding static routes exposed unexpected behavior and timing assumptions. ### Source excerpt Writing tests that check the correctness of network device configurations is hard (overview, more details). It's also an interesting exercise in getting the timing just right: Routing protocols are an eventually-consistent distributed system, and things eventually appear in the right place (if you got the configurations right), but you never know when exactly that will happen. You can therefore set some reasonable upper bounds on when things should happen, and declare failure if the timeouts are exceeded. Even then, you'll get false positives (as in: the test is telling you the configurations are incorrect, when it's just a device having a bad hair day). And just when you think you nailed it, you encounter a device that blows your assumptions out of the water. Read more ... ## netlab 25.07: Summaries and Confederations DevFeed: [netlab 25.07: Summaries and Confederations]() Original publisher: [Read original article]() Published: 2025-07-15T07:27:00Z Content type: release Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [BGP](), [Routing (disambiguation)](), [Containers](), [GitHub]() Tags: [bgp](), [evpn](), [guide](), [installation](), [netlab](), [new-features](), [ospf](), [published](), [release](), [routing]() ### AI overview The netlab 25.07 release adds OSPFv2 and OSPFv3 area support, aggregate BGP routes, BGP confederations, EVPN multihoming, OpenBSD support, initial IPv6 router-advertisement configuration, and integration with the Network Unit Testing System. It also improves installation and documents platform support and caveats. ### Source excerpt netlab release 25.07 was published yesterday. The major new features include: The ospf.areas plugin supports OSPFv2 and OSPFv3 stub areas, NSSA areas, and area ranges. The BGP routing policies plugin supports aggregate BGP routes The BGP configuration module supports BGP confederations But wait, there's much more: Read more ... [Next page]()