cpw%sneezy@LANL.GOV (C. Philip Wood) (01/06/88)
LANL is used by a number of folks on (or with access to) the Internet. When they cannot 'telnet' to our hosts here, they start calling us up and telling us how to do our job. So far, none of the suggestions have been very appealing. The current problem causing some users grief manifests itself as follows: 1. A user on GWUVM.GWU.EDU attempts to telnet to MILNET-GW.LANL.GOV. 2. The connection times out. 3. The user is pissed and calls us up. I have tried various things on our end to find out what is going on. Here are the things I found out when the problem was first reported: 1. I could talk to GWUVM.GWU.EDU from our subnets but not directly from MILNET-GW.LANL.GOV. This made absolutely no sense. 2. I sent 100 ICMP ECHO request's from MILNET-GW.LANL.GOV and 100 reply's were received. But, of the 100 reply's received about 20% had DUPLICATE SEQUENCE NUMBERS! I was getting curious. 3. I sent a more sophisticated ICMP ECHO packet with out much hope of a response. This one is coded up with the IP RECORD ROUTE option. Some hosts on the Internet actually respond to these, like our 4.3BSD hosts (a local modification), and A.ISI.EDU. I wish others would. Low and Behold, back came the following IP header and option: x00: x4f001400 IP header x04: x86450000 " x08: x11010000 " x0c: x80a401ea IP source GWU-GATE host GWUVM.GWU.EDU x10: x1a00005a IP destination MILNET host MILNET-GW.LANL.GOV x14: x01072728 IP option field NOP | RR option header x18: x80080a0e The UMDNET host TRANTOR.UMD.EDU x1c: x81020101 route UMD-BOGON-NET host 129.2.1.1 x20: x80a70101 traversed SURA host 128.167.1.1 x24: x80a70201 as SURA host 128.167.2.1 x28: x80a70102 far SURA host 128.167.1.2 x2c: x80a72101 as SURA host 128.167.33.1 x30: x80a72101 allowed SURA host 128.167.33.1 x34: x80a72101 by SURA host 128.167.33.1 x38: x80a72101 option. SURA host 128.167.33.1 Unfortunately, thats all you get in an IP option. So, what's going on? For sure, if a packet has to hop around in the SURA network before it (goes to/comes from) GWU-GATE, its going to take some time. Maybe get lost? Maybe get duplicated? What kind of network media/link levels do packets traverse here? I want to make sure that LANL doesn't acquire (as in purchase) any hardware/protocols that behave as above. Maybe we already have. Yikes! Phil Wood (cpw@lanl.gov)
steve@NOTE.NSF.GOV (Stephen Wolff) (01/07/88)
You're being misled by one of the technical differences between SURANET and MILNET. GWUVM is a host (128.164.1.234) on one of the campus networks (128.164) connected via SURANET (128.167) to the rest of the Internet. SURANET, like most (but not all) mid-level nets in the NSFNET, is composed of IP routers (in SURANET'S case, Proteon P4200s) linked together by serial lines. What Record Route is showing you is the packet traveling from 128.167.33.1 - presumably the GWU_campus_net-to-SURANET P4200 gateway at GWU - (but why it spent so much time there I don't understand) to 128.167.11.2 - the next P4200 (which happens to be at NSF) - to the principal node of SURANET at University of Maryland, College Park, where it is loaded onto MILNET. That is in fact the most direct route there is. Thereafter, there is quite possibly as much "hopping around" on the packet's way to LANL via MILNET, but because MILNET uses a distinct communications subnet (based on the PSNs) that operates below the IP level, that's all invisible to Record Route. I.e., since P4200s are gateways as well as packet switches, each has a "host" number and so leaves a fewmet for Record Route, but Record Route can't see the MILNET packet switches. From just behind the SURANET gateway at NSF, I see RTTs of 1500 ms or so to MILNET-GW.LANL.GOV; this seems totally unreasonable. Perhaps there is congestion at the UMd gateway to MILNET which, combined with the suspect behavior of the SURANET gateway at GWU, might cause your users' connections to time out. I suspect the SURANET folks are conducting their own investigation and we'll hear from them in due course... -s
steve@BRILLIG.UMD.EDU (Steve D. Miller) (01/08/88)
Subject: Re: MILNET/?/UMDNET/SURA/GWU-GATE traffic question From: Stephen Wolff <steve@note.nsf.gov> What Record Route is showing you is the packet traveling from 128.167.33.1 - presumably the GWU_campus_net-to-SURANET P4200 gateway at GWU - (but why it spent so much time there I don't understand) to 128.167.11.2 - the next P4200 (which happens to be at NSF) - to the principal node of SURANET at University of Maryland, College Park, where it is loaded onto MILNET. That is in fact the most direct route there is. Indeed, that is the most direct route there is. However, one of the restrictions under which we at UMCP operate is that we can never ever forward packets from ARPANET, NSFNET, SURANET, et al. directly to MILNET. (Otherwise, we'd effectively be a mailbridge.) The only packets that can cross our MILNET gateway are those with an IP source address on network 128.8. (There is a hack in the kernel on maryland-gw.arpa (a 4.3BSD host) that enforces this restriction.) A quick peek at the UMCP ARPANET gateways tells me that they're routing MILNET traffic via DCEC-MILNET-GW.ARPA, at least for the moment. I don't have access to the UMCP SURANET gateways, so I don't know exactly what they want to do with MILNET traffic, but I assume they send it to the ARPANET gateways. If someone from SURANET is reading this, and could check the routing, that would be good... -Steve Spoken: Steve Miller Domain: steve@mimsy.umd.edu UUCP: uunet!mimsy!steve Phone: +1-301-454-1808 USPS: UMIACS, Univ. of Maryland, College Park, MD 20742
hans@umd5.umd.edu (Hans Breitenlohner) (01/14/88)
This is an attempt to explain some of the strangeness which was reported
in and around SURA-net land.
As far as I can tell from the fragments of information, the packet
traversed the following path:
milnet-gw.lanl.gov 26.0.0.90
Milnet ???
some milnet to arpa gateway
Arpanet 56 kb serial
umd.umd.edu/trantor.umd.edu 10.8.0.20/128.8.10.14
UMD subnet 128.8.10 Ether
bogon-gw.umd.edu 128.8.10.41/129.2.1.1
UMD-BOGON-NET 129.2 Ether
sura1 gateway at U of Md 129.2.1.2/128.167.1.1
SURA subnet 128.167.1 Ether
sura2 gateway at U of Md 128.167.1.2/128.167.2.1
SURA subnet 128.167.2 56 kb serial
sura gateway at George Washington 128.167.2.2/128.164.1.1
GWU campus net Ether
gwuvm.gwu.edu 128.164.1.234
>
> so far, so good
>
GWU campus net Ether
sura gateway at GWU 128.164.1.1/128.167.2.2
SURA subnet 128.167.2 56 kb serial
sura2 gateway at U of Md 128.167.2.1/128.167.1.2
SURA subnet 128.167.1 Ether
sura1 gateway at U of Md 128.167.1.1/128.167.33.1
SURA subnet 128.167.33 56 kb serial
sura gateway at NRL 128.167.33.2
SURA subnet 128.167.33 56 kb serial
sura1 gateway at U of Md 128.167.33.1
>
> and so on, ad infinitum (or nearly so) between sura1 and sura-NRL.
>
Trantor is a Vax running 4.3 BSD. Bogon-gw, sura1 and sura2 are Proteon
p4200 routers running release 7.4 of their software, which honors the
'record route' option. The remaining sura gateways are Proteon p4200
routers running release 7.3 of their software, which ignores the 'record route'
option. This shows the usefulness of this IP option, and makes us wish more
software packages would honor it.
The following is educated guesswork, since I never got to see things in this
state, and since I do not have access to gateways outside the University of
Maryland. Apparently the gateway at NRL was advertising net 26 reachability
with a small hop count. There was a static route configured in it,
and routing and advertising are not easily separated in that software.
This is a bad situation at any time, and for several reasons. Apparently
it was aggravated by local Ethernet problems at NRL, which caused the gateway
to decide that the Ethernet was down, and send the packet to its default
network gateway, which was pointing back to sura1 at U of Md.
The fact that the packet arrived at all is likely a result of NRL's ethernet
problems being transient, or of the fact that the routing information between
the two gateways got straightened out and the packet was returned along the
route by which it was sent out. Since no date/time was given with the
problem report it is hard to verify any of this.
This seems adequate to explain the extraordinary delays and the packet loss
reported. I am at a loss to explain the duplicated packets. Perhaps someone
else can help out with that.
The problem has been resolved, and traffic between SURA-net and Milnet should
perform much better now. The sura1 gateway will no longer believe
net 26 advertisements from NRL, and I understand that the static route will
also be removed from the gateway there. Ironically this is a leftover from
past attempts by various other groups to confine Milnet traffic to their
local connections.
Thanks to cpw for reporting the problem and providing useful information.
In a case like this, where the problem was clearly confined to one net
(128.167) it would likely be faster and more effective to contact the
administrator of the net in question directly. The necessary information
can be obtained using the 'whois' utility (as in 'whois 128.167.0.0').
For more information on it and other services provided by the NIC you might
want to get a copy of "DDN NEW USER GUIDE", Publication # NIC 50001. If you
can not get it through your network administrator, use the NIC's toll free
phone number 800-235-3155 to order one.