10 redistribution

The Bryant Advantage CCNP ROUTE Study Guide

Chris Bryant, CCIE #12933 - www.thebryantadvantage.com

Back To Index

Route Redistribution Overview

What Is Route Redistribution?

Automatic Redistribution Scenarios

RIP And The Seed Metric

OSPF And The "subnets" "option"

Intro To Routing Loops

Routing Loop Lab

Preventing Routing Loops

Admin Distances and Redistribution

Default Information Originate

The ip default-gateway Command

Redistributing EIGRP

"show ip protocols"

Controlling Redistribution

Passive Interfaces

Distribute-Lists

Route Maps

Tagging Redistributed Routes

Policy Routing (And More Route Maps!)

Bonus Material:

What Is Route Redistribution?

Route redistribution is simply the process of taking routes from

one source and placing them into another routing domain. That source

doesn't have to be a dynamic routing protocol - we can redistribute

directly connected networks and static routes.

Sounds simple, right? Maybe even fun?

Actually, you'll find the basic configs of route redistribution to be just

that - simple - with two caveats:

The more route redistribution you perform in a given network, the

greater the chance of routing loops. That's especially true when you're redistributing between networks with multiple entrance / exit

points.

We both know we're in the business of details, but with route

redistribution, you really have to watch the details. Some protocols

require seed metrics; others don't. Some require you to configure a default metric; some don't. The rules aren't complex, but they are

vital.

Route redistribution is much like route summarization in that they're

both helpful in the right situation, and it should be you and I as the

network admins who decide where route redistribution takes place - not the routing protocol.

In real-world networks and your CCNP ROUTE exam, you're going to find very few scenarios where route redistribution takes place automatically.

It's probably a good idea to know where that might happen, though...

Here's a network where the now-obsolete IGRP is the LAN protocol, and

OSPF is used as the organization's WAN protocol. The central router is the only router that knows that two protocols are being used. The OSPF-

only router has no idea of the IGRP routes, and the IGRP-only router

doesn't have any of the OSPF routes.

"default next-hop" vs. "next hop"

BGP Redistribution - Potential Issues

Redistribution Metric Review

That's likely the way we want it , for two major reasons:

There's no reason for the LAN to have individual routes for any

destinations across the WAN, since the next-hop address would

always be R1.

There's really no reason for the WAN routers to have paths to the LAN networks, and it could pose a security issue for outside routers

to know exactly what network numbers we're using on our LAN -

that makes attacking our WAN that much easier.

If for some reason we did want the WAN to know about some or all of

our LAN routes, or vice versa, we'd need to configure route redistribution.

So if IGRP is obsolete, why did I mention it? Because IGRP is involved in an auto-redistribution scenario. If IGRP and EIGRP are running on

the same router and are using the exact same AS number, each

protocol will automatically redistribute their routes to the other.

There are other scenarios where route redistribution happens

automatically, all of them involving EIGRP.

Automatic Route Redistribution Scenarios

IGRP automatically redistributes with EIGRP when both run the

same AS number.

EIGRP for AppleTalk automatically redistributes between EIGRP and

RTMP (Routing Table Management Protocol, an AppleTalk routing protocol).

EIGRP for IPX will automatically redistribute between IPX for RIP (Internetwork Packet Exchange, a networking protocol used by

Novell NetWare).

Let's look at a much more common scenario - where we have multiple

EIGRP instances running on a single router (a "border router").

In the following lab, R1 is running two EIGRP instances with the AS

numbers 50 and 100. R2 is the neighbor in AS 100, R3 in AS 50. Both

routers are advertising their loopback via EIGRP.

R1 sees both routes ...

R1#show ip route eigrp 2.0.0.0/32 is subnetted, 1 subnets D 2.2.2.2 [90/2297856] via 172.12.123.2, 00:09:33, Serial0 3.0.0.0/32 is subnetted, 1 subnets D 3.3.3.3 [90/2297856] via 172.12.13.3, 00:00:29, Serial1

.. but neither R2 nor R3 sees the other's loopback.

R2#show ip route eigrp

R2#


R3#

The same rule holds for routes redistributed into an EIGRP AS -- they will not be redistributed into any other EIGRP ASes running on that router.

Note that all EIGRP routes here are internal and have an AD of 90; we

haven't done any route redistribution, so we have no external routes.

We'll revisit this lab in the EIGRP-specific portion of this session.

OSPF processes running on the same router do not automatically

exchange routes, either.

Just as with EIGRP, R1 will see both loopbacks but neither R2 nor R3 will

see the other's loopback.

R1#show ip route ospf 2.0.0.0/32 is subnetted, 1 subnets O 2.2.2.2 [110/65] via 172.12.123.2, 00:00:35, Serial0 3.0.0.0/32 is subnetted, 1 subnets O 3.3.3.3 [110/65] via 172.12.13.3, 00:00:07, Serial1

R2#show ip route ospf

R2# R3#show ip route ospf

R3#

Now that we've covered non-redistribution in detail, let's get to some

redistribution!

RIP And The Seed Metric

RIP's configuration is pretty simple - so maybe redistributing routes into

RIP is simple, too.

Maybe.

Let's take a look at the redistribute command in a RIP config with IOS Help.

R1(config)#router rip R1(config-router)#redistribute static ? metric Metric for redistributed routes route-map Route map reference <cr>

The <cr> is a little misleading here. While the command redistribute

static is a complete command, it's not enough to do the job when

redistributing routes into RIP - we need to plant a seed.

Seed metric, that is.

RIP's sole metric is hop count. If we redistribute an OSPF route into RIP

that has a cost of 74 - a common OSPF metric - RIP doesn't want

anything to do with that route, since RIP considers a metric of 16 to be "unreachable".

We have to tell RIP "here's a value for the route that you understand.",

and that value is the seed metric.

The seed metric will increment as the route travels through the new

domain, just as any other route would.

In the following network, we will redistribute one OSPF route into a RIP

domain. First, we'll try to redistribute the route without specifying the seed metric.

R1#show ip route < code table removed for clarity >

20.0.0.0/24 is subnetted, 1 subnets C 20.1.1.0 is directly connected, Serial0 172.12.0.0/24 is subnetted, 2 subnets O 172.12.34.0 [110/74] via 172.12.13.3, 00:00:12, Serial1 C 172.12.13.0 is directly connected, Serial1

R1(config)#router rip R1(config-router)#redistribute ospf 1 R1(config-router)#redistribute connected

First, we did what we should always do in this situation - make sure that

the border router has the routes we want to redistribute in the first place.

T-Shoot Checkpoint #1: If you've redistributed routes into any routing protocol - OSPF, RIP, EIGRP - and you see some of the

routes but not all of them, the first thing you should do is make

sure your border router has the routes in the first place.

If you don't see any of the routes, there's likely another issue.

We'll get to that later.

We want R2 to see both the 172.12.13.0 /24 and 172.12.34.0 /24

networks, so both OSPF and connected routes have to be redistributed into RIP on R1, since 172.12.13.0/24 is a connected route to R1.

T-Shoot Checkpoint #2: If you've successfully performed route

redistribution and find some pings don't go through during your

testing, it's likely you need to redistribute your connected

networks.

In this example, redistributing OSPF routes into RIP isn't enough,

because 172.12.13.0/24 is not an OSPF route on the router performing the redistribution.

Now on with the lab...

R2#clear ip route * R2#show ip route rip

R2#

When a show command returns nothing, there's nothing to show.

The OSPF route has not been successfully redistributed into RIP.

Since RIP converges slowly, I ran clear ip route * to force updates to be sent and to be requested by R2. We do not see the route to

172.12.34.0/24 or 172.12.13.0 /24, and a quick debug ip rip shows that

it's not contained in any update from R1.

R2#debug ip rip RIP protocol debugging is on

R2#clear ip route * R2# 00:13:39: RIP: sending request on Serial0 to 224.0.0.9 00:13:39: RIP: received v2 update from 20.1.1.1 on Serial0 00:13:39: 20.1.1.0/24 via 0.0.0.0 in 1 hops

Even though it's R2 that isn't getting the routes, the trouble's at the border router.

We didn't configure a seed metric for the route, and even though R1

allowed us to enter redistribute ospf 1 as a valid command, the route

was not redistributed. Let's go back to R1 and run the command again,

but use a seed metric this time.

R1(config)#router rip R1(config-router)#no redistribute ospf 1 R1(config-router)#no redistribute connected R1(config-router)#redistribute ospf 1 metric 2 R1(config-router)#redistribute connected metric 2

Notice that I removed the original redistribute commands. When you

configure a redistribute statement, that does not remove any previously

configured ones. (It's common to have multiple redistribute commands in a protocol config.)

Let's go to R2, clear the routing table, and see what the situation is now

with 172.12.34.0 /24.

R2#clear ip route * R2#show ip route rip 172.12.0.0/24 is subnetted, 2 subnets R 172.12.34.0 [120/2] via 20.1.1.1, 00:00:02, Serial0 R 172.12.13.0 [120/2] via 20.1.1.1, 00:00:02, Serial0 R2#ping 172.12.34.3

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.12.34.3, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)

R2 now has both the OSPF route and connected route that were

redistributed into RIP at R1. Putting the seed metric in the redistribution

command allowed us to successfully redistribute routes. However, the pings didn't go through!

Pings show us that there is an IP connectivity issue, but they don't tell us where the problem is. To begin pinpointing an IP connectivity issue, run

traceroute.

R2#traceroute 172.12.34.3

Type escape sequence to abort. Tracing the route to 172.12.34.3

1 20.1.1.1 36 msec 36 msec 32 msec 2 * * * 3 * <Ctrl-shift-6> <Ctrl-shift-6> entered here, otherwise 30 rows will appear>

R2#

The problem seems to be on R1. Let's try pinging 172.12.34.3 from

there.

R1#ping 172.12.34.3

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.12.34.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Interesting, eh? The real problem here is that the pings can get from R2

to R3, but R3 can't get them back to R2. R3 is strictly an OSPF router,

and it has no route to R2.

T-Shooting Checkpoint #3: Just because A sees B, it doesn't mean

that B sees A.

We have two options to give R3 a route to R2:

Write a static route

Perform two-way route redistribution

We're in the redistribution business right now, so let's stay there.

R1(config)#router ospf 1 R1(config-router)#redistribute connected % Only classful networks will be redistributed R1(config-router)#redistribute connected subnets

Notice that we didn't put a seed metric for redistribution into OSPF. OSPF

has a default seed metric of 20, so none has to be specified with the

redistribute command.

What OSPF does require is the subnets option to be enabled -- if you

want subnets to be redistributed into OSPF, that is.

And it's likely you do.

Let's look at R3's routing table now:

R3#show ip route ospf 20.0.0.0/24 is subnetted, 1 subnets O E2 20.1.1.0 [110/20] via 172.12.13.1, 00:01:51, Serial1

We see two important OSPF defaults in action here:

The route has a metric of 20, OSPF's default seed metric

The route is marked as "E2", short for External-Type 2. This is the default routing code for a route redistributed into OSPF. An E2

metric reflects only the cost from the ASBR (R1) to the external

destination (R2). It does not reflect the cost from the local router to

the ASBR itself.

Let's see if R3 and R2 can exchange pings...

R3#ping 20.1.1.2


R2#ping 172.12.34.3


R2 can now ping R3's Ethernet0 interface, and R3 can ping R2's Serial0

interface.

This is about as simple as a route redistribution scenario can get, and

you saw that it could go wrong easily. That's why we're going to spend some serious time here on redistribution theory as well as looking at

several hands-on examples.

Speaking of theory, here are those default seed metrics I mentioned...

RIP and EIGRP have a seed metric of "infinity", and you know no

routes with a metric of "infinity" are ever going to be placed into a

routing table. Both RIP and EIGRP require a default seed metric to

be defined during the redistribution process.

OSPF has a default seed metric of 20, as well as defaulting to a

route type of E2. There's always an exception, and the exception here is that BGP routes are given a metric of 1 by OSPF. And as

you'll see, you better be really careful when redistributing BGP into

OSPF.

Another link-state protocol, ISIS has a default seed metric of

zero, and it does allow routes to be redistributed without a specified seed metric. (ISIS is no longer tested on the CCNP routing exam.)

OSPF's default seed metric can be changed in the redistribute command

itself. Here, we'll double the OSPF default seed metric of 20 for EIGRP

routes being redistributed into OSPF.

R2(config)#router ospf 1 R2(config-router)#redistribute eigrp 100 ? metric Metric for redistributed routes metric-type OSPF/IS-IS exterior metric type for redistributed routes route-map Route map reference subnets Consider subnets for redistribution into OSPF tag Set tag for routes redistributed into OSPF <cr>

R2(config-router)#redistribute eigrp 100 metric ? <0-16777214> OSPF default metric

R2(config-router)#redistribute eigrp 100 metric 30 % Only classful networks will be redistributed R2(config-router)#redistribute eigrp 100 metric 30 subnets

There's one more reminder to include the subnets option if you want

subnets to be redistributed. Call me crazy, but I think that's an important detail to remember, because the CCNP ROUTE exam won't

remind you of it.

Suboptimal Routing And Routing Loops

When route redistribution works well, it's quite a rush, both in production

networks and the exam room.

When it doesn't work well, it can become your worst nightmare. The

larger your network, the harder it is to see all the potential issues. You

can think you've got all the bases covered, and then you put your

carefully thought-out route redistribution plan into action -- and a

problem quickly occurs that you never saw coming.

This is particularly true of two-way route redistribution.

Most of the problems you have with redistributed routes fall into two

categories -- suboptimal routing (bad) and routing loops (very bad).

Suboptimal routing generally occurs because of a miscalculation in

coming up with the right seed metric value. The packets will eventually get where they are supposed to go.

Keyword: "eventually"

R2 has two paths to send data to 172.12.34.0/24. The data could follow

the path R1-R4-R3, or the more direct R1-R3.

Quick aside: Never assume the physically shortest path is the logically shortest path, whether you're routing or switching.

All values being equal, the best path is the more direct path. If route redistribution metrics are incorrect, R2 could end up using the longer

path. Data would still reach the desired destination, but would take

longer to arrive and would put an unnecessary strain on R4's router resources. Suboptimal routing at its best / worst.

A worse effect of improperly configured route redistribution is a routing loop. Packets that enter a routing loop will be sent back and forth

between the same group of routers over and over. Packets that enter a

routing loop will keep looping and will never reach the intended destination.

Traceroute is an excellent tool to detect a routing loop. If you see the

same IP addresses appearing in the command output over and over,

you've got a routing loop.... as you're about to see.

This lab's networks:

Frame Relay: 172.12.123.0 /24

Ethernet: 172.23.23.0 /24

R3 / R4 Link: 172.34.34.0 /24

R4's Loopback: 4.4.4.4 /32, advertised into OSPF

We want the routers in the RIP domain to have connectivity to R4's

loopback - and as always, before beginning to configure redistribution,

we'll check the border router and make sure it has that route to begin

with!

R3#show ip route ospf 4.0.0.0/32 is subnetted, 1 subnets O 4.4.4.4 [110/65] via 172.34.34.4, 00:00:03, Serial1 R3#ping 4.4.4.4


The BR has the route and connectivity to that network, so now we'll

config redistribution. This time we'll use the default-metric command to

define RIP's seed metric.

R3(config)#router rip R3(config-router)#redistribute ospf 1 R3(config-router)#redistribute connected R3(config-router)#redistribute static R3(config-router)#default-metric 2

Note that even though we had no static routes that needed redistribution

- actually, there were no static routes on R3 - I included the redistribute

static command in the config.

More than once I've seen admins enter the redistribute connected and

redistribute static commands when they weren't really necessary. You might want to avoid this "blind configuration", since someone may add a

static route to the config later that you don't want redistributed.

Someone who writes an incorrect static route, like this:

R3(config)#ip route 4.4.4.4 255.255.255.255 172.12.123.1

That static route to 4.4.4.4 is pointing to R1's serial interface, not R4's.

Let's see the result on R2:

R2#show ip route rip 4.0.0.0/32 is subnetted, 1 subnets R 4.4.4.4 [120/2] via 172.23.23.3, 00:00:07, Ethernet0 172.34.0.0/24 is subnetted, 1 subnets R 172.34.34.0 [120/1] via 172.23.23.3, 00:00:07, Ethernet0

No big deal, right? The routes are still there. Let's ping 4.4.4.4 now:

R2#ping 4.4.4.4

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds: .....

We had connectivity a few minutes ago, and lost it when that static route

was redistributed -- and that's because the result of that redistribution is a routing loop, as shown by traceroute.



1 172.23.23.3 4 msec 4 msec 4 msec 2 172.12.123.1 36 msec 36 msec 32 msec 3 172.12.123.2 28 msec 28 msec 28 msec 4 172.23.23.3 32 msec 24 msec 28 msec 5 172.12.123.1 60 msec 60 msec 60 msec 6 172.12.123.2 52 msec 52 msec 52 msec 7 172.23.23.3 52 msec 52 msec 52 msec 8 172.12.123.1 84 msec 84 msec 80 msec 9 172.12.123.2 72 msec 72 msec 72 msec 10 172.23.23.3 72 msec 72 msec 72 msec 11 172.12.123.1 104 msec 104 msec 104 msec 12 172.12.123.2 96 msec 124 msec 92 msec 13 172.23.23.3 96 msec 96 msec 96 msec 14 172.12.123.1 128 msec 124 msec 128 msec 15 172.12.123.2 120 msec 116 msec 120 msec 16 172.23.23.3 120 msec 120 msec 116 msec 17 172.12.123.1 148 msec 148 msec 148 msec 18 172.12.123.2 140 msec 140 msec 144 msec 19 172.23.23.3 140 msec 140 msec 140 msec 20 172.12.123.1 172 msec 176 msec 172 msec 21 172.12.123.2 160 msec 164 msec 160 msec 22 172.23.23.3 164 msec 164 msec 164 msec 23 172.12.123.1 192 msec 196 msec 196 msec 24 172.12.123.2 184 msec 188 msec 188 msec 25 172.23.23.3 188 msec 184 msec 184 msec 26 172.12.123.1 216 msec 220 msec 220 msec 27 172.12.123.2 212 msec 212 msec 208 msec 28 172.23.23.3 208 msec 212 msec 212 msec 29 172.12.123.1 256 msec 240 msec 240 msec

30 172.12.123.2 232 msec 232 msec 232 msec

Anytime you see the same few (or two) IP addresses in traceroute, you have a routing loop. Basically, here's what's happening:

Line 1: R2 pings 4.4.4.4. According to R2's routing table, the next-hop IP address is 172.23.23.3, and the packet is sent there.

Line 2: R3 looks up 4.4.4.4 in its routing table, and as a result of that static route, the next-hop IP is 172.12.123.1 -- R1's serial interface. (The static route went into the routing table since its AD is less than that of the other source for that exact same network, OSPF.)

Line 3: R1 gets the packet, looks in its routing table, and sees the next-hop for 4.4.4.4 is 172.12.123.2 -- R2's serial interface.

At that point, R2 gets the packet back, and the entire process begins again - and we have ourselves a routing loop.

Preventing Routing Loops .. And Fixing Them

There is no "one-size-fits-all" solution for routing loop prevention. The

solution you use depends on your network topology, where the routing

loop is taking place, and the preexisting configuration.

Having said that, we're going to take a look at some routing loop

prevention mechanisms that not only will Cisco expect you to know to become a CCNP, but you should know about each of them in order to use

the proper strategy for your particular network.

The first solution is having a solid network design in the first place, which

is why it's more than worth your time to carefully analyze your network

topology and identify potential trouble spots.

If you're lucky, you'll see a network like the one illustrated below where the routing domains' only interconnection is at the point of redistribution

itself.

The importance of planning before implementing redistribution cannot be

overstated. Examine both the logical and physical topology of your

network, the routing domains, the traffic flows - everything.

This network topology lowers the possibility of routing loops, because the

only interconnectivity between the RIP and OSPF domains is at the point

of route redistribution. You need to decide in advance where your protocol border routers are - that is, the routers where both protocols

involved in redistribution are configured.

Naturally, it's not always that easy - many networks have multiple

connectivity points between routing domains for redundancy's sake.

This is a great idea - until you have to configure redistribution. Then you're going to hate redundancy. (It's okay, I won't tell anybody.)

This topology is a dream for network fault tolerance, and a nightmare when it comes to route redistribution. There are four points at which the

two protocols will interact; R1-R2, R1-R3, R2-R3, and R4-R5. R1 is still

the best location for redistribution to be configured. What you'd have to

concern yourself with here are routes being sent back and forth between the other routers.

I've worked with both network configurations shown here and the first

example is a lot easier to work with, but the second example is more

common. You've got to be prepared to work with both.

Speaking from personal experience, if you can use one-way route

redistribution in situations with multiple boundary routers, you should.

Cisco recommends that as well - avoid two-way route redistribution whenever possible.

Monitoring And Adjusting A Protocol's Administrative Distance

You know what the AD is and you know the common and not-so-

common AD values - and now we're going to put that knowledge to use.

ADs are used only when there is no "longest match" in the routing table.

If a router has two routes to the same destination that have exactly the

same prefix length, there's got to be a tiebreaker, and AD is that tiebreaker.

AD is much like split horizon - most of the time it does just what you

want it to do, but under certain circumstances, you've got to make some

changes.

You can't disable AD the way you can disable split horizon, but you can

make some (careful) changes in AD values to fine-tune your network after route redistribution.

The RIP domain includes:

The 172.12.123.0 /24 frame cloud connecting R1, R2, and R3

The 10.1.1.0 /24 network on R1

The OSPF Area 0 network:

The 30.1.1.0 /24 network connecting R2, R3, R4, and R5

The objective:

All routers in the OSPF domain have the network 10.1.1.0 /24

network in their tables.

Process:

Miniaturization!

(Okay, we'll use route redistribution instead.)

As always, our first step is to make sure our border router has the routes to be redistributed:

The first step is to make sure R3 sees the RIP route ....

R3#show ip route rip 10.0.0.0/24 is subnetted, 1 subnets R 10.1.1.0 [120/1] via 172.12.123.1, 00:00:19, Serial0


R3 sees the route, and we'll now redistribute that route into the OSPF

domain. I put R2's table there as well, because it's a very good idea to

keep an eye on the other routing tables in your routing domain as well when performing redistribution.

R3(config)#router ospf 1 R3(config-router)#redistribute rip subnets R3(config-router)#redistribute connected subnets

R3(config-router)#router rip R3(config-router)#redistribute connected metric 1

R4 now sees both 172.12.123.0 and 10.1.1.0 /24. As we expect, both

routes are marked E2 and have a cost of 20, and the next hop for both

routes is the IP address of R3's E0 interface.

R5 shows the exact same OSPF routing table:

R4#show ip route ospf 172.12.0.0/24 is subnetted, 1 subnets O E2 172.12.123.0 [110/20] via 30.1.1.3, 00:00:15, Ethernet0 10.0.0.0/24 is subnetted, 1 subnets O E2 10.1.1.0 [110/20] via 30.1.1.3, 00:00:15, Ethernet0


When you have multiple border routers and you're configuring one of

them for redistribution, be sure to watch the others for ill effects of redistribution.

R2's routing table before redistribution:



R2# (No OSPF routes to show)

R2's routing table after redistribution:

R2#show ip route rip

R2# (No RIP routes to show)

R2#show ip route ospf 10.0.0.0/24 is subnetted, 1 subnets O E2 10.1.1.0 [110/20] via 30.1.1.3, 00:04:14, Ethernet0

We don't expect 172.12.123.0/24 to show up in R2's RIP or OSPF routing

table, because it's a directly connected network. However, the route to

10.1.1.0 /24 is now using R3's Ethernet0 as a next-hop address, and it's now an OSPF route.

Packets from R2 destined for the 10.1.1.0 /24 network will now take a longer path than they would have before redistribution was configured

on R3. Previously, such packets would have gone straight to R1; now,

those packets will go to R3, then R1. Hello, suboptimal routing!

Why did R2 choose the longer path? After redistribution is configured on R3, R2 is receiving two routes for the network 10.1.1.0/24. One is from

R1 via RIP; the other is from R3 via OSPF. (The OSPF update is shown

with a two-headed arrow to indicate that every router on the broadcast

segment will receive the update sent by R3.)

The prefix length of /24 is contained with both updates, so there has to

be a tiebreaker, and that tiebreaker is AD. OSPF has an AD of 110, where RIP's is 120, so the OSPF route is chosen.

You would have noticed this by looking at the table, but it's a good idea

to check all routes on a border router that is not performing

redistribution with the traceroute command. This command shows you

the exact path data is taking to reach the destination, which gives you

an idea of whether suboptimal routing has occurred.

R2#ping 10.1.1.1




1 30.1.1.3 8 msec 4 msec 20 msec 2 172.12.123.1 36 msec * 36 msec

Our basic IP connectivity test, ping, shows that we still have connectivity to 10.1.1.0/24. The problem is that this data is taking the long way to

get there, with a next-hop of 30.1.1.3.

With suboptimal routing, we basically have three different approaches to

resolving the issue:

Changing the administrative distance

Changing the route's metrics

Filter routes with distribute-lists (covered in a later section)

Let's apply the first option....

To change the AD of a protocol on a router, use the distance command

under the appropriate routing process. We'll use this command to change the AD of OSPF on R2 to 200.

R2(config)#router ospf 1 R2(config-router)#distance ? <1-255> Administrative distance ospf OSPF distance

R2(config-router)#distance 200



< No OSPF routes to show >



1 172.12.123.1 36 msec * 36 msec

The RIP route is now preferred because all OSPF routes on R2 have an AD of 200. The next-hop IP address is now 172.12.123.1, the direct

path to 10.1.1.0 /24.

If we shut down the RIP-enabled interface on R2, the OSPF routes will be

put into the routing table. You can see the OSPF route's AD has been

successfully changed to 200.


In effect, we turned the OSPF routes into something similar to a floating static route - the higher AD guarantees the OSPF routes will appear in

the table only if the RIP routes disappear.

You have to be truly careful using any "all-or-nothing" command when it

comes to your routing table, and the distance command does just that -

it changes the AD of all the routes acquired by that particular protocol.

More likely, you'll want to change the AD of some routes rather than all

of them. To do so, you can write an ACL identifying the routes whose AD you want to affect and tie that ACL in with the distance command.

To illustrate, let's take a routing table from another lab. R2 has three routes in its EIGRP routing table, all with an AD of 90.

R2#show ip route eigrp 3.0.0.0/32 is subnetted, 1 subnets D 3.3.3.3 [90/409600] via 172.12.23.3, 00:00:28, Ethernet0 4.0.0.0/32 is subnetted, 1 subnets D 4.4.4.4 [90/409600] via 172.12.23.3, 00:00:28, Ethernet0 5.0.0.0/32 is subnetted, 1 subnets D 5.5.5.5 [90/409600] via 172.12.23.3, 00:00:28, Ethernet0

Let's double the AD of the route for 4.4.4.4 while leaving the other routes alone. ACL 5 identifies that route and that route only, and then

we just use that ACL number at the end of the distance command.

R2(config)#access-list 5 permit 4.4.4.4 0.0.0.0

R2(config)#router eigrp 100 R2(config-router)#distance 180 0.0.0.0 255.255.255.255 ? <1-99> IP Standard access list number <1300-1999> IP Standard expanded access list number WORD Standard access-list name

R2(config-router)#distance 180 0.0.0.0 255.255.255.255 5

After clearing the route table, the route to 4.4.4.4 now has an AD of

180, while the other distances remain the same.


Anytime you have two dynamic routing protocols operating in the same

network and redistribution is involved, you may find it helpful to fine-tune a route or two in this fashion.

For example, if a network is running OSPF and RIPv2, the OSPF route will

always be selected if AD is the determining factor. You may have some

RIP routes that are actually optimal, but won't be used. Now you know

how to selectively change the AD of those particular RIP routes.

Default-Information Originate (Always?)

You'll see the following section in the Multi-Area OSPF section as well.

Since this command redistributes a default route, I'm putting it here as well.

It's worth seeing again.

You know that default routes are generated in OSPF when stub and total stub areas are involved.

You also know that you can't make Area 0 a stub area.

What we can do is run the OSPF command default-information originate

with the always option to send a default route to all other OSPF routers -- and that includes routers in Area 0.

The always option allows the router to propagate a default route without

actually having one in its routing table.

Without that option, the router must have a default route in its table in

order to advertise one. If there is no default route to advertise,

neighbors will not receive a default route!

Here, both R2 and R3 will have the same next-hop address for every

remote destination - R1's serial0 interface, 172.12.123.1.

That fact would simply scream at us to configure this as a stub or total

stub area, but there's just one problem ...

R1(config)#router ospf 1 R1(config-router)#area 0 stub OSPF: Backbone can not be configured as stub area R1(config-router)#area 0 stub ? no-summary Do not send summary LSA into stub area <cr>

R1(config-router)#area 0 stub no-summary OSPF: Backbone can not be configured as stub area

.... all three routers are in Area 0, and we can't config A0 as any kind of stub.

We can use the default-information originate command to send a default

route from R1 to the spoke routers. Assuming R1 does not have a

default route in its own table, we'll need to use the always option.

Here's what happens if we don't do so:

R1(config-router)#default-information ? originate Distribute a default route

R1(config-router)#default-information originate ? always Always advertise default route metric OSPF default metric metric-type OSPF metric type for default routes route-map Route-map reference <cr>

R1(config-router)#default-information originate


R2#

Nothing on R2 or R3. We'll go back to R1, remove the first version of

the command, and replace it with the same command and the always

option.

R1(config-router)#no default-information originate R1(config-router)#default-information originate always

And now to R2 and R3 ....

R2#show ip route ospf O*E2 0.0.0.0/0 [110/1] via 172.12.123.1, 00:00:10, Serial0

R3#show ip route ospf O*E2 0.0.0.0/0 [110/1] via 172.12.123.1, 00:00:15, Serial0

Both routers have the route, marked as both a candidate default route

and an E2 route. Unlike stub areas, this route does not automatically

replace any routes already present in the receivers' route tables. You'll have to filter those some other way - shortly, we'll do just that.

ip default-gateway vs. ip default-network

The ip default-network command can be used to inject a default route into your routing process, too.

Maybe.

If the router has an interface directly connected to the network specified with this command, the router will generate a default route and send that

route to its neighbor routers.

This command can be a little tricky to use, and it works differently with

different protocols. Here, R1 and R2 are both running RIPv2. When a

gateway of last resort is configured using ip default-network on R1, RIP will advertise a default route of 0.0.0.0 to R2.

Additionally, RIP does not need to know about the network configured as the default. R1 will name the network 13.0.0.0 /8 as the default

network. This route is not being advertised by RIP, but R2 still has the

default route.

R1(config)#ip default-network 13.0.0.0

R2#show ip route < code table deleted for clarity >

Gateway of last resort is 172.12.123.1 to network 0.0.0.0

172.12.0.0/24 is subnetted, 1 subnets C 172.12.123.0 is directly connected, Serial0 30.0.0.0/24 is subnetted, 1 subnets C 30.1.1.0 is directly connected, Ethernet0 R* 0.0.0.0/0 [120/1] via 172.12.123.1, 00:00:25, Serial0

In contrast, EIGRP has to know about the default network via either a

network command or a static route redistribution.

It's easy to get ip default-network and ip default-gateway mixed up. They're both used to generate a default route. The key difference is that

ip default-gateway is used when IP routing is off, while ip default-

network is used when IP routing is on.

And after all the redistribution we've done here, redistributing a static

route is simple enough - just watch the seed metric requirements of the protocol receiving that route.

R1(config)#router rip R1(config-router)#redistribute ? bgp Border Gateway Protocol (BGP) connected Connected egp Exterior Gateway Protocol (EGP) eigrp Enhanced Interior Gateway Routing Protocol (EIGRP) igrp Interior Gateway Routing Protocol (IGRP) isis ISO IS-IS iso-igrp IGRP for OSI networks metric Metric for redistributed routes mobile Mobile routes odr On Demand stub Routes ospf Open Shortest Path First (OSPF) rip Routing Information Protocol (RIP) route-map Route map reference static Static routes <cr>

R1(config-router)#redistribute static metric 1

EIGRP Redistribution

We'll keep RIP for the protocol running between R1, R2, and R3.

10.1.1.0 /24 is still advertised by RIP. The protocol running over the

ethernet segment is now EIGRP.

EIGRP has a default seed metric of "infinity", and we need to define a seed metric when we perform the redistribution. With EIGRP, that

means defining five different settings.

There are two ways to set the seed metric with EIGRP:

Set the metric for the redistributed routes learned from a specific

source at the end of the redistribute command.

Use the default-metric command to set the default metric for all

routes being redistributed.

We'll use the first method in this example. Note that the redistribute

command is incomplete until all five metrics have been defined. Unlike

RIP, EIGRP will not allow you to redistribute routes into an AS without specifying the seed metric.

Ignore the mention of "IGRP" in IOS Help - that's just an IOS quirk.

R3(config)#router eigrp 100 R3(config-router)#redistribute rip metric ? <1-4294967295> Bandwidth metric in Kbits per second

R3(config-router)#redistribute rip metric 1544 ? <0-4294967295> IGRP delay metric, in 10 microsecond units

R3(config-router)#redistribute rip metric 1544 10 ? <0-255> IGRP reliability metric where 255 is 100% reliable

R3(config-router)#redistribute rip metric 1544 10 255 ? <1-255> IGRP Effective bandwidth metric (Loading) where 255 is 100% loaded

R3(config-router)#redistribute rip metric 1544 10 255 1 ? <1-4294967295> IGRP MTU of the path

R3(config-router)#redistribute rip metric 1544 10 255 1 1500

R3(config-router)#redistribute connected metric 1544 10 255 1 1500

The values I put in are typical EIGRP redistribution values. For your CCNP ROUTE exam, it's an excellent idea to have the order of those

values down cold. On a production router, you can always use IOS Help

to remind you of the order.

Let's check R4 and R5 to see if their EIGRP tables show the redistributed

routes.

R4#show ip route eigrp 100 172.12.0.0/24 is subnetted, 1 subnets D EX 172.12.123.0 [170/1686016] via 30.1.1.3, 00:02:04, Ethernet0 10.0.0.0/24 is subnetted, 1 subnets D EX 10.1.1.0 [170/1686016] via 30.1.1.3, 00:02:04, Ethernet0

R5#show ip route eigrp 172.12.0.0/24 is subnetted, 1 subnets D EX 172.12.123.0 [170/1686016] via 30.1.1.3, 00:02:29, Ethernet0 10.0.0.0/24 is subnetted, 1 subnets D EX 10.1.1.0 [170/1686016] via 30.1.1.3, 00:02:29, Ethernet0

The routes have been redistributed successfully into EIGRP. The

redistributed route is marked with "D EX", indicating that it is an EIGRP External route. As seen in the brackets, the AD of these routes is 170 by

default, as opposed to the AD of 90 for EIGRP internal routes and 5 for

EIGRP Summary routes.

We can also use the default-metric command to set the seed metric. This

will set the seed metric for all routes redistributed into EIGRP.

R2(config)#router eigrp 100 R2(config-router)#default-metric 1544 10 255 1 1500

Let's now look at R2's RIP and EIGRP routing tables, before and after

redistribution.

Before redistribution:



R2# (No EIGRP routes to show)

After redistribution:



R2# (No EIGRP routes to show)

The tables on R2 are exactly the same after redistribution.

Why is R2 choosing to put the RIP route into its table rather than the EIGRP route?

R2 is receiving a RIP update containing the route with an AD of 120,

where the external EIGRP update coming in on its ethernet interface has

an AD of 170. The lowest AD is preferred, so the RIP route is still

considered the best route.

If we wanted the EIGRP path to be preferred, we could change its AD on R2. We'll change the default AD of EIGRP External routes on R2 to 119,

just one less than the AD of 120. The command is a little different for

EIGRP (like every other EIGRP command, right?)

R2(config)#router eigrp 100 R2(config-router)#distance ? <1-255> Administrative distance eigrp IP-EIGRP distance

R2(config-router)#distance eigrp ?

<1-255> Distance for internal routes

R2(config-router)#distance eigrp 90 ? <1-255> Distance for external routes

R2(config-router)#distance eigrp 90 119

Note that when you want to change only one AD, you still need to

specify both with this command.

The result on R2's routing tables:

R2#show ip route rip

R2#show ip route eigrp 10.0.0.0/24 is subnetted, 1 subnets D EX 10.1.1.0 [119/1686016] via 30.1.1.3, 00:01:45, Ethernet0

This skill becomes even more valuable when you're configuring two-way

route redistribution, since changing the AD of one of your routing

protocols can help prevent routing loops.

Verifying Redistribution With "Show IP Protocols"

When configuring route redistribution or changing default values, you

need to run show ip protocols to make sure you are getting the results

you thought you'd be getting.

Here is the command output on R3:

R3#show ip protocols Routing Protocol is "rip" Sending updates every 30 seconds, next due in 5 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Redistributing: connected, rip Default version control: send version 2, receive version 2 Interface Send Recv Triggered RIP Key-chain Serial0 2 2 Serial1 2 2 Automatic network summarization is not in effect Maximum path: 4 Routing for Networks: 172.12.0.0 Routing Information Sources: Gateway Distance Last Update 172.12.123.1 120 00:00:19 Distance: (default is 120)

You can see that connected routes are being redistributed into RIP, that

autosummarization is turned off, version 2 has been hard-coded, and

RIP updates are being received from 172.12.123.1.

The rest of the output:

Routing Protocol is "eigrp 100" Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Default networks flagged in outgoing updates Default networks accepted from incoming updates EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0 EIGRP maximum hopcount 100 EIGRP maximum metric variance 1 Redistributing: connected, rip, eigrp 100 Automatic network summarization is not in effect Maximum path: 4 Routing for Networks:

30.1.1.0/24 Routing Information Sources: Gateway Distance Last Update Distance: internal 90 external 170

The EIGRP portion of the command from top to bottom shows...

The metric weights have not been changed

Unequal-cost load balancing is in effect (variance is set to 1)

RIP and connected routes are being redistributed into EIGRP

No EIGRP updates are coming in from other routers

Default ADs have not been changed

Controlling Redistributed Routes

Not only can you use the distance command to alter route selection after

redistribution, but you can also control which routers will receive the

redistributed routes in the first place. Even better, many of the tools at

our disposal are features you're already familiar with.

Certain routing protocols, particularly OSPF, will generate default routes

under certain circumstances. They can be helpful in avoiding routing loops, especially if a default route is configured instead of performing

two-way redistribution. We're always trying to avoid two-way

redistribution!

If you want each router in this network to be able to reach every other network, a default route could be sent into one routing domain while

one-way redistribution is performed with the other. For instance, a

default route could be generated by the ASBR (R1) for R3 and R4 to

use. The OSPF routes could then be redistributed into the RIP domain.

We could use one of two techniques with OSPF to make this happen,

depending on whether we're dealing with Area 0:

If we are, default-information originate (always) would come in handy

If we're not, making the area a stub or total stub route would be the direction to go in.

Passive Interfaces

Passive interfaces can be a big help in controlling routing updates and or/ routing control traffic, depending on which protocol you're dealing

with:

RIP: Passive interfaces do not send routing updates, but will accept

them. RIP adjacencies aren't affected by passive interfaces since RIP

doesn't have adjacencies in the first place.

In the following example, R1's Ethernet0 interface has been configured as passive. R1's loopback 10.1.1.1 /24 is advertised into RIP. The R1-

R2-R3 network is our usual Frame Relay network, 172.12.123.0 /24.

R1's config:

router rip version 2 passive-interface Ethernet0 network 10.0.0.0 network 30.0.0.0

network 172.12.0.0 no auto-summary

Both R2 and R3 see the loopback and the 30.1.1.0 subnet.

R2#show ip route rip 10.0.0.0/24 is subnetted, 1 subnets R 10.1.1.0 [120/1] via 172.12.123.1, 00:00:15, Serial0 30.0.0.0/24 is subnetted, 1 subnets R 30.1.1.0 [120/1] via 172.12.123.1, 00:00:15, Serial0


R5 does not see R1's loopback - the passive interface is not sending routing updates to R5.

R5#show ip route rip R5#

Let's add the loopback on R5 to the RIP process and see if R1 sees it:

R5(config)#router rip R5(config-router)#network 5.0.0.0

R1#show ip route rip 5.0.0.0/24 is subnetted, 1 subnets R 5.1.1.0 [120/1] via 30.1.1.5, 00:00:14, Ethernet0

R1 does see the route. A RIP passive interface will not send routing

updates, but it will accept them. This partial output of debug ip rip proves that R1 is multicasting updates via Serial0, but not E0, and is

receiving updates from all other routers in the domain.

EIGRP: Hellos aren't sent, so no adjacency can be formed via a passive

interface. If an adjacency exists on an interface that is then made passive, the adjacency is dropped. A subnet running a passive interface

can be advertised.

We'll use the exact same topology from the previous lab in this example

and enable EIGRP on the Frame Relay and Ethernet segments.

R1 has adjacencies to all of the other routers in the AS, R2 and R3 see the 30.1.1.0 /24 network, and R5 sees the 172.12.123.0 /24 network.

R1#show ip eigrp neighbor IP-EIGRP neighbors for process 100 H Address Interface

2 30.1.1.5 Et0 1 172.12.123.3 Se0 0 172.12.123.2 Se0

R2#show ip route eigrp 30.0.0.0/24 is subnetted, 1 subnets D 30.1.1.0 [90/2195456] via 172.12.123.1, 00:04:43, Serial0

R3#show ip route eigrp 30.0.0.0/24 is subnetted, 1 subnets D 30.1.1.0 [90/2195456] via 172.12.123.1, 00:04:46, Serial0 R5#show ip route eigrp 172.12.0.0/24 is subnetted, 1 subnets D 172.12.123.0 [90/2195456] via 30.1.1.1, 00:05:05, Ethernet0

What will the impact be when we make e0 passive? Let's find out!

R1(config)#router eigrp 100 R1(config-router)#passive-interface ethernet0

R1#show ip eigrp neighbor IP-EIGRP neighbors for process 100 H Address Interface

1 172.12.123.3 Se0 0 172.12.123.2 Se0

The first impact is the lost adjacency between R1 and R5. EIGRP passive interfaces do not send Hellos, and we know what happens when that

doesn't happen. As a result, R5 loses the EIGRP route for the Frame

Relay network.

R5#show ip route eigrp R5#

What about R2 and R3? Will they still see the 30.1.1.0 /24 network?

R2#show ip route eigrp 30.0.0.0/24 is subnetted, 1 subnets D 30.1.1.0 [90/2195456] via 172.12.123.1, 00:08:47, Serial0 R3#show ip route eigrp 30.0.0.0/24 is subnetted, 1 subnets D 30.1.1.0 [90/2195456] via 172.12.123.1, 00:08:52, Serial0

Yes, they do! EIGRP passive interfaces do not send Hellos, but the subnet running on that passive interface can still be advertised via the

network command.

OSPF: Passive interfaces do not send OSPF Hellos, so again no

adjacency can be formed, and existing adjacencies are lost on interfaces

that are then configured as passive.

Additionally, the subnet running on the passive interface will be

advertised as a stub network.

We'll use the same topology as the previous two labs.

R1 has an OSPF neighbor relationship with all other routers in the network:

R1#show ip ospf nei

Neighbor ID Pri State Dead Time Address Interface

5.1.1.1 1 FULL/BDR 00:00:33 30.1.1.5 Ethernet0

172.12.123.2 0 FULL/DROTHER 00:01:46 172.12.123.2 Serial0

172.12.123.3 0 FULL/DROTHER 00:01:55 172.12.123.3 Serial0

The other routers see 1 OSPF route.

R2#show ip route ospf 30.0.0.0/24 is subnetted, 1 subnets O 30.1.1.0 [110/74] via 172.12.123.1, 00:02:52, Serial0



172.12.0.0/24 is subnetted, 1 subnets O 172.12.123.0 [110/74] via 30.1.1.1, 00:03:02, Ethernet0

Let's make E0 passive and watch the results.

We know what the first result is going to be...

R1(config)#router ospf 1 R1(config-router)#passive-int ethernet0 00:40:56: %OSPF-5-ADJCHG: Process 1, Nbr 5.1.1.1 on Ethernet0 from FULL to DOWN, Neighbor Down: Interface down or detached

The R1 - R5 adjacency is lost immediately, and we know R5 lost its OSPF

route as a result. But is the 30.1.1.0 /24 network still advertised into OSPF?



Yes, it is! Just as with EIGRP, the adjacency through the now passive

interface is lost, but the subnet is still advertised via the network

command.

You can set all interfaces on a router as passive for a given protocol with the passive-interface default command.

R3(config)#router ospf 1 R3(config-router)#passive-interface default

To set the interfaces back to their default, just use the no passive-

interface default command.

R3(config-router)#no passive-interface default

Using Distribute-Lists To Control Redistribution

Once you perform route redistribution, you'll often find that you need to fine-tune the process by allowing some routes to be redistributed while

preventing redistribution of other routes. We can do that with distribute-

lists.

A distribute-list uses an ACL to define the routes to be redistributed -

and explicitly or implicitly prohibited from redistribution.

Here's the network for the first example:

R1 is receiving RIP updates from R5 for six networks:

R1#show ip route rip 5.0.0.0/24 is subnetted, 1 subnets R 5.1.1.0 [120/1] via 30.1.1.5, 00:00:09, Ethernet0 6.0.0.0/24 is subnetted, 1 subnets R 6.1.1.0 [120/1] via 30.1.1.5, 00:00:09, Ethernet0 7.0.0.0/24 is subnetted, 1 subnets R 7.1.1.0 [120/1] via 30.1.1.5, 00:00:09, Ethernet0 8.0.0.0/24 is subnetted, 1 subnets R 8.1.1.0 [120/1] via 30.1.1.5, 00:00:09, Ethernet0 9.0.0.0/24 is subnetted, 1 subnets R 9.1.1.0 [120/1] via 30.1.1.5, 00:00:09, Ethernet0 10.0.0.0/24 is subnetted, 1 subnets R 10.1.1.0 [120/1] via 30.1.1.5, 00:00:09, Ethernet0

If we perform redistribution as we have throughout this section, the

OSPF routers would see all of those routes - as shown here.

R1(config)#router ospf 1 R1(config-router)#redistribute rip subnets R1(config-router)#redistribute connected subnets

R2#show ip route ospf 5.0.0.0/24 is subnetted, 1 subnets O E2 5.1.1.0 [110/20] via 172.12.123.1, 00:00:07, Serial0 6.0.0.0/24 is subnetted, 1 subnets O E2 6.1.1.0 [110/20] via 172.12.123.1, 00:00:07, Serial0 7.0.0.0/24 is subnetted, 1 subnets O E2 7.1.1.0 [110/20] via 172.12.123.1, 00:00:07, Serial0 8.0.0.0/24 is subnetted, 1 subnets O E2 8.1.1.0 [110/20] via 172.12.123.1, 00:00:07, Serial0 9.0.0.0/24 is subnetted, 1 subnets O E2 9.1.1.0 [110/20] via 172.12.123.1, 00:00:07, Serial0 10.0.0.0/24 is subnetted, 1 subnets O E2 10.1.1.0 [110/20] via 172.12.123.1, 00:00:07, Serial0 30.0.0.0/24 is subnetted, 1 subnets O E2 30.1.1.0 [110/20] via 172.12.123.1, 00:00:07, Serial0

R3#show ip route ospf 5.0.0.0/24 is subnetted, 1 subnets O E2 5.1.1.0 [110/20] via 172.12.123.1, 00:00:20, Serial0 6.0.0.0/24 is subnetted, 1 subnets O E2 6.1.1.0 [110/20] via 172.12.123.1, 00:00:20, Serial0 7.0.0.0/24 is subnetted, 1 subnets O E2 7.1.1.0 [110/20] via 172.12.123.1, 00:00:20, Serial0

8.0.0.0/24 is subnetted, 1 subnets O E2 8.1.1.0 [110/20] via 172.12.123.1, 00:00:20, Serial0 9.0.0.0/24 is subnetted, 1 subnets O E2 9.1.1.0 [110/20] via 172.12.123.1, 00:00:20, Serial0 10.0.0.0/24 is subnetted, 1 subnets O E2 10.1.1.0 [110/20] via 172.12.123.1, 00:00:20, Serial0 30.0.0.0/24 is subnetted, 1 subnets O E2 30.1.1.0 [110/20] via 172.12.123.1, 00:00:20, Serial0

What if we don't want those routers to know about the existence of the

8.1.1.0 and 9.1.1.0 networks? We can write an ACL identifying those

networks as networks to be denied, and then applying that ACL to the redistribution process via the distribute-list command.

R1(config)#access-list 17 deny 8.1.1.0 0.0.0.255 R1(config)#access-list 17 deny 9.1.1.0 0.0.0.255 R1(config)#access-list 17 permit any

Remember when you thought writing an ACL was hard? Now it's second

nature to you. All we need to do is apply the command to the Serial0

interface in the OSPF config...

R1(config-router)#distribute-list 17 out serial0 % Interface not allowed with OUT for OSPF

D'oh!

Filtering routes with OSPF is just a little tricky, since we're not filtering routes per se as we would with RIP or EIGRP. We deal with LSAs in link

state protocols, and we can't start filtering LSAs or our OSPF databases

in an area won't be synced.

Let's try specifying a protocol there instead of an interface.

R1(config-router)#distribute-list 17 out rip

We didn't get an error message, so let's check the OSPF tables on R2

and R3...

R2#show ip route ospf 5.0.0.0/24 is subnetted, 1 subnets O E2 5.1.1.0 [110/20] via 172.12.123.1, 00:02:04, Serial0 6.0.0.0/24 is subnetted, 1 subnets O E2 6.1.1.0 [110/20] via 172.12.123.1, 00:02:04, Serial0 7.0.0.0/24 is subnetted, 1 subnets O E2 7.1.1.0 [110/20] via 172.12.123.1, 00:02:04, Serial0 10.0.0.0/24 is subnetted, 1 subnets O E2 10.1.1.0 [110/20] via 172.12.123.1, 00:02:04, Serial0 30.0.0.0/24 is subnetted, 1 subnets O E2 30.1.1.0 [110/20] via 172.12.123.1, 00:02:04, Serial0

R3#show ip route ospf 5.0.0.0/24 is subnetted, 1 subnets O E2 5.1.1.0 [110/20] via 172.12.123.1, 00:12:17, Serial0 6.0.0.0/24 is subnetted, 1 subnets O E2 6.1.1.0 [110/20] via 172.12.123.1, 00:12:17, Serial0 7.0.0.0/24 is subnetted, 1 subnets O E2 7.1.1.0 [110/20] via 172.12.123.1, 00:12:17, Serial0 10.0.0.0/24 is subnetted, 1 subnets O E2 10.1.1.0 [110/20] via 172.12.123.1, 00:12:17, Serial0 30.0.0.0/24 is subnetted, 1 subnets O E2 30.1.1.0 [110/20] via 172.12.123.1, 00:12:17, Serial0

Success!

If I wanted to go one step further and stop those two routes from being

put into R1's routing table, I could have put the distribute-list in the RIP process.

R1(config)#router rip R1(config-router)#distribute-list 17 ? in Filter incoming routing updates out Filter outgoing routing updates

R1(config-router)#distribute-list 17 in ? BRI ISDN Basic Rate Interface Ethernet IEEE 802.3 Loopback Loopback interface Null Null interface Serial Serial <cr>

R1(config-router)#distribute-list 17 in ethernet0

The resulting RIP table on R1:

R1#show ip route rip 5.0.0.0/24 is subnetted, 1 subnets R 5.1.1.0 [120/1] via 30.1.1.5, 00:00:00, Ethernet0 6.0.0.0/24 is subnetted, 1 subnets R 6.1.1.0 [120/1] via 30.1.1.5, 00:00:00, Ethernet0 7.0.0.0/24 is subnetted, 1 subnets R 7.1.1.0 [120/1] via 30.1.1.5, 00:00:00, Ethernet0 10.0.0.0/24 is subnetted, 1 subnets R 10.1.1.0 [120/1] via 30.1.1.5, 00:00:00, Ethernet0

Distribute-lists can also be used to filter all routes from being advertised

via a certain interface - without making that interface passive and losing the adjacency.

Let's use an EIGRP topology that we used earlier in this section, but we'll

advertise routes from R2 in this lab.

Here are those routes on R1:

R1#show ip route eigrp 2.0.0.0/24 is subnetted, 1 subnets D 2.2.2.0 [90/2297856] via 172.12.123.2, 00:00:09, Serial0 22.0.0.0/24 is subnetted, 1 subnets D 22.2.2.0 [90/2297856] via 172.12.123.2, 00:00:04, Serial0

And on R5:


What if we don't want R5 to see any of those routes - but we need to

keep the adjacency? That means we can't make E0 passive, but we can

filter all routes coming in from R1.

A one-line ACL denies all traffic explicitly:

R1(config)#access-list 25 deny any

We apply it to the EIGRP process:

R1(config)#router eigrp 100 R1(config-router)#distribute-list 25 ? in Filter incoming routing updates out Filter outgoing routing updates

R1(config-router)#distribute-list 25 out ? BRI ISDN Basic Rate Interface Ethernet IEEE 802.3 Loopback Loopback interface Null Null interface Serial Serial bgp Border Gateway Protocol (BGP) connected Connected egp Exterior Gateway Protocol (EGP) eigrp Enhanced Interior Gateway Routing Protocol (EIGRP) igrp Interior Gateway Routing Protocol (IGRP) ospf Open Shortest Path First (OSPF) rip Routing Information Protocol (RIP) static Static routes <cr>

R1(config-router)#distribute-list 25 out ethernet0

And we go to R5...


... and the routes are still there. Been there for over 11 minutes, too.

Why?

EIGRP only sends routing updates when there's a change in the network

- and a distribute-list being applied is not considered such a change.

We need to force a routing update with clear ip route *, after which we'll

check the EIGRP table on R5 immediately.

R5#clear ip route * R5# R5#show ip route eigrp

< nothing to show >

R5#

Sometimes a little route clearing is all it takes!

You can verify your distribute-list operation with debug ip eigrp...

R1#debug ip eigrp IP-EIGRP Route Events debugging is on 02:11:27: %LINK-3-UPDOWN: Interface Serial0, changed state to down 02:11:27: IP-EIGRP: 172.12.123.0/24 - denied by distribute list 02:11:27: IP-EIGRP: Int 172.12.123.0/24 metric 4294967295 - 0 4294967295 02:11:27: IP-EIGRP: 2.2.2.0/24 - denied by distribute list 02:11:27: IP-EIGRP: Int 2.2.2.0/24 metric 4294967295 - 1657856 4294967295 02:11:27: IP-EIGRP: 22.2.2.0/24 - denied by distribute list

... as well as our old buddy show ip protocols.

R1#show ip protocols Routing Protocol is "eigrp 100" Outgoing update filter list for all interfaces is not set Redistributed eigrp 100 filtered by 25 Incoming update filter list for all interfaces is not set

We can use the distribute-list command to filter EIGRP routing updates

when redistribution is involved, too. For this lab we'll use a slightly different topology.

R1 - R2 link: 172.12.123.0 / 24

R1 - R3 link: 172.13.13.0 /24

R1 - R5 link: 30.1.1.0 /24

R1 is learning two routes via RIP from R2.

R1#show ip route rip 2.0.0.0/24 is subnetted, 1 subnets R 2.2.2.0 [120/1] via 172.12.123.2, 00:00:52, Serial0 22.0.0.0/24 is subnetted, 1 subnets

R 22.2.2.0 [120/1] via 172.12.123.2, 00:00:52, Serial0

After performing redistribution of both RIP and connected routes into EIGRP 100 ...

R1(config)#router eigrp 100 R1(config-router)#default-metric 1500 10 255 1 1500 R1(config-router)#redistribute connected R1(config-router)#redistribute rip

... both R3 and R5 see the two RIP routes and the 172.12.123.0 /24

network as EIGRP external routes.

R5#show ip route eigrp 2.0.0.0/24 is subnetted, 1 subnets D EX 2.2.2.0 [170/1734656] via 30.1.1.1, 00:00:16, Ethernet0 172.12.0.0/24 is subnetted, 1 subnets D EX 172.12.123.0 [170/2195456] via 30.1.1.1, 00:00:11, Ethernet0 172.13.0.0/24 is subnetted, 1 subnets D 172.13.13.0 [90/2195456] via 30.1.1.1, 00:06:28, Ethernet0 22.0.0.0/24 is subnetted, 1 subnets D EX 22.2.2.0 [170/1734656] via 30.1.1.1, 00:00:16, Ethernet0

R3#show ip route eigrp 2.0.0.0/24 is subnetted, 1 subnets D EX 2.2.2.0 [170/2221056] via 172.13.13.1, 00:00:31, Serial1 172.12.0.0/24 is subnetted, 1 subnets D EX 172.12.123.0 [170/2681856] via 172.13.13.1, 00:00:26, Serial1 22.0.0.0/24 is subnetted, 1 subnets D EX 22.2.2.0 [170/2221056] via 172.13.13.1, 00:00:31, Serial1 30.0.0.0/24 is subnetted, 1 subnets D 30.1.1.0 [90/2195456] via 172.13.13.1, 00:06:25, Serial1

What if we didn't want R5 to see any of those routes, but for R3 to

continue to see all of them?

First, write a one-line ACL denying all traffic...

R1(config)#access-list 47 deny any

... and apply that in the EIGRP config with the distribute-list command, referencing the interface leading to R5.

R1(config)#router eigrp 100 R1(config-router)#distribute-list 47 out ethernet0

The result: R5 has none of the routes....


... and R3 still sees them all.

R3#show ip route eigrp 2.0.0.0/24 is subnetted, 1 subnets D EX 2.2.2.0 [170/2221056] via 172.13.13.1, 00:05:56, Serial1 172.12.0.0/24 is subnetted, 1 subnets D EX 172.12.123.0 [170/2681856] via 172.13.13.1, 00:05:51, Serial1 22.0.0.0/24 is subnetted, 1 subnets D EX 22.2.2.0 [170/2221056] via 172.13.13.1, 00:05:56, Serial1 30.0.0.0/24 is subnetted, 1 subnets D 30.1.1.0 [90/2195456] via 172.13.13.1, 00:11:50, Serial1

We filtered all of the routes going to R5, but kept the adjacency.

But -- and you knew that was coming -- what if we now want to filter a

route from reaching R3, but we need to use a different distribute-list?

That new requirement brings up three new questions..

Can we even use more than one distribute-list on the same router?

If so, can we use them in the same routing protocol config?

If we can, what's the net effect to all of our routing tables?

Let's find out. The new requirement is that R3 should not see the

30.1.1.0 /24 network, but continue to see the external routes. We'll write an ACL identifying the route to be denied...

R1(config)#access-list 33 deny 30.1.1.0 0.0.0.255 R1(config)#access-list 33 permit any

.... and write another distribute-list in the EIGRP config,but we will not

specify an interface or protocol.

R1(config)#router eigrp 100 R1(config-router)#distribute-list 33 ? in Filter incoming routing updates out Filter outgoing routing updates

R1(config-router)#distribute-list 33 out ? BRI ISDN Basic Rate Interface Ethernet IEEE 802.3 Null Null interface Serial Serial bgp Border Gateway Protocol (BGP) connected Connected egp Exterior Gateway Protocol (EGP) eigrp Enhanced Interior Gateway Routing Protocol (EIGRP) igrp Interior Gateway Routing Protocol (IGRP) ospf Open Shortest Path First (OSPF) rip Routing Information Protocol (RIP) static Static routes <cr>

R1(config-router)#distribute-list 33 out

The routing table on R3:

R3#show ip route eigrp 2.0.0.0/24 is subnetted, 1 subnets D EX 2.2.2.0 [170/2221056] via 172.13.13.1, 00:00:17, Serial1 172.12.0.0/24 is subnetted, 1 subnets D EX 172.12.123.0 [170/2681856] via 172.13.13.1, 00:00:17, Serial1 22.0.0.0/24 is subnetted, 1 subnets D EX 22.2.2.0 [170/2221056] via 172.13.13.1, 00:00:17, Serial1

The 30.1.1.0 /24 route has been successfully filtered -- but what about

the previous distribute-list and its effect on R5's routing table?


The previous distribute-list is still in effect, since it was specifically

written to filter route updates leaving e0. "General" distribute-lists --

lists that do not indicate a specific interface -- do not overwrite

distribute-lists that specifically mention an interface.

Let's review the current EIGRP config on R1:

router eigrp 100 redistribute connected redistribute rip network 30.1.1.0 0.0.0.255 network 172.13.13.0 0.0.0.255 default-metric 1500 10 255 1 1500 distribute-list 47 out Ethernet0 distribute-list 33 out no auto-summary no eigrp log-neighbor-changes

We have a specific distribute-list and then a general one where an interface was not specified. In this case, the specific distribute-list is

applied to the e0 interface, and the general distribute-list will be applied

to all other interfaces - - and in this lab, that includes S1 leading to R3.

Using Route Maps To Change Route Values And Attributes

Distribute-lists are a powerful tool in our route redistribution toolbox -

but sometimes we'll want to do more than simply permit or deny routes

to be advertised and redistributed.

Sometimes we'll want to set different metrics for different routes, and

maybe even change an OSPF external route type or two - and we'll do that with route maps.

Let's take a look at the mechanics of route map operation, and then we'll

apply route maps to our redistribution labs.

Route maps are somewhat similar to access-lists. They both come to a

basic decision of "permit" or "deny". Route lists give us additional power

over the data beyond just a simple "transmit" or "don't transmit". With

route maps, we can actually change route attributes.

Here's an example of how an ACL and a route-map work together - we'll use BGP in the example.

R2(config)#access-list 17 permit host 20.1.1.1

R2(config)#route-map ? WORD Route map tag

R2(config)#route-map CHANGE_NEXT_HOP ? <0-65535> Sequence to insert to/delete from existing route-map entry deny Route map denies set operations permit Route map permits set operations <cr>

R2(config)#route-map CHANGE_NEXT_HOP permit ? <0-65535> Sequence to insert to/delete from existing route-map entry <cr>

R2(config)#route-map CHANGE_NEXT_HOP permit 10 R2(config-route-map)#match ip address 17 R2(config-route-map)#set ip next-hop 10.1.1.1 R2(config-route-map)#set ? as-path Prepend string for a BGP AS-path attribute automatic-tag Automatically compute TAG value comm-list set BGP community list (for deletion) community BGP community attribute

dampening Set BGP route flap dampening parameters default Set default information extcommunity BGP extended community attribute interface Output interface ip IP specific information level Where to import route local-preference BGP local preference path attribute metric Metric value for destination routing protocol metric-type Type of metric for destination routing protocol origin BGP origin code tag Tag value for destination routing protocol weight BGP weight for routing table

First, we defined a standard ACL specifying the source IP address 20.1.1.1. (Remember, the only factor that a standard ACL can match is

the source IP address.) Then we began writing the route-map. We'll

now take a line-by-line look at how this route map was written.

R2(config)#route-map ? WORD Route map tag

A route map has to be named, and it's a good idea to give it an intuitive name. Since we're going to change the next-hop IP address of matching

traffic, we'll call the route map CHANGE_NEXT_HOP.

R2(config)#route-map CHANGE_NEXT_HOP ? <0-65535> Sequence to insert to/delete from existing route-map entry deny Route map denies set operations permit Route map permits set operations <cr>

Route map statements can be given a sequence number, and this is a

great help when you want to go back to an existing route map and add

statements. You do not have to assign a sequence number, and if you don't, the first statement you enter will be numbered "10" and each

statement after that will have a sequence number that increments by 10

from the previous statement.

The <cr> indicates that this command could be entered just as it is,

without a permit or deny statement. If you do not specify permit or deny, a route map statement will default to "permit".

We'll use the following topology to demo route maps and how they work with route redistribution.

R1 - R2 Link: 172.12.123.0 /24

R1 - R3 Link: 172.13.13.0 /24

R1 - R5 Link: 30.1.1.0 /24

R2 is advertising three networks - 2.2.2.0 /24, 22.2.0.0 /24, and

222.2.0.0 /24. R1 sees them in its RIP routing table:

R1#show ip route rip R 222.2.2.0/24 [120/1] via 172.12.123.2, 00:00:16, Serial0 2.0.0.0/24 is subnetted, 1 subnets R 2.2.2.0 [120/1] via 172.12.123.2, 00:00:16, Serial0 22.0.0.0/24 is subnetted, 1 subnets R 22.2.2.0 [120/1] via 172.12.123.2, 00:00:16, Serial0

For this lab, we have the following requirements:

2.2.2.0 -- Double the default seed metric and set the route to OSPF

external type 1.

22.2.0.0 - Keep the default seed metric, set the route to OSPF

external type 1.

222.2.2.0 -- Do not redistribute this route at all.

All future redistributed routes -- allow redistribution with the default

seed metric and OSPF route type.

That should keep us busy! And the first step, as always -- identify each

route or group of routes with an ACL.

R1(config)#access-list 2 permit 2.2.2.0 0.0.0.255 R1(config)# R1(config)#access-list 22 permit 22.2.2.0 0.0.0.255 R1(config)# R1(config)#access-list 44 permit 222.2.2.0

Now we'll start on the route map. Route maps are named, not

numbered, and I recommend you give yours an intuitive name:

R1(config)#route-map RIP2OSPF permit 10 R1(config-route-map)#match ? as-path Match BGP AS path list community Match BGP community list extcommunity Match BGP/VPN extended community list interface Match first hop interface of route ip IP specific information length Packet length

metric Match metric of route route-type Match route-type of route tag Match tag of route

R1(config-route-map)#match ip ? address Match address of route or match packet next-hop Match next-hop address of route route-source Match advertising source address of route

R1(config-route-map)#match ip address ? <1-199> IP access-list number <1300-2699> IP access-list number (expanded range) WORD IP access-list name prefix-list Match entries of prefix-lists <cr>

R1(config-route-map)#match ip address 2 ? <1-199> IP access-list number <1300-2699> IP access-list number (expanded range) WORD IP access-list name <cr>

R1(config-route-map)#match ip address 2

All IP addresses match ACL 2 will match this route-map clause. Note

that you can specify more than one ACL for a single route map clause.

What attributes can we set with a route map?

R1(config-route-map)#set ? as-path Prepend string for a BGP AS-path attribute automatic-tag Automatically compute TAG value comm-list set BGP community list (for deletion) community BGP community attribute dampening Set BGP route flap dampening parameters default Set default information extcommunity BGP extended community attribute interface Output interface ip IP specific information level Where to import route local-preference BGP local preference path attribute metric Metric value for destination routing protocol metric-type Type of metric for destination routing protocol origin BGP origin code tag Tag value for destination routing protocol weight BGP weight for routing table

Plenty of them. Quite a few are BGP-specific, but here we'll set both the

metric and metric type for this route being redistributed into OSPF.

R1(config-route-map)#set metric ? +/-<metric> Add or subtract metric <0-4294967295> Metric value or Bandwidth in Kbits per second <cr>

R1(config-route-map)#set metric 40 R1(config-route-map)#set metric-type ? external IS-IS external metric internal Use IGP metric as the MED for BGP type-1 OSPF external type 1 metric type-2 OSPF external type 2 metric <cr>

R1(config-route-map)#set metric-type type-1

Note that we can set more than one attribute. Here we're doubling the

OSPF seed metric of 20 and setting the route type to OSPF E1 from the default of E2.

The next clause will match ACL 22 and will leave the seed metric at the default, but will change the OSPF route type to E1.

R1(config)#route-map RIP2OSPF permit 20 R1(config-route-map)#match ip add 22 R1(config-route-map)#set metric-type type-1

The third clause will match ACL 44 and will deny the route from being

redistributed. Note the deny in the route-map clause and that no

attribute is actually set - since we're denying it in the first place.

R1(config)#route-map RIP2OSPF deny 30 R1(config-route-map)#match ip address 44

That matches all of our three current routes, but we were also asked to

allow future routes to be redistributed with the default seed metric and

OSPF route type.

For that, we'll write what I call a "catch-all" clause - a clause that

matches any route that wasn't specifically matched earlier. This clause

has no match rule, and since we're not changing any attributes, it won't have any set rules either.

R1(config)#route-map RIP2OSPF perm 40 R1(config-route-map)#

As you've now seen, these can get pretty involved!

Let's take a look at the route-map as a whole with show route-map.

R1#show route-map route-map RIP2OSPF, permit, sequence 10 Match clauses: ip address (access-lists): 2 Set clauses: metric 40 metric-type type-1 Policy routing matches: 0 packets, 0 bytes route-map RIP2OSPF, permit, sequence 20 Match clauses: ip address (access-lists): 22 Set clauses: metric-type type-1 Policy routing matches: 0 packets, 0 bytes route-map RIP2OSPF, deny, sequence 30 Match clauses: ip address (access-lists): 44 Set clauses: Policy routing matches: 0 packets, 0 bytes route-map RIP2OSPF, permit, sequence 40 Match clauses: Set clauses: Policy routing matches: 0 packets, 0 bytes

Now after all that, we get to apply it!

Let's see the results of the redistribution without the route-map.

R1(config)#router ospf 1 R1(config-router)#redis rip subnets

R3#show ip route ospf O E2 222.2.2.0/24 [110/20] via 172.13.13.1, 00:00:03, Serial1 2.0.0.0/24 is subnetted, 1 subnets O E2 2.2.2.0 [110/20] via 172.13.13.1, 00:00:03, Serial1 172.12.0.0/24 is subnetted, 1 subnets O E2 172.12.123.0 [110/20] via 172.13.13.1, 00:00:03, Serial1 22.0.0.0/24 is subnetted, 1 subnets O E2 22.2.2.0 [110/20] via 172.13.13.1, 00:00:03, Serial1 30.0.0.0/24 is subnetted, 1 subnets O 30.1.1.0 [110/74] via 172.13.13.1, 00:00:03, Serial1 R5#show ip route ospf O E2 222.2.2.0/24 [110/20] via 30.1.1.1, 00:00:15, Ethernet0 2.0.0.0/24 is subnetted, 1 subnets O E2 2.2.2.0 [110/20] via 30.1.1.1, 00:00:15, Ethernet0 172.12.0.0/24 is subnetted, 1 subnets O E2 172.12.123.0 [110/20] via 30.1.1.1, 00:00:15, Ethernet0 172.13.0.0/24 is subnetted, 1 subnets O 172.13.13.0 [110/74] via 30.1.1.1, 00:00:15, Ethernet0 22.0.0.0/24 is subnetted, 1 subnets O E2 22.2.2.0 [110/20] via 30.1.1.1, 00:00:15, Ethernet0

Just what we expected. Now let's remove that redis statement and

replace it with one that calls the route-map. We'll put a "regular"

redistribute connected in there, too.

R1(config)#router ospf 1 R1(config-router)#redis rip subnets route-map RIP2OSPF R1(config-router)#redis conne subnets

The result on R3:

R3#show ip route ospf 2.0.0.0/24 is subnetted, 1 subnets O E1 2.2.2.0 [110/104] via 172.13.13.1, 00:01:56, Serial1 172.12.0.0/24 is subnetted, 1 subnets O E2 172.12.123.0 [110/20] via 172.13.13.1, 00:01:56, Serial1 22.0.0.0/24 is subnetted, 1 subnets O E1 22.2.2.0 [110/84] via 172.13.13.1, 00:01:56, Serial1 30.0.0.0/24 is subnetted, 1 subnets O 30.1.1.0 [110/74] via 172.13.13.1, 00:01:56, Serial1

Let's review the route-map on R1 and check the impact on R3:

R1#show route-map route-map RIP2OSPF, permit, sequence 10 Match clauses: ip address (access-lists): 2 Set clauses: metric 40 metric-type type-1 Policy routing matches: 0 packets, 0 bytes route-map RIP2OSPF, permit, sequence 20 Match clauses: ip address (access-lists): 22 Set clauses: metric-type type-1 Policy routing matches: 0 packets, 0 bytes route-map RIP2OSPF, deny, sequence 30 Match clauses: ip address (access-lists): 44 Set clauses: Policy routing matches: 0 packets, 0 bytes route-map RIP2OSPF, permit, sequence 40 Match clauses: Set clauses: Policy routing matches: 0 packets, 0 bytes

Clause 10: 2.2.2.0 had its seed metric doubled and is marked as an

E1 route. Since E1 routes reflect the entire path to the destination, the cost is not the doubled seed metric of 40, but 104.

Clause 20: 22.2.2.0 did not have its seed metric doubled and is marked as an E1 route - so again the cost is higher than the default

seed of 20.

Clause 30: 222.2.2.0 does not appear in the routing table at all,

having been successfully filtered from redistribution.

172.12.123.0 was redistributed via the redistribute connected command,

which did not have a route-map applied, and so we see the usual defaults

there - the route is an E2 route and has the default seed metric of 20.

Great stuff! Route maps are a very powerful tool in controlling

redistribution and changing attributes when needed - they're not just for BGP configs.

Hey, there's one more thing we need to test - remember the last

requirement?

All future redistributed routes -- allow redistribution with the default

seed metric and OSPF route type.

Let's add a RIP route to the network on R2 and see if it's redistributed

into OSPF at R1 with the defaults.

The route is created and added to RIP...

R2(config)#int loopback 55 R2(config-if)#ip address 55.5.5.5 255.255.255.0 R2(config-if)#router rip R2(config-router)#network 55.0.0.0

.... the route is seen in R1's RIP routing table...

R1#show ip route rip R 222.2.2.0/24 [120/1] via 172.12.123.2, 00:00:02, Serial0 2.0.0.0/24 is subnetted, 1 subnets R 2.2.2.0 [120/1] via 172.12.123.2, 00:00:02, Serial0 55.0.0.0/24 is subnetted, 1 subnets R 55.5.5.0 [120/1] via 172.12.123.2, 00:00:02, Serial0 22.0.0.0/24 is subnetted, 1 subnets R 22.2.2.0 [120/1] via 172.12.123.2, 00:00:02, Serial0

... and it's seen at R3 with the default seed metrics, having matched clause 40 of the route-map.

R3#show ip route ospf 2.0.0.0/24 is subnetted, 1 subnets O E1 2.2.2.0 [110/104] via 172.13.13.1, 00:08:56, Serial1 55.0.0.0/24 is subnetted, 1 subnets O E2 55.5.5.0 [110/20] via 172.13.13.1, 00:00:24, Serial1 172.12.0.0/24 is subnetted, 1 subnets O E2 172.12.123.0 [110/20] via 172.13.13.1, 00:08:56, Serial1 22.0.0.0/24 is subnetted, 1 subnets O E1 22.2.2.0 [110/84] via 172.13.13.1, 00:08:56, Serial1 30.0.0.0/24 is subnetted, 1 subnets O 30.1.1.0 [110/74] via 172.13.13.1, 00:08:56, Serial1

Bingo, baby!

Clause 20 of the route-map had two set statements - you can also have

multiple match statements in a clause. If so, both match statements must match in order for that clause to be, well, a match.

I've added a clause 50 to this route-map. For this clause to match, the

route would have to match ACL 5 *and* be an OSPF E2 route to have its

metric set to the specified value.

R1(config)#route-map RIP2OSPF permit 50 R1(config-route-map)#match ip address 5 R1(config-route-map)#match route-type ? external external route (BGP, EIGRP and OSPF type 1/2) internal internal route (including OSPF intra/inter area) level-1 IS-IS level-1 route level-2 IS-IS level-2 route local locally generated route nssa-external nssa-external route (OSPF type 1/2) <cr>

R1(config-route-map)#match route-type external ? external external route (BGP, EIGRP and OSPF type 1/2) internal internal route (including OSPF intra/inter area) level-1 IS-IS level-1 route level-2 IS-IS level-2 route local locally generated route nssa-external nssa-external route (OSPF type 1/2) type-1 OSPF external type 1 route type-2 OSPF external type 2 route <cr>

R1(config-route-map)#match route-type external type-2 R1(config-route-map)#set metric 100

There's just one more set value I want to introduce you to...

tag Tag value for destination routing protocol

This innocent little value can help you prevent some big nasty routing loops, especially with 2-way redistribution. You can tag routes with a

numeric value as they're redistributed, and then prohibit routes with that

same value from being "re-redistributed" back into the original routing protocol.

Let's use the previous lab topology for a demo.

Let's say we're configuring 2-way redistribution here, and we want to

make absolutely sure that routes redistributed into OSPF cannot be "re-

redistributed" back to the RIP domain, and vice versa -- and that includes the possibility of additional border routers being added to our

network in the future.

We can tag the routes redistributed into OSPF with a value of 10, and

deny routes with that same value from being redistributed back into RIP.

I've removed the previous lab's configuration and we'll start by checking

for RIP routes on R1.


We want to redistribute them into OSPF and tag them with a value of

10. If that's all we need to do, we don't need an ACL or any match statements - just this route-map:

R1(config)#route-map RIP2OSPF permit 10 R1(config-route-map)#set tag 10

The redistribution config:

R1(config)#router ospf 1 R1(config-router)#redistribute rip route-map RIP2OSPF subnets R1(config-router)#redistribute connected % Only classful networks will be redistributed R1(config-router)#redistribute connected subnets

Don't forget the subnets option. :) Also note that in the RIP redis

statement, you can put subnets at the end of the command or

immediately after redistribute rip -- it doesn't matter, just make sure

you put it somewhere.

The OSPF table on R3:

R3#show ip route ospf 2.0.0.0/24 is subnetted, 1 subnets O E2 2.2.2.0 [110/20] via 172.13.13.1, 00:00:24, Serial1 172.12.0.0/24 is subnetted, 1 subnets O E2 172.12.123.0 [110/20] via 172.13.13.1, 00:00:06, Serial1 22.0.0.0/24 is subnetted, 1 subnets O E2 22.2.2.0 [110/20] via 172.13.13.1, 00:00:25, Serial1 30.0.0.0/24 is subnetted, 1 subnets O 30.1.1.0 [110/74] via 172.13.13.1, 00:00:25, Serial1

Three routes are learned via redistribution. You won't see tag values in

the routing table, but you will see them in the extended show ip route

command. Let's run that command for one of the external routes and for the internal 30.1.1.0 network.

R3#show ip route 2.2.2.0 Routing entry for 2.2.2.0/24 Known via "ospf 1", distance 110, metric 20 Tag 10, type extern 2, forward metric 64 Last update from 172.13.13.1 on Serial1, 00:00:43 ago Routing Descriptor Blocks: * 172.13.13.1, from 172.13.13.1, 00:00:43 ago, via Serial1

Route metric is 20, traffic share count is 1

R3#show ip route 30.1.1.0 Routing entry for 30.1.1.0/24 Known via "ospf 1", distance 110, metric 74, type intra area Last update from 172.13.13.1 on Serial1, 00:00:52 ago Routing Descriptor Blocks: * 172.13.13.1, from 172.13.13.1, 00:00:52 ago, via Serial1 Route metric is 74, traffic share count is 1

The external route has a tag of 10, and that tag is present with that

route everywhere that route is seen throughout the network.

The internal route has no tag since it wasn't learned via redistribution,

and therefore wasn't subject to tagging by the route map.

The following config will prevent any routes with the tag 10 from being

redistributed from OSPF back into RIP, while allowing any untagged

routes to be redistributed and tagged with 20.

R1(config)#route-map OSPF2RIP deny 10 R1(config-route-map)#match tag 10 R1(config-route-map)#route-map OSPF2RIP perm 20 R1(config-route-map)#set tag 20

Now what if we want to go back to the RIP2OSPF route map and use that tag to prevent routes with that tag of 20 from being advertised back to

OSPF? Here's what that route-map looks like now:

R1#show route-map RIP2OSPF route-map RIP2OSPF, permit, sequence 10 Match clauses: Set clauses: tag 10

We need the new clause to have a sequence number of less than 10,

since we need the deny clause in front of this clause, which allows all

routes and tags them with 10. Here's how we make that happen, along

with verification.

R1(config)#route-map RIP2OSPF deny 5 R1(config-route-map)#match tag 20 R1#show route-map RIP2OSPF route-map RIP2OSPF, deny, sequence 5 Match clauses: tag 20 Set clauses: Policy routing matches: 0 packets, 0 bytes route-map RIP2OSPF, permit, sequence 10 Match clauses: Set clauses: tag 10 Policy routing matches: 0 packets, 0 bytes

The joy of sequence numbers!

If we had the permit clause run first, everything would be permitted and

tagged with 10 -- even the routes we're trying to deny.

By putting the deny statement first, we deny the routes that are tagged 20 and then allow all other routes to be redistributed. That's why I put a

"5" in the first line of this new config - that's the sequence number.

Policy Routing

Policy-based routing, generally referred to as "policy routing", is the use

of route maps to determine the path a packet will take to get to its final destination. As you progress through your CCNP studies and go on to

the CCIE (or to a Cisco Quality Of Service certification), you'll find that

traffic can be "marked" by policy routing in order to give different levels of service to various classes of traffic.

This is done by marking the traffic and placing the different classes of traffic in different queues in the router, allowing the administrator to give

some traffic higher priority for transmission.

Some basic policy routing rules:

Policy routing doesn't affect the destination of the packet, but does

affect the path that is taken to get there.

Policy routing can forward traffic based on the source IP address or

the destination IP address (with the use of an extended ACL).

Policy routing can be configured globally or on a per-interface level.

Applying policy routing on an interface affects only packets arriving on

that interface - in this case, Serial0.

R2(config)#int s0 R2(config-if)#ip policy route-map CHANGE_NEXT_HOP

Applying the policy globally applies the route map to packets generated

on the router, not on all packets received on all interfaces.

R2(config)#ip local policy route-map CHANGE_NEXT_HOP

Verify either - or both! - with show ip policy.

R2#show ip policy Interface Route map local CHANGE_NEXT_HOP Serial0 CHANGE_NEXT_HOP

And here's the big rule to remember....

If a packet doesn't match any of the specific criteria in a route map, or does match a line that has an explicit deny statement, the data is

sent to the routing process and will be processed normally.

If you don't want to route packets that don't match a route-map

clause, the set command must be used to send those packets to the null0

interface. Naturally, this set command should be the final set command in the route map.

There are four possibilities for an incoming packet when route maps are in use. The following example illustrates all of them.

R2(config)#access-list 29 permit host 20.1.1.1 R2(config)#access-list 30 permit host 20.2.2.2 R2(config)#access-list 31 permit host 20.3.3.3

R2(config)#access-list 32 permit host 20.4.4.4

R2(config)#route-map EXAMPLE permit 10 R2(config-route-map)#match ip address 29 R2(config-route-map)#set ip next-hop 40.1.1.1 R2(config-route-map)#route-map EXAMPLE deny 20 R2(config-route-map)#match ip address 30

Assuming the route map has been applied to the router's ethernet0

interface, a packet sourced from 20.1.1.1 would match the first line of

the route map and have its next-hop IP address set to 40.1.1.1.

A packet sourced from 20.2.2.2 would match the deny statement

(sequence number 20). Since there is no action listed, this packet would return to the routing engine to undergo the normal routing procedure.

All traffic that did not match these two addresses would also be routed

normally - there would be no action taken by the route map.

Perhaps we want to specifically block traffic sourced from 20.3.3.3 or

20.4.4.4. We can use multiple match statements in one single route map, and have packets matching those two addresses sent to the bit

bucket - the interface null0.

R2(config)#route-map EXAMPLE permit 30 R2(config-route-map)#match ip address 31 R2(config-route-map)#match ip address 32 R2(config-route-map)#set ? as-path Prepend string for a BGP AS-path attribute automatic-tag Automatically compute TAG value comm-list set BGP community list (for deletion) community BGP community attribute dampening Set BGP route flap dampening parameters default Set default information extcommunity BGP extended community attribute interface Output interface ip IP specific information level Where to import route local-preference BGP local preference path attribute metric Metric value for destination routing protocol metric-type Type of metric for destination routing protocol origin BGP origin code tag Tag value for destination routing protocol weight BGP weight for routing table

R2(config-route-map)#set interface null0

Any traffic matching ACLs 31 or 32 will be sent to null0, resulting in its being discarded by the router. Any traffic that didn't match any of the

route map statements will be returned to the routing engine for normal

processing.

You can verify your policy-map effectiveness and monitor the number of

matches with show access-list.

Whew! We use a lot of route maps in our CCNP ROUTE studies, and you'll use them often in production networks as well - they're not just for

BGP.

Speaking of that, since we've used these maps in different sections of

the course, here's a summary of the various uses:

Packet destination set values:

Next-hop IP address, including a default next-hop

Interfaces that can route packets, including a default interface

IP PREC values (IP Precedence), Don't Fragment bit value, and IP Type of Service (ToS)

Routing protocol set values:

metric

metric type

tag values

BGP set values:

AS-Path

Community

Local Preference

Weight

Bonus Material - Not Covered On DVD, But Good Reading Anyway!

"ip default next-hop" vs. "ip next-hop"

These are two values that can be set with a route map that are very

similar, and I want to point out to you that while many CCNP candidates think they're the same thing, they are not.

If you set an "ip default next-hop" with a route map, that next-hop will

be used ONLY if an explicit path to the destination network is not present

in the routing table. An extended ACL must be used here, since a source

and destination must be defined.

R2(config)#access-list 150 permit ip host 172.1.1.1 210.1.1.0 0.0.0.255

R2(config)#route-map DEFAULT_NEXT_HOP permit R2(config-route-map)#match ip address 150 R2(config-route-map)#set ip default next-hop 100.1.1.3

R2(config)#interface e0

R2(config-if)#ip policy route-map DEFAULT_NEXT_HOP

When a packet comes into ethernet0 with a source IP of 172.1.1.1 and is

destined for any host on the 210.1.1.0/24 network, the next-hop

address will be set to 100.1.1.3 IF there is no entry in the routing table for that network.

The Null0 Interface And BGP Redistribution

Null interfaces are seen in the routing table after manual route summarization has been configured, but you can also create a static

route with Null0 as the "exit interface".

Configuring Null0 as the exit interface means that matching data will be

dropped. You configure such a route just as you would any other static

route with a specific exit interface.

R2(config)#ip route 172.12.1.0 255.255.255.0 null0

You may be wondering why we'd do that in the first place. The main purpose of a static route to null0 is to allow BGP - IGP route

redistribution. BGP route redistribution is a complex subject that you'll

master during your CCIE studies, but here are a couple of basics for you.

Instead of redistributing specific routes from an IGP into BGP, you can

create this null0 statement and then just redistribute this static route into BGP. Basically, what you're doing is aggregating the routes before

injecting them into BGP.

The null0 statement will not impact your IGP routing, since the more-

specific statements in the IGP table will be used before this null0 route

due to the longest match rule.

Let's work through an example. You have the IGP routes 150.100.1.0, 150.100.2.0, and 150.100.3.0, all with a /24 mask. You have a need to

redistribute these routes into BGP. Instead of redistributing the three

individual routes into BGP, you summarize them. The result is

150.100.0.0 /22. You create a route for that network and mask that leads to the null0 interface like this....

R2(config)#ip route 150.100.0.0 255.255.252.0 null0

... and then redistribute that route into BGP. The presence of this null

router in your IGP table will not matter, since traffic destined for the

150.100.1.0, 2.0, and 3.0 networks will have a longer match in the table.

There's one more use for such a null route, and that's to trick BGP into

thinking that there is an IGP route for this destination in the first place.

If you faced a situation where you needed to redistribute a network into

BGP from your IGP table, and that network didn't actually exist in your IGP table, you could create a route to null0 with the ip route command

and then redistribute it into BGP.

Potential Issues Regarding BGP Redistribution

We just covered one major issue regarding BGP redistribution, and discussed how to solve that with a static route to null0. There's another

major factor we have to consider, though, and that is the sheer size of

BGP routing tables.

A full BGP table can hold well over 100,000 routes. You read that right -

over 100,000 routes. You should carefully consider this fact before

attempting any redistribution involving BGP. A lot of damage can be done very quickly to your network and worldwide internet connectivity as

a whole if BGP redistribution is performed incorrectly.

There's another problem with redistributing routes from an IGP into

BGP. If the IGP routes were dynamically learned, they may actually

have been learned from BGP in the first place. Putting them back into

BGP can quickly lead to a routing loop. "routing instability" doesn't begin to describe what can happen here.

Here, R1 is redistributing a BGP-learned route into OSPF. That's fine

until R4 advertises it back to R5 because route redistribution has been

incorrectly configured. Placing a filter at R4 to prevent it from possibly advertising that route and prefix to R5 can prevent a routing loop

possibility.

You also have to be careful when redistributing BGP aggregate routes. If

one of the more-specific routes being aggregated goes down, the data is

said to have entered a black hole -- that is, the router's going to discard the data.

By the way, black holes aren't always a bad thing - they're actually an

effective network security technique when properly applied. (Note the

emphasis on properly applied!) That's beyond the scope of the CCNP

ROUTE exam, but if you enter "routing black hole" into your favorite

search engine, you'll quickly find a few documents on using black holes for network security purposes.

Whether BGP is involved or not, you've got to be very careful when configuring route redistribution in a network with multiple paths between

the routing domains.

You can use default routes and static routes to avoid two-way

redistribution. If you just can't avoid two-way, make sure to use your

skills to change administrative distances, default metrics, or some kind of route filtering to prevent loops from occurring. Route filtering

becomes very important when working with two-way redistribution.

Redistributing External OSPF Routes Into BGP

Since I've warned you about 2000 times not to redistribute anything to

and from BGP unless absolutely necessary, I won't make it 2001. But

should you have to redistribute external OSPF routes, there are some options you need to know about.

IOS Help reveals quite a few options for OSPF > BGP redistribution:

R1(config)#router bgp 100 R1(config-router)#redistribute ospf 1 ? match Redistribution of OSPF routes metric Metric for redistributed routes route-map Route map reference vrf VPN Routing/Forwarding Instance <cr>

R1(config-router)#redistribute ospf 1 match ? external Redistribute OSPF external routes internal Redistribute OSPF internal routes nssa-external Redistribute OSPF NSSA external routes

R1(config-router)#redistribute ospf 1 match external ? 1 Redistribute external type 1 routes 2 Redistribute external type 2 routes external Redistribute OSPF external routes internal Redistribute OSPF internal routes match Redistribution of OSPF routes metric Metric for redistributed routes nssa-external Redistribute OSPF NSSA external routes route-map Route map reference <cr>

R1(config-router)#redistribute ospf 1 match external 1 ? external Redistribute OSPF external routes internal Redistribute OSPF internal routes match Redistribution of OSPF routes metric Metric for redistributed routes nssa-external Redistribute OSPF NSSA external routes route-map Route map reference <cr>

R1(config-router)#redistribute ospf 1 match external 1 external 2

OSPF has two external route types, E1 and E2, E2 being the default. If

external OSPF routes must be redistributed into BGP, the full command

to put both E1 and E2 routes into BGP is shown above.

Changing A Protocol's Default Metric (Review)

Here's a quick review on using the default-metric command with RIP, EIGRP, and OSPF.

RIP's metric is simple - hop count - and so is the command.

R2(config)#router rip R2(config-router)#default-metric 2

EIGRP requires five values to be set:

R2(config)#router eigrp 100 R2(config-router)#default-metric ? <1-4294967295> Bandwidth in Kbits per second

R2(config-router)#default-metric 1544 ? <0-4294967295> Delay metric, in 10 microsecond units

R2(config-router)#default-metric 1544 10 ? <0-255> Reliability metric where 255 is 100% reliable

R2(config-router)#default-metric 1544 10 255 ? <1-255> Effective bandwidth metric (Loading) where 255 is 100% loaded

R2(config-router)#default-metric 1544 10 255 1 ? <1-4294967295> Maximum Transmission Unit metric of the path

R2(config-router)#default-metric 1544 10 255 1 1500

OSPF has a default seed metric already set (and you know what that is

by now!), and it can be changed as follows:

R2(config)#router ospf 1 R2(config-router)#default-metric ? <1-16777214> OSPF default metric

R2(config-router)#default-metric 25

Copyright ©2011 The Bryant Advantage. All Rights Reserved.

10 redistribution

Documents

route summarization

igrp routes

lan routes

lists route maps

ccnp route exam

autoredistribution scenario

ospf routes

lan protocol