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]