Ivan Pepelnjak

Author Archives: Ivan Pepelnjak

Happy Holidays and All the Best in 2025!

Another year is almost gone, and it’s time for my traditional “I will disappear until mid-January” retreat (also, don’t expect me to read my email until I’m back).

I hope you’ll also be able to disconnect from the crazy pace of the networking world, forget the “AI will make networking engineers obsolete” shenanigans (hint: SDN did not), and focus on your loved ones. I would also like to wish you all the best in 2025!

I will probably get bored sometime in late December, so expect a few new netlab features in early January.

Worth Reading: Hard Truths about AI-assisted Coding

Addy Osmani published an excellent overview of the challenges of AI-assisted coding. They apply equally well to the “AI will generate device configurations for me” or “AI will troubleshoot my network” ideas (ignoring for the moment the impact of the orders-of-magnitude smaller training set), so it’s definitely worth reading.

I particularly liked the “‌AI is like having a very eager junior developer on your team” take, as well as the description of the “70% problem” (AI will get you 70% there, but the last 30% will be frustrating) – a phenomenon perfectly illustrated by the following diagram by Forrest Brazeal:

Use Disaggregated BGP Prefixes to Influence Inbound Internet Traffic

As much as I love explaining how to use BGP in an optimal way, sometimes we have to do what we know is bad to get the job done. For example, if you have to deal with clueless ISPs who cannot figure out how to use BGP communities, you might be forced to use the Big Hammer of disaggregated prefixes. You can practice how that works in the next BGP lab exercise.

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 policy/b-disaggregate and execute netlab up.

IBGP Source Interface Selection Still Requires Configuration

A fellow networking engineer recently remarked, “FRRouting automatically selects the correct [IBGP] source interface even when not configured explicitly.

TL&DR: No, it does not. You were just lucky.

Basics first1. BGP runs over TCP sessions. One of the first things a router does when establishing a BGP session with a configured neighbor is to open a TCP session with the configured neighbor’s IP address.

Is BGP PIC Edge an Oxymoron?

This blog post discusses an old arcane question that has been nagging me from the bottom of my Inbox for almost exactly four years. Please skip it if it sounds like Latin to you, but if you happen to be one of those readers who know what I’m talking about, I’d appreciate your comments.

Terminology first:

  • Prefix Independent Convergence allows entries in the forwarding table to point to shared next hops (or next-hop groups), reducing the FIB update bottleneck when changing the next hop for a large number of prefixes (for example, when dealing with a core link failure). More details in the initial blog post and PIC applicability to fast reroute.
  • PIC Edge (as defined by vendor marketing) is the ability to switch to a backup CE route advertised to a backup PE router before the network convergence is complete.

Here’s (in a nutshell) how PIC Edge is supposed to work:

Lab: Dual-Stack IS-IS Routing

Contrary to the OSPF world, where we have to use two completely different routing protocols to route IPv4 and IPv6 (unless you believe in the IPv4 address family in OSPFv3), IS-IS provided multi-protocol support from the very early days of its embracement by IETF. Adding IPv6 support was only a matter of a few extra TLVs, but even there, IETF gave us two incompatible ways of making IPv6 work with IS-IS.

Want to know more? You’ll find the details in the Dual-Stack (IPv4+IPv6) IS-IS Routing lab exercise.

IPv6 Support for Multiple Routers and Multiple Interfaces

Fernando Gont published an Individual Internet Draft (meaning it hasn’t been adopted by any IETF WG yet) describing the Problem Statement about IPv6 Support for Multiple Routers and Multiple Interfaces. It’s so nice to see someone finally acknowledging the full scope of the problem and describing it succinctly. However, I cannot help but point out that:

Anyway, Fernando wraps up his draft with:

EVPN Designs: EVPN IBGP over IPv4 EBGP

We’ll conclude the EVPN designs saga with the “most creative” design promoted by some networking vendors: running an IBGP session (carrying EVPN address family) between loopbacks advertised with EBGP IPv4 address family.

Oversimplified IBGP-over-EBGP design

Oversimplified IBGP-over-EBGP design

There’s just a tiny gotcha in the above Works Best in PowerPoint diagram. IBGP assumes the BGP neighbors are in the same autonomous system while EBGP assumes they are in different autonomous systems. The usual way out of that OMG, I painted myself into a corner situation is to use BGP local AS functionality on the underlay EBGP session:

Dynamic BGP Peers

You might have an environment where a route reflector (or a route server) has dozens or hundreds of BGP peers. Configuring them by hand is a nightmare; you should either build a decent automation platform or use dynamic BGP neighbors – a feature you can practice in the next lab exercise.

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 session/9-dynamic and execute netlab up.

Latency Numbers Every Programmer Should Know

One of the key arguments against stretched clusters (and similar stupidities) I used in my Disaster Recovery Myths presentation was the SSD read latency versus cross-site round-trip time.

Thanks to Networking Notes, I found a great infographic I can use in my next presentation (bonus points: it also works great in a terminal when fetched with curl) and a site that checks the latency of your web site from various vantage points.

Using a BGP Route Server in an Internet Exchange Point

A BGP route server is like a BGP route reflector but for EBGP sessions. In its simplest implementation, it receives BGP updates over EBGP sessions and propagates them over other EBGP sessions without inserting its own AS number in the AS path (more details).

BGP route servers are commonly used on Internet Exchange Points (IXPs), and that’s what you can practice in the BGP Route Server in an Internet Exchange Point lab exercise.

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 session/5-routeserver and execute netlab up.

Running Routing Protocols over Tunnels

James got confused by a statement made by Hannes Gredler in his IS-IS book:

Things behave really badly if the total IGP cost over the tunnel undermines the total topologies’ cost. What happens next is that the tunnel “wraps” around itself, ultimately causing a meltdown of the entire network.

Let’s unpack that, starting with “Why would you need a tunnel?”

netlab 1.9.2: STP, LAG, Cisco IOL, Edgeshark

While I was busy fixing bugs in the netlab release 1.9.2, other contributors added exciting new features:

Other new features include:

1 2 3 176