The other issue if you try to use my tunneling method is that you'd need a different tunnel for each mask length! My method works very well with one or two masks. Beyond that it would just be a mess!
Last night I was playing with a variation of the tunnel technique where I put the tunnel in an entirely different major network. This would cause the redistributing router to summarize to the major net before advertising to the IGRP router. It works great except for the major net that already exists on the IGRP router. For example.... A-------(igrp)-------B This link is 172.16.1.0/28. You then create a tunnel and assign it 4.0.0.0/8. On B--which is also running OSPF-- you add network 4.0.0.0 to IGRP and then redistribute OSPF into IGRP. B will advertise 172.16.0.0/16 to A via the tunnel interface. Unfortunately, A ignores it. I found no way to make A use that route. Perhaps I'm headed in the right direction but just on the wrong track. ;-) I'm hoping this idea that doesn't work will spark an idea that does work. Regards, John >>> "Gregg Malcolm" 12/14/01 3:31:45 PM >>> Chuck, Seems appropriate that you are due for some pain from the dentist after screwing up my day (and more than likely, my weekend) with this question. It is a very good question tho. Have been thinking about it for awhile and have it set up on my home lab. Obviously, if the masks were reversed on the routing protocols, it with be a trivial matter w/ an OSPF summary. How many routers are you using in this scenario? I am currently using three with the middle being the re-dist point (have 6 in my lab so I can make in larger). I recall the post from John N regarding the use of a tunnel for a situation like this. I believe the problem is that in this case it would require using a /27 mask in the IGRP domain. If the scenario calls for only /28 masks in IGRP, then this would be a violation. So, are the rules : 1. No default-network 2. No static 3. No policy routing 4. Only /28 in IGRP, /27 in OSPF Thanks, Gregg ""Chuck Larrieu"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > It occurs to me that there is another answer to this problem. > > So as a Friday Follies question: what is the other answer I came up with? > > Remember, the IGRP domain is /28 the OSPF domain contains routes /27 and > shorter. You must assure reachability to all interfaces in the OSPF domain. > You are not allowed to use a default network or any static routes to attain > this end. > > for extra credit - make it funny. I will be needing a good laugh after the > dentist is through with me this afternoon. :-O > > Chuck > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > Chuck Larrieu > Sent: Wednesday, December 12, 2001 7:56 PM > To: [EMAIL PROTECTED] > Subject: The old "how to get routes into IGRP" question again - possible > [7:29021] > > > (REPOST) > > I've been fighting with one of my practice labs the last couple of days. The > problem is one of those OSPF to IGRP redistribution with a twist. The IGRP > domain is /28. So how to get those shorter /24 prefixes advertised. Oh yeah, > you can't use the default-network command to create an IGRP default route. > > So let me offer this possibility. > > IP local policy route-map > > the route map then goes something like this: > > route-map igrp-default permit 10 > set default interface [whatever the interface is] > > I also suspect that set ip default next-hop x.x.x.x works also, but at the > time I was testing I hadn't thought through all the implications, and my > test failed. > > In any case, the local policy would have to be implemented on all routers in > the IGRP domain. A bit of planning, then, is required. > > I found out something else that was interesting. Local policy packets seem > to have a particular way they are constructed. the first time I looked at my > debug ip packet, the source address was one of my loopback addresses, which > I was not advertising under IGRP. So of course my pings failed, because the > distant end did not have a route back. So I deleted the loopback, tried > again, and this time the source address was a LAN interface, this too not > advertised under IGRP. I am assuming that Cisco has a hierarchy of > interfaces. Usually a ping is sourced at the interface out which the packets > are headed. But for local policy, it was different. > > Any case, I am offering these observations for consideration. > > Wish I hadn't turned my routers off last night. Or I could gather some > screen shots. > > Chuck Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=29266&t=29266 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
