Quick summary about the Border Gateway Protocol (BGP). Today’s most relevant protocol for Overlay in Data Center as well as becoming more popular for underlay too. And the Internet’s protocol, so important in WAN communications.

Two flavours, iBGP and eBGP, this last being used in both the Internet and in the DC, and iBGP only within the same organization as it uses the same Autonomous System. Public AS typically belong to ISP’s or other large organizations (range from 1 to 64511). Private AS (numbers range from 64512 to 65535) can be used inside the organizations.

Due to its inter-domain features and its scalability, BGP is used in the Internet to inter-connect domains, something that IGPs cannot.

Inside the same organizations, there are also considerations to take into account to choose BGP instead of IGP, if compared to OSPF, we can mention the following as an example:

-OSPF follows a hierarchical structure, while BGP would be usually adopting a mesh structure.

– OSPF requires a more intensive use of memory and CPU resources, this is a problem as we scale up. It is exchanging packages frequently and it has the whole picture of the area components, plus other area’s routing information.

-OSPF focuses on determining the fastest route whereas BGP installs the best path.

OSPF is a good fit in enterprise/campus networks as well as in some Data Centers as the underlay protocol, and BGP it is used where scalability could be an issue and due to its powerful prefix manipulation and flexibility.

BGP runs on top of TCP as its transport protocol and operates on port 179.

BGP uses four different message types: OPEN, UPDATE, KEEPALIVE and NOTIFICATION.

The BGP header is as follows:

where the Marker contains an authentication value that the message receiver can predict.

the Length indicates the total length of the message in bytes.

Type indicates what kind of message is it from the four types.

and Data, which contains upper-layer information in this optional field.

BGP has two phases for session establishment between two speakers:

1. TCP connection establishment phase
2. BGP session establishment phase

BGP uses a finite state machine (FSM) to keep track of the session, during the first phase, TCP establishment, the FSM goes through the following states:


once the TCP messages are exchanged and TCP connection is established to deliver BGP packages, the next FSM states are:


In the first two states BGP attributes are exchange between the speakers. and the established state means that the peer is in a stable state and can accept routing updates.

in the Opensent state, the BGP speaker has sent an OPEN message to its peer and is waiting for the Peer to send its own OPEN message. Once this occurs, the state transitions to Openconfirm state where the speakers compare their attributes in the peer’s OPEN message to that of its own. If it is acceptable the speaker respondes with a Keepalive packet and the state changes to Established, after this, UPDATE messages are sent to exchange routing information.

In the OPEN message there are six main attributes:

version of the BGP supported by the router
The router’s Autonomous System Number
The router’s hold timer
The router’s BGP identifier
The optional parameters the router supports

Single-hop vs Multihop

Single-hop sessions are created when two speakers are located in a single physical or logical router hop away. This allows you to peer with the neighbor within the same subnet only. If it needs to peer with an IP located on another interface, such as the loopback, then we need a mechanism to avoid this limitation (as the TTL is set to 1 by default in ebgp) such as the ebgp multihop option, which would be changed to 2 (change the TTL to 2) for example if the loopback is located in the neighbor’s router.

Why would I use as the peer IP the loopback instead of the direct connected interface? Redundancy purposes, your session remains connected if there’s other path between the routers, and we avoid having duplicated information in case we had two sessions established between routers, which is a waste of resources and our configuration gets more complex.

neighbor x.x.x.x update-source [interface] is an important command in this cases, as if we establish the peering against the loopback, the packets will be sent from the outgoing interface which is the ethernet connecting to the router, and it will be discarded as the peering is established against the loopback. therefore using this command will solve this situation. This is relevant during the TCP session establishment only though, meaning that as both speakers act as client and server in the TCP session, if we configure it the command only in one of the speakers rather than in both, it will work as well, as one of the sessions will be accepted and the other dropped as it would expect a different source.