Avoiding Routing Loops When Redistributing

14 Mar

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:
■ 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 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 problem—the administrator’s preferred route not coinciding with that of the routing protocol—a 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:

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

Table 17-4 Command Description of Redistribution (Continued)

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

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

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

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

Beware of route feedback causing poor network performance.

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


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 nexthop 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

Table 17-8 Explanation of the IP Route Options (Continued)

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 passiveinterface 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

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.

Figure 17-8 The Use of Static Routes Across a Dialup Link

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.

No comments yet

Leave a Reply

You must be logged in to post a comment.