Day 4 — BGP Transport Mechanics: TCP/179, Reachability, Update-Source and eBGP Multihop

Learning objective

Build and troubleshoot a BGP session whose peer addresses are loopbacks, explaining the separate roles of IP reachability, TCP/179, source-address selection, and the eBGP TTL/multihop constraint.

BGP Transport Mechanics

---

1. Opening — BGP can be correct while the transport underneath it is impossible

When show ip bgp summary displays Active, engineers often begin changing BGP commands. That can be the wrong layer.

BGP does not discover neighbors automatically in the classic configuration model. A BGP peer is configured explicitly, and the protocol rides over TCP. Before OPEN messages, capabilities, path attributes or policies can matter, packets must be able to reach the configured peer address and a TCP connection must be established.

That means BGP troubleshooting starts below BGP:

• Is the destination peer address reachable?
• Is the correct local source address being used?
• Can the peer route back to that source?
• Is TCP/179 permitted?
• If eBGP peers are not directly connected, is the TTL/multihop design intentional?
• Is the neighbor configured against the address the remote router actually uses as its source?

Loopback-based peering makes these dependencies visible and is therefore an ideal teaching lab.

---

2. Concept and standards behaviour

2.1 BGP relies on TCP

RFC 4271 specifies BGP operation over TCP. TCP provides reliable, ordered delivery, retransmission and connection state. BGP does not need to reinvent those transport functions.

The well-known BGP server port is TCP 179. During connection establishment, one side may initiate toward destination port 179 while the local ephemeral/source port is chosen by TCP. BGP implementations also contain connection-collision handling because both sides can attempt connections.

2.2 Reachability is bidirectional

For a configured BGP peer to work, the local router must be able to route packets to the peer address, and the remote router must be able to return traffic to the local source address.

A one-way static route can therefore create deceptive symptoms: the forward ping may fail, TCP may partially progress, or packets may arrive at the remote device with a source address that has no return route.

2.3 Direct-interface peering versus loopback peering

Direct eBGP commonly peers using the addresses on the shared point-to-point link. This is simple because each peer is directly connected.

Loopback peering is useful when the operator wants the BGP session identity to be independent of one physical link. The loopback remains logically up while individual transport paths can change, provided the underlay still routes to it.

But loopback peering introduces two explicit requirements:

1. The BGP process must source the TCP connection from the intended loopback address.
2. The network must route to the remote loopback address.

On Cisco IOS XE, neighbor <address> update-source <interface> selects the source interface/address for the BGP session.

2.4 Why eBGP multihop appears

Classic directly connected eBGP assumes a very small hop distance between external peers. When the configured eBGP neighbor address is a loopback or otherwise not directly connected, the operator must intentionally permit the greater hop distance.

On Cisco IOS XE, this is commonly done with:

neighbor <peer> ebgp-multihop <ttl>

The exact TTL should be chosen deliberately. Configuring an unnecessarily large value increases the set of possible source distances and weakens the natural adjacency constraint. Later security coverage will compare eBGP multihop with TTL Security/GTSM.

2.5 update-source and ebgp-multihop solve different problems

This distinction is crucial:

• update-source controls the local source address/interface used for the BGP TCP session.
• ebgp-multihop permits eBGP establishment across more than the directly connected hop model.
• routing/static/IGP configuration provides reachability to the peer address.
• ACL/firewall policy permits the transport.

One command cannot substitute for the others.

---

3. Scenario — RETICUX Lab FND-004

Two edge routers in different ASes have two parallel physical paths. They will peer using loopbacks so the BGP session is not tied to one interface address.

Topology

Loopback based eBGP transport

              Path A: 192.0.2.0/30
        +--------------------------------+
        |                                |
   +---------+                        +---------+
   | EDGE-A  |                        | EDGE-B  |
   | AS64512 |                        | AS64513 |
   +---------+                        +---------+
        |                                |
        +--------------------------------+
              Path B: 192.0.2.4/30

Loopback0 EDGE-A: 198.51.100.1/32
Loopback0 EDGE-B: 198.51.100.2/32
BGP peer addresses: the loopbacks

Underlay

• EDGE-A Gi0/0 192.0.2.1/30 ↔ EDGE-B Gi0/0 192.0.2.2/30
• EDGE-A Gi0/1 192.0.2.5/30 ↔ EDGE-B Gi0/1 192.0.2.6/30
• Static routes provide reachability to the remote loopback through both links; the example uses one primary static and one floating backup for clarity.

Success criteria

• Both routers can ping the remote loopback using the local loopback as source.
• TCP/179 is reachable.
• BGP establishes between 198.51.100.1 and 198.51.100.2.
• Failure of the primary physical path does not require changing BGP neighbor addresses if the backup underlay route remains.

---

4. Baseline underlay configuration

EDGE-A

hostname EDGE-A
!
interface Loopback0
 ip address 198.51.100.1 255.255.255.255
!
interface GigabitEthernet0/0
 ip address 192.0.2.1 255.255.255.252
 no shutdown
!
interface GigabitEthernet0/1
 ip address 192.0.2.5 255.255.255.252
 no shutdown
!
ip route 198.51.100.2 255.255.255.255 192.0.2.2
ip route 198.51.100.2 255.255.255.255 192.0.2.6 10

EDGE-B

hostname EDGE-B
!
interface Loopback0
 ip address 198.51.100.2 255.255.255.255
!
interface GigabitEthernet0/0
 ip address 192.0.2.2 255.255.255.252
 no shutdown
!
interface GigabitEthernet0/1
 ip address 192.0.2.6 255.255.255.252
 no shutdown
!
ip route 198.51.100.1 255.255.255.255 192.0.2.1
ip route 198.51.100.1 255.255.255.255 192.0.2.5 10

Prove transport reachability before BGP

From EDGE-A:

ping 198.51.100.2 source 198.51.100.1
show ip route 198.51.100.2

From EDGE-B:

ping 198.51.100.1 source 198.51.100.2
show ip route 198.51.100.1

If these tests fail, do not begin by clearing BGP. Fix the underlay first.

---

5. BGP configuration

EDGE-A

router bgp 64512
 bgp log-neighbor-changes
 neighbor 198.51.100.2 remote-as 64513
 neighbor 198.51.100.2 update-source Loopback0
 neighbor 198.51.100.2 ebgp-multihop 2
 address-family ipv4
  neighbor 198.51.100.2 activate
 exit-address-family

EDGE-B

router bgp 64513
 bgp log-neighbor-changes
 neighbor 198.51.100.1 remote-as 64512
 neighbor 198.51.100.1 update-source Loopback0
 neighbor 198.51.100.1 ebgp-multihop 2
 address-family ipv4
  neighbor 198.51.100.1 activate
 exit-address-family

The TTL value of 2 is chosen because the configured peer is reached through one intermediate forwarding hop in the loopback-to-loopback model of this lab. Operators must calculate this based on the real topology rather than copying a high arbitrary value.

---

6. Verification before modification

Session summary

show ip bgp summary

Detailed neighbor state

show ip bgp neighbors 198.51.100.2

Relevant fields to inspect include:

• remote AS;
• external/internal link classification;
• BGP FSM state;
• uptime;
• negotiated capabilities;
• message counters;
• local/foreign TCP endpoints where displayed;
• last reset reason;
• transport statistics.

Verify routing to the peer

show ip route 198.51.100.2
show ip cef 198.51.100.2 detail

The first command confirms the RIB path. The second can help verify forwarding resolution on platforms where the CEF detail is available and useful.

---

7. Controlled modification — remove update-source

On EDGE-A:

configure terminal
router bgp 64512
 no neighbor 198.51.100.2 update-source Loopback0
end

Expected behavior

EDGE-A may now source the connection using an address selected from the outgoing path rather than 198.51.100.1. EDGE-B, however, is configured to recognize 198.51.100.1 as its BGP neighbor.

The result is a peer-address/source mismatch. Underlay reachability to both loopbacks can remain perfectly healthy while BGP fails to establish as designed.

---

8. Fault injection

Illustrative lab — not a real incident.

Fault

Remove update-source Loopback0 from EDGE-A but leave both routers configured to peer with loopback addresses.

Symptoms

• Ping between loopbacks can still succeed.
• The BGP session drops or fails to establish.
• The remote device may see connection attempts from an unexpected interface address.
• Repeated BGP resets do not fix the configuration mismatch.

---

9. Troubleshooting sequence

Step 1 — confirm scope

Only the BGP session is down; interfaces and static routes remain present.

Step 2 — verify peer reachability

ping 198.51.100.2 source 198.51.100.1

Step 3 — inspect the route to the neighbor

show ip route 198.51.100.2

Step 4 — inspect BGP state and reset reason

show ip bgp summary
show ip bgp neighbors 198.51.100.2

Step 5 — inspect configured source

show running-config | section router bgp

Step 6 — confirm multihop configuration

Verify that both peers have a deliberately sufficient ebgp-multihop setting.

Step 7 — check transport policy

If source and route are correct but TCP still fails, check ACLs/firewalls/control-plane policies for TCP 179. On a lab platform, packet capture can confirm SYN/SYN-ACK behavior.

Step 8 — make the smallest correction

Restore the intended source interface rather than changing remote AS, timers or unrelated policy.

---

10. Root cause and correction

Root cause

The BGP session was designed between loopback addresses, but EDGE-A stopped sourcing the TCP session from its loopback after update-source was removed.

Correction

configure terminal
router bgp 64512
 neighbor 198.51.100.2 update-source Loopback0
end

Why it works

The outgoing TCP connection once again uses the address that EDGE-B is configured to recognize as its peer.

---

11. Post-fix verification and path failover

After the session re-establishes:

show ip bgp summary
show ip bgp neighbors 198.51.100.2

Then test the transport resilience by shutting the primary physical link on EDGE-A:

configure terminal
interface GigabitEthernet0/0
 shutdown
end

Verify that the floating static route to the remote loopback becomes active:

show ip route 198.51.100.2
ping 198.51.100.2 source 198.51.100.1

Depending on failure detection and TCP behavior, the existing BGP session may survive if the path changes without breaking transport, or it may reset and re-establish through the alternate path. The key architectural advantage is that the BGP neighbor identity does not need to change simply because the underlay path changes.

Do not claim a specific failover time without executing the exact image/platform and measuring it.

---

12. Rollback

Restore the primary link:

configure terminal
interface GigabitEthernet0/0
 no shutdown
end

Restore update-source if it was removed:

router bgp 64512
 neighbor 198.51.100.2 update-source Loopback0

Preserve:

show ip bgp summary
show ip bgp neighbors 198.51.100.2
show ip route 198.51.100.2
show logging

before clearing sessions during a production incident.

---

13. Production lessons

Layering lesson

BGP troubleshooting begins with IP and TCP. If the peer address is unreachable, BGP policy is irrelevant.

Design lesson

Loopback peering decouples session identity from a physical interface but requires an underlay that can reach the loopbacks.

Configuration lesson

update-source and ebgp-multihop address separate requirements. Copying only one of them is not a complete loopback-peering design.

Security lesson

Do not configure unnecessarily high eBGP multihop TTLs. Later we will use TTL Security/GTSM to constrain session origin more deliberately.

Operations lesson

Preserve transport evidence before clearing BGP. A reset destroys useful state and can hide the actual sequence of failure.

---

14. Knowledge check

Q1

Two eBGP routers can ping each other’s loopbacks, but the loopback-based BGP session fails because one router sources TCP from a physical interface. Which Cisco feature directly addresses the source selection?

Answer: neighbor <peer> update-source <interface>.

Q2

Why might update-source Loopback0 still be insufficient for an eBGP loopback session?

Answer: The peers also need routability to each other’s loopbacks, return reachability, and an eBGP hop/TTL design such as an appropriate ebgp-multihop setting; TCP/179 must also be permitted.

Q3

Why is ebgp-multihop 255 a poor default habit?

Answer: It permits a much broader hop distance than usually required, reducing the adjacency constraint. The TTL should be intentionally limited to the topology, with GTSM considered where appropriate.

---

15. Sources

1. RFC 4271 — *A Border Gateway Protocol 4 (BGP-4)*.
2. Cisco — *IP Routing Configuration Guide, Cisco IOS XE 17.x: Configuring a Basic BGP Network*.
3. Cisco — *BGP Command Reference: show ip bgp neighbors*.
4. Cisco — *IP Routing Configuration Guide: Connecting to a Service Provider Using External BGP*.

Accessed: 2026-08-11.

---