From A to B

Communication Process

A fundamental distinction exists between external (eBGP) and internal BGP (iBGP) peering. iBGP peering takes place within the same autonomous system (e.g., to exchange prefixes between two BGP routers connected to different carriers). eBGP peering takes place between different autonomous systems, as in the previous example.

However, the two types of BGP differ in terms of implementation, as can be seen, for example, in the multihop function, where the time to live (TTL) is influenced by the IP header. Several hops to the peer can be the default for iBGPs. With eBGP, you need to configure this explicitly to support peers located on different subnets. In this case, the TTL counter is incremented to reach the peer.

The handling of the next-hop IP address is also different. With eBGP, the router always transmits the IP address of the outbound interface as the next hop in the accessibility information, and the receiving router replaces this with the outbound IP address of the interface it used during redistribution. With iBGP, the IP address is adopted without change on forwarding. However, this address must also be accessible for the target peer. If it is not, you can configure the next-hop self parameter to achieve the same behavior as with eBGP.

BGP uses connection-oriented TCP on port 179 as the transport protocol, which must be allowed on the transmission path. When establishing peering, the connection setup goes through different phases (Figure 2). The idle phase begins with the idle status. Then a TCP three-way handshake with the familiar SYN, SYN/ACK, ACK is used in the connect phase. If this is successful, the OpenSent phase is used to synchronize BGP information such as ASNs and authentication data, which is normally followed by the OpenConfirm phase, in which the peers wait for keep-alive messages. If successful, the Established phase is next, which is where peering is set up and the routers can exchange availability information.

Figure 2: The BGP peering process comprises six phases.

This process uses the interface on the routers that leads to the target IP address according to the routing table. To be able to cover scenarios with multiple paths without the risk of flapping (disconnection and reconnection) of the BGP peering in the event of a path error, a permanently accessible IP address should be used as the source in such a case (Figure 3). To do this, permanently active loopback interfaces are used as update sources. These interfaces are then also stored on the remote station as peer addresses and included in the remote station's routing to be able to establish peering (Figure 4).

Figure 3: BGP peering with loopback interfaces avoid session flapping if a connection fails.

Figure 4: The ASN entry in the RIPE NCC test database shows the routing guidelines for import and export.

Avoiding Loops

Freedom from loops is one of the key requirements of any routing protocol. In BGP, this is based on the AS path – that is, a list of the transit ASs through which a packet has already passed. Each autonomous system adds its ASN starting with an eBGP peering (Figure 5). An ASN can occur several times in direct succession, but cannot be fragmented in different places. If the ASN is fragmented in the AS path, BGP drops this potential path, identifying it as a loop. To extend a path artificially, you have an option for concatenating the same ASN with an AS path prepend.

Figure 5: A simple example of the use of BGP route filters. These filters can be used for both inbound and outbound announcements.

Because iBGP only has one ASN for all participating routers, this procedure cannot be used here. To counter this, iBGP and eBGP behave differently when forwarding availability information. If an iBGP peer receives information, it only forwards it to eBGP peers, but not to other iBGP peers. eBGP peers in turn forward incoming reachability information to both eBGP and iBGP peers.

The iBGP's behavior leads to some design restrictions in iBGP, which can be countered with several tools. Normally, iBGP would require a full meshing of all peers. However, this does not scale well in larger environments. Confederations and route reflectors offer a remedy. Confederations are used to define subzones, but route reflectors are more common. When iBGP peers receive reachability information, the router forwards it to the eBGP peers and the route reflectors used for scaling, but not to the other iBGP peers.

Publishing Routes

Once the peering is in place, accessibility information needs to be exchanged, as well as the originating and redistributing options. With originating, you configure a network to be announced in your AS. The BGP router searches the routing table for a known path to this network; it can be known through static routes or dynamic routing protocols such as OSPF. If successful, the router transfers these networks to the BGP table.

During redistribution, you specify a source and a target routing process (e.g., from OSPF to BGP). On this basis, the router transfers all paths from one protocol to the other – in this case to the BGP table. However, prefix lists can impose restrictions. If you do not want to announce routes that are too small, you can combine these routes to create a summary route.

As mentioned previously, BGP uses attributes for path selection, which you can manipulate with the use of route maps. Table 1 lists the attributes in the order in which they are to be processed and with a description in each case.

Not all manufacturers use the Weight attribute, and it is only significant locally on a router for making outgoing route selections. With regard to the prefix, a higher weight for peering is preferred to a lower one. The Local Preference attribute is only exchanged between iBGP peers. For example, a preference for selecting the outgoing route via a specific peer can be established within an AS.

The Locally Originated attribute handles local routes before routes learned from BGP. The length of the AS Path (i.e., the list of the ASs to be passed through) is not checked until the next step. Routers prefer shorter paths. If a decision is not made on the basis of the AS Path Length, the Origin Code (i.e., the prefix source) is used. Local prefixes take precedence over prefixes learned from EGP, followed by redistributed paths.

The Multi Exit Discriminator (MED) attribute is only used for eBGP between two ASNs. Where several peering instances to the same AS exist, a router can use the MED to specify a preferred path in the return direction. In the next step, the router prefers the path with the better metric to the BGP next-hop in IGP, which is why BGP is still based on IGP. Because BGP is designed for stability, it would favor older entries over newer ones as the next path decision parameter. If a decision has not yet been made, the router compares the router ID of the next hop and gives priority to smaller numerical values. Something similar is also used as the last tie breaker. A lower numerical IP address is preferred over higher ones as a path.

These attributes show that BGP supports complex guidelines for route selection that make the protocol anything but easy to handle.