From: Chuck Larrieu (chuck@xxxxxxxxxxxxx)
Date: Thu Mar 01 2001 - 15:25:52 GMT-3
It may be time to revisit routing 101, and my original premise on this one.
We are starting to stray down the path of trying things just for the sake of
trying them. Let me reiterate that at this time, everything is as it should
be. I have the redistribution configured as was posted earlier. All routes
are showing up in the particular routing table as expected. Ospf routes as
ospf routes, eigrp routes as eigrp routes.
1) with a single point of redistribution, and between only two routing
protocols, route filtering of any kind is not particularly relevant. The
various routers in the various domains that are adjacent to the
redistribution router will see multiple routes under different protocols,
and will install into the routing table the route with the lowest
administrative distance.
2) in this same case, when another router now joins a different routing
domain, and is running both protocols, but not redistributing, that router
will again see multiple routes from different domains, and SHOULD install
the route with the lowest AD into the routing table.
This is the way it is working now, without distribute lists, without
filtering. All is as it should be. Native ospf has an AD of 110. The
redistributed ospf routes have an eigrp AD of 170 ( eigrp external )
My original post was made because when I first set this up, and I observed
that with a particular route, that apparently did not happen. A particular
ospf route showed up as an eigrp external route with an ad of 170. I
corrected the problem by following the methodology I outlined earlier.
Unfortunately, I did not have the presence of mind to do some simple debugs
so that I could follow the router process. Since that time, I have been
unable to recreate the problem.
I do not believe the original problem occurred due to issues with
redistribution. I do not believe the original problem occurred because of
misconfiguration of one routing protocol or another. None of my configs
have changed during this exercise.
That leaves me with artifact / bug / one of those things.
I believe a number of folks on this list have experienced weird problems
with one routing protocol or another from time to time. And have experienced
the magic of the Microsoft solution - reboot and see if that clears the
problem.
My intent has been to add my observation and experience to the group's
collective wisdom. I do not believe there is a rational explanation for what
I observed.
Chuck
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Jim.Fickett@SAPPI-NA.COM
Sent: Thursday, March 01, 2001 9:53 AM
To: chuck@cl.cncdsl.com; ccielab@groupstudy.com
Subject: RE: route artifact revisited
Chuck,
I would try adding something like
router ospf 599
distribute-list 1 out eigrp 100
router eigrp 100
distribute-list 2 out ospf 599
access-list 1 deny 20.0.0.0 0.255.255.255
access-list 1 permit any
access-list 2 deny 10.0.0.0 0.255.255.255
access-list 2 permit any
see if that helps
Jim Fickett
-----Original Message-----
From: Chuck Larrieu [mailto:chuck@cl.cncdsl.com]
Sent: Thursday, March 01, 2001 12:32 PM
To: Jim.Fickett@SAPPI-NA.COM; ccielab@groupstudy.com
Subject: RE: route artifact revisited
Jim, in my case, the configuration is as follow:
router eigrp 100
redistribute ospf 599 metric 100 100 255 1 1500
network 20.0.0.0
no auto-summary
!
router ospf 599
redistribute eigrp 100 subnets
network 10.3.3.3 0.0.0.0 area 3
network 10.10.3.3 0.0.0.0 area 0
( yes I know. But I always screw with the eigrp metrics, just to see what
happens. And everything is working correctly now, with this identical
configuration )
Here is what SHOULD happen, and what NOW happens after the clear ip ospf
process:
R4 has a routing table that contains the eigrp external routes, with an AD
of 170 ( sorry - I was misusing the term "metric" in previous posts ) and
the eigrp metric.
OSPF becomes active, and the router sees routes with a better AD come into
the router, and installs them into the routing table. As shown from a debug
ip routing trace:
RT: closer admin distance for 10.1.0.0, flushing 1 routes
<-----------------------
RT: add 10.1.0.0/16 via 20.253.253.5, ospf metric [110/74]
<----------------------
RT: closer admin distance for 10.3.0.0, flushing 1 routes
RT: add 10.3.0.0/16 via 20.253.253.5, ospf metric [110/138]
RT: closer admin distance for 10.10.2.0, flushing 1 routes
RT: add 10.10.2.0/24 via 20.253.253.5, ospf metric [110/128]
This apparently did not happen when I originally built the network. Several
clear ip rout * did not yield this result.
Unfortunately I did not have the presence of mind to do the debug ip routing
at the time I was troubleshooting the original problem.
Chuck
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Jim.Fickett@SAPPI-NA.COM
Sent: Thursday, March 01, 2001 9:16 AM
To: ccielab@groupstudy.com
Subject: RE: route artifact revisited
How is R3 configured to prevent the EIGRP route that is redistributed into
OSPF from being redistributed back into EIGRP and vice versa with OSPF to
EIGRP?
Jim Fickett
-----Original Message-----
From: Nodir Nazarov [mailto:nodir@datatone.com]
Sent: Thursday, March 01, 2001 11:44 AM
To: frank wells
Cc: ccielab@groupstudy.com
Subject: Re: route artifact revisited
By the way - I could reproduce Chuck's scenario.
To recap:
R1---R4
| |
R3--R6
R1 - ospf only, R6 - eigrp only. R3 - mutually distributes each other. R4
- runs both protocols, but does not redistribute.
On R4 I got connected router (between R1 and R3) as EIGRP external. Had it
at least for 17 minutes. Checked after 10 minutes - got right one. After a
while - EIGRP external showed up. So it's flapping.
EIGRP - 172.16.0.0
OSPF - 192.168.13.0 (between R1 and R3), 192.168.14.0 (R1 and R4)
Nodir
On Thu, 1 Mar 2001, frank wells wrote:
> What prefixs' are you using on the OSPF and EIGRP sides?
>
>
> >From: "Chuck Larrieu" <chuck@cl.cncdsl.com>
> >Reply-To: "Chuck Larrieu" <chuck@cl.cncdsl.com>
> >To: "CCIE_Lab Groupstudy List" <ccielab@groupstudy.com>
> >Subject: route artifact revisited
> >Date: Wed, 28 Feb 2001 23:12:41 -0800
> >
> >Practicing redistribution for the next couple of days. My strange
behaviour
> >of the evening:
> >
> >Ospf domain --------------EIGRP domain
> >Router_1-----------------------router_4 r4 runs ospf and eigrp but
> >does not redistribute
> >| /
> >Router_3----------Router_6 r3 redistributes both ways, r6 is
> >eigrp
> >only
> >
> >The artifact - a route directly connected to an interface on R1 shows up
on
> >R4 and an eigrp external with a metric of 170. All other ospf routes are
on
> >r4 as they should be, with a metric of 110
> >
> >Several clear ip route * does not correct the situation. I shut off
> >redistribution, do a clear ip ospf proc on R1, verify that the route in
> >question is an ospf route on r4, reconfigure redistribution, and now
> >everything is as it should be. I add redistribution back onto r3. The
route
> >in question remains an ospf route. I check the output of debug ip
routing,
> >and see that the ospf route is replacing the redistribute and now EIGRP
> >route in R4's table.
> >
> >I can derive no good explanation. If I recall how I built the lab
> >correctly,
> >it is true I did not add OSPF to R4 until last, after redistribution was
in
> >place on r3. So the eigrp route would have been in r4's table already.
But
> >then, so were all of the other ospf routes, and when ospf was built, they
> >appeared as ospf routes on r4
> >
> >I'm a bit puzzled by this. And open to a rational explanation.
> >
> >Chuck
> >----------------------
> >I am Locutus, a CCIE Lab Proctor. Xx_Brain_dumps_xX are futile. Your life
> >as
> >it has been is over ( if you hope to pass ) From this time forward, you
> >will
> >study US!
> >( apologies to the folks at Star Trek TNG )
> >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:29:17 GMT-3