>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.
What I wish is that Cisco would STOP TEACHING classful addressing. With classless addressing, pretty much all the needs for secondary addresses go away. Treat classful legacy networks as a special case like NetBEUI or Banyan. The problem, in part, is that IGRP and RIPv1 were not designed or implemented with secondary addresses in mind. They dealt well with a consistent classful world on primary addresses only. > >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=29635&t=29473 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
