John,
This surely peeked my interest as to why the secondary address
solution wouldn't work so I mocked it up and as you noted nothing...
I think my chain of thought made me think that as long as the secondary
address was on the mask of the route being propagated to R1 then
it should work. However, in the setup all the subnets(172.16.1/2/3.x)
when defined under IGRP would be summarized back to the classful boundary
172.16.0.0. When this happens the router simply does not broadcast the
update
since the networks being advertised fall into the connected interface
classful boundary.
00:53:38: IGRP: sending update to 255.255.255.255 via Serial0 (172.16.1.2) -
(to R1)
00:53:38: IGRP: Update contains 0 interior, 0 system, and 0 exterior routes.
00:53:38: IGRP: Total routes in update: 0 - suppressing null update
00:53:38: IGRP: sending update to 255.255.255.255 via Serial1 (172.16.2.2) -
(to R3)
00:53:38: subnet 172.16.3.0, metric=8476
00:53:38: IGRP: Update contains 1 interior, 0 system, and 0 exterior routes.
00:53:38: IGRP: Total routes in update: 1
once this is/was identified your only option to get the route to R1 is to
disable
"split-horizon" on R2's S0 interface that's connected to R1. This now allows
the
routes that would otherwise be filtered be advertised to R1.
01:02:51: IGRP: sending update to 255.255.255.255 via Serial0 (172.16.1.2) -
(to R1)
01:02:51: subnet 172.16.1.0, metric=8476
01:02:51: IGRP: Update contains 1 interior, 0 system, and 0 exterior routes.
01:02:51: IGRP: Total routes in update: 1
01:02:51: IGRP: sending update to 255.255.255.255 via Serial0 (172.16.3.2) -
(to R3)
01:02:51: subnet 172.16.2.0, metric=8476
01:02:51: subnet 172.16.3.0, metric=8476
01:02:51: IGRP: Update contains 2 interior, 0 system, and 0 exterior routes.
01:02:51: IGRP: Total routes in update: 2
However, I observed a strange occurrence in that R2 generates a
172.16.1.0/28 route
that is also advertised to R1. How and Why? I'm looking into it.. When
this happens
then another requirement would be to use "no ip classless" (note: there is
no 0/0,
candidate defaults, etc..) to avoid the 172.16.1.0/28 route from being used
so to
avoid the obvious routing loop between R1 and R2.
Very interesting results from the question as to why we had the
172.16.1.0/28 route
generated from R2 to R1. Well after very simple process it become quite
clear as to why
the route was created. Simply put, although the 172.16.3.0/28 was
configured on the
R1 - R2 link in order for R1 to accept routes on the /28 mask.. the Primary
interface
still quite possibly would not pass that (/28) route information without
being associated
as having a /28 mask itself. I came to this conclusion by the debugs from
R1..
R1#
01:06:27: IGRP: broadcasting request on Serial0
01:06:27: IGRP: received update from 172.16.1.2 on Serial0
01:06:27: subnet 172.16.1.0, metric 10476 (neighbor 8476) ***
01:06:27: IGRP: Update contains 1 interior, 0 system, and 0 exterior routes.
01:06:27: IGRP: Total routes in update: 1
R1#
Notice the 172.16.1.0 route that was sent from R2 it the only route that R1
receives.
this is that same /28 route that now allows R1 to also see the
172.16.2.0/28.
R1#
01:08:20: RT: add 172.16.1.0/24 via 0.0.0.0, connected metric [0/0]
01:08:20: RT: network 172.16.0.0 is now variably masked
01:08:20: RT: add 172.16.3.0/28 via 0.0.0.0, connected metric [0/0]
01:08:20: IGRP: broadcasting request on Serial0
01:08:20: IGRP: received update from 172.16.1.2 on Serial0
01:08:20: subnet 172.16.1.0, metric 10476 (neighbor 8476)
01:08:20: RT: add 172.16.1.0/28 via 172.16.1.2, igrp metric [100/10476]
01:08:20: IGRP: Update contains 1 interior, 0 system, and 0 exterior routes.
01:08:20: IGRP: Total routes in update: 1
R1#
The R1 RIB eventually ends up as follows..
R1#
Gateway of last resort is not set
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
I 172.16.1.0/28 [100/10476] via 172.16.1.2, 00:00:14, Serial0
C 172.16.1.0/24 is directly connected, Serial0
I 172.16.2.0/28 [100/10476] via 172.16.3.2, 00:00:14, Serial0
C 172.16.3.0/28 is directly connected, Serial0
R1#
NOTE: Although everything looked and suggest that a ping/trace to a host
within the
172.16.1.0/28 mask(172.16.1.10) should be sent to R2 and then back to R1
causing a
routing looping(before using the "ip classless" command). However, this did
not happen
instead when the packet returned to R1 it then timed out..
R1#trace 172.16.1.10
Type escape sequence to abort.
Tracing the route to 172.16.1.10
1 172.16.1.2 136 msec 16 msec 16 msec
2 172.16.1.1 32 msec 28 msec 32 msec
3 * * *
4 * * *
5 * * *
Well this was interesting.. I hope I answered more questions than I asked.
The
disabling of split-horizon in this instance with proper filtering could be
considered
a viable solution if there were limiting factors in the given requirement
when ensuring
all routes are present in all routers throughout the network
Would I do this in my production network... :-> but then again the CCIE
lab isn't
a production network is it. there's so many way for them to get you it's
not funny..!
HTH
Nigel.
----- Original Message -----
From: "John Neiberger"
To:
Sent: Sunday, December 09, 2001 12:38 AM
Subject: VLSM and IGRP into OSPF - Another Method [7:28567]
> Lately there have been a few posts regarding redistribution
> issues between IGRP and OSPF. One in specific had the
> following scenario:
>
> R1----(IGRP)-----R2------(OSPF)------R3
>
> The R1-to-R2 link is 172.16.1.0/24 and the R2 to R3 link is
> 172.16.2.0/28. Same major network, different subnet masks.
>
> The issue is that we want R1 to see the 172.16.2.0/28 network,
> but R2 won't advertise a /28 subnet of 172.16 out an interface
> that has a /24 mask.
>
> One solution we came up with was to add a loopback interface to
> R2 and then assign a "dummy" OSPF area to it. This makes R2 an
> ABR. Then you can use the area range command to summarize
> the /28 into a /24 and it can then be redistributed into IGRP.
> Notice that this allows R1 to see 172.16.2.0/24, not the /28.
>
> Another method we discovered this morning was to use a tunnel
> instead. Create a tunnel between R1 and R2 and give it a /28
> mask, let's say 172.16.3.0/28. This alone will cause R2 to
> advertise 172.16.2.0/28 to R1.
>
> Now, to complete end-to-end connectivity you need to either add
> the tunnel endpoint on R2 to the OSPF process or redistribute
> connected on R2. This allows R3 to see the tunnel.
>
> You now have end-to-end connectivity without the need to add a
> new "dummy" OSPF area.
>
> Do any of you have any other ideas? We've tried using
> secondary IP addresses but have yet to make it work trying a
> few different methods.
>
> Regards,
> John
>
> ________________________________________________
> Get your own "800" number
> Voicemail, fax, email, and a lot more
> http://www.ureach.com/reg/tag
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=28588&t=28567
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
