Route My World!

Neighbor Relationships

• BGP Peer = BGP Neighbor.
  • A BGP peer is a BGP speaker that is configured to form neighbor relationship with another BGP speaker for the purpose of directly exchanging BGP routing information with one another.
  • Any router running BGP is a BGP speaker.
• A BGP router forms a direct neighbor relationship with a limited number of other BGP routers.
  • The Internet represents tens of thousands of autonomous systems. It is virtually impossible for one router to have direct neighbor relationship with all the routers that run BGP.

External BGP Neighbors

• EBGP – BGP is running between routers in different AS.
• IGP is not run between EBGP neighbors.
• In order to successfully exchange routing updates between two routers, TCP on each side must successfully pass the TCP 3-way handshake before BGP session can be established.
  • The IP address used in the neighbor command must be reachable without using an IGP. The best way to accomplish this is:
    • Pointing to an address that is directly connected, which is generally the case.
    • Or, use static routes to that IP address.

Internal BGP Neighbors

• IBGP – When BGP is running between routers within the same AS.
• IBGP allows routers within the same AS to exchange BGP information and all routers have the same BGP routing information about the outside autonomous systems.
• As long as routers can reach each other in order to perform TCP handshake and set up the BGP neighbor relationship, it doesn’t matter how they are connected. They can be connected in by:
  • A directly connected network.
  • Static routes.
  • Internal routing protocol (e.g. RIP, OSPF, EIGRP, etc.)
• Because multiple paths generally exist within an AS to reach other routers, a loopback address is usually used in the BGP neighbor command to establish IBGP sessions.

IBGP is required on all routers in a transit path in order for IBGP route propagation to work properly.

IBGP in a Transit AS

• Border Gateway in ‘BGP’ was coined because BGP was originally intended to run along the borders of an AS, with the routers in the middle of the AS ignorant of the details of BGP. But it is no longer the case.
• Transit AS – An AS that routes traffic from one external AS to another external AS.
  • A typical transit AS is an ISP.
  • In the diagram below, AS 65102 routes traffic from AS 65101 to AS 65103. This makes AS 65102 a transit AS.

• All routers in a transit AS must have complete knowledge of external routes.
  • In theory, this goal can be accomplished by redistributing BGP into the IGP running on the edge routers.
  • The method of redistributing all BGP routes into an IGP is, however, not good practice. Because the current Internet routing table is extremely large, this method is simply impractical.
• The more practical method for creating complete transparency for all routing information in an AS is by running IBGP on all routers within the AS.

IBGP in a Nontransit AS

• Non-transit AS – An AS that does not pass routes between the ISPs.
  • A typical example is an organization that is multihoming with two ISPs.
• BGP specifies that routes learned through IBGP are never propagated to other IBGP peers.
  • This is a mechanism to prevent routing loops.
  • By default, each BGP speaker is assumed to have a neighbor statement for all other IBGP speakers in the AS. This makes it a full mesh IBGP.
  • The default assumption by all routers running BGP within an AS is that each BGP router exchanges IBGP information directly with all other BGP routers in the AS.
  • In a full mesh, when the BGP router receives a change update from an external AS, that BGP router for the local AS is responsible for updating all other IBGP neighbors of that change. All the other neighbors will not update their other IBGP neighbors because they will assume full-mesh topology, thus, all updates are sent only by the original sending IBGP neighbor.
  • If the sending IBGP neighbor is not fully meshed with other IBGP neighbors, there will be inconsistent routing tables and routing loops or routing black holes can occur.

Full Mesh is when all BGP speakers have a neighbor statement for all other IBGP speakers in the AS

BGP Partial-Mesh Example

• In this example, when Router B receives updates from Router A, B sends updates to Routers C & D. However, it doesn’t send it to Router E because it does not have IBGP neighbore relationship with E.
• C & D will not send updates to E because by design, they are expected to assume full mesh neighborship so that B will send the update to E.
• E does not learn of any networks through B and does not use Router B to reach any networks in AS 65101 or other autonomous systems behind AS 65101.

BGP Full-Mesh Example

• The above diagram shows a fully meshed BGP toplogy.
• When router A sends update to Router B. Router B replicates the updates to C, D, and E.
• Because Router A and Router E are not directly connected, OSPF (or whatever IGP is running) will be used to route the TCP segment containing the BGP update from Router A to Router E.
• In a fully meshed IBGP, each router assumes that every other internal router has a neighbor statement that points to each IBGP neighbor.

Example: BGP Not in All Routers

• In the example above, Routers A, B, E, and F are the only ones running BGP.
• Through an EBGP session, Router A advertises network 10.0.0.0 to Router B. Router B in turn advertises the network to Router E, using IBGP. E advertises it to Router F.
• If Router F tries to send packets to network 10.0.0.0 via router E, Router E will try to send the packet to its BGP peer, Router B.
  • But in order to reach Router B, the packets must go through Router C or D.
  • Because Routers C or D are not running BGP, they don’t have a route to network 10.0.0.0. Therefore the packets are discarded.
• Assuming Routers C or D have default routes to the exit points, B and E, when Router E sends the packets to E or D, there is a good chance that C or D will send it back to router E. In turn, router E will resend it back again, eventually creating a loop.
• In order to solve all these problems, BGP must be implemented on Routers C and D.

All routers in the path between IBGP neighbors within an AS, known as the transit path, must also be running BGP. These IBGP sessions must be fully meshed.

BGP Synchronization

BGP Synchronization Rule

The BGP synchronization rule states that if an AS provides transit service to another AS, BGP should not advertise a route until all of the routers within the AS have learned about the route via an IGP

The synchronization rule is best understood with an example:

• Consider the following scenario above:
  • In the above picture, Router C sends updates about network 170.10.0.0 to Router A.
  • Routers A and B are running IBGP, so Router B receives updates about network 170.10.0.0 via IBGP.
  • In order for Router B to reach network 170.10.0.0, it has to send the traffic through router E.
    • Router E has no knowledge of network 170.10.0.0 because Router A does not redistribute network 170.10.0.0 into an IGP that is running between them.
    • Therefore, traffic the Router B sends to network 170.10.0.0 via Router E is dropped.
  • If Router B advertises to AS 400 that it can reach 170.10.0.0 before Router E learns about the network via IGP, traffic coming from Router D to Router B with a destination of 170.10.0.0 will flow to Router E and be dropped.
• In the above scenario, the synchronization rule states that:
  • If an AS (such as AS 100) passes traffic from one AS to another AS, BGP should not advertise a route (route 170.10.0.0 in this case) before all routers within the AS (AS 100) have learned about the route via IGP.
  • In this case Router B waits to hear about network 170.10.0.0 via an IGP before it sens an update to Router D.
• There are cases where synchronization can be disabled to allow BGP to converge faster. However, this can result in dropped packets if the following conditions are not met before disabling:
  • Your AS does not pass traffic from one AS to another AS.
  • All the transit routers in the AS run BGP.
• In the past it was best practice to redistribute BGP into IGP running in an AS.
  • In this case, IBGP was not needed for all routers in the transit path. By default, synchronization was on to make sure packets did not get lost.
• As the Internet grew, it has become more and more impractical to redistribute every single prefix into the IGP, therefore best practice was changed to not redistributing BGP into the IGP.
  • This required using IBGP on all routers in the transit path. In this case, synchronization was no longer needed. Thus, it is now off by default.

Synchronization Rule

• Enable synchronization if there are routers in the BGP transit path in the AS that are not running BGP.
  • With synchronization on, BGP should not advertise a route before all routers in the AS have learned about the route via IGP.
  • A router learning a route via IBGP waits until the IGP has propagated the route within the AS and then advertises it to external peers.
• Disable synchronization if routers in the transit path in the AS are running full-mesh IBGP.
  • With synchronization off, BGP can use and advertise to external BGP neighbor routes learned form an IBGP neighbor that are not present in the local routing table.

TCP and Full Mesh

• Because of its ability to move a large volume of data reliably, TCP is an appropriate transport mechanism to use for BGP.
• As opposed to the one-to-one windowing capability of OSPF or EIGRP, TCP allows BGP to take advantage of its unique window scaling capability to handle a huge volume of traffic, such as the Internet routing table.
• TCP sessions cannot be multicast or broadcast because TCP has to ensure the delivery of packets to each recipient.
  • Because TCP cannot use broadcasting, BGP cannot use it either.

BGP Tables

• BGP keeps a separate table from the IP routing table.
• Some of the common nomenclature use to describe the BGP table are:
  • BGP Table
  • BGP topology table
  • BGP topology database
  • BGP routing table
  • BGP routing database
• The router can be configured to share information between the BGP table and the IP routing table.
• BGP also has a neighbor table containing a list of neighbors with which it has a BGP connection.
• BGP adjacency must be configured explicitly for each neighbor. A TCP relationship is formed with each configured neighbor.
  • To keep track of the adjacency state, a BGP/TCP keepalive message is sent every 60sec.
• After an adjacency is established:
  1. The neighbors exchange the BGP routes that are in their IP routing table.
     • Each router collects these routes from each neighbor with which it successfully established and adjacency and places them in its BGP forwarding database
  2. All routes that have been learned from each neighbor are placed in the BGP forwarding database.
  3. The best routes for each network are selected from the BGP forwarding database using the BGP route selection process.
  4. The best routes are offered to the IP routing table.
  5. Each router compares the offered BGP routes to any other possible paths to those networks in its routing table, and the best route, based on administrative distance, is installed in the IP routing table.
     • EBGP routes have an AD of 20.
     • IBGP routes have AD of 200.

BGP Message Types

• BGP defines the following message types:
  • Open
    • The first message sent by each side.
  • Keepalive
    • If the open message is acceptable, a keepalive message confirming the open message is sent back by the side that received the open message.
  • Update
    • When the open is confirmed, the BGP connections is established, and update, keepalive and notification messages can be exchanged.
  • Notification
    • These are sent in response to errors or special conditions.

BGP Message Type: Open

An open message includes the following information:

• Version – an 8-bit field that indicates the version of BGP. The highest common version that both routers support is used. Current version is BGP-4.
• My Autonomous System – A 16-bit field that indicates the sender’s AS number. The peer router verifies this information; if it is not the AS number expected, the BGP session is torn down.
• Hold Time – A 16-bit field indicating the maximum number of seconds that can elapse between the successive keepalive or update message from the sender. Upon receipt of an open message, the router calculates the value of the hold timer to use by using the smaller of its configured hold time and the hold time received in the open message.
• BGP Router Identifier (Router ID) – 32-bit field that indicates the BGP identifier. The BGP router ID is chosen the same way the OSPF ID is chosen:
  1. Statically configured
  2. Highest loopback Address
  3. Highest active IP Address
• Optional parameters - A length field indicates the total length of the optional parameters in octets. These parameters are Type, Length, and Value (TLV)-encoded.
  • Session authentication is one example.

BGP Message Type: Keepalive

• BGP does not use any transport protocol-based keepalive mechanism to determine whether peers can be reached.
• Instead, keepalive messages are exchanged between peers often enough to keep the hold timer from expiring.
  • If the negotiatied hold time interval is 0, periodic keepalive message are not sent.
• A keepalive message consists of only a message header.

BGP Message Type: Update

• An update message has information on one path only.
  • Multiple paths require paths require multiple messages.
  • All attributes in a message refer to that path, and the networks are those that can be reached through that path.
• An update message might include the following fields:
  • Withdrawn routes – A list of IP address prefixes for routes that are being withdrawn from service, if any.
  • Path attributes – The AS-path, origin, local preference, and so forth (will be disussed in next post).
    • The attribute type consists of the attribute flags, followed by the attribute type code.
  • Network layer reachability information – A list of IP address prefixes that can be reached by this path.

BGP Message Type: Notification

• A BGP router sends a notification message when it detects an error condition.
• The BGP router closes the BGP connection immediately after sending the notification message.
• Notification messages include an error code, and error subcode, and data related to the error.

BGP Neigbor States

• BGP is a state machine that takes a router through the following states with its neighbors:

• • Idle
  • Connect
  • Active
  • Open sent
  • Open confirm
  • Established
• Only when the connection is in the established states are update, keepalive, and notification messages are exchanged.

• Keepalive messages consist of only a message header and have a length of 19 bytes.
  • The are sent every 60 seconds by default.
  • Other messages might be between 19 and 4096 bytes long.
• The default hold time is 180 seconds.

Resources:

1. Cisco – Internetworking Case Studies Using the Border Gateway Protocol for Interdomain Routing
2. Synchronization – Using BGP for Interdomain Routing – Internetworking Case Studies – Cisco

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet; Routing TCP/IP, Volume 1 (2nd Edition) (CCIE Professional Development) by Jeff Doyle and Jennifer Carroll; as well as following the links on the resources section of this entry.