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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=29599&t=29473 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
