In this example of redistribution with BGP, the discussion will focus more
on design and configuration issues, than with actual troubleshooting problems.
This section discusses injecting BGP routes into an IGP, as this is the
situation for most enterprise networks.
Prefixes that are learned from an EBGP neighbor are automatically added to
the routing table. In Figure
, for instance,
AS 300 is advertising two routes: 192.168.250.0/24 and 192.168.1.212/30. The
IGP for AS 300 and the configuration of router Tahoe are unimportant to this
example.
The important observations are that the prefixes advertised by
Tahoe to its external BGP peer are displayed in the Taos routing table as
reachable and that pings to a destination in AS 300 are successful
. An
extended ping is used because the subnet of the Taos serial interface,
192.168.1.224/30, is not advertised. The BGP-learned routes are tagged in the
routing table with a B.
Although the networks of AS 300 are reachable
from Taos, the BGP routes must be advertised into EIGRP before the networks are
reachable from AS 200 interior routers. One way to accomplish this is with the
redistribution at Taos, as demonstrated by the configuration in Figure
.
Figure
shows that AS
300 prefixes are advertised to AngelFire and that the destinations are
reachable. However, redistribution picks up every BGP route, but the
administrator might want only a subset of the BGP routes to be redistributed.
In such a case, route filters are required to suppress the unwanted routes.
Another vitally important reason exists for not redistributing BGP
routes into an IGP. A full Internet routing table consists of more than 100,000
prefixes, and an IGP process will "choke" trying to process so many
routes. Redistribution of a full Internet table, or even a large partial table,
will inevitably cause a major network crash. Never use a BGP-to-IGP
redistribution on an Internet facing router.
For more control over which
routes are advertised into AS 200, static routes can be used.
In this
configuration only 192.168.250.0/24 is advertised into the AS. As Figure
shows, AngelFire
has no knowledge of subnet 192.168.1.212/30. Using static routes in
configuration has the added benefit of protecting AS 200 from instabilities. If
network 192.168.250.0 flaps in AS 300, the changes are not advertised any
further into AS 200 than Taos.
Of course, in a single-homed AS, such as
AS 200 in Figure
little reason
exists to advertise any external routes into the AS. Unless there is a need to
advertise specific routes into the AS, a default route suffices.
In this
configuration, Taos generates a default route and advertises it to all EIGRP
speakers; however BGP can also be configured to generate a default route. To
advertise a default from Vail to its BGP neighbors, the configuration in Figure
could be used.
A default route to the Null0 interface is created statically, and the route
is advertised with the network command. The assumption with the configuration
is that Vail has full routing information. All packets are forward to Vail; any
destination address that cannot be matched to a more-specific route matches the
static route and is dropped.
In some design cases, a default should be
sent to some neighbors, but not to others. To send a default from Vail to Taos,
but not to any of Vail’s other neighbors, use the configuration in Figure
.
The BGP neighbor default-originate command
is similar to the OSPF default information-originate always
command in that a default is advertised whether the router actually has a
default route or not. Notice in the configuration that the static route from
the preceding configuration is no longer present; however, a route to 0.0.0.0/0
is still advertised to Taos, Figure
shows the
routing table of Tahoe, and unlike Taos, Tahoe does not have an entry for
0.0.0.0/0.
The advertisement of a default route to a BGP neighbor does
not suppress the more-specific routes. The routes from AS 300 are still present
in the Taos routing table. In some cases, this can be desirable. For example,
an ISP might send to a customer the routes to all of its other customers (a
partial Internet table), as well as a default to the rest of the Internet. Such
a case is useful when multihomed to the same ISP. The customer network can then
make best-path choices to the ISP’s customers and use the default route for all
other external destinations.
If only the default is to be sent, a router
must use a filter to suppress all more-specific routers. The configuration in
Figure
, using the
neighbor distribute-list command, is just one way to filter
BGP routes.