iBGP and eBGP Peerings

Contents

Intro

In this tutorial we will explore the configuration of internal BGP (iBGP) and external BGP (eBGP) peerings. This will help us understand how BGP peerings are established between different Autonomous Systems (eBGP) and within the same Autonomous Systems (iBGP).

Topology

Network topology diagram for iBGP and eBGP tutorial featuring four routers: R1 in AS1, R2 in AS2, R3 and R4 in AS4.
The last octet is the router number unless specified otherwise. Example: R1's G0/2 is 10.10.13.1/24

Initial Configs

Configuration Steps

1. Configure iBGP peerings between R3 and R4.

R3 needs to peer with R4 and they’re in the same autonomous system (AS). This makes them internal BGP (iBGP) peers. 

R3:

router bgp 34
 neighbor 10.10.34.4 remote-as 34

The first thing I did on R3 was create the BGP process using an AS number of 34. Then I specified the IP address of the neighbor and what AS that neighbor is in. 

R4:

router bgp 34
 neighbor 10.10.34.3 remote-as 34

I did the same thing on R4 but in the reverse direction. R4 neighbor statement points to R3 and R3 neighbor statment points to R4. The AS number configured locally on the router and the AS number used in the neighbor statement are the same, this makes them internal BGP (iBGP) peers. 

As long as a TCP session can form between the IP addresses used in the peerings, and no ACL’s or firewalls are blocking BGP messages, then the peers should come up. A SYSLOG message popped up letting me know the neighbors are up.

R3:

%BGP-5-ADJCHANGE: neighbor 10.10.34.4 Up

R4:

%BGP-5-ADJCHANGE: neighbor 10.10.34.3 Up

We can examine the details of the BGP session by using the show ip bgp neighbors command. 

R3#sh ip bgp neighbors 
BGP neighbor is 10.10.34.4,  remote AS 34, internal link
  BGP version 4, remote router ID 10.10.34.4
  BGP state = Established, up for 00:13:18
  Last read 00:00:30, last write 00:00:43, hold time is 180, keepalive interval is 60 seconds
  Neighbor sessions:
    1 active, is not multisession capable (disabled)
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Four-octets ASN Capability: advertised and received
    Address family IPv4 Unicast: advertised and received
    Enhanced Refresh Capability: advertised and received
    Multisession Capability: 
    Stateful switchover support enabled: NO for session 1
  Message statistics:
    InQ depth is 0
    OutQ depth is 0
    
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:                1          1
    Keepalives:            15         15
    Route Refresh:          0          0
    Total:                 17         17
  Do log neighbor state changes (via global configuration)
  Default minimum time between advertisement runs is 0 seconds

 For address family: IPv4 Unicast
  Session: 10.10.34.4
  BGP table version 1, neighbor version 1/0
  Output queue size : 0
  Index 1, Advertise bit 0
  1 update-group member
  Slow-peer detection is disabled
  Slow-peer split-update-group dynamic is disabled
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:               0          0
    Prefixes Total:                 0          0
    Implicit Withdraw:              0          0
    Explicit Withdraw:              0          0
    Used as bestpath:             n/a          0
    Used as multipath:            n/a          0
    Used as secondary:            n/a          0

                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Total:                                0          0
  Number of NLRIs in the update sent: max 0, min 0
  Last detected as dynamic slow peer: never
  Dynamic slow peer recovered: never
  Refresh Epoch: 1
  Last Sent Refresh Start-of-rib: never
  Last Sent Refresh End-of-rib: never
  Last Received Refresh Start-of-rib: never
  Last Received Refresh End-of-rib: never
                                       Sent       Rcvd
        Refresh activity:              ----       ----
          Refresh Start-of-RIB          0          0
          Refresh End-of-RIB            0          0

  Address tracking is enabled, the RIB does have a route to 10.10.34.4
  Route to peer address reachability Up: 1; Down: 0
    Last notification 00:13:41
  Connections established 1; dropped 0
  Last reset never
  Interface associated: (none) (peering address in same link)
  Transport(tcp) path-mtu-discovery is enabled
  Graceful-Restart is disabled
  SSO is disabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0            
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255
Local host: 10.10.34.3, Local port: 51787
Foreign host: 10.10.34.4, Foreign port: 179
Connection tableid (VRF): 0
Maximum output segment queue size: 50

Enqueued packets for retransmit: 0, input: 0  mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x134596):
Timer          Starts    Wakeups            Next
Retrans            17          0             0x0
TimeWait            0          0             0x0
AckHold            17         14             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger          111        110        0x134B84
DeadWait            0          0             0x0
Linger              0          0             0x0
ProcessQ            0          0             0x0
          
iss:  795824705  snduna:  795825071  sndnxt:  795825071
irs: 1267824477  rcvnxt: 1267824843

sndwnd:  16019  scale:      0  maxrcvwnd:  16384
rcvwnd:  16019  scale:      0  delrcvwnd:    365

SRTT: 897 ms, RTTO: 1680 ms, RTV: 783 ms, KRTT: 0 ms
minRTT: 15 ms, maxRTT: 1000 ms, ACK hold: 200 ms
uptime: 798995 ms, Sent idletime: 30548 ms, Receive idletime: 30750 ms 
Status Flags: active open
Option Flags: nagle, path mtu capable
IP Precedence value : 6

Datagrams (max data segment is 1460 bytes):
Rcvd: 33 (out of order: 0), with data: 17, total data bytes: 365
Sent: 34 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 17, total data bytes: 365

 Packets received in fast path: 0, fast processed: 0, slow path: 0
 fast lock acquisition failures: 0, slow path: 0
TCP Semaphore      0x1142D1BC  FREE

There is a ton of information displayed about this neighbor in the above output. It’s actually way too much. I’ve highlighted that the BGP state is established and for how long as well as how many prefixes have been sent or received. At this point that’s the most important information. Other information is related to the address-families, capabilities and more.

If you want to verify that the neighbors are up and if prefixes are being received then a simpler command you can use is show ip bgp summary. 

R3#show ip bgp summary 
BGP router identifier 10.10.34.3, local AS number 34
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.34.4      4           34      24      25        1    0    0 00:20:07        0

The above output from the show ip bgp summary command shows me that R3 has been peering with R4 for 20 minutes and zero prefixes have been received. I’m not advertising any networks so this makes sense. I’ll do the same thing on R4. 

R4#show ip bgp summary
BGP router identifier 10.10.34.4, local AS number 34
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.34.3      4           34      29      28        1    0    0 00:23:36        0

The show ip bgp summary output from R4 shows me precise information about the peering to R3. It’s been up for 23 minutes and zero prefixes are received. This confirms that the iBGP peerings are up. Now it’s time to configure eBGP peerings. 

2. Configure eBGP peerings between R1 and R3.

R1 and R3 need to peer using BGP. Because R1 is in a different AS than R3, that makes this an external BGP (eBGP) peering. 

R3:

router bgp 34
 neighbor 10.10.13.1 remote-as 1

R1:

router bgp 1
neighbor 10.10.13.3 remote-as 34
The locally configured BGP process number (AS number) and the one used in the neighbor statement are different, that makes this an eBGP peering.

After a few moments a message pops up letting me know the neighbors are up. 

R3:

%BGP-5-ADJCHANGE: neighbor 10.10.13.1 Up

R1:

%BGP-5-ADJCHANGE: neighbor 10.10.13.3 Up

Excellent, I’ll verify this by using the show ip bgp summary command. 

R3#sh ip bgp summary
BGP router identifier 10.10.34.3, local AS number 34
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.13.1      4            1       8       8        1    0    0 00:03:53        0
10.10.34.4      4           34      49      50        1    0    0 00:42:56        0

The above show ip bgp summary output on R3 shows me a summary of what I really care about. And that is the peering with R1 is up and has been for almost 4 minutes. 

R1#sh ip bgp summary
BGP router identifier 10.10.13.1, local AS number 1
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.13.3      4           34       8       8        1    0    0 00:03:58        0

The same command done on R1 shows me it’s peering to R3 is up, and has been for almost 4 minutes. The amount of prefixes says zero because no networks are actually being advertised. 

3.Configure eBGP peerings between R2 and R3.​

The last peering we need to do is the one between R2 and R3. I’ll start on R3. 

R3:

router bgp 34
 neighbor 10.10.23.2 remote-as 2

R2:

router bgp 2
 neighbor 10.10.23.3 remote-as 34

After a few moments I see SYSLOG messages pop up telling me the neighbors are up. 

R3:

%BGP-5-ADJCHANGE: neighbor 10.10.23.2 Up

R2:

%BGP-5-ADJCHANGE: neighbor 10.10.23.3 Up

Perfect, so far everything is looking good. Let me verify the peerings by using the show ip bgp summary command. 

R3#sh ip bgp summary 
BGP router identifier 10.10.34.3, local AS number 34
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.13.1      4            1      22      22        1    0    0 00:16:49        0
10.10.23.2      4            2       7       5        1    0    0 00:03:26        0
10.10.34.4      4           34      64      65        1    0    0 00:55:52        0

The above output shows me the peering from R3 towards R2 is up and has been for about 3.5 minutes. 

R2#sh ip bgp summary 
BGP router identifier 10.10.23.2, local AS number 2
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.23.3      4           34       5       7        1    0    0 00:03:35        0

The same show command done on R2 shows me that its peering to R3 has been up for about 3.5 minutes. That’s really all there is to it when it comes to configuring iBGP and eBGP peerings. If the locally configured AS number and the one used in the neighbor statement are the same then it’s an iBGP peering. If they’re different than its an eBGP peering. 

The last thing I want to mention is that you can only configure a single AS number on a router. Here’s what happens if you try. 

R4(config)#router bgp 34
R4(config-router)#router bgp 35
BGP is already running; AS is 34

I hope this tutorial on configuring iBGP and eBGP peerings was helpful. If you have any questions feel free to leave a comment below. 

EVE-NG Lab File

To download the EVE-NG topology file you'll need to be a member. You can register here. It will be right here once you log in.

Final Configs

Here are the final configs from all routers if you want to try it out yourself.

Discussion

You'll need to be a member if you want to participate in the discussion. You can register right here. The discussion will be visible here once you log in.