mcb@styx.UUCP (Michael C. Berch) (12/17/85)
The appended message was sent to me by philabs, indicating a
problem sending a message to tektronix. I can't tell from the header
why it was routed to philabs from ihnp4, since it doesn't appear in the path.
The path was the one produced by pathalias for our site.
I deal mostly with ARPA stuff and don't really understand how the UUCP
mailer at ihnp4 does things, but I don't know how a message addressed
to idi!nsc!ihnp4!tektronix!orca!raynor ended up going from ihnp4 to
philabs, who dropped it on the floor. Can anyone shed light on this?
Michael C. Berch
ARPA: mcb@lll-tis-b.ARPA
UUCP: {akgua,allegra,cbosgd,decwrl,dual,ihnp4,sun}!idi!styx!mcb
-----(begin appended message)-----
>From idi!cbosgd!ihnp4!floyd!philabs!MAILER-DAEMON Mon Dec 16 09:02:21 1985
Received: by lll-tis-b.ARPA; Mon, 16 Dec 85 09:02:18 pst
Received: by ihnp4.ATT.UUCP id AA15974; 16 Dec 85 08:49:45 CST (Mon)
Received: by philabs.uucp (4.12/3.14)
id AA10984; Mon, 16 Dec 85 09:26:52 est
Date: Sun, 15 Dec 85 20:57:59 pst
From: Mail Delivery Subsystem <ihnp4!philabs!MAILER-DAEMON>
Subject: Returned mail: Host unknown
Return-Path: <philabs!MAILER-DAEMON>
Message-Id: <8512161426.AA10984@philabs.uucp>
To: idi!styx!mcb
Status: RO
----- Transcript of session follows -----
bad system name: tektron
uux failed. code 68
550 tektronix!orca!raynor... Host unknown
----- Unsent message follows -----
Received: by philabs.uucp (4.12/3.14)
id AA10972; Mon, 16 Dec 85 09:26:52 est
Received: by ihnp4.ATT.UUCP id AA03670; 16 Dec 85 04:02:06 CST (Mon)
Received: by nsc.UUCP (4.12/4.7)
id AA26918; Sun, 15 Dec 85 22:24:35 pst
Received: by lll-tis-b.ARPA; Sun, 15 Dec 85 20:57:59 pst
Date: Sun, 15 Dec 85 20:57:59 pst
>From: Michael C. Berch <ihnp4!nsc!styx!mcb>
Message-Id: <8512160457.AA27770@lll-tis-b.ARPA>
To: idi!nsc!ihnp4!tektronix!orca!raynor
Subject: Re: Call for action on an Alternative to the Nuclear Dilemma
Newsgroups: net.general
In-Reply-To: <1957@orca.UUCP>
Organization: Lawrence Livermore Laboratory, Livermore CA
Cc:
Please keep political tracts and requests for funds out of
net.general. It is not an appropriate forum, regardless of the
importance or urgency of the cause. Thanks in advance.
Michael C. Berch
ARPA: mcb@lll-tis-b.ARPA
UUCP: {akgua,allegra,cbosgd,decwrl,dual,ihnp4,sun}!idi!styx!mcb
-----(end appended message)-----chuq@sun.uucp (Chuq Von Rospach) (12/17/85)
> The appended message was sent to me by philabs, indicating a > problem sending a message to tektronix. I can't tell from the header > why it was routed to philabs from ihnp4, since it doesn't appear in the path. > The path was the one produced by pathalias for our site. > > I deal mostly with ARPA stuff and don't really understand how the UUCP > mailer at ihnp4 does things, but I don't know how a message addressed > to idi!nsc!ihnp4!tektronix!orca!raynor ended up going from ihnp4 to > philabs, who dropped it on the floor. Can anyone shed light on this? ihnp4 uses pathalias (or a variant of it) to do routing. Unfortunately, they seem to be getting more and more confused over time, with innnacurate or inefficient routes being generated. Every so often, ihnp4 used to believe that the fastest route to nsc was ihnp4!cbosgd!nsc even though nsc talked directly to them. Now, from my mail, it seems to think that ihnp4!cbosgd!sun is the fastest route to sun, even though sun talks to ihnp4... sigh. It looks like somehow ihnp4 has decided the fastest route to tek is through philabs. Perhaps philabs used to talk to tek and the map ihnp4 is using is bogus... chuq -- :From catacombs of Castle Tarot: Chuq Von Rospach sun!chuq@decwrl.DEC.COM {hplabs,ihnp4,nsc,pyramid}!sun!chuq Power ennobles. Absolute power ennobles absolutely.
robert@fear.UUCP (Robert Plamondon) (12/18/85)
>> The appended message was sent to me by philabs, indicating a >> problem sending a message to tektronix. I can't tell from the header >> why it was routed to philabs from ihnp4, since it doesn't appear in >> the path. In article <3080@sun.uucp>, chuq@sun.uucp (Chuq Von Rospach) writes: > ihnp4 uses pathalias (or a variant of it) to do routing. > Unfortunately, they seem to be getting more and more confused over > time, with innnacurate or inefficient routes being generated. Every > so often, ihnp4 used to believe that the fastest route to nsc was > ihnp4!cbosgd!nsc even though nsc talked directly to them. Now, from > my mail, it seems to think that ihnp4!cbosgd!sun is the fastest route > to sun, even though sun talks to ihnp4... sigh. The main problem here is a failure on the part of ihnp4's mail administration to appreciate the rule, "If it ain't broke, don't fix it." They set up their mail software to take a perfectly acceptable, efficient mail route, and perform a series of changes on it that made it undeliverable. Why? While I sympathize with ihnp4's mail volume, and the perceived need to optimize the ridiculous return paths generated by news, their implementation is crude and excessive. Besides keeping their pathalias files up to date, I would suggest that sites that like to play with other people's routings adhere to guidelines like this: 1. If the path is less than five hops long, don't optimize it. 2. If the "cost" from pathalias isn't at least twice as good as the original path, don't optimize it. This way, users who know what they're doing can avoid being screwed over by so-called "smart" mailers. On the WEITEK machines, we don't have the volume problems that ihnp4 has, so we just run uumail as posted on the net. The beauty of uumail is that it only looks for the optimum path to the first hop in the address, so when presented with a complete path, it does no optimization at all. -- Robert Plamondon UUCP: {turtlevax, resonex, cae780}!weitek!robert FidoNet: 10/624 robert plamondon Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site sdcrdcf.UUCP Posting-Version: version B 2.10.3 alpha 4/15/85; site fear.UUCP Path: sdcrdcf!sdcsvax!dcdwest!ittatc!decvax!decwrl!pyramid!pesnta!amd!amdcad!cae780!weitek!fear!robert From: robert@fear.UUCP (Robert Plamondon) Newsgroups: net.mail Subject: Re: Mail problem, ihnp4 -> tektronix Message-ID: <313@fear.UUCP> Date: 18 Dec 85 01:03:39 GMT Date-Received: 19 Dec 85 10:10:38 GMT References: <17623@styx.UUCP> <3080@sun.uucp> Distribution: net Organization: Weitek Corp. Sunnyvale Ca. Lines: 47 Summary: If it works, don't fix it >> The appended message was sent to me by philabs, indicating a >> problem sending a message to tektronix. I can't tell from the header >> why it was routed to philabs from ihnp4, since it doesn't appear in >> the path. In article <3080@sun.uucp>, chuq@sun.uucp (Chuq Von Rospach) writes: > ihnp4 uses pathalias (or a variant of it) to do routing. > Unfortunately, they seem to be getting more and more confused over > time, with innnacurate or inefficient routes being generated. Every > so often, ihnp4 used to believe that the fastest route to nsc was > ihnp4!cbosgd!nsc even though nsc talked directly to them. Now, from > my mail, it seems to think that ihnp4!cbosgd!sun is the fastest route > to sun, even though sun talks to ihnp4... sigh. The main problem here is a failure on the part of ihnp4's mail administration to appreciate the rule, "If it ain't broke, don't fix it." They set up their mail software to take a perfectly acceptable, efficient mail route, and perform a series of changes on it that made it undeliverable. Why? While I sympathize with ihnp4's mail volume, and the perceived need to optimize the ridiculous return paths generated by news, their implementation is crude and excessive. Besides keeping their pathalias files up to date, I would suggest that sites that like to play with other people's routings adhere to guidelines like this: 1. If the path is less than five hops long, don't optimize it. 2. If the "cost" from pathalias isn't at least twice as good as the original path, don't optimize it. This way, users who know what they're doing can avoid being screwed over by so-called "smart" mailers. On the WEITEK machines, we don't have the volume problems that ihnp4 has, so we just run uumail as posted on the net. The beauty of uumail is that it only looks for the optimum path to the first hop in the address, so when presented with a complete path, it does no optimization at all. -- Robert Plamondon UUCP: {turtlevax, resonex, cae780}!weitek!robert FidoNet: 10/624 robert plamondon
honey@down.FUN (Peter Honeyman) (12/18/85)
this is what happens when intermediates reroute mail. ihnp4 believes the route to tektronix is cheaper if it goes through philabs. unfortunately, philabs doesn't talk to tektronix any more. i wish ihnp4 understood what source routing means. peter
gjm@packard.UUCP (Gary J. Murakami) (12/19/85)
It turns out that ihnp4 has a syntax error somewhere in its pathalias input which is causing major routing anomalies (I've seen this before when a machine signed up with a dot "." in its name). I'm sorry that I no longer baby-sit ihnp4, but I am trying to fix the routing problem now that it has been brought to my attention. Poor ihnp4 is so overloaded that I'm having trouble getting cycles to fix the problem (even nice --20 only helps a little). Peter... I'm willing to look at the new (better) pathalias and pathparse as soon as you (want to) give it to me. -Gary
gds@mit-eddie.UUCP (Greg Skinner) (12/19/85)
Perhaps Gary Murakami or Peter Honeyman would like to expand on this, but I think I can shed some light on the problem. The Sys V version of pathalias generates a long table of paths with their associated costs. > ihnp4 uses pathalias (or a variant of it) to do routing. Unfortunately, they > seem to be getting more and more confused over time, with innnacurate or > inefficient routes being generated. Every so often, ihnp4 used to > believe that the fastest route to nsc was ihnp4!cbosgd!nsc even though > nsc talked directly to them. Now, from my mail, it seems to think that > ihnp4!cbosgd!sun is the fastest route to sun, even though sun talks to > ihnp4 ... sigh. As I recall, the cost of ihnp4<->cbosgd is cheaper than ihnp4<->nsc since the phone call (if it even is a phone call anymore -- it might be datakit) is cheaper (cornet) even though the actual rate might be DEMAND. Therefore, cbosgd appears first in the table. The map data at ihnp4 may reflect a very low cost from cbosgd<->nsc which may be even less than that of ihnp4<->nsc so the ihnp4<->nsc entry never gets in the table. I remember running into a similar problem when I brought pathalias up on houxm and I was trying to force mail to go to the ARPA Internet through uucp links to an ARPAnet site. Pathalias insisted that I take some long route through cbosgd and ucbvax to get there. What I did was after pathalias generated the table I set the value of my ARPAnet gateway to less than that of cbosgd, so that it would always be favored. Probably to get the desired paths you want to have you will have to modify the UUCP maps to reflect that your own site has a cheaper direct route than DEMAND. Unfortunately this has the bad side-effect of favoring harvard for uucp sites which it is connected to which I might have cheaper routes to. Who's in charge of ihnp4 now? A quickie solution is to delete the table entry for cbosgd!nsc and set the cost of nsc to that of any other DEMAND site, which is what you want. -- It's like a jungle sometimes, it makes me wonder how I keep from goin' under. Greg Skinner (gregbo) {decvax!genrad, allegra, ihnp4}!mit-eddie!gds gds@mit-eddie.mit.edu
joel@gould9.UUCP (Joel West) (12/20/85)
> The main problem here is a failure on the part of ihnp4's mail > administration to appreciate the rule, "If it ain't broke, don't fix > it." > > While I sympathize with ihnp4's mail volume, and the perceived need > to optimize the ridiculous return paths generated by news, their > implementation is crude and excessive. > > On the WEITEK machines, we don't have the volume problems that ihnp4 > has, so we just run uumail as posted on the net. The beauty of uumail > is that it only looks for the optimum path to the first hop in the > address, so when presented with a complete path, it does no > optimization at all. But this (rewriting path to adjacent site) is exactly what some (e.g., Chuqui) complain about. If you run a site with connections to a large number of sites (our 30 are a lot to support on one ACU) you begin to appreciate ihnp4's plight. In particular, if you have one message for each of hplabs nsc sun ucbvax every hour, you can't afford to deliver each message manually. If all these machines in the Bay Area are inter-connected, you're much better off routing all mail to the one machine you have the most traffic to and is reliable (say hplabs, for purposes of argument) and then let it re-deliver the other mail. The less connections you have to make in an hour, the more you can concentrate on getting through to those you want to make. Without such a management plan, you might be limited to making one retry a day, and BOY, would that piss people off. But because of naming ambiguities in the net, and the onstant state of flux for reliable connections, I would only run aliasing to "known sites", such as my immediate neighbors. Under this theory, ucbvax!hplabs would become "hplabs" but "ucbvax" would become "hplabs!ucbvax". In short, put all your eggs in a few baskets, and then WATCH THOSE BASKETS. (Needless to say, if no one does, the whole plan falls apart). -- Joel West (619) 457-9681 CACI, Inc. Federal, 3344 N. Torrey Pines Ct., La Jolla, CA 92037 {cbosgd,ihnp4,pyramid,sdcsvax,ucla-cs}!gould9!joel gould9!joel@nosc.ARPA
gjm@packard.UUCP (Gary J. Murakami) (01/04/86)
The problem on ihnp4 turned out to be an error in the pathalias input. Most of the administration on ihnp4 is semi-automated, including the generation of its own pathalias data. Unfortunately it didn't check the syntax of the input data sufficiently. I fixed this last week, and paths should now be sane. I'm sorry that I can non longer baby-sit the system and that service is suffering. I still try to be responsive to problems, but I still have only 24 hours in a day like everyone else... -Gary