From: Tom Larus (tlarus@xxxxxxx)
Date: Mon Jul 22 2002 - 08:08:10 GMT-3
Excellent point! I was using tagging and a route map to keep RIP routes
from being redistributed back into RIP from OSPF. Even if I had been able
to do the same in the other direction, it would not have stopped this route,
because RIP had shortened the prefix so it was a new route.
I will need to practice using distribute-lists to stop route feedback. I
really like tagging and route-maps (more scalable and allow redundancy), but
the distribute-lists give you more granular control.
----- Original Message -----
From: "Jonathan V Hays" <jhays@jtan.com>
To: "'Tom Larus'" <tlarus@cox.net>; <ccielab@groupstudy.com>
Sent: Sunday, July 21, 2002 11:16 PM
Subject: RE: Split horizon practice lab experience to share
Enabling split horizon on the IGRP-only router seems like a good quick
fix. Now the IGRP-only router cannot send routes back out the FR-based
serial interface that it learned from that interface. But I wonder if
distribution lists or route-maps on the ASBR's redistribution process
isn't a better solution, since you have more control over what routes
are being allowed into each process?
In a simple lab scenario enabling split horizon may be okay (you might
want to ask the proctor about her/his thoughts on the matter, however).
Suppose the IGRP-only router is the hub of a hub-and-spoke combination.
The OSPF ASBR is one spoke and a second spoke is another IGRP-only
router. If you enable split horizon on the IGRP-only that sees the OSPF
ASBR, that may prevent a routing loop on the OSPF box, but that also
prevents it from sending out those redistributed routes to the other
IGRP-only router.
I am not criticizing you personally. I just think the solution may be
more of a quick fix than a good long-term stable solution.
Jonathan
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Tom Larus
Sent: Sunday, July 21, 2002 11:04 AM
To: Jonathan V Hays; ccielab@groupstudy.com
Subject: Re: Split horizon practice lab experience to share
You are exactly right. I should have said "enable split horizon on
physical FR interfaces where a DV routing protocol is running.
As for detail about the problem:
The problem was that a route to a loopback interface in the OSPF domain
was going into and out of the routing table on a router that was
speaking OSPF and that had a an ISDN link which was configured to as
OSPF demand circuit in area 0. Since it was area ), I could not simply
"stubify" its area a bit to isolate it from route instability elsewhere
in the network, so I had to solve the underlying problem to get the ISDN
link to stay down as it should. Of course, one would need to solve the
underlying routing problem anyway. I am beginning to suspect that a lot
of the problems that people have with ISDN demand circuit are really
problems with instabilities in their routing table. That is one of the
major lessons I take from this.
As for the mechanism of finding the solution, I turned on more debugging
than I needed, but I think it was debug ip ospf lsa-generation that
tipped me off about the exact route that was causing the problem.
Seeing a route local to the OSPF-only router I am working on coming from
way the heck over at the other end of the IGRP domain made the nature of
the problem pretty obvious.
----- Original Message -----
From: "Jonathan V Hays" <jhays@jtan.com>
To: "'Tom Larus'" <tlarus@cox.net>; <ccielab@groupstudy.com>
Sent: Sunday, July 21, 2002 1:23 PM
Subject: RE: Split horizon practice lab experience to share
Hi Tom,
Thanks for sharing your experience. I am a bit confused on a couple of
points in your post. Maybe you or someone else can answer.
1. Was it enabling or disabling split horizon that solved your problem?
I understand that split horizon's basic function is to NOT send network
advertisements out the same interface it came from.
You say below the problem was a router "that had not had split horizon
enabled on the physical interface" - implying that you ENABLED split
horizon to fix the problem. This makes intuitive sense, as enabling
split horizon means fewer updates. But your first "lesson learned" below
says to DISABLE split horizon on physical FR interfaces. I believe that
split horizon is disabled by default on frame-relay interfaces, correct?
Can you clarify this?
2. Could you give a more detailed explanation of the mechanism of the
problem and its solution?
Thanks,
Jonathan
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Tom Larus
Sent: Sunday, July 21, 2002 9:47 AM
To: ccielab@groupstudy.com
Subject: Split horizon practice lab experience to share
Another example of how the basic stuff is the most important stuff. Here
I was working through my materials from NMC-1, to learn the lessons that
I may have missed during class and reinforce the lessons I did learn.
My ISDN link (ospf demand circuit) was coming up more than it should,
but not so often that it was an ISDN config problem.
I figured out that it was instability in the routing tables. Debug
output showed a route from the ospf domain being advertised from the
igrp domain, and the problem turned out to be a router at the far end of
the igrp domain that had not had split horizon enabled on the physical
interface.
Lessons learned:
1) Disable split on physical FR interfaces on which DV protocols are
running (basic point right out of Caslow/Pavlichenko). Missing this
simple step could cost a lot of troubleshooting time if it were to
happen in an exam setting.
2) If you see routes coming over from an IGRP or RIP router that should
not be coming from that router, think of split horizon. Do not go crazy
wondering if it is a quirk about classful routing protocols. Just think
split horizon. (Think of quirks about classful routing protocols when
you are having trouble getting a route advertised to or from an IGRP or
RIP
router)
3) When you are having problems keeping an ISDN link quiet, do not
instantly assume that you have misconfigured the ISDN link, that you
need to put no peer neighbor route on another router, or that you need
to use a distribute list of some sort (you may need one of these, but
don't assume
so.) The problem may simply be instability in your IGP tables.
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:36:38 GMT-3