Information Technology Reference
In-Depth Information
The remote site prefixes should not be summarized in BGP. The summarization of these
prefixes can create an issue where traffic would be black-holed unless all the hub routers
are physically connected. Figure 5-19 shows a scenario in which R1 and R2 are the hub
routers, and R3 and R4 are the remote site routers. The remote sites are each dual-homed
to R1 and R2 via Frame Relay PVCs.
Figure 5-19
Remote Site Connectivity Black Hole Example
BGP Core
R1
R2
Frame Relay Cloud
R3
R4
Routing information to the remote sites is filtered to allow only the default route to be sent
from the hub router to the remote site. The remote site advertises only its local prefixes to
the hub router. Assume that both remote sites have primary connectivity through router R1
and that R1 advertises a summary prefix that aggregates the prefixes for both R3 and R4
into the BGP core network, setting the MED such that the prefix originated by R1 is the
preferred path. If the PVC between R3 and R1 fails, traffic still is directed at R1 because of
the summary for R3 and R4. The link to R3 is down, which results in the traffic's being
routed Null0, following the nailed up static used to create the summary.
If the hub routers are physically connected, an iBGP session can be created between them,
which allows R1 to send the traffic destined for R3 via R2 and down the backup PVC to R3.
However, if the hub routers are not physically connected, an iBGP session should not be
created between the two, based on the IGP design used in this example. To build the iBGP
session, the loopback addresses would have to be advertised between the hub routers, via
the remote sites to provide reachability for the iBGP session to form. This would result in
