GroupStudy.com GroupStudy.com - A virtual community of network engineers
Home BookStore StudyNotes Links Archives StudyRooms HelpWanted Discounts Login
RE: Another redistribution/connected question posted 05/26/2001
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]
Comments interspersed.

At 12:13 PM 5/26/2001 -0700, Daniel C. Young wrote:

Jim,

There has been a lot of discussion on this topic matter. Check the archives
month by month with the key word "ospf redistribution", and I'm sure that
you will find something. But I will give a humble attempt to summarize what

Oh, doing that search generates quite a bit, yes. I'm not sure I could wade through it all in a week, though. :)

I personally have learned.

Connected networks
OSPF will not redistribute connected networks when there is no matching
network command under the router configuration. The key is to check the
masks that you apply on the network statement. OSPF will check which
interfaces (connected networks) will be included by the network statements.
If it falls outside the mask, the you will have to perform a "redistribute
connected" to have OSPF generate a proper LSA for it (type-5 for a non-area
0 router and type-3 for area 0). It has nothing to do with route-maps unless
the route-maps somehow filter the routes. IGRP and RIP are classful distance
vector protocols, so they will only accept routes that have classful masks
(/8, /16, and /24). Also if you have subnets included, like 172.16.1.0/24,
then don't forget to use the parameter "subnet".

Let me make sure I read you, and that we're talking about the same thing. I'm interested in redistribution from one network protocol (IGRP or RIP, for example) into OSPF -- not the other way around. Are you telling me that the OSPF redistribution process won't inject a connected route from another routing protocol unless there's a network command under the OSPF process for that network?

That doesn't make sense to me. First of all, if the network is configured directly under the OSPF process as part of an OSPF area; there's no need to redistribute it. Second, it doesn't mesh with what I've seen (mostly on 12.0(11) or 12.0(15) lately). Most of the time, I get connected networks in the IGRP domain redistributing into OSPF without a problem. Sometimes, though, they don't and I end up redistributing connected to make up for it.

I think you might be thinking of OSPF->IGRP/RIP redistribution instead (the classic VLSM/FLSM problem, which I'm finally quite comfortable with). At least, that's what I suspect, since you talk about classful masks and what kind of networks IGRP/RIP will accept.

For the purposes of this question, I don't care a whit what RIP or IGRP will accept from OSPF. What boggles me at the moment is why sometimes I'm seeing connected routes being redistributed into OSPF as part of an IGRP process, and sometimes I'm not.

Of course, every time I've done this since posting this message, the IGRP routes have successfully redistributed into OSPF without having to explicitly redistribute them as connected.

Stub network -> split horizon?
No, split horizon is a distance vector protocol feature used to prevent
routing loops. OSPF uses cost to calculate SPF, builds a complete topology,
then inserts only loop-free routes into the IP routing table. I would
suggest that you develop an understanding of when route-maps or
distribute-lists are truly needed. I have a feeling that if you just apply
them blindly and fail to justify your reason when asked by a proctor, you
may lose points on the exam. Start out without any filters, then observe
each route on the table and FOLLOW ITS PATH -- as if they were static
routes. You will develop a very good understanding of routing protocol
behavior when you do this.

Again, I suspect we're thinking about different directions. I'm familiar with the OSPF process, and the difference between distance vector and link-state routing protocols.

Rereading my message, I wasn't clear that the "stub networks" I'm talking about aren't OSPF Stub Areas. Bad choice of words. I'm talking about things like the network example I gave, and what we typically see in practice labs. There's a big OSPF multi-area domain, and then there's an IGRP spur that connects to the OSPF domain at exactly one place. Usually, that IGRP spur is another spoke in a hub-spoke frame relay cloud.

If you do mutual redistribution between OSPF and IGRP in that scenerio, you're going to have problems unless you change something. Split-horizon is turned off on frame interfaces by default, so the frame-connected IGRP router will advertise everything it hears back to the source. If we're doing mutual OSPF to IGRP redistribution without either split-horizon or route maps, that means the OSPF router will redistribute everything it knows into IGRP, send it to the IGRP router (allowing for VLSM/FLSM issues that I'm ignoring entirely because they're not relevant here), and get them back from the IGRP router. This, in routing, is what we call Bad. IGRP has a lower administrative distance than OSPF, so the OSPF/IGRP router puts the IGRP routes into the routing table instead of the OSPF routes. For a little while, both routers will point at each other for these routes, then they'll be marked as possibly down, then withdrawn, and the cycle will start again.

So far as I've seen, there's two ways to prevent this route feedback problem:

1) Use route-maps. If you accept only networks you know are valid from the IGRP domain (usually the easiest in all practice labs I've seen, since they all have big OSPF domains and only two or three networks in the IGRP domain), then there's no chance that the OSPF networks (which now look like IGRP networks) will be injected into the routing table.
2) Turn on split-horizon on the IGRP router. That should also prevent the OSPF routes from being advertized back as IGRP.

The whole question is only valid when the IGRP/RIP network is a spur off of OSPF. If there's more than one connection from IGRP to OSPF, then split horizon obviously won't help.

So the question is: when we have a spur network situation like this, is it sufficient to depend on split-horizon on the IGRP router to prevent route feedback to the OSPF/IGRP router? Or is there some other source of route feedback that can happen? Is there anything "intra-router" that can happen (such as the OSPF/IGRP redistributing routes from OSPF to IGRP and back to OSPF all on the same router)? I haven't seen anything like that lately, but it doesn't mean it can't happen.

Redistribution resources
http://www.cisco.com/pcgi-bin/Support/PSP/index.pl?i=Technologies
Go to the section on OSPF or RIP, and you will certainly find excellent
whitepapers covering issues with redistribution. As far as "the guts of
redistribution", you are right in that it depends on the routing protocol.
But if you remember this simple concept, it's not that bad: Redistributed
routes or networks behave as though it was natively originated by the
redistributing router. That is, OSPF will insert type-3 or type-5 LSAs
depending on whether the redistributing router was in area 0. RIP/IGRP will,
assuming that they have classful masks, simply broadcast the routing table
entry to their non-passive interfaces.

Good luck on your exam. If my notes help you in any way, please give me
feedback after the exam. I am due in August 12-13.

Regards,

Daniel C. Young
Sr. Network Engineer
CCNP (ATM, Security & Voice Specialist),
CCDP, CCSE, MCSE+I

SBC Internet Data Center
(949) 221-1928 Work
(714) 350-8945 Cell
young@xxxxxxxxx

-----Original Message-----
From: nobody@xxxxxxxxxxxxxx [mailto:nobody@xxxxxxxxxxxxxx]On Behalf Of Jim
Graves
Sent: Friday, May 25, 2001 7:42 AM
To: ccielab@xxxxxxxxxxxxxx
Subject: Another redistribution/connected question


I've been playing with redistribution some more, and I've run into some
behavior I can't quite explain.  I've noticed that sometimes when
redistributing, a connected network won't make it in with the rest of the
routing protocol's domain; sometimes it does.

For example: Suppose we have:

(OSPF
[10.1.0.0/24]---R1---[10.1.2.0/24])--R2---([10.2.3.0/24]---R3---[10.3.0.0/24
]
IGRP)

R2 does redistribution between OSPF and IGRP.

Sometimes when I've done this, the connected network (10.2.3.0 in this
example) goes into the ospf domain without anything else needing to be
done.  Sometimes, though, I need to redistribute it into the OSPF domain
explicitly.  I haven't been able to play with this quite enough to know
what makes the difference.  Does anyone know?  Is it related to which
protocol is used (IGRP vs. RIP, say)?  Does it have to do with whether
redistribution is controlled with route-maps?  I plan to test these two
theories if I have time.

Another question: in scenerios like I describe above where the routing
domains look like stubs off of each other (i.e., there's only one
redistribution point between two protocols; it looks like a tree), is
split-horizon enough to prevent route feedback?  I used to put in
route-maps to control redistribution as a matter of habit, but now I'm
concerned about having them counted as "extra" commands (although I can
also give a pretty good "belt and suspenders" speech if needed).  More
recently, I've just used split-horizon to prevent route feedback.  That
seems to be working, but I might also be missing something.

Finally, does anyone have a good, really in-depth resource on
redistribution?  I've read Doyle v1, but I'm looking for something that
goes into the guts of how redistribution works.   For starters, I'm still
not clear on exactly where the redistributed routes come from.  Are they
routes that are in the routing table?   Are they routes that are in the
database?  Or does it depend on the routing protocol -- OSPF takes the
routes straight from the database, while IGRP or RIP have no database, so
they have to take routes straight from the routing table (which would also
explain my confusion about connected routes)?

Lots of questions, I know.  I have less than a week before my test, and I'm
dissecting redistribution.  :)

Thanks all,

Jim
**Please read:http://www.groupstudy.com/list/posting.html

**Please read:http://www.groupstudy.com/list/posting.html
_______________________________________________________
To unsubscribe from the CCIELAB list, send a message to
majordomo@xxxxxxxxxxxxxx with the body containing:
unsubscribe ccielab