IntermediatePublished 2026-07-03
Lab 3: iBGP over Loopbacks with OSPF Reachability
Bundle lab
Lab 3 of 10 in BGP Fundamentals · ← Previous · Next →
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.
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 plansGrade 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 accountFound a problem with this lab?
Please sign in to report a problem — tying it to your attempts lets us reproduce and fix it faster.