John,
On one of your most recent test scanerios I had posted what you
noticed here and made some assumptions based on what we know of the routing
protocols behavior. Here's my reply from what I saw duiring that test...
------- Paste Begin -----------
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 thinking about it
things become
somewhat 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: Wednesday, December 19, 2001 1:17 AM
Subject: More Friday Follies [7:29607]
> Okay, I tried something else and it's getting even stranger yet.
>
> Previously, at Chuck's suggestion I added no ip split-horizon.
> However, I only added it to the redistributing router. That
> had interesting yet not entirely successful results.
>
> Then, I added no ip split-horizon to the IGRP-only router,
> which makes no sense since in my configuration it is not
> advertising any routes. Strangely enough, this seemed to work
> for a bit until a routing loop developed. ;-)
>
> So, I added a distribute list to the IGRP-only router
> disallowing any outgoing routing updates. Things are now
> equally unpredictable but I'm seeing sometihng I didn't see
> before:
>
> I 172.16.20.0/28 [100/10476] via 172.16.20.1, 00:00:30,
> Serial1
> C 172.16.20.0/24 is directly connected, Serial1
> I 172.16.10.0/28 [100/8976] via 172.16.20.1, 00:00:30,
> Serial1
> I 172.16.5.0/28 [100/8976] via 172.16.1.1, 00:00:30,
> Serial1
> C 172.16.1.0/28 is directly connected, Serial1
>
> See the 172.16.20.0/28 route? It doesn't exist!
> 172.16.20.0/24 is directly connected. For some reason, this
> router now thinks it's learning the /28 subnet of that network
> via IGRP, which it isn't.
>
> My guess is that it's taking the network from the secondary
> address and applying the mask of the primary address. Bizarre,
> and very undesirable!
>
> Now I'm back to where I was before. Tunnels, while being
> unwieldy and ugly, work. If a back-to-back frame relay
> connection is allowed then subinterfaces work equally well.
>
> It really seems that there ought to be another way to make this
> work so if anyone discovers the trick that I appear to be
> missing, please pass it along. I'm sure there is a key to this
> that I'm overlooking.
>
> Thanks,
> John the Bewildered
>
> ________________________________________________
> 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=29717&t=29717
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
