Foundation Topics

Understanding Redistribution Fundamentals

Routing protocols have distinct advantages and disadvantages in different situations. A protocol that is supported on old equipment (such as RIP) might not support fast classless operation needed in the core of the network (such as OSPF, IS-IS, or EIGRP). Most organizations use the most appropriate routing protocol in different parts of their network. Organizations running multiple routing protocols need to pass networks learned by one protocol into another. This process is called redistribution.

Redistribution should not be thought of as a quick and easy solution. Redistribution is complex. It is crucial that you understand the operation of the processes and how this affects your network. This chapter focuses on the implementation of redistribution.

Each routing protocol within an AS can be thought of as a routing domain. Routes redistributed into a routing domain are termed external routes, while native routes are called internal routes.

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 other routing protocols.

In Figure 11-1, the routing table for Router B has entries from RIP and OSPF. Router C is connected using EIGRP, but the protocol is only running on the link connecting B and C and therefore does not propagate non-EIGRP routes. You can see that the RIP updates sent out the interfaces do not include networks from OSPF. There are no entries for EIGRP.

Figure 11-1. Routing Updates Without Using Redistribution

[View full size image]

Notice that Router C has only connected routes. Although EIGRP has been configured, Router C need only propagate its connected routes via EIGRP and use a default route pointing to Router B.

Redistribution can occur only between processes routing the same routed protocol. IPv4 routes can be passed from OSPF to EIGRP to RIP. IPv6 paths can be communicated from RIPng to OSPFv3.

Table 11-2 explains the subtleties of redistribution.

Figure 11-2 illustrates redistribution within an organization.

Figure 11-2. Autonomous Systems Within an Organization

[View full size image]

The main reasons for having multiple protocols within an organization are as follows:

• The organization is transitioning from one routing protocol to another.

• The company wants to transition from multiple routing protocols to a single routing protocol.

• Often after a merger or a takeover, it takes planning, strategy, and careful analysis to determine the best overall design for the network.

• There are (political) ideological differences among the different network administrators, which currently 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

Redistribution is the answer to running multiple routing protocols within your network while maintaining one cohesive network. However, before you embark on this strategy, you must carefully consider the problems that might arise. You need to briefly consider the routing protocol operation—in particular, how a path is selected to go into the routing table.

Routing Metrics and Redistribution

There are many routing protocols for IP, and each uses a different metric. If two protocols want to share information through redistribution, the configuration must deal with this difference in metrics.

In redistribution, a receiving routing protocol has no point of reference for the metric; for example, RIP would be baffled by a metric of 786. Furthermore, there is no way to algorithmically compare metrics from different protocols. Instead, when routes are accepted into a new protocol, 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; however, depending on the routing protocol, the default might prevent the route from entering the routing table. The seed metrics are defined in Table 11-3.

Path Selection Between Routing Protocols

This section discusses path selection between routing protocols. 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 is based on an arbitrary administrative distance. Remember that routers prefer paths with lower administrative distance.

It is 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 process will place the route with the best administrative distance into the routing table.

• Routing protocols can only redistribute routes they know. 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.

• Redistributed routes are called external. External routes in EIGRP are given a different (higher) AD, while OSPF tracks the route as external and prefers internal routes.

Potential Problems with Redistribution

Redistribution is not optimal. The simpler and more straightforward the design, the better managed and more stable the network, which means fewer errors and faster convergence. 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.

The problems that can arise from redistribution are typically difficult to troubleshoot because the symptoms often appear at some distance from the configuration error. The problems experienced as a result of multiple routing processes and their redistribution include the following:

• Routing loops because routers send routing information received from one autonomous system back into the same autonomous system.

• Suboptimal routing decisions are made because of the difference in routing metrics.

• The convergence time 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.

The following sections describe how to avoid these potential problems.

Avoiding Routing Loops When Redistributing

Routing loops occur when a routing protocol redistributes routes into another protocol and then receives the same routes back—a process called route feedback. Because the metric is reset through redistribution, the routing protocol could see the redistributed path as more attractive. The potential for confusion is enormous, as shown in Figure 11-3; routes distributed from OSPF to EIGRP are distributed back to EIGRP at two redistribution points, causing the routing tables of the respective routers to continuously rotate between alternate primary paths for the redistributed routes.

Figure 11-3. How Route Feedback Can Cause Routing Loops

[View full size image]

This problem is solved by the following configurations:

• Changing the metric

• Changing the administrative distance

• Using default routes

• Using passive interfaces with static routes

• Using distribute lists

These configurations are discussed in the section of this chapter titled "Configuring Redistribution."

Restricting (to some level) the information sent across various domains is often necessary to manage the complexity of these networks and to reduce the possibility of routing loops. This is done via filtering, using access lists.

Consider the problem by looking at the example in Figure 11-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; this 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.

Figure 11-4. Path Selection Using Administrative Distance

[View full size image]

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 for this 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 the RIP administrative distance of 120. The routing table contains the RIP path to the network 190.10.10.0.

When EIGRP then redistributes into RIP at Routers B and E, 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. For these reasons, you should be careful with bidirectional redistribution.

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 or OSPF routes. The administrative distance reflects the preferred choice.

Avoiding Suboptimal Routing Decisions When Redistributing

Routing loops are only one problem that can result from redistributing routes between routing protocols. Suboptimal routing is another problem occasionally 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.

When designing your network, keep the following guidelines in mind when redistributing between routing protocols to avoid routing loops and suboptimal path selection:

• 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 function similar 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 protocol 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 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

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 is fairly slow. Sharing network information between the two might cause 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.

Exchange of Routing Protocol-Specific Parameters

The decision-making process and the information sent within the protocols might be incompatible and not easily exchanged, leading to errors and complex configuration. Each routing protocol maintains parameters specific to that protocol—including route metrics. Part of the function of route redistribution is to manage the transformation of these parameters between routing protocols in a meaningful way.

For example, redistributing into OSPF requires translating all the parameters of the redistributed routing protocol into the OSPF cost metric. This is very limiting when converting from a protocol such as EIGRP which has five parameters (bandwidth, load, reliability, delay, and MTU) when redistributing into EIGRP, so a judicious decision must be made by the network engineer as to how to best convert EIGRP routes with their associated parameters into OSPF routes with the cost parameter. If the inter-protocol mappings are ill-conceived, the routing process of the receiving protocol will be adversely affected. Several illustrative examples are provided in this chapter, demonstrating the principle of route parameter mappings.

Controlling Routing Updates During Redistribution

Controlling routing updates is useful for many reasons:

• To hide some networks from the rest of the organization (security)

• To prevent routing loops

• To control network overhead

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, the process listens but will not send updates on a passive interface. In OSPF and EIGRP, the process does not send hellos, and therefore no neighbor relationship can form.

Interfaces that participate in the routing process are controlled by the interface configuration. The configuration instructs the routing process via the network command as to which interfaces to use. The passive interface command is useful to disable a routing protocol on a per-interface basis; this command 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.

Static routes are not practical in a large network because the table cannot dynamically learn of changes in the network topology. In small environments or in stub networks, however, this is an excellent solution. 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 a BGP and an IGP to exchange information.

The reasons for static routing are summarized as follows:

• If there is only one path, then there is no need for the complication and overhead of a routing protocol.

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

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

• To redistribute from a routing protocol that understands variable-length subnet mask (VLSM) to one that does not.

Default Routes

A default route is a "route of last resort." The default route (0.0.0.0 mask 0.0.0.0) is the least specific path and the router will always choose more specific paths. If there are no other matching entries in the routing table, the default route is used.

Default routes reduce overhead and complexity, and can remove loops, particularly when they are 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 is 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 11-5.

Figure 11-5. The Use of Default and Static Routes

[View full size image]

The Null Interface

A null interface is a virtual interface that could also be called a bit bucket. All traffic destined for the remote network is routed into a black hole. This is used either to discard routes by destination in a rudimentary filtering system or to redistribute between classless and classful routing protocols.

The null interface is a convenient place to point summarized links, as shown in Chapter 14, "BGP Concepts." Null interfaces are also used automatically by EIGRP to drop packets within a summarized network when the specific destination network does not appear in the routing table.

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 used in conjunction with careful network design afford the greatest control of the traffic flow within the network. You learn more about distribute lists in the section, "Controlling Routing Updates with Filtering," later in this chapter.

Route Maps

Route maps are complex access lists that permit conditional programming. Distribute lists are access lists filtering routing updates, whereas route maps use match criteria to match traffic as desired and a set function to alter parameters within the routing protocol packets. The ultimate effect of distribute lists can essentially be reproduced by a route map; that is, distribute lists are easier to implement but do not permit nearly as much granularity.

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 11-6 shows the options for controlling routing updates in a large and complex network.

Figure 11-6. Controlling Routing Updates

[View full size image]

In Figure 11-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.

A default route is configured to send packets out interface S0. A static route is configured to send packets out interface S1. Interface S0 provides a path to 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, which could be huge.

The organization has a default route, which is used when there is not a specific route to a destination.

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, suggesting 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 section with configuration examples.

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:

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. The command 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" later in this chapter.

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 11-4.

Configuring the Default Metric

The default metric can be configured in two ways:

• The redistribute command permits the assignment of the metric to the redistributed routing protocol specified in this command.

• Use the default-metric command to assign a metric to all redistributed routes from all routing protocols.

If both the redistribute command and default-metric commands are used within a single routing process, the metric assigned by the redistribute command takes precedence. A default-metric command should be used if multiple routing protocols are being redistributed, because some routing protocols will not redistribute routes from other routing protocols without a specific metric assigned by the redistribute command.

Example 11-1 shows the metric included in the redistribute command.

Example 11-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, or BGP

It is possible to redistribute the routing protocol and then, with a separate command, to state the default metric. There is no advantage to handling metric assignment within the redistribute command or separately.

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, or BGP, use the following command syntax:

Router(config-router)# default-metric number

The default-metric command is used in Example 11-2.

Example 11-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 Example 11-2, the default metric is set to 2. Generally you should set the metric high enough so that external routes are not as interesting as internal routes. If your network is five hops wide, consider a metric of 6 or more. Assigning a default metric helps prevent routing loops.

Configuring the Default Metric for EIGRP

To configure the default metric for 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 11-5.

Example 11-3 shows the configuration of the default metric when redistributing between routing protocols.

Example 11-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 11-3, EIGRP assigns the same seed metric to networks from both RIP and OSPF. 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 compound metric used by EIGRP. However, RIP and OSPF would supply a number for hop count and cost, respectively. (Refer to Example 11-2.) This design requires careful consideration and filtering of routing updates because it can result in route feedback, as shown in Figure 11-7.

Figure 11-7. Configuring the Default Metric

[View full size image]

In Figure 11-7, 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. The end result of this scenario will be suboptimal routing, depending on the exact topology.

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. On the other hand, 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; in this case, the administrative distance determines which routing protocol is used in the routing table. The metric is only relevant within the route selection process of a given routing protocol.

To ensure the optimal path is chosen, it is sometimes necessary to change the administrative distance. The command structure is somewhat protocol-dependent, in that EIGRP requires separate internal and external distances. 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 11-6.

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

Configuration Commands to Control Routing Updates in Redistribution

As explained in the section "Controlling Routing Updates During Redistribution," it is necessary to