2026 Peering Workshop: Basic Inter-AS Routing with eBGP

Since the IXPN 2026 Peering Workshops in Lagos and Abuja, I have received several LinkedIn messages from engineers who were unable to attend and wanted access to the training materials or session recordings. Unfortunately, the workshops were not recorded.

Rather than let the material disappear after the event, I decided to document the labs covered during the workshops in a series of blog posts. Whether you missed the training entirely or attended and would like a deeper dive into the exercises, this series is for you.

Let’s get started.

Problem

In this first lab, our objective is straightforward: establish inter-domain routing between two autonomous systems, AS65100 and AS65200, allowing them to exchange Network Layer Reachability Information (NLRI) through eBGP.

In AS65100, the internet edge router R1 runs OSPF, EIGRP, and static routing with internal routers R2, R3, and R4. Let’s take a look at R1’s routing table.

We are interested in the three highlighted routes. These are the prefixes that will be injected into BGP and advertised to AS65200.

Take note of the metrics associated with these routes. In this lab, IOS uses the source route metrics to populate the MED attribute when the routes are injected into BGP. As a result, the MED values advertised to external peers mirror the metrics of the original routes. This is a common way to influence how a neighboring AS enters your network when multiple entry points are available.

On the AS65200 side, we have a single router, R5, acting as the internet edge device and simulating an advertised prefix using a loopback interface.

To make things a little more interesting, we have two parallel links between AS65100 and AS65200 so we can demonstrate eBGP load balancing across redundant paths.

One option would be to bundle the two physical links into a LAG and establish BGP across the resulting logical interface. While that approach works, it couples the BGP session to the health of the LAG. Instead, we’ll peer using loopback interfaces and use equal-cost static routes to reach the remote loopback across both physical paths.

I don’t know about you, but I love loopback interfaces ;)

Let’s configure our peering IPs on loopbacks and then point a pair of static routes on each router toward the remote loopback.

and on R5:

Solution

Now that we understand the problem, let’s bring up BGP between the two autonomous systems.

On both R1 and R5, we are targeting the loopback addresses in our BGP configuration. We must also source the BGP session from the loopback interface. This is because BGP expects incoming TCP connections to originate from the configured neighbor address. Since we are peering using loopbacks, the source address of the BGP session must match the neighbor definition on the remote router.

Let’s see if BGP is up from R1’s perspective.

The session is stuck in the Idle state, which means BGP is not even attempting to establish a TCP connection with the peer. Let’s enable BGP debugging on R1 to gather more information.

Now we have a clue. BGP is reporting that there is no route to peer 198.51.100.5.

At first glance, that doesn’t make much sense. R1 clearly has two static routes to the peer’s loopback address installed in its RIB. In fact, CEF has programmed both paths for equal-cost forwarding toward R5.

The issue is that Cisco IOS performs an eBGP connected check by default. IOS expects an eBGP peer to be directly connected and reachable through a connected subnet. Even though the peer is reachable through the routing table, the session will not establish unless the connected check is disabled or eBGP multihop is configured.

For this lab, we can disable the connected check using the disable-connected-check command. Once disabled, the peer can be reached through static routes or dynamically learned routes.

This works well here because R1 and R5 are not establishing a true multihop eBGP session. The routers remain one IP hop apart, and BGP packets continue to be transmitted with a TTL of 1.

Historically, older IOS releases did not support disable-connected-check. In those cases, engineers commonly configured ebgp-multihop to relax the directly connected requirement. Configuring eBGP multihop allows the peer to be reached through recursive routing rather than requiring a connected route.

Sure enough, the BGP session now comes up successfully.

The output of show bgp ipv4 unicast neighbors confirms that the peer is not directly connected, the connected check has been disabled, and the outgoing TTL remains 1.

At this point, the BGP session is established, but we are not yet advertising any routes. Let’s inject our prefixes into BGP on both sides.

Let’s verify the BGP Loc-RIB on R1.

Everything looks good.

R1 has originated the three prefixes from AS65100, while R5 is advertising the 192.0.2.0/24 prefix from AS65200.

The injected routes retain information derived from their source routes, including metric values that IOS uses to populate MED. Note also that the nexthops of thess prefixes are inherited from the original IGP routes.

Before advertising the routes to R5, R1 updates the next-hop attribute to its peering address. This is the default behavior for eBGP advertisements.

There is one notable exception. When advertising routes across a shared broadcast segment—such as an Internet Exchange Point (IXP)—a router may advertise a third-party next hop instead of itself. This behavior is common on IXPs because it allows traffic to flow directly between participants without unnecessary forwarding through intermediate routers.

On the AS65200 side, R5 is successfully learning the three prefixes from AS65100.

Notice that the received routes have R1 as their next hop, exactly as expected.

Let’s perform a quick reachability test between 192.0.2.5 and 172.16.2.2.

Success.

The output of show ip cef 172.16.2.2 detail on R5 confirms that we are indeed load sharing across the two parallel links.

At this point, we have established eBGP connectivity between AS65100 and AS65200, exchanged reachability information, and verified end-to-end connectivity between prefixes in both autonomous systems.

In the next lab, we’ll build on this foundation and explore IGP implementation within a transit AS.