Foundation Topics
Basic BGP Configuration Commands
BGP is designed to connect to neighboring autonomous systems. To do so, you must enable BGP, identify your AS, and identify your neighbors and their AS. Configurations also include commands to define the networks being advertised.
This section describes the generic commands used to implement BGP. Later sections then build on this basic configuration to discuss more complex topics.
Enabling BGP
Just like the other routing protocols, BGP is enabled with the router command. This same command is used to identify the AS of this router. The syntax is
Router(config)# router bgp autonomous-system-number
Identifying Neighbors and Defining Peer Groups
BGP does not promiscuously attach to other routers—neighbors must be predefined. The neighbor command is used to identify each neighbor and its AS. If the neighbor AS is the same as this router's AS, this is an iBGP connection. If the AS is different, this is an external neighbor. After the neighbor is defined, further neighbor commands are used to describe the policy used to filter routes to the neighbor.
Router(config-router)# neighbor ip-address remote-as autonomous-system-number
Listing a series of neighbors and the associated policies could be tedious. Large blocks of configuration lines are hard to read and debug. The concept of a peer group helps solve these problems.
A peer group is a group of neighbors that share the same update policy. Routers are listed as members of the peer group and then policy is associated with the peer group. The group policy is applied to each neighbor, although it can be customized for individual partners.
Peer groups not only reduce the configuration; they also ease the overhead on the router. If each neighbor is configured individually then the BGP update process has to run separately for each neighbor. If multiple neighbors are configured as a group, the update process can run once and then send the same update to all members of the group. Because of this, all members of the group must be either internal or external.
The neighbor peer-group-name command is used to create the peer group and to associate the peers with an AS. Once the peer group has been defined, members are defined using the neighbor peer-group command.
Router(config-router)# neighbor peer-group-name peer-group Router(config-router)# neighbor ip-address | peer-group-name remote-as autonomous-system-number Router(config-router)# neighbor ip-address peer-group peer-group-name
In Example 15-1, a router has been configured with three neighbors.
Example 15-1. Basic Configuration of Neighbors
Router(config)# router bgp 100 Router(config-router)# neighbor 10.255.255.202 remote-as 100 Router(config-router)# neighbor 10.255.255.203 remote-as 100 Router(config-router)# neighbor 10.255.255.204 remote-as 100 |
Example 15-2 shows the same configuration using a peer group.
Example 15-2. Basic Configuration of a Peer Group
Router(config)# router bgp 100 Router(config-router)# neighbor MyAS peer-group Router(config-router)# neighbor 10.255.255.202 peer-group MyAS Router(config-router)# neighbor 10.255.255.203 peer-group MyAS Router(config-router)# neighbor 10.255.255.204 peer-group MyAS Router(config-router)# neighbor MyAS remote-as 100 |
The neighbor command can also be used to disable a peer. Administratively shutting down a peer is done during maintenance to prevent "flapping" (to prevent the router from annoying its neighbors by oscillating between up and down).
Router(config-router)# neighbor ip-address | peer-group-name shutdown
Figure 15-1 shows the topology for the forthcoming Example 15-3.
Figure 15-1. Topology for Example 15-3
Example 15-3 shows the basic configuration commands required to make eBGP operate between autonomous systems. In Example 15-3, Router A in AS100 connects to routers in AS100, AS200, AS300, AS400, and AS500.
Example 15-3. Basic Configuration of eBGP on Router A
Router A Router(config)# interface Serial0.1 Router(config-int)# ip address 10.255.255.201 255.255.255.252 ! Router(config)# interface Serial0.2 Router(config-int)# ip address 10.255.255.205 255.255.255.252 ! Router(config)# interface Serial0.3 Router(config-int)# ip address 10.255.255.209 255.255.255.252 ! Router(config)# interface Serial0.4 Router(config-int)# ip address 10.255.255.213 255.255.255.252 ! Router(config)# router bgp 100 Router(config-router)# neighbor 10.255.255.202 remote-as 200 Router(config-router)# neighbor 10.255.255.206 remote-as 300 Router(config-router)# neighbor 10.255.255.210 remote-as 400 Router(config-router)# neighbor 10.255.255.214 remote-as 500 |
Source IP Address
Internal neighbors do not have to be directly attached. Typically, an IGP is responsible for routing within the AS so that BGP speakers can reach each other from across the AS.
In Figure 15-2, Router A has three IP addresses. When peering to A, B could choose to peer to the directly connected IP (172.25.1.1); however, if the associated link goes down, the interface no longer responds to that address. Even though there continues to be a path from B to A through C, B cannot reach the peering address and A is unavailable.
Figure 15-2. Internal Peering
Peering to a loopback address helps to prevent this conundrum. If Router B peers to the loopback interface (10.1.1.1) then it is unaffected by the status of the top link. However, it is important that the routers advertise the loopback networks used in this fashion with the IGP.
A second problem is that, when BGP traffic is created, the source IP is the output interface. On Router B, traffic from B to A would normally follow the direct path and be sourced from 172.25.1.2, but when that link fails, traffic will be sourced from the other interface (172.25.3.1). Since the new source address does not match the peer address configured on Router A, the connection will be refused.
To truly allow for redundant paths, the source address must always be what the neighbor expects. This can be accomplished with the neighbor update-source command:
Router(config-router)# neighbor ip-address | peer-group-name update-source interface
Example 15-4 shows an example configuration for Routers A and B. Both routers peer to their neighbors' loopback and source traffic from their own loopback, allowing for redundancy.
Example 15-4. Allowing for Redundant Peering Paths
Router A RouterA(config)# router bgp 25 RouterA(config-router)# neighbor 10.1.1.2 remote-as 25 RouterA(config-router)# neighbor 10.1.1.2 update-source loopback0 Router B RouterB(config)# router bgp 25 RouterB(config-router)# neighbor 10.1.1.1 remote-as 25 RouterB(config-router)# neighbor 10.1.1.1 update-source loopback0 |
External neighbors do not have the benefit of a routing protocol to learn peering addresses and so are usually directly attached. eBGP packets also have a TTL of 1, which prevents them from traveling more than one hop. It is possible to use a similar redundancy technique externally—however, the following two conditions must be met:
There must be a route to the peering address.
The TTL must be set to an appropriate number of hops.
To change the default TTL of external connections, use the command neighbor ebgp-multihop:
Router(config-router)# neighbor ip-address | peer-group-name ebgp-multihop hops
Forcing the Next-Hop Address
A BGP next hop is the point of entry into an AS. Typically, the next hop will be the address of the edge router, but there are some cases where it makes sense to change this. For instance, routes received from external neighbors will be advertised with external next-hop IP addresses. Internal neighbors might not recognize this as a valid address. The next-hop-self command allows a router to substitute its internal address so that internal neighbors understand how to reach the next-hop address. The next-hop attribute is discussed further in the attributes section of this chapter.
The syntax of the command is as follows:
Router(config-router)# neighbor {ip-address | peer-group} next-hop-self
Defining the Networks to Be Advertised
The network command determines the networks that are originated by this router. This is a different use of the network command than you are accustomed to configuring with EIGRP, OSPF, and RIP. This command does not identify the interfaces on which to run BGP; it states the networks that are available within the AS. Multiple network commands may be used as needed. The mask portion is used because BGP can handle subnetting and supernetting. The command syntax is
Router(config-router)# network network-number mask network-mask
Aggregating Routes
To aggregate (summarize) routes within the BGP domain, use the following command from router configuration mode:
Router(config-router)# aggregate-address ip-address mask [summary-only] [as-set]
If the parameter summary-only is used, then the specific routes are suppressed and the summary route is the only one propagated. Sending only the summary is the usual usage. If the parameter as-set is used, then all the autonomous systems that have been traversed will be recorded as a set in the update message.
Note
Before the aggregate-address command, routes were summarized by using a network statement and a static route. The network statement defined the route and then a static route to null0 met the synchronization requirement and prevented routing loops.
The following configuration illustrates the older method for advertising an aggregate address:
Router(config)# router bgp 10 Router(config-router)# network 10.0.0.0 255.255.254.0 Router(config)# ip route 10.0.0.0 255.255.254.0 null0
This set of commands is equivalent to aggregate-address 10.0.0.0 255.255.254.0; aggregate-address improves on the older method because it allows for easy summarization, allows for easy filtering of subnets, and is easier to read in a configuration.
Example 15-5 is a BGP configuration using the aggregate-address command with the summarization parameter. In this example, routes with a prefix longer than /16 are summarized. In this way, the route 10.10.35.8/29 is not seen in BGP updates because it is summarized into the 10.20.0.0/16 advertisement. Any route that does not summarize into those specified in the example is listed individually. Summarization reduces the overhead on the network and simplifies system administration.
Example 15-5. The aggregate-address Command with the Summarization Parameter
Router A Router(config)# interface Serial0 Router(config-int)# ip address 10.255.255.201 255.255.255.224 Router(config)# router bgp 100 Router(config-router)# network 10.10.35.8 255.255.255.252 Router(config-router)# network 10.10.27.0 255.255.255.0 Router(config-router)# network 10.10.100.0 255.255.2550.0 Router(config-router)# aggregate-address 10.10.0.0 255.255.0.0 summary-only Router(config-router)# neighbor 10.255.255.202 remote-as 200 Router(config-router)# neighbor 10.255.255.202 next-hop-self Router(config-router)# neighbor 10.255.255.206 remote-as 300 Router(config-router)# neighbor 10.255.255.206 next-hop-self |
Authentication
Authentication is extremely important with BGP—some providers even require authentication. Without authentication, Internet routing would be exposed to poisoning or misdirection that could allow attackers to insert themselves into a path or prevent communication.
BGP authentication involves agreeing to a key (password) and is accomplished by sending an MD5 hash of the key with every BGP packet. Authentication is easy to setup; simply associate a password with a neighbor:
Router(config-router)# neighbor ip-address password password
For example, authenticating neighbor 10.1.1.1 using a password of b8k6m3w1 follows:
Router(config-router)# neighbor 10.1.1.1 password b8k6m3w1Managing and Verifying the BGP Configuration
The show commands for BGP are comprehensive and give clear information about the BGP sessions and routing options. These informative commands were introduced in the previous chapter. Their functions are as follows:
show ip bgp— Displays the BGP routing table.
show ip bgp summary— Displays the status of all BGP sessions, as well as the number of prefixes learned per session.
show ip bgp neighbors— Displays information about the TCP connections to neighbors, such as the number of each type of BGP message sent and received with each neighbor. When the connection is established, the neighbors can exchange updates.
show processes cpu— Displays active processes and is used to identify any process that is using excessive resources.
Another command that helps to troubleshoot any implementation and should be considered in the BGP configuration is the debug command. An entire book in the IOS documentation set is devoted to this command. For BGP, debug is a very useful command. It is shown here with all the possible options:
Router# debug ip bgp [dampening | events | keepalives | updates]
This command displays live information of events as they occur. The options available display dampening information, events, keepalives to maintain the TCP session with the peer, and routing updates as they are sent or received. Route dampening is a mechanism to minimize the instability caused by route flapping. By counting the number of times the identified route fails and applying a penalty to the route for each flap, BGP can ignore ill-behaved routes and use only the well-behaved.
Resetting Neighbors
After configuration changes in BGP, it is sometimes necessary to do a "hard reset" and disconnect the TCP session between neighbors. This can be forced with the following command:
Router(config-router)# clear ip bgp {* | address}[soft [in | out]]
This command disconnects the session between the neighbors and reestablishes it using the new configuration that has been entered. BGP only exchanges routes when neighbor relationships are established, so if neighbors change policies—for example, to implement new distribute lists—resetting is the only way to propagate the changes without cycling the power.
There are several problems with a hard reset, however:
Hard resets take a long time to complete and interrupt routing in the interim.
Hard resets count as a flap and could cause peers to disassociate themselves.
Hard resets force a full set of routing updates and could generate a lot of traffic.
Soft resets have the same effect as "hard resets" but do not interrupt routing or cause a flap. Soft resets can be done inbound or outbound. An outbound soft reset looks like this:
Router(config-router)# clear ip bgp {* | address} soft out
An outbound soft reset tells the local router to resend its entire BGP table to this neighbor, but to do so without tearing down the TCP session between them. Changes to outbound route filtering can be passed to neighbors this way.
There are times, however, when you want your neighbor to softly resend their advertisement. Of course, you cannot force an "autonomous" neighbor to do anything. You could call the provider and ask, but this can be difficult or impossible.
Soft inbound resets allow you to simulate receiving an update. First, your router must have an unprocessed copy of the neighbor update. The soft-reconfiguration-inbound command must be preset for the neighbor, as shown in the following syntax. Since this causes your router to remember two copies of the advertisement (the before and after processing versions), this consumes much more memory.
Router(config-router)# neighbor ip-address soft-reconfiguration inbound
Assuming that the capability is available, you may replay a previously recorded advertisement—for example, to force a neighbor advertisement through new filters—using the command:
Router(config-router)# clear ip bgp ip-address soft in
Using the soft option (with or without any additional keywords) initiates a soft reset and does not tear down the session.
At this point, you have seen the array of BGP commands used most frequently in BGP implementations. This completes the exploration of the more commonly used BGP commands. Chapter 16 delves into greater depth with more specific formulations of BGP implementations.
