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 listing 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.

Considering figure 10-4, the following configuration of RTA will specify the networks that will be injected into BGP.

RTA configuration:

    router ospf 10
     passive-interface Serial0
     network 172.16.0.0 0.0.255.255 area 0

    router bgp 3
     network 172.16.1.0 mask 255.255.255.0
     network 172.16.65.0 mask 255.255.255.192
     network 172.16.220.0 mask 255.255.255.0
     network 192.68.5.0
     network 192.68.10.0
     neighbor 172.16.20.1 remote-as 1
     no auto-summary

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 RTC's BGP table, the origin code was "?", meaning incomplete, which is an indication that the origin of these networks is learned by some other means. Anytime routes are injected into BGP via redistribution, the origin code would be incomplete.

    RTC#sh ip bgp
    BGP table version is 34, local router ID is 192.68.11.1
    Status codes: s suppressed, d damped, h history, * valid, > best,
    i - internal Origin codes: i - IGP, e - EGP, i - incomplete
       Network             Next Hop          Metric LocPrf  Weight Path
    *> 172.16.1.0/24       172.16.20.2            0         0 3 i
    *> 172.16.65.0/26      172.16.20.2           20         0 3 i
    *> 172.16.220.0/24     172.16.20.2            0         0 3 i
    *> 192.68.5.0          172.16.20.2           20         0 3 i
    *> 192.68.10.0         172.16.20.2           20         0 3 i
    *> 192.68.11.0         0.0.0.0                 0     32768 i

The network command only takes effect 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.

Injecting Information Statically into BGP

Listing prefixes with the network command has the same drawbacks as dynamic redistribution. If a route that is listed with the network command goes down, BGP will send an update; if the route comes back, BGP will send another update. If this behavior continues, the IGP instability will translate into BGP instabilities. The only way around this is to use a combination of statically defined prefixes in conjuction with the network command. This will make sure that the prefixes will always remain in the IP routing tables and will always be advertised.

In the previous example, if you wanted to make sure that the fluctuations of route 192.68.10.0/24 do not translate into fluctuations in the BGP, you would include in RTA a static route of the form:

    ip route 192.68.10.0 255.255.255.0 Ethernet1

By using the static approach, the prefix entry will always be present in the IP routing table and will always be advertised. The drawback of this approach is that even when a route is down, it will still be advertised by BGP. Considering the gain in network stability compared to the damage an ill-behaved route or multiple ill-behaved routes can cause, administrators may find this approach very efficient.

RTA configuration:

    router bgp 3
     network 172.16.1.0 mask 255.255.255.0
     network 172.16.65.0 mask 255.255.255.192
     network 172.16.220.0 mask 255.255.255.0
     network 192.68.5.0
     network 192.68.10.0
     neighbor 172.16.20.1 remote-as 1
     no auto-summary
    ip route 192.68.10.0 mask 255.255.255.0    Ethernet1

The preceding configuration will make sure that 192.68.10.0/24 is always sent. Note that RTA itself is originating the 192.68.10.0/24 prefix and is not relying on the advertisement coming from RTF. In case an aggregate is advertised via a static route, it is better to point the static route to null 0 (pit bucket) for loop prevention.