Information Technology Reference
In-Depth Information
Example 5-10 Path Information for 10.1.0.0/16 (Continued)
172.16.13.17 from 172.16.13.17 (172.16.9.1)
Origin IGP, localpref 100, valid, external
65101
172.16.13.9 from 172.16.13.9 (172.16.3.1)
Origin IGP, metric 307200, localpref 100, valid, external, best
100
Example 5-11 Path Information for 10.2.0.0/16
R11#show ip bgp 10.2.0.0
BGP routing table entry for 10.2.0.0/16, version 57
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
172.16.13.9
65103 65102
172.16.13.17 from 172.16.13.17 (172.16.9.1)
Origin IGP, localpref 120, valid, external, best
65101 65102
172.16.13.9 from 172.16.13.9 (172.16.3.1)
Origin IGP, localpref 100, valid, external
120
To summarize these path-selection exercises, it is obvious that the external BGP core archi-
tecture does not include the IGP metric in the path-selection process. This is because no
common IGP runs throughout the network core. The result is that the BGP path-selection
process is performed without visibility into the physical topology and link bandwidth. This
can be overcome through manually modifying BGP attributes. Care must be taken to ensure
that modifications are done precisely to avoid creating additional instances of suboptimal
routing.
Failure and Recovery Scenarios
A couple of failure scenarios are of interest in this architecture. Device failure in the regional
autonomous systems is handled by the regional IGP, making this failure uninteresting from
a BGP standpoint.
The failure of a core link causes the BGP session traversing it to be torn down. How long
this takes depends on the link failure detection and BGP hold timer. If the router detects the
link failure, the session that is sourced off that interface is torn down immediately provided
that bgp fast-external failover is enabled, which is the default.
If the peers are connected via a multiaccess broadcast medium, such as Fast Ethernet, the
failure of one link might not mean the failure of the other link. This results in the peer that
has the link failure tearing down the session, whereas the other peer remains in the Estab-
lished state. The peer that does not detect the link failure does not tear down the session
until the holdtime expires.
Search WWH ::




Custom Search