From: David Buechner (dbuechn@attglobal.net)
Date: Tue Jun 22 2004 - 01:22:23 GMT-3
Nick,
Your problem is not that R4 doesn't have a route R2 (for example), but
rather it is that R2 does not have full reachability *back* to R4.
The debug at the bottom of your web page shows that R4 is correctly sending
the packet out it's ethernet interface. If you do a similar 'debug ip
packet' on R2 you'll likely find that R2 receives the ping and gives you a
message that 21.1.1.4 is unroutable when it tries to send back the reply.
What's happening is that the 21.1.1.0/24 network between R1 and R4 is not
being redistributed into your OSPF domain. There has been a lot of
discussion of this on the list (searching for ISIS and CONNECTED may get
you most of it).
The best explanation I've heard of this is from Brian McGahan and I share
it with apologies to him for plagiarizing: while ISIS can be used to carry
IP routing information it is not, technically, an IP protocol. Therefore
OSPF redistribution finds ISIS derived routes in the routing table on R1 to
redistribute, but does *NOT* find any connected interfaces "running ISIS"
as an IP protocol. Therefore, the connected interfaces on which ISIS is
running are not automatically redistributed. Any mistakes in this
paragraph are undoubtedly mine, not Brian's, BTW!!!
The solution is straight-forward - redistribute CONNECTED routes into OSPF
on R1. You'll likely want to use a route-map so that you only get the
interface you're interested in.
This does point out something that used to trip me up - when you can't ping
you *HAVE* to look at both the outbound path *AND* the return path. It's
easy to get stuck on the fact that R4 knows how to get everywhere and lose
sight of the fact that your ping destination can't get *BACK* to you.
You may look at the routing tables on R2 and other routers and see the
route for R4's loopback and think I'm nuts - but remember, the ping you're
generating, unless you tell it differently, is being sourced on the
outgoing interface. In this case that means that the ping is coming from
21.1.1.4.
Make sense?
David
At 10:49 AM 6/21/2004, Nick Tucker wrote:
>> > > > I've been doodling with ISIS some. Topology is this:
>> > > >
>> > > > / ---R2
>> > > > R4----Ethernet-----R1------Frame --|
>> > > > \---R3-----Ethernet----R5-----Ethernet-----R6
>> > > >
>
>Appreciate all the responses so far, hopefully I answer all the ?'s asked
>so far in this email.
>I have admended the above topology to what I replicated last nite.
>
>I tried it by hardcoding the is-levels to 2 only, to level1-2, same
>results Interestingly enough, when I changed
>R4/R1 to level1 only - I lost all communication between r4/r1 ,but thats
>another horse to beat another day.
>
>I have all of my lab configs up at http://tofguild.org/cisco/isislab.txt
>and if anyone wants to take a look. BUT:
>
>I'm not going to paste them here, because after reading 1 comment this
>morning, I see something jumping out at me.
>The route for the ethernet between r1--r4 is not in r2's or any other
>router in my topology. I just know I've read something (and
>this morning about making sure the eth route was in the others tables) on
>this group in the archives something along the l
>ines of isis not redisitributed connected interfaces by default, and it
>looks like I've just become another victim of it.
>
>This is my network between r1 - r4 :
>
>C 21.1.1.0 is directly connected, Ethernet0/0
>
>Let me lab this up again today to make sure I got punked, before I stick
>my foot in my mouth anymore.
>
>Thanks guys
>
>_______________________________________________________________________
>Please help support GroupStudy by purchasing your study materials from:
>http://shop.groupstudy.com
>
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:46 GMT-3