If iBGP Peers Use Loopbacks, What Must Be Reachable Before BGP Can Come Up?

Published: September 25, 2026 | Last Technically Reviewed: September 25, 2026

Quick Summary

When two iBGP peers use loopback addresses, those loopbacks must already be reachable through the IP routing and forwarding path before the BGP TCP session can form. OSPF is one common way to provide that reachability, but it is not mandatory. IS-IS, static routes, or another suitable underlay can do the same job. Loopbacks are useful because they provide stable logical BGP endpoints that are not tied to one physical interface; if multiple routed paths exist underneath, a physical-link failure does not necessarily require the BGP session itself to fail. However, an Established BGP session proves control-plane connectivity between the peers-not that every advertised service prefix or application path is healthy.

A recent public r/networking discussion started with a simple question: should an iBGP neighbor use a physical interface IP or a loopback address? After several participants explained the stability advantage of loopback-based peering, the original poster immediately asked the more important follow-up: "does that mean before bgp peering, i need to advertising the loopback ip with another igp protocol like OSPF?" Another participant then asked whether the same idea applies to OSPF and EIGRP. The thread therefore exposes the full dependency question rather than stopping at "use loopbacks."

Read the original Reddit discussion - "ibgp loopback?"

This is a public community discussion, not a Network-Switch.com customer case. The community source establishes the real question chain. Protocol behavior below is grounded in RFCs and current Cisco documentation; the layered troubleshooting framework is editorial engineering analysis.

Quick Answer: iBGP does not need OSPF specifically. It needs a usable route to the neighbor address. If the configured neighbor is the remote loopback, that loopback must already be reachable before BGP can establish its TCP session. RFC 4271 defines BGP as operating over TCP, with BGP connection attempts using TCP port 179.

RFC 4271 - Border Gateway Protocol 4 (BGP-4)

The second principle is equally important:

A route to the peer loopback proves control-plane reachability to that endpoint. It does not prove that downstream forwarding or the application is healthy.

Why iBGP Often Uses Loopbacks Instead of Physical Interface Addresses

Consider two routers with two routed paths between them:

Router A
Loopback0: 10.0.0.1/32
     
      Link A 
                      
      Link B 
                       
                    Router B
              Loopback0: 10.0.0.2/32

If Router A peers to the IP address of Router B's Link A interface, the BGP session is closely coupled to the reachability of that interface address.

If both peers instead use loopbacks:

10.0.0.1/32
      ↕
 Underlay Routing
      ↕
10.0.0.2/32

the BGP session endpoint is no longer identified by one particular transit link.

Cisco's BGP documentation explicitly states that neighbor update-source can source the TCP connection from an operational interface, including a loopback. Cisco also describes loopback peering as useful where multiple paths exist because loss of one physical interface does not necessarily bring down the BGP session.

Cisco - Configure iBGP and eBGP With or Without a Loopback Address

The important correction is:

The loopback does not create redundancy.

The actual design is:

stable loopback endpoint + multiple usable underlay paths

If the routers have only one physical path between them, using loopbacks does not manufacture a second path.

Physical Interface IP vs Loopback iBGP Peering

The defensible conclusion is not:

iBGP must always use loopbacks.

It is:

Loopbacks are often preferable when the BGP session should remain anchored to a stable logical endpoint while the underlay is free to change paths.

What Must Exist Before the BGP Session Can Form?

Before BGP can exchange OPEN, KEEPALIVE, or UPDATE messages, the two session addresses need IP reachability.

If Router A is configured with:

neighbor 10.0.0.2 remote-as 65000

Router A first needs to know:

How do I forward an IP packet to 10.0.0.2?

And Router B needs the reverse path to Router A's selected source address.

The dependency stack is:

Physical Links
      
Underlay Reachability
      
Remote Loopback Route
      
TCP Session
      
BGP Session
      
BGP Routes
      
Forwarding
      
Application Traffic

Each layer can fail independently.

RFC 4271 describes BGP's TCP-based connection process, while Cisco's own iBGP-over-loopback example demonstrates the practical dependency: the documented configuration includes both neighbor ... update-source Loopback0 and a static route that makes the remote loopback reachable.

Verified Cisco IOS Example

Cisco's documented iBGP example includes the following logic:

interface Loopback0
 ip address 10.1.1.1 255.255.255.255

router bgp 300
 neighbor 10.2.2.2 remote-as 300
 neighbor 10.2.2.2 update-source Loopback0

ip route 10.2.2.2 255.255.255.255 10.10.10.2

The two important prerequisites are obvious:

1. the remote loopback is reachable;
2. the TCP connection is sourced from the local loopback.

Cisco explicitly describes the static route as ensuring that the remote peer address used for peering is reachable.

Cisco - Verified iBGP Loopback Configuration Example

Do not confuse this with ebgp-multihop. Cisco's same document shows that command in the eBGP loopback example because the peer is not directly connected from an eBGP perspective. That is a related reachability issue, but it is not an automatic requirement for the iBGP case discussed here.

How Can the Remote Loopback Become Reachable?

The key point is:

BGP cannot first establish a session and then teach itself how to reach the address required to establish that same session.

Some other routing information must already make that endpoint reachable.

Do You Need OSPF Before iBGP?

No. Reachability is mandatory. OSPF is not.

That distinction directly answers the original Reddit follow-up. The thread itself includes replies saying OSPF can carry the loopbacks, while static routes may be enough in a small topology.

A two-router lab may only need:

Static route to remote loopback

A larger routed network may benefit from:

OSPF / IS-IS
        
Infrastructure loopback reachability

BGP does not care which valid mechanism placed the usable route in the forwarding topology. It cares that the configured neighbor IP is reachable.

Does the Same Logic Apply to OSPF or EIGRP?

Only partly.

The idea of using stable loopback addresses is widely useful.

The neighbor-formation mechanics are protocol-specific.

OSPF normally forms adjacencies on OSPF-enabled network interfaces. RFC 2328 describes OSPF Hello packets being sent on network interfaces to discover and maintain neighboring routers; on point-to-point physical networks, Hellos are sent on that link.

RFC 2328 - OSPF Version 2

A loopback is commonly useful in OSPF as:

• a stable router ID source;
• an infrastructure prefix;
• a management/control-plane address.

But ordinary OSPF operation is not simply:

configure the remote router's arbitrary loopback as a BGP-style neighbor endpoint.

EIGRP also has its own neighbor-discovery model. RFC 7868 describes EIGRP neighbor discovery and HELLO packets as part of normal protocol operation, so it should not be mechanically described as "BGP loopback peering but with EIGRP."

RFC 7868 - Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)

Cisco - Introduction to EIGRP

The useful generalization is:

Stable loopback addressing is a broadly useful routing design principle, but adjacency formation must be understood protocol by protocol.

Why This Is Not a Circular Routing Dependency

At first glance, the design can look circular:

OSPF / IS-IS
      
Reach BGP loopback
      
iBGP comes up
      
BGP installs routes

It is reasonable to ask:

Aren't we using routing to build routing?

Yes-but the two routing systems can serve different scopes.

In many architectures, the IGP carries infrastructure reachability, such as:

• router loopbacks;
• point-to-point transport prefixes;
• internal routed paths.

BGP then carries another set of information, such as:

• Internet routes;
• service prefixes;
• policy-rich routes;
• VPN routes;
• overlay reachability.

That is dependency by design, not necessarily circular dependency.

A better model is:

UNDERLAY / INFRASTRUCTURE

How do I reach the BGP speaker itself?
        
OSPF / IS-IS / Static / Other

                

BGP CONTROL PLANE

What routes and policies should the
BGP speakers exchange once connected?

The underlay does not need BGP to discover the peer's loopback if it already has an independent route.

BGP then uses that transport reachability to establish its TCP session and exchange its own route information.

This should not be over-generalized into:

OSPF is always the underlay and BGP is always the overlay.

That terminology does not accurately describe every network.

A safer statement is:

In many designs, an IGP carries infrastructure reachability while BGP carries a different route scope or policy domain. That is intentional layering, not logical circularity.

What Happens When a Physical Link Fails?

This is where the loopback design can provide operational value.

Consider two paths:

           Link A
Router 1 ---------- Router 2
    \                  /
     \---- Link B ----/

The BGP session is:

R1 Lo0  <------ iBGP ------>  R2 Lo0

Initially, the underlay may route the peer loopbacks over Link A.

If Link A fails:

Link A fails
      
Underlay detects failure
      
Underlay reconverges
      
Peer loopback reachable through Link B
      
Existing TCP/BGP session may survive

Cisco explicitly identifies this kind of multiple-path stability as a reason loopback-sourced BGP can be useful.

But the precise wording matters:

The BGP session can remain established if alternate reachability is preserved or restored before the TCP/BGP session fails.

It is not guaranteed.

Whether it survives depends on:

• failure-detection time;
• IGP convergence time;
• duration of packet loss;
• TCP behavior;
• BGP timers;
• topology;
• the exact failure.

RFC 4271 defines BGP's HoldTimer and KEEPALIVE behavior, including negotiation and timer expiration as part of session state.

RFC 4271 - BGP HoldTimer and State Machine

This is one reason fast underlay convergence matters: if the underlay restores connectivity quickly enough, BGP may never need to tear down and rebuild the session.

But there is a second problem:

The BGP session can remain healthy while real traffic is already broken.

When the BGP Session Is Up but the Network Is Still Broken

Imagine:

Peer Loopback Reachability = GOOD
TCP                       = GOOD
BGP                       = ESTABLISHED
BGP Route                 = PRESENT

But...

Service Prefix
      
Wrong / unresolved next hop
      
Failed downstream path
      
BLACKHOLE

A BGP peer only proves that its own control-plane conversation is functioning.

It does not prove that:

• every next hop resolves correctly;
• every FIB entry forwards correctly;
• every downstream link is healthy;
• ACLs permit service traffic;
• routing is symmetric;
• the application is alive.

Reachability vs Health

The troubleshooting framework should therefore be:

Physical
   
Underlay
   
Peer Loopback
   
TCP
   
BGP
   
Route
   
Forwarding
   
Service

Do not collapse these into one health state.

What Does BFD Add?

RFC 5880 defines Bidirectional Forwarding Detection as a mechanism for detecting faults in the bidirectional path between forwarding engines, with the goal of providing rapid failure detection.

RFC 5880 - Bidirectional Forwarding Detection (BFD)

Cisco's current IOS XE BGP/BFD documentation says BFD provides fast forwarding-path failure detection and highlights faster BGP reconvergence as its primary benefit.

Cisco IOS XE - BGP Support for BFD

That gives us a cleaner separation:

BGP Hold / Keepalive
 BGP session liveness

IGP Hello / Dead mechanisms
 IGP adjacency liveness

BFD
 Fast monitored forwarding-path failure detection

Application Monitoring
 Does the service itself actually work?

BFD is not a general application-health monitor.

It also does not prove every downstream service path is healthy just because a BFD session remains up.

Troubleshooting Ladder: If iBGP Over Loopbacks Does Not Come Up

A successful ping to the loopback does not mean BGP must come up.

It proves only part of the dependency chain.

For production routed designs, the protocol design should also be checked against the exact hardware platform, forwarding capabilities, and software release rather than assuming that the presence of "BGP" or "BFD" in a feature list proves the intended failure behavior. Network-Switch's engineering workflow can be used for that platform/BOM validation step:

Network-Switch Engineering & BOM Review

The final diagnostic model is:

1. Physical connectivity exists
2. Peer loopback is reachable
3. TCP/BGP session forms
4. Expected routes are installed
5. Data plane forwards correctly
6. Service actually works

Those are different states.

A healthy BGP session is evidence of control-plane reachability-not proof of end-to-end service health.

For more L3 and routing engineering notes:

Network-Switch Engineer Lab

Source and Evidence Boundary

Community Evidence
The r/networking thread "ibgp loopback?" establishes the real user journey: physical IP vs loopback, followed by the question of whether OSPF must make the loopback reachable first, and then whether similar logic applies to OSPF/EIGRP. Community replies are evidence of the problem and practitioner discussion, not authoritative protocol definitions.

Reddit - ibgp loopback?

Standards / Primary Technical Sources
RFC 4271 establishes BGP's TCP/session mechanics and timers. RFC 2328 establishes OSPF Hello/neighbor behavior. RFC 5880 defines BFD's forwarding-path failure-detection purpose. RFC 7868 documents EIGRP protocol behavior.

Vendor-Specific Evidence
Cisco documents loopback-sourced BGP with neighbor ... update-source, the requirement for independent peer reachability in its example, and BGP integration with BFD.

Engineering Analysis
The dependency stack, Reachability vs Health table, and troubleshooting ladder are editorial engineering frameworks derived from the documented protocol behavior. They are not presented as quotations or official Cisco/IETF troubleshooting procedures.

First-Party Lab Evidence
None is claimed in this article. Network-Switch has not presented this specific iBGP scenario here as a first-party lab reproduction. If a future lab test is added, its topology, software versions, configurations, CLI outputs, failure procedure, observed timings, and limitations should be published separately.

Official External Sources

Community

Reddit - ibgp loopback?

IETF / RFC

RFC 4271 - A Border Gateway Protocol 4 (BGP-4)

RFC 5880 - Bidirectional Forwarding Detection (BFD)

RFC 2328 - OSPF Version 2

RFC 7868 - Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)

Cisco

Cisco - Configure iBGP and eBGP With or Without a Loopback Address

Cisco IOS XE - BGP Support for BFD

Cisco - Introduction to EIGRP