Capstone: Three Autonomous Systems

Three autonomous systems. You build all of it.

No router bgp is staged anywhere. No neighbors, no advertised routes, nothing. The interfaces have addresses and that is it. By the end, every AS must reach every other AS's loopback, including the two on the ends that can only talk through the AS in the middle. This is the proof that the eBGP fundamentals stuck.

Topology

The interface and loopback addressing is already configured on all three routers. Everything BGP is yours to build.

Deploy the lab

Download the lab and unzip it (the download includes the topology and the router configs). From inside the unzipped folder, run:

containerlab deploy -t topology.clab.yml

That boots all three routers. Drop into r1's FRR shell (and open r2 and r3 in their own terminals the same way):

docker exec -it clab-bgp-ebgp-capstone-r1 vtysh

docker exec -it clab-bgp-ebgp-capstone-r2 vtysh
docker exec -it clab-bgp-ebgp-capstone-r3 vtysh

Your mission

Build the whole thing from scratch so the network is fully reachable end to end:

• On every router, start a BGP process in its own AS (router bgp <asn>).
• Bring up eBGP to each directly connected neighbor. r1 has one neighbor (r2), r3 has one neighbor (r2), and r2 has two (r1 and r3): r2 is the transit AS in the middle.
• Advertise each router's loopback into BGP with network <loopback>/32 so the prefixes have somewhere to come from.
• Set no bgp ebgp-requires-policy under router bgp on all three routers, or FRR's RFC 8212 default filters every eBGP route and you will see (Policy) instead of routes.
• You do not configure transit explicitly: once r2 has both sessions up, it automatically re-advertises the eBGP routes it learns, so r1 and r3 reach each other through AS 65002.

Objectives

• ✅ The eBGP session from r1 to 10.0.12.2 is Established.
• ✅ The eBGP session from r3 to 10.0.23.2 is Established.
• ✅ r1 has learned 3.3.3.3/32 via transit, with AS_PATH 65002 65003.
• ✅ r3 has learned 1.1.1.1/32 via transit, with AS_PATH 65002 65001.

Hints

Terse nudges only. This is your proof, so reach for these only when stuck.

• Session won't establish? eBGP remote-as on each side must be the other router's AS. Both ends must be configured.
• Session up but no routes? You forgot network <loopback>/32, or no bgp ebgp-requires-policy is missing on a router (look for (Policy) in the summary).
• r2 is special. It needs two neighbor ... remote-as lines, one toward r1 (65001) and one toward r3 (65003).
• r1 and r3 see nothing from each other? Re-check that r2's both sessions are Established. Transit only works if r2 has learned the route in the first place.

Verify

On r1, confirm the session and the transit route to r3:

On r3, confirm the session and the transit route to r1:

The two transit routes should show an AS_PATH that begins with 65002, proof the prefix crossed AS 65002 to get to you. For a full-mesh sanity check, look at the whole table on each router with show ip bgp and confirm all three loopbacks (1.1.1.1/32, 2.2.2.2/32, 3.3.3.3/32) are present.

Tear down

containerlab destroy -t topology.clab.yml

What you learned

• An eBGP edge router peers with every directly connected neighbor in another AS, and a transit AS in the middle simply runs two eBGP sessions.
• A BGP speaker re-advertises the eBGP routes it learns to its other eBGP neighbors by default, which is exactly what makes transit work, no extra config required.
• Each hop across an AS boundary prepends that AS to the AS_PATH, so r1 sees 65002 65003 for r3's loopback and r3 sees 65002 65001 for r1's: the path records the whole road.
• no bgp ebgp-requires-policy is non-negotiable in these fundamentals labs: without it, RFC 8212 silently filters your eBGP routes.

Next: these were all external sessions between different ASes. The iBGP Fundamentals module starts with bgp-why-ibgp, where you'll see what changes when two routers share the same AS.