What transport does BGP use, and who opens the connection?
Show the answer
Say this first
BGP runs over TCP port 179. Each side tries to connect to the other's port 179 from an ephemeral port. If both succeed at the same time, collision detection keeps the connection opened by the router with the higher BGP router ID and closes the other. TCP gives BGP reliable, ordered delivery, so BGP needs no retransmission of its own and sends only incremental updates after the first full exchange.
Go deeper
Seeing who connected
R1# show tcp brief
TCB Local Address Foreign Address (state)
7F8A2C1B3D40 192.0.2.2.179 192.0.2.1.38112 ESTABR1 owns port 179 in this connection, so ISP1 (192.0.2.1) opened it. You can force one side to wait with
neighbor 192.0.2.1 transport connection-mode passive.
What follows from running over TCP
- Firewalls and ACLs must allow TCP 179 between the peers, in the direction each side may connect.
- Session authentication lives in TCP options: MD5 (RFC 2385) or TCP-AO (RFC 5925).
- Path MTU matters. If the session comes up but drops a few minutes later every time, with the hold timer expiring during the initial table transfer, suspect full-size TCP segments being dropped on the path while small keepalives get through.
Message framing
Every message starts with a 19-byte header: a 16-byte marker of all ones, a 2-byte length and a 1-byte type. The maximum message size is 4096 bytes, or 65535 when both peers support extended messages (RFC 8654).
They will ask next
Why does BGP use TCP when OSPF does not?
BGP moves very large tables between organisations, often across several hops. TCP gives it reliability and flow control for free and works over any routed path. OSPF only talks to neighbors on the same link, so it runs directly on IP (protocol 89) with its own acknowledgments.
If TCP is reliable, why does BGP need keepalives?
TCP keeps quiet when nothing is sent, and it does not prove the BGP process on the other side is healthy. BGP KEEPALIVE messages and the hold timer do that.
Traps
- Saying UDP 179.
- Thinking only one side listens. Both listen and both try to connect unless one is set to passive.