11.2 EBGP/IBGP Sessions, State Machine and Messages
Key Takeaways
EBGP and IBGP differ in AS relationship, default TTL, next-hop handling and route readvertisement rules.
Connect/Active indicate TCP establishment work; Established is the state used for route exchange.
BGP message types are OPEN 1, UPDATE 2, NOTIFICATION 3 and KEEPALIVE 4; route refresh is a negotiated extension.
4. EBGP vs. IBGP Architectural Differences
BGP behaves differently depending on whether peers belong to the same Autonomous System or different Autonomous Systems:
+---------------------------------------------------------------------------------------------------+
| EBGP VS. IBGP COMPARATIVE SPECIFICATIONS |
+-----------------------------+-----------------------------+---------------------------------------+
| Operational Parameter | External BGP (EBGP) | Internal BGP (IBGP) |
+-----------------------------+-----------------------------+---------------------------------------+
| AS Relationship | Distinct ASNs | Identical ASN |
| | (local-as != peer-as) | (local-as == peer-as) |
+-----------------------------+-----------------------------+---------------------------------------+
| Default IP TTL | 1 | 255 |
+-----------------------------+-----------------------------+---------------------------------------+
| Peering IP Address | Physical interface subnet | Loopback address (lo0.0) via IGP |
+-----------------------------+-----------------------------+---------------------------------------+
| Next-Hop Modification | Automatically reset to self | Preserved unchanged from EBGP |
| | (local peering IP) | (Requires 'then next-hop self' policy)|
+-----------------------------+-----------------------------+---------------------------------------+
| Route Re-advertisement | Allowed to all EBGP & IBGP | Prohibited to other IBGP peers |
| | peers (subject to policy) | (IBGP Split-Horizon rule) |
+-----------------------------+-----------------------------+---------------------------------------+
| Junos Route Preference | 170 | 170 |
+-----------------------------+-----------------------------+---------------------------------------+
EBGP Mechanics: Direct Connection & Multihop
Because EBGP runs between different administrative organizations, routers are typically connected over a dedicated physical point-to-point circuit. By default, EBGP packets are generated with an IP Time-To-Live (TTL) of 1.
Loopback peering uses a destination that is not the directly connected interface address. Junos normally requires multihop and a usable route to that address, plus a matching local-address on the peer. A router does not decrement TTL merely when originating a packet onto its own interface; transit routers decrement TTL when forwarding. The direct-neighbor check and actual transit hop count are separate reasons to configure multihop.
[edit protocols bgp group EBGP-PEER]
set type external
set peer-as 64500
set neighbor 192.0.2.1 multihop ttl 5
set neighbor 192.0.2.1 local-address 198.51.100.1
IBGP Mechanics: Next-Hop Preservation & Split-Horizon
Inside an enterprise AS, IBGP routers typically peer between loopback interfaces (lo0.0) rather than physical links. This ensures that the BGP session remains active as long as the underlying IGP (OSPF or IS-IS) can route traffic around physical link failures.
Two critical operational behaviors govern IBGP:
- Next-Hop Preservation: When an edge router learns an external prefix via EBGP and reflects that route to internal IBGP peers, BGP does not change the next-hop IP address. The next-hop remains the IP address of the external peer in the neighboring AS. If internal core routers do not possess an IGP route to that external next-hop subnet, the route becomes unresolved and is hidden from
inet.0. To correct this, enterprise edge routers apply an export policy containingthen next-hop selfto all IBGP peering sessions. - The IBGP Split-Horizon Rule: To prevent routing loops within an AS without altering the
AS_PATH, BGP dictates that a route learned from an IBGP peer must never be re-advertised to another IBGP peer. Consequently, all routers participating in IBGP must form a full logical mesh of peering sessions (), or implement Route Reflectors.
Junos Route Preference Note: In Junos OS, both EBGP and IBGP routes receive an identical administrative route preference of 170 in the default routing table (
inet.0). This contrasts with other network vendors that assign disparate administrative distances (such as 20 for EBGP and 200 for IBGP).
5. The BGP Finite State Machine (FSM)
A BGP neighbor session progresses through six discrete states defined in RFC 4271:
+---------------------------------------------------------------------------------------------------+
| BGP FINITE STATE MACHINE (FSM) TRANSITION SEQUENCE |
| |
| [1. IDLE] ------(Start Event)-----> [2. CONNECT] <-----(ConnectRetry Expired)----+ |
| ^ | | |
| | (TCP Fails) (TCP Fails) |
| (Error/ | | | | |
| Notification) v +-------------> [3. ACTIVE] ------------+ | |
| | (TCP OK) | |
| | | (TCP OK) |
| | v | |
| +----------------------- [4. OPENSENT] <---------------+ |
| | | |
| | (Open Msg Validated) |
| | v |
| +--------------------- [5. OPENCONFIRM] |
| | | |
| | (Keepalive Received) |
| | v |
| +-------------------- [6. ESTABLISHED] |
+---------------------------------------------------------------------------------------------------+
- Idle: The initial state. BGP allocates local resources, ignores incoming connection attempts, and waits for a Start event (manual activation, configuration commit, or interface up). Upon the Start event, BGP resets the
ConnectRetrytimer, initiates a TCP handshake to the remote peer, and transitions to Connect. - Connect: BGP waits for the TCP three-way handshake to complete. If TCP successfully connects, BGP clears the ConnectRetry timer, sends an Open message to the peer, and transitions to OpenSent. If the TCP connection attempt fails or the ConnectRetry timer expires, BGP drops to Active.
- Active: BGP attempts to restart the TCP connection. If the connection completes, BGP transmits an Open message and moves to OpenSent. If the ConnectRetry timer expires while in Active, BGP transitions back to Connect. A peer cycling indefinitely between Connect and Active typically indicates a physical connectivity failure, firewall blocking port 179, incorrect neighbor IP address, or missing
multihopconfiguration. - OpenSent: BGP has transmitted its Open message and is actively awaiting the peer's Open message. Once received, the local router validates the BGP version, Autonomous System number, BGP Router ID, and negotiated Hold Time. If parameters match, BGP sends a Keepalive packet and transitions to OpenConfirm. If a mismatch occurs (e.g., peer AS mismatch), BGP sends a Notification message and returns to Idle.
- OpenConfirm: BGP waits for a Keepalive or Notification message from the peer. Receipt of a Keepalive message transitions the session to Established.
- Established: The BGP session is fully up and functional. Peers exchange Update messages containing Network Layer Reachability Information (NLRI), Keepalive messages, and optional route refresh requests.
6. BGP Protocol Message Types
All BGP messages share a standardized 19-byte header comprising a 16-byte Marker field (synchronization and authentication), a 2-byte Length field (19-byte header and a baseline maximum message length of 4096 bytes; negotiated Extended Message capability is an explicit exception), and a 1-byte Type field defining four packet types:
| Type | Message Name | Primary Function & Packet Structure | Default Transmission Interval |
|---|---|---|---|
| 1 | Open | Negotiates operational parameters: BGP Version (4), Local ASN, Hold Time (Junos default 90s), BGP Identifier (32-bit RID), and Optional Parameters (Capabilities: 4-byte ASN, Multiprotocol Extensions, Route Refresh, Graceful Restart) | Sent once immediately upon successful TCP connection |
| 2 | Update | Transports routing information. Can advertise a single new path with multiple path attributes alongside Network Layer Reachability Information (NLRI prefixes), and/or withdraw multiple unreachable prefixes simultaneously | Triggered dynamically when routing topology changes |
| 4 | Keepalive | Maintains session liveness and prevents Hold Timer expiration when no Update packets are being exchanged. Consists purely of the standard 19-byte BGP header with no payload | Sent periodically every 30 seconds (1/3 of the 90s Hold Time in Junos) |
| 3 | Notification | Transmitted immediately when an operational error is detected (e.g., Hold Timer expired, bad peer ASN, authentication failure, malformed Update). Contains an Error Code, Error Subcode, and diagnostic data. Instantly closes the TCP connection and resets FSM to Idle | Sent only upon unrecoverable protocol error conditions |
Operational Gotcha: The Hold Timer Negotiation
During the Open message exchange, each peer proposes its configured Hold Time. The operational Hold Time is negotiated to the lower value between the two peers. In Junos, the default Hold Time is 90 seconds, and Keepalives are sent at one-third of this value (30 seconds). If a router fails to receive a Keepalive or Update before the Hold Timer reaches zero, it generates a Notification (Hold Timer Expired), tears down the session, drops all associated BGP routes, and reverts to Idle.
An enterprise edge router learns external prefix 203.0.113.0/24 from an EBGP peer with a next-hop of 198.51.100.1. The edge router re-advertises this route across an IBGP peering session to an internal core router. In Junos OS, what is the default next-hop behavior on the core router, and how should it be resolved if the route is hidden?
The edge router automatically updates the next-hop to its own loopback address; no further configuration is necessary
The next-hop remains 198.51.100.1; if the core router lacks an IGP route to that subnet, the route becomes hidden and requires a 'then next-hop self' export policy on the edge router
The core router resets the next-hop to 0.0.0.0; the core router must configure an explicit static route pointing to the edge router's loopback interface
The next-hop is overwritten with the BGP Router ID of the edge router; the edge router must enable EBGP multihop toward the core router
A network engineer observes that a BGP peering session between two Junos routers is repeatedly cycling between the Connect and Active states without ever progressing to OpenSent. What is the most likely root cause of this operational issue?
The two routers have negotiated mismatched BGP Hold Times in their Open messages
The remote peer received an Update packet with an unrecognized optional non-transitive attribute
A firewall filter or routing issue is preventing the completion of the TCP port 179 three-way handshake
The local router detected its own Autonomous System number inside the AS_PATH attribute
Why is the 'multihop' configuration statement required in Junos OS when establishing an EBGP peering session between loopback interface addresses across direct point-to-point links?
Junos normally expects a directly connected EBGP peer; loopback destinations need multihop configuration and a usable route, with TTL sufficient for transit hops.
Loopback interfaces in Junos operate exclusively in 32-bit AS mode, requiring multihop to convert packets into 2-byte format
EBGP peering requires TCP port 179 to be translated to port 1179 when traversing logical loopback subnets
Internal BGP split-horizon rules prevent loopback addresses from participating in external peering unless multihop is activated
Sections you finish are checked off in the contents.