swb@TCGOULD.TN.CORNELL.EDU (Scott Brim) (02/02/88)
I suspect this deserves to be called a bug...... We have a few static network routes installed in our campus gateways (p4200s) in order to take care of some miscellaneous non-routing gateways attached to some ethernets. The way we do it is we put a static route in the p4200 (or p4200s) which lie between the campus backbones and the ethernet that particular box hangs off of. The problem is that with version 7.4 we also have "split horizon" route announcements. What we get, then, is oddnet--oddgw--ethernet--p4200--backbone-->world What we see is that the p4200 will announce (RIP) its static route out with a reasonable metric to the backbone and the world, but in the direction that the static route points (toward the ethernet) it always sends out a metric of 16 (infinity). That means that since 7.4 anything which is between the p4200 and the odd gateway (in this case that means on the shared ethernet) has no route to the odd network, despite the p4200's static route. If there were some way to work around this with reasonable engineering I wouldn't consider it a bug. I just don't see a good solution though (I don't like the idea of having to have a static route in everything on that ethernet). I believe that a static route entry should not be affected by the split horizon rule. Scott
lekash@ORVILLE.NAS.NASA.GOV (John Lekashman) (02/02/88)
Umm, why should a p4200 have to cover for a defective non-routing oddgw? I realize it would be nice if it did, but I think that the oddgw should participate in some sort of routing protocol, which could then be used. I can see you wanting to set the static route in the p4200, and having everthing else pick up on that from there, but it seems counter-productive to accomodate broken (ie non-routing) gateways. Perhaps it is more expedient to get proteon to hack up routing again, since they are more responsive than oddgw, but perhaps one should get oddgw to be repaired. john
fedor@NISC.NYSER.NET (Mark Fedor) (02/02/88)
Scott, Remember the old arguments/discussions we had when developing gated? This very question came up. This exact problem caused a routing problem at JVNC. Our solution with gated was to not apply the split-horizon rule to STATIC routes. This seems to have worked fine in our gated experiences. It's nice to see we are not the only ones who have grappled with this problem. While not very consistent (and elegant), I think split-horizon should not be applied to STATIC routes. I'm sure there are other people who think otherwise.... Mark
fedor@NISC.NYSER.NET (Mark Fedor) (02/02/88)
> >Date: Mon, 1 Feb 88 14:48:47 PST >From: John Lekashman <lekash@orville.nas.nasa.gov> >Subject: Re: split horizon vs. static routes > >Umm, why should a p4200 have to cover for a defective non-routing >oddgw? I realize it would be nice if it did, but I think that the >oddgw should participate in some sort of routing protocol, which >could then be used. I can see you wanting to set the static route >in the p4200, and having everthing else pick up on that from there, >but it seems counter-productive to accomodate broken (ie non-routing) >gateways. Perhaps it is more expedient to get proteon to hack >up routing again, since they are more responsive than oddgw, but >perhaps one should get oddgw to be repaired. > > john >>>> John, Your point is well taken and I can't really argue with it, but (there's always a but, eh?) let's say the oddgw was not broken. It was only running a different routing protocol (let's say HELLO). The keepers of this network didn't want to run gated anywhere (they didn't have a unix gateway around). They simply wanted to use scott's suggestion. They couldn't do it with the 7.4 software. Maybe I'm grasping for straws, but applying split-horizon to static routes seems to limit the usefulness of static routes. And most times when you need static routes, you have this strange configuration and you need them to be as useful as possible. Like you said, this is not a bug (it's an opinion???). It sure would be nice if Proteon 7.4 didn't apply split-horizon to static routes. I would like to see a change. We'll see. Any other comments? Mark
mac@MONK.PROTEON.COM (Michael A. Curtis) (02/03/88)
Scott, As a work around, why not try this: oddnet--oddgw--ethernet--p4200--backbone-->ROW Add a second IP address to the P4200 (ethernet side) and to the oddgw (same side) and change the static route to indicate that the route to oddnet is via the new address in the oddgw. The end result is: 1) RIP out via ethernet (old address). 2) Route via new address in oddgw. We realize that this is going to introduce an extra hop for traffic destined for oddnet which originates on the ethernet, but is the result of the work around and appears to be unavoidable when operating incompatible machines. Let me know how it works. Best regards, Michael A. Curtis Proteon, Inc.
ccruss@deneb.ucdavis.edu (0059;0000000000;230;9999;98;) (02/03/88)
We ran into the same problem when we came up on 7.4. We also have a
dumb gateway that can not advertise itself and had been using the
p4200 to advertise the route. The quick solution was to put the static
route in the p4200 anyway and have the p4200 as the default route. The
other hosts did not know the route to the dumb gw, so they sent it to
the default. The p4200 as the default did know about the dumb gw because
of the static route and would send it on its way. Not a clean solution,
but it worked.
When we get time we will make the change to allow a gated host to advertise
the dumb gw.
Russell Hobby
Data Communications Manager
U. C. Davis
Computing Services BITNET: RDHOBBY@UCDAVIS
Davis Ca 95616 UUCP: ...!ucbvax!ucdavis!rdhobby
(916) 752-0236 INTERNET: rdhobby@ucdavis.edubraden@VENERA.ISI.EDU (02/03/88)
Scott, Presumably, when a host on the ethernet sends a packet destined for oddnet to the P4200, the P4200 should send a Redirect back to the host, specifying the oddgw. If the P4200 does not send such a Redirect, it does not follow RFC1009, and that should indeed be a bug. Bob Braden
jnc@BRUBECK.PROTEON.COM (02/05/88)
Scott, I don't know what people out at Proteon think of this issue, but my personal comment is that if you want RIP to operate this way you need to bring this up with Chuck Hedrick and get him to put it in the RIP RFC. I don't have any definite conclusion as to whether this behviour will negate what split horizon was put in to do; I do agree there is a problem, though. Noel -------
mac@MONK.PROTEON.COM (Michael A. Curtis) (02/10/88)
Gentlemen, I have been asked to take a minute to clarify the issue with the Split Horizon and Static Routes. What I know: 1) Static Routes are subject to Split Horizon/Poison Reverse. 2) oddgw and the P4200 do not share a common Routing Protocol. 3) The P4200 does not advertise on the ethernet that it knows how to get to oddnet. My thoughts: 1) Trick the P4200 into routing to oddnet at the expense of an extra hop. 2) Add a second IP address on both the oddgw and the P4200 and change the static route in the P4200 to reflect the new IP address at the route to oddnet. What happens: 1) The P4200 will NOT advertise a route out the new IP address to oddnet. 2) The P4200 WILL advertise a route to oddnet via the original IP address. 3) Hosts on the ethernet will think the P4200 is the route to oddnet with the expense of an extra hop, when oddgw actually is the right route. 4) The P4200 will NOT issue an ICMP Redirect even though it is sending packets destined for oddnet out the same interface they were received on because it is sending them out on another IP address on that interface. 5) The P4200 WILL advertise out to the backbone the correct route to oddnet and will not incur an extra hop for traffic generated on networks/subnets other than the ethernet. Hope this helps. I'm game if anyone has any better ideas or comments. Best regards, Michael A. Curtis Proteon, Inc.
hans@umd5.umd.edu (Hans Breitenlohner) (02/13/88)
I find it unfortunate that there seems to be such overwhelming consensus (at least among the readers which post articles) that split horizon should not apply to static routes. I would like to present two arguments against that. First a very general one. The configuration in question always seem to involve an 'othergw' which does not speak RIP, hosts which listen to RIP, and a p4200, on an ethernet. The argument further involves something of the flavor "I don't want to install static routes on all hosts". Well, with all due respect, you have a mismatched batch of equipment, and you should pay the price for that. This could be done by installing static routes, default routes, or by adopting Mike Curtis' proposal (at a slight performance hit). I can understand that you would like for Proteon to solve your problem, but I think that it is unreasonable to expect it. The second argument is more specific, and involves a counter-example. This is not contrived, but actually happened. I won't mention any names, to protect the innocent (and the not so innocent). Take a regional network, consisting mainly of p4200s connected via serial lines. Several sites have connections either to Arpanet or to Milnet. Many of these also advertise default. A site with a Milnet connection decides that its Arpanet traffic should not be routed through its Milnet connection, and puts in a static route pointing to the rest of the network for net 10. Unfortunately this site runs 7.3, and the route for net 10 gets advertised to the rest of the network. There it overrides the best way known to reach net 10 (via default route). Instant routing loop, instant black hole for net 10, instant disaster! In some cases it may be possible to manipulate hop counts to avoid this, but in the case where the network for which the static route is installed is handled by default instead of explicit advertisments there is no other way to accomplish the same thing. In conclusion, there are a number of different scenarios in which static routes are useful. In some cases ignoring split horizon might be useful or expedient, but in other cases it can lead to disaster. I have no problem with Proteon adding the flexibility to allow users to ignore split horizon for static routes, but I think it would be a serious mistake to do so as the general case.