BGP Fundamentals

BGP is the protocol that makes the Internet work. It is based on Path-vector routing and is used for inter-domain routing between different Autonomous Systems (AS).

BGP AS numbers are 2 bytes fields that are allocated by IANA and range from 0 – 65535. RFC 4893 also discusses about 4-byte ASN ranging from 0 to 4294967296.

Before we delve into BGP Fundamentals, it is important to note that IANA (Internet Assigned Numbers Authority) is a department of ICANN (Internet Corporation for Assigned Names and Numbers) responsible for coordinating some of the key elements that keep the Internet running smoothly.

IANA’s various activities can be broadly grouped in to three categories:

  • Domain Names – IANA manages the DNS Root and other functions such as the .int and .arpa domains
  • Number Resources – IANA coordinates the global pool of IP and AS numbers, providing them to Regional Internet Registries
  • Protocol Assignments – Internet protocols numbering systems are managed by IANA in conjunction with standards bodies

Both IPv4 and IPv6 addresses are generally assigned in a hierarchical manner.

Users are assigned IP addresses by Internet service providers (ISPs). ISPs obtain allocations of IP addresses from a local Internet registry (LIR) or National Internet Registry (NIR) or from their appropriate Regional Internet Registry (RIR).

The IANA’s role is to allocate IP addresses from the pools of unallocated addresses to the RIRs according to their needs as described by global policy. When an RIR requires more IP addresses for allocation or assignment within its region, the IANA makes an additional allocation to the RIR.

Note that IANA does not make allocations directly to ISPs or end users except in specific circumstances such as allocations of multicast addresses or other protocol specific needs.

Reasons to Use BGP:

Whenever we want the world to know about us, we need to advertise the prefixes out to them.

When we share the information for some prefix, we actually build up the control plane. The control plane is always built upstream whereas the traffic i.e. the data plane flows downstream.

Let us talk about reasons to use BGP:

  • First of all, the main reason is scalability as BGP can handle thousands of thousands of routes that cannot be handled by IGPs
  • The Internet routing table never converges and BGP is stable enough to take care of that too
  • BGP uses route attributes unlike IGPs that use link-cost for routing decisions and hence traffic-engineering can be implemented easily

Transit vs Multi-Homed Networks:

  • Transit Network: It is a network where transit traffic flows through it. It needs full routing table to make accurate decisions and should not use default routing
  • Multi-homed networks are enterprise networks with two or more connections to ISPs. They allow control of inbound and outbound routing policy

Do we really need BGP?

How to make sure if we really need to run BGP? Well, following are scenarios wherein there is no need to have BGP in your network

  • Single ISP Connectivity – For such type of connectivity, only the default routing is sufficient
  • Limited Memory or CPU – The global table needs GBs of memory just for storage. In case you don’t have enough memory or CPU resources, there is no need to run BGP
  • IPv4 Address Space Ownership – If you don’t own your IPv4 addresses, BGP is not required as ISPs advertise the address space on your behalf

IMPORTANT: Can we implement BGP without IGP Protocol ? If yes, then how can we do it? If no, why?

One issue is network convergence, which is very slow with BGP. BGP timers are 60 (hold time) and 180 (dead time) seconds for Cisco, of course we could change those timers.

Other Issues – BGP valid routes are based on path selection which is more complex than simple metric of OSPF or EIGRP. Configuration-wise, setting up BGP as IGP is complex and challenging in contrast to IGP.

BGP concern is stability and works perfect in routing Internet routes where changes do not happen too often whereas IGPs are designed for speed, fast recovery, re-convergence, multi-path or load balancing traffic.

BGP Data Structure:

BGP uses 3 table data structure that is described as below:

  • Neighbor table
  • BGP table
  • IP Routing table

The neighbor table contains information about BGP peers. With BGP, we have to specify who are peers are (unlike other IGPs). Note that BGP neighbors does not need to be directly connected!

The BGP table is to advertise the routes to the control plane and the part of that control plane
information makes it to the routing table.

The routing table is responsible for forwarding of the traffic down to the destination network.

The BGP table contains all prefixes learned from all peers. If the same route from an IGP is also received along with BGP, then the AD becomes the decisive factor as to which of them makes way into the IP routing table.

How BGP works?

Following diagram would help in understanding BGP workflow in a much better way:

BGP Fundamentals

How does BGP form Peers?

To become neighbors, BGP uses TCP as layer 4 protocol (RIP borrows UDP). Other IGPs (OSPF and EIGRP) use their own layer 4 protocols.

IMPORTANT: “BGP always needs IGP underneath.”

BGP Packet Format

BGP peer establishment and maintenance use four types of packets that are stated below:

  • OPEN
  • KEEPALIVE
  • UPDATE
  • NOTIFICATION

Open message is saying “Hello” to the other peer
Peers announce their capabilities (such as VPNv4, route refresh) while Open messages are sent.

OPEN message includes BGP version, Local ASN, Local Router ID (the highest loopback address on the router when BGP begins (if not loopback, the highest IP on the physical interface), Hold time and other capabilities options.

If we hard-code the Router ID, we do need to worry about loopback or interface IP addresses as the manual assignment takes priority.

BGP Keepalive follows the same standard mechanism and is a method to allow the same TCP connection for the conversation instead of opening a new one with each new request. By default, the Keepalives are sent after every 60 seconds and the dead timer is 3 times of that.

The BGP UPDATE message includes:

  • Withdrawn routes – List of routes that should be discarded
  • NLRI – Routes that are advertised
  • Path vector attributes – Used for BGP best path selection

AS path is read from right to left as in the AS path. Note if the AS path is empty in BGP UPDATE message, it means we are advertising the network to our internal BGP peer.

BGP UPDATE also includes the Origin code, that is, how does a route gets into BGP. Origin codes are categorized as:

  • i – IGP
  • e – EGP
  • ? – Redistributed

For i (IGP), it means that somewhere BGP has used “network command” to get the route into BGP.

Lastly, BGP Notification message is used for error messages (any bad event).

The BGP session gets closed after the BGP Notification message. Some of the main reasons that can initiate this type of a message are unsupported version number, unacceptable hold timer or the hold timer expired.

BGP Peering States

Let us have a close look at different “states” when two BGP routers try to become neighbors.

  • Idle
    • This is the first state when both routers are waiting to start the 3-way handshake
  • Connect
    • BGP is waiting to complete 3-way handshake
  • Active
    • 3-way handshake failed, try again
  • OpenSent
    • 3-way handshake complete, OPEN message sent
  • OpenConfirm
    • OPEN message received, parameters agreed upon
  • Established
    • Peering complete.  The BGP neighbor adjacency is established and BGP peers will send update packets to exchange routing information

BGP Fundamentals


Resetting BGP Session

There are times such as link down when a route propagated in BGP doesn’t exist.

Since BGP takes quite a lot of time to converge, we often feel the need to clear the BGP table therefore. We can reset the BGP session by in two ways:

  • BGP Hard Reset – Resets the TCP connection
  • BGP Soft Reset – Just refreshes the BGP session

If we turn on debugging after doing the hard reset and see the result, we can easily notice the BGP peering states and also the optional capabilities.

If we manually shut down the BGP neighbor, we will have the state shown as: Idle (Admin).

Common BGP Troubleshooting Tools

  • Looking Glass Servers

Looking Glass servers are computers on the Internet running one of a variety of publicly available Looking Glass software implementations.

BGP looking glasses can be a great tool for troubleshooting and general information. Looking glasses give us a view into the BGP tables and routing tables of ISPs.

The looking glasses can be actual routers that anyone can telnet to and run “show” command or actual servers that understand IOS “show” commands.

Publicly accessible Looking Glass servers are run by ISPs or Internet Exchange Points (IXPs).

  •  BGP ASN Query Tool

Another good BGP tool is the BGP Autonomous System Number Query Tool. This is a nice tool to find out who owns a BGP AS number.

It is a handy tool to troubleshoot Internet routing issues, especially to international locations.

  • BGPlay

BGPlay is a Java application which displays animated graphs of the routing activity of a certain prefix within a specified time interval.

It is very user-friendly and the graphical output makes it easy to comprehend BGP updates.

In the next article, I will discuss the difference between BGP peering types, BGP Next-Hop Self and how do we get prefixes into BGP. In case of any queries or feedback, please drop a comment below and I would love to respond and help.

The following two tabs change content below.

Haider Khalid

IP MPLS & Enterprise Core Network Engineer, CCIE# 52939
Haider Khalid is an IP MPLS & Enterprise Core Network Engineer (CCIE# 52939) who has worked with several ISPs & Telecom operators in Pakistan, Middle East and the UK. He is always keen to learn new technologies and likes to share them with his peers and other people. In case of any questions or feedback, please feel free to drop a comment below or connect with him on LinkedIn.

Leave a Reply

Your email address will not be published. Required fields are marked *