From: Jim Graves (jtg@xxxxxxxxxx)
Date: Sat May 26 2001 - 16:52:24 GMT-3
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@pobox.com
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of Jim
>Graves
>Sent: Friday, May 25, 2001 7:42 AM
>To: ccielab@groupstudy.com
>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
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:30:54 GMT-3