belaboring beyond all usefulness maybe, but I am prone to write this one off as "because that's how it works" and move one. secondary addressing appears to be filled with pitfalls. I believe it has nothing to do with RFC's, but rather, it's just the way the code runs. I think over the past few weeks we have examined the behaviour in detail, and have at best a few things to try, but no real consistency. RIP appeared to be happier with secondary addressing than does IGRP.
with regards to the /16 summary, IGRP appears to accept routes only with the classful mask matching that of the interface that receives the route. I suppose a good question is "how does it know?" In my experiments, I redistributed lots of routes with lots of different masks into IGRP. Only those with a mask matching that of the IGRP domain were accepted. A summary /16 was never created. At this point I am supposing that the redistribution code is what controls that. Otherwise, why not accept ALL routes as matching the IGRP domain mask? e.g. 129.5.10.1/22 as 129.5.10.0/28 for example? I wish CCO got into this kind of thing a bit more. Sure would love to talk to the people who coded this stuff. Chuck -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John Neiberger Sent: Tuesday, December 18, 2001 11:12 PM To: [EMAIL PROTECTED] Subject: Re: RE: That Friday Follies Question... [7:29473] I thought I had discovered a way to do this but it didn't work, either. It was a variation of the tunnel technique except the tunnel is in a completely different classful network. For example... A----(igrp)-----B The link is 172.16.1.0/28. I create a tunnel that is 4.0.0.1/8. On B, I configure both networks in IGRP. I was hoping that B would send a 172.16.0.0/16 summary back to A, which it does, but A ignores it and I could never figure out why. I wonder if that strange behavior earlier with split horizon might come into play here? There just *has* to be a way to get A to accept the summary route from B over the 4/8 tunnel. Any thoughts there? John BTW, if I marked the calendar every time I was wrong there'd be no room left on the calendar! :-) ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag ---- On Wed, 19 Dec 2001, Chuck Larrieu ([EMAIL PROTECTED]) wrote: > that reminds me... > > mark this date on your calendars, everyone. I was WRONG. > > I pretty much spent the weekend testing various scenarios, and I have > compiled several pages of observations. But the short of it is that > given > the constraints of the scenario - full reachability into a VLSM domain > from > an FLSM domain whose prefix is LONGER that most of the routes in the > VLSM > domain, and without the use of a default network or default route seems > doable only by judicious use of policy routing. Local policy in > particular, > depending upon the topology. > > I was thinking that one could create a summary route on the classful > boundary of the network in question. But IGRP in particular will not > accept > the summary /16 if all the interfaces in its domain are some other > prefix. > > Chuck > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > c1sc0k1d > Sent: Tuesday, December 18, 2001 1:02 PM > To: [EMAIL PROTECTED] > Subject: Re: That Friday Follies Question... [7:29473] > > > Hmmm... interesting. I'll give it a go in my lab and let you know what > happens. I'm looking forwards to Chucks answer as well. > > The k1d > > > > ""John Neiberger"" wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > 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=29613&t=29473 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
