Goldfish Networks wordmark
IntermediatePublished 2026-07-03

Lab 3: iBGP over Loopbacks with OSPF Reachability

Bundle lab

Build an internal BGP (iBGP) peering between two IOS routers in the same AS over stable Loopback0 addresses, with OSPF providing loopback reachability. Each router originates a /24 from Loopback1 into BGP, and next-hop/peering behavior is validated from end hosts. This lab emphasizes the deterministic neighbor configuration (remote-as, update-source Loopback0, router-id) and exact-match network origination, supported by a minimal, secure OSPF core.

Track
Est. time
55 minutes
Difficulty
Intermediate
Topics

Learning objectives

  • Configure OSPF area 0 to provide stable reachability to iBGP peering loopbacks with proper router-ids and passive-interface hygiene.
  • Establish an iBGP session in AS 65001 over Loopback0 with neighbor update-source Loopback0 and matching remote-as on both ends.
  • Originate exact /24 networks from Loopback1 using the network ... mask command and validate advertisement reception on the peer.
  • Explain why update-source Loopback0 is mandatory for iBGP peering over loopbacks and how reachability underpins BGP TCP formation.
  • Verify and troubleshoot iBGP and OSPF control-plane formation using show commands, and validate data-plane reachability from end hosts.

Troubleshooting focus

  • If the iBGP neighbor stays Idle/Active, verify IP reachability to the remote Loopback0 (OSPF learning the /32) and ensure both sides use update-source Loopback0.
  • If the iBGP session forms but the /24s do not appear in the BGP table, confirm the exact network ... mask statement matches the installed route for the loopback /24.
  • If host-to-remote loopback pings fail, check that OSPF carries the local user LAN as passive so the remote router has a return path.
  • If OSPF adjacency does not form, validate area 0 on both sides, the correct wildcard mask for the /30 transit, and that the transit interface is not passive.
  • If paths appear but next-hop is unreachable, ensure the peer statements are iBGP (same AS) and consider next-hop-self where appropriate.

Topology

Subscribe to preview this lab's topology.

See plans

Related labs

More hands-on Cisco Modeling Labs practice on the same track and topics.

Grade your work

How this lab is graded
  • Build it your way. Where a lab lets you choose a value — a VLAN name, an interface description — grading checks that you configured it, not which name you picked. Names that another line has to reference, like an ACL applied with access-class, are stated in the guide and do have to match.
  • Addresses, modes and protocol keywords are exact. An IP address, a subnet mask, switchport mode trunk, an encapsulation — these carry the meaning of the lab, so they are graded as written in the guide.
  • Grading reads your saved configuration. Export the lab from CML after you have configured it, and make sure anything you set is in the running-config — a change that only exists in a terminal session never reaches the grader.
  • You can submit as many times as you like. Your best score stands, and each attempt tells you which checks passed so you can work the gaps.
  • Scored something you believe is correct? Use Report an issue on this page — that is exactly how the grading fixes in the changelog got found.

Create a free account to submit your lab for grading.

Create a free account
Found a problem with this lab?

Please sign in to report a problem — tying it to your attempts lets us reproduce and fix it faster.