Understanding the Fundamentals of Redistribution It is rare to find just one routing protocol running within an organization. If the organization is running multiple routing protocols, you need to find some way of passing the networks learned by one routing protocol into another so that every workstation can reach every other workstation. This process is called redistribution . Redistribution is used when a router is receiving information about remote networks from various sources. Although all the networks are entered into the routing table and routing decisions are made on all the networks present in the table, a routing protocol propagates only those networks that it has learned through its own process. When there is no sharing of network information between the routing processes, it is referred to as ships in the night (SIN) routing. Redistribution is often necessary within a network, if only as a transitional implementation. Nonetheless, it should not be thought of as a quick and easy solution. Although route redistribution is often a lifesaver for your network, it is fraught with complexity. Understanding the operation of the processes that you have implemented and how this influences your network is crucial. This chapter focuses on the main topics dealing with the implementation of redistribution. Although an organization might have many routing protocols running within its autonomous system, each interior routing protocol sees itself as the only interior routing protocol within the autonomous system. When an interior routing protocol such as EIGRP has routes redistributed into its routing process, it assumes that these routes are from another autonomous system and are therefore external routes. This affects the route selection made by the routing process, and EIGRP prefers the interior routes. The exterior routing protocols see the organization as the autonomous system that connects to the Internet or a service provider. In Figure 17-1, the routing table for Router B has entries from RIP and OSPF. There are no entries for EIGRP because this is a single network directly connected to the router. You can see that the RIP updates sent out the interfaces do not include networks from OSPF. There are no entries for EIGRP. Figure 17-1. Routing Updates Without Using Redistribution  Furthermore, Router C has only connected routes in the routing table. This is because, although EIGRP has been configured, Router C is a stub router. When the other interfaces are configured with addresses and the rest of the EIGRP network is connected to Router C, the network will be populated with EIGRP routes, which it will propagate to Router B. If redistribution is then implemented, the entire network will be available to everyone. Redistribution can occur only between processes routing the same Layer 3 protocol. So, for example, OSPF, RIP, IGRP, and EIGRP can redistribute routing updates among themselves because they all support the same TCP/IP stack and share the same routing table. However, there can be no network redistribution between AppleTalk and IPX. Some routing protocols automatically exchange networks, although others require some level of configuration. Table 17-2 shows the subtleties of automatic redistribution. Table 17-2. Automatic Redistribution Between Routing Protocols | Routing Protocol | Redistribution Policy | | Static | Requires manual redistribution into other routing protocols. | | Connected | Unless included in the network command for the routing process, requires manual redistribution. | | RIP | Requires manual redistribution. | | IGRP | Will automatically redistribute between IGRP and EIGRP if the autonomous system number is the same. Otherwise, it requires manual redistribution. | | EIGRP | Will automatically redistribute between IGRP and EIGRP if the autonomous system number is the same. Otherwise, it requires manual redistribution. EIGRP for AppleTalk will automatically redistribute between EIGRP and RTMP. EIGRP for IPX will automatically redistribute between EIGRP and IPX RIP/ SAP; in later versions, NLSP can be manually redistributed. | | OSPF | Requires manual redistribution between different OSPF process IDs and routing protocols. | | IS-IS | Requires manual redistribution between different routing protocols | | BGP | Requires manual redistribution between different routing protocols | Figure 17-2 illustrates redistribution within an organization. Figure 17-2. Autonomous Systems Within an Organization  The main reasons for multiple protocols existing within an organization are as follows : -
The organization is transitioning from one routing protocol to another because there is a need for a more sophisticated protocol. -
Historically, the organization was a series of small network domains. The company has plans to transition to a single routing protocol in the future. -
Some departments might have host-based solutions that require different protocols. For example, some UNIX hosts use RIP to discover gateways. -
Often after a merger or a takeover, it takes planning, strategy, and careful analysis to determine the best overall design for the network. -
Politically, there are ideological differences among the different network administrators, which until now have not been resolved. -
In a very large environment, the various domains might have different requirements, making a single solution inefficient. A clear example is in the case of a large multinational corporation, where EIGRP is the protocol used at the access and distribution layers , but BGP is the protocol connecting the core . Understanding the Routing Decisions That Affect Redistribution When embarking on running multiple routing protocols within your network and making one cohesive whole network, redistribution is the answer, but only after careful consideration has been given to the problems that might arise. In order to do this, you need to consider briefly the routing protocol operation, in particular how a path is selected to go into the routing table. For a detailed discussion on routing tables, refer to Chapter 1, "IP Routing Principles." Path selection is dealt with in depth in Chapter 4, "IP Distance Vector Routing Principles." Routing Metrics and Redistribution There are many routing protocols for IP, and each routing protocol uses a different metric. If the different protocols want to share information through redistribution, the configuration must translate the metrics. The configuration commands are dealt with in the section "Configuring Redistribution," later in this chapter. Problems arise when the metrics are redistributed without additional configuration. The metric has no point of reference in the new routing protocol; for example, RIP would be baffled by the metric presented as 786, when expecting a hop count between 015. In accepting the new networks, the receiving process must have a starting point, or seed metric , in order to calculate the metric for the routing protocol. The seed metric is assigned to all the routes received into a process through redistribution. The metric is incremented from that point on as the networks propagate throughout the new routing domain. There are defaults for the seed metrics, but depending on the routing protocol, the default might prevent the route from entering the routing table. The seed metrics are as defined in Table 17-3. Table 17-3. Default Seed Metrics | IP Routing Protocol | Default Seed Metric | Action | | RIP | From Cisco IOS release 12.1, the seed metric is infinity | No routes entered into the routing table | | IGRP | Infinity | No routes entered into the routing table | | EIGRP | Infinity | No routes entered into the routing table | | IS-IS | | Routes entered into the routing table | | OSPF | 20 (type 2), but routes from BGP are given a metric of 1 (type 2) | Routes entered into the routing table | | BGP | MED is given the IGP metric value | Routes entered into the routing table | Remember, the metric is the main method of route selection within a routing protocol. Therefore, it is necessary to define a default seed metric for the networks accepted from the other routing protocol. Path Selection Between Routing Protocols Now that route selection within a routing protocol has been explained, this section discusses path selection between routing protocols when more than one routing protocol is running on your network. If the protocols have paths to the same remote destination network, the routing process must decide which path to enter into the routing table. Because the metrics differ between the protocols, selection based on the metric is ruled out as a solution. Instead, another method was devised to solve the problem, the administrative distance , as discussed in Chapter 4. The distinction between the two selection processes is simple : Administrative distance determines between IP routing protocols, and the metric chooses between paths from one routing protocol. Administrative distance and metrics appear to solve all your problems, until you start to redistribute the information between routing protocols, and the routing process becomes confused as to from where the information came. When the carefully determined rules of selection become tangled, suboptimal routing decisions and routing loops result. It is therefore important to consider the following rules when redistributing between IP routing protocols: -
If more than one routing protocol is running on a router, the routing table will place the route with the best administrative distance into the routing table. -
In order to be redistributed, the route must exist in the routing table under the ownership of the routing protocol that is being redistributed. Thus, if RIP is being redistributed into EIGRP, the routing table must have an entry for the RIP network. -
When a route is redistributed, it inherits the default administrative distance of the new routing protocol. -
When a route is redistributed, it is considered as an external route to the new routing protocol. For EIGRP and BGP, this means it will inherit the administrative distance of an external route to the new routing protocol. OSPF tracks the route as external and chooses internal routes first. It is clear that redistribution is not the optimum network design. The simpler and more straightforward the design, the better managed and more stable the network, with fewer errors and faster convergence. Therefore, a hierarchical IP addressing scheme designed to allow continued network growth, combined with a single IP routing protocol that has the scope to support growth, results in a strong, reliable, and fast network. However, it is rare to find a network of any size that runs only one IP routing protocol. When multiple protocols are running, it is necessary to redistribute. Although the concept of redistribution is straightforward, the design and implementation are extremely tricky. Without a full documented understanding of both the network and the traffic flow, the implementation of redistribution can result in routing loops or the selection of suboptimal paths. The problems that can occur from redistribution are typically difficult to troubleshoot because the symptoms often appear some distance from the configuration error. The problems experienced as a result of multiple routing processes and their redistribution include the following: -
The wrong, or less efficient, routing decision is made because of the difference in routing metrics. The choice of the less efficient route is referred to as choosing the suboptimal path . -
A routing loop occurs, in which the data traffic travels in a circle without ever arriving at the destination. This is normally due to routing feedback, where routers send routing information received from one autonomous system back into the same autonomous system. -
The convergence time of the network increases because of the different technologies involved. If the routing protocols converge at different rates, this might result in timeouts and the temporary loss of networks. -
The decision-making process and the information sent within the protocols might be incompatible and not easily exchanged, leading to errors and complex configuration. Avoiding Routing Loops When Redistributing Routing loops occur when a routing protocol is fed its own networks. The routing protocol might see a network as having a more favorable path, although this path points in the opposite direction, into a different routing protocol domain. The potential for confusion is enormous , and it is very easy to create routing loops when redistributing, as shown in Figure 17-3. Figure 17-3. How Route Feedback Can Cause Routing Loops  This problem is solved by the following configurations: These configurations are discussed in the section of the chapter titled "Configuring Redistribution." To manage the complexity of these networks and to reduce the possibility of routing loops, some level of restriction in the information sent across the various domains is often necessary. This is done via filtering, using access lists. Consider the problem by looking at the example in Figure 17-4, remembering that administrative distance is considered without any reference to the metrics. Imagine for a moment that Router A is running RIP and advertising network 190.10.10.0 to both Routers B and E. When Router B receives the RIP update, it redistributes the network 190.10.10.0 into OSPF and advertises it to Router C, which advertises the network to Router D. Eventually Router E receives an OSPF update from D, reporting a network 190.10.10.0 with the path D, C, B, A. However, Router E has a direct path to Router A via RIP, which would be the preferable path. In this instance, the administrative distance works against the network. Because OSPF has an administrative distance of 110 and RIP has an administrative distance of 120, the path placed in the routing table is the one advertised by OSPF via D, C, B and A. In this case, manually configuring the administrative distance on Routers B and E is advisable. Figure 17-4. Path Selection Using Administrative Distance  If EIGRP is running on Routers B, C, D, and E, there should be no problems. When RIP redistributes into EIGRP on Router B and the update is propagated to Router E, the routing table should select the route to 190.10.10.0 via Router A. The reason is that when network 190.10.10.0 is redistributed into EIGRP, it is flagged as an external route. Thus, it has the administrative distance of 170 and is discarded in favor of RIP administrative distance of 120. The routing table contains RIP's path to the network 190.10.10.0. When EIGRP then redistributes into RIP, the routing table, having no EIGRP entry for the network 190.10.10.0, cannot redistribute this network back into the RIP process. Theoretically, a routing loop is avoided. However, in practice this might not be the case, as it is dependent on when the routing updates come into the routing process and the inherent stability of the network. You should avoid two-way redistribution between routing protocols for these reasons, unless you take great care in the design of the network and place filters on the redistributing routers in order to prevent routing protocol feedback. Remember that although you can change the defaults for administrative distance, you should take care when subverting the natural path selection, and any manual configuration must be done with careful reference to the network design of the organization and its traffic flow. To change the administrative distance of a routing protocol, use the following command: Router(config-router)# distance weight [network wildcard-mask] For a static route use the following command: Router(config)# ip route network [ mask ] { address interface } [ distance ] There are additional commands to change specific types of routes on a per-protocol basis. For example, it is possible to change the administrative distance of internal or external EIGRP routes. This can also be done for OSPF and BGP. To find more on this subject, search for the keyword "distance" on the Cisco web site. The administrative distance reflects the preferred choice. The defaults are listed in Chapter 4 in Table 4-2. Avoiding Suboptimal Routing Decisions When Redistributing Routing loops are only one problem that can result from redistributing routes between routing protocols. As mentioned in the previous section, suboptimal routing is sometimes created by redistribution. For example, the administrative distance selects the suboptimal path when a directly connected network is designed as a backup link. Although this is a problem of administrative distance as opposed to redistribution, it is important to ensure that the suboptimal path is not propagated into the new routing protocol. To overcome this problemthe administrator's preferred route not coinciding with that of the routing protocola floating static route is configured, as described in Chapter 4. The following are guidelines to keep in mind when designing your network to avoid routing loops and suboptimal path selection when redistributing between routing protocols: -
Have a sound knowledge and clear documentation of the following: -
- The network topology (physical and logical) -
- The routing protocol domains -
- The traffic flow -
Do not overlap routing protocols. It is much easier if the different protocols can be clearly delineated into separate domains, with routers acting in a similar function to area border routers (ABRs) in OSPF. This is often referred to as the core and edge protocols . -
Identify the boundary routers on which redistribution is to be configured. -
Determine which protocol is the core and which protocol is the edge protocol. -
Determine the direction of redistribution, that is, into which routing protocol the routes are to be distributed. -
If redistribution is needed, ensure that it is a one-way distribution, where the one routing protocol redistributes into another routing protocol, but the other routing protocol does not redistribute back. For example, RIP redistributes into EIGRP, but EIGRP does not redistribute into RIP. This avoids networks being fed back into the originating domain. Use default routes to facilitate the use of one-way redistribution, if necessary. -
If two-way redistribution cannot be avoided, use the mechanisms in the following list: -
- Manually configuring the metric -
- Manually configuring the administrative distance -
- Using distribution access lists Avoiding Problems with Network Convergence When Redistributing To maintain consistent and coherent routing among different routing protocols, you must consider the different technologies involved. A major concern is the computation of the routing table and how long it takes the network to converge. Although EIGRP is renowned for its speed in convergence, RIP has a poorer reputation in this regard. Sharing the network information across the two technologies might cause some problems. For example, the network converges at the speed of the slower protocol. At some point, this will create timeouts and possibly routing loops. Adjusting the timers might solve the problems, but any routing protocol configuration must be done with a sound knowledge of the entire network and of the routers that need to be configured. Timers typically require every router in the network to be configured to the same value. Controlling Routing Updates During Redistribution Controlling routing updates is useful for many reasons. The reasons for controlling routing updates include: -
To hide certain networks from the rest of the organization -
To prevent routing loops -
To control the network overhead or traffic on the wire, allowing the network to scale -
For simple security reasons Various methods enable you to control the routing information sent between routers during redistribution. These methods include the following: -
Passive interfaces -
Static routes -
Default routes -
The null interface -
Distribute lists -
Route maps The next sections describe each method in more detail. Passive Interfaces A passive interface does not participate in the routing process. In RIP and IGRP, the process listens but will not send updates. In OSPF and EIGRP, the process neither listens nor sends updates because they do not send Hellos, and therefore no neighbor relationship can form. The interfaces that participate in the interior routing process are controlled by the interface configuration. During configuration, the routing process is instructed via the network command on which interfaces to use. Because most protocols express the networks at the major boundary, interfaces that have no reason to send this protocol's updates propagate the data across the network. This is not only a waste of bandwidth, but in many cases, it can lead to confusion, particularly during redistribution. The configuration of passive interfaces to prevent updates going into the domains of other routing protocols can simplify the network administration and prevent routing loops. Static Routes A static route is a route that is manually configured. It takes precedence over routes learned by a routing process because it has a lower default administrative distance. If no routing process is configured, static routes can be configured to populate the routing table. This is not practical in a large network because the table cannot learn of changes in the network topology dynamically. In small environments or for stub networks, however, this is an excellent solution. It is used to good effect when there are multiple protocols configured. Instead of redistributing the entire routing tables between the protocols, static routes are defined and redistributed. This is useful if you need to provide more information than a default route. The routing protocols have the information they need while you maintain careful control over the design and data flow. Again, this is a typical scenario for BGP and an IGP to exchange information. The reasons for static routing are summarized as follows: -
To prevent the need for a routing protocol to run on the network, reducing the network overhead to zero. This can be used with dialup lines (dial-on-demand routing). -
If there are two autonomous systems that do not need to exchange the entire routing table, but simply need to know about a few routes. -
No routing protocol is configured, for example, on a remote stub node. -
To change the mask of the network. For example, as seen in BGP, you can statically define a supernet and redistribute the static route into the BGP process. This is also done when redistributing from a routing protocol that understands VLSM to one that does not. Default Routes A default route is used if there is no entry in the routing table for the destination network. If the lookup finds no entry for the desired network and no default route is configured, the packet is dropped. If the routing process is denied the right to send updates, the downstream routers will have a limited understanding of the network. To resolve this, use default routes. Default routes reduce overhead, add simplicity, and can remove loops, particularly when used instead of redistribution between routing protocols. One routing protocol can use a default route to the other routing protocol's domain; a typical example would be an IGP pointing a default route into the BGP domain. Another occasion for configuring a default route would be for a stub network to connect to the larger network. Default and static routes are shown in Figure 17-5. Figure 17-5. The Use of Default and Static Routes  The null Interface The null interface is an imaginary interface that is defined as the next logical hop in a static route. All traffic destined for the remote network is carefully routed into a black hole. This is used to good effect in redistribution, as it is used either to discard routes by destination in a rudimentary filtering system or to redistribute between classless and classful routing protocols. It is used to feed routes into the other routing protocol, allowing another mask to be set. In this way, it aggregates routes as shown in Chapter 16, "Implementing and Tuning BGP for Use in Large Networks." Distribute Lists Distribute lists are access lists applied to the routing process, determining which networks are accepted into the routing table or sent in updates. When communicating to another routing process through redistribution, it is important to control the information sent into the other process. This control is for security, overhead, the prevention of routing loops, and management reasons. Access lists afford the greatest control for determining the traffic flow in the network. Route Maps Route maps are complex access lists that permit conditional programming. If a packet or route matches the criteria defined in a match statement, changes defined in the set command are performed on the packet or route in question. These are used in redistribution in the same way as distribute lists, but allow a greater level of sophistication in the criteria stated. Figure 17-6 shows the options for controlling routing updates in a large and complex network. Figure 17-6. Controlling Routing Updates  In Figure 17-6, Router A has a distribute list that is denying the propagation of the network 140.100.32.0 out of E3, which is the network connected to E2. Network 140.100.32.0 might have some security reasons for not being seen by the networks connected to Router B. This network could be a test or an R&D project for the department connecting to Router B, and connectivity would confuse the situation. S0 and S1 have static routes configured. In the case of S0, this is the connection into the Internet, and the static routes are configured by the ISP. This allows them to connect to the ISP without having to receive dynamic routing updates from the ISP. The routing updates from the ISP containing the Internet routing tables could be huge. The organization has a default route set so that anyone wanting to flee the organization's network can send to the default route, thus keeping the routing tables small and the update traffic to a minimum. On S1, the router's interface is configured with static routes so that the router at the other end does not need to run a routing protocol. The router at the other end has a default route configured, and the suggestion is that this is a stub network. This ensures that Router C has a simple configuration with few demands on the router. The concepts of redistribution are detailed in the following examples with configuration scripts. This will reinforce the concepts and understanding of the technology. Configuring Redistribution Redistribution configuration is specific to the routing protocol itself. Before you contemplate implementation, reference the configuration guides from Cisco. All protocols require the following steps for redistribution: - Step 1. Configure redistribution.
- Step 2. Define the default metric to be assigned to any networks that are distributed into the routing process.
The commands for redistribution are configured as subcommands to the routing process. The redistribute command identifies the routing protocol from which the updates are to be accepted. It identifies the source of the updates. These commands, discussed in detail in the next sections, constitute the basic steps in the implementation of redistribution. Depending on the design of your network, additional configuration might be needed. The configuration of administrative distance, passive interfaces, and static and default routes are provided in the section "Configuration Commands to Control Routing Updates in Redistribution." Redistribution Configuration Syntax To configure redistribution between routing protocols, the following command syntax is used under the routing protocol that receives the routes: Router(config-router)# redistribute protocol [ process-id ] { level-1 level-1-2 level-2 } [ metric metric-value ] [ metric-type type-value ] [ match { internal external 1 external 2 }] [ tag tag-value ] [ route-map map-tag ] [ weight weight ] [ subnets ] The command is very complex because it shows all the parameters for all the different protocols. For an explanation of the command parameters, refer to Table 17-4. Table 17-4. Command Description of Redistribution | Command | Description | | protocol | This is the routing protocol that provides the routes. Remember, most commands with two parameters are structured from a value to a value or from a source to a destination. Routes are redistributed from this source protocol. It can be one of the following keywords: connected, bgp, eigrp, egp, igrp, isis, iso-igrp, mobile, ospf, static , or rip . | | process-id | For BGP, EGP, EIGRP, or IGRP, this is an autonomous system number. For OSPF, this is an OSPF process ID. RIPv1 and RIPv2 do not use either a process ID or an autonomous system number. | | level-1 | For IS-IS, Level 1 routes are redistributed into other IP routing protocols independently. | | level-1-2 | For IS-IS, both Level 1 and Level 2 routes are redistributed into other IP routing protocols. | | Level-2 | For IS-IS, Level 2 routes are redistributed into other IP routing protocols independently. | | metric metric-value | This optional parameter is used to specify the metric used for the redistributed route. When redistributing into protocols other than OSPF, if this value is not specified and no value is specified using the default-metric router configuration command, routes cannot be redistributed. If the routes are redistributed, the routing table might become completely confused with mismatched metrics. Although it might be possible to configure networks to be redistributed into another protocol without specifying a metric, it is ill advised. Configure a specific or default metric, using a value consistent with the destination protocol. Remember that you are influencing the path selection made by the routing process. | | metric-type type-value | This is an optional OSPF parameter that specifies the external link type associated with the default route advertised into the OSPF routing domain. This value can be 1 for type 1 external routes, or 2 for type 2 external routes. The default is 2. Refer to Chapter 8, "Using OSPF Across Multiple Areas," for more detail on OSPF external route types. | | match | This is an optional OSPF parameter that specifies the criteria by which OSPF routes are redistributed into other routing domains. It can be one of the following: internal Redistribute routes that are internal to a specific autonomous system. external 1 Redistribute routes that are external to the autonomous system but that are imported into OSPF as a type 1 external route. external 2 Redistribute routes that are external to the autonomous system but that are imported into OSPF as a type 2 external route. | | tag tag-value | (Optional) The tag-value is a 32-bit decimal value attached to each external route. It is not used by the OSPF protocol itself, but it can be used to communicate information between autonomous system boundary routers. If no value is specified, then the remote autonomous system number is used for routes from BGP and EGP; for other protocols, zero (0) is used. | | route-map | (Optional) This instructs the redistribution process that a route map must be referenced to filter the routes imported from the source routing protocol to the current routing protocol. If it is not specified, all routes are redistributed because no filtering is performed. If this keyword is specified but no route map tags are listed, no routes will be imported. It is important, therefore, to pay attention to the configuration. | | map-tag | This is the optional identifier of a configured route map to filter the routes imported from the source routing protocol to the current routing protocol. Route maps are covered later in this chapter. | | weight weight | (Optional) This sets the attribute of network weight when redistributing into BGP. The weight determines the preferred path out of a router when there are multiple paths to a remote network. This is an integer between 0 and 65,535. | | subnets | (Optional) For redistributing routes into OSPF, this is the scope of redistribution for the specified protocol. It is important to remember that this is required to bring subnets of classful networks. | Configuring the Default Metric The default metric can be configured in several ways. The first is to include the metric in the redistribute command, defining the metric for that specific redistribution, which you saw in the preceding command syntax. You can also configure the default metric with a command defined under the routing process. Using the default-metric command saves work because it eliminates the need to define metrics separately for each redistribution. Example 17-1 shows the metric included in the redistribute command. Example 17-1. Including the Metric in the redistribute Command Router(config)# router eigrp 100 Router(config-router)# redistribute rip metric 10000 100 255 1 1500 Router(config-router)# network 140.100.0.0 This configuration shows the following: -
The use of the redistribute command -
The routing process from which the routes are being accepted -
The metric parameter, allowing the configuration of the EIGRP to state the new metric that the old RIP networks will use while traversing the EIGRP network Configuring the Default Metric for OSPF, IS-IS, RIP, EGP, or BGP It is possible to redistribute the routing protocol and then, with a separate command, to state the default metric. The advantage is that it is a simpler configuration visually, which is helpful in troubleshooting. Also, if more than one protocol is being redistributed into the routing protocol, the default metric applies to all the protocols being redistributed. IS-IS cannot define a default metric. The metric must be stated when redistributing. If no metric is stated, the default (0 cost) is entered and the route discarded. To configure the default metric for OSPF, RIP, EGP, or BGP, use the following command syntax: Router(config-router)# default-metric number The default-metric command is used in Example 17-2. Example 17-2. Configuring the Default Metric for Static and OSPF Routes Received by RIP Router(config)# router rip Router(config-router)# redistribute static Router(config-router)# redistribute ospf 25 Router(config-router)# default-metric 2 In this example, the default metric is set to 2. You are advised to set the metric to a low number so that when RIP increments the metric, it can do so without hitting the upper limit of the metric, 15. Configuring the Default Metric for EIGRP or IGRP To configure the default metric for IGRP or EIGRP, use the following command syntax: Router(config-router)# default-metric bandwidth delay reliability loading mtu Typically, you should take the values shown on one of the outgoing interfaces of the router being configured by issuing the following exec command: Router# show interface The significance of the metric values is shown in Table 17-5. Table 17-5. The Parameters of the default-metric Command | Command Parameter | Description | | bandwidth | The minimum bandwidth seen on the route to the destination. It is presented in kilobits/per second (kbps). | | delay | The delay experienced on the route and presented in tens of microseconds. | | reliability | The probability of a successful transmission given the history of this interface. The value is not used. It is expressed in a number from 0 to 255, where 255 is indicates that the route is stable and available. | | loading | A number range of 0 to 255, where 255 indicates that the line is 100 percent loaded. This parameter is not used either and is, therefore, set to one. | | mtu | The maximum packet size that can travel through the network. This parameter is not used and is therefore set to 1500. | Example 17-3 shows the configuration of the default metric when redistributing between routing protocols. Example 17-3. Configuring the Default Metric for EIGRP Router(config)# router eigrp 100 Router(config-router)# redistribute rip Router(config-router)# redistribute ospf 10 Router(config-router)# default-metric 10000 100 255 1 1500 Router(config-router)# network 140.100.0.0 In Example 17-3, EIGRP assigns networks from both RIP and OSPF the same seed metric. Although this design and configuration seems complex, it is fairly common. Imagine the situation in which OSPF and RIP have been running. The decision to transition the network to EIGRP has been made. The network designed for EIGRP will run in the core, with the edge routers running redistribution. RIP has been included in the design map to accommodate the UNIX systems running RouteD, which is the routing process for UNIX systems. The default, or seed, metric used is the bandwidth, delay, reliability, load, and maximum transmission unit (MTU), which reflect the compound metric used by IGRP and EIGRP. However, RIP and OSPF would supply in the configuration a number for hop count and cost, respectively. (Refer to Example 17-2.) This design requires careful consideration and filtering of routing updates because it can result in route feedback, as shown in Figure 17-7. Figure 17-7. Configuring the Default Metric  In this figure, EIGRP redistributes the network 10.1.1.32 from OSPF throughout its domain. At the other end of the domain, EIGRP is redistributed into RIP. The network is now known by all routers, whatever their routing protocol preference. However, if another router on the border between the EIGRP domain and the RIP domain is redistributing, it will hear the RIP update for 10.1.1.32 and redistribute all its networks into EIGRP, including the network originating from OSPF. EIGRP will in turn redistribute 10.1.1.32 back into OSPF, creating a classic routing loop. Configuring the Administrative Distance As shown in this chapter, it is important to ensure that routes redistributed into another routing protocol are assigned an appropriate metric. However, it is equally important to consider the need to control the choice that the routing process makes when presented with multiple routes to the same destination from different routing protocols. The metric is not appropriate because the multiple routes are from different routing protocols that are not redistributing. Changing the administrative distance allows the best path to be chosen . To ensure that the optimal path is chosen, it is sometimes necessary to change the administrative distance to make it less favorable. The command structure is protocol-dependent, in that EIGRP requires a separate command. The following command syntax is used for EIGRP: Router(config)# distance eigrp internal-distance external-distance The distance command, as used to configure the EIGRP administrative distance, is explained in Table 17-6. Table 17-6. Configuring Administrative Distance for EIGRP | Command | Description | | internal-distance | Administrative distance for EIGRP internal routes. These are routes learned from another entity within the same autonomous system. | | external-distance | Administrative distance for EIGRP external routes. These are routes for which the best path is learned from a neighbor external to the autonomous system, such as EIGRP from another autonomous system or another TCP/IP routing protocol, such as OSPF. | To configure the administrative distance for the other IP protocols, the following command syntax is used: Router(config-router)# distance weight [ address mask ] [ access-list-number name ] [ ip ] The distance command to configure the administrative distance for other IP protocols is explained in Table 17-7. Table 17-7. Configuring Administrative Distance for Other IP Protocols | Command | Description | | weight | Administrative distance, an integer from 10 to 255, where 255 means that the route is unreachable. The values 0 to 9 are reserved for internal use. | | address | Optional IP address. Assigns the administrative distance to networks according to the IP address of the router supplying the routing information. | | mask | Optional wildcard mask for IP address. A bit set to 1 in the mask argument instructs the software to ignore the corresponding bit in the address value. | | access-list-number name | Optional number or name of standard access list to be applied to the incoming routing updates. Assigns administrative distance to matching or permitted networks. | | ip | Optional. Specifies IP-derived routes for Intermediate System-to-Intermediate System (IS-IS). | Configuration Commands to Control Routing Updates in Redistribution As explained in the section "Controlling Routing Updates During Redistribution," it is necessary to control the flow of updates between the routing protocol as well as throughout the autonomous system. The following sections consider the implementation of passive interfaces, static routes, and default routes. Configuring the Passive Interface The passive interface is used for routing protocols that send updates through every interface with an address that is included in the network command. If the routing protocol is not running on the next-hop router, it is a waste of time to send updates out of the interface. The command reduces spending limited resources without compromising the integrity of the router. The router processes all routes received on an interface. The command syntax to configure a passive interface, where type and number indicate the interface to be made, is as follows: Router(config-router)# passive-interface type number Configuring Static Routes The following shows the syntax for configuring the static route: Router(config)# ip route prefix mask { address interface } [ distance ] [ tag tag ] [ permanent ] This defines the path by stating the next-hop router to which to send the traffic. This configuration can be used only if the network address for the next-hop router is in the routing table. If the static route needs to be advertised to other routers, it should be redistributed. In some versions of the IOS software, this route is automatically redistributed. It is viewed as a connected network, as long as the output interface is referred in the static route instead of an IP address. Table 17-8 explains the options available in the static route command. Table 17-8. Explanation of the IP Route Options | Command | Description | | prefix | The route prefix for the destination. | | mask | The prefix mask for the destination. | | address | The IP address of the next-hop router that can be used to reach that network. | | Interface | The network interface to use to get to the destination network. | | distance | Optional administrative distance to assign to this route. (Recall that administrative distance refers to how believable the routing protocol is.) | | tag tag | Optional value that can be used as a match value in route maps. | | Permanent | Specification that the route will not be removed even if the interface associated with the route goes down. | Use static routes pointing to the outgoing interface only on point-to-point interfaces. Static routes configured on multipoint or multiaccess interfaces need a next-hop address. On point-to-point interfaces, the information is sent to the only other device on the network. In Example 17-4 (and the corresponding Figure 17-8), the use of a static route and the passive-interface command is illustrated . Additional configuration is included to place the commands in context; the commands relevant to this section are placed in bold. Example 17-4. The Use of Static Routing and Passive Interfaces Router(config)# Router A RouterA(config)# username RouterB password Shhh RouterA(config)# dialer-list 1 protocol ip permit RouterA(config)# interface bri 0 RouterA(config-if)# encapsulation ppp RouterA(config-if)# ip addr 10.1.2.1 255.255.255.0 RouterA(config-if)# ppp authentication chap RouterA(config-if)# dialer map ip 10.1.2.2 broadcast name RouterB 1222555222201 RouterA(config-if)# dialer-group 1 RouterA(config)# interface ethernet 0 RouterA(config-if)# ip address 10.1.1.1 255.255.255.0 RouterA(config)# ip route 10.1.3.0 255.255.255.0 10.1.2.2 RouterA(config)# router eigrp 1 RouterA(config-router)# network 10.0.0.0 RouterA(config-router)# passive-interface Bri0 Figure 17-8. The Use of Static Routes Across a Dialup Link  In this example, the link between Routers A and B is raised when Router A sees interesting traffic try to exit the serial interface. Interesting traffic is traffic that is permitted in a preconfigured access list. In this example, all IP traffic is considered interesting. This example is perfectly valid for occasional access, except for the few additional ISDN parameters that need to be added. Figure 17-8 illustrates the use of both static routes and passive interfaces. In this example, you see that EIGRP updates do not flow across the dialup line because the interface pointing into the ISDN cloud is configured as a passive interface. The same configuration has been applied to Router B so that no updates raise the WAN link. Neither Router A nor Router B knows of the networks on the other side of the WAN, so static routes must be configured. Configuring Default Routes In larger networks, there might be many static routes to be configured. Not only is this a chore for the administrator, but it also requires vigilance so that changes in the routing table can be reconfigured. It might be that turning on a routing protocol is advised, or alternatively, you can configure a specialized static route, called a static default route . The following is a static default route that will generate a default route on the router configured: Router(config)# ip route 0.0.0.0 0.0.0.0 s0 NOTE The different routing protocols treat these default route commands differently when redistributing them into the routing protocol. Reference the Cisco documentation set for detailed explanations .
The default routes are propagated through the network dynamically or can be configured into the individual routers. If a router has a directly connected interface onto the specified default network, the dynamic routing protocols running on that router will generate or source a default route. In the case of RIP, it will advertise the pseudonetwork 0.0.0.0. In the case of IGRP, the network itself is advertised and flagged as an exterior route. When default information is being passed along through a dynamic routing protocol, no further configuration is required. In the case of RIP, there can be only one default route, network 0.0.0.0. However, in the case of IGRP, several networks can offer default routes, although only one is used. If the router is not directly connected to the default network but does have a route to it, it is considered as a candidate default path. To configure a default route, use the following syntax: Router(config)# ip default-network network-number This command will generate a default route to be sent in updates. It does not generate a default network on the router that was configured, and it will only generate a default route if the route used is directly connected. When there are multiple default routes in the routing table, the route candidates are examined. As you would expect, the best default path is selected based on administrative distance and metric. The gateway to the best default path then becomes the gateway of last resort for the router, which is another term for default router. You can display the gateway of last resort with this command: Router# show ip route The default route will appear in the routing table marked as a static route with S*. The gateway of last resort will be set to this network. Redistribution Examples The following examples are case studies that pull together the concepts you learned about redistribution. Redistribution involves complex design and configuration considerations. Therefore, it is best to see the various problems and solutions illustrated in context. This section presents three examples: -
Route redistribution without redundant paths between different routing protocols. -
Route redistribution with redundant paths between different routing protocols. The example also covers resolving the path selection problems that result in redistributed networks. -
The use of a default network in a redistributed environment. Example 1: Route Redistribution Without Redundant Paths Refer to Figure 17-9 for this example of route redistribution without redundant paths between different routing protocols. Figure 17-9. Simple Redistribution Between RIP and EIGRP  Figure 17-9 shows local offices connecting to the main office via Frame Relay. Each office has a point-to-point permanent virtual circuit (PVC) to a router in the main office. EIGRP is being run through the Frame Relay cloud to reduce the network overhead. The LANs are running IP for Microsoft Windows NT, and there is no need for a routing protocol to be run on the LAN segments. RIP is being run at the main office. This is to allow the corporate servers to have an understanding of the network. The servers are UNIX systems running the RouteD daemon. RouteD listens only to RIP updates. Redistribution allows the servers to know about the EIGRP networks. If the EIGRP networks need to know about each other, the RIP networks would need to be redistributed into the EIGRP environment. This is unlikely because the servers are centrally held at the main office, and there will be little lateral traffic flow. The configuration shown in Figure 17-9 is simple because there are no redundant links. The Frame Relay cloud uses point-to-point PVCs. In the future, the company might want to add redundancy by meshing the Frame Relay cloud and consolidating the three core routers into one large router. Currently, the company has a simple and low-cost solution using existing equipment. Example 2: Route Redistribution with Redundant Paths Refer to Figure 17-10 for this example, which covers route redistribution with redundant paths between different routing protocols and resolving path selection problems that result in redistributed networks. Figure 17-10. Choosing the Optimal Path, Through Administrative Distance, When Redistribution Is Using Redundant Paths  In Figure 17-10, Router A is connected to networks 140.100.1.0, 140.100.2.0, and 140.100.3.0. Using RIP, network 140.100.1.0 is advertised to Router B, 140.100.3.0 is advertised to Router C, and network 140.100.2.0 is advertised to both Routers A and B. The routing table of Router A will show the information presented in Table 17-9. Table 17-9. Router A Routing Table Information | Routing Protocol | Network/Subnet | Next Logical Hop | Metric | | Connected | 140.100.1.0/24 | Connected E0 | | | Connected | 140.100.2.0/24 | Connected E1 | | | Connected | 140.100.3.0/24 | Connected E2 | | | RIP | 10.10.10.8/30 | 140.100.3.2 | 1 hop | | RIP | 10.10.10.12/30 | 140.100.3.2 | 1 hop | | RIP | 10.10.10.16/30 | 140.100.3.2 | 1 hop | | RIP | 10.10.10.20/30 | 140.100.3.2 | 1 hop | | RIP | 10.10.10.24/30 | 140.100.3.2 | 1 hop | | RIP | 10.10.10.28/30 | 140.100.3.2 | 1 hop | | RIP | 10.10.10.32/30 | 140.100.3.2 | 1 hop | | RIP | 193.144.6.0/24 | 140.100.3.2 | 1 hop | | RIP | 193.144.7.0/24 | 140.100.3.2 | 1 hop | | RIP | 193.144.8.0/24 | 140.100.3.2 | 1 hop | The routing table of Router B will show the information presented in Table 17-10. Table 17-10. Router B Routing Table Information | Routing Protocol | Network/Subnet | Next Logical Hop | Metric | | RIP | 140.100.1.0/24 | 140.100.3.1 | 1 hop | | RIP | 140.100.2.0/24 | 140.100.3.1 | 1 hop | | Connected | 140.100.3.0/24 | Connected E0 | | | Connected | 10.10.10.8/30 | Connected S0 | | | Connected | 10.10.10.12/30 | Connected S0 | | | Connected | 10.10.10.16/30 | Connected S0 | | | EIGRP | 10.10.10.20/30 | 10.10.10.9 | 2221056 | | EIGRP | 10.10.10.24/30 | 10.10.10.9 | 2221056 | | EIGRP | 10.10.10.28/30 | 10.10.10.13 | 2221056 | | EIGRP | 10.10.10.32/30 | 10.10.10.13 | 2221056 | | EIGRP | 193.144.6.0/24 | 10.10.10.9 | 2221056 | | EIGRP | 193.144.7.0/24 | 10.10.10.13 | 2221056 | | EIGRP | 193.144.8.0/24 | 10.10.10.17 | 2221056 | Note that the routing table for Router A sees all the subnets for network 10.0.0.0 with a mark of 255.255.255.252 or /30. However, because RIP does not pass the network mark in updates and Router A is not connected to network 10.0.0.0, a static route must have been configured so that Router A can see the /30 mask. The routing table sees all the paths as unique, so it is clear which paths are accessible through RIP or EIGRP. Even after redistribution, the routing table will not change; the confusion occurs after the propagation of the EIGRP updates through the network. The EIGRP updates will be sent to all the routers in the domain, and Routers E, F, and G will have no confusion. Depending on the timing of the updates and convergence, however, Router C might become confused. Routers E, F, and G will have sent information on how to get to the networks 140.100.1.0 and 140.100.2.0. Router C will also receive information from Router A. Sending the data traffic to Router A is obviously the optimum path; however, because EIGRP has a significantly better administrative distance, the EIGRP route will be placed in the routing table as having the best path. On the assumption that the Frame Relay PVCs all have the same bandwidth, the routing table will see all three paths and distribute the traffic evenly among them. Example 17-5 shows how to configure Routers B, C, and D to change the administrative distance to favor RIP for the LANs within its domain. The networks 140.100.1.0 and 140.100.2.0 are given an administrative distance of 200 in accordance with the access list. This ensures that the RIP path will be favored if it is available. Example 17-5. Changing the Administrative Distance to Favor RIP Router(config)# router rip Router(config-router)# network 140.100.0.0 Router(config-router)# passive interface S0.1 Router(config-router)# redistribute eigrp 100 metric 3 Router(config)# router eigrp 100 Router(config-router)# network 140.100.0.0 Router(config-router)# passive interface E0 Router(config-router)# default-metric 10000 100 255 1 1500 Router(config-router)# distance 200 0.0.0.0 255.255.255.255 3 Router(config)# access-list 3 permit 140.100.1.0 Router(config)# access-list 3 permit 140.100.2.0 The distance command sets the administrative distance for the EIGRP 100 process. It changes the distance from 90 to 200, which makes the routes that RIP offers more favorable because RIP has an administrative distance of 120. The use of 0.0.0.0 with a wildcard mask of 255.255.255.255 is just as a placeholder. It indicates that although the command allows for a network to be specified so that the administrative distance can be applied selectively to that network, in this configuration, no network has been selected. The command has been applied to all networks. You do want the administrative distance to be altered on two networks, however. This granularity cannot be stated in the distance command; therefore, an access list is used. In the example, the number 3 at the end of the command line points to the access list that carries that number as an identifier. The access list, by permitting networks 140.100.1.0 and 140.100.2.0, is identifying the networks to which the distance command is to be applied. Example 3: A Default Network in a Redistributed Environment The use of the default network simplifies the configuration of a redistributed network by allowing the redistribution to be one-way. This significantly reduces the possibility of feedback of networks into the originating domain. The configuration for this example is inset within Figure 17-11 because the configuration of more than one router is shown. Figure 17-11. The Use of a Default Network in a Redistributed Network to Resolve Problems with Path Selection  In this design, every router and, therefore, workstation within the RIP domain sees its own internal networks, but all other networks are accessed via the default route. Router B's configuration is shown in Example 17-6. Example 17-6. Router B Configuration RouterB(config)# router rip RouterB(config-router)# network 190.10.10.0 Router A redistributes between RIP and EIGRP and acts as an ABR in OSPF, with the RIP domain acting as a stub network. The default route is configured as a static route on Router A, redistributed into RIP, and propagated throughout the RIP domain. The internal RIP-only routers must be configured to accept a default route with a destination network because it is only reachable via a route default. The configuration for Router A is shown in Example 17-7. Example 17-7. Router A Configuration RouterA(config)# router eigrp 100 RouterA(config-router)# redistribute rip RouterA(config-router)# default-metric 10000 100 255 1 1500 RouterA(config-router)# network 10.0.0.0 RouterA(config)# router rip RouterA(config-router)# network 190.10.10.0 RouterA(config-router)# redistribute static RouterA(config)# ip route 0.0.0.0 0.0.0.0 10.10.10.1 The redistribution on Router A can now be one-way. EIGRP needs to know all the networks in the RIP domain, but RIP, when configured with a default route, needs no understanding of the outside world. The RIP domain works in a similar fashion as a stub network in OSPF. Controlling Routing Updates with Filtering Despite all the mechanisms for controlling and reducing the routing updates on your network, it is sometimes necessary to wield greater and more flexible power. This comes in the form of access lists, which when applied to routing updates are referred to as distribute lists . The logic used in the distribute list is similar to that of an access list. The process is listed in the following text: -
The router receives a routing update or is about to send a routing update about one or more networks. -
The router looks at the appropriate interface involved with the action to check for filtering. -
The router determines whether a filter is associated with the interface. -
If a filter is present, the router examines the access list to see if there is a match on any of the networks in the routing update. -
If there is no filter on the interface, the routing update is sent directly to the routing process as normal. -
If there is a filter, the route entry is processed according to the distribute list: advertise the route if matched by a permit statement or do not advertise if it is matched by a deny statement. -
If no match is found in the distribute list, the implicit deny any at the end of the access list will cause the update to be dropped. Routing updates can be filtered for any routing protocol by defining an access list and applying it to a specific routing protocol. There are some limitations to distribute lists when applied to OSPF. For example, the inbound list prevents routes entering the routing table but does not prevent link-state packets from being propagated. When creating a routing filter or distribute list, the following steps should be taken: -
Write out in longhand what you are trying to achieve. -
Identify the network addresses to be filtered, and create an access list. Permit the networks you want to have advertised. -
Determine whether you are filtering routing updates coming into the router or updates to be propagated to other routers. -
Assign the access list using the distribute-list command. Use the following command syntax to configure the distribute list to filter incoming updates: Router(config-router)# distribute-list { access-list-number name } in [ type number ] Table 17-11 explains the options of this command. Table 17-11. Explanation of the distribute-list in Command Options | Command | Description | | access-list-number name | Gives the standard access list number or name | | in | Applies the access list to incoming routing updates | | type number | Gives the optional interface type and number from which updates will be filtered | Use the following command syntax to configure the distribute list to filter outgoing updates: Router(config-router)# distribute-list { access-list-number name } out [ interface-name routing-process autonomous-system-number ] Table 17-12 explains the options of this command. Table 17-12. Explanation of the distribute-list out Command Options | Command | Description | | access-list-number name | Gives the standard access list number or name | | out | Applies the access list to outgoing routing updates | | interface-name | Gives the optional interface name out of which updates will be filtered | | routing-process | Gives the optional name of the routing process, or the keyword static or connected , from which updates will be filtered | | autonomous-system-number | Gives the optional autonomous system number of routing process | Verifying, Maintaining, and Troubleshooting the Implementation of Redistribution and Filtering The key to maintaining and troubleshooting the redistribution within your network is to have a clear understanding of the network topology from both a physical and a logical perspective. The traffic flowsthe peaks and lows in the traffic volumeare also important in truly understanding the connectivity issues within the network. From this vantage point, it is possible to interpret the output presented by the various tools available. Most of the appropriate commands in tracking redistribution problems are ones that have been examined earlier. They include the following: In addition to these commands, the trace and extended ping commands are also very useful. The trace Command The trace command is invoked from user mode, whereas the extended trace is only available from the exec privileged level. This shows the routers that a packet has passed through to reach its destination. The extended trace test is called by entering the command without any destination. This results in the utility asking a series of questions, allowing you to change the defaults. The Extended ping Command To check host reachability and network connectivity, use the ping privileged exec command. The extended ping utility is called by entering the command without any destination. This results in the utility asking a series of questions, allowing you to change the defaults. Using trace and Extended ping You do not use trace to determine the path taken, but rather to identify where there is a problem in the network. Where the trace utility fails indicates a good starting point for troubleshooting a complex network. The trace command is not very useful in reflecting the routing path because path changes are not shown. The extended ping command, however, is very useful because it announces every interface that it traverses if the record option is selected. The limitation is the maximum hops that it can report, which is nine. It is also possible to specify a source address in the trace or ping commands (as long as it is an interface on the router). This can be useful for testing certain types of access lists, route maps, and so on. Otherwise, the route will choose the source address of its own interface closest to the destination. It is also useful for testing network reachability from the far end. These commands are generic to TCP/IP troubleshooting. | 