rfc-visual
GitHub

RFC 4271 · January 2006 · Y. Rekhter, T. Li, S. Hares

A Border Gateway Protocol 4 (BGP-4)

DRAFT STANDARDIETF stream
9 verified errata7 held for document update

Index fetched 2026-10-19 from rfc-editor.org

How it works

Built by hand from RFC 4271. Every arrow, step and field cites the RFC sentence it comes from, and an automated test checks each quote against the RFC text. Provisional: not yet reviewed by a second engineer. Help verify this visual

100%

RFC 4271 §4.2 After a TCP connection is established, the first message sent by each side is an OPEN message. If the OPEN message is acceptable, a KEEPALIVE message confirming the OPEN is sent back.

  1. 1. A → B: OPEN

    A's outgoing TCP connection succeeds, so A sends an OPEN message to its peer and moves to OpenSent.

    A: OpenSent · B: —

    RFC 4271 §8.2.2 If the DelayOpen attribute is set to FALSE, the local system: - stops the ConnectRetryTimer (if running) and sets the ConnectRetryTimer to zero, - completes BGP initialization - sends an OPEN message to its peer, - sets the HoldTimer to a large value, and - changes its state to OpenSent.

  2. 2. B → A: OPEN

    B was listening in Active. Once it has accepted the TCP connection, it sends its own OPEN and also moves to OpenSent.

    A: — · B: OpenSent

    RFC 4271 §8.2.2 If the DelayOpen attribute is set to FALSE, the local system: - sets the ConnectRetryTimer to zero, - completes the BGP initialization, - sends the OPEN message to its peer, - sets its HoldTimer to a large value, and - changes its state to OpenSent.

  3. 3. A → B: KEEPALIVE

    A finds no errors in B's OPEN, so it confirms it with a KEEPALIVE, sets its Hold Timer to the negotiated value and moves to OpenConfirm.

    A: OpenConfirm · B: —

    RFC 4271 §8.2.2 If there are no errors in the OPEN message (Event 19), the local system: - resets the DelayOpenTimer to zero, - sets the BGP ConnectRetryTimer to zero, - sends a KEEPALIVE message, and - sets a KeepaliveTimer (via the text below) - sets the HoldTimer according to the negotiated value (see Section 4.2), - changes its state to OpenConfirm.

  4. 4. B → A: KEEPALIVE

    B confirms A's OPEN the same way, passing through OpenConfirm. A side in OpenConfirm that receives a KEEPALIVE moves to Established, so both peers end up Established.

    A: Established · B: Established

    RFC 4271 §8.2.2 If the local system receives a KEEPALIVE message (KeepAliveMsg (Event 26)), the local system: - restarts the HoldTimer and - changes its state to Established.

Not shown: Optional session attributes and their events: DelayOpen and the DelayOpenTimer (Events 12, 20), AutomaticStart/AutomaticStop (Events 3, 5-8), peer oscillation damping and the IdleHoldTimer (Event 13), TCP tracking (Events 14, 15); The 'any other event' fallbacks to Idle with an FSM Error NOTIFICATION, in every state except Idle; Connection collision detection and the OpenCollisionDump event (sections 6.8, 8.2.1.2); Idle-state exits on header/OPEN errors and NOTIFICATIONs in Connect and Active (mostly tied to DelayOpen); OpenConfirm exits on TcpConnectionFails, NotifMsg (Event 25) and header/OPEN errors (their rule text crosses a page break); Self-loops: ConnectRetryTimer_Expires in Connect, KeepaliveTimer_Expires in OpenConfirm and Established, KEEPALIVE/UPDATE received in Established; UPDATE, NOTIFICATION and KEEPALIVE message bodies; path attributes and the decision process.

Lineage

100%

Text

Loading the RFC text…