If secondary addresses are required in the transition, they must be configured before any of the host addressing, NAT, or access lists can be changed. The old routing protocol also might need updating to include the new networks in its network commands if you want it to route for these networks.

Use the ip address address mask secondary interface configuration command to assign a secondary IP address to an interface.

Example 7-1 shows a sample configuration with a primary and a secondary address configured on FastEthernet 0/0.

Router#show run
<output omitted>
interface FastEthernet0/0
ip address 172.17.1.3 255.255.255.240 secondary
ip address 10.1.2.3 255.255.255.0

Some routing protocols have issues with secondary addresses.

EIGRP and OSPF do not accept an update from, or form a neighbor relationship with, a router on the wrong subnet; EIGRP constantly generates error messages in this situation. Therefore, you must use the same subnet for the primary addresses on neighbor routers; do not use the same subnet for the secondary address on one router and the primary address on its neighbor.

Cisco routers use the following two parameters to select the best path when they learn two or more routes to the same destination from different routing protocols:

Table 7-1 lists the default administrative distance (believability) of protocols supported by Cisco (this is a copy of Table 2-2).

When using route redistribution, you might occasionally need to modify a protocol’s administrative distance so that it is preferred. For example, if you want the router to select RIP-learned routes rather than OSPF-learned routes for some specific destination, you must increase the OSPF administrative distance or decrease the RIP administrative distance for the routes to that destination. Modifying the administrative distance is discussed in the later section “Using Administrative Distance to Influence the Route-Selection Process.”

When a router is redistributing, it must assign a metric to the redistributed routes.

Redistributed routes are not physically connected to a router; rather, they are learned from other sources (such as other routing protocols). If a boundary router is to redistribute information between routing protocols, it must be capable of translating the metric of the received route from the source routing protocol into the other routing protocol. For example, if a boundary router receives a RIP route, the route has hop count as a metric. To redistribute the route into OSPF, the router must translate the hop count into a cost metric that the other OSPF routers will understand.

This metric, referred to as the seed or default metric, is defined during redistribution configuration. After the seed metric for a redistributed route is established, the metric increments normally within the autonomous system. (The exception to this rule is OSPF E2 routes, which hold their initial metric regardless of how far they are propagated across an autonomous system.)

The default-metric router configuration command establishes the seed metric for all redistributed routes. Cisco routers also allow the seed metric to be specified as part of the redistribute command, either with the metric option or by using a route map. These commands are discussed in detail in the later section “Configuring Redistribution.”

Table 7-2 lists the default seed metric value for routes that are redistributed into each IP routing protocol. A metric of infinity tells the router that the route is unreachable and, therefore, should not be advertised. Therefore, when redistributing routes into RIP, IGRP, and EIGRP, you must specify a seed metric, or the redistributed routes will not be advertised.

For OSPF, the redistributed routes have a default type 2 (E2) metric of 20, except for redistributed BGP routes, which have a default type 2 metric of 1.

For IS-IS, the redistributed routes have a default metric of 0. But unlike RIP, IGRP, or EIGRP, a seed metric of 0 is not treated as unreachable by IS-IS. Configuring a seed metric for redistribution into IS-IS is recommended.

For BGP, the redistributed routes maintain the IGP routing metrics.

Figure 7-3 illustrates an example with an OSPF seed metric of 30 for redistributed RIP routes on Router C. The link cost of the Serial link to Router D is 100. The routes are redistributed as E2 routes, so the cost for networks 172.16.0.0, 172.17.0.0, and 172.18.0.0 in Router D is only the seed metric (30). Notice that the metrics of the three networks in the RIP cloud are irrelevant in the OSPF cloud, because the router in the OSPF network (Router D) forwards any traffic for these three networks to the border (redistributing) router, Router C. Router C then forwards the traffic within the RIP network appropriately.

Figure 7-3. Redistribution Between OSPF and EIGRP

The following two methods of redistribution are available:

If redistribution must be done in both directions or on multiple boundary routers, the redistribution should be tuned to avoid problems such as suboptimal routing and routing loops. Depending on your network design, you may use any of the following redistribution techniques, as illustrated in Figure 7-4:

Figure 7-4. Redistribution Techniques

Use the redistribute protocol [process-id] [match route-type] [metric metric-value] [route-map map-tag] router configuration command to redistribute routes into RIP. This command is explained in Table 7-3.

Example 7-3 shows how to configure redistribution from OSPF process 1 into RIP. This example uses the router rip command to access the routing process into which routes need to be redistributed—the RIP routing process. The redistribute command is then used to specify the routing protocol to be redistributed into RIP. In this case, it is OSPF routing process number 1.

RtrA(config)#router rip
RtrA(config-router)#redistribute ospf ?

 <1-65535>  Process ID
RtrA(config-router)#redistribute ospf 1 ?
  match      Redistribution of OSPF routes
  metric     Metric for redistributed routes
  route-map  Route map reference
...
  <cr>

Figure 7-5 provides an example of redistributing routes into RIP. On Router A, routes from OSPF process 1 are redistributed into RIP and are given a seed metric of 3. Because no route type is specified, both internal and external OSPF routes are redistributed into RIP. Notice that Router B learns about the 172.16.0.0 network from Router A via RIP; Router B’s routing table has 172.16.0.0 installed as a RIP route.

Figure 7-5. Routes Redistributed into RIP

Use the redistribute protocol [process-id] [metric metric-value] [metric-type type-value] [route-map map-tag] [subnets] [tag tag-value] router configuration command to redistribute routes into OSPF. This command is explained in Table 7-4.

Example 7-4 shows how to configure redistribution from EIGRP autonomous system 100 into OSPF. This example uses the router ospf 1 command to access the OSPF routing process 1 into which routes need to be redistributed. The redistribute command is then used to specify the routing protocol to be redistributed into OSPF—in this case, the EIGRP routing process for autonomous system 100.

RtrA(config)#router ospf 1
RtrA(config-router)#redistribute eigrp ?

  <1-65535>  Autonomous system number
RtrA(config-router)#redistribute eigrp 100 ?

  metric         Metric for redistributed routes
  metric-type    OSPF/IS-IS exterior metric type for redistributed routes
  route-map      Route map reference
  subnets        Consider subnets for redistribution into OSPF
  tag            Set tag for routes redistributed into OSPF
...
  <cr>

Redistribution into OSPF can also be limited to a defined number of prefixes by the redistribute maximum-prefix maximum [threshold] [warning-only] router configuration command. The threshold parameter will default to logging a warning at 75 percent of the defined maximum value configured. After reaching the defined maximum number, no further routes are redistributed. If the warning-only parameter is configured, no limitation is placed on redistribution; the maximum value number simply becomes a second point where another warning messaged is logged. This command was introduced in Cisco IOS Version 12.0(25)S and was integrated into IOS versions 12.2(18)S and 12.3(4)T and later.

Figure 7-6 illustrates an example of redistributing EIGRP routes into OSPF. In this example, the default metric of 20 for OSPF is being used. The metric type is set to 1 (type 1 external [E1] routes), meaning that the metric increments whenever updates are passed through the network. Assuming the cost of the Ethernet link is 10, Router B’s cost for the 172.16.1.0 route is 20 + 10 = 30. The command contains the subnets option, so subnets are redistributed.

Figure 7-6. Routes Redistributed into OSPF

Use the redistribute protocol [process-id] [match route-type] [metric metric-value] [route-map map-tag] router configuration command to redistribute routes into EIGRP. This command is explained in Table 7-5.

Example 7-5 shows how to configure redistribution from OSPF into EIGRP autonomous system 100. This example uses the router eigrp 100 command to access the routing process into which routes need to be redistributed—in this case, the EIGRP routing process for autonomous system 100. The redistribute command is then used to specify the routing protocol to be redistributed into EIGRP autonomous system 100—in this case, OSPF routing process 1.

RtrA(config)#router eigrp 100
RtrA(config-router)#redistribute ospf ?

  <1-65535>  Process ID
RtrA(config-router)#redistribute ospf 1 ?

  match        Redistribution of OSPF routes
  metric       Metric for redistributed routes
  route-map    Route map reference
...
  <cr>

Table 7-6 shows the five parameters that comprise metric-value when redistributing into EIGRP.

Figure 7-7 illustrates an example of redistributing OSPF routes into EIGRP autonomous system 100. In this case, a metric is specified to ensure that routes are redistributed. The redistributed routes appear in Router B’s table as external EIGRP (D EX) routes. External EIGRP routes have a higher administrative distance than internal EIGRP (D) routes, so internal EIGRP routes are preferred over external EIGRP routes.

Figure 7-7. Routes Redistributed into EIGRP

The metric used in this example is interpreted as follows:

Use the redistribute protocol [process-id] [level level-value] [metric metric-value] [metric-type type-value] [route-map map-tag] router configuration command to redistribute routes into IS-IS. This command is explained in Table 7-7.

Example 7-6 shows how to configure redistribution from EIGRP autonomous system 100 into IS-IS. This example uses the router isis command to access the routing process into which routes need to be redistributed—the IS-IS routing process. The redistribute command is then used to specify the routing protocol to be redistributed into IS-IS—in this case, the EIGRP routing process for autonomous system 100.

RtrA(config)#router isis
RtrA(config-router)#redistribute eigrp 100 ?

  level-1      IS-IS level-1 routes only
  level-1-2    IS-IS level-1 and level-2 routes
  level-2      IS-IS level-2 routes only
  metric       Metric for redistributed routes
  metric-type  OSPF/IS-IS exterior metric type for redistributed routes
  route-map    Route map reference
...
  <cr>

By default, routes are introduced into IS-IS as Level 2, with a metric of 0.

Redistribution into IS-IS can also be limited to a defined number of prefixes by the redistribute maximum-prefix maximum [threshold] [warning-only | withdraw] router configuration command. The threshold parameter will default to logging a warning at 75 percent of the defined maximum value configured. After reaching the defined maximum number, no further routes are redistributed. The optional withdraw parameter will also cause IS-IS to rebuild link-state protocol data units (PDUs) (link-state packets [LSPs]) without the external (redistributed) IP prefixes. If the warning-only parameter is configured, no limitation is placed on redistribution; the maximum value number simply becomes a second point where another warning messaged is logged. This command was introduced in Cisco IOS Version 12.0(25)S and was integrated into IOS versions 12.2(18)S and 12.3(4)T and later.

Figure 7-8 illustrates an example of redistributing from EIGRP autonomous system 100 into IS-IS, on Router A. No metric is configured, so these routes have a seed metric of 0. No level type is given, so the routes are redistributed as Level 2 routes (as shown by the L2 in Router B’s routing table).

Figure 7-8. Routes Redistributed into IS-IS

Router(config)#router ospf 1
Router(config-router)#redistribute isis ?
<output omitted>
  level-1              IS-IS level-1 routes only
  level-1-2            IS-IS level-1 and level-2 routes
  level-2              IS-IS level-2 routes only
<output omitted>

If you use the default-metric command, the default metric you specify applies to all protocols being redistributed into this protocol.

If you use the metric parameter in the redistribute command, you can set a different default metric for each protocol being redistributed. A metric configured in a redistribute command overrides the value in the default-metric command for that one protocol.

When redistributing into EIGRP, use the default-metric bandwidth delay reliability loading mtu router configuration command to set the seed metric for all protocols. The parameters of this command are the same as those described earlier in Table 7-6.

When redistributing into OSPF, RIP, and BGP, use the default-metric number router configuration command for setting the seed metric. The number is the value of the metric, such as the number of hops for RIP.

There are times when you must include a subnet in a routing protocols’ network command, although you do not want the interface on which the subnet is connected to participate in the routing protocol.

Table 7-8 describes the parameters of this command.

When you use the passive-interface command with RIP and IGRP, routing updates are not sent out of the specified interface. However, the router still receives routing updates on that interface.

When you use the passive-interface command with EIGRP, hello messages are not sent out of the specified interface. Neighboring router relationships do not form with other routers that can be reached through that interface (because the hello protocol is used to verify bidirectional communication between routers). Because no neighbors are found on an interface, no other EIGRP traffic is sent.

Using the passive-interface command on a router running a link-state routing protocol also prevents the router from establishing neighboring router adjacencies with other routers connected to the interface specified in the command. The router does not send hello packets on the interface and therefore cannot establish neighbor adjacencies.

In Internet service providers (ISPs) and large enterprise networks, many distribution routers have more than 200 interfaces. Before the introduction of the passive-interface default command in Cisco IOS Software Release 12.0, network administrators would configure the routing protocol on all interfaces and then manually set the passive-interface command on the interfaces where they did not require adjacency. However, this solution meant entering many passive-interface commands. A single passive-interface default command can now be used to set all interfaces to passive by default. To enable routing on individual interfaces where you require adjacencies, use the no passive-interface command.

For example, in Figure 7-9, Routers A and B run RIP and have a network command that encompasses all their interfaces. However, the network administrator wants to run RIP only on the link between Router A and Router B. Router A has several interfaces, so the passive-interface default command is configured, and then the no passive-interface command is used for the one interface from where RIP updates are advertised. Router B has only two interfaces, so the passive-interface command is used for the one interface that does not participate in RIP routing.

Figure 7-9. passive-interface Command Restricts Routing Traffic on an Interface

It is important to understand how this configuration affects the information exchanged between Routers A, B, and C. Unless you configure another routing protocol between Routers A and B and Router C, and redistribute between it and RIP, Router A does not tell Router C about the networks it learned from Router B via RIP (or about any of Router A’s directly connected networks). Likewise, Router B does not tell Router C that it has a way to reach the networks advertised by Router A via RIP (or about any of Router B’s directly connected networks). Physical redundancy is built into this network; however, the three routers might not be able to use the redundancy effectively if they are not configured properly. For example, if the link between Routers C and A fails, Router C does not know that it has an alternative route through Router B to reach Router A.

This section shows an example of route redistribution in a network using multiple routing protocols.

Figure 7-10 shows the network of a hypothetical company. The network begins with two routing domains (or autonomous systems)—one using OSPF and one using RIPv2. Router B is the boundary router; it connects directly to one router within each routing domain and runs both protocols. Router A is in the RIPv2 domain and advertises subnets 10.1.0.0, 10.2.0.0, and 10.3.0.0 to Router B. Router C is in the OSPF domain and advertises subnets 10.8.0.0, 10.9.0.0, 10.10.0.0, and 10.11.0.0 to Router B.

Figure 7-10. Sample Network Before Redistribution

Figure 7-10 also shows the configuration of Router B. RIPv2 is required to run on the serial 0/0/1 interface only, so the passive-interface command is configured for interface serial 0/0/2 to prevent RIPv2 from sending route advertisements out that interface. OSPF is configured on interface serial 0/0/2.

Figure 7-11 shows the routing tables for Routers A, B, and C. Each routing domain is separate, and routers within them only recognize routes communicated from their own routing protocols. The only router with information on all the routes is Router B, the boundary router that runs both routing protocols and connects to both routing domains.

Figure 7-11. Routing Tables Before Redistribution

The goal of redistribution in this network is for all routers to recognize all routes within the company. To accomplish this goal, RIPv2 routes are redistributed into OSPF, and OSPF routes are redistributed into RIPv2. Router B is the boundary router, so the redistribution is configured on it, as shown in Figure 7-12.

Figure 7-12. Redistribution Configured on Router B

RIPv2 is redistributed into the OSPF process, and the metric is set using the redistribute command. A metric value of 300 is selected because it is a worse metric than any belonging to a native OSPF route.

Routes from OSPF process 1 are redistributed into the RIPv2 process with a metric of 5. A value of 5 is chosen because it is higher than any metric in the RIP network.

Figure 7-13 shows the routing tables of all three routers after redistribution is complete; Routers A and C now have routes to all the subnets that Router B learned from the other routing protocol. There is complete reachability; however, Routers A and C now have many more routes to keep track of than before. They also will be affected by any topology changes in the other routing domain.

Figure 7-13. Routing Tables After Redistribution

Depending on the network requirements, you can increase efficiency by summarizing the routes before redistributing them. Remember that route summarization hides information, so if routers in the other autonomous systems are required to track topology changes within the entire network, route summarization should not be performed. A more typical case is that the routers need to recognize topology changes only within their own routing domains, so performing route summarization is appropriate.

If routes are summarized before redistribution, each router’s routing tables are significantly smaller. Figure 7-14 shows the routing tables after summarization has been configured. Router B benefits the most; it now has only four routes to keep track of instead of nine. Router A has five routes instead of eight, and Router C has six routes to keep track of instead of eight. The configurations on Routers A and C are also shown in Figure 7-14.

Figure 7-14. Routing Tables After Summarization

For RIPv2 on Router A, the summarization command is configured on the interface connecting to Router B, interface S0/0/0. Interface S0/0/0 advertises the summary address instead of the individual subnets. (Note that when RIPv2 is configured, the subnet mask of the summary address must be greater than or equal to the default mask for the major classful network.) 10.0.0.0 255.252.0.0 summarizes the four subnets on Router A (including the 10.0.0.0/30 subnet).

For OSPF, summarization must be configured on an area border router (ABR) or an ASBR. Therefore, OSPF area 1 is created to include the four subnets to be summarized. Router C becomes an ABR, and the summarization command is configured under the OSPF process on Router C. 10.8.0.0 255.252.0.0 summarizes the four subnets on Router C.

Figure 7-16 shows the general process that a router uses when filtering routing updates using a distribute list that is based on the incoming or outgoing interface. The process includes the following steps:

Figure 7-16. Route Filters Using a Distribute List

You can filter routing update traffic for any protocol by defining an access list and applying it to a specific routing protocol using the distribute-list command. A distribute list enables the filtering of routing updates coming into or out of a specific interface from neighboring routers using the same routing protocol. A distribute list also allows the filtering of routes redistributed from other routing protocols or sources. To configure a distribute list, follow this procedure:

Figure 7-17 shows the topology of a WAN in which network 10.0.0.0 must be hidden from the devices in network 192.168.5.0.

Figure 7-17. Network 10.0.0.0 Needs to Be Hidden from Network 192.168.5.0

Example 7-10 is the configuration of Router B in Figure 7-17. In this example, the distribute-list out command applies access list 7 to packets going out interface Serial 0/0/0. The access list allows only routing information about network 172.16.0.0 to be distributed out Router B’s Serial 0/0/0 interface. The implicit deny any at the end of the access list prevents updates about any other networks from being advertised. As a result, network 10.0.0.0 is hidden.

router eigrp 1
  network 172.16.0.0
  network 192.168.5.0
  distribute-list 7 out Serial0/0/0
!
access-list 7 permit 172.16.0.0 0.0.255.255

With mutual redistribution, using a distribute list helps prevent route feedback and routing loops. Route feedback occurs when routes originally learned from one routing protocol are redistributed back into that protocol. Figure 7-18 illustrates an example in which redistribution is configured both ways between RIPv2 and OSPF (two-way redistribution). The configuration on Router B is shown in Example 7-11.

Figure 7-18. Router B Controls Redistribution

router ospf 1
  network 10.0.0.8 0.0.0.3 area 0
  redistribute rip subnets
  distribute-list 2 out rip

router rip
  network 10.0.0.0
  version 2
  passive-interface Serial0/0/3
  redistribute ospf 1 metric 5
  distribute-list 3 out ospf 1

access-list 2 deny 10.8.0.0 0.3.255.255
access-list 2 permit any

access-list 3 permit 10.9.0.0

Router B redistributes networks 10.1.0.0 to 10.3.0.0 from RIPv2 into OSPF. Route feedback could occur if Router D, another redistribution point, is configured, and OSPF on Router D then redistributes those same networks back into RIP. Router D’s configuration would be similar to Router B’s configuration.

Therefore, the configuration in Example 7-11 shows a distribute list configuration that prevents route feedback. Access list 2 denies the original OSPF routes and permits all others; the distribute list configured under OSPF refers to this access list. The result is that networks 10.8.0.0 to 10.11.0.0, originated by OSPF, are not redistributed back into OSPF from RIPv2. All other routes are redistributed into OSPF. Redistribution from OSPF into RIPv2 is filtered with access list 3; note that this is a more restrictive filter that permits only one route, 10.9.0.0, to be redistributed into RIPv2.

A distribute list hides network information, which could be considered a drawback in some circumstances. For example, in a network with redundant paths, a distribute list might permit routing updates for only specific paths, to avoid routing loops. In this case, other routers in the network might not know about the other ways to reach the filtered networks, so if the primary path goes down, the backup paths are not used because the rest of the network does not know they exist. When redundant paths exist, you should use other techniques, such as manipulating the administrative distance or metric, instead of distribute lists, to enable the use of an alternative path (with a worse administrative distance or metric) when the primary path goes down.

Network administrators use route maps for a variety of purposes. Several of the more common applications for route maps are as follows:

Route maps are complex access lists that allow some conditions to be tested against the packet or route in question using match commands. If the conditions match, some actions can be taken to modify attributes of the packet or route; these actions are specified by set commands.

A collection of route map statements that have the same route map name are considered one route map. Within a route map, each route map statement is numbered and therefore can be edited individually.

The statements in a route map correspond to the lines of an access list. Specifying the match conditions in a route map is similar in concept to specifying the source and destination addresses and masks in an access list.

The route-map map-tag [permit | deny] [sequence-number] global configuration command can be used to define a route map. This command is explained in detail in Table 7-11.

The default for the route-map command is permit, with a sequence-number of 10.

A route map may be made up of multiple route map statements. The statements are processed top-down, similar to an access list. The first match found for a route is applied. The sequence number is also used for inserting or deleting specific route map statements in a specific place in the route map.

The match condition route map configuration commands are used to define the conditions to be checked. The set condition route map configuration commands are used to define the actions to be followed if there is a match and the action to be taken is permit. (The consequences of a deny action depend on how the route map is being used.)

A single match statement may contain multiple conditions. At least one condition in the match statement must be true for that match statement to be considered a match (this is a logical OR operation). A route map statement may contain multiple match statements. All match statements in the route map statement must be considered true for the route map statement to be considered matched. (This is a logical AND operation.)

For example, IP standard or extended access lists can be used to establish match criteria using the match ip address {access-list-number | name} [...access-list-number | name] route map configuration command. If multiple access lists are specified, matching any one results in a match. A standard IP access list can be used to specify match criteria for a packet’s source address; extended access lists can be used to specify match criteria based on source and destination addresses, application, protocol type, type of service (ToS), and precedence.

The sequence number specifies the order in which conditions are checked. For example, if two statements in a route map are named MYMAP, one with sequence 10 and the other with sequence 20, sequence 10 is checked first. If the match conditions in sequence 10 are not met, sequence 20 is checked.

Like an access list, an implicit deny any appears at the end of a route map. The consequences of this deny depend on how the route map is being used.

Another way to explain how a route map works is to use a simple example and see how a router would interpret it. Example 7-12 shows a sample route map configuration. (Note that on a router, all the conditions and actions shown would be replaced with specific conditions and actions, depending on the exact match and set commands used.)

route-map demo permit 10
  match x y z
  match a
  set b
  set c
route-map demo permit 20
  match q
  set r
route-map demo permit 30

The route map named demo in Example 7-12 is interpreted as follows:

The redistribute commands discussed in the “Configuring Redistribution” section all have a route-map option with a map-tag parameter. This parameter refers to a route map configured with the route-map map-tag [permit | deny] [sequence-number] global configuration command, as described earlier in Table 7-11.

The match condition route map configuration commands are used to define the conditions to be checked. Table 7-12 lists some of the variety of match criteria that can be defined; some of these commands are used for BGP policy, some for PBR, and some for redistribution filtering.

The set condition route map configuration commands change or add characteristics, such as metrics, to any routes that have met a match criterion and the action to be taken is permit. (The consequences of a deny action depend on how the route map is being used.) Table 7-13 lists some of the variety of set commands that are available. Not all the set commands listed here are used for redistribution purposes; the table includes commands for BGP and PBR.

Example 7-13 illustrates a route map being used to redistribute RIPv1 into OSPF 10. The route map, called redis-rip, is used in the redistribute rip route-map redis-rip subnets command under the OSPF process.

router ospf 10
  redistribute rip route-map redis-rip subnets

route-map redis-rip permit 10
  match ip address 23 29
  set metric 500
  set metric-type type-1

route-map redis-rip deny 20
  match ip address 37

route-map redis-rip permit 30
  set metric 5000
  set metric-type type-2

access-list 23 permit 10.1.0.0 0.0.255.255
access-list 29 permit 172.16.1.0 0.0.0.255
access-list 37 permit 10.0.0.0 0.255.255.255

Sequence number 10 of the route map is looking for an IP address match in access list 23 or access list 29. Routes 10.1.0.0/16 and 172.16.1.0/24 match these lists. If a match is found, the router redistributes the route into OSPF with a cost metric of 500 and sets the new OSPF route to external type 1.

If there is no match to sequence number 10, sequence number 20 is checked. If there is a match in access list 37 (10.0.0.0/8), that route is not redistributed into OSPF, because sequence number 20 specifies deny.

If there is no match to sequence number 20, sequence number 30 is checked. Because sequence number 30 is a permit and there is no match criterion, all remaining routes are redistributed into OSPF with a cost metric of 5000 and an external metric of type 2.

There is a possibility that routing feedback might cause suboptimal routing or a routing loop when routes are redistributed at more than one router. Figure 7-19 illustrates a network in which mutual redistribution (redistribution in both directions) is configured on Routers A and B. To prevent redistribution feedback loops, route maps are configured on both routers.

Figure 7-19. Route Maps Can Help Avoid Route Feedback Loops

The potential for routing feedback becomes apparent if you follow the advertisements for a specific network before route maps are configured. For example, RIPv2 on Router C advertises network 192.168.1.0. Routers A and B redistribute the network into OSPF. OSPF then advertises the route to its neighbor OSPF routers as an OSPF external route. The route passes through the OSPF autonomous system and eventually makes its way back to the other edge router. Router B (or A) then redistributes 192.168.1.0 from OSPF back into the original RIPv2 network; this is a routing feedback loop.

To prevent the routing feedback loop, a route map has been applied to Routers A and B, as shown in Example 7-14. The route-map statement with sequence number 10 refers to access list 1, which matches the original RIPv2 network. (The access list should include all networks in the RIPv2 domain.) This route map statement is a deny, so the 192.168.1.0 route is denied from being redistributed back into RIPv2. If the route does not match sequence number 10, the router then checks sequence number 20, which is an empty permit statement. This statement matches all routes, so all other routes are redistributed into RIP.

access-list 1 permit 192.168.1.0 0.0.0.255

route-map pacific deny 10
  match ip address 1

route-map pacific permit 20

router rip
  redistribute ospf 10 route-map pacific

router ospf 10
  redistribute rip subnets

Recall that administrative distance is a way of ranking the trustworthiness of the sources of routing information. Administrative distance is expressed as an integer from 0 to 255, as shown earlier in Table 7-1; lower values indicate greater trustworthiness or believability.

For example, in Figure 7-20, R1 chooses different paths to get to the 10.0.0.0/8 network on R6, depending on the routing protocol configured. If RIP, IS-IS, OSPF, and EIGRP are all configured on all routers in this network, the protocols make the following path decisions:

Figure 7-20. Path Selected Through a Network Depends on the Routing Protocols Configured

Because EIGRP has the lowest administrative distance of the four protocols, only the EIGRP path to 10.0.0.0/8 is put into the routing table.

In some cases, you will find that a router selects a suboptimal path because it believes a routing protocol that actually has a poorer route, because it has a better administrative distance. One way to make sure that routes from the desired routing protocol are selected is to assign a higher administrative distance to the route(s) from the undesired routing protocol.

For all protocols except EIGRP and BGP, use the distance administrative-distance [address wildcard-mask [ip-standard- list] [ip-extended-list]] router configuration command, as explained in Table 7-14, to change the default administrative distances.

For EIGRP, use the distance eigrp internal-distance external-distance router configuration command, as explained in Table 7-15. By default, natively learned routes have an administrative distance of 90, but external routes have an administrative distance of 170.

For BGP, use the distance bgp external-distance internal-distance local-distance router configuration command to change the administrative distances, as explained in Table 7-16.

For OSPF, you can also use the distance ospf {[intra-area dist1] [inter-area dist2] [external dist3]} router configuration command to define the OSPF administrative distances based on route type, as explained in Table 7-17.

Figure 7-21 illustrates a network using multiple routing protocols, RIPv2 and OSPF. There are a number of ways to correct path-selection problems in a redistribution environment. The purpose of this example is to show how a problem can occur, where it appears, and one possible way to resolve it.

Figure 7-21. Sample Redistribution Network Topology

Recall that OSPF is by default considered more believable than RIPv2 because it has an administrative distance of 110 and RIPv2 has an administrative distance of 120. For example, if a boundary router (P3R1 or P3R2) learns about network 10.3.3.0 via RIPv2 and also via OSPF, the OSPF route is inserted into the routing table. This route is used because OSPF has a lower administrative distance than RIPv2, even though the path via OSPF might be the longer (worse) path.

Example 7-15 and Example 7-16 illustrate the configurations for the P3R1 and P3R2 routers. These configurations redistribute RIPv2 into OSPF and OSPF into RIPv2 on both routers.

hostname P3R1
!
router ospf 1
 redistribute rip metric 10000 metric-type 1 subnets
 network 172.31.0.0 0.0.255.255 area 0
!
router rip
 version 2
 redistribute ospf 1 metric 5
 network 10.0.0.0
 no auto-summary

hostname P3R2
!
router ospf 1
 redistribute rip metric 10000 metric-type 1 subnets
 network 172.31.0.0 0.0.255.255 area 0
!
router rip
 version 2
 redistribute ospf 1 metric 5
 network 10.0.0.0
 no auto-summary

The RIPv2 routes redistributed into OSPF have an OSPF seed metric of 10,000 to make these routes less preferred than native OSPF routes and to protect against route feedback. The redistribute command also sets the metric type to 1 (external type 1) so that the route metrics continue to accrue. The routers also redistribute subnet information.

The OSPF routes redistributed into RIPv2 have a RIP seed metric of five hops to also protect against route feedback.

Example 7-17 displays the routing table on the P3R2 router after redistribution has occurred. Even though the P3R2 router learns RIPv2 and OSPF routes, it lists only OSPF routes in the routing table, because they have a lower administrative distance.

P3R2#show ip route
<output omitted>
Gateway of last resort is not set

     172.31.0.0/24 is subnetted, 1 subnet
C       172.31.3.0/24 is directly connected, Serial0/0/0
     10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
O E1    10.3.1.0/24 [110/10781] via 172.31.3.1, 00:09:47, Serial0/0/0
O E1    10.3.3.0/24 [110/10781] via 172.31.3.1, 00:04:51, Serial0/0/0
C       10.3.2.0/24 is directly connected, FastEthernet0/0
O E1    10.200.200.31/32 [110/10781] via 172.31.3.1, 00:09:48, Serial0/0/0
O E1    10.200.200.34/32 [110/10781] via 172.31.3.1, 00:04:52, Serial0/0/0
C       10.200.200.32/32 is directly connected, Loopback0
O E1    10.200.200.33/32 [110/10781] via 172.31.3.1, 00:04:52, Serial0/0/0
O E2    10.254.0.0/24 [110/50] via 172.31.3.3, 00:09:48, Serial0/0/0
P3R2

The first edge router on which redistribution is configured, P3R1 in this case, has a routing table that contains both OSPF and RIPv2 routes, as you would expect. The routers in the OSPF domain learn about the routes from the RIPv2 domain via redistribution; they then advertise these RIPv2 routes via OSPF routes to their neighboring routers. Thus, the second edge router, P3R2, receives information about the RIPv2 domain routes (also called the native RIPv2 routes) from both OSPF and RIPv2. P3R2 prefers the OSPF routes because OSPF has a lower administrative distance; therefore, none of the RIPv2 routes appears in the P3R2 routing table.

Refer to Figure 7-21 to trace some of the routes. The redistribution has resulted in suboptimal paths to many of the networks. For instance, 10.200.200.34 is a loopback interface on router P3R4. P3R4 is directly attached to P3R2; however, from P3R2 the OSPF path to that loopback interface goes through P3R1, and then P3R3, and then P3R4 before it reaches its destination. The OSPF path taken is actually a longer (worse) path than the more direct RIPv2 path.

You can change the administrative distance of the redistributed RIPv2 routes to ensure that the boundary routers select the native RIPv2 routes. Example 7-18 and Example 7-19 show the configurations on the P3R1 and P3R2 routers. The distance command changes the administrative distance of the OSPF routes to the networks that match access list 64 to 125 (from 110). Table 7-18 describes some of the command parameters used in the example configurations.

hostname P3R1
!
router ospf 1
 redistribute rip metric 10000 metric-type 1 subnets
 network 172.31.0.0 0.0.255.255 area 0
 distance 125 0.0.0.0 255.255.255.255 64
!
router rip
 version 2
 redistribute ospf 1 metric 5
 network 10.0.0.0
 no auto-summary
!
access-list 64 permit 10.3.1.0
access-list 64 permit 10.3.3.0
access-list 64 permit 10.3.2.0
access-list 64 permit 10.200.200.31
access-list 64 permit 10.200.200.32
access-list 64 permit 10.200.200.33
access-list 64 permit 10.200.200.34

hostname P3R2
!
router ospf 1
 redistribute rip metric 10000 metric-type 1 subnets
 network 172.31.0.0 0.0.255.255 area 0
 distance 125 0.0.0.0 255.255.255.255 64
!
router rip
 version 2
 redistribute ospf 1 metric 5
 network 10.0.0.0
 no auto-summary
!
access-list 64 permit 10.3.1.0
access-list 64 permit 10.3.3.0
access-list 64 permit 10.3.2.0
access-list 64 permit 10.200.200.31
access-list 64 permit 10.200.200.32
access-list 64 permit 10.200.200.33
access-list 64 permit 10.200.200.34

Access list 64 is used to match all the native RIPv2 routes. The access-list 64 permit 10.3.1.0 command configures a standard access list to permit the 10.3.1.0 network; similar access list statements permit the other internal native RIPv2 networks. Table 7-19 describes some of the command parameters used in the examples.

Both P3R1 and P3R2 are configured to assign an administrative distance of 125 to routes listed in access list 64, which it learns from OSPF. Access list 64 has permit statements for the internal native RIPv2 networks 10.3.1.0, 10.3.2.0, and 10.3.3.0 and the loopback networks 10.200.200.31, 10.200.200.32, 10.200.200.33, and 10.200.200.34. Therefore, when either of these routers learns about these networks from both RIPv2 and OSPF, it selects the routes learned from RIPv2—with a lower administrative distance of 120—over the same routes learned from OSPF (via redistribution from the other boundary router)—with an administrative distance of 125—and puts only the RIPv2 routes in the routing table.

You need to configure the distance command on both redistributing routers because either one can have suboptimal routes, depending on which redistributing router sends the OSPF updates about the RIPv2 networks to the other redistributing router first.

Example 7-20 shows that Router P3R2 now retains the more direct paths to the internal networks by learning them from RIPv2.

P3R2#show ip route
<output omitted>
Gateway of last resort is not set

     172.31.0.0/24 is subnetted, 1 subnet
C       172.31.3.0/24 is directly connected, Serial0/0/0
     10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
R       10.3.1.0/24 [120/2] via 10.3.2.4, 00:00:03, FastEthernet0/0
R       10.3.3.0/24 [120/1] via 10.3.2.4, 00:00:03, FastEthernet0/0
C       10.3.2.0/24 is directly connected, FastEthernet0/0
R       10.200.200.31/32 [120/3] via 10.3.2.4, 00:00:04, FastEthernet0/0
R       10.200.200.34/32 [120/1] via 10.3.2.4, 00:00:04, FastEthernet0/0
C       10.200.200.32/32 is directly connected, Loopback0
R       10.200.200.33/32 [120/2] via 10.3.2.4, 00:00:04, FastEthernet0/0
O E2    10.254.0.0/24 [110/50] via 172.31.3.3, 00:00:04, Serial0/0/0

P3R2#

However, some routing information is lost with this configuration. For example, depending on the actual bandwidths, the OSPF path might have been better for the 10.3.1.0 network; it might have made sense not to include 10.3.1.0 in the access list for P3R2.

This example illustrates the importance of knowing your network before implementing redistribution and closely examining which routes the routers select after redistribution is enabled. You should pay particular attention to routers that can select from a number of possible redundant paths to a network, because they may select suboptimal paths.

Figure 7-23 shows the steps that occur when a DHCP client requests an IP address from a DHCP server.

Figure 7-23. DHCP Operation

A DHCP client may receive offers from multiple DHCP servers and can accept any one of the offers; the client usually accepts the first offer it receives. An offer from the DHCP server is not a guarantee that the IP address will be allocated to the client; however, the server usually reserves the address until the client has had a chance to formally accept the address.

DHCP supports three possible address allocation mechanisms:

An address binding is the mapping between the client’s IP and hardware (MAC) addresses. The client’s IP address can be configured by the administrator (manual address allocation) or assigned from a pool by the DHCP server.

On Cisco IOS devices, DHCP address pools are stored in nonvolatile RAM (NVRAM). There is no limit on the number of address pools.

Manual bindings are also stored in NVRAM. Manual bindings are just special address pools configured by a network administrator. There is no limit on the number of manual bindings.

Automatic bindings are IP addresses that have been automatically mapped to the MAC addresses of hosts that are found in the DHCP database. Automatic bindings are stored on a remote host called the database agent, which is any host—for example, a File Transfer Protocol (FTP), TFTP, or Remote Copy Protocol (RCP) server—that stores the DHCP bindings database. The bindings are saved as text records for easy maintenance.

You can configure multiple DHCP database agents and you can configure the interval between database updates and transfers for each agent.

The DHCP server database is organized as a tree. The root of the tree is the address pool for networks, branches are subnetwork address pools, and leaves are bindings to clients. Subnetworks inherit network parameters and clients inherit subnetwork parameters. Therefore, common parameters, for example the domain name, should be configured at the highest (network or subnetwork) level of the tree.

Inherited parameters can be overridden. For example, if a parameter is defined for both the network and a subnetwork, the definition of the subnetwork is used.

Address leases are not inherited. If a lease is not specified for an IP address, by default, the DHCP server assigns a one-day lease for the address.

Configuration parameters and other control information are carried in tagged data items that are stored in the options field of the DHCP message. Options provide a method of appending additional information.

The Cisco IOS DHCP implementation also allows most DHCP server options to be customized. For example, the Cisco IOS image can be customized with option 150 to support intelligent IP phones.

Before configuring a Cisco IOS DHCP server, the following items should be identified:

The Cisco IOS DHCP server and relay agent are enabled by default. You can verify if they have been disabled by checking your configuration file. If they have been disabled, the no service dhcp command will appear in the configuration file; use the service dhcp global configuration command to reenable the functionality if necessary.

The following are some of the possible tasks when configuring a Cisco IOS DHCP server. (The commands are described in Table 7-20 later in this section.)

Table 7-20 describes some of the commands used to configure a Cisco IOS DHCP server, in logical order.

In Example 7-21, three DHCP address pools are created: one in network 172.16.0.0, one in subnetwork 172.16.1.0, and one in subnetwork 172.16.2.0. Attributes from network 172.16.0.0—such as the domain name, DNS server, NetBIOS name server, and NetBIOS node type—are inherited in subnetworks 172.16.1.0 and 172.16.2.0. In pools 1 and 2, clients are granted 30-day leases. All addresses in each subnetwork, except the excluded addresses, are available to the DHCP server for assigning to clients. Table 7-21 lists the IP addresses for the devices in three DHCP address pools.

ip dhcp database ftp://user:[email protected]/router-dhcp write-delay 120
ip dhcp excluded-address 172.16.1.100 172.16.1.103
ip dhcp excluded-address 172.16.2.100 172.16.2.103
!
ip dhcp pool 0
 network 172.16.0.0 /16
 domain-name cisco.com
 dns-server 172.16.1.102 172.16.2.102
 netbios-name-server 172.16.1.103 172.16.2.103
 netbios-node-type h-node
!
ip dhcp pool 1
 network 172.16.1.0 /24
 default-router 172.16.1.100 172.16.1.101
 lease 30
!
ip dhcp pool 2
 network 172.16.2.0 /24
 default-router 172.16.2.100 172.16.2.101
 lease 30

In the past, each Cisco IOS DHCP server had to be configured separately with all parameters and options. The Cisco IOS has been revised to allow remote Cisco IOS DHCP servers to import option parameters from a centralized server.

Figure 7-24 and Example 7-22 and Example 7-23 illustrate a central and remote server configured to support the importing of DHCP options. The central server is configured with DHCP options, such as DNS and WINS addresses. In response to a DHCP request from a local client, the remote server can request or “import” these option parameters from the centralized server.

Figure 7-24. DHCP Options Import

! Do not assign this range to DHCP clients
ip dhcp-excluded address 10.0.0.1 10.0.0.5
!
ip dhcp pool central
! Specifies the network number and mask for DHCP clients
 network 10.0.0.0 255.255.255.0
! Specifies the domain name for the client
 domain-name central
! Specifies the DNS server that will respond to DHCP clients when they
! need to correlate host name to IP address
 dns-server 10.0.0.2
! Specifies the NETBIOS WINS server
 netbios-name-server 10.0.0.2
!
interface FastEthernet0/0
 ip address 10.0.0.1 255.255.255.0
 duplex auto
 speed auto

ip dhcp pool client
! Specifies the network number and mask for DHCP clients
 network 172.16.1.0 255.255.255.0
! Import DHCP option parameters into DHCP server database
 import all
!
interface FastEthernet0/0
! Specifies that the interface acquires an IP address through DHCP
 ip address dhcp
 duplex auto
 speed auto

The Cisco IOS DHCP server and relay agent are enabled by default. However, the Cisco IOS DHCP relay agent is enabled on an interface only when a helper address is configured to enable DHCP broadcasts received on the interface to be forwarded to the configured DHCP server.

DHCP clients use UDP broadcasts to send their initial DHCPDISCOVER message, because they do not have information about the network to which they are attached. If the client is on a network that does not include a server, UDP broadcasts are normally not forwarded by the attached router, as illustrated in Figure 7-25.

Figure 7-25. Routers Do Not Forward Broadcasts, by Default

The ip helper-address address interface configuration command causes UDP broadcasts received on the interface to be changed to a unicast and forwarded out another interface to the unicast IP address specified by the command. The relay agent sets the gateway address (the giaddr field of the DHCP packet) and, if configured, adds the relay agent information option (option 82) in the packet and forwards it to the DHCP server. The reply from the server is forwarded back to the client after removing option 82. Figure 7-26 illustrates the use of the ip helper-address command to implement a DHCP relay agent. Example 7-24 provides the helper address configuration for the router in this figure.

Figure 7-26. IP Helper Address Example

interface FastEthernet0/0
 ip address 172.16.1.100 255.255.255.0
 ip helper-address 172.16.2.1
 ip helper-address 172.16.2.2
 ip helper-address 172.16.3.2

By default, the ip helper-address command enables forwarding of packets sent to all the well-known UDP ports that may be included in a UDP broadcast message, which are the following:

The ip forward-protocol udp [port] global configuration command can be used to customize this feature to network requirements. Ports can be eliminated from the forwarding service with the no ip forward-protocol port global configuration command, and ports can be added to the forwarding service with the ip forward-protocol port global configuration command.

Example 7-25 illustrates an example. This configuration would cause packets sent to the Time and NetBIOS ports to not be forwarded; packets sent to UDP port 8000 would be forwarded.

interface FastEthernet0/0
 ip address 10.3.3.3 255.255.255.0
 ip helper-address 10.1.1.1
 no ip forward-protocol udp 137
 no ip forward-protocol udp 138
 no ip forward-protocol udp 37
 ip forward-protocol udp 8000

The following are some of the possible tasks when configuring a Cisco IOS DHCP relay agent (the commands are described in Table 7-22 later in this section):

Table 7-22 describes some of the commands used to configure a Cisco IOS DHCP relay agent, in logical order.