Well, this is getting even weirder. Adding no ip split-horizon
seems to work, sort of. If I shut down the interfaces involved
and then bring them back up, all routes are advertised. Look
at the following:
C 172.16.20.0/24 is directly connected, Serial1
I 172.16.20.0/28 [100/10476] via 172.16.20.1, 00:00:05,
Serial1
I 172.16.10.0/28 [100/8976] via 172.16.20.1, 00:00:05,
Serial1
I 172.16.5.0/28 [100/8976] via 172.16.1.1, 00:00:06,
Serial1
C 172.16.1.0/28 is directly connected, Serial1
That was from the IGRP-only router. As you can see, it is
learning /24 and /28 routes over the same interface. Now look
at the output of show ip protocols:
Routing Information Sources:
Gateway Distance Last Update
172.16.20.1 100 00:00:13
172.16.1.1 100 00:00:13
As you can see, it is receiving updates from both IP
addresses. Here's where it gets weird. I now do a clear ip
route * and look what happens:
Routing Information Sources:
Gateway Distance Last Update
172.16.20.1 100 00:00:20
172.16.1.1 100 00:00:03
It stops receiving routes from the secondary! The /24 routes
disappear from the routing table and can only be brought back
by doing a shut/no shut on the interfaces involved.
If I don't ever clear routes, this router continues to receive
updates from both source addresses. Why would it stop
receiving routes *after* I clear routes?
Very interesting. This is close to what I noticed before.
Sometimes it would seem to work but then it would stop. Thanks
to this experiment I can now reproduce it. However, I have no
explanation. :-)
Any takers?
Thanks,
John
________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
---- On Tue, 18 Dec 2001, Chuck Larrieu ([EMAIL PROTECTED])
wrote:
> did you disable split horizon? I can't think of why it should
work, but
> a
> couple of weeks ago we had a thread on secondary addresses
with RIP and
> the
> only way to get that one to work was by disabling split
horizon on the
> interfaces where the secondaries appeared.
>
> Chuck
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of
> John Neiberger
> Sent: Tuesday, December 18, 2001 12:06 PM
> To: [EMAIL PROTECTED]
> Subject: Re: That Friday Follies Question... [7:29473]
>
>
> In my testing I was never able to get secondary interfaces to
work
> properly. IGRP would advertise over one or the other, but
not both, and
> I wasn't able to figure out how it picked which one to use.
I've
> configured slightly different scenarios from scratch two or
three times
> and I could never make secondary IP addresses work.
>
> John
>
> >>> "c1sc0k1d" 12/18/01 12:25:29 PM >>>
> AFAIK, there is only one way to summarize with rip and igrp
and that is
> by
> creating a static and redistributing the static. Since that
is not
> possible
> and since we cannot use the default network command we must
have an
> ospf
> interface that shares the /27 igrp network to get routes to
pass.
> That
> could be performed with secondary addresses or a tunnel
interface (or
> a
> frame subinterface). I think for igrp to advertise on the
secondary
> address
> method, it also needs to be configured to advertised on the
primary,
> although I could be mistaken. I know it's that way for eigrp.
>
> The k1d
>
>
>
> ""John Neiberger"" wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > The R1/R8 Tunnel needs to be a /28 since you're trying to
get /28
> routes
> > into the IGRP domain. However, since you're going from a
> longer-match
> > mask to a shorter-mask, you don't need to use this method.
It will
> work
> > but you could also use a couple of the other methods posted.
> >
> > First, you could create a loopback interface on R8 and then
assign
> it
> > to a "dummy" OSPF area. This allows you to use the area
range
> command
> > to summarize the /28 routes into a /27.
> >
> > Another option that someone posted was to use two OSPF
processes and
> > redistribute one into the other and use the summary-address
command.
> >
> > I thought that Chuck's Follies question was how to get
shorter-mask
> > routes from OSPF into IGRP. Using your example, try making
the OSPF
> > domain /27 and the IGRP domain /28. That makes things much
more
> > difficult!
> >
> > I've found two ways to handle this and I don't like either
one, to
> be
> > honest. I'm anxiously awaiting Chuck's answer because this
is
> really
> > bugging me. There ought to be an easier way. However, in
the real
> > world we wouldn't have the restrictions of the lab.
> >
> > John
> >
> > >>> "Richard Botham" 12/18/01 8:18:00 AM >>>
> > John,
> > Thanks for wrecking my weekend too......
> > I tried to get this to work using the tunnel method and the
> secondary
> > addressing method but with no success.
> >
> > My lab looks look like this
> >
> > r4--(igrp/27)--r2--(igrp/27)--r1--(igrp /27)--r8--(ospf /28)
> >
> > interfaces
> >
> > r4/r2 network 172.168.10.80/27
> > r2/r1 network 172.168.10.64/27
> > r1/r8 network 172.168.10.16/27
> > r1/r8 tunnel 172.168.11.0/27
> > r8 network 172.168.10.32/28
> >
> >
> > I tried all combinations of /27 & /28 masks on the tunnel
to try and
> > get the
> > /27 routes into the table on r1 but with no joy.
> >
> > Look at this form debug ip igrp trans
> >
> > 04:49:59: IGRP: sending update to 255.255.255.255 via
Tunnel0
> > (172.168.11.1)
> > 04:49:59: subnet 172.168.10.32, metric=6882
> >
> > So the route appears to be advertised out of tunnel0
towards r1 as
> you
> > would
> > expect , because the mask is the same.
> > However the route never appears in the routing table on r1
although
> it
> > has
> > an interface using a /27 ( tunnel )
> > You do not see r1 receiving the /27 route
> >
> >
> > I would like to hear your thoughts as I cannot think of
another way
> to
> > get
> > around this one.
> >
> > Best regards
> > Richard Botham
[EMAIL PROTECTED]
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=29605&t=29473
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
