Semestre 1 CCNP, Módulo 8

Module 8: Route Optimization

Overview

Dynamic routing, even in small internetworks, can involve much more than just enabling the default behavior of a routing protocol. A few simple commands may be enough to get dynamic routing started. However, more advanced configuration must be done to enable such features as routing update control and exchanges among multiple routing protocols. Routing can be optimized in a network by controlling when a router exchanges routing updates and what those updates contain. This module examines the key IOS route optimization features, including routing update control, policy-based routing, and route redistribution.

8.1 Controlling Routing Update Traffic

8.1.1 Controlling routing updates

Router RTA as shown in Figure , is running a simple distance vector routing protocol called RIP.

The RIP configuration command network 10.0.0.0 serves two functions. First, the command tells RIP where to send and receive advertisements, and on which interfaces to send and receive updates. The network 10.0.0.0 command enables RIP updates on all interfaces that have an IP address belonging to the 10.0.0.0 network, such as Bri0, S1, S2, and E1. Second, this command tells the RIP process what to advertise. All directly connected subnets belonging to the major network 10.0.0.0 are included in RIP updates, in addition to any dynamically learned routes. That means that RTA advertises the networks 10.1.1.0, 10.2.2.0, 10.3.3.0, and 10.4.4.0.

Unfortunately, the default behavior of RIP, or any routing protocol, may not be the best thing for an internetwork. Is it useful for RTA to send updates on all four interfaces?

Updating out E0 is a waste of resources. No other routers on the 10.4.4.0 subnetwork can receive the updates, so they serve no purpose. Meanwhile, sending updates creates slight, and needless, overhead and a potential security risk. A malicious user could use a packet sniffer to capture routing updates and therefore glean key network information.

For these reasons, it is necessary to configure passive interfaces or route filters to control routing updates. Both strategies are discussed in the following sections.

8.1.2 Passive interfaces

Configure LAN interfaces as passive interfaces when enabling a routing protocol. A passive interface receives updates, but does not send them. The passive-interface command can be used with all IP interior gateway protocols. It can be used with RIP, IGRP, EIGRP, OSPF, and IS-IS. The syntax of the command is as follows:

Router(config-router)#passive-interface type number

Configure the E0 interface on RTA as a passive interface.

Use the passive-interface command on WAN interfaces to prevent routers from sending updates to link partners.

There may be several reasons to prevent updates on the WAN. If RTA and RTX are connected by a dial-on-demand ISDN link, regular RIP updates will keep the link up constantly. This will result in an unnecessarily large bill from the provider. Instead, a static route can be configured on both routers with the Bri0 on RTA configured as a passive interface.

Notice that for RTA to update RTY and RTZ about the route to 172.16.1.0, it must be configured to redistribute static routes into RIP. The redistribute static command tells RIP to import the static routes into RIP and advertise them as part of a RIP update. Route redistribution is covered in more detail later in this module.

The passive-interface command works differently with the different IP routing protocols that support it. In OSPF, the network address of the passive interface appears as a stub network. OSPF routing information is neither sent nor received by way of a passive interface. In EIGRP and OSPF, the router stops sending Hello packets on passive interfaces. When this happens, the router cannot form neighbor adjacencies. Therefore, the router cannot send and receive routing updates on the interface. It will be seen later in this module that the passive effect can be achieved for an EIGRP interface by using the distribute-list command. This can be done without preventing adjacency relationships.

Figures through are animations that are designed to help the student gain a better understanding of a passive interface in routing.

8.1.3 Filtering routing updates with distribute-list

Configuring an interface as passive prevents it from sending updates entirely. However, sometimes there is a need to suppress only certain routes in the update from being sent or received. If RTA is configured with the network 10.0.0.0 command, all four directly connected subnets will be advertised in the updates from RTA, along with any dynamically learned routes. However, RTZ may need to be prevented from learning about network 10.1.1.0 from RTA.

This may be needed to enforce a routing policy that is based on some external factor such as link expense, administrative jurisdiction, or security concerns. In some cases, there is the desire to reduce needless overhead by preventing access routers from receiving the complete, and possibly immense, core routing table. Just assume that for one of these reasons, RTZ is not to learn the route to 10.1.1.0 from RTA.

Use the distribute-list command to pick and choose which routing updates a router will send or receive. By referencing an access list, the distribute-list creates a route filter. This is a set of rules that precisely controls what routes a router will send or receive in a routing update. This command is available for all IP routing protocols and can be applied to either inbound or outbound routing updates. When applied to inbound updates, the syntax for configuring a route filter is as follows:

Router(config-router)#distribute-listaccess-list-number in [interface-name]

When applied to outbound updates, the syntax can be more complicated as shown in the following:

Router(config-router)#distribute-listaccess-list-number out [interface-name routing-process as-number]

The routing-process and as-number options are invoked when exchanging routes between different routing protocols. This will be covered later in the module, in the section titled Route Redistribution.

In Figure , access list 24 will match the route to 10.1.1.0 and result in a deny. When referenced by the distribute-list command, this match results in the removal of the route to network 10.1.1.0 in the outbound update. However, there is a drawback. The distribute-list 24 out command will have a global effect on RIP updates out every interface, not just out the interface connected to RTZ. The intent was to suppress the 10.1.1.0 route from updates to RTZ only. This level of specificity can be accomplished by using an optional interface argument with the command, shown as follows:

RTA(config-router)#distribute-list 24 out interface s2

Conversely, RTZ could have been told to globally filter network 10.1.1.0 from any incoming updates.

Or, 10.1.1.0 could have been precisely filtered from the specific interface on RTZ, shown as follows:

RTZ(config-router)#distribute-list 16 in

The distribute-list command can filter any routes in either an outbound or an inbound update globally, or for a specific interface. The Cisco IOS permits one incoming and one outgoing global distribute-list for each routing process. It also permits one incoming and one outgoing distribute-list for each interface involved in a routing process. Keep track of which routing filters are applied globally and which are applied on specific interfaces with the show ip protocols command.

Configuring a Passive EIGRP Interface Using distribute-listCommand
A passive interface cannot send EIGRP Hello packets, which prevents adjacency relationships with link partners. A "pseudo" or false passive EIGRP interface can be created by using a route filter that suppresses routes from the EIGRP routing update, shown as follows:

RTA(config)#router eigrp 364
RTA(config-router)#network 10.0.0.0
RTA(config-router)#distribute-list 5 out interface s2
RTA(config-router)#exit
RTA(config)#access-list 5 deny any

With this configuration, RTA can send EIGRP Hello packets and establish adjacencies, but no routes will appear in any updates sent out s2.

8.2.1 Policy routing overview

Use the ip route command to dictate which path a router will select to a given destination. However, through policy routing, a router can be programmed to choose a route based not only on destination, but on source as well.

Concerns such as monetary expense, organizational jurisdiction, or security issues can lead administrators to establish policies, or rules, that routed traffic should follow. Left to their default behavior, routing protocols may arrive at path decisions that conflict with these policies. For that reason, administrators use policy routing to override dynamic routing and take precise control of how their routers handle certain traffic.

Although policy routing can be used to control traffic within an autonomous system (AS), it is typically used to control routing between autonomous systems. For that reason, policy routing is used extensively with exterior gateway protocols (EGPs), such as Border Gateway Protocol (BGP).

The route-map command is used to configure policy routing, which is often a complicated task. A route map is defined using the syntax shown in the figure.

The map-tag is the name, or ID, of the route map. This map-tag can be set to something easily recognizable, such as route2ISP or CHANGEROUTE. The route-map command changes the mode on the router to the route-map configuration mode, from there conditions can be configured for the route map.

Route maps operate similar to access lists, by examining one line at a time and when a match is found, action is taken. Route maps are different from numbered access lists because they can be modified without changing the entire list. Each route map statement is given a number. If a sequence number is not specified, the first route map condition will automatically be numbered as ten (10). The second condition will automatically be numbered as 20, and so on. The optional sequence number can be used to indicate the position that a new route map is to have in the list of route maps already configured with the same name.

After entering the route-map command, enter set and match commands in the route-map configuration mode. Each route-map command has a list of match and set commands associated with it. The match commands specify the match criteria. They are the conditions that should be tested to determine whether to take action. The set commands specify the set actions. They are the actions to be performed if the match criteria are met.

8.2.2 Policy routing example

Figure presents a policy routing scenario. A route map can be used at RTA to implement policy routing. Assume for this example that the policy to be enforced is as follows:

* Route Internet-bound traffic from 192.168.1.0/24 to ISP1
* Route Internet-bound traffic from 172.16.1.0/24 to ISP2

First, define the access lists that will be used in the route maps to match IP addresses. Then configure the route map itself using the syntax shown in Figure .

The commands in Figure have actually configured two policies. The ISP1 route map matches access list 1 and routes traffic out S0 toward ISP1. The ISP2 route map matches access list 2 and routes that traffic out S1 toward ISP2.

The final step is to apply each route map to the appropriate interface on RTA using the ip policy route-map command. With the route maps applied to the appropriate LAN interfaces, policy routing is successfully implemented.

Frequently, route maps are used to control the exchange of routing information during redistribution. Route redistribution is detailed in the next section.

8.3.1 Redistribution overview

To support multiple routing protocols within the same internetwork efficiently, routing information must be shared among the different routing protocols. For example, routes learned from a RIP process may need to be imported into an IGRP process. This process of exchanging routing information between routing protocols is called route redistribution. Such redistribution can be one-way or two-way. One-way routes are where one protocol receives the routes from another. Two-way routes are where both protocols receive routes from each other. Routers that perform redistribution are called boundary routers because they border two or more autonomous systems or routing domains. This section examines route redistribution in detail, including the use of administrative distance, guidelines for redistribution implementation, and issues with redistribution configuration.

Using multiple routing protocols typically results in increased administrative complexity and overhead. Why would this be done in the first place? Actually, there are several scenarios in which using multiple routing protocols solves more problems than it creates, especially in medium and large sized networks.

Consider a large, mixed vendor routing environment in which Cisco routers work alongside other routers. An administrator may create an all Cisco domain, where the advantages of proprietary protocols such as IGRP and EIGRP can be retained. Meanwhile, other areas of the network run a nonproprietary protocol, such as OSPF or RIP.

Multiple routing protocols may also be effectively deployed to support legacy UNIX systems that support RIP only. These systems may represent a significant financial investment and may not be readily upgradeable. An administrator may elect to run RIP on subnets populated by the UNIX systems but might use a more scalable protocol elsewhere. Also, running multiple routing protocols can be seen as a temporary fix during a prolonged upgrade from older protocols and hardware to newer, more scalable solutions.

On some occasions redistribution is implemented even when running compatible routing platforms. For example, an organization with all Cisco routers running EIGRP. If the organization is exchanging routing information with a domain outside its administrative control, it may choose to configure route redistribution as a means of logically separating the different routing processes, which may have different policies.

Cisco routers support up to 30 dynamic routing processes. This means that a router can run RIP, OSPF, IGRP, IS-IS, EIGRP, IPX RIP, RTMP, AppleTalk, and other protocols simultaneously. Most of these routing protocols enable the configuration of multiple processes of the same routing algorithm. RIP is a notable exception. For example, multiple IGRP processes can be defined by using different AS numbers, or different OSPF processes by using different process ID numbers.

Notice that in the configuration shown in Figure , that the OSPF processes for RTA, 24 and 46, will not share routing information unless route redistribution is configured. Each routing process places substantial demands on the router memory and CPU resources. Because of this, only boundary routers should run more than one routing process for the same routed protocol, and only when absolutely necessary.

8.3.2 Administrative distance

If a boundary router is running multiple IP routing protocols, then it may be possible that the router will learn about the same network from more than one routing protocol. For example, RTZ may learn about the 10.0.0.0 network from both RIP and IGRP. Which route will RTZ install in its routing table?

A router looks at the metric value to determine the best route. However, in this case, the router would have to compare the simple metric of RIP, its hop count, with the composite metric of IGRP, this being derived from bandwidth, delay, reliability, load, and MTU. As noted in Module 3, Routing Overview, the metrics are not based on the same factors, so it would not be a reliable comparision. The metric of 10576 from IGRP cannot be accurately measured against the metric of three (3) from RIP for the same route. Instead, routers use administrative distance to choose between routes to the same network offered by different routing protocols.

The administrative distance of a routing protocol provides a rate of trustworthiness as a source of routing information. Administrative distance is an integer from 0 to 255. The lowest administrative distance has the highest trust rating. An administrative distance of 255 means the routing information source cannot be trusted at all and should be ignored. An administrative distance of zero is reserved for directly connected interfaces and will always be preferred.

Specifying administrative distance values enables the Cisco IOS software to discriminate between sources of routing information. If two routes have the same network number, and possibly subnet information, the IOS software always picks the route whose routing protocol has the lowest administrative distance. Figure shows the default administrative distances for some routing information sources.

The IGRP route will be preferred, or trusted, over the RIP route to the same network. This is because of the lower administrative distance for IGRP, which is 100, as opposed to RIP, which is 120. There may be a time that having the router believe RIP over IGRP is needed. Fortunately, the Cisco IOS allows the administrative distance to be manually configured, as discussed in the next section.

8.3.3 Modifying administrative distance by using the distance command

When using multiple IP routing protocols on a router, the default administrative distance of each is usually sufficient. However, some circumstances call for changing the administrative distance values on a router.

For example, if a router is running both IGRP and OSPF, it may receive routes to the same network from both protocols. The default administrative distances favors IGRP routes over OSPF routes. However, because IGRP does not support CIDR, the router will need to use the OSPF route instead. In this case, configure the local router to apply a custom administrative distance to all OSPF routes.

With the distance 95 OSPF configuration command, RTZ compares the IGRP and OSPF routes and comes up with a different result.

In its broadest application, the distance command can be used to modify the administrative distance value applied to all routes learned by way of a specific routing process. The commands in Figure will assign the value of 95 to all routes learned by the OSPF 1 process. Notice that these values are local to the router. Although RTZ assigns the 10.0.0.0 network an administrative distance of 95, all other Cisco OSPF routers will apply a value of 110, unless otherwise configured.

The distance command can also be applied with optional arguments to make changes to selected routes based on where they originate. The expanded syntax of the distance command is as follows:

Router(config-router)#distanceweight [source-ip-address source-mask (access-list-number | name)]

After running multiple protocols on a boundary router, it may be discovered that one or two suboptimal paths have been installed because of their lower administrative distance. Rather than assign a new distance value to all routes learned by a process, specific routes can be identified based on their source IP. Using the optional arguments, configure a router as follows to apply an administrative distance of 105 to all RIP routes received from 10.4.0.2:

RTZ(config)#router rip
RTZ(config-router)#distance 105 10.4.0.2 0.0.0.0

Alternatively, an administrative distance value can be applied to only certain routes from that same source by specifying an access list.

Remember that the administrative distance defaults exist for a reason and will serve a network well in most circumstances. Use the distance command only when certain that it is necessary to guarantee optimal routing.

8.3.4 Redistribution guidelines

Route redistribution can be complicated and have several disadvantages as shown in the following:

* Routing loops – Depending on how redistribution is used, routers can send routing information received from one AS back into the AS. The feedback is similar to the split horizon problem that occurs in distance vector technologies.
* Incompatible routing information – Each routing protocol uses different metrics. Because these metrics cannot be translated exactly into a different protocol, path selection using the redistributed route information may not be optimal.
* Inconsistent convergence time – Different routing protocols converge at different rates. For example, RIP converges slower than EIGRP, so if a link goes down, the EIGRP network will learn about it before the RIP network.

These potential trouble spots can be avoided with careful planning and implementation. Use the following important guidelines when configuring route redistribution:

* Be familiar with the network – There are many ways to implement redistribution and being familiar with the network helps to make the best decisions.
* Do not overlap routing protocols – Do not run two different protocols in the same internetwork. Instead, have distinct boundaries between networks that use different routing protocols.
* Use one-way redistribution with multiple boundary routers – If more than one router serves as a redistribution point, use one-way redistribution to avoid routing loops and convergence problems. Consider using default routes in the domains that do not import external routes.
* Use two-way redistribution with a single boundary router – Two-way redistribution works smoothly when redistribution is configured on a single boundary router in the internetwork. If there are multiple redistribution points, do not use two-way redistribution unless a mechanism to reduce the chances of routing loops is enabled. A combination of default routes, route filters, and distance modifications can be used to combat routing loops.

8.3.5 Configuring one-way redistribution

Although the redistribution command is available for all IP routing protocols, it behaves differently depending on the actual IP routing protocols involved. However, the underlying principles are the same. Therefore, the examples in this section can be used as a starting point for any redistribution scheme.

This section closely examines examples of one-way and two-way redistribution and then focuses on specific redistribution issues, including connected, static routes and the default-metric command.

In Figure , RTB injects routes learned by way of RIP into the EIGRP domain. However, the RIP routers do not learn about the EIGRP routes. This is one-way route distribution. In this example, the RIP routers can use a default route to handle any traffic bound for nonlocal destinations.

As the AS boundary router, RTB must run two routing processes, one for the RIP domain and one for the EIGRP AS.

The syntax of the redistribute command is as follows:

Router(config-router)#redistributeprotocol [process-id] {level-1 level-1-2 level-2} [metricmetric-value][metric-typetype-value] [match {internal external 1 external 2}] [tagtag-value] [route-mapmap-tag][weightweight] [subnets]

The redistribute rip command enables route redistribution. RIP routes learned by RTB will be imported into the EIGRP process. The metric argument sets up the values used by EIGRP to translate the metric from the hop count on RIP to the composite metric on EIGRP. When used with IGRP/EIGRP, the metric keyword sets the bandwidth value, the delay, the reliability, the load, and the maximum transmission unit (MTU). The bandwidth value is in Kbps, the delay is in tenths of microseconds, while the reliability and the load are out of 255.

These five values constitute the seed metric. The seed metric is the initial metric value of an imported route. After it is imported into the EIGRP AS, the RIP route becomes an EIGRP route with a composite metric derived from these seed values. Using the configuration in Figure , RIP routes with metrics of two (2), six (6), and 14 will be redistributed with the same EIGRP metric value of 2195456. However, as the imported route propagates to other EIGRP routers, its metric values increment according to EIGRP rules.

Click on the topology in Figure to examine the routing tables of the EIGRP router, RTA, for the boundary router, RTB, and for the RIP router, RTC. The tables have been reformatted for the purpose of clarity.

The routing table on RTA includes not only the EIGRP routes from AS 24, but also the redistributed routes from the RIP domain. The redistributed RIP routes that have been learned from RTB are denoted by D EX because EIGRP considers them external. As discussed in Module 5, EIGRP differentiates between internal routes, routes, and external routes. Internal routes are learned from within the AS, while external routers are imported from outside the AS. The Cisco IOS assigns a different administrative distance of 170 to the external EIGRP routes, which is much less desirable.

The table from RTB shows that RTB is running two routing protocols and has learned routes by way of RIP and learned routes by way of EIGRP. RIP is denoted by an R and EIGRP is denoted by a D.

Notice that RTC does not have a default route and has not learned about any routes from the boundary router, RTB. That means that RTC cannot route to six (6) of the 12 networks shown in the outputs of Figure . It may be decided that the best solution in this scenario is to use a default route that points to RTB. This can easily be accomplished statically, as the following shows:

RTC(config)#ip route 0.0.0.0 0.0.0.0 172.16.0.1

Because RTC is running RIP, it can dynamically propagate its 0.0.0.0/0 route to the other routers in the RIP domain. If choosing to implement this default route configuration, there is no need for the boundary router, RTB, to send updates into the RIP domain. Therefore the RIP interface on RTB should be configured as passive, as the following shows:

RTB(config)#router rip
RTB(config-router)#passive-interface s0

A more complex topology may require that a two-way, or mutual, redistribution be employed. This is done by importing the EIGRP routes into the RIP domain, as described in the next section.

8.3.6 Configuring two-way redistribution

The boundary router can be configured for two-way redistribution, as shown in Figures – .

Notice that the syntax of the metric keyword varies depending on the routing protocol that it uses. For RIP, OSPF, and BGP, the metric option is followed by a single number that represents the metric value (hop count, cost, and so on). For IGRP and EIGRP, the metric option is followed by five values that represent bandwidth, delay, reliability, load, and MTU.

NOTE:

Whenever there is a major network that is subnetted, use the keyword subnets to redistribute protocols into OSPF. Without this keyword, OSPF redistributes only major networks that are not subnetted. For example, to inject EIGRP routes, including subnets, into an OSPF area, use the command redistribute eigrp 24 metric 100 subnets.

In Figure , RIP is configured to import EIGRP routes and distribute them into the RIP domain with a seed metric of two hops.

Mutual redistribution will result in RTC installing 11 routes in its table (click on the topology Figure to view RTC routing table).

Unlike EIGRP, RIP does not differentiate between external and internal routes. Also, note that RTB seed metric has resulted in a metric of two hops for all the redistributed routes, even though two of these networks are actually three hops away.

After configuring two-way redistribution, RTC and RTA have only 11 routes, while the boundary router (RTB) has 12. What is happening? The answer lies in the directly connected routes of router RTB as follows:

* 172.16.0.0/16 (missing from RTA table)
* 172.24.0.0/16 (missing from RTC table)

Recall that the network command identifies not only which interfaces to run the routing protocol on, but also which directly connected networks will be included in routing updates. Look carefully in Figure . RTB RIP process is configured to advertise the connected network 172.16.0.0, while its EIGRP process is configured to advertise the connected network 172.24.0.0.

To bring RTA and RTC routing tables up to a complete 12 routes, we can configure both of RTB routing processes to include the two connected networks using the network command. However, that will result in a RIP process running in the EIGRP AS and an EIGRP process running in the RIP domain. This solution will generate needless overhead. Redistribution offers a much more efficient and elegant solution. RTB can be configured to redistribute its connected routes using a default metric, as discussed in the following sections.

8.3.7 Redistributing connected and static routes

Directly connected routes can be redistributed into a routing protocol by using the redistribute connected command with a seed metric, as shown in the following example:

RTB(config-router)#router eigrp 24
RTB(config-router)#redistribute connected metric 10000 100 255 1 1500

By using the connected keyword, redistribution will inject all connected routes into the updates from the routing protocol. This is done without configuring a network statement.

Static routes can be redistributed in the same way. The following example illustrates how RTB could be configured to redistribute static routes:

RTB(config-router)#router eigrp 24
RTB(config-router)#redistribute static metric 10000 100 255 1 1500

In Figure , RTB is configured for two-way redistribution. Notice that the seed metric is included each time the redistribute command is issued. The default-metric command can be used as a shortcut in this situation.

The default-metric Command
An alternative to this redistribution configuration is to use the default-metric command instead of including the same seed metric with each redistribute statement. Whenever the redistribute command is used and the metric is not specified, the router will use the default metric value as the seed metric. The default metric value can be administratively configured for each routing protocol, as shown in the second show running-config output. In the second example, all EIGRP redistribute commands will use the default metric, 10000 100 255 1 1500. Meanwhile, all RIP redistribute commands will use a default metric of two (2).

8.3.8 Verifying redistribution operation

The following commands are used to verify the route redistribution operation:

* Know the network topology, particularly where redundant routes exist.
* Display the routing table of the appropriate routing protocol on a variety of routers in the internetwork using the show ip route command. For example, check the routing table on the ASBR as well as some of the internal routers in each AS.
* Perform a traceroute on some of the routes that go across the ASs to verify that the shortest path is being used for routing. Make sure that traces are performed on networks where redundant routes exist.
* If routing problems are encountered, use traceroute and debug commands to observe the routing update traffic on the ASBRs and internal routers.

8.4.1 Phase 1: Configuring a RIP network

This section presents a case study that addresses the issues associated with integrating RIP with OSPF. Complex internetworks typically include UNIX hosts and legacy routers, neither of which is likely to support OSPF. Because of this, most OSPF internetworks must also use RIP in select areas. This case study provides examples of how to complete the following phases in redistributing information between RIP and OSPF networks:

1. Configuring a RIP network
2. Adding OSPF to the core of a RIP network
3. Adding OSPF areas

Phase 1: Configuring RIP
Figure illustrates the RIP network. Three sites are connected with serial lines.

This RIP network uses a Class B address, 172.16.0.0, and a 24-bit subnet mask.

All three routers are connected to the same major network, so they will each be configured with the network 172.16.0.0 command. Click on the topology in Figure to view the running configurations of each router.

8.4.2 Phase 2: Adding OSPF to the core of a RIP network

A common first step in migrating a RIP network to an OSPF network is to configure backbone routers that run both RIP and OSPF. This is while the remaining network devices run RIP. These backbone routers act as OSPF ASBRs. Each ASBR controls the flow of routing information between OSPF and RIP. In Figure , router A, router B, and router C now act as ASBRs.

Because RIP does not need to run between the backbone routers, updates can be suppressed using the passive-interface command. Although the following example specifies RTA, the same commands could be entered on the other routers:

Router A(config)#router rip
Router A(config-router)#passive-interface serial0/0 0
Router A(config-router)#passive-interface serial0/1 1

Instead of RIP updates, OSPF updates will carry the redistributed information across the WAN links. The necessary OSPF routing and redistribution commands are shown as follows:

NOTE:

The same configuration is used for all three routers except for the network numbers.

Router A(config)#router ospf 109
Router A(config-router)#redistribute rip subnets
Router A(config-router)#network 172.16.62.0 0.0.0.255 area 0
Router A(config-router)#network 172.16.63.0 0.0.0.255 area 0

The subnets keyword tells OSPF to redistribute all subnet routes. Without the subnets keyword, only networks that are not subnetted are redistributed by OSPF.

The redistributed RIP routes appear as external Type 2 routes in OSPF, as discussed in Module 6 OSPF.

Mutual redistribution must be configured for other routers in the RIP domain, those not shown in Figure , to receive information from OSPF. The following example lists the necessary commands, which are again the same for each router:

Router A(config)#router rip
Router A(config-router)#redistribute ospf 109 match internal external 1 external 2
Router A(config-router)#default-metric 10

Note that the redistribute command includes the OSPF process ID, 109. The other keywords, match internal external 1 and external 2, instruct RIP to redistribute internal OSPF routes, as well as external Type 1 and Type 2 routes. This is the default for OSPF redistribution. These keywords are required only if its behavior is to be modified.

As illustrated in Figure , there are no paths directly connecting the RIP domains outside the core. In real world networks, this is not always the case. If one RIP domain can communicate directly with another, there is a chance that they will exchange routes, resulting in a routing feedback loop. Route filters can be used to prevent these potentially disastrous loops.

The following configuration allows the OSPF process on RTA to redistribute RIP information, only for networks 172.16.8.0 through 172.16.15.0:

Router A(config)#router ospf 109
Router A(config-router)#redistribute rip subnets
Router A(config-router)#distribute-list 11 out rip
Router A(config)#access-list 11 permit 172.16.8.0 0.0.7.255
Router A(config)#access-list 11 deny 0.0.0.0 255.255.255.255

These commands prevent RTA from advertising networks in other RIP domains onto the OSPF backbone. This prevents other boundary routers from using false information and forming a loop. When an OSPF backbone area is in place, the RIP domains can easily be converted into OSPF areas.

8.4.3 Phase 3: Adding OSPF areas

Each RIP domain can be converted into an OSPF area independently of the other RIP domains. This allows the migration of one section of the internetwork at a time, if desired.

When all three of the RIP domains have become OSPF areas, the three core routers will serve as ABRs. Recall that ABRs control the exchange of routing information between OSPF areas and the OSPF backbone. Each ABR keeps a detailed record of the topology of its area and summarizes this information in its updates to other backbone routers.

Notice that Figure also presents a new addressing scheme in the core. A 29-bit mask, 255.255.255.248, is used to address WAN links and conserve address space. Meanwhile, a 24-bit mask remains on the LAN interfaces, resulting in variable length subnet masks. OSPF fully supports VLSM, while RIP v1 does not. With OSPF as the sole routing protocol, the network can now make the most of the advantages of VLSM. The following example shows the commands necessary to configure Router A for OSPF operation on all interfaces, with the appropriate masks:

Router A(config)# router ospf 109
Router A(config-router)# network 172.16.62.0 0.0.0.7 area 0
Router A(config-router)# network 172.16.63.0 0.0.0.7 area 0
Router A(config-router)# network 172.16.8.0 0.0.0.255 area 1

Because OSPF is classless, each ABR can be configured to use route summarization. For example, Router A connects to eight networks, which occupy a contiguous address space. Therefore, this ABR can be configured as follows to send a single supernet route, which will advertise all eight of the networks:

Router A(config)# router ospf 109
Router A(config-router)# area 1 range 130.10172.16.8.0 255.255.248.0
Router A(config)# router ospf 109
Router A(config-router)# area 1 range 172.16.8.0 255.255.255.0

Router A will advertise one route, 172.16.8.0 255.255.255.0, which covers all subnets in Area 1, into Area 0. Without the range keyword in the area command, Router A would advertise each subnet individually. For example, one route for 172.16.8.0 255.255.255.0, one route for 172.16.9.0 255.255.255.0, and so forth. The migration of the network from RIP to OSPF is now complete, and redistribution is no longer necessary.

8.5.1 Configuring distribute lists and passive interfaces

8.5.2 Configuring route maps

8.5.3 Unequal-cost load balancing with IGRP

8.6.1 Route optimization challenge lab


by sdominguez.com

* prepara tu examen ccna.
* prepara tu examen ccnp.
* prepara tu certificacion ccnp.
* prepara tu certificacion ccna.
* prepara tu examenes ccna.
* prepara tu examenes ccnp.
* prepara tu certificaciones ccnp.
* prepara tu certificacion ccna.