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 @

2 thoughts on “BGP Quick Notes – Part 1

  1. Gabe, have you ever came across using ebgp multihop as an option for BGP peering in NSX. On a cisco router it’s straight forward however can you please advise how I can perform this on NSX?

    • Hi Mike,

      We’ve tested multihop eBGP on NSX for tenant connections vCloud Air. It doesn’t need to be enabled specifically. As long as the non-direct peer can be reached (via static route or default gateway), NSX edge will peer.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s