9.5 Configure BGP to Interact with IGPs
9.5.4
Inject information dynamically into BGP (configuration)
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.

  • redistribute protocol [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.