Basic eBGP Peering

Hi all,

Studying for my CCIE RS, I would like to start of with BGP. On this post I am aiming to explain how BGP relationships form and at the message types with BGP messages.

Note: BGP connects autonomous system (AS) together

We are going to setup neighbour relationship between R1 in AS 100 and R2 in AS 200, Which will be our first eBGP relationship.

R1

config t
!
int lo0
ip address 10.1.0.1 255.255.255.0
!
int s0/2
ip address 10.1.1.1 255.255.255.0
no shut 
!
router bgp 100
neighbor 10.1.1.2 remote-as 200

R2

config t

int lo0
ip address 172.17.0.1 255.255.255.0
!
int s0/0
ip address 10.1.1.2 255.255.255.0
no shut
!
router bgp 200
neighbor 10.1.1.1 remote-as 100

So we have now created a BGP relationship in a few lines.

We can confirm that R1 and R2 are neighbors using the “sh ip bgp neighbors” command and below is the output from this

Looking closely at the output you will notices the relationship is an external one and secondly that the router ID advertised by R2 is 172.17.0.1, the BGP state is established and has been for 2 days and 5 hours and within the uptime period 6177 Keepalive messages. And lastly we can see that the connection is using port 179 on R2 and 57776 on R1 this indicates that R2 is the active peer of the relationship.

R1

R1#sh ip bgp neighbors 

BGP neighbor is 10.1.1.2,  remote AS 200, external link
  BGP version 4, remote router ID 172.17.0.1
  BGP state = Established, up for 2d05h
  Last read 00:00:30, last write 00:00:30, hold time is 180, keepalive interval is 60 seconds
  Neighbor capabilities:
    Route refresh: advertised and received(old & new)
    Address family IPv4 Unicast: advertised and received
  Message statistics:
    InQ depth is 0
    OutQ depth is 0
                         Sent       Rcvd
    Opens:                  4          4
    Notifications:          0          0
    Updates:                0          0
    Keepalives:          6177       6177
    Route Refresh:          0          0
    Total:               6181       6181
  Default minimum time between advertisement runs is 30 seconds

 #truncated#

Connection state is ESTAB, I/O status: 1, unread input bytes: 0            
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
Local host: 10.1.1.1, Local port: 57776
Foreign host: 10.1.1.2, Foreign port: 179

R2

R2#sh ip bgp neighbors 

BGP neighbor is 10.1.1.1,  remote AS 100, external link
  BGP version 4, remote router ID 10.1.0.1
  BGP state = Established, up for 2d05h
  Last read 00:00:49, last write 00:00:49, hold time is 180, keepalive interval is 60 seconds
  Neighbor capabilities:
    Route refresh: advertised and received(old & new)
    Address family IPv4 Unicast: advertised and received
  Message statistics:
    InQ depth is 0
    OutQ depth is 0
                         Sent       Rcvd
    Opens:                  5          5
    Notifications:          0          0
    Updates:                0          2
    Keepalives:          6214       6212
    Route Refresh:          0          0
    Total:               6219       6219
  Default minimum time between advertisement runs is 30 seconds

   #truncated#

Connection state is ESTAB, I/O status: 1, unread input bytes: 0            
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
Local host: 10.1.1.2, Local port: 179
Foreign host: 10.1.1.1, Foreign port: 57776

It's amazing to see how BGP completes it transformation to established, use the “debug bgp all” command is one way to accomplish another way is GNS3 by right clicking the link between R1 and R2 you can select capture which uses wire shark.

Below uses the Cisco IOS command the router goes through a number of states, from Active it goes to Idle, from it goes to Connect. From Connect it goes to Opensent, and then to OpenConfirm, before finally becoming Established.


ldle is the initial state when the routing process is enabled, or when the device is reset. The devices waits to receive a connection request from a remote peer, this is shown as the passive open message in the output below
Once we get the connection request we then move to Connect state this where the BGP process detects that a peer is attempting to connect and setup a TCP session.
The will then try to establish a TCP session with a peer. If the session is successful the connection state will move to Opensent state this is where the connection is established and an open messages is sent. The peer which receive the opensent confirms with an OpenComfirm massage state and a keep live message once received the peering transition to the Established state. At this point we can safely say that peering is now fully operational.

One more thing once we have established state the peer will exchange keepalives messages to make sure that the remote peer is still available the keepalive messages are sent by default 60 seconds and if no reply is heard within the hold time (default 180 seconds) the router declares the peer to be dead.

*Mar  7 18:14:52.607: BGP: 10.1.1.1 passive open to 10.1.1.2
*Mar  7 18:14:52.607: BGP: 10.1.1.1 went from Active to Idle
*Mar  7 18:14:52.607: BGP: 10.1.1.1 went from Idle to Connect
*Mar  7 18:14:52.611: BGP: 10.1.1.1 rcv message type 1, length (excl. header) 26
*Mar  7 18:14:52.611: BGP: 10.1.1.1 rcv OPEN, version 4, holdtime 180 seconds
*Mar  7 18:14:52.611: BGP: 10.1.1.1 went from Connect to OpenSent
*Mar  7 18:14:52.611: BGP: 10.1.1.1 sending OPEN, version 4, my as: 200, holdtime 180 seconds
*Mar  7 18:14:52.611: BGP: 10.1.1.1 rcv OPEN w/ OPTION parameter len: 16
*Mar  7 18:14:52.611: BGP: 10.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Mar  7 18:14:52.611: BGP: 10.1.1.1 OPEN has CAPABILITY code: 1, length 4
*Mar  7 18:14:52.611: BGP: 10.1.1.1 OPEN has MP_EXT CAP for afi/safi: 1/1
*Mar  7 18:14:52.611: BGP: 10.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar  7 18:14:52.611: BGP: 10.1.1.1 OPEN has CAPABILITY code: 128, length 0
*Mar  7 18:14:52.611: BGP: 10.1.1.1 OPEN has ROUTE-REFRESH capability(old) for all address-families
*Mar  7 18:14:52.611: BGP: 10.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar  7 18:14:52.611: BGP: 10.1.1.1 OPEN has CAPABILITY code: 2, length 0
*Mar  7 18:14:52.611: BGP: 10.1.1.1 OPEN has ROUTE-REFRESH capability(new) for all address-families 
BGP: 10.1.1.1 rcvd OPEN w/ remote AS 100
*Mar  7 18:14:52.611: BGP: 10.1.1.1 went from OpenSent to OpenConfirm
*Mar  7 18:14:52.611: BGP: 10.1.1.1 send message type 1, length (incl. header) 45
*Mar  7 18:14:52.619: BGP: 10.1.1.1 went from OpenConfirm to Established
*Mar  7 18:14:52.623: %BGP-5-ADJCHANGE: neighbor 10.1.1.1 Up