Re: Redirect wars and Buterfly gateways

Greg Skinner (
Mon, 19 May 86 14:12:00 PDT

> From: tom@LOGICON.ARPA (Jeff Makey , Tom Perrine)

> Speaking of brain-dead gateways, we have had some more instances of the
> ICMP "redirect wars". This morning SRI-MILNET-GW redirected us to
> BBN-MILNET-GW, who redirected us back to SRI-MILNET-GW. This happened
> 11 times in 29 seconds while trying to establish a connection.
> A reponse came in 23 seconds, but after we had timed out.

This happens to me also. Here's a sample netstat -r from
( It seems that our default gateway does not
always know how to get cross-net ...

Routing tables
Destination Gateway Flags Refcnt Use SWS pm Interface
default UG 0 25 75 0 imp0
su-net-temp sri-milnet-gw.a UG 0 1030 75 0 imp0
su-net-temp isi-gateway.arp UG 0 1027 75 0 imp0
su-net-temp stanford-gatewa UG 0 6071 75 0 imp0
su-net-temp UG 0 3 75 0 imp0
su-net-temp sac-milnet-gw.a UG 0 3 75 0 imp0
su-net-temp UG 0 4 75 0 imp0
su-net-temp lbl-milnet-gw.a UG 0 2 75 0 imp0
su-net-temp bbn-milnet-gw.a UG 0 4 75 0 imp0
su-net-temp bbnnet2-arpanet UG 0 4 75 0 imp0
su-net-temp UG 0 2 75 0 imp0
su-net-temp UG 0 1 75 0 imp0
su-net-temp bbn-cronus-gw.a UG 0 2 75 0 imp0
su-net-temp isi-milnet-gw.a UG 0 1 75 0 imp0
su-net-temp UG 0 2 75 0 imp0
su-net-temp bbn-net-gateway UG 0 2 75 0 imp0
su-net-temp dcec-milnet-gw. UG 0 1 75 0 imp0

Note the highest use count for the su-net-temp net is for
stanford-gateway, which is as it should be. Some of the other gateways
mentioned are a little skeptical -- why would multiple gateways at BBN
be involved in what should be a decision strictly made in California?

One question is how your host handles redirects. In 4.2, if there are
multiple gateways to the same destination, it attempts to share the load
between the two, by taking the lowest use count. I have discovered
situations in which this may not be ideal. 4.3 attempts to be more
flexible by taking the route from the last redirect, and notifying any
connections of the route change (this is done in 4.2 BBN also). There
is a short time in between the issuance of the redirect and the route
change for the connection in which the old route might be used, which
could cause a flurry of redirects. I'd like to know how yours (and
others) IP routing implementations handle these sort of situations.
(I'd especially like to hear from the "hosts should be dumb, gateways
should be smart" folks.)

Back to the original topic, though, I have noticed similar behavior
going between and for a lot of
connections I make (aside from the above, this happens for the rutgers
and mit-temp networks).


This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:33 GMT