Interactions Between BGP and IGPs

Interactions between BGP and an interior gateway protocol are more likely to occur in an enterprise topology than in a service provider topology. You can also encounter interactions when configuring small test topologies. The main interaction factors are the following:

Synchronizing BGP with IGPs

In Figure 36, AS 100 provides transit service but does not run BGP on all of the routers in the AS. In this situation, you must redistribute BGP into the IGP so that the non-BGP routers—for example, router Albany—learn how to forward traffic to customer prefixes. If BGP converges faster than the IGP, a prefix might be advertised to other ASs before that prefix can be forwarded.

For example, suppose router LA advertises a route to router Boston using EBGP, and router Boston propagates that route to router NY using IBGP. If router NY propagates the route to router Chicago before the IGP within AS 100 has converged—that is, before router Albany learns the route—then router Chicago might start sending traffic for that route before router Albany can forward that traffic.

Figure 36: Synchronization

Synchronization

Synchronization solves this problem by preventing a BGP speaker from advertising a route over an EBGP session until all routers within the speaker’s AS have learned about the route. If the AS contains routers connected by means of an IGP, the BGP speaker cannot propagate a BGP route that it learned from a peer until an IGP route to the prefix has been installed in the BGP speaker’s IP routing table. The BGP speaker advertises the BGP route externally even if the IGP route is better than the BGP route. By contrast, if synchronization is disabled, a BGP speaker propagates a BGP route learned from a peer only if it is the best route to the prefix in the IP routing table.

Synchronization is enabled by default. However, you must configure redistribution of external routes into the IGP, or the routing tables will not receive the IGP routes.

Note: When you create an address family for a VRF, synchronization is automatically disabled for that address family.

If synchronization is enabled and if redistribution is configured for the networks in Figure 36, router NY checks its IGP routing table for a route to 192.56.0.0/16 when it learns about the prefix from the IBGP session with router Boston. If the route is not present, the prefix is not reachable through router Albany, so router NY does not advertise it as available. Router NY keeps checking its IGP routing table; if the route appears, router NY knows that it can pass traffic to the prefix and advertises the route by means of EBGP to router Chicago.

In practice, service providers rarely redistribute BGP into an IGP because existing IGPs cannot handle the full Internet routing table (about 100,00 routes). Instead, all routers in an AS typically run BGP; in these cases it is advisable to turn synchronization off everywhere.

Disabling Synchronization

Because the routes learned by means of EBGP are extensive, redistributing those routes into your IGP consumes processor and memory resources. You can disable synchronization if your AS does not pass traffic from one AS to another or if all the transit routers in your AS run BGP. Figure 37 shows the same configuration as in the previous example, except that all the routers in AS 100 now run IBGP. As a result, all the routers receive updates learned by the area border routers from external BGP speakers.

Figure 37: Disabling Synchronization

Disabling Synchronization

If synchronization is disabled, a BGP speaker propagates a BGP route learned from a peer only if it is the best route to the prefix in the IP routing table. However, the speaker does advertise the routes that it originates.

The following commands show how to configure routers Boston, NY, and Chicago (shown in Figure 37) with synchronization disabled for routers NY and Boston. The no synchronization command enables router NY to put the route to 192.56.0.0/16 in its IP routing table and advertise it to router Chicago without learning about 192.56.00/16 from router Albany. The command also enables router Boston to put the route to 192.30.0.0/16 in its IP routing table and advertise it to router LA without learning about 192.30.00/16 from router Albany.

To configure router Boston:

host1((config)#router bgp 100 host1(config-router)#neighbor 2.2.2.2 remote-as 100 host1(config-router)#neighbor 4.4.4.1 remote-as 100 host1(config-router)#neighbor 1.1.1.2 remote-as 300 host1(config-router)#no synchronization

To configure router NY:

host2(config)#router bgp 100 host2(config-router)#neighbor 3.3.3.2 remote-as 200 host2(config-router)#neighbor 2.2.2.1 remote-as 100 host2(config-router)#neighbor 4.4.4.3 remote-as 100 host2(config-router)#no synchronization

To configure router Albany:

host3(config)#router bgp 100 host3(config-router)#neighbor 4.4.4.4 remote-as 100 host3(config-router)#neighbor 4.4.4.2 remote-as 100 host3(config-router)#no synchronization

To configure router Chicago:

host4(config)#router bgp 200 host4(config-router)#neighbor 3.3.3.1 remote-as 100

To configure router LA:

host5(config)#router bgp 300 host5(config-router)#neighbor 1.1.1.1 remote-as 100 host5(config-router)#network 192.56.0.0

synchronization

Setting the Administrative Distance for a Route

The administrative distance is an integer in the range 0–255 that is associated with each route known to a router. The distance represents how reliable the source of the route is considered to be. A lower value is preferred over a higher value. An administrative distance of 255 indicates no confidence in the source; routes with this distance are not installed in the routing table. As shown in Table 21, default distances are provided for each type of source from which a route can be learned.

Table 21: Default Administrative Distances for Route Sources

Route Source

Default Distance

Connected interface

0

Static route

1

External BGP

20

OSPF

110

IS-IS

115

RIP

120

Internal BGP

200

Unknown

255

If the IP routing table contains several routes to the same prefix—for example, an OSPF route and an IBGP route—the route with the lowest administrative distance is used for forwarding.

By default, BGP propagates received BGP routes to EBGP routes only if the BGP route is used for forwarding traffic—that is, if it is the route with the lowest administrative distance in the IP forwarding table. However, you can modify this behavior by using the bgp advertise-inactive command. See Advertising Inactive Routes for more information.

You can use the distance bgp command to configure the administrative distance associated with routes. If you choose to set an administrative distance, you must specify a value for all three of the following types of routes:

You can use the distance bgp command to configure these preferences. The following commands leave the internal distance at 200, set the external distance to 150, and set the local distance to 80:

host1(config)#router bgp 100 host1(config-router)#network 172.28.0.0 host1(config-router)#neighbor 156.128.5.5 remote-as 310 host1(config-router)#neighbor 142.132.1.1 remote-as 50 host1(config-router)#distance bgp 150 200 80

distance bgp

Example 1

Routes learned from other sources can be preferred to routes learned by means of BGP. Consider the network structure shown in Figure 38.

Figure 38: Administrative Distances

Administrative Distances

Suppose router KC originates 172.17.24.0/21 and advertises the route to router Chicago by means of EBGP. Both router KC and router Chicago are directly connected to the network represented by 172.17.24.0/21. If you issue the show ip route command on router Chicago, the BGP route does not appear. Instead, only the connected route is displayed.

Both routes are in the IP routing table, but the show ip route command displays only the best route. (Use the show ip route all command to display all best routes; in this case the BGP route and the connected route.) Connected routes have a default distance of 0. Routes learned by means of EBGP have a default value of 20. The connected route is a better route than the EBGP route and appears in the command display.

In practice, if two BGP peers are connected to the same network, both peers should originate the route.

Example 2

Consider the network structure shown in Figure 39. Router Chicago originates prefix 192.168.11.0/24 and advertises it by means of EBGP to router Albany. Router Albany advertises the route to router Boston by means of IBGP.

Router Albany also redistributes the route into the interior gateway protocol RIP, which informs router NY of the route. Router NY propagates the route to router Boston by means of RIP, from which it is injected into BGP.

In this example, both router Albany and router Boston have synchronization turned on. When synchronization is on, BGP propagates a received route to EBGP peers, even if the IP forwarding table contains a non-BGP route with a better administrative distance than the BGP route. This example demonstrates why synchronization is needed.

Figure 39: Administrative Distance and Synchronization

Administrative Distance and Synchronization

Router Boston does not advertise the route externally to router Philly. At first, this is because router Boston has not yet heard about the prefix from router NY, and therefore the IGP route does not appear in router Boston’s IP routing table.

BGP routes are not propagated until a route to the prefix by means of any IGP appears in the IP routing table. In other words, routers connected by means of an IGP must have a route to the prefix before a BGP speaker can advertise the route it learned from a peer.

When the RIP route appears on router Boston, the router has both an IBGP route and a RIP route to the same prefix. Even though the RIP route has a better administrative distance, the IBGP route is propagated to router Philly because synchronization is turned on.

Configuring Backdoor Routes

In certain network topologies, a BGP speaker might learn routes to the same prefix from an external BGP peer and by means of an IGP protocol. Consider the network structure shown in Figure 40.

A company has established an OSPF link between routers NY and Boston. This private link between the two routers is known as a backdoor link. Router NY learns two routes to prefix 172.19.0.0/16; one by means of OSPF from router Boston, and one by means of EBGP from router LA through router SanDiego. As was shown in Table 21, EBGP routes have an administrative distance of 20 and are preferred over IGP routes, which have much higher administrative distances. In this example, the longer path by means of EBGP is preferred over the OSPF backdoor path with its distance of 110.

Figure 40: Backdoor Route

Backdoor Route

You can modify this behavior by issuing the network backdoor command on router NY:

host1(config)#router bgp 300 host1(config-router)#neighbor 10.4.4.1 remote-as 400 host1(config-router)#network 172.19.0.0 backdoor

Unlike the typical network command, network backdoor does not cause the BGP speaker to advertise the specified prefix. Instead, it sets the administrative distance for the EBGP path to that prefix to the same value as a route learned by means of IBGP. That is, the EBGP administrative distance is changed from the highly preferred value of 20 to the highly unpreferred value of 200. In Figure 40, this change in value results in the backdoor OSPF being more preferred as a way to reach prefix 172.19.0.0/16.

network backdoor

Setting the Maximum Number of Equal-Cost Multipaths

You can use the maximum-paths command to specify the number of equal-cost paths to the same destination that BGP can submit to the IP routing table.

If you set the value to 1, the router installs the single best route in the IP routing table. If you set the value greater than 1, the router installs that number of parallel routes.

By default, for IBGP routes, unequal-cost multipaths are installed in the routing table. You must use the equal-cost keyword with the maximum-paths ibgp command to enable equal-cost multipaths to be used in the routing table for traffic forwarding. IGP can use an asymmetric set of paths for a given destination. This functionality is called unequal-cost load balancing. Unequal-cost load balancing enables traffic to be distributed among multiple unequal-cost paths to ensure higher overall throughput and reliability.

maximum-paths