Nigel, Sometimes I just wish I'd pay more attention. ;-) You did, in fact, run across exactly what I was seeing. Maybe I didn't pay attention during your original post because I hadn't run into a couple of those issues yet. Then, when I did run into them I had completely forgotten about the results from your testing.
I promise to watch more carefully in the future! Thanks, John ---- On Wed, 19 Dec 2001, Nigel Taylor ([EMAIL PROTECTED]) wrote: > 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 [EMAIL PROTECTED] > > > > ________________________________________________ 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=29744&t=29744 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
