gaspar@STL-08SIMA.ARMY.MIL (Al Gaspar) (11/29/90)
I'm not sure that this actually belongs in this group, but, since we have an cisco AGS gateway, it seemed a good place to start. For some time now (a couple of years), we have had an AGS gateway with one ethernet board (our software is currently at 8.1(19)). It's Internet address is 192.35.148.1. Off of this gateway we have some Unisys 5000/95s running SysV.3 from Unisys, a Vax 780 (on its way out) running 4.3 bsd from mt. xinu, and some Sun products running 4.03 SunOs. These machines are all set up to let the AGS handle their routing. These machines have generally good connectivity to the ethernet (though the bsd and SunOs software seems a bit more reliable than NET-5000 on the Unisys machines). Recently we added another ethernet board to our AGS gateway. Its address is 192.70.191.1. Off of this ethernet we have hung two SPARCstation 1+s running SunOs 4.1 (192.70.191.2 & 3) and one cisco STS-10X terminal server (192.70.191.4). These machines are also set up to let the AGS handle their routing. However, these machines cannot reach and cannot be reached (using ping and traceroute) by any machines outside of the milnet. The only exception that I have found to this is that I can (very) occasionally reach jpl-devvax.jpl.nasa.gov (128.149.1.143) and a couple of the other machines 128.149.1.xxx machines. However, when I can reach these machines, traceroute shows the addresses up to and including the milnet gateway at moffett.mt.ddn.mil (26.0.0.16); after that it shows all *'s until it hits the destination machine. If I run traceroute off the AGS itself, I get addresses all the way. The Defense Communications Agency (DCA) has told us that this may be the result of some flaky mail gateways on the NSFNET maintained by BBN. The explanation given is that when these gateways hickup they destroy all of the dynamic routing to the milnet and, therefore, only those sites that are in static tables can reach outside of the milnet and vice versa. Since our first ethernet address has been around awhile it presumably is in many static tables. DCA also tells us that BBN knows of the problem, but that a fix has a very low priority. I am wondering whether this explanation sounds plausible. Are there any other possibilities that I might explore? Any help or suggestions will be greatly appreciated. The current situation is a pain... Thanks-- Al -- Al Gaspar <gaspar@stl-08sima.army.mil> USAMC SIMA, ATTN: AMXSI-TTC, 1222 Spruce St., St. Louis, MO 63103-2834 COMMERCIAL: (314) 331-4354 AUTOVON: 555-4354 uunet.uu.net!stl-08sima.army.mil!gaspar
fair@apple.com (Your Friendly Postmaster) (11/29/90)
The DDN management bulletin had a notice about this recently. Basically, if you're on MILNET, you're hosed. I was once a MILNET liaison at LLNL in 1986; I doubt much has changed since then... Erik E. Fair apple!fair fair@apple.com
long@nic.near.net (Daniel Long) (11/30/90)
From: Al Gaspar <gaspar@stl-08sima.army.mil> Subject: Internet Problems Date: Wed, 28 Nov 90 08:45:20 CST I'm not sure that this actually belongs in this group, but, since we have an cisco AGS gateway, it seemed a good place to start. Probably the tcp-ip@nic.ddn.mil would be a good place for this kind of question. Recently we added another ethernet board to our AGS gateway. Its address is 192.70.191.1. Off of this ethernet we have hung two SPARCstation 1+s running SunOs 4.1 (192.70.191.2 & 3) and one cisco STS-10X terminal server (192.70.191.4). These machines are also set up to let the AGS handle their routing. However, these machines cannot reach and cannot be reached (using ping and traceroute) by any machines outside of the milnet. The only exception that I have found to this is that I can (very) occasionally reach jpl-devvax.jpl.nasa.gov (128.149.1.143) and a couple of the other machines 128.149.1.xxx machines. However, when I can reach these machines, traceroute shows the addresses up to and including the milnet gateway at moffett.mt.ddn.mil (26.0.0.16); after that it shows all *'s until it hits the destination machine. If I run traceroute off the AGS itself, I get addresses all the way. The trick here is that NSFNET keeps a database of networks it knows about. Your old network (192.35.148) is in that database. Your new network is not. You need to fill out an Internet Number Template available from NIC.DDN.MIL as file: NETINFO:INTERNET-NUMBER-TEMPLATE.TXT. In this template, question 4 asks whether you want your network to be advertised to NSFNET (i.e. added to the NSFNET database). Contact HOSTMASTER@NIC.DDN.MIL for more information. The Defense Communications Agency (DCA) has told us that this may be the result of some flaky mail gateways on the NSFNET maintained by BBN. The explanation given is that when these gateways hickup they destroy all of the dynamic routing to the milnet and, therefore, only those sites that are in static tables can reach outside of the milnet and vice versa. Since our first ethernet address has been around awhile it presumably is in many static tables. DCA also tells us that BBN knows of the problem, but that a fix has a very low priority. I am wondering whether this explanation sounds plausible. Are there any other possibilities that I might explore? Any help or suggestions will be greatly appreciated. The current situation is a pain... I'm not an expert on the BBN Mailbridges which connect the MILNET to NSFNET (and other networks) but I'll pass your note along to those who are. However, I'm quite sure that the problem you're experiencing with your new network has nothing to do with the Mailbridges. Hope this helps, Dan
medin@nsipo.nasa.gov (NASA ARC NSI Project Office) (11/30/90)
Well, not quite. This is an acute problem, but various solutions are being worked on. We have one of the 2 FIX sites, and the MB here is very busy, but it is a lot more efficient than it used to be. Unfortunately, the load has also greatly increased. There is going to be a get together on this problem at IETF next week. We should know more then. Understand however, that there are something like 2000 nets floating around these days. Figure out how large an EGP NR message has to be to send these, then figure out how many of these can flow over a 56 Kb line, where the updates are going off every 2 minutes. This is a matter of physics. You need to change the problem in order to accomodate this all on a 56Kbps based network. Thanks, Milo