BGP Update-Source on One Side Packet Capture

This packet capture shows a classic iBGP mistake that doesn’t always break anything: two routers peer between their loopbacks (1.1.1.1 and 2.2.2.2), but only R1 has neighbor 2.2.2.2 update-source Loopback0. R2 is missing it. When R2 tries to connect, it uses its interface address as the source, and R1 answers with a TCP RST. When R1 connects, the session comes up fine.

So the session works, but only one router can ever open it. The capture shows both attempts right after a session reset. The internal BGP lesson explains why iBGP peers use loopbacks, and troubleshooting BGP neighbor adjacency covers this and other session problems. More captures are in the Packet Capture Library.

Want to open this capture in Wireshark yourself? The pcap file is free with a NetworkLessons account. Your free account also unlocks all our free lessons and every capture in the Packet Capture Library.

Create a free account to download the pcap

Already have an account? Log in and the download button appears here.

Capture overview

File	bgp-update-source-one-side.pcapng
Packets	26
Protocol	BGP-4 over TCP 179, iBGP in AS 1
Devices	Cisco IOS: R1 (loopback 1.1.1.1, with update-source), R2 (loopback 2.2.2.2, interface 192.168.12.2, without update-source)
Wireshark filter	tcp.port == 179 or tcp.flags.reset == 1 for the rejected attempt

This is the relevant configuration:

R1(config)#router bgp 1
R1(config-router)#neighbor 2.2.2.2 remote-as 1
R1(config-router)#neighbor 2.2.2.2 update-source Loopback0

R2(config)#router bgp 1
R2(config-router)#neighbor 1.1.1.1 remote-as 1

Packets in this capture

No. Time       Source        Destination   Info
1   0.000000   2.2.2.2       1.1.1.1       NOTIFICATION (Cease / Administratively Reset)
2-5 0.016802   ...                         TCP FIN/ACK, old session closed
6   13.363762  192.168.12.2  1.1.1.1       13589 → 179 [SYN]
7   13.372824  1.1.1.1       192.168.12.2  179 → 13589 [RST, ACK]
8   13.995283  1.1.1.1       2.2.2.2       15259 → 179 [SYN]
9   14.096722  2.2.2.2       1.1.1.1       179 → 15259 [SYN, ACK]
10  14.099093  1.1.1.1       2.2.2.2       15259 → 179 [ACK]
11  14.112682  1.1.1.1       2.2.2.2       OPEN Message
13  14.148365  2.2.2.2       1.1.1.1       OPEN Message
14  14.150158  2.2.2.2       1.1.1.1       KEEPALIVE Message
16  14.184810  1.1.1.1       2.2.2.2       KEEPALIVE Message
18  14.194838  1.1.1.1       2.2.2.2       UPDATE Message
21  14.386696  2.2.2.2       1.1.1.1       UPDATE Message
...

Packet walkthrough

The session reset (packet 1)

Border Gateway Protocol - NOTIFICATION Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 21
    Type: NOTIFICATION Message (3)
    Major error Code: Cease (6)
    Minor error Code (Cease): Administratively Reset (4)

The capture starts with someone running clear ip bgp on R2. R2 sends a NOTIFICATION with Cease / Administratively Reset, and both routers close the TCP connection (packets 2-5). Then both routers try to set up a new session.

R2 connects: TCP RST (packets 6-7)

Internet Protocol Version 4, Src: 192.168.12.2, Dst: 1.1.1.1
Transmission Control Protocol, Src Port: 13589, Dst Port: 179
    Flags: 0x002 (SYN)

Internet Protocol Version 4, Src: 1.1.1.1, Dst: 192.168.12.2
Transmission Control Protocol, Src Port: 179, Dst Port: 13589
    Flags: 0x014 (RST, ACK)

• Source 192.168.12.2: R2 has no update-source, so it uses the address of its outgoing interface toward 1.1.1.1. The destination is right, but the source isn’t the address R1 expects.
• RST, ACK from R1: R1 only accepts BGP connections from addresses that are configured as a neighbor. It has neighbor 2.2.2.2, not neighbor 192.168.12.2, so it refuses the connection with a TCP reset. On the router, you’d see the neighbor stuck in Active, and possibly a “no such neighbor” or connection refused message in the debug.

R1 connects: session comes up (packets 8-21)

Internet Protocol Version 4, Src: 1.1.1.1, Dst: 2.2.2.2
Transmission Control Protocol, Src Port: 15259, Dst Port: 179
    Flags: 0x002 (SYN)

• Source 1.1.1.1: R1 has update-source Loopback0, so its SYN comes from its loopback.
• R2 accepts it: R2 has neighbor 1.1.1.1, and the SYN comes from 1.1.1.1 to R2’s own loopback 2.2.2.2. R2 replies from the address the connection was sent to, so the reply’s source is 2.2.2.2 automatically. That’s why the missing update-source on R2 doesn’t matter here.
• OPEN, KEEPALIVE, UPDATE: the session goes to Established and the routers exchange their routes. Both OPEN messages show My AS 1 (iBGP) and the BGP identifiers 1.1.1.1 and 2.2.2.2.

Why this is a problem anyway

The session works, so it’s easy to miss. But it only works because R1 happens to win the race to open the connection, or because R2’s attempts keep failing. Every time the session resets, R2 sends SYNs that get rejected until R1 tries again. If R1 is ever configured with neighbor 2.2.2.2 transport connection-mode passive, nobody opens the session and it never comes back. The fix is simple: configure update-source on both routers, so either side can open the session.