Ping Labz

How to Configure iBGP Neighbors and Full Mesh

iBGP has rules eBGP does not: split-horizon, full-mesh, and next-hop preservation. Ignore any of them and routes vanish silently from your network. A practical guide to configuring iBGP neighbors and full mesh.

How to Configure iBGP Neighbors and Full Mesh - PingLabz BGP article title card

Once your border routers have eBGP sessions with external peers, you need a way to distribute those learned routes to other BGP speakers inside your AS. That's iBGP's job. But iBGP comes with rules that don't exist in eBGP - the split-horizon restriction, the full mesh requirement, and the next-hop preservation behavior - and ignoring any of them means routes silently disappear from your network.

(This article is part of the PingLabz BGP series - the full BGP guide maps the whole cluster in reading order.)

Lab Topology Reminder

  • R1-HQ: AS 65001, Lo0: 1.1.1.1 - border router: Et0/1 172.16.0.1/30 to ISP-A-PE1 (AS 65010, 172.16.0.2), Et0/2 172.16.0.5/30 to ISP-B-PE1 (AS 65020, 172.16.0.6), Et0/3 10.0.0.1/30 to R2-HQ
  • R2-HQ: AS 65001, Lo0: 2.2.2.2 - internal router: Et0/1 10.0.0.2/30 to R1-HQ, Et0/2 10.0.0.5/30 to R3-BRANCH
  • R3-BRANCH: AS 65002, Lo0: 3.3.3.3 - branch router and eBGP peer of R2-HQ (not part of the iBGP mesh): Et0/1 10.0.0.6/30 to R2-HQ, originates 10.3.0.0/16
  • OSPF runs between R1-HQ and R2-HQ as the IGP, carrying loopback addresses; the ISP and branch /30s are not in OSPF

I re-ran this lab, built in my home lab, on Cisco IOL 17.18.2 in Containerlab, so the interfaces are Ethernet0/x rather than GigabitEthernet. R1-HQ and R2-HQ share the 10.0.0.0/30 link, and OSPF area 0 carries both loopbacks across it. R3-BRANCH hangs off R2-HQ Et0/2 on 10.0.0.4/30 and peers with R2-HQ over eBGP. Every output below comes from that five-router lab: R1-HQ, R2-HQ, R3-BRANCH and the two ISP PEs.

Topology diagram: R1-HQ (Lo0 1.1.1.1) peers over eBGP with ISP-A-PE1 (AS 65010) at 172.16.0.2 and ISP-B-PE1 (AS 65020) at 172.16.0.6, and over iBGP with R2-HQ (Lo0 2.2.2.2) between loopbacks across the 10.0.0.0/30 OSPF link; R2-HQ Et0/2 10.0.0.5 peers over eBGP with R3-BRANCH (AS 65002, Lo0 3.3.3.3) at 10.0.0.6, which originates 10.3.0.0/16 and sits outside the iBGP mesh, and R2-HQ sees every ISP /18 via next hop 1.1.1.1.
iBGP topology - R1-HQ and R2-HQ peer within AS 65001 using loopback addresses (OSPF provides reachability)

Why Loopback-Based Peering

iBGP sessions should always peer between loopback addresses rather than physical interfaces. The reason: if R1-HQ and R2-HQ have two physical links between them and one fails, a physical-interface-based iBGP session on that link dies. A loopback-based session survives because the loopback is reachable via the remaining link (as long as the IGP has an alternate path).

This requires two things: the loopbacks must be in the IGP (OSPF in our lab), and the BGP session must be sourced from the loopback.

Configuration

On R1-HQ:

R1-HQ(config)# router bgp 65001
R1-HQ(config-router)# neighbor 2.2.2.2 remote-as 65001
R1-HQ(config-router)# neighbor 2.2.2.2 update-source Loopback0
R1-HQ(config-router)# neighbor 2.2.2.2 next-hop-self
R1-HQ(config-router)# neighbor 2.2.2.2 description R2-HQ-iBGP

On R2-HQ:

R2-HQ(config)# router bgp 65001
R2-HQ(config-router)# neighbor 1.1.1.1 remote-as 65001
R2-HQ(config-router)# neighbor 1.1.1.1 update-source Loopback0
R2-HQ(config-router)# neighbor 1.1.1.1 next-hop-self
R2-HQ(config-router)# neighbor 1.1.1.1 description R1-HQ-iBGP

R2-HQ also runs the eBGP session to R3-BRANCH, and R3-BRANCH originates the branch prefix:

R2-HQ(config-router)# neighbor 10.0.0.6 remote-as 65002
R2-HQ(config-router)# neighbor 10.0.0.6 description R3-BRANCH

R3-BRANCH(config)# ip route 10.3.0.0 255.255.0.0 Null0
R3-BRANCH(config)# router bgp 65002
R3-BRANCH(config-router)# network 10.3.0.0 mask 255.255.0.0
R3-BRANCH(config-router)# neighbor 10.0.0.5 remote-as 65001
R3-BRANCH(config-router)# neighbor 10.0.0.5 description R2-HQ

Breaking this down:

  • remote-as 65001 - same AS on both sides, so this is iBGP.
  • update-source Loopback0 - source the TCP session from the loopback. Without this, BGP uses the outgoing physical interface IP, which won't match the neighbor address configured on the remote side.
  • next-hop-self - changes the BGP next-hop to the local loopback when advertising to this iBGP peer. Without it, routes learned from eBGP peers retain the original external next-hop (e.g., 172.16.0.2), which R2-HQ can't reach directly. See BGP Next-Hop-Self for a deep dive.

The Full Mesh Requirement

Because of the iBGP split-horizon rule (routes from one iBGP peer are NOT re-advertised to another iBGP peer), every iBGP speaker must peer with every other iBGP speaker. In a network with n BGP routers, you need n×(n-1)/2 iBGP sessions:

2
1
5
10
10
45
20
190
50
1,225

At small scale (under 10 routers), full mesh is manageable. Beyond that, use route reflectors (covered next) or confederations (BGP Confederations).

Peer Groups (Template Optimization)

When you have multiple iBGP peers with the same configuration (same update-source, same next-hop-self, same route-maps), peer groups reduce repetition and improve update efficiency:

R1-HQ(config-router)# neighbor IBGP-PEERS peer-group
R1-HQ(config-router)# neighbor IBGP-PEERS remote-as 65001
R1-HQ(config-router)# neighbor IBGP-PEERS update-source Loopback0
R1-HQ(config-router)# neighbor IBGP-PEERS next-hop-self
!
R1-HQ(config-router)# neighbor 2.2.2.2 peer-group IBGP-PEERS
R1-HQ(config-router)# neighbor 2.2.2.2 description R2-HQ

On modern IOS XE, peer templates (template peer-policy and template peer-session) offer more flexibility than peer groups, but peer groups are simpler and still widely used.

Get the BGP Field Reference - 9 pages, free

Everything you'd want to remember about BGP on nine printable pages. FSM diagram, all 13 best-path steps with gotchas, troubleshooting decision tree, copy-paste IOS XE templates, and real lab captures. Free for PingLabz members - just sign up with your email.

Get the BGP cheat-sheet

Verification

R1-HQ# show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 65001
BGP table version is 8, main routing table version 8
7 network entries using 1736 bytes of memory
7 path entries using 952 bytes of memory
5/5 BGP path/bestpath attribute entries using 1520 bytes of memory
3 BGP AS-PATH entries using 72 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 4280 total bytes of memory
BGP activity 7/0 prefixes, 7/0 paths, scan interval 60 secs
7 networks peaked at 19:30:53 Oct 20 2026 UTC (00:06:00.519 ago)

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2.2.2.2         4        65001      12      13        8    0    0 00:06:25        2
172.16.0.2      4        65010      12      14        8    0    0 00:07:12        2
172.16.0.6      4        65020      11      15        8    0    0 00:07:13        2

R2-HQ (2.2.2.2) shows as AS 65001, confirming it's an iBGP peer. Its PfxRcd of 2 is R2-HQ's own 10.2.0.0/16 plus R3-BRANCH's 10.3.0.0/16, which R2-HQ passes on over iBGP. Each ISP sends 2.

R1-HQ# show ip bgp neighbors 2.2.2.2 | include BGP state|Local host|Foreign host
  BGP state = Established, up for 00:06:25
Local host: 1.1.1.1, Local port: 179
Foreign host: 2.2.2.2, Foreign port: 46096

The local host is 1.1.1.1 (Loopback0) and the foreign host is 2.2.2.2, so update-source is working on both ends. R2-HQ opened this TCP session, which is why R1-HQ shows the well-known port 179.

R2-HQ# show ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 *>i  10.1.0.0/16      1.1.1.1                  0    100      0 i
 *>   10.2.0.0/16      0.0.0.0                  0         32768 i
 *>   10.3.0.0/16      10.0.0.6                 0             0 65002 i
 *>i  100.64.0.0/18    1.1.1.1                  0    100      0 65010 i
 *>i  100.64.64.0/18   1.1.1.1                  0    100      0 65010 i
 *>i  100.64.128.0/18  1.1.1.1                  0    100      0 65020 i
 *>i  100.64.192.0/18  1.1.1.1                  0    100      0 65020 i

The i before the > marks iBGP-learned routes, and their next hop is 1.1.1.1 (R1-HQ's loopback) thanks to next-hop-self. 10.3.0.0/16 has no i because R2-HQ learned it from R3-BRANCH over eBGP. R3-BRANCH sits outside the iBGP mesh and receives everything R2-HQ uses, including the routes R2-HQ learned from R1-HQ over iBGP. The iBGP split-horizon rule only blocks iBGP-to-iBGP re-advertisement:

R3-BRANCH# show ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 *>   10.1.0.0/16      10.0.0.5                               0 65001 i
 *>   10.2.0.0/16      10.0.0.5                 0             0 65001 i
 *>   10.3.0.0/16      0.0.0.0                  0         32768 i
 *>   100.64.0.0/18    10.0.0.5                               0 65001 65010 i
 *>   100.64.64.0/18   10.0.0.5                               0 65001 65010 i
 *>   100.64.128.0/18  10.0.0.5                               0 65001 65020 i
 *>   100.64.192.0/18  10.0.0.5                               0 65001 65020 i

To check the alternative, I removed next-hop-self on R1-HQ and soft-reset the session outbound. R2-HQ then kept the external next hops and could not use them:

R2-HQ# show ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 *>i  10.1.0.0/16      1.1.1.1                  0    100      0 i
 *>   10.2.0.0/16      0.0.0.0                  0         32768 i
 *>   10.3.0.0/16      10.0.0.6                 0             0 65002 i
 * i  100.64.0.0/18    172.16.0.2               0    100      0 65010 i
 * i  100.64.64.0/18   172.16.0.2               0    100      0 65010 i
 * i  100.64.128.0/18  172.16.0.6               0    100      0 65020 i
 * i  100.64.192.0/18  172.16.0.6               0    100      0 65020 i

R2-HQ# show ip bgp 100.64.0.0/18
BGP routing table entry for 100.64.0.0/18, version 11
Paths: (1 available, no best path)
  Not advertised to any peer
  Refresh Epoch 1
  65010
    172.16.0.2 (inaccessible) from 1.1.1.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0
      Updated on Oct 20 2026 19:37:28 UTC

R2-HQ# show ip route 172.16.0.2
% Network not in table

The four ISP prefixes lost their > best-path marker, and the detail view marks 172.16.0.2 as inaccessible because R2-HQ has no route to it. With no best path, R2-HQ also stopped advertising them, so R3-BRANCH lost all four ISP prefixes:

R3-BRANCH# show ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 *>   10.1.0.0/16      10.0.0.5                               0 65001 i
 *>   10.2.0.0/16      10.0.0.5                 0             0 65001 i
 *>   10.3.0.0/16      0.0.0.0                  0         32768 i

Putting next-hop-self back on R1-HQ restored 1.1.1.1 as the next hop, the best-path markers and R3-BRANCH's ISP routes. R2-HQ's next-hop-self toward R1-HQ does the same job in the other direction. When I removed it, R1-HQ saw R3-BRANCH's prefix with the branch link address as next hop, which isn't in OSPF:

R1-HQ# show ip bgp 10.3.0.0/16
BGP routing table entry for 10.3.0.0/16, version 9
Paths: (1 available, no best path)
  Not advertised to any peer
  Refresh Epoch 1
  65002
    10.0.0.6 (inaccessible) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0
      Updated on Oct 20 2026 19:38:35 UTC

R1-HQ# show ip route 10.0.0.6
% Subnet not in table

With it restored, R1-HQ resolves 10.3.0.0/16 via 2.2.2.2 (metric 11 through OSPF):

R1-HQ# show ip bgp 10.3.0.0/16
BGP routing table entry for 10.3.0.0/16, version 8
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  65002
    2.2.2.2 (metric 11) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
      Updated on Oct 20 2026 19:30:53 UTC

Troubleshooting

iBGP peer stuck in Active
Cause
Loopback not reachable via IGP, or update-source missing
Fix
Verify ping 2.2.2.2 source 1.1.1.1. Confirm OSPF is advertising both loopbacks. Add update-source Loopback0.
iBGP session up but routes not in routing table
Cause
Next-hop unreachable - external next-hop not reachable by internal router
Fix
Add next-hop-self on the border router advertising to iBGP peers.
iBGP routes have AD 200, losing to OSPF route
Cause
Normal behavior - iBGP AD (200) is higher than OSPF (110)
Fix
This is by design. If you need iBGP to win, either remove the IGP route for that prefix or adjust AD with distance bgp.
Routes from R1-HQ not reaching a third iBGP router that peers only with R2-HQ
Cause
iBGP split-horizon - R2-HQ won't re-advertise iBGP-learned routes to another iBGP peer. An eBGP peer such as R3-BRANCH still receives them.
Fix
Establish direct iBGP peering between R1-HQ and that router, or deploy route reflectors.

Key Takeaways

  • Always peer iBGP sessions between loopback addresses with update-source Loopback0 for resilience.
  • Use next-hop-self on border routers to fix the default iBGP behavior of preserving the external next-hop.
  • Full mesh iBGP scales to roughly 10 routers. Beyond that, use route reflectors or confederations.
  • Peer groups simplify configuration when multiple iBGP peers share the same settings.
  • iBGP routes have AD 200 - they lose to IGP routes by design. Verify next-hop reachability first when iBGP routes aren't being installed.
Share Share Share Share Share Email

Read next