BGP Peering - why two KEEPALIVE Messages

Question

During the process of BGP establishing a BGP peering between two routers. There is the following exchange. What puzzles me a little is that after each UPDATE Message there are two KEEPALIVE messages in the same packet. Any idea why ?

**Source       Destination  Proto  Length  Message**
ROUTER_A --> ROUTER_B      BGP    99     OPEN Msg
ROUTER_B --> ROUTER_A      BGP    118    OPEN Msg, KEEPALIVE Msg
ROUTER_A --> ROUTER_B      BGP    73     KEEPALIVE Msg
ROUTER_A --> ROUTER_B      BGP    106    UPDATE Msg
ROUTER_A --> ROUTER_B      BGP    92     KEEPALIVE Msg, KEEPALIVE Msg

Border Gateway Protocol - KEEPALIVE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 19
    Type: KEEPALIVE Message (4)
Border Gateway Protocol - KEEPALIVE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 19
    Type: KEEPALIVE Message (4)

ROUTER_B --> ROUTER_A      BGP    106    UPDATE Msg
ROUTER_B --> ROUTER_A      BGP    92     KEEPALIVE Msg, KEEPALIVE Msg

Border Gateway Protocol - KEEPALIVE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 19
    Type: KEEPALIVE Message (4)
Border Gateway Protocol - KEEPALIVE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 19
    Type: KEEPALIVE Message (4)

Answer 1

When the routers on either end of a BGP session first boot, the session between them is in the Idle state. The BGP session remains idle until a start event is detected. Typically, the start event is the configuration of a new BGP session or the resetting of an existing BGP session. At boot time, the start event is generated by the router as the BGP session is initiated.

After it detects a start event, the BGP host sends TCP request packets to its configured BGP neighbors. These packets are directed only to neighboring interfaces that have been explicitly configured as BGP neighbors. Upon receipt of the TCP request packet, the neighboring host generates a TCP response to complete the three-way handshake and establish a TCP connection between the peers. While this handshake is taking place, the BGP state for the connection is Connect. If a TCP timeout occurs while the originating host is waiting for a TCP response packet, the BGP state for the connection is Active. The Active state indicates that the router is actively listening for a TCP response and the TCP retry timer has been initiated.

Once a TCP connection has been established between both ends of a BGP session, the BGP session state is OpenSent, indicating that the originating router has generated an open message. The open message is an initial BGP handshake that must occur before any route advertisement can take place. Upon receipt of the open message, the neighboring router generates a keepalive message. Receipt of the keepalive message establishes a point-to-point connection, and the BGP session state transitions to Established. While the originating host waits for the keepalive response packet, the BGP session state is OpenConfirm.

Source of the information