|
The following example demonstrates how routing
information can be injected dynamically into BGP. Assume that AS3 is
getting Internet connectivity from AS1. AS3 is running OSPF as an IGP
inside the AS and is running EBGP with AS1.
On the other hand, AS3 has also one
customer, C1, with the following criteria:
- C1 is pointing a default toward AS3.
- C1 advertises all its routes to AS3 via RIP.
RTF is running two routing processes, the OSPF process and the RIP
process. RTF will listen to RIP only on its connection to C1 and will
redistribute the RIP updates it gets from C1 into OSPF. On the other hand,
RTA will run two routing processes, the OSPF process and the BGP process.
RTA will inject all its routes and customer routes dynamically into BGP.
Note: Click on topology to view command outputs.
The RTF configuration has introduced two new commands:
-
passive-interface type number
-- This router command disables
sending routing updates on the specified interface. In our example, when
used with RIP, this command prevents RIP updates from being sent on
interface S2/1. This is in case RTF has multiple customers connected
that do not need to see each other's networks.
When used with OSPF, this command disables hello packets from being
sent on the specified interface, which eventually prevents link-state
information from being exchanged on that interface.
[process-id]
-- This command injects
routes from one routing domain into another routing domain. In this
example, RTF is injecting the RIP routes into the OSPF domain (OSPF
process 10). Numerous extensions (such as subnets) of the redistribute
command exist; these extensions will be explained in context.
The subnet keyword is used to make sure that all subnetted information
will be injected into the OSPF process. This is needed only in the case of
redistributing routes into the OSPF protocol.
Note that RTD has configured a static route pointing a 0/0 default
toward RTF. For all destinations that are outside C1, RTD will direct the
traffic to RTF. RTD will also redistribute the static default route into
the internal RIP domain so that all other routers can follow a default
toward AS3. The
default-metric router
command assigns a metric to
the routes redistributed into a particular protocol. In this case, the
default-metric assigns a hop count of 1 to the 0/0 route injected into
RIP.
RTA has a combination of OSPF routes that belong to AS3 and other
external routes that came in from the RIP domain C1. Using the
redistribute router
command, RTA will dynamically inject all these routes into its BGP process.
Note that RTA is using the keywords "match external 1 external 2" in
conjunction with the
redistribute router
command. This is because OSPF does not inject external OSPF routes into BGP
unless it is specifically instructed to do so. This measure was put in for loop
avoidance in case the external OSPF information came from BGP.
Note in the RTA IP table how networks 192.68.10.0/24 and 192.68.5.0/24
are listed as external OSPF routes (O E2). Dynamic redistribution will
cause all these networks to be sent into BGP. The following is how the BGP
table of RTC would look:
Note how all networks running OSPF in AS3 have become BGP routes in
AS1. Usually, not every network that belongs to your AS needs to be sent
via BGP. You might be running private or illegal network numbers inside
the AS that need not be advertised. Note how the loopback address
172.16.2.254/32 was also injected into BGP. No provider will enable you to
advertise such prefixes and will instruct you to filter them, or the
provider might filter them on its end. This restriction is put in place to
make sure that customers are aggregating their routes as much as possible
to prevent the explosion of the global IP routing tables. Also, the DMZ
network 172.16.20.0/24 has been injected into BGP, and because this is not
necessary, redistribution should be accompanied by filtering to specify
the exact routes that need to be advertised. The configuration of RTA
gives an example of how filtering could be applied.
Filtering in the preceding example was performed with a route map,
which is an indication of a set of actions to be taken in case certain
criteria are found. Our criteria here are to find a match on the host
route 172.16.2.254/32 and the network 172.16.20.0/24 and to prevent them
from being sent via BGP. The access-list 1 will enable us to find a match
on these routes, and the route map BLOCKROUTES specifies that they be
denied. The second instance of the route map (20) permits all other routes
to be injected into BGP.
To have better control over what is being redistributed from the IGP
into BGP, the
network command can be
used. The
network command is a way
to individually list the prefixes that need to be sent via BGP. The
network command has a
limit of 200. If more than 200 networks need to be listed, dynamic
redistribution is a must. The network command specifies the prefix to be
sent out (network and mask). The statement "network 172.16.1.0 mask
255.255.255.0," for example, is an indication for prefix
172.16.1.0/24 to be sent. Networks that fall on a major net boundary
(255.0.0.0, 255.255.0.0, or 255.255.255.0) do not need to have the mask
included; for example, the statement "network 172.16.0.0" is
sufficient to send the prefix 172.16.0.0/16. Such networks are also listed
in the BGP routing table without the /x notation. For example, the Class C
network 192.68.11.0 is equivalent to 192.68.11.0/24. In addition, the configuration of RTA will specify the networks that will be
injected into BGP.
The following is what the BGP table of RTC would look like. All routes
have been injected into BGP except for 172.16.2.254/32 and 172.16.20.0/24.
Note that the table looks similar to the one produced when redistributing
the OSPF routes into BGP and applying filters. The only noticeable
difference is with the origin code, which is indicated by the "i"
at the end of the path information. The "i" origin code
indicates that the source of these networks is internal (IGP) to the
originating AS. If you look at the previous snapshot of the RTC BGP table,
the origin code was "?," meaning incomplete, an indication that
the origin of these networks is learned by some other means. Any time
routes are injected into BGP via redistribution, the origin code would be
incomplete.
The network command takes effect only if the prefixes listed are known
to the router -- that is, BGP will not go blindly advertising prefixes just
because they were listed. The router will check for the availability of an
exact match of the prefix in the IP routing table before the network is
advertised. In the preceding example, if we list "network
172.16.192.0 mask 255.255.255.0," that network will not be originated
because it is unknown by the router.
|
 |
Lab
Activity |
| |
In
this lab, you will how to inject routes from an
IGP into BGP using redistribution. |
|
|
|
|