BGP Packet and Neighbor negotiation

BGP Header

  • Marker – 16 byte field used for BGP authentication. If authentication is not used, Marker field contains all 1s
  • Length – Length of BGP message
  • Type – OPEN, UPDATE, NOTIFICATION, KEEPALIVE, ROUTE REFRESH (if peer support this capability)

OPEN Message Format

Open message is used for BGP session establishment. First we check what fields the OPEN message contains and we check the actual neighbor negotiation.

  • Version – BGP version
  • My AS – AS number
  • Hold timer
  • BGP Identifier – BGP Router ID. Loopback in most cases
  • Optional Parameter Lenght – total length of optional parameters
  • Optional Parameter – optional parameter represented by triplet Type, Lenght, Value. Here are the optional Capabilities which contains information that allows for BGP feature negotiation; it is either supported or unsupported between BGP peers. If a Capability option is not supported, it will be ignored by the remote peer, and the session will be renegotiated without the capability. This way the BGP protocol can be enhanced for new features without need for changing the protocol.

BGP key states during negotiation:

  1. IDLE
  2. CONNECT – BGP is going to use 3-Way TCP handshake to connect to its peer. If connection is successful the state transit to OPEN Sent state, if the state would be unsuccessful the state transit to ACTIVE state.
  3. ACTIVE – BGP is actively trying to connect to its peer. If the connection is successful the state transit to OPEN Sent state, otherwise if the ConnectRetry timer expires, BGP restart the ConnectRetry timer and fall back to CONNECT state.
  4. OPEN SENT – your router has sent an open sesssion message to the neighbor you manually configured. OPEN SENT means that you just sent the open message and you are waiting to receive the confirmation.
  5. OPEN CONFIRMED – router has received confirmation to the OPEN SENT message from neighbor.
  6. ESTABLISHED – when everything is OK this is the last stage. However you wont be able to see this stage because when is everything ok and established you just see in the show ip bgp summary other things like link counts, hold timer,… So if you dont see any of these stages and you dont see established thats probably good thing 😉 At this stage the BGP peer start exchanging the UPDATE packets with its peer.

NOTIFICATION Message

A NOTIFICATION message is always sent whenever an error is detected. After that, the peer connection is closed.

KEEPALIVE Message

KEEPALIVE messages are periodic messages exchanged between peers to determine whether peers are reachable. the hold time is the reset after receipt of successive KEEPALIVE or UPDATE messages.

UPDATE Message

Central to the BGP protocol is the concept of routing updates. Routing updates contain all the necessary information that BGP uses to construct a loop-free picture of the network. The following are the basic blocks of an UPDATE message:

  • Network Layer Reachability Information (NLRI) – the routes itself, the prefixes
  • Path Attributes – here are all the BGP attributes, both well known and optional.
  • Unreachable routers

In nuts the NLRI indicates, in the form of an IP prefix route, the networks being advertised. The Path Attribute list enables BGP to detect routing loops and gives it the flexibility to enforce local and global routing policies. An example of a BGP Path Attribute is the AS_PATH attribute, which is a sequence of AS numbers that a route has traversed before reaching the BGP router. The third part of the UPDATE message is a list of routes that have become unreachable or, in BGP terminology, withdrawn.

BGP Capabilities Negotiation

BGP peer capabilities can be negotiated during session BGP initialization, using the Optional Capabilities parameter, which is contained in the OPEN message. BGP capabilities negotiation is described in RFC 2842. This element was added into BGP so that new features could be added into the BGP specification without requiring upgrades to newer versions of the protocol.

Using capabilities advertisement, peers can exchange capabilities and negotiate a session using the most agreed-upon features. If one of the peers does not support an optional parameter, it sends the advertiser a NOTIFICATION message with the error „Unsupported Optional Parameter.“ After receiving the NOTIFICATION message, the advertising peer resends the message without the unsupported parameter and so on, until both peers agree on a set of parameters. BGP capabilities fields are as follows:

  • 0 Reserved
  • 1 Multiprotocol extensions for BGP-4
  • 2 ROUTE-REFRESH capability for BGP-4
  • 3 Cooperative route filtering capability
  • 4 Multiple routes to a destination capability
  • 5–63 Unassigned
  • 64 Graceful restart capability
  • 65 Support for 4-octet AS number capability
  • 66 Support for dynamic capability
  • 128–255 Vendor specific

Route-Refresh Messages

BGP systems send route-refresh messages to a peer only if they have received the route refresh capability advertisement from the peer. A BGP system must advertise the route refresh capability to its peers using BGP capabilities advertisement if it wants to receive route-refresh messages. This optional message is sent to request dynamic, inbound, BGP route updates from BGP peers or to send outbound route updates to a BGP peer.

Route-refresh messages consist of the following fields:

  • AFI—Address Family Identifier (16-bit).
  • Res—Reserved (8-bit) field, which must be set to 0 by the sender and ignored by the receiver.
  • SAFI—Subsequent Address Family Identifier (8-bit).

If a peer without the route-refresh capability receives a route-refresh request message from a remote peer, the receiver ignores the message.