BGP in the Core
The core is the place in your network where the scalability pains will be felt first. The core needs to have full knowledge of all the destinations in the network—full routes. The task is to configure BGP on all the core routers, and let it handle the routes that are external to the core. The IGP will carry only the information about local destinations. See Figure 8-1.
A simple way to shift the burden of carrying the routing information to BGP is to implement a full iBGP mesh in the core. In this case, the routing information from the distribution layer is redistributed into BGP, which carries it as internal routes. IGP routes have a lower administrative distance than iBGP and, hence, are favored. Therefore, it is necessary to filter all the IGP routes coming from the distribution layer into the core. Another solution is to use a different IGP in the core (or at least use a different instance or process). In addition, iBGP synchronization needs to be turned off. For details on synchronization, see Appendix D,"BGP Fundamentals."
Figure 8-1. The Network Core
This approach provides an instant scalable core. In terms of migration, you should overlay BGP on the IGP that is currently in use. Once the routes have been redistributed into BGP, and its consistency is verified (in other words, make sure that all the routes are present in the BGP table), you can start filtering the IGP information at the border. If two or more distribution routers are introducing the same summary, then changing iBGP's administrative distance to favor its routes over the IGP's is a safer approach.
It is very important to highlight the fact that BGP was not conceived as an IGP; its main objective when it was designed was to carry external routes—routes learned from other ASs or routing domains. BGP cannot detect routing loops within an AS; it can detect loops only in eBGP routes.
Because of this, you cannot redistribute iBGP routes (routes originated in the local AS) into your IGP. In other words, the BGP routes cannot be passed on to the distribution layer. This leaves you with a single choice: to only carry a default pointing back to the core. If your distribution layer needs at least partial routing information from the core, then you will need to have an eBGP connection. This approach is explored in the following sections. Another advantage of using eBGP to glue your network together is the added flexibility (in filtering and decision making) that BGP provides.
Case Study: Sample Migration
Consider the network core in Figure 8-1. The first task is to overlay BGP on the existing network without any other changes taking place. The configuration is simple and can be standardized for ease of deployment:
router bgp 109
no synchronization
redistribute ospf 1 route-map routes-to-core
neighbor x.x.x.x remote-as 109
no auto-summary
!
route-map routes-to-core permit 10
set metric-type internal
Note that synchronization and autosummary are turned off. This last action allows BGP to carry the routing information with the same granularity as the IGP does (not only the major networks). Also, the MED is set using the set metric-type internal command with the purpose of being able to choose the best exit point (shortest IGP distance) in case of multiple options. Remember: One neighbor statement is required for each of the other routers in the core.
As discussed in Chapter 5, "OSPF Network Design," the ABRs may or may not be located at the edge of the core. The preceding configuration assumes that the ABRs are not the border routers—so redistribution of OSPF into BGP takes place. Keep in mind that the redistributed routes are the ones present in the routing table.
If the border routers are ABRs, then summarization takes place at these routers. The summarized routes, however, are not present in the routing table at the ABRs. It is necessary to manually create the summaries and then redistribute them. The sample configuration changes to something like this:
router bgp 109
no synchronization
neighbor x.x.x.x remote-as 109
redistribute static route-map routes-to-core
no auto-summary
!
router ospf 109
area 0 range y.y.y.y y.y.y.y
area 0 range t.t.t.t t.t.t.t
!
ip route y.y.y.y y.y.y.y null0
ip route t.t.t.t t.t.t.t null0
!
route-map routes-to-core permit 10
set metric 20
An advantage of this method is that the routes are "nailed" to the null0 interface (which means it never flaps and never goes down), which will ensure stability in the core regardless of the state of any of the areas. One major difference in the approach is the use of the metric; in this case, the metric may be set either with a route map, or on each route at the time that they are defined.
To verify the consistency of the information in the BGP table, a comparison must be made between the data in the routing table (learned via OSPF, in this case) and the one in the BGP table. The following configuration presents an example of what you need to see (for network 20.1.1.0/24, in this case):
rtrC#show ip route 20.1.1.0
Routing entry for 20.1.1.0/24
Known via "ospf 109", distance 110, metric 65, type intra area
Redistributing via ospf 109
Last update from 140.10.50.6 on Serial0, 00:00:28 ago
Routing Descriptor Blocks:
* 140.10.50.6, from 20.1.1.1, 00:00:28 ago, via Serial0
Route metric is 65, traffic share count is 1
rtrC#show ip bgp 20.1.1.0
BGP routing table entry for 20.1.1.0/24, version 47
Paths: (1 available, best #1)
Local
140.10.50.6 from 140.10.50.6 (20.1.1.1)
Origin incomplete, metric 20, localpref 100, valid, internal, best
If these two tables are not uniform, then you will need to revisit your redistribution points and check your filters (if any). Because LSA filtering can be tricky (at best) or impossible, changing the administrative distance for the iBGP routes will be explored next. To achieve the change, the following command is used:
router bgp 109
distance bgp 20 20 20
This command sets the administrative distance for internal, external, and local BGP routes to 20. In Cisco routers, the default administrative distance for OSPF routes is 110—and the lowest value is preferred. To verify the effectiveness of the change, take a look at the routes again:
rtrC#show ip route 20.1.1.0
Routing entry for 20.1.1.0/24
Known via "bgp 109", distance 20, metric 20, type internal
Last update from 140.10.50.6 00:00:09 ago
Routing Descriptor Blocks:
* 140.10.50.6, from 140.10.50.6, 00:00:09 ago
Route metric is 20, traffic share count is 1
AS Hops 0
rtrC#show ip bgp 20.1.1.0
BGP routing table entry for 20.1.1.0/24, version 47
Paths: (1 available, best #1)
Local
140.10.50.6 from 140.10.50.6 (20.1.1.1)
Origin incomplete, metric 20, localpref 100, valid, internal, best