BGP notes:

Runs over reliable transport

Eliminate the need to implement : update fragmentation, retransmission,
acknowledgement, and sequencing
Based on TCP
Uses TCP port :179 for establishing the connections
2 hosts form a transport protocol connection. They exchange messages to
open and confirm the connection parameters.
Initial dataflow= entire BGP routing table
Routing table changes =>incremental updates
Keep alive messages ,periodically to ensure that the connection is alive
In response to errors or special conditions =>notification messages
Hosts = Routers
AS with more than one BGP gateway=>the gateways must have direct BGP
Sessions with each other.

Messages:
-

Max message size =1024 bytes

A. Message header:

a.

b.

Marker : 16 bits
Mark the start of the message
Synchronization error opcode 5
Length : 16 bits
Total Length of the message(Including header in bytes)
If illegal length is detected >1024bytes or <8bytes => notification
message with opcode 6
c. Version : 8 bits
Current BGP version
Bad version=> notification message with opcode 8
d. Type : 8 bits
Type codes:
1 - OPEN
2 - UPDATE
3 - NOTIFICATION
4 - KEEPALIVE
5 - OPEN CONFIRM
Unrecognized type value => notification message with opcode 7

e. Hold Timer:
Number of seconds that elapse since receiving a BGP Keep Alive or BGP
Update
B. OPEN Message
After a transport protocol connection is established, the first message sent
by the ether side is an OPEN Message
If the OPEN message is acceptable=>Open Confirm =>after that: keep
alive, update, notification

a. My Autonomous System: 16 bits

Autonomous System number
If there is a problem with the filled a message with opcode 9 is sent
b. Link Type: 8 bits
Define the codes:
0 INTERNAL- the peer is another BGP speaking host in our AS
1 UP - the peer is higher in the AS hierarchy
2 DOWN the peer is lower in the AS hierarchy
3 - H-LINK- the peer is at the same level
-defining our position in the AS graph relative to our peer
-if link type is unacceptable a message with opcode 1 is sent
c. Authentication code:8 bits
Value= Authentication method that has been used
0= no authentication is used
Authentication value is not recognized= message with opcode 2
d. Authentication Data: variable length
Contains authentication data
If authentication fails a message with opcode3 is sent
C. OPEN CONFIRM Message
-sent after receiving an open Message
-this completes the BPG connection setup
-consists of: BGP header with an OPEN Confirm type
-no data in this message
D. UPDATE Message
- Used to transfer routing info between BGP peers
- The info can be used to construct a graph describing the relationships of
the various AS
- When an error is detected: message with opcode 4

a. Gateway : 32bits
The address of a gateway that has routes to the Internet Networks
Must belong to the same AS as the BGP peer who advertises it
If there is a problem with the gateway -> message with subcode 6
b. AS count: 8bits
Count of direction and AS number pairs
If it is incorrect=> subcode 1
c. Direction : 8bits
The direction taken by the routing info when exiting the AS defined by
succeedinf AS number field
Values defined:
1 - UP (went up a link in the graph)
2 - DOWN (went down a link in the graph)
3 - H_LINK (horizontal link in the graph)
4 - EGP_LINK (EGP derived information)
5 - INCOMPLETE (incomplete information)
If the code is unrecognized =>subcode 2
d. AS Number : 16bits
As number that transmit the routing info
If there is a problem with the AS number =>subcode 3
e. Net Count : 16 bits
The number of metric and network field pairs which follow this field
If there is a problem =>subcode 7
f. Network : 16 bits
4 bytes of internet Network number

If there is a problem => subcode 8

g. Metric :16 bits
BGP metrics are comparable only if routes have exactly the same AS
path
E. NOTIFICATION message
Sent when an error condition is detected
BGP connection is closed shortly after sending the notification error

a. Opcode : 16 bits
Opcodes :
1 (*) - link type error in open. Data is one byte of proper link type.
2 (*) - unknown authentication code. No data.
3 (*) - authentication failure. No data.
4 (*) - update error. See below for data description.
5 (*) - connection out of sync. No data.
6 (*) - invalid message length. Data is two bytes of bad length.
7 (*) - invalid message type. Data is one byte of bad message type.
8 (*) - invalid version number. Data is one byte of bad version.
9 (*) - invalid AS field in OPEN. No data.
10 (*) - BGP Cease. No data.
The following subcodes are defined:
1 - Invalid AS count
2 - Invalid direction code
3 - Invalid autonomous system
4 - EGP_LINK or INCOMPLETE_LINK link type at other than the end of
the AS path list
5 - Routing loop
6 - Invalid gateway field
7 - Invalid Net Count Field
8 - Invalid network field
b. Data : variable
F. KEEPALIVE
BGP does not use any transport protocol based keepalive mechanism to
determine if the peers are reachable
Reasonable minimum frequency of keepalive exchange would be one third
of the Hold Time interval
BGP header without any Data

BGP Finite State machine

A. BGP-Idle State

Refuses all incoming BGP connections

No resources are allocated to the BGP neighbor
In response to the Start Event =>local system initializes all BGP resource
and changes its state to Active
B. BGP-Active State
-trying to acquire a BGP neighbor by opening the transport protocol
connection
-if the TP open fails, BGP stays in the BGP-Active state
-otherwise the local system sends an OPEN message to its peer and
changes its state to BGP-OPENSent
-in response to the Stop event the local system releases all BGP resources
and changes the state to Idle
C. BGP-OpenSent State
-waits for an OPEN message from its peer
-when an open message is received => the files are checked
-if the initial BGP header checking detects an error, BGP deallocates all
resources associated with this peer and returns to Active state
-otherwise the Link Type, Authentication code, Authentication Data fields
are checked
-if link type is incorrect => Notification message with opcode 1.The
following combination of link type fields are correct:

- if the link type between two peers is internal => the AS number must be
the same
- if the Authentication code field is non-zero => checked for known
authentication codes
- if the Authentication code field is non-zero => the authentication
procedure is invoked
- if any of the above tests detect an error the local system closes the BGP
conection =>BGP Idle
- if there are no errors BGP sends and OPEN Confirm message and goes
into the BGP-OPENConfirm State
- if disconnect notification is received =>IDLE State
D. BGP-OpenConfirm State
-Waits for an open conform message =>then goes to Established
-if the hold times expires before an open confirm massage is received=>
BGP-Idle
E. BGP- Established State
Update message handling
-BGP update message may be received only the Bgp_Established