Information Technology Reference
In-Depth Information
with the regional IGP's EIGRP process number. One point to keep in mind is that, with all
three processes sharing the same resources, instability in one routing process might affect
other routing processes if there is a resource shortage.
The regional IGP process provides reachability throughout the entire regional network.
This process carries full routing and topological information for the region. The regional
IGP process terminates on the core routers in this architecture. A default route should be
injected into the regional IGP process on the core routers to provide reachability to the core
and other regions.
The core IGP process is responsible for maintaining connectivity among the core routers.
This IGP process should only carry prefixes and topology information for the core
routers, core links, and loopback interfaces on the core routers. There should be no redis-
tribution between the core IGP process and any other routing process. The core IGP process
provides reachability between the loopback interfaces to allow the iBGP sessions to form
and provides next-hop reachability for the BGP learned prefixes. The peering for all iBGP
sessions is with the loopback interfaces, and the
next-hop-self
command is used.
The BGP process running on each core router should peer via iBGP with every other core
router, creating a full mesh of iBGP sessions. The BGP process is responsible for propagating
prefix information between the core routers at each region. The iBGP sessions should be
sourced from the loopback interfaces on the core routers to ensure that BGP sessions
remain active even if a link fails, unless the core router becomes isolated.
The preferred method of injecting regional prefix information into the BGP process is
through the use of
network
statements. However, redistribution may be done from the
regional IGP in a controlled fashion (that is, with proper filtering). The prefixes from BGP
should not be redistributed into the regional IGP, because this would drastically reduce any
scalability improvements obtained by deploying BGP in the first place.
Path Selection
BGP path selection typically is resolved by comparing the IGP metrics to the routers from
which it received the prefix. The assumption is made that no extra policy is applied except
when explicitly mentioned or shown in configuration examples. It should be assumed that
bgp bestpath compare-routerid
is configured on all routers to ensure deterministic path
selection.
If each region has only a single core router, only a single path exists, and it is installed in
the routing table. If redundant routers are deployed for each region, one copy of each prefix
from each core router exists in the originating region.
Consider Figure 5-2. Region 102 has two core routers, and both inject 10.2.0.0/16 into the
iBGP core. All the core routers in the other regions see two paths for 10.2.0.0/16—one from
each core router in region 102, as shown in Example 5-1. BGP by default selects one best
path to install in the routing table.
