Configuring BGP

2017-11-03 09:05:04

Problem

You want to run BGP in a simple network.

Solution

In its simplest configuration, BGP exchanges routes between a router in one AS and another router in a different AS. The first router is in AS 65500:

Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#interface Serial0 Router1(config-if)#ip address 192.168.55.6 255.255.255.252 Router1(config-if)#exit Router1(config)#router bgp 65500 Router1(config-router)#network 192.168.1.0 Router1(config-router)#neighbor 192.168.55.5 remote-as 65501 Router1(config-router)#no synchronization Router1(config-router)#exit Router1(config)#end Router1#

The second router is in AS 65501:

Router2#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router2(config)#interface Serial0 Router2(config-if)#ip address 192.168.55.5 255.255.255.252 Router2(config-if)#exit Router2(config)#router bgp 65501 Router2(config-router)#network 172.25.17.0 mask 255.255.255.0 Router2(config-router)#neighbor 192.168.55.6 remote-as 65500 Router2(config-router)#no synchronization Router2(config-router)#exit Router2(config)#end Router2#

Discussion

This example shows two routers in different Autonomous Systems. Router1 is in AS 65500, and is configured to share routing information only for a single network using the command network 192.168.1.0. Because this is a classful network, we don't need to include a mask. However, you will notice that the syntax of the network command on Router2 is different:

Router2(config-router)#network 172.25.17.0 mask 255.255.255.0

This is because the routing information we want to share only includes 172.25.17.0/24, and not the entire classful network, 172.25.0.0/16.

The first thing you should do after configuring two routers for BGP is to ensure that they are able to establish a BGP connection. You can verify this with the command show ip bgp summary:

Router1#show ip bgp summary BGP router identifier 192.168.99.5, local AS number 65500 BGP table version is 7, main routing table version 7 4 network entries and 4 paths using 484 bytes of memory 2 BGP path attribute entries using 196 bytes of memory BGP activity 11/7 prefixes, 11/7 paths Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 192.168.55.5 4 65501 17 18 7 0 0 00:12:38 2 Router1#

Here you can see that Router1 has a BGP neighbor, 192.168.55.5, in AS 65501. The most critical detail here is the last column, State/PfxRcd. In this column, you will see either a word, indicating the state of the peer connection, or a number, indicating the number of routing prefixes (that is, the number of distinct subnets in the routing table) that have been received from this peer.

In this case, the router had a valid BGP session with the neighbor device, 192.168.55.5 for just over 12 minutes. If this session is broken for any reason, you will most likely see either the word "Active" or "Idle" in this field. The following output shows another peer device, 172.25.2.2, which is down:

More than one engineer has seen the word "Active" (or "Connect") here and thought that the session was active. But, in fact it means that this peer relationship is currently down. The BGP connection is only up if you see a number in the last column. Note also that the word "Idle" in this column indicates that the router doesn't believe that a session is even possible with this peer device, or that it has not yet attempted to connect (the router will wait several seconds before attempting a connection). If the Idle condition persists, this usually indicates that the remote peer is unreachable. A persistent "Active" state, on the other hand, most likely indicates a configuration problem.

It often takes almost a minute to establish a BGP peer connection, so be patient if you don't see the peers immediately connect. If after this time they still have failed to connect, you should double check your "neighbor" configuration statements. Make sure that you have the right remote IP address and AS number, in particular. If these are correct, and you can ping the remote peer's IP address. Then you should make sure that the routers are using the interfaces that you think they are to reach the destination.

The example in the Solutions section of this recipe shows an eBGP peer relationship because we have configured different ASNs on the two routers:

Router1(config)#router bgp 65500 Router1(config-router)#neighbor 192.168.55.5 remote-as 65501

This shows that Router1 is in AS 65500, while Router2 is in AS 65501. You configure iBGP peers the same way, but the neighbor statement specifies the same ASN value as the router bgp statement. We can add a iBGP peer in AS 65500 as follows:

And we would configure the other iBGP peer router like this:

There is no need to establish a peer relationship between this new router and the eBGP peer, Router2. Router3 may connect to one or more other, completely different ASs, though. And there is nothing to prevent you from having an iBGP peer that doesn't connect to any eBGP peers. However, it is important to create a full mesh of iBGP relationships among all of the BGP routers inside any given AS.

BGP uses a permanent TCP connection between pairs of peer routers, and every peer relationship must be configured manually. This is actually one of the biggest strengths of BGP because it allows you to configure unique properties, such as unique filtering for each peer. With the various IGPs that we have already discussed, the routing peers generally discover one another dynamically by default.

However, the above examples only specify the destination IP address, not the source address. In this particular case, there is only one way to reach the destination, so there is no need to specify the source address, as the routers will simply use the IP address of the nearest interface. There are some cases where you do need to specify the source address, though.

For example, you might have two iBGP routers in your network, with several different possible paths between them. In this case, it would be better to configure the two routers to use their loopback addresses for the peer configuration, rather than the physical interfaces, which could go down. If you have redundant paths, you may as well use them. You could configure the router to use its loopback address for BGP as follows:

Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#interface Ethernet0 Router1(config-if)#ip address 192.168.55.6 255.255.255.0 Router1(config-if)#exit Router1(config)#interface Ethernet1 Router1(config-if)#ip address 192.168.56.10 255.255.255.0 Router1(config-if)#exit Router1(config)#interface Loopback0 Router1(config-if)#ip address 172.21.19.1 255.255.255.255 Router1(config-if)#exit Router1(config)#ip route 172.20.1.2 255.255.255.255 192.168.55.1 Router1(config)#ip route 172.20.1.2 255.255.255.255 192.168.56.1 Router1(config)#router bgp 65500 Router1(config-router)#neighbor 172.20.1.2 remote-as 65500 Router1(config-router)#neighbor 172.20.1.2 update-source Loopback0 Router1(config-router)#exit Router1(config)#end Router1#

Then, on the other router, you would have:

Router3#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router3(config)#interface Ethernet0 Router3(config-if)#ip address 192.168.55.1 255.255.255.0 Router3(config-if)#exit Router3(config)#interface Ethernet1 Router3(config-if)#ip address 192.168.56.1 255.255.255.0 Router3(config-if)#exit Router3(config)#interface Loopback0 Router3(config-if)#ip address 172.20.1.2 255.255.255.255 Router3(config-if)#exit Router3(config)#ip route 172.21.19.1 255.255.255.255 192.168.55.6 Router3(config)#ip route 172.21.19.1 255.255.255.255 192.168.56.10 Router3(config)#router bgp 65500 Router3(config-router)#neighbor 172.21.19.1 remote-as 65500 Router3(config-router)#neighbor 172.21.19.1 update-source Loopback0 Router3(config-router)#exit Router3(config)#end Router3#

Each of these routers uses the other's loopback IP address for its BGP neighbor statement. But to create a TCP session, you need the source address from one end to match the destination address of the other. So we have included commands to force each router to use their loopback interfaces for these source addresses:

Router1(config-router)#neighbor 172.20.1.2 update-source Loopback0

We strongly recommend using the update-source option, specifying a loopback interface on both routers, whenever you have redundant paths between iBGP peers.

So far, everything that we have discussed has to do with establishing the iBGP and eBGP peer relationships. We haven't exchanged any actual routing information yet. This brings us to the network commands in the example configuration files. On the first router, we used the classful version of the command to advertise an entire Class C network, 192.168.1.0/24:

Router1(config)#router bgp 65500 Router1(config-router)#network 192.168.1.0

The second router, however, uses the more general classless version of the network command:

Router2(config)#router bgp 65501 Router2(config-router)#network 172.25.17.0 mask 255.255.255.0

These commands allow the router to pick up routes out of its routing table and pass them along using BGP. BGP will not advertise anything that it doesn't have in its routing table. The first command will advertise the prefix 192.168.1.0/24 if it is in the routing table, while the second one will advertise 172.25.17.0/24. It is important to realize that these are literally the prefixes that BGP will advertise. If you have a route for 192. 168.1.4/32, then the first network statement we mentioned will not cover it. Instead, you would have to explicitly include a network command for this prefix:

Router1(config)#router bgp 65500 Router1(config-router)#network 192.168.1.4 mask 255.255.255.255

You can also use redistribution to inject routes into BGP from either static routes or foreign routing protocols. As we discuss in Recipe 9.14, however, redistribution is messy and complicated. We strongly recommend against redistribution to introduce routes into BGP if it can be avoided.

Note that because BGP will only advertise a prefix if it is in the routing table, an unstable IGP route could introduce instability into BGP. You can ensure the route is always available, though, by using a floating static route pointing to the null interface:

Router1(config)#ip route 192.168.1.0 255.255.255.0 null0 250

Here we have specified an Administrative Distance of 250 for this route. This value is deliberately very high to ensure that it is worse than any IGP, as well as iBGP. Now when the dynamic route drops out of the IGP routing table, the router replaces it with this floating static route, and BGP continues to advertise the prefix. This is not always desirable, of course. You may want this BGP router to stop advertising routes that it cannot reach. But in most cases, stability is more important. See Recipe 5.5 for more information about floating static routes.

Looking back at the example in the Solutions section of this recipe, you will see that we disabled synchronization on both routers:

Router1(config)#router bgp 65500 Router1(config-router)#no synchronization

Synchronization is enabled by default. This feature is intended for situations in which your AS acts as a transit for packets from one AS to another, but where some of the routers in your AS do not run BGP. In this case, the routers that only run the IGP need to have the same routing table as the BGP routers, or the AS could become a black hole for the unsynchronized routes. If synchronization is enabled in this situation, BGP will only advertise routes that are present in both the IGP and BGP route tables.

In this example, we had no intention of carrying the BGP routing table through the IGP. We generally recommend disabling synchronization, unless you are running an IGP and redistributing routes between BGP and the IGP.

Take a close look at the examples in this recipe because they show how Cisco's BGP configuration syntax works. When you want to change the parameters for a particular peer, you must first define the neighbor and the AS that this peer resides in. Then you can start to define any nondefault behavior for this peer with further neighbor commands that specify the same peer IP address. There are literally dozens of different options you can adjust this way. We mention several of these options in this chapter.

Категории