info-vax@ucbvax.ARPA (10/11/84)
From: Ron Tencati <TENCATI@JPL-VLSI.ARPA> I seem to be having problems with my routing table entries. Does anyone know of any software that I can get my hands on that will let me "ping" gateways? We run the Kashtan 4.1c IP kernel under VMS 3.6. It sure would be nice if we could get rid of these annoying "network unreachable" messages... I need a way to verify that packets are making it to their destination. We need existing software, we don't have the technology to write our own. Thanks in advance for any help. Ron ------
info-vax@ucbvax.ARPA (10/11/84)
From: Rudy.Nedved@CMU-CS-A.ARPA You don't want to ping anything...all you do is clogg up the network if everyone uses your solution. The best bet is to wait for the BBN core gateways to get the "last bug" fixed where they forget about little networks like MILNET. They seem to do a pretty good job... ...is it possible that you have te version of VMS software that does not have a default gateway and you have to specify for each network a gateway? Maybe this is the problem...we had this problem and we got errors like "network unreachable" or something. At the moment, TOPS-20/TENEX BBN code has pinging in it for PRIME gateways...for one site this caused their connected IMP to "freeze" every so many minutes because the PING code was sending a massive number of PINGs to a large number of gateways (of course the problem was also one of incorrect "channel" usage and can sort of be avoided). All and all PINGs by non-gateway hosts is a bad idea...especially for them poor 9600 and 1200 baud links some folks (like us) have. -Rudy
info-vax@ucbvax.ARPA (10/11/84)
From: Paul Milazzo <milazzo@rice.ARPA> Rudy: What Ron meant was that he wants a program with which can manually send out pings and look for responses. He is interested in using such a program as a manual diagnostic aid for connectivity analysis, not part of his standard operating procedure. I'm sure that by now we're all aware that pinging in the TOPS-20 sense is a bad idea. Incidentally, the particular problem Ron wishes to diagnose is why, after correcting his routing information, we (Rice) can connect to JPL-VLSI, but JPL-VLSI can't open connections to us at either our CSNET-PDN or RICE-NET address. I've never seen this sort of asymmetric behavior in a TCP/IP. Does anyone out there have any ideas? Paul G. Milazzo <milazzo@rice.ARPA> Dept. of Computer Science Rice University, Houston, TX
info-vax@ucbvax.ARPA (10/11/84)
From: Rudy.Nedved@CMU-CS-A.ARPA Well. Yesterday CMU-Gateway stop getting routing updates for MILNET from the core gateway that we get information from for about 4 hours. The result was that CMU-CS-A (ARPANET) could not talk to CMU-CS-B (MILNET) but CMU-CS-B could talk to CMU-CS-A. The subtle difference (I believe) is that the TOPS-10 code will use the IMP/port information it keeps on active connection when sending a response....and uses its assigned gateway when it initiates a connection. Given that if you give a packet to a one of your two assigned ARPANET/MILNET gateways...it tends to deliver it even though the core gateways don't tell anyone else about its delivery ability. I don't like the situation and wish there were "fixes" but one must recognize that the "growth" of the Internet structure has been like an explosion...kinda of unexpected....the core gateways and other gateways are having a problem dealing with the information (that is why I like the concept of hiding as much internal network structure as possible from external gateways). -Rudy
info-vax@ucbvax.ARPA (10/12/84)
From: Martin Fouts <fouts@AMES-NAS-GW.ARPA>
I don't have an idea, but I've got related problems. We have
three vaxes here using the same MILNET Imp. The VMS host can get
through to SRI-UNIX without problems. Both of the 4.2BSD vaxes are LAN
gateways and running Kirton's EGP implementation. One of the 4.2BSD
nodes can get through to SRI-UNIX, but nodes on its LAN can't. The
other one can't get through at all.
The error message is "connection timed out" in either case.
Anybody got any ideas?
----------info-vax@ucbvax.ARPA (10/12/84)
From: Mike Muuss <mike@BRL-TGR.ARPA> For 4.2 BSD, BRL has a program called "ping", which allows you to measure connectivity, round trip time, and packet loss. Source is availible on BRL-VGR and BRL-TGR via anonymous FTP. We also have in development a program to make sure that the "default route" is working, and to switch among a set of them in event of failure. We will probably put this program into production in a week, and will distribute in November. -Mike
info-vax@ucbvax.ARPA (10/12/84)
From: Dan Grim <grim@udel-ee> We saw exactly the same behavior here at Delaware when machines on two separate local nets could not connect in one direction when they could in the other. Our problem turned out to be that one of our multiply connected machines (arpa and local ethernet) was sending its arpa internet address as the source address in the IP packets and the machine on the other local net apparently had the wrong routes installed to reply. That machine could reach other arpa hosts however so it is not as simple a problem as it may seem. The outcome is that routing on intermediate hosts seemed to be able to cause the assymetric behavior. Dan Grim <Grim@UDel> Dept of Electrical Engineering University of Delaware
info-vax@ucbvax.ARPA (10/17/84)
From: Ron Tencati <TENCATI@JPL-VLSI.ARPA> Since it was I that made the original request for software to "ping" a gateway, I should respond to the inquiry as to what a "ping" is so everyone will know what I was asking. I am not a technical person at all. As I understood it, you run some program and tell it the net-address of a gateway (or host) that you wanted to check yourconnection to. The software would then send some number of packets out to that address and wait for some to return. After some length of time, it would print a summary of timing delays and packets sent/recieved which would implicitly tell you that you could in fact make a connection to that address. I need that information to check out my routing tables so I can be sure that all my routes are valid. I am still not sure. I admit that this information is probably wrong, but wrong as it may be, it was the basis for my previous question. I understand that it is not a good idea to "ping" anything since all it does is flood the net with packets, and if every one pinged, there would be no traffic getting through.... but what about my route tables? I could still use some advice... Ron Tencati TENCATI@JPL-VLSI ------