emv@mailrus.cc.umich.edu (Edward Vielmetti) (10/02/88)
(debugging paths is a pain.) There's a bug in the d.usa.fl.1 map entry of ucf-cs w/regard to the domain description of UCF.EDU. It causes some of my paths to Florida to bounce through New York City. In particular, ucf-cs mailrus!rutgers!cmcl2!phri!pluto!ucf-cs The problem is that "pluto.ucf.edu" in the ucf-cs map collides with a 1987 map for "pluto" in u.usa.ny.3. The ucf "pluto" is apparently on a local network with "ucf-cs", hence the confusion. An interesting exercise would be to send mail to rutgers!pluto!postmaster and see which is the "real" machine. Since I don't know which map coordinators are involved in this it was easiest to post. There's yet another pluto in the map entry of "mscunx" in u.usa.mn.1, I suspect it's even different from the other two. (I submit that active rerouting is bad for everyone on the net except rutgers, and only since rutgers controls the maps.)
roy@phri.UUCP (Roy Smith) (10/02/88)
emv@mailrus.cc.umich.edu (Edward Vielmetti) writes: > ucf-cs mailrus!rutgers!cmcl2!phri!pluto!ucf-cs > > The problem is that "pluto.ucf.edu" in the ucf-cs map > collides with a 1987 map for "pluto" in u.usa.ny.3. As far as I know, the u.usa.ny.3 pluto is dead, and has been for some time. Certainly, we havn't been able to get through to them for a while. In fact, I see that they are no longer in our L.sys file (hence the path fragment phri!pluto should result in bounced mail) nor our most recent map entry (so unless people are working with out-dated maps, there shouldn't be any re-routing of plutomail through us). -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network"
clarke@acheron.UUCP (Ed Clarke) (10/02/88)
From article <731@mailrus.cc.umich.edu>, by emv@mailrus.cc.umich.edu (Edward Vielmetti): > There's a bug in the d.usa.fl.1 map entry of ucf-cs w/regard to the > domain description of UCF.EDU. It causes some of my paths to > Florida to bounce through New York City. In particular, > > ucf-cs mailrus!rutgers!cmcl2!phri!pluto!ucf-cs > > The problem is that "pluto.ucf.edu" in the ucf-cs map > collides with a 1987 map for "pluto" in u.usa.ny.3. > The ucf "pluto" is apparently on a local network with > "ucf-cs", hence the confusion. A quick look through the maps shows at least three 'pluto' machines. There are two lan connected machines - one at the Universito of Central Florida ( the one you want ), and one at the University of Toronto. A third machine is only uucp connected and is not part of a domain. None of these three machines conflict if you use 'smail' (2.5). You just have to fully qualify the addresses: smail -A person@pluto uunet!hombre!phri!pluto!person smail -A person@pluto.ucf.edu uunet!steinmetz!ge-dab!ucf-cs!pluto.ucf.edu!person smail -A person@pluto.decnet.toronto.edu uunet!utai!pluto.decnet.toronto.edu!person I know it's a pain, but this is the way mail is headed. You're going to have to fully qualify your destination. As a side note, I'm not sure what would happen if I registered a machine as uunet.COM ( besides having everyone on the net form a lynch mob ). I have a feeling that most map entries for uunet are technically WRONG - and should be of the form "uunet.uu.net(DEMAND)" rather than "uunet(DEMAND)". This is only a horrible example - I'm sure no map coordinator would permit it. But what about 'pluto'? I have a route through SOME pluto to 'hp'. And it's wrong. smail -A person@hp uunet!hombre!phri!pluto!hp!person This should have routed through 'pluto.ucf.edu'. Ed Clarke uunet!bywater!acheron!clarke -- Ed Clarke uunet!bywater!acheron!clarke
page@swan.ulowell.edu (Bob Page) (10/04/88)
It's worse that that - since ucf-cs talks to pluto, and hp is on that same ethernet (surprise to the folks at Hewlett-Packard), mail to hp!user will not only not get to H-P, it won't even get to pluto, since phri doesn't talk to it. This is just one example of the state of the maps. Tell me quick: how to I get to csab? ipac? usafa? vice? viper? Are you sure? Take usafa for example. Not registered, but listed by three sites: u.usa.co.1:winfree usafa(WEEKLY) u.usa.fl.1:gould usafa(HOURLY*4) u.usa.nh.1:trixie usafa(HOURLY) These sites aren't exactly 'close'. Are these all the same machine? How can anyone know? Can I get from trixie to gould through usafa? (yes, I know trixie talks to gould) At least we can infer viper is in Minnesota, with five (5) sites listing it in their maps. It's not registered though. If machines can't correctly route to with the published map data, there's no way they can reroute when you add the unpublished hosts. [Would you believe we talk to a pluto via uucp?] ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page
jbuck@epimass.EPI.COM (Joe Buck) (10/05/88)
In article <248@acheron.UUCP> clarke@acheron.UUCP (Ed Clarke) writes: >As a side note, I'm not sure what would happen if I registered a >machine as uunet.COM ( besides having everyone on the net form a >lynch mob ). I have a feeling that most map entries for uunet are >technically WRONG - and should be of the form "uunet.uu.net(DEMAND)" >rather than "uunet(DEMAND)". No, they are not wrong. For purposes of UUCP mail, uunet without qualification means uunet.uu.net; the map entries are right. Mail to your hypothetical machine uunet.com would have to be fully qualified, but not mail to uunet, since they own the UUCP name (by having it registered on the UUCP map). -- - Joe Buck, card-carrying ACLU liberal jbuck@epimass.epi.com, or uunet!epimass.epi.com!jbuck, or jbuck%epimass.epi.com@uunet.uu.net for old Arpa sites
brianr@rosevax.Rosemount.COM (Brian E. Richter) (10/07/88)
From article <731@mailrus.cc.umich.edu>, by emv@mailrus.cc.umich.edu (Edward Vielmetti): > There's yet another pluto in the map entry of "mscunx" > in u.usa.mn.1, I suspect it's even different from the > other two. I will check into this one, unfortunately the folks at mscunx have just gone through an upgrade so it may be while before I find out about thier entry. Brian E. Richter | Domain: brianr@rosevax.rosemount.com Rosemount Inc. | UUCP: uunet!rosevax!brianr 12001 Technology Drive | Tel: +1 612 828 3941 Eden Prairie, Mn 55344 | ?.usa.mn.1 map coordinator -- Brian E. Richter | Domain: brianr@rosevax.rosemount.com Rosemount Inc. | UUCP: uunet!rosevax!brianr 12001 Technology Drive | Tel: +1 612 828 3941 Eden Prairie, Mn 55344 | ?.usa.mn.1 map coordinator