BGP Peering Explored

I had an opportunity to play around with GNS3 briefly today; configured eBGP.  I know a few things about the rules of an eBGP peering relationship from my past reading.  So today I was aiming to validate what I thought I understood.

I configured the following scenario:

Before starting up the BGP protocol and configuring the BGP peers, I configured a default gateway (Gateway of last resort on both sides of this WAN) in the end R1’s loopback was able to ping and vice-versa, all is perfect and well.

I configured everything else above ensuring that my update-source and multihop commands were not forgotten, asserting my self that this would be an easy breezy practice exercise.  When I was finished I went to check the neighbor peering state here is what i got:

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

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd         4   200       0       0        0    0    0 never    Active
R2#show ip bgp summary
BGP router identifier, local AS number 200
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd         4   100       0       0        0    0    0 never    Active

Nooo! No cigar… there is IP connectivity, so what are we missing? Well… I know that an exact route must be in place for a route to be advertised, so I inferred that adding specific routes on both sides should do the trick.  So i went to add a static route for on R1 first… to my surprise, setting up one side did the trick.  Here is what I saw:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#ip route
*Mar  1 00:20:36.119: %BGP-5-ADJCHANGE: neighbor Up
R1#show ip bgp
*Mar  1 00:20:43.955: %SYS-5-CONFIG_I: Configured from console by console
R1#show ip bgp summ
R1#show ip bgp summary
BGP router identifier, local AS number 100
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd         4   200       4       4        1    0    0 00:00:10        0

The bgp debugs on the other side confirm the handshake was successful:

R2#debug ip bgp

BGP debugging is on for address family: IPv4 Unicast
*Mar  1 00:20:35.803: BGP: passive open to
*Mar  1 00:20:35.807: BGP: went from Active to Idle
*Mar  1 00:20:35.807: BGP: went from Idle to Connect
*Mar  1 00:20:35.819: BGP: rcv message type 1, length (excl. header) 26
*Mar  1 00:20:35.819: BGP: rcv OPEN, version 4, holdtime 180 seconds
*Mar  1 00:20:35.819: BGP: went from Connect to OpenSent
*Mar  1 00:20:35.819: BGP: sending OPEN, version 4, my as: 200, holdtime 180 seconds
*Mar  1 00:20:35.823: BGP: rcv OPEN w/ OPTION parameter len: 16
*Mar  1 00:20:35.823: BGP: rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Mar  1 00:20:35.823: BGP: OPEN has CAPABILITY code: 1, length 4
*Mar  1 00:20:35.823: BGP: OPEN has MP_EXT CAP for afi/safi: 1/1
*Mar  1 00:20:35.823: BGP: rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar  1 00:20:35.827: BGP: OPEN has CAPABILITY code: 128, length 0
*Mar  1 00:20:35.827: BGP: OPEN has ROUTE-REFRESH capability(old) for all address-families
*Mar  1 00:20:35.827: BGP: rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar  1 00:20:35.827: BGP: OPEN has CAPABILITY code: 2, length 0
*Mar  1 00:20:35.827: BGP: OPEN has ROUTE-REFRESH capability(new) for all address-families
BGP: rcvd OPEN w/ remote AS 100
*Mar  1 00:20:35.831: BGP: went from OpenSent to OpenConfirm
*Mar  1 00:20:35.831: BGP: send message type 1, length (incl. header) 45
*Mar  1 00:20:35.867: BGP: went from OpenConfirm to Established
*Mar  1 00:20:35.867: %BGP-5-ADJCHANGE: neighbor Up

Interesting.  So you do not need to have exact routes in the routing table on both sides.  Oddly enough, you don’t even need to have the static routes in place after the TCP handshake is completed and the session is established.

R1(config)#no ip route
R1(config)#show ip route
% Invalid input detected at '^' marker.

R1(config)#do show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is to network is subnetted, 1 subnets
C is directly connected, Loopback0 is subnetted, 1 subnets
C is directly connected, Serial0/0
S* [1/0] via

R1(config)#do show tcp brief
TCB       Local Address               Foreign Address             (state)
64C9C5B0                      ESTAB

I set the the protocol to 2 second keepalives just to be double sure – and sure enough it stayed up.

R1(config-router)#timers bgp 2 20
*Mar  1 00:28:30.899: %SYS-5-CONFIG_I: Configured from console by console
R1#show ip bgp summ
R1#show ip bgp summary
BGP router identifier, local AS number 100
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd         4   200      12      12        1    0    0 00:08:01        0

R1#show ip bgp neighbors
BGP neighbor is,  remote AS 200, external link
  BGP version 4, remote router ID
  BGP state = Established, up for 00:08:22
  Last read 00:00:21, last write 00:00:21, hold time is 180, keepalive interval is 60 seconds
  Configured hold time is 20,keepalive interval is 2 seconds, Minimum holdtime from neighbor is 0 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:                  1          1
    Notifications:          0          0
    Updates:                0          0
    Keepalives:            11         11
    Route Refresh:          0          0
    Total:                 12         12

Lessons learned:
Lesson learned #1 – BGP peering requires a specific route (from the specific source initiating the TCP handshake) simply having IP connectivity or a gateway of  last resort is not sufficient for the neighbor peering to establish.  It only requires it on the side initiating the handshake, the replying device can have only a default route.
Lesson learned #2 – BGP peering does not require a specific route once the TCP session is established, that means the requirement for a specific route in the table doesn’t exist so long as the TCP session is established.
Lesson learned #3 – BGP bite you in the rear if you’re not patient and careful!

That’s all for today peeps.  Good fight and good nite!

Gabe @

BGP Quick Notes – Part 1

This is a dense facts review, this one is not meant for learning BGP for the first time; this post is meant to cover many of facts very quickly.  Without further delay…

Good choice if you connect to multiple ISPs.
If you need to control how traffic enters or exists your network.
If you need to react to Internet topology changes.

Three options for receiving BGP routes from an ISP:

• Default routes from each provider: Simple to configure, low bandwidth and light use of router resources.  The internal IGP metric determines the exit router for all traffic bound outside the autonomous system.  No BGP path manipulation is possible (can lead to suboptimal routing if you use more than one ISP).

Default routes plus some more specific routes: This option results in medium use of bandwidth and router resources.  It enables you to manipulate the exit path for specific routes using BGP so that traffic takes a shorter path to networks in each ISP.  Thus path selection is more predictable.  The IGP metric chooses the exit path for default routes.

• All routes from all providers: This requires the highest use of bandwidth and router resources.   Typically done by large enterprises and ISPs.  Path selection for all external routes can be controlled via BGP policy routing tools.


•  Single-homed: A site with a single ISP connection.  This is sufficient for a site that does not depend heavily on Internet or WAN connectivity.  Either use static routes, or advertise the site routes to the ISP and receive a default route from the ISP.

• Dual-homed: A site with two connections to the same ISP, either from one or two routers.  Designed with  loadbalancing or with a primary link and  a redundant backup.   Either static or dynamic routing would work with this type.

• Multihoming: A site connecting to more than one ISP at the same time for redundancy, and for better performance if one ISP provides a better path to frequently used networks.  Also gives an ISP-independent solution.  BGP is typically used with multihomed connections.

• Dual multihoming: Two connections to multiple ISPs.  This gives the most redundancy.  BGP is used with the ISPs, and can be used internally as well.


• BGP stands for Border Gateway Protocol.
• Routers running BGP are termed BGP speakers.
• BGP uses the concept of autonomous systems(AS).  An AS is a group of networks under a common administration.  IANA assigns AS.
• AS 1 to 64511 are public .  AS 64512 to 65535 are private.
• An AS will run an IGP within, and an EGP between AS.  BGPv4 is the only EGP currently in use.
• Routing between AS is coined interdomain routing.
The admin distance (AD) for EBGP routes is 20. AD for IBGP routes is 200.
• BGP neighbors are called peers and must be statically configured.
• BGP uses TCP 179.  BGP peers exchange incremental, triggered route updates and periodic keep alives.
• Routers can run only one instance of BGP at a time.
• BGP is a path-vector protocol.  The route to a network consists of a list of AS on the path to that network.
• BGP’s loop prevention mechanism is the AS number.  When an update about a network leaves an AS, that autonomous systems’s number is prepended to the list of AS.  If it finds its own AS number in that list, the update is discarded.
• Use BGP when AS is multihomed, when route path manipulation is needed, or when the AS is a transit AS.
• Do not use BGP in a single-homed AS, with a router that does not have sufficient resources to handle it, or with a staff that does not have a good understanding of BGP path selection and manipulation.

BGP uses 3 databases.  The first 2 are BGP specific, the 3rd is the one shared by all the routing processes on the router…

• Neighbor database:A list of all configured BGP neighbors.  To view it, use the show ip bgp summary command.

• BGP database, or RIB: A list of networks known by BGP, along with thier paths and attributes.  To view it, use show ip bgp command

• Routing table: The one seen with show ip route.


• Open: After a neighbor is configured, BGP sends an open message to try to establish peering.  The message includes AS, Router ID, and hold time.

• Update: Message used to transfer routing information between peers.  Includes new routes, withdrawn routes, and path attributes.

• Keepalive: BGP peers echange keepalives every 60 seconds by default.  These are used to maintain the peering session active.

• Notification: When a problem occurs that causes a router to end BGP peering, a notification message is sent to the neighbor, and the connection is closed.

Internal BGP (iBGP) is a peering relationship between routers in the same AS

External BPG (eBGP) is a peering relationship between routers in different AS.

Before any peering relationships will be formed a TCP session needs to be established.  There must be IP connectivity to the peer.

In this illustration, basic eBGP peering can be configured using the following commands :

RtrA(config)# Router bgp 65100
RtrA(config-rtr)#  neighbor remote-as 65300

RtrD(config)# Router bgp 65300
RtrD(config-rtr)#  neighbor remote-as 65100

If both routers are within a single AS.  The same commands (with the AS adjusted) would create an iBGP peering relationship.
By default, the next hop for a route recieved from an EBGP neighbor is the IP address of the neighbor that sent the update.   When this update is relayed to IBGP neighbors, the next hop attribute is not changed.  Therefore IBGP routers must have a route to that next hop IP. Consider the scenario below.

An update from RtrA to RtrB would have a next-hop attribute of  When RtrB passes the update to RtrC, the next hop will remain  If RtrC does not have a route to the update from RtrAwill be unusable by RtrC.  We can modify this rule by applying an additional neighbor command on RtrB:

RtrB(config-rtr)#  neighbor remote-as 65200
RtrB(config-rtr)#  neighbor next-hop-self

The next hop self will adjust the next hop attribute.  RtrC will recieve the update as if it had originated at RtrB – as a valid neighbor RtrC will necessarily have route to RtrB, and everything will work well :D.

Next-hop-self logic can also be to prevent extra hops on a Multiaccess Network.  (For example updates to RtrD about do not need to hop through  


The BGP synchronization rule requires that when a BGP router receives information about a network from an IBGP neighbor, it does not use that information until a matching route is learned via an IGP or static route.  IT also does not advertise that route to an EBGP neighbor unless a matching route is in the routing table.  In the topology below if RtrB advertices a route to RtrC, the RtrC does not submit it to the routing table or advertise it to RtrD unless it also learns the route from an IGP source.  If all routers in the Autonomous system are running BGP, it is usually safe to turn off synchronization.  The command would be    Rtr{all}(config-rtr)#no synchronization.


neighbor peer {group-name} peer group  Creates a peer group to which you can assign neighbors.  

• By default, members of the peer group inherit all the configuration options of the peer group. Members also can be configured to override the options that do not affect outbound updates.

All the peer group members will inherit the current configuration as well as changes made to the peer group. Peer group members will always inherit the following configuration options by default:

remote-as (if configured)
outbound route-maps
outbound filter-lists
outbound distribute-lists

BGP assumes neighbors are directly connected .  If they are not, we must specify in BGP to look more than one hop away for the neighbor.  We must apply the following command to the neighbor statement:
Rtr_(config-rtr)#neighbor {ip-address} ebgp-multihop {# of hops}

If we are peering with loopback interfaces, we need to specify the source of the BGP packets to match the loopback.  We would use this command:
Rtr_(config-rtr)#neighbor {ip-address} update-source {interface (ex. loopback 0} 

We can manually take down a peering session:  Rtr_(config-rtr)#neighbor {ip-address} shutdown.

In BGP, the network command tells the router to originate an advertisement for a network.  The network doesn’t have to be connected to the router; it just has to be in the routing table.

Rtr_(config-rtr)#network prefix mask subnet mask –    Initiates the advertisements


Check state using the show ip bgp summary or show ip bgp neighbors.  The status can include the following:

Idle: No peering; router is looking for neighbor.  Idle(admin) means the neighbor has been admin shut.

Connect: TCP handshake completed.

OpenSent, or Active: An open message was sent trying to establish the peering.

OpenConfirm: Router has received a reply to the open message.

Established:  Routers havea  BGP peering session.  This is the desired state.

And lets call that a wrap.   In the next post  we’ll review BGP attributes, Path selection, route filtering, confederations, route reflectors, authentication, and show command review for troubleshooting… well maybe over 2 or 3 more posts.

If you’re still here, you’re nuts! Thanks for reading! 😀


Gabe @