Building an IBGP Core

In Figure 16-14, USA.Cal.R1 needs full IBGP mesh, so it must maintain peering statements for all the IBGP-speaking routers. However, full IBGP mesh causes difficulty with optimal routing.

To accommodate optimal routing and add predictability, is not peering USA.Cal.R1 with Euro.Fra.R2, which accommodates the physical topology. To accommodate optimal routing with IBGP, must break the IBGP model and perform many tricks that complicate the network.

Another possible problem occurs with a race condition, in which the same route is sent from both the IBGP neighbors. In this case, network would be sent from USA.Cal.R1 and USA.Tex.R2 to Euro.Lon.R1 and Euro.Fra.R2. For optimization, you must redistribute IBGP route into IGP in Europe, even though this would cause the race condition.

USA.Cal.R1 is advertising a route to to Euro.Lon.R1. Similarly, USA.Tex.R5 is sending the same route to Euro.Fra.R2. Both European routers will install this route into their routing table via IBGP. Both U.S. routers send this less-specific route to European routers because of the failover situation. In case one of the IBGP routers in the United States goes down, routers in Europe can still reach each other's destinations in the United States via the less-specific routes.

For example, if USA.Cal.R1 goes down, Europe.Lon.R1 will not receive routes to 172,16.0.0/21. To reach these destinations, Europe can now use, which is learned from USA.Tex.R5 by Europe.Fra.R2.

Returning to the discussion of the race condition, both European routers are receiving routes from the United States via IBGP. As mentioned earlier, both Euro.Lon.R1 and Euro.Fra.R2 would redistribute this route into IGP for the region. The first router that redistributes this route in IGP will propagate the route to the other routers. Upon receiving the IGP route, the second IBGP router will remove the IBGP route from the routing table.

This occurs because OSPF has a better administrative distance than IBGP. This is not a predictable behavior, however, because the administrator would not know the origin of the redistributed route. This problem is overcome by reducing the administrative distance of IBGP, making it lower than the OSPF route, even though this will affect all IBGP routes.

The problem with this method is inconsistency. Suppose that you changed the administrative distance of the IBGP-learned route on Euro.Lon.R1. When Euro.Lon.R1 receives a route from USA.Cal.R1 now, it will receive the following routes:

The race condition would not exist for because Euro.Lon.R1 is the only router redistributing this route into its regional IGP. Similarly, there would not be a race condition for because Euro.Fra.R2 is the only redistributing router for this destination.

There are two commands in this configuration:

• The bgp redistribute-internal command is used to redistribute IBGP routes into IGP. By default, BGP will not redistribute IBGP-learned routes into IGP. Note that this command should be used only if you have a very clear understanding of BGP and IGP interactions. A routing loop could easily be formed by using this command.

• The distance bgp 20 100 200 command is used to change the administrative distance of the BGP-learned routes. The first number (20, by default) changes the external administrative distance; the second number (200, by default) changes the IBGP administrative distance; and the third number is for local BGP routes.

Local routes are those BGP entries that are created by the BGP originating router in its own routing table. For example, when the aggregate-address command is configured, BGP router creates a null route to the aggregate mask:

router bgp 1


This routing entry is automatically entered by BGP in the routing table:

B [200/0] via, 00:46:53, Null0

Routing entry for Known via "bgp 1", distance 200, metric 0, type locally generated Routing Descriptor Blocks: * directly connected, via Null0

Route metric is 0, traffic share count is 1

This is a local distance and is also set to 200, by default. In this configuration, the default distance is maintained for local routes, but the administrative distance for internal routing is changed to 100. This decreases the distance of IBGP to avoid the race condition:

router bgp 1

neighbor remote-as 1 neighbor 172.16.64. 4 remote-as 1 neighbor 172.16.64. 5 remote-as 1 neighbor 172.16.64. 6 remote-as 1

bgp redistribute-internal (Dangerous unless you know BGP


distance bgp 20 100 200 network mask network mask Configuration for OSPF forEuro.Lon.R1

router ospf 2 (This is for routing process for OSPF

within Europe)

network 172.16. 96.0 area 0 network area 1 redistribute bgp 1 subnets router ospf 4

network area 0

By changing the administrative distance, the race condition for is avoided, and both routers in the European region will install their IBGP-learned routes into the routing table. The redistribute command under the OSPF process redistributes the IBPG route into OSPF as external type 2, which is the default behavior in Cisco routers.

By default, all routes in Cisco are redistributed with external type 2. The OSPF route to would be redistributed with external type 2, and both routers would send the same metric.

If two routers send routes with the same external type 2 metric, the tie-breaker is the shortest path to the ASBR. Thus, routers closer to Euro.Lon.R1 would exit through it for network, and routers closer to Euro.Fra.R2 would use it for network Routers at an equal distance would perform load balancing.

In conclusion, IBGP should be used in the core only when there are no policy requirements, optimal routing is not desired, and all the interregional traffic is sent via default routers to the core. Implementing IBGP with optimal routing is complicated because it requires the configuration of knobs. This can be problematic if you are not familiar with BGP.

Was this article helpful?

0 0

Post a comment