BGP Fundamentals


A router’s primary function is to move packets from one network to a different network. A router learns about unattached networks through static configuration or through dynamic routing protocols that distribute network topology information between routers. Routers try to select the best loop-free path in a network based on the destination network. Link flaps, router crashes, and other unexpected events could impact the best path, so the routers must exchange information with each other so that the network topology updates during these types of events.

  • RFC 1654 defines Border Gateway Protocol (BGP) as an EGP standardized path-vector routing protocol that provides scalability, flexibility, and network stability.
  • BGP uses the concept of autonomous systems.
    • An autonomous system is a group of networks under a common administration.
  • BGP neighbors are called peers and must be statically configured.
  • BGP routing with a peer in a different AS is called external BGP (eBGP). With a peer in the same AS it is called internal BGP (iBGP).
  • The administrative distance for eBGP routes is 20. The administrative distance for iBGP routes is 200.
  • BGP uses TCP port 179. BGP peers exchange incremental, triggered route updates and periodic keepalives.
  • Routers can run only one BGP process at a time. Switches with Virtual Device Contexts (VDC) can run one BGP process per VDC.
  • BGP’s loop prevention mechanism is an autonomous system number. When an update regarding a network leaves an autonomous system, that AS’s number is prepended to the list of autonomous systems that have handled that update. When a BGP router receives an update, it examines the AS list. If it finds its own autonomous system number in that list, the update is discarded.

Autonomous System Numbers

ASNs were originally 2 bytes (in the 16-bit range), which made 65,535 ASNs possible. Due to exhaustion, RFC 4893 expanded the ASN field to accommodate 4 bytes (in the 32-bit range). This allows for 4,294,967,295 unique ASNs, providing quite an increase from the original.

Two blocks of private ASNs are available for any organization to use as long as they are never exchanged publicly on the Internet.

  • 64,512–65,535 (16-bit range)
  • 4,200,000,000–4,294,967,294 (32-bit range)

Path Attributes

BGP attaches path attributes (PA) associated with each network path. The PAs provide BGP with granularity and control of routing policies within BGP. The BGP prefix PAs are classified as follows:

  • Well-known mandatory
  • Well-known discretionary
  • Optional transitive
  • Optional nontransitive

Well-known attributes must be recognized by all BGP implementations.

Well-known mandatory attributes must be included with every prefix advertisement, whereas well-known discretionary attributes may or may not be included with the prefix advertisement.

Optional attributes do not have to be recognized by all BGP implementations.

Optional attributes can be set so that they are transitive and stay with the route advertisement from AS to AS. Other PAs are nontransitive and cannot be shared from AS to AS.

In BGP, the Network Layer Reachability Information (NLRI) is the routing update that consists of the network prefix, prefix length, and any BGP PAs for that specific route.

Loop Prevention

BGP is a path vector routing protocol and does not contain a complete topology of the network-like link state routing protocols. BGP behaves similar to distance vector protocols to ensure a path is loop free.

The BGP attribute AS_PATH is a well-known mandatory attribute and includes a complete listing of all the ASNs that the prefix advertisement has traversed from its source AS. The AS_PATH is used as a loop prevention mechanism in the BGP protocol. If a BGP router receives a prefix advertisement with its AS listed in the AS_PATH, it discards the prefix because the router thinks the advertisement forms a loop.

Address Families

Originally, BGP was intended for routing of IPv4 prefixes between organizations, but RFC 2858 added Multi-Protocol BGP (MP-BGP) capability by adding extensions called address-family identifier (AFI). An address-family correlates to a specific network protocol, such as IPv4, IPv6, and the like, and additional granularity through a subsequent address-family identifier (SAFI), such as unicast and multicast.

MBGP achieves this separation by using the BGP path attributes (PAs) MP_REACH_NLRI and MP_UNREACH_NLRI. These attributes are carried inside BGP update messages and are used to carry network reachability information for different address families.

Every address-family maintains a separate database and configuration for each protocol (address-family + subaddress family) in BGP. This allows for a routing policy in one address-family to be different from a routing policy in a different address family even though the router uses the same BGP session to the other router. BGP includes an AFI and a SAFI with every route advertisement to differentiate between the AFI and SAFI databases.

Inter-Router Communication

  • BGP does not use hello packets to discover neighbors, as do IGP protocols, and it cannot discover neighbors dynamically.
    • BGP neighbors are defined by an IP address.
  • BGP uses TCP port 179 to communicate with other routers.
    • TCP allows for handling of fragmentation, sequencing, and reliability (acknowledgement and retransmission) of communication packets.
  • IGP protocols follow the physical topology because the sessions are formed with hellos that cannot cross network boundaries (that is, single hop only). BGP uses TCP, which is capable of crossing network boundaries (that is, multihop capable). While BGP can form neighbor adjacencies that are directly connected, it can also form adjacencies that are multiple hops away. Multihop sessions require that the router use an underlying route installed in the RIB (static or from any routing protocol) to establish the TCP session with the remote endpoint.

BGP neighbors connected via the same network use the ARP table to locate the Layer 2 address of the peer. Multihop BGP sessions require route table information for finding the IP address of the peer. It is common to have a static route or IGP running between IBGP neighbors for providing the topology path information for establishing the BGP TCP session. A default route is not sufficient to form a multihop BGP session.

BGP can be thought of as a control plane routing protocol or as an application, because it allows for the exchanging of routes with peers multiple hops away. BGP routers do not have to be in the data plane (path) to exchange prefixes, but all routers in the data path need to know all the routes that will be forwarded through them.

BGP Direct and Multihop Sessions

BGP Sessions

A BGP session refers to the established adjacency between two BGP routers. BGP sessions are always point-to-point and are categorized into two types:

  • IBGP: Sessions established with an IBGP router that are in the same AS. AD of 200.
  • EBGP: Sessions established with a BGP router that are in a different AS. AD of 20.

Administrative distance (AD) is a rating of the trustworthiness of a routing information source. If a router learns about a route to a destination from more than one routing protocol, and they all have the same prefix length, AD is compared. The preference is given to the route with the lower AD.

BGP Next-Hop Significance

  • BGP is not a routing protocol
    • BGP is an application used to exchange NLRI
    • E.g. the route details but not the path details
  • IPv4 NLRI contains…
    • Prefix/len
    • Attributes
      • Local Pref, AS_PATH, etc.
    • Next-hop
  • BGP Next-Hop controls IGP route recursion
    • I.e. BGP knows the next-hop but not the outgoing interface
    • IGP must be able to perform recursion otherwise the route cannot be used
  • Result of failed next-hop recursion is failed bestpath selection
    • I.e. the route is not installed in RIB or advertised
  • Why do we care?
    • Different peerings have different next-hop processing rules

IBGP Next-Hop Processing

  • By default…
    • Outbound iBGP updates do not modify the next-hop attribute regardless of iBGP peer type
  • Can be modified
    • neighbor next-hop-self
    • route-map action set ip next-hop
    • As of 15.1(1)SY, next-hop-self ALL for inserting RR in the data-path
      • Used in Unified MPLS design

EBGP Next-Hop Processing

  • By default…
    • the router changes the next hop attribute of a BGP route (to its own address) when the router sends out a route.
    • E.g. if update-source is Loopback0, next-hop is Loopback0
  • Can be modified
    • route-map action set ip next-hop
    • neighbor next-hop-unchanged
    • E.g. “Third Party” next-hop
    • Limited corner case applications


  • Default TTL 255.
    • Implies neighbors do not have to be connected as long as IGP reachability exists.
  • IBGP peers typically peer via loopbacks.
    • Allowing rerouting around failed paths via IGP.
    • Required for some application such as MPLS L3VPN

IBGP Loop Prevention

  • IBGP learned routes cannot be advertised to another IBGP peer.
  • Implies IBGP requires either..
    • Fully meshed IBGP peering
    • RRs
    • Confederations

IBGP Full Mesh Requirement

It was explained earlier in this chapter how BGP uses the AS_PATH as a loop detection and prevention mechanism because the ASN is prepended when advertising to an EBGP neighbor. IBGP peers do not prepend their ASN to the AS_PATH, because the NLRIs would fail the validity check and would not install the prefix into the IP routing table.

No other method exists to detect loops with IBGP sessions, and RFC 4271 prohibits the advertisement of a NLRI received from an IBGP peer to another IBGP peer. RFC 4271 states that all BGP routers within a single AS must be fully meshed to provide a complete loop-free routing table and prevent traffic blackholing.


  • R1, R2, and R3 are all within AS65100.
  • R1 has an IBGP session with R2, and R2 has an IBGP session with R3.
  • R1 advertises the prefix to R2, which is processed and inserted into R2’s BGP table.
  • R2 does not advertise the NLRI to R3 because it received the prefix from an IBGP peer.
  • To resolve this issue, R1 must form a multihop IBGP session so that R3 can receive the prefix directly from R1.
    • R1 connects to R3’s IP address, and R3 connects to R1’s IP address.
    • R1 and R3 need a static route to the remote peering link, or R2 must advertise the and network into BGP.
IBGP Prefix Advertisement Behavior

Peering via Loopback Addresses

BGP sessions are sourced by the outbound interface toward the BGP peers IP address by default.

Imagine three routers connected via a full mesh. In the event of a link failure on the R1-R3 link, R3’s BGP session with R1 times out and terminates. R3 loses connectivity to R1’s networks even though R1 and R3 could communicate through R2 (multihop path). The loss of connectivity occurs because IBGP does not advertise routes learned from another IBGP peer.

Two solutions exist to overcome the link failure:

  1. Add a second link between all routers (3 links will become 6 links) and establish two BGP sessions between each router.
  2. Configure an IGP protocol on the routers’ transit links, advertise loopback interfaces into the IGP, and then configure the BGP neighbors to establish a session to the remote router’s loopback address.

Of the two methods, the second is more efficient and preferable.

The loopback interface is virtual and always stays up. In the event of link failure, the session remains intact while the IGP finds another path to the loopback address and, in essence, turns a single-hop IBGP session into a multihop IBGP session.

Updating the BGP configuration to set the destination of the BGP session to the remote router’s loopback IP address is not enough. The source IP address of the BGP packets will still reflect the IP address of the outbound interface. When a BGP packet is received, the router correlates the source IP address of the packet to the BGP neighbor table. If the BGP packet source does not match an entry in the neighbor table, the packet cannot be associated to a neighbor and is discarded.

The source of BGP packets can be set statically to an interface’s primary IP address with the BGP session configuration command neighbor ip-address update-source interface-type interface-number on IOS nodes. IOS XR and NX-OS devices use the command update-source interface-type interface-number under the neighbor session within the BGP router configuration.

Below example illustrates the concept of peering using loopback addresses after the network link fails. R1 and R3 still maintain BGP session connectivity while routes learned from OSPF allow BGP communication traffic between the loopbacks via R2. R1 can still forward packets to R3 via R2 because R1 performs a recursive lookup to identify R2 as the next-hop address.

Note: Sourcing BGP sessions from loopback interfaces eliminates the need to recompute the BGP best path algorithm if a peering link fails. It also provides automatic load balancing if there are multiple equal cost paths via IGP to the loopback address.

Link Failure with IBGP Sessions on Loopback Interfaces


  • TTL on EBGP packets default to 1
    • Can be modified if peers are multiple hops away.
      • neighbor ebgp-multihop [ttl]
      • neighbor ttl-security hops [ttl]
  • The advertising router modifies the BGP next-hop to the IP address sourcing the BGP connection.
  • Non-multihop peers must be directly connected by default
    • BGP packets drop in transit if a multihop BGP session is attempted. (TTL on IBGP packets is set to 255, which allows for multihop sessions).
    • Can be modified if connected peers via loopbacks.
    • neighbor disable-connected-check

EBGP Loop Prevention

The receiving router verifies that the AS_PATH doesn’t contain the local ASN. BGP discards the NLRI if it fails the AS_PATH loop prevention check.

  • The advertising router prepends its ASN to the existing AS_PATH.
    • Local ASN prepended to outbound updates.
  • Loop prevention via AS_PATH.
  • Inbound updates containing local ASN are discarded.
    • Can be modified with neighbor allowasn-in or as-override

Leave a Reply

Related Post

BGP PacketsBGP Packets

BGP uses a variety of messages for establishing the connection, exchanging routing information, checking if the remote BGP neighbor is still there and/or notifying the remote side if any errors