Border Gateway Protocol (BGP)

Introduction

Border Gateway Protocol is an Exterior Gateway Protocol (EGP) used for routing between the autonomous systems. It is the protocol which is used to to make core routing decisions on the internet. BGP has two flavours, eBGP and iBGP. eBGP is routing between the autonomous systems and iBGP is routing within an autonomous systems. BGP is a path-vector routing protocol and has following features:

• Reliable updaes (TCP -based, port 179)
• Triggered updates only
• Rich metric
• Scalable to massive networks

 Specifications
             Protocol Type              Path-vector
                   eBGP AD              20
                    iBGP AD              200
              Update Mode              Triggered only
                    Transport              TCP/179
             Authentication              None, md5
                           RFC              RFC 4271

Default Timers
                      Holddown time      180 seconds
                  Keepalive interval           60 seconds
 Advertisement interval (iBGP)          5 seconds
Advertisement interval (eBGP)          30 seconds

BGP Path Attributes
BGP metrics attached to a BGP route are called 'Path attributes'. BGP path attributes are categorized as 'Well-known' and 'Optional'.

BGP Path Attributes

► Well -known: Well-known attributes must be recognized by all compliant BGP implementations. All well-known attributes are propagated to other neighbors. Well-known attributes are mandatory or discretionary.

■ Mandatory well-known attributes must be present in all update messages

• Next-hop: IP address of the next-hop router
• AS-path: Sequence of AS numbers through which the network is accessible.
• Origin: Origin of BGP route

                       •  i   Route originated in an IGP

                       •  e  Route originated in EGP

                       •  ?  Route was redistributed into BGP

■ Discretionary well-known attributes must be supported by all BGP implementations, but do not have to be present in all BGP updates.

• Local preference: Used for consistent routing policy within AS.
• Atomic aggregate: Informs the router that the route has been summarized. 

► Optional: Optional attributes may or may not be recognized by all BGP implementation. Optional BGP attributes are transitive or non-transitive.

■ Transitive optional attributes are propagated to other neighbors even if not recognized. (partial bit set to indicate that the attribute was not recognized) 

• Aggregator: Specifies the IP address and AS number of the router that performed route aggregation.
• Community:  Used for route tagging.

■ Non-Transitive optional attributes are discarded if not recognized.

• Multi-Exit Discriminator: Used to discriminate between multiple entry points to a single AS.

Order of preference of attributes in BGP
The order of preference varies based on whether the attributes are applied for inbound updates or outbound updates.
For inbound updates the order of preference is:

• route-map
• filter-list
• prefix-list, distribute-list

For outbound updates the order of preference is:

• prefix-list, distribute-list
• filter-list
• route-map

NOTE: The attributes prefix-list and distribute-list are mutually exclusive, and only one command (neighbor distribute-list or neighbor prefix-list) can be applied to each inbound or outbound direction for a particular neighbor.

Route injection in BGP process
The BGP process injects local routes in two different ways:

• Using the Network configuration command.
• Using redistribution.

Network command works differently in BGP as compared to other routing protocols like OSPF. When we use network command in OSPF, it does the following two functions.                                                                                                                                                              

• Sends hello on those interfaces.
• Advertise the network of those interfaces that matches that network statement.

For example, an interface of a router has an IP address 192.0.2.1/29. If we issue the command network 192.0.2.0 0.0.255.255, the OSPF process will identify all those interfaces which have IP address starting with 192.0.X.X and start sending hello packets out those interfaces to discover neighbors. Second, the OSPF process will start advertising the network of those interfaces. In this case, OSPF will advertise the network 192.168.2.0/29.

In BGP, when we issue the network command, the BGP process will look into the routing table for the exact match of route and advertises that network. For example, if we issue the command network 192.0.2.0 255.255.255.0, the BGP process looks into routing table and search for the route 192.168.2.0/24. If BGP process finds the route to the destination network in the routing table, then only it will advertise that route otherwise that network statement has no effect.
A discard route also works for advertising a network into BGP. Suppose your router does not have route to 192.0.2.0/24, but still you want to advertise that network (why would you do so?), you can make it work by adding the following route.

ip route 192.0.2.0 255.255.255.0 Null0

BGP Synchronization rule
A BGP router with synchronization enabled does not install iBGP learned routes into it's routing table if it is not able to validate those routes in its IGP. Issue the no synchronization command under router bgp in order to disable synchronization. This prevents BGP from validating iBGP routes in IGP.

no synchronization

BGP Split-horizon rule
Routes learned via iBGP will never be advertised to another iBGP peer.
There are three ways to overcome this rule:

1. create a full mesh topology between iBGP peers.
2. route-reflectors
3. confederations

BGP Next-hop Processing
For eBGP peers: Change next-hop address on advertised routes.
For iBGP peers: Do not change next-hop address on advertised routes.
To overcome this rule, following command can be used under BGP process:

neighbor x.x.x.x next-hop-self

Establishing eBGP neighbors
Unlike iBGP neighbor relationships, eBGP neighbors must be directly connected by default. Routers sets the TTL of packets carrying BGP messages to 1, unless the ebgp-multihop is configured.

For example, if we want to establish eBGP neighbor relationship between Router1 and Router2 (image 1(a)) using the loopback IP address configured, we can use the following command:

neighbor x.x.x.x disable-connected-check

image 1(a)

In addition to the disable-connected-check command, we'll also have to use the following command so that the BGP messages are sent with the source IP address of loopback inerface.

neighbor x.x.x.x update-source loopback0

In the above example, we can also use the command neighbor x.x.x.x ebgp-multihop, which will set the TTL of packets carrying BGP messages to 255 and the router automatically and implicitly behaves to the neighbor as if the disable-connected-check was configured. The genuine use of ebgp-multihop is when we want to establish eBGP neighbor relationships through the routers.
For example, if we want to establish eBGP neighbor relationship between Router1 and Router2 (image 1(b)), we can use the following command:

 neighbor x.x.x.x ebgp-multihop 2

This command will set the TTL of packets carrying BGP messages to 2. If we leave the command without specifying maximum hop count, it will defaults to 255.

image 1(b)

BGP Message Types
Four BGP message types are specified in RFC 1771.

1. Open: Opens a BGP communication session between peers and is the first message sent by each side.
2. Update: Used to provide routing updates to other BGP systems.
3. Notification: Sent when an error condition is detected.
4. Keep-alive: Notifies BGP peers that a device is active.

 BGP Neighbor States
When BGP is configured with a neighbor IP address, it goes through a series of stages before it reaches the desired Established state in which BGP has negotiated all the required parameters and is willing to exchange BGP routes. BGP goes through the following stages of neighbor relationship:

Idle State:

• Refuse all incoming BGP connections.
• Start the initialization of event triggers.
• Initiates a TCP connection with its configured BGP peer.
• Listens for a TCP connection from its peer.
• Changes its state to Connect.
• If an error occurs at any state of the process, the BGP session is terminated immediately and returned to the Idle state. Some of the reasons why a router does not progress from the Idle state are:
• TCP port 179 is not open.
• A random TCP port over 1023 is not open.
• Peer address configured incorrectly on either router.
• AS number configured incorrectly on either router .

 Connect State:

• Waits for successful TCP negotiation with peer.
• BGP does not spend much time in this state if the TCP session has been successfully established.
• Sends Open message to peer and changes state to OpenSent.
• If an error occurs, BGP moves to the Active state. Some reasons for the error are:
• TCP port 179 is not open.
• A random TCP port over 1023 is not open.
• Peer address configured incorrectly on either router.
• AS number configured incorrectly on either router.

 Active State:

• If the router was unable to establish a successful TCP session, then it ends up in the Active state.
• BGP tries to restart another TCP session with the peer and, if successful, then it sends an Open message to the peer.
• If it is unsuccessful again, the FSM is reset to the Idle state.
• Repeated failures may result in a router cycling between the Idle and Active states. Some of the reasons for this include:
• TCP port 179 is not open.
• A random TCP port over 1023 is not open.
• BGP configuration error.
• Network congestion.
• Flapping network interface.

OpenSent State:

• BGP FSM listens for an Open message from its peer.
• Once the message has been received, the router checks the validity of the Open message.
• If there is an error it is because one of the fields in the Open message does not match between the peers, e.g., BGP version mismatch, MD5 password mismatch, the peering router expects a different My AS, etc. The router then sends a Notification message to the peer indicating why the error occurred.
• If there is no error, a Keepalive message is sent, various timers are set and the state is changed to OpenConfirm.

OpenConfirm State:

• The peer is listening for a Keepalive message from its peer.
• If a Keepalive message is received and no timer has expired before reception of the Keepalive, BGP transitions to the Established state.
• If a timer expires before a Keepalive message is received, or if an error condition occurs, the router transitions back to the Idle state.

 Established State:

• In this state, the peers send Update messages to exchange information about each route being advertised to the BGP peer.
• If there is any error in the Update message then a Notification message is sent to the peer, and BGP transitions back to the Idle state.
• If a timer expires before a Keepalive message is received, or if an error condition occurs, the router transitions back to the Idle state.