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:
- Synchronization between BGP and IGPs
- Administrative distances for routes learned from various sources
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 routersfor example, router Albanylearn 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 convergedthat is, before router Albany learns the routethen router Chicago might start sending traffic for that route before router Albany can forward that traffic.
![]()
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.
![]()
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.
host1((config)#router bgp 100host1(config-router)#neighbor 2.2.2.2 remote-as 100host1(config-router)#neighbor 4.4.4.1 remote-as 100host1(config-router)#neighbor 1.1.1.2 remote-as 300host1(config-router)#no synchronizationhost2(config)#router bgp 100host2(config-router)#neighbor 3.3.3.2 remote-as 200host2(config-router)#neighbor 2.2.2.1 remote-as 100host2(config-router)#neighbor 4.4.4.3 remote-as 100host2(config-router)#no synchronizationhost3(config)#router bgp 100host3(config-router)#neighbor 4.4.4.4 remote-as 100host3(config-router)#neighbor 4.4.4.2 remote-as 100host3(config-router)#no synchronizationhost4(config)#router bgp 200host4(config-router)#neighbor 3.3.3.1 remote-as 100host5(config)#router bgp 300host5(config-router)#neighbor 1.1.1.1 remote-as 100host5(config-router)#network 192.56.0.0synchronization
- Use to enable and disable synchronization between BGP and an IGP.
- Synchronization is enabled by default. However, creating an address family for a VRF automatically disables synchronization for that address family.
- This command takes effect immediately.
- Use the no version to advertise a route without waiting for the IGP to learn a route to the prefix.
Setting the Administrative Distance for a Route
The administrative distance is an integer in the range 0255 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 22, default distances are provided for each type of source from which a route can be learned.
If the IP routing table contains several routes to the same prefixfor example, an OSPF route and an IBGP routethe 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 trafficthat 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:
- externalAdministrative distance for BGP external routes. External routes are routes for which the best path is learned from a BGP peer external to the AS. Acceptable values are from 1 to 255. The default value is 20.
- internalAdministrative distance for BGP internal routes. Internal routes are those routes that are learned from a BGP peer within the same AS. Acceptable values are from 1 to 255. The default value is 200.
- localAdministrative distance for BGP local routes. Local routes are those routes locally originated by BGP. BGP can locally originate routes if you issue the network command, if you configure redistribution into BGP, or by means of a non-AS-set aggregate route. Acceptable values are from 1 to 255. The default value is 200.
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 100host1(config-router)#network 172.28.0.0host1(config-router)#neighbor 156.128.5.5 remote-as 310host1(config-router)#neighbor 142.132.1.1 remote-as 50host1(config-router)#distance bgp 150 200 80distance bgp
- external-distanceAdministrative distance for routes external to the AS in the range 1255. The default is 20.
- internal-distanceAdministrative distance for routes internal to the AS in the range 1255. The default is 200.
- local-distanceAdministrative distance for local routes in the range 1255. The default is 200.
- The default value is 20 for external routes, 200 for internal route, and 200 for local routes.
- The new distance is applied to all routes that are subsequently placed in the IP routing table. To apply the new distance to routes that are already present in the IP routing table, you must use the clear ip routes * command to reinstall BGP routes in the IP routing table.
- Use the no version to return the distances to their default values, 20, 200, and 200.
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.
![]()
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.
![]()
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 22, 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.
![]()
You can modify this behavior by issuing the network backdoor command on router NY:
host1(config)#router bgp 300host1(config-router)#neighbor 10.4.4.1 remote-as 400host1(config-router)#network 172.19.0.0 backdoorUnlike 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
- Use to cause a backdoor IGP route to be preferred over an EBGP route to the same prefix by setting the administrative distance of the EBGP route to that of an IBGP route, 200.
- Issuing this command does not cause the BGP speaker to advertise the specified route.
- This command takes effect immediately.
- Example
host1(config-router)#network 10.53.42.0 backdoorUse the no version to restore the default distance to the EBGP route, 20. 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.
maximum-paths
- Use to set the maximum number of equal-cost multipaths.
- Specify a value in the range 116; the default value is 1.
- If you do not specify a keyword, the maximum number applies only to routes learned from external peers. If you specify the ibgp keyword, the maximum number applies only to routes received from internal peers. If you specify the eibgp keyword (valid only for VRF IPv4 unicast or IPv6 unicast address families), the maximum number applies to routes received from internal peers and external peers.
- This command takes effect immediately; it does not bounce the session.
- You can specify the maximum number of equal-cost multipaths in the context of the virtual router, an IPv4 unicast or IPv6 unicast address family, or a VRF specified in the context of an IPv4 unicast or IPv6 unicast address family.
- This command is not supported for VPNv4 or VPNv6 address families.
- Example 1
host1(config-router)#maximum-paths 3Example 2 host1:vr1(config-router-af)#maximum-paths ibgp 5Use the no version to restore the default value, 1.