Course contents

Module 2: Configuring BGPLesson 2.2 (2 of 6 in this module)5 of 43 in the BGP course

Configuring iBGP with loopbacks

R1 learns a provider route, but how does the company's second router learn it? Let's carry that route inside the same AS without copying the provider's table into OSPF.

Advanced · 14 min read

You'll learn to build an iBGP session between reachable loopbacks, explain update-source and next-hop-self, and verify a provider route from R2.

What is missing on R2?

Continue from the eBGP lab, where R1 in company AS 64500 learns 203.0.113.0/24 from ISP A in AS 64501. R2 is another router in the same company AS. We want R2 to learn that destination through R1. Because their AS numbers match, their session is internal BGP (iBGP).

We need two separate kinds of information. First, R1 and R2 need IP routes to each other's session addresses. Then iBGP can exchange external prefixes. We use OSPF, an internal routing protocol, for the first job and BGP for the second. Learning the provider prefix in iBGP does not create the routes required to establish that same session.

PurposeR1R2
Internal physical link, /30Gi0/1: 10.0.12.1Gi0/1: 10.0.12.2
Session endpoint, /32Loopback0: 10.255.0.1Loopback0: 10.255.0.2
BGP local AS6450064500
BGP router ID1.1.1.12.2.2.2

A loopback is a software interface. The /32 represents one IPv4 address, using mask 255.255.255.255. A router ID is a BGP identifier; it is not the session address here. R1's existing provider link remains Gi0/0 192.0.2.2/30 to ISP A 192.0.2.1. We do not add that provider link to OSPF.

Gi0/1 .1.2 Gi0/110.0.12.0/30R1 · AS 64500Loopback0: 10.255.0.1/32R2 · AS 64500Loopback0: 10.255.0.2/32

Device key: R1 · AS 64500, R2 · AS 64500 (router)

Lines show the example’s network connections. The coloured path and envelope follow the current step; its text identifies the sender, receiver and traffic type.

Reading the addresses

IP labels identify interfaces or destinations. Subnet labels identify networks; /n is the prefix length. A router ID (RID) identifies a routing process and need not be a reachable interface.

An IP address alone is not a URL. A web URL includes a scheme such as https://; an address on a router or printer does not imply a website.

  • R1 · AS 64500: Loopback0: 10.255.0.1/32
  • R2 · AS 64500: Loopback0: 10.255.0.2/32
  1. 1. Learn the remote loopback Each router learns the other loopback /32 over the internal Ethernet link.
  2. 2. Build the loopback session The BGP TCP endpoints are 10.255.0.1 and 10.255.0.2, not the Gi0/1 addresses.
  3. 3. Advertise a reachable next hop R1 sends the provider prefix with next-hop-self so R2 can forward towards R1.
The cable carries both internal routing and the iBGP conversation. The logical session uses loopback addresses reached across that cable.

Give IP routing the first job

iBGP on loopbacks, carried by an IGP
iBGP on loopbacks, carried by an IGPR1 and R2 in AS 64500 are joined by two physical links. An IGP, OSPF in this example, advertises their loopbacks 10.0.0.1 and 10.0.0.2. The iBGP session is a TCP connection between the loopbacks and rides on whichever physical link the IGP chooses, so it survives the loss of one link.AS 64500R1Lo0 10.0.0.1R2Lo0 10.0.0.2link Alink BiBGP session, loopback to loopbackIGP: advertises both loopbacksBGP: update-source Loopback0

On small screens, swipe sideways or focus the diagram and use the arrow keys.

The IGP supplies reachability to the loopbacks and BGP supplies the internet routes. If the IGP cannot reach the peer loopback, the session never forms, whatever the BGP configuration says.

The following Cisco IOS XE 17.x-style commands start in global configuration mode. R1 retains its earlier eBGP configuration. R2 has no existing BGP or OSPF configuration in this lab. OSPF process 1 selects only the internal link and loopback; passive-interface stops Hellos on the loopback while still advertising its selected address.

The IGP carries the loopbacks
The IGP carries the loopbacksiBGP sessions use loopbacks, so an IGP must reach them first.IGP or staticreaches both loopbacksPingloopback to loopbackiBGP sessioncomes up

On small screens, swipe sideways or focus the diagram and use the arrow keys.

BGP does not find its own neighbours. The IGP, or static routes, carry the loopback addresses.
router ospf 1 router-id 1.1.1.1 passive-interface default no passive-interface GigabitEthernet0/1 exit interface GigabitEthernet0/1 ip address 10.0.12.1 255.255.255.252 ip ospf network point-to-point ip ospf 1 area 0 no shutdown interface Loopback0 ip address 10.255.0.1 255.255.255.255 ip ospf 1 area 0

R1: set the OSPF router ID and passive policy before selecting interfaces. Advertise the loopback over the internal link; the ISP-facing Gi0/0 remains outside OSPF.

router ospf 1 router-id 2.2.2.2 passive-interface default no passive-interface GigabitEthernet0/1 exit interface GigabitEthernet0/1 ip address 10.0.12.2 255.255.255.252 ip ospf network point-to-point ip ospf 1 area 0 no shutdown interface Loopback0 ip address 10.255.0.2 255.255.255.255 ip ospf 1 area 0

R2: set its router ID before selecting interfaces, then use the matching area and network type with its own addresses.

In privileged EXEC mode on R1, run show ip ospf neighbor, show ip route 10.255.0.2 and ping 10.255.0.2 source Loopback0. Expect a Full neighbour, a /32 route and replies. Repeat the source-loopback ping on R2 towards 10.255.0.1. Testing from the loopback matters because that will be the TCP source.

Prove loopback-to-loopback IP reachability before adding the iBGP neighbour. A ping from Gi0/1 alone does not check the return route to Loopback0.

Choose the session source on both routers

neighbor ... remote-as 64500 selects an iBGP peer because it matches the local AS. update-source Loopback0 tells BGP to use the local loopback IP as its TCP source. Without it, a connection might use the outgoing physical interface address. The other router is expecting the configured loopback neighbour, so that mismatch can prevent the intended session.

Session source choice
Session source choiceWithout update-source the session uses the exit interface address. With it, the session uses the loopback.Default sourceAddress of the exitinterfacePeer sees an address itdoes not expectupdate-source Loopback0Packets leave with theloopback addressMatches the neighbourcommand on the peervs

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Both routers must agree on which addresses they peer with.
router bgp 64500 neighbor 10.255.0.2 remote-as 64500 neighbor 10.255.0.2 update-source Loopback0 address-family ipv4 unicast neighbor 10.255.0.2 activate neighbor 10.255.0.2 next-hop-self exit-address-family

R1: add R2 without replacing the existing provider neighbour. next-hop-self makes R1 the next hop for provider routes it sends to R2.

router bgp 64500 bgp router-id 2.2.2.2 no bgp default ipv4-unicast neighbor 10.255.0.1 remote-as 64500 neighbor 10.255.0.1 update-source Loopback0 address-family ipv4 unicast neighbor 10.255.0.1 activate neighbor 10.255.0.1 next-hop-self exit-address-family

R2: configure the matching loopback peer. The reciprocal next-hop-self is useful when R2 later gains its own external routes; it does not originate a route by itself.

Next-hop-self changes the next-hop attribute of eligible routes sent to that peer. R1's external prefix originally had ISP A's next hop, 192.0.2.1. Ordinary iBGP would preserve it, but R2 has no route to that provider link in this design. With next-hop-self, R1 advertises 10.255.0.1, which R2 already reaches through OSPF.

Read the provider route on R2

Example output
R2#show ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 *>i 198.51.100.0      10.255.0.1               0    100      0 i
 *>i 203.0.113.0       10.255.0.1               0    100      0 64501 i
Both paths came from R1 over iBGP, shown by the i in the left status field. R1 originated the company prefix, so its AS path is empty inside its own AS. The provider prefix still has AS path 64501: iBGP did not prepend 64500. The final i is the separate origin code.

Run show ip route 203.0.113.1 on R2. With no competing source, the /24 is installed as an iBGP route with Cisco distance 200 and next hop 10.255.0.1. The router then looks up how to reach that next hop, finding the OSPF route across Gi0/1. This extra lookup is called recursive next-hop resolution.

Reading the iBGP route on R2
Reading the iBGP route on R2The status code, the next hop and the path show why a route is or is not used.Status code >Best path selected for this prefixNext hop 192.0.2.1Must be reachable, or the route is unusablePath 64501AS path is unchanged inside the AS

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Check the next hop first: an unreachable next hop explains most silent iBGP failures.

The company prefix may already be connected on R2 if you built the shared course LAN at Gi0/2 198.51.100.3/24. In that case the connected route wins over the iBGP copy for the same /24. That is expected. In the minimal lab here, R2 has only Gi0/1 and Loopback0 configured, so it can install both learned prefixes.

Test one mistake at a time

  1. On R2, check show ip bgp summary. Expect the loopback neighbour in AS 64500 with a numeric prefix count. Confirm its source with show ip bgp neighbors 10.255.0.1.
  2. On R1, under the IPv4 address family, remove neighbor 10.255.0.2 next-hop-self using its no form. After the new advertisement is processed, R2's provider path has next hop 192.0.2.1 and is unusable if no route reaches that IP. The iBGP session itself stays up.
  3. Restore next-hop-self and check the next hop returns to 10.255.0.1. If the policy change has not refreshed the route on your release, use a negotiated soft outbound refresh on R1 rather than a hard session clear: clear ip bgp 10.255.0.2 soft out.

The practical trade-off is extra preparation: loopback sessions need internal routing and matching source configuration. They become valuable when the network has several possible physical paths. As the number of iBGP routers grows, ordinary iBGP also needs a full mesh of sessions or a deliberate route-reflector design.

Technical references: Cisco IOS XE basic BGP configuration, Cisco loopback peering examples and RFC 4271. These are documentation-based teaching configurations, not a physical-router validation result.

Check your iBGP reasoning

Predict · scenario 1

R1's neighbour address is R2 Loopback0, but R1 initiates TCP from Gi0/1. Which setting selects the intended local endpoint?

Predict · scenario 2

The iBGP session is Established, but a provider path has unreachable next hop 192.0.2.1. What fits this design?

Predict · scenario 3

The only physical R1–R2 link fails. Do loopbacks keep the iBGP session alive?

FAQ

Can iBGP use physical interface addresses instead?
Yes. iBGP does not require loopbacks. Loopbacks give stable endpoints that can remain reachable through another routed path when a physical link fails. That benefit needs an actual alternative path; this single-link lab has none.
Does update-source fix an unreachable next hop?
No. update-source chooses the local IP used for the BGP TCP session. next-hop-self changes the forwarding next hop in eligible advertisements to that peer. The IP routing table must still know how to reach both the session endpoint and the advertised next hop.
Does OSPF need every external BGP prefix?
Not in this design. OSPF carries internal links and loopback reachability. iBGP carries the provider prefix and its BGP attributes. The router resolves the BGP next hop through the internal route.