Configuring BGP

Table 6-1 lists the basic BGP configuration commands and their functions.


The BGP Network Command
In most IGPs, the network command starts the routing process on an interface. In BGP, the command tells the router to originate an advertisement for that network. The network does not have to be connected to the router; it just has to be in the routing table. In theory, it could even be a network in a different autonomous system (not usually recommended).

When advertising a network, BGP assumes you are using the default classful subnet mask. If you want to advertise a subnet, you must use the optional keyword mask and specify the subnet mask to use. Note that this is a subnet mask, not the inverse mask used by OSPF and EIGRP network statements. The routing table must contain an exact match (prefix and subnet mask) to the network listed in the network statement before BGP will advertise the route.


BGP Peering
BGP assumes that external neighbors are directly connected and that they are peering with the IP address of the directly connected interface of their neighbor. If not, you must tell BGP to look more than one hop away for its neighbor, with the neighbor ip-address ebgp-multihop number-of-hops command. You might use this command if you are peering with loopback interface IP addresses, for instance. BGP assumes that internal neighbors might not be directly connected, so this command is not needed with IBGP.

BGP Peering States
The command show ip bgp neighbors shows a list of peers, and the status of their peering session. This status can include the following states:

• Idle—No peering; router is looking for neighbor. Idle (admin) means that the neighbor relationship has been administratively shut down.
• Connect—TCP handshake completed.
• OpenSent, or Active—An open message was sent to try to establish the peering.
• OpenConfirm—Router has received a reply to the open message.
• Established—Routers have a BGP peering session. This is the desired state.

You can troubleshoot session establishment with debug commands. Use debug ip bgp events or debug ip bgp ipv4 unicast (in IOS versions 12.4 and up) to see where the process fails. Some common failure causes include AS number misconfiguration, neighbor IP address misconfiguration, neighbor with no neighbor statement for your router, and neighbor with no route to the source address of your router’s BGP messages.


BGP Path Selection
IGP, such as EIGRP or OSPF, choose routes based on lowest metric. They attempt to find the shortest, fastest way to get traffic to its destination. BGP, however, has a very different way of route selection. It assigns various attributes to each path; these attributes can be administratively manipulated in order to control the path that is selected. It then examines the value of these attributes in an ordered fashion until it is able to narrow all the possible routes down to one path.


BGP Attributes
BGP chooses a route to network based on the attributes of its path. Four categories of attributes exist:

• Well-known mandatory—Must be recognized by all BGP routers, present in all BGP updates, and passed on to other BGP routers. For example, AS path, origin, and next hop.
  

• Well-known discretionary—Must be recognized by all BGP routers and passed on to other BGP routers, but need not be present in an update. For example, local preference.
  

• Optional transitive—Might or might not be recognized by a BGP router, but is passed on to other BGP routers. If not recognized, it is marked as partial. For example, aggregator, community.
  

• Optional nontransitive—Might or might not be recognized by a BGP router and is not passed on to other routers. For example, Multi-Exit Discriminator (MED), originator ID.

Table 6-2 lists common BGP attributes, their meanings, and their category.


Influencing BGP Path Selection
BGP was not created to be a fast protocol; it was created to allow as much administrative control over route path selection as possible. Path selection is controlled by manipulating BGP attributes, usually using route maps. You can set a default local preference by using the command bgp default local-preference and a default MED for redistributed routes with the default-metric command under the BGP routing process. But by using route maps, you can change attributes for certain neighbors only or for certain routes only. This is higher than the default local preference of 120, so routers within the AS are more likely to prefer that path than others.

Route maps can also be applied to routes sent to or received from a neighbor. The following example shows a simple route map that sets MED on all routes advertised out to an EBGP neighbor:

route-map MED permit 10
set metric 50
!
router bgp 65001
neighbor 10.1.1.1 route-map MED out

When attributes are changed, you must tell BGP to apply the changes. Either clear the BGP session (clear ip bgp * ) or do a soft reset (clear ip bgp * soft in | out). Routers using recent IOS versions will do a route refresh when the session in cleared inbound.


BGP Path Selection Criteria
BGP tries to narrow its path selection down to one best path; it does not load balance by default. To do so, it examines the path attributes of any loop-free, synchronized (if synchronization is enabled) routes with a reachable next-hop in the following order:

1. Choose the route with the highest weight.
2. If weight is not set, choose the route with the highest local preference.
3. Choose routes that you advertise.
4. Choose the path with the shortest autonomous system path.
5. Choose the path with the lowest origin code (i is lowest, e is next, ? is last).
6. Choose the route with the lowest MED, if the same autonomous system advertises the possible routes.
7. Choose an eBGP route over an iBGP route.
8. Choose the route through the nearest IGP neighbor.
9. Choose the oldest route.
10. Choose a path through the neighbor with the lowest router ID.
11. Choose a path through the neighbor with the lowest IP address.

To enable BGP to load balance over more than one path, you must enter the command maximum-paths number-of-paths. BGP can load balance over a maximum of six paths.

BGP

• BGP stands for Border Gateway Protocol.
• BGP uses the concept of autonomous systems. An autonomous system is a group of networks under a common administration.
• Autonomous systems run Interior Gateway Protocols (IGP) within the system. They run an Exterior Gateway Protocol (EGP) between them.
• BGP version 4 is the only EGP currently in use.
• BGP neighbors are called peers and must be statically configured.
• BGP uses TCP port 179.
• BGP is a path-vector protocol. Its route to a network consists of a list of autonomous systems on the path to that network.
• BGP’s loop prevention mechanism is autonomous system number.

When an update about a network leaves an autonomous system, that autonomous system’s number is prepended to the list of autonomous systems that have handled that update. When an autonomous system receives an update, it examines the autonomous system list. If it finds its own autonomous system number in that list, the update is discarded.

In Figure 6-1, BGP routers in AS 65100 see network 10.1.1.0 as having an autonomous system path of 65200 65300 65400.

Multihoming
Multihoming means connecting to more than one ISP at the same time. It is done for redundancy and backup in case one ISP fails and for better performance if one ISP provides a better path to often used networks. Three ways exist to receive routes from each ISP:

• Default routes from each provider—This results in low use of bandwidth and router resources. The internal network’s IGP metric determines the exit router for all traffic bound outside the autonomous system.
• Default routes plus some more specific routes—This results in medium use of bandwidth and router resources. This allows you to manipulate the exit path for specific routes using BGP, but the IGP metric chooses the exit path for default routes.
• All routes from all providers—This requires the highest use of bandwidth and router resources. It is typically done by large enterprises and ISPs. Path selection for all external routes can be controlled via BGP policy routing tools.

BGP Databases
BGP uses three databases. The first two listed are BGP-specific; the third is shared by all routing processes on the router:

• Neighbor database—This is a list of all configured BGP neighbors. To view it, use the show ip bgp summary command.
• BGP database, or RIB (Routing Information Base)—This is a list of networks known by BGP, along with their paths and attributes. To view it, use the show ip bgp command.
• Routing table—This is a list of the paths to each network used by the router, and the next hop for each network. To view it, use the show ip route command.

BGP Message Types
BGP has four types of messages:

• Open—After a neighbor is configured, BGP sends an open message to try to establish peering with that neighbor. Includes information such as autonomous system number, router ID, and hold time.
• Update—Message used to transfer routing information between peers.
• Keepalive—BGP peers exchange keepalive messages every 60 seconds by default. These keep the peering session active.
• Notification—When a problem occurs that causes a router to end the BGP peering session, a notification message is sent to the BGP neighbor and the connection is closed.

Internal and External BGP
Internal BGP (IBGP) is BGP peering relationship between routers in the same autonomous system. External BGP (EBGP) is BGP peering relationship between routers in different autonomous systems. BGP treats updates from internal peers differently than updates from external peers.

In Figure 6-2, routers A and B are EBGP peers. Routers B, C, and D are IBGP peers.
BGP Next Hop Selection
The next hop for a route received from an EBGP neighbor is the IP address of the neighbor that sent the update.

When a BGP router receives an update from an EBGP neighbor, it must pass that update to its IBGP neighbors without changing the nexthop attribute. The next-hop IP address is the IP address of an edge router belonging to the next-hop autonomous system. Therefore, IBGP routers must have a route to the network connecting their autonomous
system to that edge router. For example, in Figure 6-3, RtrA sends an update to RtrB, listing a next hop of 10.2.2.1, its serial interface. When RtrB forwards that update to RtrC, the next-hop IP address will still be 10.2.2.1. RtrC needs to have a route to the 10.2.2.0 network in order to have a valid next hop.

To change this behavior, use the neighbor [ip address] next-hop-self command in BGP configuration mode. In Figure 6-3, this configuration goes on RtrB. After you give this command, RtrB will advertise its IP address to RtrC as the next hop for networks from AS 65100, rather than the address of RtrA. Thus, RtrC does not have to know about the
external network between RtrA and RtrB (network 10.2.2.0).


BGP Next Hop on a Multiaccess Network
On a multi-access network, BGP can adjust the next-hop attribute to avoid an extra hop. In Figure 6-3, RtrC and RtrD are EBGP peers, and RtrC is an IBGP peer with RtrB. When C sends an update to D about network 10.2.2.0, it normally gives its interface IP address as the next hop for D to use. But because B, C, and D are all on the same multiaccess network, it is inefficient for D to send traffic to C, and C to then send it on to B. This process unnecessarily adds an extra hop to the path. So, by default, RtrC advertises a next hop of 10.3.3.3 (RtrB’s interface) for the 10.2.2.0 network. This behavior can also be adjusted with the neighbor [ip address] next-hop-self command.


BGP Synchronization Rule
The BGP synchronization rule requires that when a BGP router receives information about a network from an IBGP neighbor, it does not use that information until a matching route is learned via an IGP or static route. It also does not advertise that route to an EBGP neighbor unless a matching route is in the routing table. In Figure 6-3, if RtrB advertises a route to RtrC, then RtrC does not submit it to the routing table or advertise it to RtrD unless it also learns the route from some other IGP source.

Recent IOS versions have synchronization disabled by default. It is usually safe to turn off synchronization when all routers in the autonomous system run BGP. To turn it off in earlier IOS versions, use the command no synchronization under BGP router configuration mode.