From Susan.M.Horvath@um.cc.umich.edu Sun Feb 2 20:54:36 1992 Received: from mailrus.cc.umich.edu by merit.edu (5.65/1123-1.0) id AA21456; Sun, 2 Feb 92 20:54:36 -0500 Received: from um.cc.umich.edu by mailrus.cc.umich.edu (5.61/1123-1.0) id AA19849; Sun, 2 Feb 92 20:50:40 -0500 Date: Sun, 2 Feb 92 20:49:36 EST From: Susan.M.Horvath@um.cc.umich.edu Reply-To: nsfnet-info To: Merit/NSFNET.Information.Services-Interested.Parties@um.cc.umich.edu, Douglas.E.Van.Houweling@um.cc.umich.edu, nsfnet-reports Message-Id: <11266521@um.cc.umich.edu> Subject: January NSFNET T1 Usage by Service NSFNET T1 Usage by Service January 1992 Service Type % Packets % Bytes ============ ========= ======= File exchange 28 50 Networked mail 21 23 Interactive 15 5 Name lookup 7 4 Other TCP/UDP services 27 17 Non TCP/UDP services 2 1 --- --- 100 100 The categories above are defined as follows: File exchange ftp: data and control (tcp ports 20, 21) Networked mail smtp, nntp, vmnet, uucp (tcp ports 25, 119, 175, 540) Interactive telnet, finger, who, login (tcp ports 23, 79, 513, udp port 513) Name lookup domain name service (udp port 53, tcp port 53) Other TCP/UDP services all tcp/udp ports not included above (e.g. irc, talk, X-windows, appletalk) Non-TCP/UDP services icmp, egp, etc. More detailed information is available for anonymous FTP from NIS.NSF.NET (the Merit/NSFNET Information Services machine) in the file NSF92-01.PORTS on the NSFSTATS directory. - - - - - - - - - - - - - - - - - From donnab@CERF.NET Mon Feb 3 16:54:16 1992 Received: from nic.cerf.net by merit.edu (5.65/1123-1.0) id AA17324; Mon, 3 Feb 92 16:54:16 -0500 Received: by nic (4.1/CERFnet-1.0) id AA18989; Mon, 3 Feb 92 13:56:13 PST Date: Mon, 3 Feb 92 13:56:13 PST From: Donna Bigley Message-Id: <9202032156.AA18989@nic> To: broidoj@Sds.Sdsc.Edu, help@CERF.NET, nsfnet-reports, ops@cerf.net Subject: CERFnet Weekly Report for the week of Monday, January 27, 1992. ############################################################################### This is the CERFnet weekly activity report for the period of Monday, January 27th through Sunday, February 2nd, 1992. This report is also available through anonymous FTP from NIC.CERF.NET [192.102.249.3] in the cerfnet/cerfnet_stats subdirectory. The filename is: 2-february-92.txt All times are in Pacific Standard Time, and in the 24-hour format. Please direct any questions or comments to: donnab@cerf.net or help@cerf.net ****************************************************************************** NETWORK OUTAGES: SITE: KOREA SITES AFFECTED: KOREA TIME STARTED: MON. 1-27-92 10:08 TIME ENDED: Still Flaking TIME ELAPSED: (Intermittant Outages) REASON: Unknown SITE: USD SITES AFFECTED: USD TIME STARTED: TUE. 1-28-92 22:37 TIME ENDED: TUE. 1-28-92 07:23 TIME ELAPSED: 8 hours 46 min REASON: Unscheduled Outage SITE: CIT SITES AFFECTED: CIT Dial n' CERF and Los Nettos. TIME STARTED: WED. 1-29-92 06:35 TIME ENDED: WED. 1-29-92 07:48 TIME ELAPSED: 1 hour 13 min REASON: Site Scheduled Maintenance SITE: CERFnet SITES AFFECTED: CERFnet TIME STARTED: WED. 1-29-92 07:55 TIME ENDED: WED. 1-29-92 16:55 TIME ELAPSED: 9 hours (Intermittant Access) REASON: Equipment Trouble SITE: CERFnet SITES AFFECTED: Hang10 TIME STARTED: WED. 1-29-92 15:10 TIME ENDED: WED. 1-29-92 15:18 TIME ELAPSED: 8 min. REASON: CERFnet Scheduled Maintenance SITE: AJS SITES AFFECTED: AJS TIME STARTED: FRI. 1-31-92 01:21 TIME ENDED: FRI. 1-31-92 02:29 TIME ELAPSED: 1 hour 8 min. REASON: Power Outage SITE: GA SITES AFFECTED: GA TIME STARTED: FRI. 1-31-92 07:14 TIME ENDED: FRI. 1-31-92 07:38 TIME ELAPSED: 24 min. REASON: Site Scheduled Maintenance ------------------------------------------------------------------------ NETWORK ACTIVITY: 01/27/92 The Ethernet between CIT and Los Nettos was hung. A clear interface released the interface. 01/28/92 UCSD/FDDI installation completed. Some routing problems with 134.24 persisted for 24 hours after install. ------------------------------------------------------------------------ CERFNET TRAFFIC CAPACITY USAGE AT EACH CIRCUIT LINK LINK SPEED CAPACITY PEAK HOUR (PDT) SDSC/CALTECH 1.544 mbps 11.0% 17:00 SDSC/UCI 1.544 mbps 06.3% 12:00 SDSC/UCLA 1.544 mbps 06.0% 15:00 SDSC/UCOP 1.544 mbps 05.8% 17:00 UCI/UCLA 1.544 mbps 00.5% 14:00 SDSC/UCR 512 kbps 02.8% 21:00 UCLA/UCSB 512 kbps 09.9% 21:00 SDSC/AGI 1.544 mbps 00.06% 17:00 SDSC/BIOSYM 1.544 kbps 00.2% 17:00 SDSC/GA 1.544 mbps 00.7% 17:00 SDSC/GD 1.544 mbps 01.4% 10:00 SDSC/SAIC 1.544 mbps 01.2% 17:00 SDSC/SCAQMD 1.544 mbps 00.05% 21:00 SDSC/SDSU 1.544 mbps 01.9% 17:00 UCI/CSU CO(SWRL) 1.544 mbps 03.0% 17:00 UCOP/APPLE 1.544 mbps 00.9% 17:00 UCOP/CISCO 1.544 mbps 00.2% 10:00 UCR/LLUMC 1.544 mbps 00.02% 09:00 CALTECH/CADAM 56 kbps 00.6% 10:00 CALTECH/CLAREMONT 56 kbps 22.9% 21:00 CALTECH/DISNEY 56 kbps 04.2% 10:00 CALTECH/OXY 56 kbps 04.5% 10:00 SDSC/AJS 56 kbps 02.4% 13:00 SDSC/KOREA 56 kbps 04.8% 22:00 SDSC/QUALCOMM 56 kbps 12.6% 14:00 SDSC/SCIH 56 kbps 04.1% 00:00 SDSC/USD 56 kbps 07.1% 17:00 SDSC/USIU 56 kbps 04.9% 17:00 SDSC/XEROX 56 kbps 00.6% 10:00 UCI/CMD 56 kbps 04.8% 20:00 UCI/EMULEX 56 kbps 01.7% 16:00 UCI/FULLERTON 56 kbps 08.7% 21:00 UCI/HUGHES 56 kbps 11.1% 16:00 UCI/MTI 56 kbps 04.6% 10:00 UCI/SPARTA 56 kbps 03.4% 12:00 UCI/UNOCAL 56 kbps 10.1% 10:00 UCLA/ISX 56 kbps 00.5% 13:00 UCLA/PEPPERDINE 56 kbps 01.4% 19:00 UCLA/QUOTRON 56 kbps 10.0% 17:00 UCLA/SMC 56 kbps 00.6% 05:00 UCOP/FARALLON 56 kbps 03.4% 17:00 UCOP/INTEL 56 kbps 14.9% 14:00 UCOP/LSIL 56 kbps 06.0% 20:00 UCOP/NETLABS 56 kbps 12.2% 19:00 ------------------------------------------------------------------------------ SITE CISCO BOX UPTIME SINCE LAST REBOOT (as of 00:15 PST on Feb. 3, 1992): CERFnet BACKBONE CALTECH [131.215.139.253] Up: 04 days 16 hours 29 minutes [Site Scheduled Maintenance] SDSC Drzog [132.249.16.13] Up: 50 days 08 hours 25 minutes SDSC Hang10 [132.249.16.15] Up: 04 days 08 hours 56 minutes [CERFnet Scheduled Maintenance] UCI [128.200.1.101] Up: 24 days 16 hours 07 minutes UCLA [128.97.130.10] Up: 11 days 12 hours 44 minutes UCOP [134.24.52.112] Up: 72 days 08 hours 41 minutes UCR [134.24.108.105] Up: 79 days 12 hours 36 minutes CERF 1544 AGI [134.24.202.110] Up: 37 days 17 hours 54 minutes APPLE [134.24.70.200] Up: 98 days 06 hours 15 minutes BIOSYM [134.24.57.200] Up: 00 days 06 hours 48 minutes [Unscheduled Site Maintenance] CISCO Systems [134.24.54.200] Up: 61 days 14 hours 09 minutes CSUCO/SWRL [130.150.102.200] Up: 19 days 12 hours 46 minutes GA [134.24.221.200] Up: 02 days 16 hours 37 minutes [CERFnet Scheduled Maintenance] GD [134.24.60.200] Up: 32 days 04 hours 14 minutes LLUMC [134.24.208.200] Up: 75 days 12 hours 22 minutes SAIC [134.24.53.208] Up: 29 days 08 hours 34 minutes SCAQMD [134.24.234.200] Up: 45 days 14 hours 27 minutes SDSU [192.77.100.101] Up: 55 days 16 hours 31 minutes UCSB [134.24.107.107] Up: 75 days 07 hours 38 minutes CERF 56 AJS [134.24.225.101] Up: 16 days 14 hours 17 minutes CADAM [134.24.229.200] Up: 30 days 13 hours 06 minutes CLAREMONT [134.24.206.109] Up: 35 days 06 hours 49 minutes CMD [134.24.218.200] Up: 06 days 13 hours 14 minutes [Power Outage] DATAPRODUCTS [134.24.211.104] Up: 09 days 15 hours 19 minutes DISNEY [134.24.207.211] Up: 04 days 00 hours 33 minutes [Equipment Trouble] EMULEX [134.24.209.212] Up: 50 days 15 hours 48 minutes FARALLON [134.24.56.200] Up: 09 days 08 hours 09 minutes FULLERTON [134.24.214.217] Up: 48 days 15 hours 33 minutes HUGHES [134.24.204.200] Up: 80 days 07 hours 21 minutes INTEL [134.24.55.200] Up: 36 days 03 hours 19 minutes LSIL [134.24.72.200] Up: 36 days 14 hours 14 minutes MTI [134.24.216.100] Up: 30 days 13 hours 39 minutes NETLABS [134.24.71.200] Up: 58 days 15 hours 07 minutes OXY [134.24.205.108] Up: 160 days 12 hours 51 minutes PEPPERDINE [134.24.203.218] Up: 29 days 13 hours 24 minutes QUALCOMM [134.24.200.201] Up: 12 days 07 hours 02 minutes QUOTRON [134.24.230.202] Up: 69 days 13 hours 44 minutes SANTA MONICA [134.24.210.219] Up: 24 days 01 hours 22 minutes SCI-HOR [134.24.109.205] Up: 66 days 11 hours 15 minutes SERI/KOREA [134.24.223.200] Up: 132 days 00 hours 00 minutes SPARTA [134.24.215.200] Up: 16 days 14 hours 57 minutes UNOCAL [134.24.217.200] Up: 11 days 14 hours 24 minutes USD [134.24.201.106] Up: 04 days 15 hours 45 minutes [Unscheduled Outage] USIU [134.24.222.215] Up: 211 days 17 hours 07 minutes XEROX [134.24.51.207] Up: 95 days 23 hours 22 minutes DIAL n' CERF DNC-SDSC [134.24.1.2] Up: 19 days 04 hours 51 minutes DNC-UCI [134.24.2.2] Up: 26 days 03 hours 24 minutes DNC-UCLA [134.24.3.2] Up: 11 days 12 hours 38 minutes DNC-CALTECH [134.24.4.2] Up: 04 days 16 hours 28 minutes [Site Scheduled Maintenance] DNC-UCOP [134.24.5.2] Up: 156 days 15 hours 10 minutes - - - - - - - - - - - - - - - - - From bsb Tue Feb 4 07:59:57 1992 Received: by merit.edu (5.65/1123-1.0) id AA06531; Tue, 4 Feb 92 08:00:03 -0500 From: "Belinda Sue Blair" Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA06516; Tue, 4 Feb 92 07:59:57 -0500 Received: by home.merit.edu (4.1/client-0.9) id AA02341; Tue, 4 Feb 92 07:59:56 EST Date: Tue, 4 Feb 92 07:59:56 EST Message-Id: <9202041259.AA02341@home.merit.edu> To: nwg Subject: Additions to the NSFNET policy-based routing database The following networks have been added to the NSFNET policy-based routing database: T1 Network: Net # Net Name Primary Secondary Location -------- ----------- ------- --------- -------- 192.146.113 PALINET 1206 204 Palinet, 3401 Market St., Suite 262, Philadelphia, PA 19104-3319, USA 192.136.120 VINTHILL3 184 164 Directorate of Information Management, Vint Hill Farms Station, Warrenton, VA 22186, USA 192.136.65 SIMSCINET 209 210 Simulation Sciences, Inc., 3033 S. Parker Rd. Floor 4, Aurora, CO 80014, USA 192.135.174 ACM-NET 114 Association for Computer Machinery, P.O. Box 21599, Waco, TX 76702-1599, USA 192.132.84 SILL-EMH 164 184 DOIM/USAISC Ft Sill, Bldg 462, Ft. Sill, OK 73503-5100, USA 192.124.121 PRACTIC 701 279 Practical Computing, Inc., 1030 W. Maude Avenue, Suite 512, Sunnyvale, CA 94086, USA 138.244 LMU-MEDVER 293 291 Ludwig-Maximilians-Univ ersitaet Muenchen, Klinikum Grosshadern, Marchioninistrasse 15, D-8000 Muenchen 70, GERMANY 130.248 ADOBE 701 279 Adobe Systems Inc., 1585 Charlestion Road, Mountain View, CA 94039, USA 129.222 UNISYS-B3 701 279 Unisys, 2700 N. First Street, San Jose, CA 95131, USA 152.73 NOVO 1238 701 Research IT, 1AM, Novo Nordisk A/S, Novo Alle, DK-2880, DENMARK 152.41 CATAWBA-NET 750 756 Catawba College, 2300 West Innes Street, Salisbury, NC 28144, USA 152.39 SHAW-NET 750 756 Shaw University, Administrative Data Processing, 118 East South Street, Raleigh, NC 27611, USA 152.38 CAMPBELL-NET 750 756 Academic Computing Center/Campbell College, P.O.Box 338, Buies Creek, NC 27506, USA 192.58.245 MDANET 602 601 MacDonald Dettwiler and Associates, 13800 Commerce Parkway, Richmond, B.C., V6V 2J3, CANADA 156.18 ECLNET1 590 Ecole Centrale de Lyon, Centre de Calcul 36 av. Guy de Collongue, B.P. 163 69131 Ecully Cedex FRANCE 155.220 FTKNOX-NET4 184 164 USAISC-DOIM, USAISC-FT KNOX, Attn: ASQNB-ZKO-I, Bldg 1227, Fort Knox, KY 40121-5660, USA 140.161 DOUGLAS-NET 602 601 MacDonald Dettwiler and Associates, 13800 Commerce Parkway, Richmond, B.C., V6V 2J3, CANADA 139.232 FTSAMGATEWY1 164 184 Army Information Systems Command, Bldg 4190, Attn: ASQNA-SHN-LOG, Fort Sam Houston, TX 78234, USA 139.161 FSAMGW1 164 184 Army Information Systems Command, Fort Sam Houston, San Antonio, TX 78234, USA 138.246 LMU-WIFO-INK 293 291 Ludwig-Maximilians-Univ ersitaet Muenchen, Klinikum Grosshadern, Marchioninistrasse 15, D-8000 Muenchen 70, GERMNAY 138.245 LMU-WIFO-GRH 293 291 Ludwig-Maximilians-Univ ersitaet Muenchen, Klinikum Grosshadern, Marchioninistrasse 15, D-8000 Muenchen 70, GERMANY 192.75.165 ENIC 601 602 Eye Institute of Canada, Toronto Western Hospital, Volume Investigation Lab, 399 Bathurst Stree, Toronto, Ontario M5T 2S8, CANADA 192.102.1 CANLAN 293 291 Centre of Academic Networking, University of Technology of Vienna, Gusshausstrasse 25, A-1040 Vienna, AUSTRIA 152.32 CHOWAN-NET 750 756 Chowan College, Murfreesboro, NC 27855, USA 146.83 REUNA 86 279 University of Chile, Centro de Computacion, Blanco Encalada 2120, Santiago, CHILE 144.252 LABCOM-ETDL 184 164 U.S. Army LABCOM, ATtn:SLCET-DT, Fort Monmouth, NJ 07703-5000, USA 142.73 MDANET1 602 601 MacDonald Dettwiler and Associates, 13800 Commerce Parkway, Richmond, B.C., V6V 2J3, CANADA 142.44 MYRA 602 601 MYRA Systems Corporation, 3795 Carey Road, Victoria, British Columbia V8Z 628, CANADA 152.37 MT-OLIVE-NET 750 756 Mount Olive College, Mount Olive, NC 28365, USA 152.36 QUEENS-NET 750 756 Queens College, 1900 Selwyn Av., Charlotte, NC 28274, USA 152.35 MEREDITH-NET 750 756 Academic Computing Department/Meredith College, 3800 Hillsborough Street, Raleigh, NC 27607, USA 152.33 ELON-NET 750 756 Academic Computing Department/Elon College, Academic Computing Department, Elon College, NC 27244, USA 192.71.211 TEK-UDAC 1238 701 Uppsala University, Teknikum, Box 534, S-751 21 Uppsala, SWEDEN Total NSFNET T1 announced networks: 4559 T3 Network: Network IP: 129.222 Network Name: UNISYS-B3 Location: Unisys, 2700 N. First Street, San Jose, CA 95131, USA Country Code: US 1:701 Alternet Router Network IP: 130.248 Network Name: ADOBE Location: Adobe Systems Inc., 1585 Charlestion Road, Mountain View, CA 94039, USA Country Code: US 1:701 Alternet Router Network IP: 132.151 Network Name: NRI-NET Country Code: US 42:702 Alternet Router 43:237 MERIT network Network IP: 192.124.121 Network Name: PRACTIC Location: Practical Computing, Inc., 1030 W. Maude Avenue, Suite 512, Sunnyvale, CA 94086, USA Country Code: US 1:701 Alternet Router Network IP: 192.146.113 Network Name: PALINET Location: Palinet, 3401 Market St., Suite 262, Philadelphia, PA 19104-3319, USA Country Code: US 1:1206 PSCNET Total NSFNET T3 announced networks: 1164 The configuration reports, map information sheets, and configuration files which reflect these changes are available for anonymous ftp on nis.nsf.net as usual. nsfsites - configuration reports latest report for: - NSFNET T1 has the file extension .now - NSFNET T3 has the file extension 3.now nsfconfg - configuration files for the routing software for each NSS latest report for: - NSFNET T1 has the file format config.nss# - NSFNET T3 has the file extension .t3p Please send all requests for configuration changes to nsfnet-admin@merit.edu using the NSFNET configuration forms. The forms are available on-line from the nis.nsf.net machine. Use ftp and the anonymous login to get on the machine. Do a "cd nsfsites" and grab the files TEMPLATE.NET, TEMPLATE.GATE, and TEMPLATE.AS. ************** -B. Sue Blair Merit Network Operations - - - - - - - - - - - - - - - - - From vaf@Valinor.Stanford.EDU Tue Feb 4 21:09:21 1992 Received: from Valinor.Stanford.EDU by merit.edu (5.65/1123-1.0) id AA27940; Tue, 4 Feb 92 21:09:21 -0500 Received: by Valinor.Stanford.EDU (5.65/inc-1.0) id AA29888; Tue, 4 Feb 92 18:09:19 -0800 Date: Tue, 4 Feb 92 18:09:19 PST From: Vince Fuller To: regional-techs, techcomm@farnet.org Office: Spruce Hall F15, (415) 723-6860 Usmail: Pine Hall 115, Stanford, CA, 94305-4122 Subject: The CIX and the NSFNET regionals - a dilemma Message-Id: As some of you are probably aware, BARRNet is in the process of establishing a connection to the CIX. While working out the details of how routing will work between BARRNet member sites and customers/members of other CIX-connected networks, I have run into some difficulty which may indicate a fundamental problem for use of the CIX to interconnect research-oriented networks. In short, I believe that such networks face a serious dilemma if they connect to the CIX: how to provide unrestricted commercial-to-commercial access to the CIX-reachable networks while at the same time providing optimal routing over high-bandwidth NSFNET paths for research-oriented traffic. All, of course, while not creating large amounts of management overhead or strange routing anomalies. I would very much appreciate feedback from this community on the enclosed message, which I originally sent to the CIX tech group. Of particular interest to me is whether this group considers the assymetric routing which would be engineered by my proposed "solution" to this dilemma to be an issue and whether or not the "solution" would adequately address any NSFNET AUP concerns (I use the world "solution" loosely as I am neither proud nor very pleased with the described scheme). Thanks, Vince Fuller/BARRNet --------------- As you are probably aware, BARRNet is in the process of establishing a connection to CIX-WEST in Santa Clara. At this time, pretty much all of the administrative details of doing so have been finalized. While thinking about how routing will work, however, it occurred to me that there are some major technical details which remain unresolved. In particular, how are we to deal with routing between research-oriented networks which should use the T3 NSFNET but which will use the CIX due to the way routing is set up (as I understand it, current CIX members prefer all CIX-advertised routes over those which they may learn via the NSFNET, either by weighting advertisements or simply by only using the NSFNET as a default path). This will be a problem (politically severe immediately, technically eventually) for certain paths, such as for BARRNet sites which wish to access the San Diego Supercomputer center (and I assure you that there are several universities attached to BARRNet which have high bandwidth requirements for this particular case), and will become more severe as the T3 NSFNET becomes fully deployed. To solve this problem, it is necessary to determine whether a given network conversation is affectted by the NSFNET AUP or not. Since conformance to the AUP is based on the content of the conversation, it is not possible for the routing system to do this in an automated way - the best approximation we can make is to divide the world into those networks which are unaffected by the AUP (I'll call them "research" sites) and those which are. Routing via the NSFNET would then be preferred for all traffic which inolves a "research" site and via the CIX for all else. Unfortunately, I don't believe such a routing plan is implementable using current technology, as it requires that routing decisions be based on both traffic source and destination. The best that could be done would be to bias routing such that the each CIX-connected midlevel prefers any NSFNET path it has to "research" sites over the CIX path. This could be done in two ways: 1. Configure each CIX-connected mid-level to suppress advertisement of "research" sites to the CIX, guarenteeing that those networks are only reachable via the NSFNET. 2. At each CIX-connected mid-level, adjust metrics such that advertisements for other mid-levels' "research" networks are preferred via the NSFNET. Either "solution" creates a number of problems: 1. Routing must be coordinated among the CIX-connected mid-level networks to establish which networks are "research". Not a technical problem, but procedurally a pain in the neck. 2. Both are unwieldy in that each CIX-connected midlevel will need to maintain a list of all of "research" sites, either within its own network (solution #1, painful) or from all other CIX-connected midlevels (solution #2, more painful) 3. Both engineer route assymetry into the system. This is ugly and may or may not be acceptable. To expand on point #3, here are examples involving real sites, one "research" (Berkeley) and one "commercial" (InterOP) site in BARRNet and one "research" (ISI) and one "commercial" (Hughes Aircraft) site in CERFNet/Los Nettos (I picked these out of a hat, so to speak; I have no idea how much actual traffic flows among these four). In order to allow the NSFNET path to be used for the "research" sites, both CERFNet and BARRNet will need to hack their routing configurations to prefer the NSFNET path for Berkeley and ISI. This generates symmetric and "appropriate" paths for two of the possible communication pairs: Berkeley<->ISI and InterOP<->Hughes, but codifies assymetry for the mixed "commercial" and "research" pairs. For Interop<->ISI, BARRNet will route to ISI via the NSFNET but CERFNet will route back to InterOP via the CIX. In the Berkeley<->Hughes case, BARRNet will use the CIX to route to Hughes but CERFNet will route back to Berkeley via the NSFNET. Not pretty. There is also another policy problem with the presence of the NSFNET and it's AUP - even if all CIX-connected organizations are configured to prefer routing via the CIX for "commercial" networks, what happens if the path between two "commercial" networks via the CIX fails? If the networks are also advertised via the NSFNET, suddenly what was an unrestricted path between the two is now subject to the NSFNET AUP, without the knowledge of any user. It seems to me that the only way to prevent this is to never advertise to the NSFNET those networks which may wish to transmit any non-AUP traffic. Have these problems been previously addressed by the CIX membership? Are there solutions which I am missing? Does no one else consider these issues to be a problematic? When I explained this to my management, there was very serious concern voiced, in particular over the use of the non-T3 path for AUP-conformant sites (i.e. between BARRNET members and SDSC), since traffic between purely research-oriented sites (such as universities) should use the network which has been expressly provided for it - the T3 NSFNET. Your comments and thoughts on this matter would be greatly appreciated. - - - - - - - - - - - - - - - - - From jrr@concert.net Tue Feb 4 21:43:55 1992 Received: from scamp.concert.net by merit.edu (5.65/1123-1.0) id AA28818; Tue, 4 Feb 92 21:43:55 -0500 Received: by scamp.concert.net (5.59/tas-concert/6-19-91) id AA14891; Tue, 4 Feb 92 21:43:54 -0500 Date: Tue, 4 Feb 92 21:43:54 -0500 From: Joe Ragland Message-Id: <9202050243.AA14891@scamp.concert.net> To: regional-techs, techcomm@farnet.org, vaf@Valinor.Stanford.EDU Subject: Re: The CIX and the NSFNET regionals - a dilemma Vince's problems with CIX vs. T3 NSFNET routing reminded me of a recent posting to the com-priv list from Dennis Ferguson. I hope Dennis doesn't mind my forwarding his concerns to these groups also. There's much in common here. --joe From com-priv3-forw@psi.com Sat Feb 1 22:00:17 1992 Received: by MrBill.CAnet.CA id <105513>; Sat, 1 Feb 1992 21:55:10 -0000 From: Dennis Ferguson To: schoff@psi.com Subject: Re: Are We to Buy Speed for a Few or Connectivity for Many? Cc: com-priv@psi.com Message-Id: <92Feb1.215510gmt.105513@MrBill.CAnet.CA> Date: Sat, 1 Feb 1992 21:54:56 -0000 Status: RO > While there maybe "bad" regionals that need to be hardened (sorry Laura, > I can remember the new politically correct word, i'm not very good at > this politics stuff), there is a much larger need to harden the backbone > infrastructure through alternatives, the CIX being one. Its pretty > frightening what "the market" could do with a 1/8th of the funds being poured > into the current nsfnet. If you look at the upcoming solicitation from > NSF they say that implicitly - you can do the math yourself. > > Marty This leads to a topic which I personally find interesting. One advantage of a single, large (well-working) "backbone", with the asymmetric relationship to client networks which this implies, is that it simplifies routing considerably for just about everyone. Making two or more points of contact work well between networks which wish to maintain some sort of symmetric relationship makes the problem of obtaining decent routing between them quite hard. The two-backbone NSFnet proposal, and the CIX model as I understand it, both seem to have the potential for producing some really intriguing routing problems. The NSF seems to be covering their bets by also spending big bucks for a routing arbiter, whose problem I assume this would become. From here it appears that the CIX has punted on the problem for the moment by only bringing up one point of contact (I assume that packets wouldn't travel between Reston, VA and Falls Church, VA via California if this weren't the case). While this does simplify things considerably, it can obviously lead to some very long distance paths between geographically close sites and (speaking of hardening) leaves a single point of failure where a fire or earthquake or backhoe may ruin a lot of peoples' days. I was wondering, then, if there was a routing plan for a possible future CIX with more players and more points of contact (or even a plan for bringing up the rumoured CIX-east), and if so is the plan available. In fact, I'd also like very much to see what the NSF had in mind for the two backbones in terms of routing, though I suspect even they aren't quite sure at this point. Dennis Ferguson - - - - - - - - - - - - - - - - - From jrr@concert.net Tue Feb 4 22:14:04 1992 Received: from scamp.concert.net by merit.edu (5.65/1123-1.0) id AA29451; Tue, 4 Feb 92 22:14:04 -0500 Received: by scamp.concert.net (5.59/tas-concert/6-19-91) id AA14933; Tue, 4 Feb 92 22:14:03 -0500 Date: Tue, 4 Feb 92 22:14:03 -0500 From: Joe Ragland Message-Id: <9202050314.AA14933@scamp.concert.net> To: regional-techs, techcomm@farnet.org, vaf@Valinor.Stanford.EDU Subject: Re: The CIX and the NSFNET regionals - a dilemma One additional comment... Aside from CIX/NSFNET routing problems, we have seen some of the consequences of multiple backbones with the current T1 and T3 NSFNET backbones and the interconnect between the two. That's how we find routes from the East Coast to the West Coast and back again, especially when the active interconnect is at SDSC. The routing arbitrator in this case is the same as the operator of both backbones but that doesn't help since the problems are fundamental to basic routing design. --joe - - - - - - - - - - - - - - - - - From jcurran@nic.near.net Tue Feb 4 22:18:46 1992 Received: from nic.near.net by merit.edu (5.65/1123-1.0) id AA29540; Tue, 4 Feb 92 22:18:46 -0500 Message-Id: <9202050318.AA29540@merit.edu> To: Vince Fuller Cc: regional-techs, techcomm@farnet.org Subject: Re: The CIX and the NSFNET regionals - a dilemma Date: Tue, 04 Feb 92 22:18:37 -0500 From: John Curran -------- Vince, I recently wrote a breif message on this same topic which mentions some possible solutions (none good). I attached it here to help clarify the issues involved for those network service providers which have a major research component. /John ----------- Date: Mon, 27 Jan 92 22:22:13 EST From: John Curran To: Folks:; Subject: NSFNET and CIX routing issues Hello All, John Rugo passed along the message regarding the various routing issues that arise for a regional that connects to both the CIX and the NSFNET. I would like to summarize the situation that occurs to insure that we are all working on the same problem. We welcome any and all thoughts on this issue. Given that a basically research and educational network (such as NEARnet) has a high-speed connection (assume 10 or 45 Mb/s) to the NSFNET and also connects to CIX to exchange commercial traffic, here are the ramifications: Any network which is only CIX-reachable presents no problems. You accept the route for the site and send any traffic via the CIX. Routes to all of NEARnet's members are made available to that site and their network sends traffic for NEARnet members via the CIX. Any network which is NSF AUP compliant and prefers to use the NSFNET is not a problem: You insure that such network routes are not announced via the CIX and NEARnet members will automatically use the NSFNET to reach them. Likewise, NEARnet will not announce routes to these "R&E" networks via CIX, which prevents any return traffic from taking the wrong path. Note that both of the above policies work, but cannot be simultaneously implemented in almost any network today. The policies would require that routes back to an R&E site (say, "Harvard") be sent to the CIX so that a purely commercial site (say, "TRW") can access them, yet it also requires that the route to Harvard not be announced in order that any other CIX- reachable R&E site (say, "Stanford") does not utilize the slower path. This is only a problem if: - There exists R&E members that utilize more peak bandwidth than the CIX path will allow. (There is: Harvard Astrophysics, MIT Laboratory for Computer Science, BBN packet video, etc..) - The routes that are used by R&E sites is the same as the routes used by your non-R&E sites. (They are: packets are generally routed based on destination, and not on any history such as "color" or source network) - There exists both R&E and non-R&E traffic on the network (There will be; or there is no reason to pursue the CIX). How technology can solve the problem: If you can separate your network into two distinct networks with separate routers for R&E and non-R&E members, then you can maintain distinct routing tables for each type of member. This is not pretty, or cost effective. If you place a box at your border which not only routes on destination but also on the source of the packet, then you can effectively maintain distinct routing tables for R&E and non-R&E sites. This does create a traffic bottleneck and single point of failure. If you mark packets with a indication of whether they are commercial or R&E, and then build a router which understands the indication, then you can route each packet accordingly (and also solve the mixed-R&E case nicely.) That's the situation to the best of my knowledge. If anyone sees a solution, or has questions about the assumptions, I'd be interested in hearing from you. /John ------- End of Forwarded Message - - - - - - - - - - - - - - - - - From schoff@psi.com Tue Feb 4 22:47:54 1992 Received: from psi.com by merit.edu (5.65/1123-1.0) id AA00103; Tue, 4 Feb 92 22:47:54 -0500 Received: from localhost by psi.com (5.61/2.1-PSI/PSINet) id AA02909; Tue, 4 Feb 92 22:47:43 -0500 Message-Id: <9202050347.AA02909@psi.com> To: Joe Ragland Cc: regional-techs, techcomm@farnet.org, vaf@valinor.stanford.edu, cix-tech@cix.org, mkapor@eff.org Subject: Re: The CIX and the NSFNET regionals - a dilemma In-Reply-To: Your message of "Tue, 04 Feb 92 22:14:03 EST." <9202050314.AA14933@scamp.concert.net> Date: Tue, 04 Feb 92 22:47:42 -0500 From: "Martin Lee Schoffstall" I've deferred responding publicly to the com-priv message since I hoped others would. But I will respond to this.... there isn't a routing "problem". there are gigapackets/month running through the CIX reliably, with little latency, and very inexpensively. What vaf wants is some tuning for the high bandwidth path that he and a very few others have by the grace of nsf and tax $'s. it is a reasonable request given that people don't want to ante up quite yet for t3 cix interconnects. This tuning to my knowledge is driven by a fairly small % of the total CIX networks (10 out of 500?). the t1/t3 interconnect problems (as reported) were a completely different animal. the "solution" has been to abandon the t1 in favor of the t3, i have that in several email messages. the t1/t3 interconnect problems affected everyone for many months.... Marty ---------- Aside from CIX/NSFNET routing problems, we have seen some of the consequences of multiple backbones with the current T1 and T3 NSFNET backbones and the interconnect between the two. That's how we find routes from the East Coast to the West Coast and back again, especially when the active interconnect is at SDSC. The routing arbitrator in this case is the same as the operator of both backbones but that doesn't help since the problems are fundamental to basic routing design. --joe - - - - - - - - - - - - - - - - - From jcurran@nic.near.net Tue Feb 4 23:47:58 1992 Received: from nic.near.net by merit.edu (5.65/1123-1.0) id AA01450; Tue, 4 Feb 92 23:47:58 -0500 Message-Id: <9202050447.AA01450@merit.edu> To: Martin Lee Schoffstall Cc: Joe Ragland , regional-techs, techcomm@farnet.org, vaf@valinor.stanford.edu, cix-tech@cix.org, mkapor@eff.org Subject: Re: The CIX and the NSFNET regionals - a dilemma In-Reply-To: Your message of Tue, 04 Feb 92 22:47:42 -0500. <9202050347.AA02909@psi.com> Date: Tue, 04 Feb 92 23:47:26 -0500 From: John Curran -------- > From: Martin Lee Schoffstall > Subject: Re: The CIX and the NSFNET regionals - a dilemma > Date: Tue, 04 Feb 92 22:47:42 -0500 > > > I've deferred responding publicly to the com-priv message since I hoped > others would. But I will respond to this.... > > there isn't a routing "problem". there are gigapackets/month running > through the CIX reliably, with little latency, and very inexpensively. > > What vaf wants is some tuning for the high bandwidth path that he and > a very few others have by the grace of nsf and tax $'s. it is a > reasonable request given that people don't want to ante up quite yet > for t3 cix interconnects. This tuning to my knowledge is driven > by a fairly small % of the total CIX networks (10 out of 500?). I am providing the following data based on NEARnet's current membership in order to put the situation in perspective. I would expect that the ratios would vary significantly from one network service provider to another. Of NEARnet's 115 members, we would require such "tuning" (as mentioned above) for at least 20 organizations. This represents 60-70 network routes out of about 250. This considers only bandwidth; certainly reliability and latency might also force transit network selection. The routing issue is very real for any network which serves the academic and research community. Providing for their needs, while preventing the Internet from segmenting, is the significant challenge before us. /John - - - - - - - - - - - - - - - - - From dennis@MrBill.CAnet.CA Wed Feb 5 00:57:18 1992 Received: from MrBill.CAnet.CA by merit.edu (5.65/1123-1.0) id AA02997; Wed, 5 Feb 92 00:57:18 -0500 Received: by MrBill.CAnet.CA id <105513>; Wed, 5 Feb 1992 00:56:48 -0000 From: Dennis Ferguson To: jcurran@nic.near.net Subject: Re: The CIX and the NSFNET regionals - a dilemma Cc: regional-techs, techcomm@farnet.org Message-Id: <92Feb5.005648gmt.105513@MrBill.CAnet.CA> Date: Wed, 5 Feb 1992 00:56:38 -0000 John, > How technology can solve the problem: [...] > If you mark packets with a indication of whether they are commercial or > R&E, and then build a router which understands the indication, then you can > route each packet accordingly (and also solve the mixed-R&E case nicely.) I'd point out (probably unnecessarily) that if you replaced "commercial" and "R&E" with "wants maximum reliability" and "wants maximum throughput" it would immediately conjure up a way to maintain a split routing table, with type-of-service. While no current routers support this, there are at least bits in the IP header to be used for this, and OSPF could carry the routes and get the dual routing tables right if someone actually bothered to implement that part of the protocol. Now, if you had routers which had a knob which said "for any packet which arrives though this interface with the default TOS, change the TOS to one of commercial or R&E", in this way allowing you to classify packets as "AUP-compliant" or "commercial" when they entered your network, you could effectively do what was suggested above, all with existing but seldom-implemented bits of the protocol. It also might allow users to pick their own preferred routing by setting the TOS bits on their own. This isn't perfect. It isn't quite clear to me how one would assemble the dual routing tables, picking the outbound direction properly for networks which can only be routed one way while splitting, networks with alternative routing, without importing all routes from everywhere. Despite this, however, it seems like about the quickest way to obtain source-based policy routing in cases where only a limited number of policies (like two) exist, since most of the protocol knobs exist already. Dennis Ferguson - - - - - - - - - - - - - - - - - From mathis@pele.psc.edu Wed Feb 5 02:44:01 1992 Received: from pele.psc.edu by merit.edu (5.65/1123-1.0) id AA04937; Wed, 5 Feb 92 02:44:01 -0500 Received: by pele.psc.edu (5.57/Ultrix2.4-C cf:ab 9/11/90 --MM--) id AA00494; Wed, 5 Feb 92 02:43:58 EST Message-Id: <9202050743.AA00494@pele.psc.edu> To: Vince Fuller Cc: regional-techs, techcomm@farnet.org, mathis@pele.psc.edu Subject: Re: The CIX and the NSFNET regionals - a dilemma In-Reply-To: Your message of Tue, 04 Feb 92 18:09:19 -0800. Date: Wed, 05 Feb 92 02:43:57 EST From: mathis@pele.psc.edu I believe that Vince is completely correct. With current routing protocols the NSFNET AUP policy can only be implemented with contorted and sub-optimal topologys and routing configurations. (One could argue that the policys are optimal for securing other goals in a wider arena, but that is not a technical discussion). In a general sense PC routing (that is "politically correct routing") requires switches to know the usage policys of both the source and destination sites. This means that traffic must be routed on the basis of both its destination address and SOURCE address and there needs to be some mechanism of associating the usage policys with remote addresses. Neither part of this can be accurately implemented by current protocols and architectures. Consider the following simpler situation that came up in Pennsylvania a while back: We (PSCnet) are NSF R&E. PREPnet transits PSCnet to reach the NSFnet backbones. Intra PREPnet traffic is NOT subject to the NSF usage rules, and does not distinguish between commercial and non-commercial internal sites. There was a proposal for PREPnet to acquire an additional ANS connection to address two goals: redundant paths for the research users and an external path that was not subject to the NSF rules. It was correctly observed that inbound traffic (from the backbones to the sites) could be PC routed, as long as the remote site/backbone/interchange did the correct thing. However, outbound traffic (sites to backbones) could not be "PC routed". The problem is that all traffic from commercial sites to remote commercial sites MUST leave via the ANS connection, yet all traffic from research sites strongly prefers to leave via the PSCnet connection. Given the topology under consideration this required traffic to flow in opposite directions on the same link to the same destination, depending on the source of the traffic. This can not be done today. period. PSC's position was that if PREPnet accepted comercial interstate traffic from any customers, then PSCnet could not accept any traffic from PREPnet. PREPnet would then be single attached via ANS. Any other position would have put us in violation of our funding. (This predated the NSF/ANS co+re policy, which provides an out.) As I look over the other replys, I see that many have missed a point that I assumed: The problems arise when there is a (complex) midlevel carrying mixed traffic between assorted sites and both flavors of backbones. It is not a problem if the midlevel is "pure" research or commercial. It is less of a problem if both backbones land on the same FDDI dmz. It is clear to me that one of two things is going to happen: The rules will change, and there will be good technical solutions. -or- The rules will not change, and we will have split research and commercial networks with weak interconnects. Organizations that really need to function in both worlds will have two network numbers or two connections.... --MM-- - - - - - - - - - - - - - - - - - From schoff@psi.com Wed Feb 5 11:00:03 1992 Received: from psi.com by merit.edu (5.65/1123-1.0) id AA06746; Wed, 5 Feb 92 11:00:03 -0500 Received: from localhost by psi.com (5.61/2.1-PSI/PSINet) id AA04442; Wed, 5 Feb 92 10:59:47 -0500 Message-Id: <9202051559.AA04442@psi.com> To: John Curran Cc: Joe Ragland , regional-techs, techcomm@farnet.org, vaf@valinor.stanford.edu, cix-tech@cix.org, mkapor@eff.org Subject: Re: The CIX and the NSFNET regionals - a dilemma In-Reply-To: Your message of "Tue, 04 Feb 92 23:47:26 EST." <9202050448.AA03542@psi.com> Date: Wed, 05 Feb 92 10:59:45 -0500 From: "Martin Lee Schoffstall" John, Could you elaborate on your technical criteria for this? For instance is it 10Mbps - 45Mbps pipe access? 4Mbps spikes? what? Are these commercial or academic organizations? Marty PS: I note that your NSFNet T3 has a 10Mbps ethernet interface as of 2 weeks ago, do things change if/when it goes to FDDI? -------- > From: Martin Lee Schoffstall > Subject: Re: The CIX and the NSFNET regionals - a dilemma > Date: Tue, 04 Feb 92 22:47:42 -0500 > > > I've deferred responding publicly to the com-priv message since I hoped > others would. But I will respond to this.... > > there isn't a routing "problem". there are gigapackets/month running > through the CIX reliably, with little latency, and very inexpensively. > > What vaf wants is some tuning for the high bandwidth path that he and > a very few others have by the grace of nsf and tax $'s. it is a > reasonable request given that people don't want to ante up quite yet > for t3 cix interconnects. This tuning to my knowledge is driven > by a fairly small % of the total CIX networks (10 out of 500?). I am providing the following data based on NEARnet's current membership in order to put the situation in perspective. I would expect that the ratios would vary significantly from one network service provider to another. Of NEARnet's 115 members, we would require such "tuning" (as mentioned above) for at least 20 organizations. This represents 60-70 network routes out of about 250. This considers only bandwidth; certainly reliability and latency might also force transit network selection. The routing issue is very real for any network which serves the academic and research community. Providing for their needs, while preventing the Internet from segmenting, is the significant challenge before us. /John - - - - - - - - - - - - - - - - - From schoff@psi.com Wed Feb 5 11:22:47 1992 Received: from psi.com by merit.edu (5.65/1123-1.0) id AA07441; Wed, 5 Feb 92 11:22:47 -0500 Received: from localhost by psi.com (5.61/2.1-PSI/PSINet) id AA05159; Wed, 5 Feb 92 11:21:50 -0500 Message-Id: <9202051621.AA05159@psi.com> To: brian@lloyd.com Cc: jcurran@nic.near.net, jrr@concert.net, regional-techs, techcomm@farnet.org, vaf@valinor.stanford.edu, cix-tech@cix.org, mkapor@eff.org Subject: Re: The CIX and the NSFNET regionals - a dilemma In-Reply-To: Your message of "Tue, 04 Feb 92 21:52:00 PST." <9202050552.AA21357@ray.lloyd.com> Date: Wed, 05 Feb 92 11:21:46 -0500 From: "Martin Lee Schoffstall" Brian, I've had retail service customers since 1985, i have had user's groups meetings 3-4 times a year since 1986, I know who pays the bills, and I don't have a big university to back me if I fail, or a government agency to pay me regardless if it works. Trust me, I'm properly motivated. I don't think I pooh poohed VAF, in fact I didn't even respond to his posting yet, so relax your over-reacting. John Curran's posting from nearnet says that my tremendously detailed engineering solution called "tuning" (see my upcoming paper in IEEE Networks) works for 115 - 20 of his organizations. That's not too bad given the big R&D budget of the last few days. I kind of disagree on the need for an immediate DAMN good answer, given the many upcoming changes I see 3-4 answers over the next 18months as things evolve. And I see them being done cooperatively with little in the way of emotion or rancor. Marty PS: despite the intensity i do appreciate the statement that you believe that I'm doing my customer a service by using the CIX. ------- > From: Martin Lee Schoffstall > Subject: Re: The CIX and the NSFNET regionals - a dilemma > Date: Tue, 04 Feb 92 22:47:42 -0500 > > > I've deferred responding publicly to the com-priv message since I hoped > others would. But I will respond to this.... > > there isn't a routing "problem". there are gigapackets/month running > through the CIX reliably, with little latency, and very inexpensively. > > What vaf wants is some tuning for the high bandwidth path that he and > a very few others have by the grace of nsf and tax $'s. it is a > reasonable request given that people don't want to ante up quite yet > for t3 cix interconnects. This tuning to my knowledge is driven > by a fairly small % of the total CIX networks (10 out of 500?). Right now the performance of the NSFnet is pretty bad (even the T3 network performance is worse than a CIX provided connection) so you are probably doing your customers a service by using the CIX to route packets instead of the NSFnet. But let's look into the future where ANS finally gets its technical act together and the T3 NSFnet really starts to hum. Add in much greater use of the CIX and I can see an inverted picture where the CIX is more of a bottleneck than the NSFnet. Let me bring this closer to home for you. The federal government is paying to provide a T3 network for research and education. I suspect that NYSERnet is intended to be a beneficiary of this service. I also presume that PSI is still the carrier for NYSERnet (please correct me if I am wrong). In that case, by running traffic through the CIX you are circumventing a federal resource. Not a problem now but what if the NSFnet gets its act together? In that case you, PSI, will be doing your clients who may legitimately use the NSFnet, a GREAT disservice. Were I them I would become POWERFULLY annoyed. How are you going to deal with the problem then? Bottom line here Marty is that you and every other service provider who carries both CO and RE traffic had better have a DAMNED good answer to this problem. I would recommend you begin to think about it NOW. I have been harping about dropping AUPs on the NSFnet but that is unlikely to ever happen so we are going to have to live with the detritus. Now one last item: don't get on Vince's case. He has been tasked with solving a problem and he is doing his best. He has identified a problem that clearly ought to be dropped in your lap (collective "your" because I suspect that CERFNet and possibly UUnet/Alternet are in the same boat). Perhaps you ought to say "thank you" and work with him instead of pooh-poohing his posting. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 - - - - - - - - - - - - - - - - - From brian@lloyd.com Wed Feb 5 11:32:07 1992 Received: from ray.lloyd.COM by merit.edu (5.65/1123-1.0) id AA07756; Wed, 5 Feb 92 11:32:07 -0500 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA21357; Tue, 4 Feb 92 21:52:00 PST Date: Tue, 4 Feb 92 21:52:00 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9202050552.AA21357@ray.lloyd.com> To: schoff@psi.com Cc: jcurran@nic.near.net, jrr@concert.net, regional-techs, techcomm@farnet.org, vaf@valinor.stanford.edu, cix-tech@cix.org, mkapor@eff.org Subject: The CIX and the NSFNET regionals - a dilemma Reply-To: brian@lloyd.com > From: Martin Lee Schoffstall > Subject: Re: The CIX and the NSFNET regionals - a dilemma > Date: Tue, 04 Feb 92 22:47:42 -0500 > > > I've deferred responding publicly to the com-priv message since I hoped > others would. But I will respond to this.... > > there isn't a routing "problem". there are gigapackets/month running > through the CIX reliably, with little latency, and very inexpensively. > > What vaf wants is some tuning for the high bandwidth path that he and > a very few others have by the grace of nsf and tax $'s. it is a > reasonable request given that people don't want to ante up quite yet > for t3 cix interconnects. This tuning to my knowledge is driven > by a fairly small % of the total CIX networks (10 out of 500?). Right now the performance of the NSFnet is pretty bad (even the T3 network performance is worse than a CIX provided connection) so you are probably doing your customers a service by using the CIX to route packets instead of the NSFnet. But let's look into the future where ANS finally gets its technical act together and the T3 NSFnet really starts to hum. Add in much greater use of the CIX and I can see an inverted picture where the CIX is more of a bottleneck than the NSFnet. Let me bring this closer to home for you. The federal government is paying to provide a T3 network for research and education. I suspect that NYSERnet is intended to be a beneficiary of this service. I also presume that PSI is still the carrier for NYSERnet (please correct me if I am wrong). In that case, by running traffic through the CIX you are circumventing a federal resource. Not a problem now but what if the NSFnet gets its act together? In that case you, PSI, will be doing your clients who may legitimately use the NSFnet, a GREAT disservice. Were I them I would become POWERFULLY annoyed. How are you going to deal with the problem then? Bottom line here Marty is that you and every other service provider who carries both CO and RE traffic had better have a DAMNED good answer to this problem. I would recommend you begin to think about it NOW. I have been harping about dropping AUPs on the NSFnet but that is unlikely to ever happen so we are going to have to live with the detritus. Now one last item: don't get on Vince's case. He has been tasked with solving a problem and he is doing his best. He has identified a problem that clearly ought to be dropped in your lap (collective "your" because I suspect that CERFNet and possibly UUnet/Alternet are in the same boat). Perhaps you ought to say "thank you" and work with him instead of pooh-poohing his posting. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 - - - - - - - - - - - - - - - - - From zawada@ncsa.uiuc.edu Wed Feb 5 11:57:03 1992 Received: from newton.ncsa.uiuc.edu by merit.edu (5.65/1123-1.0) id AA08681; Wed, 5 Feb 92 11:57:03 -0500 Received: from bliga.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA08931 (5.65a/IDA-1.4.2 for regional-techs@merit.edu); Wed, 5 Feb 92 10:56:51 -0600 Return-Path: Received: by bliga.ncsa.uiuc.edu (4.1/NCSA-4.1) id AA08036; Wed, 5 Feb 92 10:56:49 CST Date: Wed, 5 Feb 92 10:56:49 CST From: zawada@ncsa.uiuc.edu (Paul Zawada) Message-Id: <9202051656.AA08036@bliga.ncsa.uiuc.edu> To: brian@lloyd.com Subject: Re: The CIX and the NSFNET regionals - a dilemma In-Reply-To: Mail from 'brian@lloyd.com (Brian Lloyd)' dated: Tue, 4 Feb 92 21:52:00 PST Cc: regional-techs, cix-tech@cix.org > > Right now the performance of the NSFnet is pretty bad (even the T3 > network performance is worse than a CIX provided connection) so you > are probably doing your customers a service by using the CIX to route > packets instead of the NSFnet. But let's look into the future where > ANS finally gets its technical act together and the T3 NSFnet really > starts to hum. Add in much greater use of the CIX and I can see an > inverted picture where the CIX is more of a bottleneck than the > NSFnet. Really? What do you base your assertions on? I can tell you right now that the NSFNET T3 backbone has come a long, long way since last October. (Mark Knopper and his gang must have been in hell back then!) The reliablity has been extremely good. I will admit that the traffic probably isn't taking full advantage of the speed of the T3 pipes right now, but the upgrade of the T3 cards in the NSSes will hopefully improve that situation. The throughput is still definitely higher than a T1 though... So, are there people still having problems with the T3 backbone? I have failed to see any evidence that "the NSFnet is pretty bad," at least worse than a CIX T1 connections. --zawada __ - - - - - - - - - - - - - - - - - From brian@lloyd.com Wed Feb 5 13:37:41 1992 Received: from ray.lloyd.COM by merit.edu (5.65/1123-1.0) id AA11719; Wed, 5 Feb 92 13:37:41 -0500 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA21566; Wed, 5 Feb 92 09:24:56 PST Date: Wed, 5 Feb 92 09:24:56 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9202051724.AA21566@ray.lloyd.com> To: mathis@pele.psc.edu Cc: vaf@valinor.stanford.edu, regional-techs, techcomm@farnet.org, mathis@pele.psc.edu In-Reply-To: mathis@pele.psc.edu's message of Wed, 05 Feb 92 02:43:57 EST <9202050743.AA00494@pele.psc.edu> Subject: The CIX and the NSFNET regionals - a dilemma Reply-To: brian@lloyd.com Date: Wed, 05 Feb 92 02:43:57 EST From: mathis@pele.psc.edu It is clear to me that one of two things is going to happen: The rules will change, and there will be good technical solutions. -or- The rules will not change, and we will have split research and commercial networks with weak interconnects. Organizations that really need to function in both worlds will have two network numbers or two connections.... Good assesment. One thing that I have noticed in life, people don't always see their way clear to perform preventative measures (oh, money is too tight, I don't have time, etc.) but they sure scream when the damned thing breaks. Perhaps we ought to start encouraging companies to start requesting more than one network number: one for RE and one for non-RE (I would rather we quit calling the non-RE thing "CO" since not all non-RE stuff is commercial). This will cause the usage of network numbers to increase dramatically, hastening the time that we run out of address space. This would break things very quickly. Maybe the hue and cry would convince the powers-that-be that things ought to change. It would really be a shame to be forced to break the very thing many have spent significant parts of their life to build just so we could get it fixed. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 - - - - - - - - - - - - - - - - - From brian@lloyd.com Wed Feb 5 13:36:12 1992 Received: from ray.lloyd.COM by merit.edu (5.65/1123-1.0) id AA11679; Wed, 5 Feb 92 13:36:12 -0500 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA21613; Wed, 5 Feb 92 09:50:06 PST Date: Wed, 5 Feb 92 09:50:06 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9202051750.AA21613@ray.lloyd.com> To: zawada@ncsa.uiuc.edu Cc: regional-techs, cix-tech@cix.org In-Reply-To: Paul Zawada's message of Wed, 5 Feb 92 10:56:49 CST <9202051656.AA08036@bliga.ncsa.uiuc.edu> Subject: The CIX and the NSFNET regionals - a dilemma Reply-To: brian@lloyd.com My comments are based on some tests that I ran a couple of weeks ago. Latency between Stanford and MIT via the T3 NSFnet was much greater than an equivalent path via CIX/Alternet (about 50% longer delay via the NSFnet). The results were repeatable and consistent. Throughput was also lower but I attribute that to the longer latency and limited TCP window size. The bottom line was that the performance as seen by a standard workstation using standard networking tools was better via CIX. I suspect that very large windows would push the throughput performance in favor of the NSFnet but I do not have the tools right now to test that. Anybody have a TCP with large windows I can play with? Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 - - - - - - - - - - - - - - - - - From schoff@psi.com Wed Feb 5 13:50:08 1992 Received: from psi.com by merit.edu (5.65/1123-1.0) id AA12080; Wed, 5 Feb 92 13:50:08 -0500 Received: from localhost by psi.com (5.61/2.1-PSI/PSINet) id AA10281; Wed, 5 Feb 92 13:49:41 -0500 Message-Id: <9202051849.AA10281@psi.com> To: brian@lloyd.com Cc: zawada@ncsa.uiuc.edu, regional-techs, cix-tech@cix.org, mkapor@eff.org Subject: Re: The CIX and the NSFNET regionals - a dilemma In-Reply-To: Your message of "Wed, 05 Feb 92 09:50:06 PST." <9202051750.AA21613@ray.lloyd.com> Date: Wed, 05 Feb 92 13:49:39 -0500 From: "Martin Lee Schoffstall" Brian, We see similiar problems, functional capability for interactive applications like telnet is MUCH better through the CIX than through the NSFNet. When "SaltLakeCity" has its normal problems (we've seen about a dozen in January, and we're not looking really) then it goes through the roof. Leveraging off another posting elsewhere, I was wondering how hard it would be for cisco to change their architecture to have multiple routing tables and slightly modify their protocol prioritization scheme so that telnet/rlogin is not just prioritized but goes out a different path (specifically the CIX path). Marty ----- My comments are based on some tests that I ran a couple of weeks ago. Latency between Stanford and MIT via the T3 NSFnet was much greater than an equivalent path via CIX/Alternet (about 50% longer delay via the NSFnet). The results were repeatable and consistent. Throughput was also lower but I attribute that to the longer latency and limited TCP window size. The bottom line was that the performance as seen by a standard workstation using standard networking tools was better via CIX. I suspect that very large windows would push the throughput performance in favor of the NSFnet but I do not have the tools right now to test that. Anybody have a TCP with large windows I can play with? Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 - - - - - - - - - - - - - - - - - From almquist@pa.dec.com Wed Feb 5 16:36:33 1992 Received: from inet-gw-1.pa.dec.com by merit.edu (5.65/1123-1.0) id AA17294; Wed, 5 Feb 92 16:36:33 -0500 Received: by inet-gw-1.pa.dec.com; id AA07610; Wed, 5 Feb 92 13:30:54 -0800 Received: by rfc1035.pa.dec.com; id AA09102; Wed, 5 Feb 92 13:22:41 -0800 Date: Wed, 5 Feb 92 13:22:41 -0800 Message-Id: <9202052122.AA09102@rfc1035.pa.dec.com> To: schoff@psi.com Cc: brian@lloyd.com, zawada@ncsa.uiuc.edu, regional-techs, cix-tech@cix.org, mkapor@eff.org Subject: The CIX and the NSFNET regionals - a dilemma From: Philip Almquist Sender: almquist@nsl.dec.com In-Reply-To: "Martin Lee Schoffstall"'s message of Wed, 05 Feb 92 13:49:39 -0500 <9202051849.AA10281@psi.com> Marty, > Leveraging off another posting elsewhere, I was wondering how hard it > would be for cisco to change their architecture to have multiple routing > tables and slightly modify their protocol prioritization scheme so that > telnet/rlogin is not just prioritized but goes out a different path > (specifically the CIX path). In general, TOS support in routers is pretty easy, though it may not be in Cisco's case depending on how they designed their fast switching stuff. In theory, of course, Cisco is adding TOS support since they are adding OSPF and TOS is a part of OSPF, but I don't know whether theory matches practice in this case (it doesn't in the case of some other OSPF vendors). Philip - - - - - - - - - - - - - - - - - From schoff@psi.com Wed Feb 5 16:53:55 1992 Received: from psi.com by merit.edu (5.65/1123-1.0) id AA17807; Wed, 5 Feb 92 16:53:55 -0500 Received: from localhost by psi.com (5.61/2.1-PSI/PSINet) id AA16084; Wed, 5 Feb 92 16:53:07 -0500 Message-Id: <9202052153.AA16084@psi.com> To: Philip Almquist Cc: brian@lloyd.com, zawada@ncsa.uiuc.edu, regional-techs, cix-tech@cix.org, mkapor@eff.org Subject: Re: The CIX and the NSFNET regionals - a dilemma In-Reply-To: Your message of "Wed, 05 Feb 92 13:22:41 PST." <9202052122.AA09102@rfc1035.pa.dec.com> Date: Wed, 05 Feb 92 16:53:06 -0500 From: "Martin Lee Schoffstall" Marty, > Leveraging off another posting elsewhere, I was wondering how hard it > would be for cisco to change their architecture to have multiple routing > tables and slightly modify their protocol prioritization scheme so that > telnet/rlogin is not just prioritized but goes out a different path > (specifically the CIX path). In general, TOS support in routers is pretty easy, though it may not be in Cisco's case depending on how they designed their fast switching stuff. In theory, of course, Cisco is adding TOS support since they are adding OSPF and TOS is a part of OSPF, but I don't know whether theory matches practice in this case (it doesn't in the case of some other OSPF vendors). Actually I was proposing that this be handled outside of setting TOS bits, but I wasn't clear. basically if I own a router from cisco today i can prioritize my interface traffic using the "priority-list" command. i select by protocol. Could that concept be built on to give me per port control over my routing in the future? who knows. Marty - - - - - - - - - - - - - - - - - From brian@lloyd.com Thu Feb 6 07:45:19 1992 Received: from ray.lloyd.COM by merit.edu (5.65/1123-1.0) id AA06531; Thu, 6 Feb 92 07:45:19 -0500 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA22062; Wed, 5 Feb 92 15:36:17 PST Date: Wed, 5 Feb 92 15:36:17 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9202052336.AA22062@ray.lloyd.com> To: schoff@psi.com Cc: almquist@jessica.stanford.edu, zawada@ncsa.uiuc.edu, regional-techs, cix-tech@cix.org, mkapor@eff.org In-Reply-To: "Martin Lee Schoffstall"'s message of Wed, 05 Feb 92 16:53:06 -0500 <9202052153.AA16084@psi.com> Subject: The CIX and the NSFNET regionals - a dilemma Reply-To: brian@lloyd.com No Marty. You are going to need either TOS routing or routing based on source address. The cleanest solution is TOS routing because most routers will include that feature in the near future. Now we need to get the host application software to follow suit or we need a hack that will cause a router to turn on the appropriate TOS bits when it sees a non-RE source address. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 - - - - - - - - - - - - - - - - - From schoff@psi.com Thu Feb 6 09:07:29 1992 Received: from psi.com by merit.edu (5.65/1123-1.0) id AA08275; Thu, 6 Feb 92 09:07:29 -0500 Received: from localhost by psi.com (5.61/2.1-PSI/PSINet) id AA02841; Thu, 6 Feb 92 09:06:21 -0500 Message-Id: <9202061406.AA02841@psi.com> To: brian@lloyd.com Cc: almquist@jessica.stanford.edu, zawada@ncsa.uiuc.edu, regional-techs, cix-tech@cix.org, mkapor@eff.org Subject: Re: The CIX and the NSFNET regionals - a dilemma In-Reply-To: Your message of "Wed, 05 Feb 92 15:36:17 PST." <9202052336.AA22062@ray.lloyd.com> Date: Thu, 06 Feb 92 09:06:19 -0500 From: "Martin Lee Schoffstall" true TOS needs the hosts to participate - not likely in this century, the installed base is too large. subverting TOS with a router override is doable because you only have to change about 10K routers. whether you should TOS for R&E vs usefuly things like high bandwith or low latency should be debated. but it is doable provided I carry around multiple routing tables in my router. Marty ----- No Marty. You are going to need either TOS routing or routing based on source address. The cleanest solution is TOS routing because most routers will include that feature in the near future. Now we need to get the host application software to follow suit or we need a hack that will cause a router to turn on the appropriate TOS bits when it sees a non-RE source address. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 - - - - - - - - - - - - - - - - - From cert-advisory-request@cert.sei.cmu.edu Thu Feb 6 16:15:49 1992 Received: from tictac.cert.sei.cmu.edu by merit.edu (5.65/1123-1.0) id AA19171; Thu, 6 Feb 92 16:15:49 -0500 Received: by tictac.cert.sei.cmu.edu (5.65/2.5) id AA03485; Thu, 6 Feb 92 15:58:11 -0500 Message-Id: <9202062058.AA03485@tictac.cert.sei.cmu.edu> From: CERT Advisory Date: Thu, 6 Feb 92 15:57:37 EST To: cert-advisory@cert.sei.cmu.edu Subject: CERT Advisory - Michelangelo PC Virus Warning Organization: Computer Emergency Response Team : 412-268-7090 =========================================================================== CA-92:02 CERT Advisory February 6, 1992 Michelangelo PC Virus Warning --------------------------------------------------------------------------- The Computer Emergency Response Team/Coordination Center (CERT/CC) has received information concerning a personal computer virus known as Michelangelo. The virus affects IBM PCs and compatibles. A description of the virus, along with suggested countermeasures, is presented below. --------------------------------------------------------------------------- I. Description The Michelangelo virus is a computer virus that affects PCs running MS-DOS (and PC-DOS, DR-DOS, etc.) versions 2.xx and higher. Note, however, that although the virus can only execute on PCs running these versions of DOS, it can infect and damage PC hard disks containing other PC operating systems including UNIX, OS/2, and Novell. Thus, booting an infected DOS floppy disk on a PC that has, for example, UNIX on the hard disk would infect the hard disk and would probably prevent the UNIX disk from booting. The virus infects floppy disk boot sectors and hard disk master boot records (MBRs). When the user boots from an infected floppy disk, the virus installs itself in memory and infects the partition table of the first hard disk (if found). Once the virus is installed, it will infect any floppy disk that the user accesses. Some possible, though not conclusive, symptoms of the Michelangelo virus include a reduction in free/total memory by 2048 bytes, and some floppy disks that become unusable or display "odd" graphic characters during "DIR" commands. Additionally, integrity management products should report that the MBR has been altered. Note that the Michelangelo virus does not display any messages on the PC screen at any time. II. Impact The Michelangelo virus triggers on any March 6. On that date, the virus overwrites critical system data, including boot and file allocation table (FAT) records, on the boot disk (floppy or hard), rendering the disk unusable. Recovering user data from a disk damaged by the Michelangelo virus will be very difficult. III. Solution Many versions of anti-virus software released after approximately October 1991 will detect and/or remove the Michelangelo virus. This includes numerous commercial, shareware, and freeware software packages. Since this virus was first detected around the middle of 1991 (after March 6, 1991), it is crucial to use current versions of these products, particularly those products that search systems for known viruses. The CERT/CC has not formally reviewed, evaluated, or endorsed any of the anti-virus products. While some older anti-virus products may detect this virus, the CERT/CC strongly suggests that sites verify with their anti-virus product vendors that their product will detect and eradicate the Michelangelo virus. The CERT/CC advises that all sites test for the presence of this virus before March 6, which is the trigger date. If an infection is discovered, it is essential that the user examine all floppy disks that may have come in contact with an infected machine. As always, the CERT/CC strongly urges all sites to maintain good backup procedures. --------------------------------------------------------------------------- The CERT/CC wishes to thank for their assistance: Mr. Christoph Fischer of the Micro-BIT Virus Center (Germany), Dr. Klaus Brunnstein of the Virus Test Center (Germany), Mr. A. Padgett Peterson, P.E., of the Technical Computing Center at Martin-Marietta Corp., and Mr. Steve R. White of IBM's Thomas J. Watson Research Center. --------------------------------------------------------------------------- If you believe that your system has been compromised, contact CERT/CC or your representative in FIRST (Forum of Incident Response and Security Teams). Internet E-mail: cert@cert.sei.cmu.edu Telephone: 412-268-7090 (24-hour hotline) CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4), on call for emergencies during other hours. Computer Emergency Response Team/Coordination Center (CERT/CC) Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Past advisories, information about FIRST representatives, and other information related to computer security are available for anonymous ftp from cert.sei.cmu.edu (192.88.209.5). - - - - - - - - - - - - - - - - - From bsb Fri Feb 7 08:45:43 1992 Received: by merit.edu (5.65/1123-1.0) id AA09966; Fri, 7 Feb 92 08:45:51 -0500 From: "Belinda Sue Blair" Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA09943; Fri, 7 Feb 92 08:45:43 -0500 Received: by home.merit.edu (4.1/client-0.9) id AA23361; Fri, 7 Feb 92 08:45:41 EST Date: Fri, 7 Feb 92 08:45:41 EST Message-Id: <9202071345.AA23361@home.merit.edu> To: nwg Subject: Additions to the NSFNET policy-based routing database The following networks have been added to the NSFNET policy-based routing database: T1 Network: Net # Net Name Primary Secondary Location -------- ----------- ------- --------- -------- 192.146.147 DGSD 195 Digital Sound Corporation, 6307 Carpinteria Ave., Carpinteria, CA 93013, USA 192.146.101 LEXMARK-DMZ 750 756 Lexmark International Inc., 740 New Circle Road, Northwest, Lexington, KY 40511, USA 192.138.207 CRIC-NET 560 281 Collaborative Research Incorporated, 1365 Main Street, Waltham, MA 02154, USA 192.138.179 NEMC-NET3 1384 1383 Tufts University, 169 Holland Street, Somerville, MA 02144, USA 192.138.178 NEMC-NET2 1384 1383 Tufts University, 169 Holland Street, Somerville, MA 02144, USA 192.138.177 NEMC-NET1 1384 1383 Tufts University, 169 Holland Street, Somerville, MA 02144, USA 192.138.168 UTEXAS-MSI 281 114 University of Texas at Austin, Marine Science Institute at Port Aransas, 750 Channel View Drive, Port Aransas, TX 78373, USA 192.138.161 STEDWARDS 280 114 St. Edwards University, 3001 S. Congress Ave., Austin, TX 78704, USA 192.136.128 LABCOM-IG 184 164 US Army Laboratory Command, US Army LABCOM, 2800 Powder Mill Rd., Adelphi, MD 20772, USA 192.136.127 WSMR-NET13 164 184 USAISC-TWS-V, Commander, USAISC-WS, White Sands Missle Range, NM 88002, USA 192.136.126 WSMR-NET12 164 184 US Army Atmospheric Sciences Lab, Commander/Director, US Army Atmospheric Sciences Lab, SLCAS-D, WSMR, NM 88002, USA 192.136.125 WSMR-NET11 164 184 USAISC-TWS-V, Commander, USAISC-WS, White Sands Missle Range, NM 88002, USA 192.136.124 MCPH-NET4 184 164 DAIG, HQDA, Attn: SAIG-IR, Washington, DC 20310-1730, USA 192.136.123 MCPH-NET3 184 164 DAIG, HQDA, Attn: SAIG-IR, Washington, DC 20310-1730, USA 192.136.122 MCPH-NET2 184 164 DAIG, HQDA, Attn: SAIG-IR, Washington, DC 20310-1730, USA 192.136.121 MCPH-NET1 184 164 DAIG, HQDA, Attn: SAIG-IR, Washington, DC 20310-1730, USA 134.184 VUB-ULB 590 Vrije Universiteit Brussel + Universite Libre de Bruxelles, Rekencentrum; Pleinlaan 2; B-1050 Brussels, BELGIUM 132.209 UQTR-IP-NET 603 601 Universite du Quebec a Trois-Rivieres, 3351 Boulevarde Des Forges, Quebec G9A 5H7, CANADA 192.135.195 NT02 1238 701 Norwegian Telecom Research, NTR, P.O box 83, N-2007 Kjeller, NORWAY 192.135.194 NT01 1238 701 Norwegian Telecom Research, NTR, P.O box 83, N-2007 Kjeller, NORWAY 192.82.158 VMU-NET 590 Veterinaermedizinische Universitaet Wien, EDV-Zentrum; Linke Bahngasse 11; A-1030 Wien, AUSTRIA 192.71.193 UHA-LAN 1238 701 University Council (UHA), UHA, Box 45501, S-104 30 Stockholm, SWEDEN 192.31.114 DRINET 200 201 Novell, Inc., 2180 Fortune Drive, San Jose, CA 95131, USA 157.238 SESQUI-2 114 280 Rice University-Sesquinet, 6100 South Main, Houston, TX 77251, USA 156.106 ITU-GVA-1 590 1238 International Telecommunications Union, Place de Nations, CH-1211 Geneva 20, SWITZERLAND 156.26 SHOCKNET 93 Wichita State University, 1845 Fairmount, Wichita, KS 67208-1595, USA 192.112.84 AGSIMNET 210 209 American Graduate School of International Management, 15249 North 59th Avenue, Glendale, AZ 85306, USA 192.109.58 FRIEDE 701 1238 Friede Beratungsgesellschaft mbH, Westendstr. 117, D-W-8000 Muenchen 2, GERMANY 192.109.31 EMBNET-HH 293 291 n/a, GERMANY 192.92.69 INFOLAN 174 Infonet, Inc., 2100 E. Grand Avenue, M/S B237, P.O. Box 1022, El Segundo, CA 90245, USA 192.135.215 NTBNR 114 280 Northern Telecom/Bell Northern Research, 2201 Lakeside, Richardson, TX 75081, USA 192.135.196 NT03 1238 701 Norwegian Telecom Research, NTR, P.O box 83, N-2007 Kjeller, NORWAY 155.222 RIA-6-NET 164 184 USAISC-AMCCOM, Attn: ASQNC-ARI-IOC-N, Rock Island Arsenal, Rock Island, IL 61299-7210, USA 152.88 DDETH 590 1238 EMA-EAWAG, Ueberlandstrasse 129/133, CH-8600 Duebendorf, SWITZERLAND 147.191 USWSIS 209 210 US West Inc., 9785 Maroon Circle #160, Englewood, CO 80112, USA 144.197 LADC 174 750 Lockheed Advanced Development Company, P.O. Box 250, Plant B6 Building 311, Sunland, CA 91041-3702, USA 142.76 SUNNYBROOK 601 602 Sunnybrook Health Science Centre, Rm S-131, 2075 Bayview Ave., North York, Ontario M4N 3M5, CANADA 141.61 MPIB-NET 293 291 Max-Planck-Institut fuer Biochemie , Rechenzentrum Am Klopferspitz D-W- 8033 Martinsried, GERMANY 192.88.203 PGWKS 701 279 PageWorks, 36 John F. Kennedy Street, Cambridge, MA 02138, USA 192.86.8 MUSE-ETHER2 200 754 MicroUnity Systems Engineering, Incorporated, 4699 Old Ironsides, Suite 410, Santa Clara, CA 95054, USA 192.84.1 BBN-SYSENGRC1 1384 1383 BBN Communications, 150 Cambridge Park Drive, Cambridge, MA 02140, USA 192.136.41 TREVANO 590 1238 Scuola Tecnica Superiore, CH-6952 Canobbio, SWITZERLAND Total NSFNET T1 announced networks: 4601 T3 Network: Network IP: 192.31.114 Network Name: DRINET Location: Novell, Inc., 2180 Fortune Drive, San Jose, CA 95131, USA Country Code: US 1:200 BARRNet 2:201 BARRNet Network IP: 192.84.1 Network Name: BBN-SYSENGRC1 Location: BBN Communications, 150 Cambridge Park Drive, Cambridge, MA 02140, USA Country Code: US 1:560 NEARnet Regional Network 2:281 NEARnet Regional Network Network IP: 192.86.8 Network Name: MUSE-ETHER2 Location: MicroUnity Systems Engineering, Incorporated, 4699 Old Ironsides, Suite 410, Santa Clara, CA 95054, USA Country Code: US 1:200 BARRNet Network IP: 192.88.203 Network Name: PGWKS Location: PageWorks, 36 John F. Kennedy Street, Cambridge, MA 02138, USA Country Code: US 42:702 Alternet Router Network IP: 192.108.246 Network Name: ARD-NET Location: Federal Bureau of Investigation, 10th & Pennsylvania Ave., Washington D.C. 20535, USA Country Code: US 42:702 Alternet Router Network IP: 192.138.177 Network Name: NEMC-NET1 Location: Tufts University, 169 Holland Street, Somerville, MA 02144, USA Country Code: US 1:560 NEARnet Regional Network 2:281 NEARnet Regional Network Network IP: 192.146.101 Network Name: LEXMARK-DMZ Location: Lexmark International Inc., 740 New Circle Road, Northwest, Lexington, KY 40511, USA Country Code: US 1:1751 Lexmark, Lexington, KY Total NSFNET T3 announced networks: 1174 The configuration reports, map information sheets, and configuration files which reflect these changes are available for anonymous ftp on nis.nsf.net as usual. nsfsites - configuration reports latest report for: - NSFNET T1 has the file extension .now - NSFNET T3 has the file extension 3.now nsfconfg - configuration files for the routing software for each NSS latest report for: - NSFNET T1 has the file format config.nss# - NSFNET T3 has the file extension .t3p Please send all requests for configuration changes to nsfnet-admin@merit.edu using the NSFNET configuration forms. The forms are available on-line from the nis.nsf.net machine. Use ftp and the anonymous login to get on the machine. Do a "cd nsfsites" and grab the files TEMPLATE.NET, TEMPLATE.GATE, and TEMPLATE.AS. ************** -B. Sue Blair Merit Network Operations - - - - - - - - - - - - - - - - - From mak Mon Feb 10 12:00:06 1992 Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA06958; Mon, 10 Feb 92 12:00:06 -0500 Received: by home.merit.edu (4.1/client-0.9) id AA03364; Mon, 10 Feb 92 10:58:00 EST From: mak Message-Id: <9202101558.AA03364@home.merit.edu> To: regional-techs Subject: Merit NOC manager position Date: Mon, 10 Feb 92 10:57:58 -0500 Hi. Dale Johnson is moving to a different position at Merit, the "Network Management Systems" group manager. So this opens up the following position, FYI. Mark The University of Michigan and Merit Network, Inc. are seeking applications for the position of Network Operations Center Manager. The NOC is located at the University of Michigan, and the candidate will be employed by the University. Send applications to Tina Pryor, ITD-Resource Administration, University of Michigan, 519 W. William, Ann Arbor, MI 48109. The University of Michigan is an equal opportunity employer. Refer to the University's posting number: A-121032-TP ---------------------------------------------------------------- TITLE: Manager, Information Technology Division-Network Operations Center BASIC FUNCTION Provide management, leadership and vision in network operations for national, state, and campus networking within The University of Michigan-ITD Network Systems, including UMnet, MichNet, and the NSFNET and ANS networks. The primary focus of the Network Operations Center is hour-to-hour and day-to-day operations of the various networks, including the development and reliable execution of standard operating procedures in a 24-hour per day, 7 day per week operations environment. The Center also manages large amounts of critical configuration information, and production of routine reports on Network Performance. CHARACTERISTIC DUTIES Provide leadership and management of the Network Operations Center. Produce and guarantee reliable execution of Center responsibilities, given the resources available. Arrange for new procedures to meet the operational requirements of rapidly changing technology. Define the support needs for the Network Operations Center. Work with the Center's customers and engineering support groups to establish their operational needs. Arrange for resources to meet those needs. Respond to network and Operations Center emergencies as needed on a twenty-four hour basis. Evaluate and report on the Center's technical performance for administrative and customer audiences. Coordinate projects with other groups and managers in Network Systems and the with the Center's vendors and corporate partners. Develop staffing plans and goals, hire and train new staff, assign and prioritize projects, promote professional development and provide general functional and administrative supervision of Network Operations Center staff to meet unit objectives. Represent the Network Operations Center, Merit, and the University of Michigan on national and international committees, standards bodies, and other appropriate organizations, including providing leadership of such groups. Present the Network Operations Center, Merit, and the Networks to varied audiences via tours, lectures, and other presentations. Arrange for maintenance and physical improvements to the Network Operations Center facility. QUALIFICATIONS A Bachelor's degree in computer science, electrical engineering, applied mathematics or other related discipline. A Master's degree or an equivalent combination of education and experience is preferred. Significant knowledge and experience in the Internet and Unix environments, including knowledge and experience in managing networks using the TCP/IP protocol suite is required. Considerable knowledge of and five years experience in data networking. Three years of operations coordination experience is required, with at least two at a staff management level preferred. Ability and vision to supervise the design and coordination of large scale, complex projects, establish goals, and meet objectives is required. Ability to communicate well with technical and administrative people, and work cooperatively with staff, peer managers and upper management is required. Ability to delegate responsibility and be accessible to technical staff is required. Active participation in networking organizations at a national level is desirable. Three or more years of computer programming experience is desirable. Commitment to quality operations and a vision of the future is required. - - - - - - - - - - - - - - - - - From almquist@pa.dec.com Mon Feb 10 18:25:16 1992 Received: from inet-gw-1.pa.dec.com by merit.edu (5.65/1123-1.0) id AA17234; Mon, 10 Feb 92 18:25:16 -0500 Received: by inet-gw-1.pa.dec.com; id AA25286; Mon, 10 Feb 92 15:23:59 -0800 Received: by rfc1035.pa.dec.com; id AA02274; Mon, 10 Feb 92 15:22:38 -0800 Date: Mon, 10 Feb 92 15:22:38 -0800 Message-Id: <9202102322.AA02274@rfc1035.pa.dec.com> To: schoff@psi.com Cc: brian@lloyd.com, zawada@ncsa.uiuc.edu, regional-techs, cix-tech@cix.org, mkapor@eff.org Subject: The CIX and the NSFNET regionals - a dilemma From: Philip Almquist Sender: almquist@nsl.dec.com In-Reply-To: "Martin Lee Schoffstall"'s message of Wed, 05 Feb 92 16:53:06 -0500 <9202052153.AA16084@psi.com> Marty, > Actually I was proposing that this be handled outside of setting TOS > bits, but I wasn't clear. basically if I own a router from cisco today > i can prioritize my interface traffic using the "priority-list" command. > i select by protocol. Could that concept be built on to give me per > port control over my routing in the future? who knows. What you're trying to do is basically what TOS does: choose your outgoing path based on whether the application is most concerned about delay, throughput, or whatever. When a host doesn't set any TOS bits, a router could conceivably then peek into the packet to look at TCP ports as part of computing the next hop. However, a router that did so would probably still want to leverage off of the TOS mechanism by using the TCP ports to determine what TOS bits the host should (according to Host Requirements) have set. Philip - - - - - - - - - - - - - - - - - From donnab@CERF.NET Mon Feb 10 18:35:50 1992 Received: from nic.cerf.net by merit.edu (5.65/1123-1.0) id AA17550; Mon, 10 Feb 92 18:35:50 -0500 Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA03879; Mon, 10 Feb 92 15:38:21 PST Date: Mon, 10 Feb 92 15:38:21 PST From: Donna Bigley Message-Id: <9202102338.AA03879@nic.cerf.net> To: broidoj@Sds.Sdsc.Edu, help@CERF.NET, nsfnet-reports, ops@cerf.net Subject: CERFnet Weekly Report for the week of Monday, February 3, 1992. ############################################################################### This is the CERFnet weekly activity report for the period of Monday, February 3rd through Sunday, February 9th, 1992. This report is also available through anonymous FTP from NIC.CERF.NET [192.102.249.3] in the cerfnet/cerfnet_stats subdirectory. The filename is: 9-february-92.txt All times are in Pacific Standard Time, and in the 24-hour format. Please direct any questions or comments to: donnab@cerf.net or help@cerf.net ****************************************************************************** NETWORK OUTAGES: SITE: KOREA SITES AFFECTED: KOREA TIME STARTED: MON. 1-27-92 10:08 TIME ENDED: FRI. 2-7-92 23:23 TIME ELAPSED: 12 days 13 hours 15 min (Intermittant Outages) REASON: Link Failure (Korea Local Line Problem) SITE: DATAPRODUCTS SITES AFFECTED: DATAPRODUCTS TIME STARTED: TUE. 2-4-92 09:00 TIME ENDED: TUE. 2-4-92 15:22 TIME ELAPSED: 6 hours 22 min REASON: Link Failure SITE: QUALCOMM SITES AFFECTED: QUALCOMM TIME STARTED: TUE. 2-4-92 09:58 TIME ENDED: WED. 2-5-92 10:20 TIME STARTED: WED. 2-5-92 10:36 TIME ENDED: WED. 2-5-92 10:50 TIME ELAPSED: 24 hours 36 min REASON: Equipment Trouble SITE: UCLA SITES AFFECTED: UCLA Dial n' CERF, UCSB, ISX, Dataproducts, Santa Monica College, Quotron, Pepperdine, and Los Nettos. TIME STARTED: THU. 2-6-92 07:38 TIME ENDED: THU. 2-6-92 07:40 TIME ELAPSED: 2 min REASON: CERFnet Scheduled Maintenance SITE: CERFnet SITES AFFECTED: CERFnet TIME STARTED: THU. 2-6-92 12:00 TIME ENDED: THU. 2-6-92 15:30 TIME ELAPSED: 3 hours 30 min REASON: Routing Troubles SITE: CICESE SITES AFFECTED: CICESE TIME STARTED: THU. 2-6-92 15:28 TIME ENDED: THU. 2-6-92 16:30 TIME ELAPSED: 1 hour 2 min REASON: Unknown SITE: QUALCOMM SITES AFFECTED: QUALCOMM TIME STARTED: THU. 2-6-92 18:35 TIME ENDED: FRI. 2-7-92 06:51 TIME ELAPSED: 12 hours 16 min. REASON: Equipment Trouble SITE: UCLA SITES AFFECTED: UCLA Dial n' CERF, UCSB, ISX, Dataproducts, Santa Monica College, Quotron, Pepperdine, and Los Nettos. TIME STARTED: FRI. 2-7-92 10:14 TIME ENDED: FRI. 2-7-92 10:32 TIME ELAPSED: 18 min REASON: CERFnet Scheduled Maintenance SITE: UCOP SITES AFFECTED: UCOP Dial n' CERF, CIX-WEST, Cisco, Farallon, Apple, Intel-SC, LSIL, and NetLabs. TIME STARTED: SAT. 2-8-92 09:48 TIME ENDED: SAT. 2-8-92 16:19 TIME ELAPSED: 7 hours 11 min REASON: Site Scheduled Maintenance SITE: UCR SITES AFFECTED: UCR TIME STARTED: SUN. 2-9-92 00:06 TIME ENDED: SUN. 2-9-92 00:38 TIME ELAPSED: 32 min REASON: Unknown ------------------------------------------------------------------------ CERFNET TRAFFIC CAPACITY USAGE AT EACH CIRCUIT LINK LINK SPEED CAPACITY PEAK HOUR (PDT) SDSC/CALTECH 1.544 mbps 11.4% 19:00 SDSC/UCI 1.544 mbps 04.8% 11:00 SDSC/UCLA 1.544 mbps 05.2% 16:00 SDSC/UCOP 1.544 mbps 03.7% 16:00 UCI/UCLA 1.544 mbps 10.0% 20:00 SDSC/UCR 512 kbps 02.9% 17:00 UCLA/UCSB 512 kbps 08.1% 16:00 SDSC/AGI 1.544 mbps 00.1% 12:00 SDSC/BIOSYM 1.544 kbps 00.2% 12:00 SDSC/GA 1.544 mbps 00.1% 13:00 SDSC/GD 1.544 mbps 02.1% 10:00 SDSC/SAIC 1.544 mbps 10.0% 13:00 SDSC/SCAQMD 1.544 mbps 00.02% 10:00 SDSC/SDSU 1.544 mbps 01.2% 20:00 UCI/CSU CO(SWRL) 1.544 mbps 02.1% 20:00 UCOP/APPLE 1.544 mbps 00.7% 09:00 UCOP/CISCO 1.544 mbps 00.4% 08:00 UCR/LLUMC 1.544 mbps 00.01% 09:00 CALTECH/CADAM 56 kbps 00.6% 16:00 CALTECH/CLAREMONT 56 kbps 18.7% 14:00 CALTECH/DISNEY 56 kbps 03.4% 07:00 CALTECH/OXY 56 kbps 04.8% 15:00 SDSC/AJS 56 kbps 02.1% 16:00 SDSC/KOREA 56 kbps 04.0% 16:00 SDSC/QUALCOMM 56 kbps 07.6% 14:00 SDSC/SCIH 56 kbps 05.6% 01:00 SDSC/USD 56 kbps 06.0% 17:00 SDSC/USIU 56 kbps 01.9% 11:00 SDSC/XEROX 56 kbps 00.9% 08:00 UCI/CMD 56 kbps 05.3% 20:00 UCI/EMULEX 56 kbps 01.3% 15:00 UCI/FULLERTON 56 kbps 01.8% 13:00 UCI/HUGHES 56 kbps 10.6% 15:00 UCI/MTI 56 kbps 03.5% 19:00 UCI/SPARTA 56 kbps 04.4% 05:00 UCI/UNOCAL 56 kbps 08.3% 05:00 UCLA/ISX 56 kbps 00.8% 13:00 UCLA/PEPPERDINE 56 kbps 01.7% 07:00 UCLA/QUOTRON 56 kbps 08.4% 13:00 UCLA/SMC 56 kbps 01.1% 19:00 UCOP/FARALLON 56 kbps 03.2% 10:00 UCOP/INTEL 56 kbps 12.4% 15:00 UCOP/LSIL 56 kbps 07.7% 22:00 UCOP/NETLABS 56 kbps 20.1% 19:00 ------------------------------------------------------------------------------ SITE CISCO BOX UPTIME SINCE LAST REBOOT (as of 00:15 PST on Feb. 10, 1992): CERFnet BACKBONE CALTECH [131.215.139.253] Up: 11 days 16 hours 29 minutes SDSC Drzog [132.249.16.13] Up: 57 days 08 hours 25 minutes SDSC Hang10 [132.249.16.15] Up: 03 days 09 hours 52 minutes [Routing Troubles] UCI [128.200.1.101] Up: 31 days 16 hours 07 minutes UCLA [128.97.130.10] Up: 02 days 13 hours 42 minutes [CERFnet Scheduled Maintenance] UCOP [134.24.52.112] Up: 01 days 08 hours 57 minutes [Site Scheduled Maintenance] UCR [134.24.108.105] Up: 86 days 12 hours 36 minutes CERF 1544 AGI [134.24.202.110] Up: 44 days 17 hours 54 minutes APPLE [134.24.70.200] Up: 105 days 06 hours 15 minutes BIOSYM [134.24.57.200] Up: 07 days 06 hours 48 minutes CISCO Systems [134.24.54.200] Up: 68 days 14 hours 09 minutes CSUCO/SWRL [130.150.102.200] Up: 26 days 12 hours 46 minutes GA [134.24.221.200] Up: 09 days 16 hours 37 minutes GD [134.24.60.200] Up: 39 days 04 hours 14 minutes LLUMC [134.24.208.200] Up: 82 days 12 hours 22 minutes SAIC [134.24.53.208] Up: 36 days 08 hours 34 minutes SCAQMD [134.24.234.200] Up: 52 days 14 hours 27 minutes SDSU [192.77.100.101] Up: 62 days 16 hours 31 minutes UCSB [134.24.107.107] Up: 82 days 07 hours 38 minutes CERF 56 AJS [134.24.225.101] Up: 23 days 14 hours 17 minutes CADAM [134.24.229.200] Up: 05 days 13 hours 01 minutes [Site Activity] CLAREMONT [134.24.206.109] Up: 04 days 12 hours 32 minutes [Site Activity] CMD [134.24.218.200] Up: 13 days 13 hours 14 minutes DATAPRODUCTS [134.24.211.104] Up: 16 days 15 hours 19 minutes DISNEY [134.24.207.211] Up: 11 days 00 hours 33 minutes EMULEX [134.24.209.212] Up: 57 days 15 hours 48 minutes FARALLON [134.24.56.200] Up: 02 days 06 hours 24 minutes [Unknown] FULLERTON [134.24.214.217] Up: 55 days 15 hours 33 minutes HUGHES [134.24.204.200] Up: 87 days 07 hours 21 minutes INTEL [134.24.55.200] Up: 43 days 03 hours 19 minutes LSIL [134.24.72.200] Up: 01 days 13 hours 08 minutes [Site Activity] MTI [134.24.216.100] Up: 37 days 13 hours 39 minutes NETLABS [134.24.71.200] Up: 65 days 15 hours 07 minutes OXY [134.24.205.108] Up: 06 days 17 hours 13 minutes [Unknown] PEPPERDINE [134.24.203.218] Up: 36 days 13 hours 24 minutes QUALCOMM [134.24.200.201] Up: 02 days 17 hours 23 minutes [Equipment Trouble] QUOTRON [134.24.230.202] Up: 76 days 13 hours 44 minutes SANTA MONICA [134.24.210.219] Up: 31 days 01 hours 22 minutes SCI-HOR [134.24.109.205] Up: 73 days 11 hours 15 minutes SERI/KOREA [134.24.223.200] Up: 139 days 00 hours 00 minutes SPARTA [134.24.215.200] Up: 23 days 14 hours 57 minutes UNOCAL [134.24.217.200] Up: 18 days 14 hours 24 minutes USD [134.24.201.106] Up: 11 days 15 hours 45 minutes USIU [134.24.222.215] Up: 218 days 17 hours 07 minutes XEROX [134.24.51.207] Up: 102 days 23 hours 22 minutes DIAL n' CERF DNC-SDSC [134.24.1.2] Up: 26 days 04 hours 51 minutes DNC-UCI [134.24.2.2] Up: 33 days 03 hours 24 minutes DNC-UCLA [134.24.3.2] Up: 18 days 12 hours 38 minutes DNC-CALTECH [134.24.4.2] Up: 11 days 16 hours 28 minutes DNC-UCOP [134.24.5.2] Up: 01 days 08 hours 58 minutes [Site Scheduled Maintenance] - - - - - - - - - - - - - - - - - From skw Tue Feb 11 06:29:27 1992 Received: by merit.edu (5.65/1123-1.0) id AA02284; Tue, 11 Feb 92 06:29:31 -0500 From: "Steven K. Widmayer" Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA02278; Tue, 11 Feb 92 06:29:27 -0500 Received: by home.merit.edu (4.1/client-0.9) id AA26053; Tue, 11 Feb 92 06:29:26 EST Date: Tue, 11 Feb 92 06:29:26 EST Message-Id: <9202111129.AA26053@home.merit.edu> To: nwg Subject: Additions to the NSFNET policy-based routing database -- postponed Cc: nsr Due to problems with the operating system used to generate the NSFNET routing configuration files, the normal Tuesday morning update has been rescheduled for Wednesday morning during the 05:00 - 08:00 EST window. Apologies for any inconvenience this delay will cause. --Steve Widmayer Merit/NSFNET - - - - - - - - - - - - - - - - - From schoff@psi.com Tue Feb 11 12:05:54 1992 Received: from psi.com by merit.edu (5.65/1123-1.0) id AA10884; Tue, 11 Feb 92 12:05:54 -0500 Received: from localhost by psi.com (5.61/2.1-PSI/PSINet) id AA15759; Tue, 11 Feb 92 12:05:25 -0500 Message-Id: <9202111705.AA15759@psi.com> To: Philip Almquist Cc: brian@lloyd.com, zawada@ncsa.uiuc.edu, regional-techs, cix-tech@cix.org, mkapor@eff.org Subject: Re: The CIX and the NSFNET regionals - a dilemma In-Reply-To: Your message of "Mon, 10 Feb 92 15:22:38 PST." <9202102322.AA02274@rfc1035.pa.dec.com> Date: Tue, 11 Feb 92 12:05:20 -0500 From: "Martin Lee Schoffstall" Marty, > Actually I was proposing that this be handled outside of setting TOS > bits, but I wasn't clear. basically if I own a router from cisco today > i can prioritize my interface traffic using the "priority-list" command. > i select by protocol. Could that concept be built on to give me per > port control over my routing in the future? who knows. What you're trying to do is basically what TOS does: choose your outgoing path based on whether the application is most concerned about delay, throughput, or whatever. yes. When a host doesn't set any TOS bits, a router could conceivably then peek into the packet to look at TCP ports as part of computing the next hop. However, a router that did so would probably still want to leverage off of the TOS mechanism by using the TCP ports to determine what TOS bits the host should (according to Host Requirements) have set. agreed. the router could send a ICMP SET_YOUR_TOS_BIT,_DUMMY to the host. ;-) m - - - - - - - - - - - - - - - - - From smr Tue Feb 11 16:55:56 1992 Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA18877; Tue, 11 Feb 92 16:55:56 -0500 Received: by home.merit.edu (4.1/client-0.9) id AA09073; Tue, 11 Feb 92 16:55:55 EST Date: Tue, 11 Feb 92 16:55:55 EST From: smr Message-Id: <9202112155.AA09073@home.merit.edu> To: regional-techs Subject: Advanced Topics Questionnaire Cc: seminar Hello all- Some of the comments that we heard in the aftermath of our recent Advanced Topics Seminar suggests that perhaps it is time to rethink its content and format. Thus, we have compiled a small questionnaire that should help us in this decision. We are hoping that you will respond whether you came to the January seminar or to a previous one(s). For those who wish to make specific comments about this past seminar, which the set of questions below does not directly elicit, please feel free to do so. Sincerely, Sheri Repucci Merit/Internet Engineering =================================================================== ** Please send responses to seminar@merit.edu ** A. Did you attend this past seminar? (y/n) If no, why? If yes.... 1. Which topics did you find most useful? 2. Which topics did you find least useful? 3. Are there topics you would like to see at a future seminar? B. Format of Seminar 1. Have you attended any of our Advanced Topics Seminars? (y/n) 2. Does the current format of the seminar meet your needs? Current defined as a mix of about 40% regional issues and 60% advanced topics sessions. (y/n) 3. If it does not meet your needs.... a. Would you prefer to meet just with the other regionals (ie: no advanced topics sessions)? b. Would you prefer a greater concentration on regional issues (perhaps 75% regional 25% advanced topics sessions)? c. Would you prefer two different events? One meeting with just regionals and one to present advanced topics, at different times in the year? d. Other: C. Comments: - - - - - - - - - - - - - - - - - From skw Wed Feb 12 10:50:20 1992 Received: by merit.edu (5.65/1123-1.0) id AA13229; Wed, 12 Feb 92 10:50:32 -0500 From: "Steven K. Widmayer" Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA13190; Wed, 12 Feb 92 10:50:20 -0500 Received: by home.merit.edu (4.1/client-0.9) id AA25481; Wed, 12 Feb 92 10:50:16 EST Date: Wed, 12 Feb 92 10:50:16 EST Message-Id: <9202121550.AA25481@home.merit.edu> To: nwg Subject: Additions to the NSFNET policy-based routing database The following networks have been added to the NSFNET policy-based routing database: T1 Network: Net # Net Name Primary Secondary Location -------- ----------- ------- --------- -------- 130.97 DOERLNET 68 Boeing Computer Services, 825 Jadwin Avenue, Richland, WA 99352 133.53 JAERINET 372 297 Japan Atomic Energy Reserch Institute, JAPAN 136.224 SUC-TECH-ALF 174 Alfred SUC of Technology, Alfred State University College of Technology, Alfred, NY 141.53 UNIHGW-LAN 293 291 Universitaet Greifswald, D-O-2200 Greifswald, GERMANY 144.228 SPRINT-INNET5 1240 Sprint/United Information Service, 1200 Main Street, M/S MOKCMT062, Kansas City, MO 64105 145.23 KNMI-NET 590 Royal Netherlands Meteorological Institute, P.O. Box 201, 3730 AE DE BILT, NETHERLANDS 146.155 INTER-CHILE 86 279 SECICO, Vicuna Mackena 4860, Santiago, CHILE 147.173 CNRSGRENOBLE 1238 701 CNRS, 15 Avenue des Martyrs, B.P. 166, 38042 Grenoble CEDEX 09, FRANCE 153.5 YUNAC-NET 590 YUNAC - Yugoslav Network for the Academic Community, Jamova 39, 61000 Ljubljana, Slovenia, YUGOSLAVIA 156.111 CPMC 174 Columbia-Presbyterian Medical Center, 161 Fort Washington Av., New York, NY 10032 157.169 ESSI 1238 701 ESSI - Universite de Nice, Batiment CERISI, BP 132, 06561 Sophia-Antipolis CEDEX, FRANCE 192.5.190 ANLNET21 293 291 Argonne National Laboratory, 9700 South Cass Avenue, Argonne, IL 60439 192.5.191 ANLNET22 293 291 Argonne National Laboratory, 9700 South Cass Avenue, Argonne, IL 60439 192.5.192 ANLNET23 293 291 Argonne National Laboratory, 9700 South Cass Avenue, Argonne, IL 60439 192.5.193 ANLNET24 293 291 Argonne National Laboratory, 9700 South Cass Avenue, Argonne, IL 60439 192.26.239 UP-PT 701 1238 University of Porto, CIUP, R.Campo Alegre 823, 4100 Porto, PORTUGAL 192.75.177 OISENET 601 602 Ontario Instiute for Studies in Education, Computing Services Group, 252 Bloor St. W, Rm3-340, Toronto, Ontario M5S 1V6, CANADA 192.77.155 LEGI-DMZ 750 756 Legi-Slate, 777 North Capitol St. NE, Suite 900, Washington, DC 20002 192.82.214 FEUPNET 701 1238 FACULDADE DE ENGENHARIA UNIVERSIDADE DO PORTO, CIUP, R.Campo Alegre 823, 4100 Porto, PORTUGAL 192.92.135 FCUP-NET 701 1238 University of Porto - Faculty of Sciences network, CIUP, R.Campo Alegre 823, 4100 Porto, PORTUGAL 192.93.178 ERGENS 1238 701 E.N.S.E.R.G., 23 Rue des Martyrs, F-38016 Grenoble CEDEX, FRANCE 192.108.218 ARC-SIMFACNET 372 297 NASA Ames Research Center, MS 233-8, Moffett Field, CA 94035 192.124.229 TENET-POP-10 280 114 University of Texas System K-12 nets, University of Texas System Services Building, Austin Texas 78712 192.131.239 VSLA 86 279 Virginia State Library and Archives, Library Automation and Networking Division, 11th Street at Capitol Square, Richmond, VA 23219 192.132.85 FTKNOX-NET5 184 164 USAISC-DOIM, USAISC-FTKNOX, Attn: ASQNB-ZKO-I, Bldg 1227, Fort Knox, KY 40121-5660 192.133.72 BCNET1 372 297 HONG KONG BAPTIST COLLEGE, 224 Waterloo Road, Kowloon, HONG KONG 192.135.84 HAMP-SYD-NET 297 372 Hampton Sydney College, P.O. Box 856, Hampden-Sydney, VA 23943-0856 192.135.169 CIBA-GEIGY1 97 Ciba-Geigy, 556 Morris Avenue, Summit, NJ 07901 192.135.170 CIBA-GEIGY2 97 Ciba-Geigy, 556 Morris Avenue, Summit, NJ 07901 192.135.171 CIBA-GEIGY3 97 Ciba-Geigy, 556 Morris Avenue, Summit, NJ 07901 192.135.172 CIBA-GEIGY4 97 Ciba-Geigy, 556 Morris Avenue, Summit, NJ 07901 192.135.173 CIBA-GEIGY5 97 Ciba-Geigy, 556 Morris Avenue, Summit, NJ 07901 192.138.176 NEMC-NET1 1384 1383 Tufts University, 169 Holland Street, Somerville, MA 02144 192.146.104 VADIT 86 279 Department of Information Technology, 110 S. 7th Street, Richmond, VA 23219 192.146.161 HITACHI-ASL1 97 Hitachi America, Ltd., 307 College Road East, Princeton NJ 08540 192.146.162 HITACHI-ASL2 97 Hitachi America, Ltd., 307 College Road East, Princeton NJ 08540 192.146.243 KVCC 233 177 Kalamazoo Valley Community College, Kalamazoo, MI 49007 192.146.244 CIESIN-AA 233 177 CIESIN, P.O. Box 8689, Ann Arbor, MI 48107 Total NSFNET T1 announced networks: 4637 The following T1 gates have also been added: Router Internet Address: 192.52.195.16 Router Internet Name: ICM-FIX-W.CIT.CORNELL.EDU Router AS Number: 1240 (USSPRINT - Palo Alto, CA) NSS number colocated with router: 13 Router type: AGS+/Cisco Router Internet Address: 192.54.222.9 Router Internet Name: Cambridge.MA.ALTER.NET Router AS Number: 702 (Alternet at Boston) NSS number colocated with router: 8 Router type: cisco IGS/R T3 Network: 180 T1 configured SURAnet networks (not listed here) have been added to the T3 database. Network IP: 129.33 Network Name: IBM-ALMADEN Location: IBM Corporation, Almaden Research Center, 650 Harry Road, San Jose, CA 95120 Country Code: US 1:1747 IBM Watson, Yorktown Heights, NY Network IP: 192.77.155 Network Name: LEGI-DMZ Location: Legi-Slate, 777 North Capitol St. NE, Suite 900, Washington, DC 20002 Country Code: US 1:1327 ANS Washington D.C. - DNSS 59 Network IP: 192.138.176 Network Name: NEMC-NET1 Location: Tufts University, 169 Holland Street, Somerville, MA 02144 Country Code: US 1:560 NEARnet Regional Network 2:281 NEARnet Regional Network Network IP: 192.146.243 Network Name: KVCC Location: Kalamazoo Valley Community College, Kalamazoo, MI 49007 Country Code: US 1:237 MERIT network Network IP: 192.146.244 Network Name: CIESIN-AA Location: CIESIN, P.O. Box 8689, Ann Arbor, MI 48107 Country Code: US 1:237 MERIT network Total NSFNET T3 announced networks: 1357 The following T3 gates have also been added: AS Number: 86 AS Notes: ENSS 136, College Park AS Country Code: US ANS: No BkBn: 690 NSS: 140.222.136 - ENSS136 College Park, MD Gate: 192.80.214.1 - sura1.sura.net ENSS 136, College Park, MD Gate: 192.80.214.3 - sura3.sura.net ENSS 136, College Park, MD Gate: 192.80.214.4 - sura4.sura.net ENSS 136, College Park, MD Gate: 192.80.214.7 - sura7.sura.net ENSS 136, College Park, MD Gate: 192.80.214.8 - sura8.sura.net ENSS 136, College Park, MD Gate: 192.80.214.12 - sura12.sura.net ENSS 136, College Park, MD AS Number: 600 AS Notes: OARNET, Cleveland, OH AS Country Code: US ANS: Yes BkBn: 690 NSS: 140.222.168 - ENSS 168 - OARnet Cleveland, OH Gate: 192.88.195.1 - gwcsp1.oar.net OARNET, Cleveland, OH AS Number: 1751 AS Notes: Lexmark, Lexington, KY AS Country Code: US ANS: Yes BkBn: 690 NSS: 140.222.165 - ENSS 165 - Lexmark Lexington, KY Gate: 192.146.101.3 - lexgw.lexmark.com Lexmark, Lexington, KY The configuration reports, map information sheets, and configuration files which reflect these changes are available for anonymous ftp on nis.nsf.net as usual. nsfsites - configuration reports latest report for: - NSFNET T1 has the file extension .now - NSFNET T3 has the file extension 3.now nsfconfg - configuration files for the routing software for each NSS latest report for: - NSFNET T1 has the file format config.nss# - NSFNET T3 has the file extension .t3p Please send all requests for configuration changes to nsfnet-admin@merit.edu using the NSFNET configuration forms. The forms are available on-line from the nis.nsf.net machine. Use ftp and the anonymous login to get on the machine. Do a "cd nsfsites" and grab the files TEMPLATE.NET, TEMPLATE.GATE, and TEMPLATE.AS. --Steve Widmayer Merit/NSFNET - - - - - - - - - - - - - - - - - From nwg-owner Wed Feb 12 18:23:53 1992 Received: by merit.edu (5.65/1123-1.0) id AA24901; Wed, 12 Feb 92 18:23:56 -0500 Received: from sol.sura.net by merit.edu (5.65/1123-1.0) id AA24893; Wed, 12 Feb 92 18:23:53 -0500 Received: by sol.sura.net (5.65+/($Id: sendmail.cf,v 1.19 1991/07/18 01:38:01 jmalcolm Exp $)) id AA21841; Wed, 12 Feb 92 18:18:11 -0500 Date: Wed, 12 Feb 92 18:18:11 -0500 From: oleary@sura.net Message-Id: <9202122318.AA21841@sol.sura.net> To: nwg Subject: T3 backbone stability We are cutting over to use the T3 backbone now, and I am concerned by the several recent messages about ENSS and CNSS problems. Could someone at Merit summarize some of the recent outages if there have been trends, or could some of the other midlevels provide us with some insight as to how (in)stability has affected your connections? We are going with the emerging standard of send T3 stuff to the T3 and T1 stuff to the T1, explicitly importing T3 routes and defaulting everything else to the T1. thanks, dave o'leary SURAnet - - - - - - - - - - - - - - - - - From mak Thu Feb 13 01:34:49 1992 Received: by merit.edu (5.65/1123-1.0) id AA04729; Thu, 13 Feb 92 01:34:52 -0500 From: "Mark Knopper" Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA04725; Thu, 13 Feb 92 01:34:49 -0500 Received: by home.merit.edu (4.1/client-0.9) id AA11502; Thu, 13 Feb 92 01:34:49 EST Message-Id: <9202130634.AA11502@home.merit.edu> To: nwg Subject: T3 backbone stability Date: Thu, 13 Feb 92 01:34:48 -0500 Dave, I have summarized and enclosed below our trouble tickets written over the last 5 days for the T3 network. The only problem that affected more than one peer site was a crash of CNSS40 at Cleveland yesterday afternoon due to a hardware problem. While a CNSS crash of this type would not normally cause users loss of connectivity due to backbone redundancy, this crash did result in connectivity loss since the Ann Arbor interconnect E131 which is homed int o the Cleveland POP became reachable via the safety net T1 links only. The interconnect gateway was switched over to Houston during this time. This resulted in a 25 minute outage of the interconnect. The last T3 router crash we had was several weeks ago and the last hardware induced crash was several months ago. While this is an undesirable event, I suspect that SURAnet's use of the T3 backbone may actually reduce your dependency on the interconnect gateways. We have installed new software (build 64 and new rcp_routed) across the T3 system during the last two weeks with additional performance and reliability enhancements including improved aggregation of interior routing updates, faster convergence time, and reduced CPU utilization. Operationally we have begun the on-call schedule for the new NNAF engineering group which has resulted in some more detailed NSR reports on these scheduled and unscheduled events. This event coupled with the numerous scheduled software installations may have given you the false impression that there was an increase in problems. My general conclusion is that while we have still have some problems with the current T3 adapter technology, this has been manageable and the T3 backbone is still very reliable. We will cautiously monitor the network reliability for changes as we add additional traffic to the T3 system. The T 1 network is not nearly as reliable and we are busy working on those problems. Mark Peer network router problems: 18410 - SURAnet sura7.sura.net 18429 - BARRnet equipment move 18441 - Pittsburgh power failure Backbone router hardware problems: 18423 - cisco serial interface, Xlink (Germany) 18426 - cnss40 spare t3 card removed from backplane to reduce frequency of black links. We have been getting about 3 black links per month on one interface on this cnss. 18432, 18491, 18509 - enss129 fddi card hang, manual reset 18465 - enss129 fddi card replacement scheduled maintainence 18504 - cnss40 crash resulting in interconnect switchover Routing configuration problems: 18503 - Missing ibgp line in cnss48 and 49 for new enss164 at IBM Watson Scheduled Backbone router software upgrades: 18414 - new rcp_routed on enss131 for better route aggregation 18416 - new build 64 on enss163 for performance improvements 18424 - new rcp_routed on cnss83 18425 - new rcp_routed on enss135, 137, 139 18430 - new rcp_routed on enss129, 132 18431 - new build 67 on enss135, 129, 132 (to fix fddi bug in build 64) Site maintenance tickets, no downtime: 18451, 18452, 18453, 18454, 18455, 18456, 18457 - Perform spare parts inventory at Cleveland and Hartford POPs, and at ENSS sites 128, 135, 129, 132, 133, 134. ======================================================================= Date: Wed, 12 Feb 92 18:18:11 EST To: nwg@merit.edu From: oleary@sura.net Subject: T3 backbone stability We are cutting over to use the T3 backbone now, and I am concerned by the several recent messages about ENSS and CNSS problems. Could someone at Merit summarize some of the recent outages if there have been trends, or could some of the other midlevels provide us with some insight as to how (in)stability has affected your connections? We are going with the emerging standard of send T3 stuff to the T3 and T1 stuff to the T1, explicitly importing T3 routes and defaulting everything else to the T1. thanks, dave o'leary SURAnet - - - - - - - - - - - - - - - - - From skw Fri Feb 14 07:56:24 1992 Received: by merit.edu (5.65/1123-1.0) id AA14839; Fri, 14 Feb 92 07:56:28 -0500 From: "Steven K. Widmayer" Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA14835; Fri, 14 Feb 92 07:56:24 -0500 Received: by home.merit.edu (4.1/client-0.9) id AA23909; Fri, 14 Feb 92 07:56:23 EST Date: Fri, 14 Feb 92 07:56:23 EST Message-Id: <9202141256.AA23909@home.merit.edu> To: nwg Subject: Additions to the NSFNET policy-based routing database The following networks have been added to the NSFNET policy-based routing database: T1 Network: Net # Net Name Primary Secondary Location -------- ----------- ------- --------- -------- 144.162 DCCCD 280 114 Dallas County Community College District, 4343 North HWY 67, Mesquite, TX 75150 144.251 AVTROS-NET2 184 164 AVSCOM/TROSCOM, Attn:ASQNC-STL-D, 4300 Goodfellow Boulevard, St. Louis, MO 63120-1798 148.53 INGREURO 701 279 Intergraph Corp, 1 Madison Industrial Park, Huntsville, AL 35894-0001 152.62 DGPDN3 174 750 Data General, 4400 Computer Drive, Westboro, MA 01580 155.102 ERIM 233 177 Environmental Research Institute of Michigan, P.O. Box 134001, Ann Arbor, MI 48113-4001 192.77.187 PSINET-C-187 174 750 PSI, Inc., 165 Jordan Road, Troy, NY, 12180 192.77.188 PSINET-C-188 174 750 PSI, Inc., 165 Jordan Road, Troy, NY, 12180 192.77.189 PSINET-C-189 174 750 PSI, Inc., 165 Jordan Road, Troy, NY, 12180 192.77.190 PSINET-C-190 174 750 PSI, Inc., 165 Jordan Road, Troy, NY, 12180 192.77.191 PSINET-C-191 174 750 PSI, Inc., 165 Jordan Road, Troy, NY, 12180 192.77.192 PSINET-C-192 174 750 PSI, Inc., 165 Jordan Road, Troy, NY, 12180 192.77.193 PSINET-C-193 174 750 PSI, Inc., 165 Jordan Road, Troy, NY, 12180 192.77.194 PSINET-C-194 174 750 PSI, Inc., 165 Jordan Road, Troy, NY, 12180 192.77.195 PSINET-C-195 174 750 PSI, Inc., 165 Jordan Road, Troy, NY, 12180 192.77.196 PSINET-C-196 174 750 PSI, Inc., 165 Jordan Road, Troy, NY, 12180 192.107.241 QUINTUS-NET1 701 279 Quintus Computer Systems, Inc, 2100 Geng Road, Suite 101, Palo Alto, CA 94303 192.107.242 QUINTUS-NET2 701 279 Quintus Computer Systems, Inc, 2100 Geng Road, Suite 101, Palo Alto, CA 94303 192.107.243 QUINTUS-NET3 701 279 Quintus Computer Systems, Inc, 2100 Geng Road, Suite 101, Palo Alto, CA 94303 192.107.244 QUINTUS-NET4 701 279 Quintus Computer Systems, Inc, 2100 Geng Road, Suite 101, Palo Alto, CA 94303 192.107.245 QUINTUS-NET5 701 279 Quintus Computer Systems, Inc, 2100 Geng Road, Suite 101, Palo Alto, CA 94303 192.108.120 ROE1 274 60 Royal Observatory Edinburgh, Blackford Hill, Edinburgh EH9 3HJ, UNITED KINGDOM 192.136.144 SES-C001 114 1700 Rice University-Sesquinet, 6100 South Main, Houston, TX 77251 192.136.145 SES-C002 114 1700 Rice University-Sesquinet, 6100 South Main, Houston, TX 77251 192.136.146 SES-C003 114 1700 Rice University-Sesquinet, 6100 South Main, Houston, TX 77251 192.136.147 SES-C004 114 1700 Rice University-Sesquinet, 6100 South Main, Houston, TX 77251 192.136.148 SES-C005 114 1700 Rice University-Sesquinet, 6100 South Main, Houston, TX 77251 192.136.149 SES-C006 114 1700 Rice University-Sesquinet, 6100 South Main, Houston, TX 77251 192.136.150 SES-C007 114 1700 Rice University-Sesquinet, 6100 South Main, Houston, TX 77251 192.136.151 SES-C008 114 1700 Rice University-Sesquinet, 6100 South Main, Houston, TX 77251 192.136.152 SES-C009 114 1700 Rice University-Sesquinet, 6100 South Main, Houston, TX 77251 192.136.153 SES-C010 114 1700 Rice University-Sesquinet, 6100 South Main, Houston, TX 77251 Total NSFNET T1 announced networks: 4668 T3 Network: Network IP: 148.53 Network Name: INGREURO Location: Intergraph Corp, 1 Madison Industrial Park, Huntsville, AL 35894-0001 Country Code: US 42:702 Alternet Router Network IP: 152.62 Network Name: DGPDN3 Location: Data General, 4400 Computer Drive, Westboro, MA 01580 Country Code: US 1:174 NYSERNET Regional Network / PSI Network IP: 155.102 Network Name: ERIM Location: Environmental Research Institute of Michigan, P.O. Box 134001, Ann Arbor, MI 48113-4001 Country Code: US 1:237 MERIT network Network IP: 192.67.225 Network Name: SIMNET-RUCKR Location: SIMNET, Fort Rucker, AL 36362 Country Code: US 1:200 BARRNet Network IP: 192.67.227 Network Name: SIMNET-KNOX Location: SIMNET, Fort Knox, KY, 40121 Country Code: US 1:200 BARRNet Network IP: 192.77.187 Network Name: PSINET-C-187 Location: PSI, Inc., 165 Jordan Road, Troy, NY, 12180 Country Code: US 1:174 NYSERNET Regional Network / PSI Network IP: 192.77.188 Network Name: PSINET-C-188 Location: PSI, Inc., 165 Jordan Road, Troy, NY, 12180 Country Code: US 1:174 NYSERNET Regional Network / PSI Network IP: 192.77.189 Network Name: PSINET-C-189 Location: PSI, Inc., 165 Jordan Road, Troy, NY, 12180 Country Code: US 1:174 NYSERNET Regional Network / PSI Network IP: 192.77.190 Network Name: PSINET-C-190 Location: PSI, Inc., 165 Jordan Road, Troy, NY, 12180 Country Code: US 1:174 NYSERNET Regional Network / PSI Network IP: 192.77.191 Network Name: PSINET-C-191 Location: PSI, Inc., 165 Jordan Road, Troy, NY, 12180 Country Code: US 1:174 NYSERNET Regional Network / PSI Network IP: 192.77.192 Network Name: PSINET-C-192 Location: PSI, Inc., 165 Jordan Road, Troy, NY, 12180 Country Code: US 1:174 NYSERNET Regional Network / PSI Network IP: 192.77.193 Network Name: PSINET-C-193 Location: PSI, Inc., 165 Jordan Road, Troy, NY, 12180 Country Code: US 1:174 NYSERNET Regional Network / PSI Network IP: 192.77.194 Network Name: PSINET-C-194 Location: PSI, Inc., 165 Jordan Road, Troy, NY, 12180 Country Code: US 1:174 NYSERNET Regional Network / PSI Network IP: 192.77.195 Network Name: PSINET-C-195 Location: PSI, Inc., 165 Jordan Road, Troy, NY, 12180 Country Code: US 1:174 NYSERNET Regional Network / PSI Network IP: 192.77.196 Network Name: PSINET-C-196 Location: PSI, Inc., 165 Jordan Road, Troy, NY, 12180 Country Code: US 1:174 NYSERNET Regional Network / PSI Network IP: 192.107.241 Network Name: QUINTUS-NET1 Location: Quintus Computer Systems, Inc, 2100 Geng Road, Suite 101, Palo Alto, CA 94303 Country Code: US 42:702 Alternet Router Network IP: 192.107.242 Network Name: QUINTUS-NET2 Location: Quintus Computer Systems, Inc, 2100 Geng Road, Suite 101, Palo Alto, CA 94303 Country Code: US 42:702 Alternet Router Network IP: 192.107.243 Network Name: QUINTUS-NET3 Location: Quintus Computer Systems, Inc, 2100 Geng Road, Suite 101, Palo Alto, CA 94303 Country Code: US 42:702 Alternet Router Network IP: 192.107.244 Network Name: QUINTUS-NET4 Location: Quintus Computer Systems, Inc, 2100 Geng Road, Suite 101, Palo Alto, CA 94303 Country Code: US 42:702 Alternet Router Network IP: 192.107.245 Network Name: QUINTUS-NET5 Location: Quintus Computer Systems, Inc, 2100 Geng Road, Suite 101, Palo Alto, CA 94303 Country Code: US 42:702 Alternet Router Total NSFNET T3 announced networks: 1376 The configuration reports, map information sheets, and configuration files which reflect these changes are available for anonymous ftp on nis.nsf.net as usual. nsfsites - configuration reports latest report for: - NSFNET T1 has the file extension .now - NSFNET T3 has the file extension 3.now nsfconfg - configuration files for the routing software for each NSS latest report for: - NSFNET T1 has the file format config.nss# - NSFNET T3 has the file extension .t3p Please send all requests for configuration changes to nsfnet-admin@merit.edu using the NSFNET configuration forms. The forms are available on-line from the nis.nsf.net machine. Use ftp and the anonymous login to get on the machine. Do a "cd nsfsites" and grab the files TEMPLATE.NET, TEMPLATE.GATE, and TEMPLATE.AS. --Steve Widmayer Merit/NSFNET - - - - - - - - - - - - - - - - - From nwg-owner Fri Feb 14 21:03:24 1992 Received: by merit.edu (5.65/1123-1.0) id AA06840; Fri, 14 Feb 92 21:03:28 -0500 Received: from LABS-N.BBN.COM by merit.edu (5.65/1123-1.0) id AA06835; Fri, 14 Feb 92 21:03:24 -0500 Message-Id: <9202150203.AA06835@merit.edu> To: nwg Cc: nearnet-ops@nic.near.net, network@mit.edu Subject: [Merit Network Operations Center: 02/14/92 NSS 8 Princeton Unreachable 20:26 - ? EDT] Date: Fri, 14 Feb 92 21:03:04 -0500 From: skennedy@BBN.COM Circuit problems should not affect connectivity to a host across an ethernet? Are there two NSS-8 outages? As we reported (NN TT# 2642), the T1-EPSP at MIT is down. Drops pings... Sean Kennedy NEARnet ------- Forwarded Message Received: from nic.near.net by LABS-N.BBN.COM id aa10008; 14 Feb 92 20:54 EST Received: from nic.near.net by nic.near.net id aa25834; 14 Feb 92 20:52 EST Received: from merit.edu by nic.near.net id aa25830; 14 Feb 92 20:52 EST Return-Path: Received: by merit.edu (5.65/1123-1.0) id AA06457; Fri, 14 Feb 92 20:49:57 -0500 Received: by merit.edu (5.65/1123-1.0) id AA06453; Fri, 14 Feb 92 20:49:55 -0500 Date: Fri, 14 Feb 92 20:49:55 -0500 From: Merit Network Operations Center Message-Id: <9202150149.AA06453@merit.edu> To: nsr@merit.edu Subject: 02/14/92 NSS 8 Princeton Unreachable 20:26 - ? EDT 02/14/92 NSS 8 Princeton Unreachable 20:26 - ? EDT due to circuit problems. Michele Davis MERIT/NSFNet ------- End of Forwarded Message - - - - - - - - - - - - - - - - - From donnab@CERF.NET Mon Feb 17 15:20:35 1992 Received: from nic.cerf.net by merit.edu (5.65/1123-1.0) id AA27601; Mon, 17 Feb 92 15:20:35 -0500 Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA07019; Mon, 17 Feb 92 12:22:45 PST Date: Mon, 17 Feb 92 12:22:45 PST From: Donna Bigley Message-Id: <9202172022.AA07019@nic.cerf.net> To: broidoj@Sds.Sdsc.Edu, help@CERF.NET, nsfnet-reports, ops@cerf.net Subject: CERFnet Weekly Report for the week of Monday, February 10, 1992. ############################################################################### This is the CERFnet weekly activity report for the period of Monday, February 10th through Sunday, February 16th, 1992. This report is also available through anonymous FTP from NIC.CERF.NET [192.102.249.3] in the cerfnet/cerfnet_stats subdirectory. The filename is: 16-february-92.txt All times are in Pacific Standard Time, and in the 24-hour format. Please direct any questions or comments to: donnab@cerf.net or help@cerf.net ****************************************************************************** NETWORK OUTAGES: SITE: SERI/KOREA SITES AFFECTED: SERI/KOREA TIME STARTED: SAT. 2-8-92 01:19 TIME ENDED: TIME ELAPSED: (Intermittent Outages) REASON: Telco persuing problems in Korea. SITE: DATAPRODUCTS SITES AFFECTED: DATAPRODUCTS TIME STARTED: MON. 2-10-92 11:14 TIME ENDED: TUE. 2-11-92 06:32 TIME ELAPSED: 19 hours 18 min. REASON: Power Outage SITE: EMULEX SITES AFFECTED: EMULEX TIME STARTED: TUE. 2-11-92 07:29 TIME ENDED: TUE. 2-11-92 07:51 TIME ELAPSED: 22 min. REASON: Unknown SITE: GA SITES AFFECTED: GA TIME STARTED: TUE. 2-11-92 07:31 TIME ENDED: TUE. 2-11-92 07:50 TIME ELAPSED: 19 min. REASON: CERFnet/Site Scheduled Maintenance SITE: CIT SITES AFFECTED: CIT Dial n' CERF, OXY, Disney, Claremont, Cadam, SCAQMD and Los Nettos. TIME STARTED: WED. 2-12-92 08:44 TIME ENDED: WED. 2-12-92 09:06 TIME ELAPSED: 22 min. REASON: CERFnet Scheduled Maintenance SITE: QUALCOMM SITES AFFECTED: QUALCOMM TIME STARTED: WED. 2-12-92 20:06 TIME ENDED: THU. 2-13-92 00:38 TIME ELAPSED: 4 hours 32 min. REASON: Unknown SITE: DATAPRODUCTS SITES AFFECTED: DATAPRODUCTS TIME STARTED: THU. 2-13-92 04:24 TIME ENDED: THU. 2-13-92 08:23 TIME ELAPSED: 3 hours 59 min. REASON: Power Outage SITE: AGI SITES AFFECTED: AGI TIME STARTED: THU. 2-13-92 08:51 TIME ENDED: THU. 2-13-92 10:19 TIME STARTED: THU. 2-13-92 10:43 TIME ENDED: THU. 2-13-92 11:08 TIME ELAPSED: 1 hour 53 min. REASON: Power Outage SITE: GA SITES AFFECTED: GA TIME STARTED: THU. 2-13-92 04:31 TIME ENDED: THU. 2-13-92 07:30 TIME ELAPSED: 2 hours 59 min. REASON: Power Outage SITE: DATAPRODUCTS SITES AFFECTED: DATAPRODUCTS TIME STARTED: THU. 2-13-92 23:55 TIME ENDED: FRI. 2-14-92 16:46 TIME ELAPSED: 16 hours 51 min. (Intermittent Access) REASON: Link Failure SITE: SERI/KOREA SITES AFFECTED: SERI/KOREA TIME STARTED: FRI. 2-14-92 06:34 TIME ENDED: FRI. 2-14-92 10:29 TIME ELAPSED: 3 hours 55 min. REASON: Link Failure SITE: McDonnell Douglas SITES AFFECTED: McDonnell Douglas TIME STARTED: SAT. 2-15-92 22:32 TIME ENDED: SAT. 2-15-92 22:50 TIME ELAPSED: 18 min. REASON: Unknown SITE: McDonnell Douglas SITES AFFECTED: McDonnell Douglas TIME STARTED: SUN. 2-16-92 02:46 TIME ENDED: SUN. 2-16-92 06:25 TIME STARTED: SUN. 2-16-92 11:27 TIME ENDED: MON. 2-17-92 06:29 TIME ELAPSED: 23 hours 21 min. (Intermittent Access) REASON: Unknown ------------------------------------------------------------------------ CERFNET TRAFFIC CAPACITY USAGE AT EACH CIRCUIT LINK * Capacities for sites off of Caltech are unavailable. LINK SPEED CAPACITY PEAK HOUR (PDT) SDSC/CALTECH 1.544 mbps 12.1% 15:00 SDSC/UCI 1.544 mbps 05.0% 15:00 SDSC/UCLA 1.544 mbps 05.1% 14:00 SDSC/UCOP 1.544 mbps 04.5% 10:00 SDSC/UCR 1.544 mbps 00.7% 10:00 UCI/UCLA 1.544 mbps 00.8% 02:00 SDSC/UCR 512 kbps 02.1% 10:00 UCLA/UCSB 512 kbps 05.7% 16:00 SDSC/AGI 1.544 mbps 00.1% 20:00 SDSC/BIOSYM 1.544 mbps 00.1% 16:00 SDSC/GA 1.544 mbps 00.1% 08:00 SDSC/GD 1.544 mbps 01.9% 11:00 SDSC/SAIC 1.544 mbps 01.1% 14:00 SDSC/SDSU 1.544 mbps 01.9% 10:00 UCI/CSU CO(SWRL) 1.544 mbps 02.1% 10:00 UCOP/APPLE 1.544 mbps 00.7% 12:00 UCOP/CISCO 1.544 mbps 00.2% 15:00 UCR/LLUMC 1.544 mbps 00.01% 14:00 SDSC/AJS 56 kbps 01.5% 08:00 SDSC/KOREA 56 kbps 10.2% 18:00 SDSC/QUALCOMM 56 kbps 05.5% 05:00 SDSC/SCIH 56 kbps 06.1% 03:00 SDSC/USD 56 kbps 07.1% 17:00 SDSC/USIU 56 kbps 00.6% 15:00 SDSC/XEROX 56 kbps 00.7% 17:00 UCI/CMD 56 kbps 06.1% 20:00 UCI/EMULEX 56 kbps 01.2% 16:00 UCI/FULLERTON 56 kbps 01.4% 13:00 UCI/HUGHES 56 kbps 07.9% 11:00 UCI/MTI 56 kbps 05.8% 17:00 UCI/SPARTA 56 kbps 02.4% 09:00 UCI/UNOCAL 56 kbps 06.8% 22:00 UCLA/ISX 56 kbps 00.9% 10:00 UCLA/PEPPERDINE 56 kbps 02.4% 06:00 UCLA/QUOTRON 56 kbps 04.3% 13:00 UCLA/SMC 56 kbps 00.8% 15:00 UCOP/FARALLON 56 kbps 04.2% 11:00 UCOP/INTEL 56 kbps 15.9% 15:00 UCOP/LSIL 56 kbps 07.1% 21:00 UCOP/NETLABS 56 kbps 14.2% 20:00 ------------------------------------------------------------------------------ SITE CISCO BOX UPTIME SINCE LAST REBOOT (as of 00:15 PST on Feb. 17, 1992): CERFnet BACKBONE CALTECH [131.215.139.253] Up: 04 days 15 hours 17 minutes [CERFnet Scheduled Maintenance] SDSC Drzog [132.249.16.13] Up: 64 days 08 hours 25 minutes SDSC Hang10 [132.249.16.15] Up: 10 days 09 hours 52 minutes UCI [128.200.1.101] Up: 38 days 16 hours 07 minutes UCLA [128.97.130.10] Up: 09 days 13 hours 42 minutes UCOP [134.24.52.112] Up: 08 days 08 hours 57 minutes UCR [134.24.108.105] Up: 93 days 12 hours 36 minutes CERF 1544 AGI [134.24.202.110] Up: 03 days 13 hours 54 minutes [Power Outage] APPLE [134.24.70.200] Up: 112 days 06 hours 15 minutes BIOSYM [134.24.57.200] Up: 14 days 06 hours 48 minutes CISCO Systems [134.24.54.200] Up: 75 days 14 hours 09 minutes CSUCO/SWRL [130.150.102.200] Up: 33 days 12 hours 46 minutes GA [134.24.221.200] Up: 03 days 16 hours 45 minutes [Power Outage] GD [134.24.60.200] Up: 46 days 04 hours 14 minutes LLUMC [134.24.208.200] Up: 89 days 12 hours 22 minutes SAIC [134.24.53.208] Up: 43 days 08 hours 34 minutes SCAQMD [134.24.234.200] Up: 59 days 14 hours 27 minutes SDSU [192.77.100.101] Up: 69 days 16 hours 31 minutes UCSB [134.24.107.107] Up: 89 days 07 hours 38 minutes CERF 56 AJS [134.24.225.101] Up: 30 days 14 hours 17 minutes CADAM [134.24.229.200] Up: 12 days 13 hours 01 minutes CLAREMONT [134.24.206.109] Up: 03 days 14 hours 02 minutes [Unscheduled Outage] CMD [134.24.218.200] Up: 20 days 13 hours 14 minutes DATAPRODUCTS [134.24.211.104] Up: 05 days 20 hours 03 minutes [Power Outage] DISNEY [134.24.207.211] Up: 18 days 00 hours 33 minutes EMULEX [134.24.209.212] Up: 64 days 15 hours 48 minutes FARALLON [134.24.56.200] Up: 05 days 15 hours 03 minutes [Unsheduled Site Maintenance] FULLERTON [134.24.214.217] Up: 62 days 15 hours 33 minutes HUGHES [134.24.204.200] Up: 94 days 07 hours 21 minutes INTEL [134.24.55.200] Up: 50 days 03 hours 19 minutes LSIL [134.24.72.200] Up: 08 days 13 hours 08 minutes MTI [134.24.216.100] Up: 44 days 13 hours 39 minutes NETLABS [134.24.71.200] Up: 72 days 15 hours 07 minutes OXY [134.24.205.108] Up: 03 days 19 hours 45 minutes [Unknown] PEPPERDINE [134.24.203.218] Up: 43 days 13 hours 24 minutes QUALCOMM [134.24.200.201] Up: 04 days 09 hours 37 minutes [Power Outage] QUOTRON [134.24.230.202] Up: 84 days 13 hours 44 minutes SANTA MONICA [134.24.210.219] Up: 38 days 01 hours 22 minutes SCI-HOR [134.24.109.205] Up: 80 days 11 hours 15 minutes SERI/KOREA [134.24.223.200] Up: 146 days 00 hours 00 minutes SPARTA [134.24.215.200] Up: 03 days 19 hours 09 minutes [Power Outage] UNOCAL [134.24.217.200] Up: 25 days 14 hours 24 minutes USD [134.24.201.106] Up: 18 days 15 hours 45 minutes USIU [134.24.222.215] Up: 225 days 17 hours 07 minutes XEROX [134.24.51.207] Up: 109 days 23 hours 22 minutes DIAL n' CERF DNC-SDSC [134.24.1.2] Up: 33 days 04 hours 51 minutes DNC-UCI [134.24.2.2] Up: 40 days 03 hours 24 minutes DNC-UCLA [134.24.3.2] Up: 25 days 12 hours 38 minutes DNC-CALTECH [134.24.4.2] Up: 18 days 16 hours 28 minutes DNC-UCOP [134.24.5.2] Up: 08 days 08 hours 58 minutes - - - - - - - - - - - - - - - - - From cert-advisory-request@cert.sei.cmu.edu Mon Feb 17 16:58:06 1992 Received: from tictac.cert.sei.cmu.edu by merit.edu (5.65/1123-1.0) id AA00410; Mon, 17 Feb 92 16:58:06 -0500 Received: by tictac.cert.sei.cmu.edu (5.65/2.5) id AA06843; Mon, 17 Feb 92 16:45:44 -0500 Message-Id: <9202172145.AA06843@tictac.cert.sei.cmu.edu> From: CERT Advisory Date: Mon, 17 Feb 92 16:45:20 EST To: cert-advisory@cert.sei.cmu.edu Subject: CERT Advisory - Internet Intruder Activity Organization: Computer Emergency Response Team : 412-268-7090 =========================================================================== CA-92:03 CERT Advisory February 17, 1992 Internet Intruder Activity --------------------------------------------------------------------------- The Computer Emergency Response Team/Coordination Center (CERT/CC) has received information regarding a significant intrusion incident on the Internet. Systems administrators should be aware that many systems on the Internet have been compromised due to this activity. To identify whether your systems have been affected by the activity we recommend that all system administrators check for the signs of intrusion detailed in this advisory. This advisory describes the activities that have been identified as part of this particular incident. This does not address the possibility that systems may have been compromised due to other, unrelated intrusion activity. --------------------------------------------------------------------------- I. Description The intruders gained initial access to a host by discovering a password for a user account on the system. They then attempted to become root on the compromised system. II. Impact Having gained root access on a system, the intruders installed trojan binaries that captured account information for both local and remote systems. They also installed set-uid root shells to be used for easy root access. III. Solution A. Check your systems for signs of intrusion due to this incident. 1. Check the su, ftpd, and ftp binaries (for example, "/bin/su", "/usr/ucb/ftp" and "/usr/etc/in.ftpd" on Sun systems) against copies from distribution media. 2. Check for the presence of any of the following files: "/usr/etc/..." (dot dot dot), "/var/crash/..." (dot dot dot), "/usr/etc/.getwd", "/var/crash/.getwd", or "/usr/kvw/..." (dot dot dot). 3. Check for the presence of "+" in the "/etc/hosts.equiv" file. 4. Check the home directory for each entry in the "/etc/passwd" file for the presence of a ".rhosts" file containing "+ +" (plus space plus). 5. Search the system for the presence of the following set-uid root files: "wtrunc" and ".a". 6. Check for the presence of the set-uid root file "/usr/lib/lpx". B. Take the following steps to secure your systems. 1. Save copies of the identified files to removable media. 2. Replace any modified binaries with copies from distribution media. 3. Remove the "+" entry from the "/etc/hosts.equiv" file and the "+ +" (plus space plus) entry from any ".rhosts" files. 4. Remove any of the set-uid root files that you find, which are mentioned in A5 or A6 above. 5. Change every password on the system. 6. Inspect the files mentioned in A2 above for references to other hosts. --------------------------------------------------------------------------- If you believe that your system has been compromised, contact CERT/CC or your representative in FIRST (Forum of Incident Response and Security Teams). Internet E-mail: cert@cert.sei.cmu.edu Telephone: 412-268-7090 (24-hour hotline) CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4), on call for emergencies during other hours. Computer Emergency Response Team/Coordination Center (CERT/CC) Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Past advisories, information about FIRST representatives, and other information related to computer security are available for anonymous ftp from cert.sei.cmu.edu (192.88.209.5). - - - - - - - - - - - - - - - - - From skw Tue Feb 18 07:43:35 1992 Received: by merit.edu (5.65/1123-1.0) id AA21393; Tue, 18 Feb 92 07:43:37 -0500 From: "Steven K. Widmayer" Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA21389; Tue, 18 Feb 92 07:43:35 -0500 Received: by home.merit.edu (4.1/client-0.9) id AA22321; Tue, 18 Feb 92 07:43:34 EST Date: Tue, 18 Feb 92 07:43:34 EST Message-Id: <9202181243.AA22321@home.merit.edu> To: nwg Subject: Additions to the NSFNET policy-based routing database The following networks have been added to the NSFNET policy-based routing database: T1 Network: Net # Net Name Primary Secondary Location -------- ----------- ------- --------- -------- 129.11 LEEDS 274 60 Leeds University, Leeds LS2 9JT, UNITED KINGDOM 133.13 UNIV-RYUKYU 372 297 The University of the Ryukyus, JAPAN 133.16 KYOUTOINSTECH 372 297 Kyouto Institute of Technology, JAPAN 133.22 KIDNET 372 297 Kyushu Institute of Design, JAPAN 133.35 NINES 372 297 Information Processing Center Niigara University, JAPAN 133.37 OITA-UNIV 372 297 Oita University, JAPAN 133.42 WAKAYAMA-U 372 297 Wakayama University, JAPAN 133.68 NITECH 372 297 Nagoya Institute of Technology, JAPAN 133.85 TOYOTA-CTNET 372 297 Toyota College of Technology, JAPAN 133.94 KURUMEINET 372 297 Kurme Institute of Technology, JAPAN 133.95 KUMAMOTO-UNI 372 297 Kumamoto University Computer Center, JAPAN 133.107 HSK-NET 372 297 Hitachi Software Engineering Co., LTD., JAPAN 133.112 SOUM-NETR-1 372 297 SOUM Corporation, JAPAN 133.123 FORETUNE-LAN 372 297 Foretune Co., Ltd., JAPAN 133.130 TRAD-NET 372 297 Trad Techologies Corp., JAPAN 133.186 JAPANB-INET10C 372 297 Japan Inet, JAPAN 134.122 PHOENIX 560 281 Phoenix Technologies, Ltd., 38 Sidney Street, Cambridge, MA 02139 150.12 HIT-NETWORK 372 297 Himeji Institute of Technology, JAPAN 150.61 CANON-NET 372 297 CANON INC., JAPAN 150.65 FRONTNET 372 297 Japan Advanced Institute of Science and Technology, JAPAN 150.69 KIT 372 297 Kyushu Institute of Technology, JAPAN 150.88 HITACHI-CABL 372 297 Hitachi Cable, LTD., JAPAN 192.50.101 KNCTNET 372 297 Kumamoto National College of Technology, JAPAN 192.133.16 CSCNET 93 Chadron State College, Computer Center, 1000 S Main St., Chadron NE 69337 Total NSFNET T1 announced networks: 4691 T3 Network: Network IP: 134.122 Network Name: PHOENIX Location: Phoenix Technologies, Ltd., 38 Sidney Street, Cambridge, MA 02139 Country Code: US 1:560 NEARnet Regional Network 2:281 NEARnet Regional Network Total NSFNET T3 announced networks: 1377 The configuration reports, map information sheets, and configuration files which reflect these changes are available for anonymous ftp on nis.nsf.net as usual. nsfsites - configuration reports latest report for: - NSFNET T1 has the file extension .now - NSFNET T3 has the file extension 3.now nsfconfg - configuration files for the routing software for each NSS latest report for: - NSFNET T1 has the file format config.nss# - NSFNET T3 has the file extension .t3p Please send all requests for configuration changes to nsfnet-admin@merit.edu using the NSFNET configuration forms. The forms are available on-line from the nis.nsf.net machine. Use ftp and the anonymous login to get on the machine. Do a "cd nsfsites" and grab the files TEMPLATE.NET, TEMPLATE.GATE, and TEMPLATE.AS. --Steve Widmayer Merit/NSFNET - - - - - - - - - - - - - - - - - From COLE@CC.UTAH.EDU Wed Feb 19 13:14:26 1992 Received: from cc.utah.edu by merit.edu (5.65/1123-1.0) id AA12381; Wed, 19 Feb 92 13:14:26 -0500 Date: Wed, 19 Feb 1992 11:13 MST From: Allen Cole Subject: Re: The CIX and the NSFNET regionals - a dilemma To: schoff@psi.com Cc: zawanda@ncsa.uiuc.edu, regional-techs, cix-tech@cix.org, mkapor@eff.org Message-Id: <34B70768A8024062@CC.UTAH.EDU> X-Envelope-To: regional-techs@merit.edu X-Vms-To: IN%"schoff@psi.com" X-Vms-Cc: IN%"zawanda@ncsa.uiuc.edu",IN%"regional-techs@merit.edu",IN%"cix-tech@cix.org",IN%"mkapor@eff.org" Marty writes ------------ >We see similiar problems, functional capability for interactive >applications like telnet is MUCH better through the CIX than through >the NSFNet. When "SaltLakeCity" has its normal problems (we've seen >about a dozen in January, and we're not looking really) then it goes >through the roof. An update. There have been circuit problem for a couple of the circuits into Salt Lake. After a 24 hour test period the problem has been isolated to the tail circuits at Salt Lake. Fortunately a new fiber local loop has been recently installed here. That will probably make a difference. cole@cc.utah.edu - - - - - - - - - - - - - - - - - From skh Wed Feb 19 18:26:28 1992 Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA22570; Wed, 19 Feb 92 18:26:28 -0500 Received: by home.merit.edu (4.1/client-0.9) id AA07034; Wed, 19 Feb 92 18:26:27 EST Date: Wed, 19 Feb 92 18:26:27 EST From: skh Message-Id: <9202192326.AA07034@home.merit.edu> To: regional-techs Subject: OSI Survey for Regionals attached to the Internet Cc: noop, osi-interop Below is a survey on OSI usage in the Internet. Could you take a moment and fill out this survey? It may look long, but it should only take a few minutes to fill out. Your answers will help the people working on OSI in the Internet plan our next work. Thank you for your help! Please send it in as soon as possible. We'd like to get all responses back within a week. Thank-you, Susan Hares IETF NOOP chair Survey on OSI in Your Network Purpose for Survey: The IETF Network OSI Operational Working Group wants to find out details on OSI use their is in the Internet. The results of the survey will be published as an FYI document for the Internet. Any people answering the Survey will be sent electronic copies of the FYI document on the results of the survey. As people beginning to use OSI on the Internet, the will be able to refer to this document to find out who supports the ISO CLNP layer across the Internet. Timeframe for Survey: Please return this survey by February 27th, 1992. Results will be published as a paper for the NOOP group by March 7th, 1992. Send responses to skh@merit.edu. Introduction to the Survey: Questions 1-6 are for those who route Connection Network Layer Packets (CLNP ISO 8473) or DECNET Phase 5 traffic on their network. Questions 7-8 are for those who do not yet route CLNP or DECNET Phase 5. 1.) Do you support the routing of Connection Network Layer Protocol (CLNP (ISO 8473)) packets on your network? If so, 1.1) What number of routers do you have in your network? How many of these routers pass CLNP packets? 1.2) What router vendors do you use in your network? What router vendors do you use in the routers that are passing CLNP packets? 1.3) What type of intra-domain routing do you do within your network? IS-IS? Cisco IGRP based OSI? static? 1.4) What type of inter-domain routing do you do? Cisco poor-man's Inter-domain routing? static? 1.5) Would you be interested in the new ISO Inter-Domain Routing Protocol (IDRP (ISO CD 10747)) when it becomes available? 1.6) Do you consider the OSI service to be: Production - guaranteed delivery and high level of service, Experimental - guaranteed delivery, but service not at highest level Prototype - A first offerings of CLNP which is limited to a few sites, or Pilot - For demonstrations and Pilot projects only? Please select the category nearest to your service. You may include other comments to further qualify this service level. 1.7) If you are running both IP and CLNP, What do you consider your IP service - Production, Experimental, Prototype, or Pilot? 1.8) What amount of traffic do you pass per day, per week and per month? 2.) Are you now routing DECNET Phase 5 traffic on your system? If you are routing DECNET Phase 5: a.) What type of routers are you using? (manufacturer and model? b.) How many routers do you have? c.) What type of hosts are sending traffic? d.) How many DECNET Phase 5 hosts do you have? 3.) Do you currently attach one or more OSI vendor company to your network? Do any of these companies send OSI traffic across the network? If so, 3.1) How many OSI companies are attached to your network? 3.2) How many of these OSI companies send application data regularly? 3.3) What are the companies attached to your network? 3.4) What applications are these companies using? It would be helpful to list the applications by company if that is possible. 3.5) Would any of these companies be interested in "Pilot" projects to try exchanging OSI applications with those people on the Internet. 4.) Do you support OSI applications at your network site? If so, 4.1) What applications do you support? Do you support: X.500 X.400 FTAM VT Xwindows SQL based applications CMIP (please answer yes or no to each applications) others - please list with company 4.2) For each of the applications you answered yes to above please indicate: a.) equipment the application runs on b.) does it run over CLNP/TP4 stack or TCP/IP stack c.) what vendor supplies the software d.) any comments on how easy it is to use e.) Is your application based on ISODE? If so what version of ISODE? 4.3) Are you a part of a Pilot Project or testing group for this application? 4.4) Would you be willing to be a part of a Pilot Project or testing group for this application? 4.5) Do you have a set of routers or hosts which could form a "test bed" at your site? 4.6) Would you be willing to allow this test bed (either a short term or long term basis) to join with other test beds at other networks to test out new software in the Internet? 4.6) Would you be willing to have a "test bed" at your site if additional funding for this was available? Would you be willing on either a short term or long term basis to allow 5.) Do you have any of the following network tools on your routers? a.) OSI ping (or echo function) b.) OSI traceroute c.) OSI table dump What routers have these functions? How would you rate the User Interface to these network tools - poor, fair, good, or excellent? 6.) Do you have any of the following network tools on your hosts? a.) OSI ping (or echo function) b.) OSI traceroute c.) OSI table dump What hosts have these functions? How would you rate the User Interface to these network tools - poor, fair, good, or excellent? 7.) If you do not support switching CLNP packets today, a.) Will you need to route DECNET Phase 5 in the future? b.) Will you route CLNP packets if you had clients that required OSI service? c.) Will you route CLNP packets only when IS-IS was supported on all your routers? (please indicate what types of routers you use in your network) d.) Will you need network tools (that supported an osi ping, osi traceroute, and osi routing table dump) to support CLNP in your network? e.) Will you require both clients and IS-IS supported on all your routers (b and c above) f.) Will you require that you have OSI clients, IS-IS on all your routers, and OSI network tools (b, c and d above) Please answer yes or no to items a thru e. Additional comments are also welcome. 8.) If you do not currently use an OSI application at your site, please answer the following: 8.1) Would you be interested in X.500? In X.500 over TCP/IP? In X.500 over CLNP? 8.2) Would you be interested in X.400? in X.400 over TCP/IP? In X.400 over CLNP? 8.3) Would you be interested in FTAM over ISO Transport Class 4 (TP4) and CLNP? 8.4) Would you be interested in FTAM over ISO transport Class 0 (TP0) and X.25? 8.5) Would be interested in VT over TP and CLNP? 8.6) Would you be interested in trying out TCP over CLNP? 8.7) Would you be interested in trying out X-windows over CLNP? - - - - - - - - - - - - - - - - - From vaf@Valinor.Stanford.EDU Wed Feb 19 21:02:29 1992 Received: from Valinor.Stanford.EDU by merit.edu (5.65/1123-1.0) id AA26430; Wed, 19 Feb 92 21:02:29 -0500 Received: by Valinor.Stanford.EDU (5.65/inc-1.0) id AA28697; Wed, 19 Feb 92 18:02:25 -0800 Date: Wed, 19 Feb 92 18:02:24 PST From: Vince Fuller To: regional-techs Office: Spruce Hall F15, (415) 723-6860 Usmail: Pine Hall 115, Stanford, CA, 94305-4122 Subject: CSU/DSU selection Message-Id: We at BARRNet are considering re-evaluating the T1 CSU/DSUs that we use in an effort to find a more cost-effective solution to connecting small sites which want T1 connectivity (we currently use Cylinks, which might be thought of as the "cadillac" of CSU/DSUs - many features, kinda pricey...) To this end, I'd appreciate hearing about experience that other networks have had with T1 CSU/DSUs made by various manufacturers. The following evaluation criteria are of particular interest: - Cost per unit (list price, price we can expect to get, discount plans offered, if any) - Does manufacuturer offer multi-unit "nest" (and if so, cost) - Framing options (D4 vs. ESF, etc.) - Line encoding options (AMI vs. B8ZS, etc.) - Maximum effective bandwidth (1344 vs. 1536); if full-T1, what scheme is used to guarentee one's density requirement is met Responses to vaf@stanford.edu - I'll summarize if there is interest. --Vince - - - - - - - - - - - - - - - - - From skw Thu Feb 20 09:15:20 1992 Received: by merit.edu (5.65/1123-1.0) id AA05955; Thu, 20 Feb 92 04:33:05 -0500 From: "Steven K. Widmayer" Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA05948; Thu, 20 Feb 92 04:33:03 -0500 Received: by home.merit.edu (4.1/client-0.9) id AA13970; Thu, 20 Feb 92 04:33:01 EST Date: Thu, 20 Feb 92 04:33:01 EST Message-Id: <9202200933.AA13970@home.merit.edu> To: nwg Subject: Additions to the NSFNET policy-based routing database The following networks have been added to the NSFNET policy-based routing database: T1 Network: no additions. Total NSFNET T1 announced networks: 4691 T3 Network: 646 T1 configured NYSERNET Regional Network / PSI (AS 174) networks (not listed here) have been added to the T3 database. 47 T1 configured Georgia Tech (AS 279) networks (not listed here) have been added to the T3 database. Total NSFNET T3 announced networks: 2070 The following T3 gate has been added: AS Number: 279 AS Notes: Georgia Tech AS Country Code: US ANS: No BkBn: 690 NSS: 140.222.138 - Georgia Tech Georgia Tech Gate: 192.76.181.1 - GIT1 Georgia Tech, Atlanta, GA The configuration reports, map information sheets, and configuration files which reflect these changes are available for anonymous ftp on nis.nsf.net as usual. nsfsites - configuration reports latest report for: - NSFNET T1 has the file extension .now - NSFNET T3 has the file extension 3.now nsfconfg - configuration files for the routing software for each NSS latest report for: - NSFNET T1 has the file format config.nss# - NSFNET T3 has the file extension .t3p Please send all requests for configuration changes to nsfnet-admin@merit.edu using the NSFNET configuration forms. The forms are available on-line from the nis.nsf.net machine. Use ftp and the anonymous login to get on the machine. Do a "cd nsfsites" and grab the files TEMPLATE.NET, TEMPLATE.GATE, and TEMPLATE.AS. --Steve Widmayer Merit/NSFNET - - - - - - - - - - - - - - - - - From bsb Fri Feb 21 09:20:55 1992 Received: by merit.edu (5.65/1123-1.0) id AA18660; Fri, 21 Feb 92 09:21:00 -0500 From: "Belinda Sue Blair" Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA18656; Fri, 21 Feb 92 09:20:55 -0500 Received: by home.merit.edu (4.1/client-0.9) id AA04694; Fri, 21 Feb 92 09:20:54 EST Date: Fri, 21 Feb 92 09:20:54 EST Message-Id: <9202211420.AA04694@home.merit.edu> To: nwg Subject: Additions to the NSFNET policy-based routing database The following networks have been added to the NSFNET policy-based routing database: T1 Network: Net # Net Name Primary Secondary Location -------- ----------- ------- --------- -------- 192.101.197 ECAN 590 European Center for Advanced Networking (EBM ECAN), Tiergartenstr. 8, D-6900 Heidelberg, GERMANY 155.225 CITNET-B 297 372 The Citadel, Computer Center, Charleston, SC 29409, USA 192.147.26 BCM-TEST-B 750 756 Baylor College of Medicine, Texas Medical Center, Houston, TX 77030, USA 192.138.24 AMEDD-HCSSA 184 164 Health Care Systems Support Activity,2455 NE 410, Ste 150, San Antonio, TX 78217, USA 192.93.238 FNET-CICBX2 590 Centre Interuniversitaire de Calcul de Bordeaux, 351, cours de la Liberation, 33405 Talence CEDEX, FRANCE 192.93.13 FNET-CEMES 1238 CEMES-LOE, BP 4347, F-31055 Toulouse CEDEX, FRANCE 192.86.167 OMPT 1238 Observatoire Midi pyrenees, 14 avenue Edouard Belin, 31400 Toulouse, FRANCE 192.84.220 HQ-NET 750 756 HQ-Interaktive Mediensysteme, Schusterinsel 7, D-7858 Weil am Rhein, GERMANY 192.70.193 GEOWASH-NET1 209 210 Colorado SuperNet, Inc., Colorado School of Mines, 1500 Illinois, Golden, CO 80401, USA 192.70.112 FNET-CNET194 1238 FNET, Institut National de Recherche en Informatique et Automatique, Domaine de Voluceau, Rocquencourt, BP 105, F-78153 Le Chesnay CEDEX, FRANCE 192.65.174 TJHSST 86 279 Thomas Jefferson High School for Science and Technology, 6560 Braddock Road,, Alexandria, VA 22312, USA 192.54.152 FNET-INSA-ROUEN 590 I.N.S.A. (Institut National Des Sciences Appliquees) de Rouen, BP 8; F-76131 Mont Saint Aignan, FRANCE 192.16.239 DRE-NET5 174 750 Defense Research Establishment Ottawa, Shirley Bay, Ottawa, Ontario, CANADA 192.16.238 DRE-NET4 174 750 Defense Research Establishment Ottawa, Shirley Bay, Ottawa, Ontario, CANADA 192.16.237 DRE-NET3 174 750 Defense Research Establishment Ottawa, Shirley Bay, Ottawa, Ontario, CANADA 192.16.236 DRE-NET2 174 750 Defense Research Establishment Ottawa, Shirley Bay, Ottawa, Ontario, CANADA 192.16.235 DRE-NET1 174 750 Defense Research Establishment Ottawa, Shirley Bay, Ottawa, Ontario, CANADA 192.16.234 DRE-DOC1 174 750 Defense Research Establishment Ottawa, Shirley Bay, Ottawa, Ontario, CANADA 192.16.233 TCCCS-NET1 174 750 Defense Research Establishment Ottawa, Shirley Bay, Ottawa, Ontario, CANADA 192.12.239 CU-ACS 209 210 University of Colorado, Computing and Network Services, 3645 Marine St., Boulder, CO 80309-0455, USA 158.80 BAKER 233 177 G-1050 West Bristol Road, Baker College, USA 157.229 SSH-NET 1206 204 Shadyside Hospital, 5230 Centre Avenue, Pittsburgh, PA 15232, USA 157.159 INT-EVRY 1238 I.N.T.= Institut National des Telecoms, I.N.T. Centre de Calcul, 9 rue Charles Fourier, 91011 EVRY FRANCE 157.138 UNIVENET 590 Universita' degli Studi - Venezia, Dorsoduro 3861 30123 VENEZIA ITALY 155.2 ANSER 184 164 ANSER Information Technology Division, Arlington, VA 22202, USA 153.92 CCC-NET 750 756 Conware Computer Consulting, Killisfeldstrasse 64, W-7500 Karlsruhe 41, GERMANY 153.42 MESSIAH-NET 1206 204 Messiah College, Grantham, PA 17027, USA 150.189 VZ-NET5 1250 Consejo Nacional de Inverstiaciones Cientificas y Technoligia (CONICIT) , Officina de Informatica, Apartado 70617, Caracas, VENEZUELA 150.188 VZ-NET4 1250 Consejo Nacional de Inverstiaciones Cientificas y Technoligia (CONICIT), Officina de Informatica, Apartado 70617, Caracas, VENEZUELA 150.187 VZ-NET3 1250 Consejo Nacional de Inverstiaciones Cientificas y Technoligia (CONICIT), Officina de Informatica, Apartado 70617, Caracas, VENEZUELA 150.186 VZ-NET2 1250 Consejo Nacional de Inverstiaciones Cientificas y Technoligia (CONICIT), Officina de Informatica, Apartado 70617, Caracas, VENEZUELA 150.185 VZ-NET1 1250 Consejo Nacional de Inverstiaciones Cientificas y Technoligia (CONICIT), Officina de Informatica, Apartado 70617, Caracas, VENEZUELA 150.104 SBACIP 86 279 School Board of Alachua County, Information Resources, 620 East University Avenue, Gainesville, FL 36201-5498, USA 150.100 SINET1 1240 National Center for Science Information System, JAPAN 150.99 SINET 1240 National Center for Science Information System, JAPAN 149.236 BAM-LAN 750 756 Bruker Analytische Messtechnik GmbH, Am Silberstreifen, D-W-7512 Rheinstetten 4, GERMANY 147.250 ENSTA 1238 701 Ecole Nationale Superieure de Techniques Avancees - ENSTA, 32 Boulevard Victor, 75015 Paris, FRANCE 147.174 SELUNET 86 279 Southeastern Louisiana University, P.O. Box 430, Hammond, LA 70402, USA 144.118 DREXELSUBNET 1206 204 Telecommunications & Networking Group, Office of Computing Services, Drexel University, Philadelphia, PA 19104-2884, USA 141.44 TUMD 750 756 Technische Universitaet Magdeburg, Universitaetsrechenzent rum, Universitaetsplatz 2, PSF 4120, D-O-3010 Magdeburg, GERMANY 137.201 MICRON 210 209 Micron Technology, 2805 E. Columbia Road, Boise, ID 83706, USA 137.9 ANDREWS-NET1 184 164 Andrews Air Force Base, Camp Springs, MD 20331, USA Total NSFNET T1 announced networks: 4733 T1 special additions: AS# NSS Gate IP Protocol Description ---- ---- ------------ ---------- ------------- 1740 6 132.249.16.13 EGP cisco systems 1740 6 132.249.16.15 EGP cisco systems T3 Network: Network IP: 141.44 Network Name: TUMD Location: Technische Universitaet Magdeburg, Universitaetsrechenzentrum, Universitaetsplatz 2, PSF 4120, D-O-3010 Magdeburg, GERMANY Country Code: DE 1:1324 ANS New York City - DNSS 35 Network IP: 144.118 Network Name: DREXELSUBNET Location: Telecommunications & Networking Group, Office of Computing Services, Drexel University, Philadelphia, PA 19104-2884, USA Country Code: US 1:1206 PSCNET Network IP: 147.168 Network Name: NAVSWC-NET Location: Naval Surface Warfare Center, White Oak Laboratory, Silver Spring, MD 20903-5000, USA Country Code: US 1:86 ENSS 136, College Park 2:279 Georgia Tech Network IP: 147.174 Network Name: SELUNET Location: Southeastern Louisiana University, P.O. Box 430, Hammond, LA 70402, USA Country Code: US 1:86 ENSS 136, College Park 2:279 Georgia Tech Network IP: 149.236 Network Name: BAM-LAN Location: Bruker Analytische Messtechnik GmbH, Am Silberstreifen, D-W-7512 Rheinstetten 4, GERMANY Country Code: DE 1:1324 ANS New York City - DNSS 35 Network IP: 150.104 Network Name: SBACIP Location: School Board of Alachua County, Information Resources, 620 East University Avenue, Gainesville, FL 36201-5498, USA Country Code: US 1:86 ENSS 136, College Park 2:279 Georgia Tech Network IP: 153.42 Network Name: MESSIAH-NET Location: Messiah College, Grantham, PA 17027, USA Country Code: US 1:1206 PSCNET Network IP: 153.92 Network Name: CCC-NET Location: Conware Computer Consulting, Killisfeldstrasse 64, W-7500 Karlsruhe 41, GERMANY Country Code: DE 1:1324 ANS New York City - DNSS 35 Network IP: 157.229 Network Name: SSH-NET Location: Shadyside Hospital, 5230 Centre Avenue, Pittsburgh, PA 15232, USA Country Code: US 1:1206 PSCNET Network IP: 158.80 Network Name: BAKER Location: G-1050 West Bristol Road, Baker College, USA Country Code: US 1:237 MERIT network Network IP: 192.16.233 Network Name: TCCCS-NET1 Location: Defense Research Establishment Ottawa, Shirley Bay, Ottawa, Ontario, CANADA Country Code: CA 1:174 NYSERNET Regional Network / PSI Network IP: 192.16.234 Network Name: DRE-DOC1 Location: Defense Research Establishment Ottawa, Shirley Bay, Ottawa, Ontario, CANADA Country Code: CA 1:174 NYSERNET Regional Network / PSI Network IP: 192.16.235 Network Name: DRE-NET1 Location: Defense Research Establishment Ottawa, Shirley Bay, Ottawa, Ontario, CANADA Country Code: CA 1:174 NYSERNET Regional Network / PSI Network IP: 192.16.236 Network Name: DRE-NET2 Location: Defense Research Establishment Ottawa, Shirley Bay, Ottawa, Ontario, CANADA Country Code: CA 1:174 NYSERNET Regional Network / PSI Network IP: 192.16.237 Network Name: DRE-NET3 Location: Defense Research Establishment Ottawa, Shirley Bay, Ottawa, Ontario, CANADA Country Code: CA 1:174 NYSERNET Regional Network / PSI Network IP: 192.16.238 Network Name: DRE-NET4 Location: Defense Research Establishment Ottawa, Shirley Bay, Ottawa, Ontario, CANADA Country Code: CA 1:174 NYSERNET Regional Network / PSI Network IP: 192.16.239 Network Name: DRE-NET5 Location: Defense Research Establishment Ottawa, Shirley Bay, Ottawa, Ontario, CANADA Country Code: CA 1:174 NYSERNET Regional Network / PSI Network IP: 192.58.225 Network Name: NCRDS3 Location: U.S. Geological Survey, 809 National Center, Reston, VA 22092 Country Code: US 1:201 BARRNet Network IP: 192.65.174 Network Name: TJHSST Location: Thomas Jefferson High School for Science and Technology, 6560 Braddock Road, Alexandria, VA 22312, USA Country Code: US 1:86 ENSS 136, College Park 2:279 Georgia Tech Network IP: 192.84.220 Network Name: HQ-NET Location: HQ-Interaktive Mediensysteme, Schusterinsel 7, D-7858 Weil am Rhein, GERMANY Country Code: DE 1:1324 ANS New York City - DNSS 35 Network IP: 192.147.26 Network Name: BCM-TEST-B Location: Baylor College of Medicine, Texas Medical Center, Houston, TX 77030, USA Country Code: US 1:1700 Rice University, Houston, TX Total NSFNET T3 announced networks: 2090 T3 special additions: AS Number: 1740 AS Notes: CERFnet AS Country Code: US Gate: 132.249.32.13 - longboard.sdsc.edu ENSS 135 - San Diego The configuration reports, map information sheets, and configuration files which reflect these changes are available for anonymous ftp on nis.nsf.net as usual. nsfsites - configuration reports latest report for: - NSFNET T1 has the file extension .now - NSFNET T3 has the file extension 3.now nsfconfg - configuration files for the routing software for each NSS latest report for: - NSFNET T1 has the file format config.nss# - NSFNET T3 has the file extension .t3p Please send all requests for configuration changes to nsfnet-admin@merit.edu using the NSFNET configuration forms. The forms are available on-line from the nis.nsf.net machine. Use ftp and the anonymous login to get on the machine. Do a "cd nsfsites" and grab the files TEMPLATE.NET, TEMPLATE.GATE, and TEMPLATE.AS. ************** -B. Sue Blair Merit Network Operations - - - - - - - - - - - - - - - - - From skw Mon Feb 24 08:03:08 1992 Received: by merit.edu (5.65/1123-1.0) id AA18759; Mon, 24 Feb 92 08:03:11 -0500 From: "Steven K. Widmayer" Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA18754; Mon, 24 Feb 92 08:03:08 -0500 Received: by home.merit.edu (4.1/client-0.9) id AA14193; Mon, 24 Feb 92 08:03:07 EST Date: Mon, 24 Feb 92 08:03:07 EST Message-Id: <9202241303.AA14193@home.merit.edu> To: nwg Subject: Additions to the NSFNET policy-based routing database The following networks have been added to the NSFNET policy-based routing database: T1 Network: no additions. Total NSFNET T1 announced networks: 4733 T3 Network: 125 T1 configured CERFnet (AS 1740) networks (not listed here) have been added to the T3 database. Total NSFNET T3 announced networks: 2217 The configuration reports, map information sheets, and configuration files which reflect these changes are available for anonymous ftp on nis.nsf.net as usual. nsfsites - configuration reports latest report for: - NSFNET T1 has the file extension .now - NSFNET T3 has the file extension 3.now nsfconfg - configuration files for the routing software for each NSS latest report for: - NSFNET T1 has the file format config.nss# - NSFNET T3 has the file extension .t3p Please send all requests for configuration changes to nsfnet-admin@merit.edu using the NSFNET configuration forms. The forms are available on-line from the nis.nsf.net machine. Use ftp and the anonymous login to get on the machine. Do a "cd nsfsites" and grab the files TEMPLATE.NET, TEMPLATE.GATE, and TEMPLATE.AS. --Steve Widmayer Merit/NSFNET - - - - - - - - - - - - - - - - - From nwg-owner Mon Feb 24 11:03:45 1992 Received: by merit.edu (5.65/1123-1.0) id AA23984; Mon, 24 Feb 92 11:03:58 -0500 Received: from mako.psc.edu by merit.edu (5.65/1123-1.0) id AA23975; Mon, 24 Feb 92 11:03:45 -0500 Received: by mako.psc.edu (5.57/Ultrix2.4-C cf:ab 9/11/90 --MM--) id AA09747; Mon, 24 Feb 92 11:03:29 -0500 Message-Id: <9202241603.AA09747@mako.psc.edu> To: "Steven K. Widmayer" Cc: nwg, petko@mako.psc.edu Subject: Re: Additions to the NSFNET policy-based routing database In-Reply-To: Your message of "Mon, 24 Feb 92 08:03:07 EST." <9202241303.AA14193@home.merit.edu> Date: Mon, 24 Feb 92 11:03:22 -0500 From: petko@mako.psc.edu X-Mts: smtp Only if we have gotten the memory that Ken ordered. I don't know if we have. BTW, did Mark P. get his 30ft wyse cable? Stephen - - - - - - - - - - - - - - - - - From nwg-owner Mon Feb 24 11:13:07 1992 Received: by merit.edu (5.65/1123-1.0) id AA24256; Mon, 24 Feb 92 11:13:10 -0500 Received: from nic.cerf.net by merit.edu (5.65/1123-1.0) id AA24252; Mon, 24 Feb 92 11:13:07 -0500 Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA25982; Mon, 24 Feb 92 08:16:04 PST From: Pushpendra Mohta Message-Id: <9202241616.AA25982@nic.cerf.net> Subject: A note on CERFnet Routing Changes over the weekend To: skw (Steven K. Widmayer) Date: Mon, 24 Feb 92 8:16:03 PST Cc: nwg In-Reply-To: <9202241303.AA14193@home.merit.edu>; from "Steven K. Widmayer" at Feb 24, 92 8:03 am X-Usmail: CERFnet, P.O. BOX 85608, San Diego, CA 92186-9784 X-Mailer: ELM [version 2.3 PL11] Steven K. Widmayer writes: >> >> >>T3 Network: >> >>125 T1 configured CERFnet (AS 1740) networks (not listed here) have been >>added to the T3 database. >> I have had a few requests for information about this change in CERFnet routing. Two major changes took place over the weekend. (1) Erstwhile AS 195 split into AS 1740 (CERFnet ) and AS 195 (SDSCnet) AS 1740 has about 125 primary nets and AS 195 about 10. AS 1740 is a secondary AS for about 15 more. Some of our peers use MERIT's database for access-lists and measuring inter AS traffic flows. They might want to update their local databases. (2) CERFnet began routing on the T3 NSFnet backbone. The following defines CERFnet's *current* routing preferences: (1) CERFnet member routes (2) Routes received from CERFnet peers: CIX CSUnet ESNet LosNettos KREOnet SDSCnet (3) Routes received from the T3 ENSFnet. (4) Default to T1 NSFnet (5) Default to T3 ENSFnet --pushpendra Pushpendra Mohta pushp@cerf.net +1 619 534 5056 CERFNet - - - - - - - - - - - - - - - - - From nwg-owner Mon Feb 24 11:22:16 1992 Received: by merit.edu (5.65/1123-1.0) id AA24614; Mon, 24 Feb 92 11:22:24 -0500 Received: from mako.psc.edu by merit.edu (5.65/1123-1.0) id AA24608; Mon, 24 Feb 92 11:22:16 -0500 Received: by mako.psc.edu (5.57/Ultrix2.4-C cf:ab 9/11/90 --MM--) id AA09801; Mon, 24 Feb 92 11:21:56 -0500 Message-Id: <9202241621.AA09801@mako.psc.edu> To: petko@mako.psc.edu Cc: "Steven K. Widmayer" , nwg, petko@mako.psc.edu Subject: Re: Additions to the NSFNET policy-based routing database In-Reply-To: Your message of "Mon, 24 Feb 92 11:03:22 EST." <9202241603.AA09747@mako.psc.edu> Date: Mon, 24 Feb 92 11:21:51 -0500 From: petko@mako.psc.edu X-Mts: smtp Sorry about the goof. Stephen - - - - - - - - - - - - - - - - - From donnab@CERF.NET Mon Feb 24 16:13:05 1992 Received: from nic.cerf.net by merit.edu (5.65/1123-1.0) id AA03273; Mon, 24 Feb 92 16:13:05 -0500 Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA11844; Mon, 24 Feb 92 13:15:47 PST Date: Mon, 24 Feb 92 13:15:47 PST From: Donna Bigley Message-Id: <9202242115.AA11844@nic.cerf.net> To: broidoj@Sds.Sdsc.Edu, help@CERF.NET, nsfnet-reports, ops@cerf.net Subject: CERFnet Weekly Report for the week of Monday, February 23, 1992. ############################################################################### This is the CERFnet weekly activity report for the period of Monday, February 17th through Sunday, February 23rd, 1992. This report is also available through anonymous FTP from NIC.CERF.NET [192.102.249.3] in the cerfnet/cerfnet_stats subdirectory. The filename is: 23-february-92.txt All times are in Pacific Standard Time, and in the 24-hour format. Please direct any questions or comments to: donnab@cerf.net or help@cerf.net ****************************************************************************** NETWORK OUTAGES: SITE: McDonnell Douglas SITES AFFECTED: McDonnell Douglas TIME STARTED: MON. 2-17-92 15:55 TIME ENDED: MON. 2-17-92 16:30 TIME ELAPSED: 35 min. REASON: Site Scheduled Maintenance SITE: McDonnell Douglas SITES AFFECTED: McDonnell Douglas TIME STARTED: MON. 2-17-92 20:30 TIME ENDED: WED. 2-19-92 13:33 TIME ELAPSED: 1 day 17 hours 3 min. (Intermittent Access) REASON: Equipment Trouble SITE: SERI/KOREA SITES AFFECTED: SERI/KOREA TIME STARTED: WED. 2-19-92 04:42 TIME ENDED: WED. 2-19-92 08:48 TIME ELAPSED: 4 hours 6 min. REASON: Unknown SITE: CIT SITES AFFECTED: CIT Dial n' CERF, OXY, Disney, Claremont, Cadam, and SCAQMD. TIME STARTED: WED. 2-19-92 08:16 TIME ENDED: WED. 2-19-92 08:24 TIME ELAPSED: 8 min. REASON: CERFnet Scheduled Maintenance SITE: CIT-SDSC T1 SITES AFFECTED: CIT-SDSC T1 TIME STARTED: THU. 2-20-92 08:36 TIME ENDED: THU. 2-20-92 09:59 TIME ELAPSED: 1 hour 23 min. REASON: Link Failure SITE: PEPPERDINE SITES AFFECTED: PEPPERDINE TIME STARTED: SAT. 2-22-92 09:54 TIME ENDED: SAT. 2-22-92 11:01 TIME ELAPSED: 1 hour 7 min. REASON: Site Scheduled Maintenance SITE: GA SITES AFFECTED: GA TIME STARTED: SAT. 2-22-92 05:26 TIME ENDED: SAT. 2-22-92 12:59 TIME STARTED: SAT. 2-22-92 17:41 TIME ENDED: SAT. 2-22-92 19:34 TIME ELAPSED: 9 hours 26 min. REASON: Unscheduled Site Maintenance SITE: UCOP SITES AFFECTED: UCOP Dial n' CERF, Netlabs, LSIL, Intel-SC, Farallon, Cisco, SCAQMD and CIX-WEST. TIME STARTED: SUN. 2-23-92 13:34 TIME ENDED: MON. 2-24-92 06:25 TIME ELAPSED: 16 hours 51 min. REASON: Equipment Trouble ------------------------------------------------------------------------ NETWORK ACTIVITY: A heavy load on the CERFnet stub on Thursday, February 20th, affected routing; however, the load has been brought down and routing stablized. On Friday, February 21st, all T1 networks announced out of San Diego were not getting announced into any of the T3 gateways on the NSFnet. After NSFnet reloaded the new configurations, the T1 hosts were reachable through the T3 side. On Saturday, February 22nd, between 10:00 - 11:30, and on Monday, February 24th, between 04:00 - 04:30, there was intermittent access due to new NSFnet routing. CERFnet split into a separate AS # for routing to and from the NSFnet. ------------------------------------------------------------------------ CERFNET TRAFFIC CAPACITY USAGE AT EACH CIRCUIT LINK LINK SPEED CAPACITY PEAK HOUR (PDT) SDSC/CALTECH 1.544 mbps 12.1% 17:00 SDSC/UCI 1.544 mbps 05.7% 12:00 SDSC/UCLA 1.544 mbps 04.9% 12:00 SDSC/UCOP 1.544 mbps 04.6% 11:00 UCI/UCLA 1.544 mbps 00.6% 17:00 SDSC/UCR 512 kbps 01.5% 13:00 UCLA/UCSB 512 kbps 06.5% 14:00 SDSC/AGI 1.544 mbps 00.2% 20:00 SDSC/BIOSYM 1.544 mbps 00.2% 11:00 SDSC/GA 1.544 mbps 00.1% 17:00 SDSC/GD 1.544 mbps 02.2% 08:00 SDSC/SAIC 1.544 mbps 00.9% 07:00 SDSC/SCAQMD 1.544 mbps 00.04% 12:00 SDSC/SDSU 1.544 mbps 01.4% 17:00 UCI/CSU CO(SWRL) 1.544 mbps 02.3% 17:00 UCOP/APPLE 1.544 mbps 00.9% 14:00 UCOP/CISCO 1.544 mbps 00.3% 18:00 UCR/LLUMC 1.544 mbps 00.02% 17:00 CALTECH/CADAM 56 kbps 00.6% 17:00 CALTECH/CLAREMONT 56 kbps 15.3% 15:00 CALTECH/DISNEY 56 kbps 04.3% 17:00 CALTECH/OXY 56 kbps 15.4% 17:00 SDSC/AJS 56 kbps 01.7% 07:00 SDSC/KOREA 56 kbps 11.8% 18:00 SDSC/QUALCOMM 56 kbps 06.5% 11:00 SDSC/SCIH 56 kbps 04.2% 13:00 SDSC/USD 56 kbps 06.0% 17:00 SDSC/USIU 56 kbps 00.6% 17:00 SDSC/XEROX 56 kbps 01.0% 15:00 UCI/CMD 56 kbps 05.2% 20:00 UCI/EMULEX 56 kbps 01.1% 17:00 UCI/FULLERTON 56 kbps 01.7% 07:00 UCI/HUGHES 56 kbps 10.8% 13:00 UCI/MTI 56 kbps 05.5% 11:00 UCI/SPARTA 56 kbps 02.5% 04:00 UCI/UNOCAL 56 kbps 07.0% 08:00 UCLA/ISX 56 kbps 01.6% 09:00 UCLA/PEPPERDINE 56 kbps 01.6% 08:00 UCLA/QUOTRON 56 kbps 06.4% 05:00 UCLA/SMC 56 kbps 00.6% 01:00 UCOP/FARALLON 56 kbps 05.8% 08:00 UCOP/INTEL 56 kbps 17.0% 17:00 UCOP/LSIL 56 kbps 08.8% 22:00 UCOP/NETLABS 56 kbps 11.9% 19:00 ------------------------------------------------------------------------------ SITE CISCO BOX UPTIME SINCE LAST REBOOT (as of 00:15 PST on Feb. 24, 1992): CERFnet BACKBONE CALTECH [131.215.139.253] Up: 04 days 15 hours 51 minutes [CERFnet Scheduled Maintenance] SDSC Drzog [132.249.16.13] Up: 01 days 13 hours 52 minutes [Software Changes] SDSC Hang10 [132.249.16.15] Up: 00 days 00 hours 35 minutes [Software Changes] UCI [128.200.1.101] Up: 45 days 16 hours 07 minutes UCLA [128.97.130.10] Up: 16 days 13 hours 42 minutes UCOP [134.24.52.112] STILL DOWN [Equipment Trouble] UCR [134.24.108.105] Up: 100 days 12 hours 36 minutes CERF 1544 AGI [134.24.202.110] Up: 10 days 13 hours 54 minutes APPLE [134.24.70.200] Up: 119 days 06 hours 15 minutes BIOSYM [134.24.57.200] Up: 21 days 06 hours 48 minutes CISCO Systems [134.24.54.200] Up: 82 days 14 hours 09 minutes CSUCO/SWRL [130.150.102.200] Up: 40 days 12 hours 46 minutes GA [134.24.221.200] Up: 01 days 04 hours 41 minutes [Unscheduled Site Maintenance] GD [134.24.60.200] Up: 53 days 04 hours 14 minutes LLUMC [134.24.208.200] Up: 96 days 12 hours 22 minutes SAIC [134.24.53.208] Up: 50 days 08 hours 34 minutes SCAQMD [134.24.234.200] Up: 66 days 14 hours 27 minutes SDSU [192.77.100.101] Up: 76 days 16 hours 31 minutes UCSB [134.24.107.107] Up: 96 days 07 hours 38 minutes CERF 56 AJS [134.24.225.101] Up: 37 days 14 hours 17 minutes CADAM [134.24.229.200] Up: 19 days 13 hours 01 minutes CLAREMONT [134.24.206.109] Up: 10 days 14 hours 02 minutes CMD [134.24.218.200] Up: 27 days 13 hours 14 minutes DATAPRODUCTS [134.24.211.104] Up: 04 days 00 hours 03 minutes [Site Activity] DISNEY [134.24.207.211] Up: 25 days 00 hours 33 minutes EMULEX [134.24.209.212] Up: 71 days 15 hours 48 minutes FARALLON [134.24.56.200] Up: 12 days 15 hours 03 minutes FULLERTON [134.24.214.217] Up: 69 days 15 hours 33 minutes HUGHES [134.24.204.200] Up: 101 days 07 hours 21 minutes INTEL [134.24.55.200] Up: 57 days 03 hours 19 minutes LSIL [134.24.72.200] Up: 15 days 13 hours 08 minutes MTI [134.24.216.100] Up: 51 days 13 hours 39 minutes NETLABS [134.24.71.200] Up: 79 days 15 hours 07 minutes OXY [134.24.205.108] Up: 10 days 19 hours 45 minutes PEPPERDINE [134.24.203.218] Up: 01 days 13 hours 14 minutes [Site Scheduled Maintenance] QUALCOMM [134.24.200.201] Up: 11 days 09 hours 37 minutes QUOTRON [134.24.230.202] Up: 91 days 13 hours 44 minutes SANTA MONICA [134.24.210.219] Up: 45 days 01 hours 22 minutes SCI-HOR [134.24.109.205] Up: 87 days 11 hours 15 minutes SERI/KOREA [134.24.223.200] Up: 153 days 00 hours 00 minutes SPARTA [134.24.215.200] Up: 10 days 19 hours 09 minutes UNOCAL [134.24.217.200] Up: 01 days 13 hours 01 minutes [Unknown] USD [134.24.201.106] Up: 25 days 15 hours 45 minutes USIU [134.24.222.215] Up: 232 days 17 hours 07 minutes XEROX [134.24.51.207] Up: 116 days 23 hours 22 minutes DIAL n' CERF DNC-SDSC [134.24.1.2] Up: 40 days 04 hours 51 minutes DNC-UCI [134.24.2.2] Up: 47 days 03 hours 24 minutes DNC-UCLA [134.24.3.2] Up: 32 days 12 hours 38 minutes DNC-CALTECH [134.24.4.2] Up: 04 days 15 hours 35 minutes [CERFnet Scheduled Maintenance] DNC-UCOP [134.24.5.2] Up: 15 days 08 hours 58 minutes - - - - - - - - - - - - - - - - - From skw Tue Feb 25 09:52:14 1992 Received: by merit.edu (5.65/1123-1.0) id AA27896; Tue, 25 Feb 92 09:52:16 -0500 From: "Steven K. Widmayer" Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA27892; Tue, 25 Feb 92 09:52:14 -0500 Received: by home.merit.edu (4.1/client-0.9) id AA05038; Tue, 25 Feb 92 09:52:13 EST Date: Tue, 25 Feb 92 09:52:13 EST Message-Id: <9202251452.AA05038@home.merit.edu> To: nwg Subject: Additions to the NSFNET policy-based routing database The following networks have been added to the NSFNET policy-based routing database: T1 Network: Net # Net Name Primary Secondary Location -------- ----------- ------- --------- -------- 145.30 AMSMSS 590 Koninklijke/Shell-Labor otorium Amsterdam, P.O.Box 3003; NL - 1003 AA Amsterdam, NETHERLANDS 152.79 UCDMC 201 754 University of California, Davis, Computing Services, Davis, CA 95626 156.116 NR-NCC 1238 Norwegian Computer Center, P.O. Box 114, Blindern, N-0314 Oslo, NORWAY 192.36.73 TIPNET 1238 Swedish Telecom, S-123 86 Farsta, SWEDEN 192.88.195 OARNET-BLOCK4 750 756 Ohio Supercomputer Center, 1224 Kinnear Road, Columbus, OH 43212 192.92.130 EUNET-BE 701 1238 EUnet Belgium, c/o KU Leuven, Dept. Computerwetenschappen, Celestijnenlaan 200A, B-3001 Heverlee, BELGIUM 192.92.131 EUNET-BE-LINKS 701 1238 EUnet Belgium, c/o KU Leuven, Dept. Computerwetenschappen, Celestijnenlaan 200A, B-3001 Heverlee, BELGIUM Total NSFNET T1 announced networks: 4733 T3 Network: 56 T1 configured CICnet (AS 266/267) networks (not listed here) have been added/changed in the T3 database to OARNet (AS 600). Network IP: 152.79 Network Name: UCDMC Location: University of California, Davis, Computing Services, Davis, CA 95626 Country Code: US 1:201 BARRNet Network IP: 192.88.195 Network Name: OARNET-BLOCK4 Location: Ohio Supercomputer Center, 1224 Kinnear Road, Columbus, OH 43212 Country Code: US 1:600 OARNET, Cleveland, OH Total NSFNET T3 announced networks: 2217 The configuration reports, map information sheets, and configuration files which reflect these changes are available for anonymous ftp on nis.nsf.net as usual. nsfsites - configuration reports latest report for: - NSFNET T1 has the file extension .now - NSFNET T3 has the file extension 3.now nsfconfg - configuration files for the routing software for each NSS latest report for: - NSFNET T1 has the file format config.nss# - NSFNET T3 has the file extension .t3p Please send all requests for configuration changes to nsfnet-admin@merit.edu using the NSFNET configuration forms. The forms are available on-line from the nis.nsf.net machine. Use ftp and the anonymous login to get on the machine. Do a "cd nsfsites" and grab the files TEMPLATE.NET, TEMPLATE.GATE, and TEMPLATE.AS. --Steve Widmayer Merit/NSFNET - - - - - - - - - - - - - - - - - From cert-advisory-request@cert.sei.cmu.edu Tue Feb 25 12:57:18 1992 Received: from tictac.cert.sei.cmu.edu by merit.edu (5.65/1123-1.0) id AA03568; Tue, 25 Feb 92 12:57:18 -0500 Received: by tictac.cert.sei.cmu.edu (5.65/2.5) id AA00311; Tue, 25 Feb 92 12:44:25 -0500 Message-Id: <9202251744.AA00311@tictac.cert.sei.cmu.edu> From: CERT Advisory Date: Tue, 25 Feb 92 12:42:30 EST To: cert-advisory@cert.sei.cmu.edu Subject: CERT Advisory - AT&T /usr/etc/rexecd Vulnerability Organization: Computer Emergency Response Team : 412-268-7090 =========================================================================== CA-92:04 CERT Advisory February 25, 1992 AT&T /usr/etc/rexecd Vulnerability --------------------------------------------------------------------------- The Computer Emergency Response Team/Coordination Center (CERT/CC) has received information concerning a vulnerability in AT&T TCP/IP Release 4.0 running on SVR4 systems for both the 386/486 and 3B2 RISC platforms. The existing error, in the remote execution server /usr/etc/rexecd, has been corrected, and a new executable for rexecd is available from AT&T by calling 800-543-9935. Patches may be obtained outside the U.S. by calling your local technical support. The numbers associated with the fix are 5127 (3.5" media) and 5128 (5.25" media). The problem does not exist in TCP/IP release 3.2 for SVR3, or any earlier versions of the TCP/IP product running on either the 3B2 or 386 platforms. The version of TCP/IP distributed with SVR4 by UNIX(r) System Laboratories, Inc. (a subsidiary of AT&T) does not contain this vulnerability. UNIX(r) is a registered trademark of UNIX System Laboratories, Inc. --------------------------------------------------------------------------- I. Description A vulnerability has been identified where root privileges may be accessed through the use of /usr/etc/rexecd. II. Impact A user on a remote machine may be able to run commands as root on the target host (the host running the affected /usr/etc/rexecd). III. Solution 1. Administrators of affected systems should execute, as root, the following command to immediately turn off access to rexecd until the new binary can be obtained. # chmod 400 /usr/etc/rexecd 2. Obtain and install the new patch. The fix will be supplied as one diskette, and it comes with one page of instructions documenting the procedure to replace the existing /usr/etc/rexecd binary. --------------------------------------------------------------------------- The CERT/CC wishes to thank Bradley E. Smith, Network & Technical Services, Bradley University, for bringing this vulnerability to our attention and for providing a corresponding solution. We would also like to thank AT&T for their very quick response to this problem. --------------------------------------------------------------------------- If you believe that your system has been compromised, contact CERT/CC or your representative in FIRST (Forum of Incident Response and Security Teams). Internet E-mail: cert@cert.sei.cmu.edu Telephone: 412-268-7090 (24-hour hotline) CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4), on call for emergencies during other hours. Computer Emergency Response Team/Coordination Center (CERT/CC) Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Past advisories, information about FIRST representatives, and other information related to computer security are available for anonymous ftp from cert.sei.cmu.edu (192.88.209.5). - - - - - - - - - - - - - - - - - From skw Wed Feb 26 05:54:12 1992 Received: by merit.edu (5.65/1123-1.0) id AA27120; Wed, 26 Feb 92 05:54:14 -0500 From: "Steven K. Widmayer" Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA27116; Wed, 26 Feb 92 05:54:12 -0500 Received: by home.merit.edu (4.1/client-0.9) id AA21069; Wed, 26 Feb 92 05:54:11 EST Date: Wed, 26 Feb 92 05:54:11 EST Message-Id: <9202261054.AA21069@home.merit.edu> To: nwg Subject: Additions to the NSFNET policy-based routing database The following networks have been added to the NSFNET policy-based routing database: T1 Network: Net # Net Name Primary Secondary Location -------- ----------- ------- --------- -------- 146.1 JAM-NET 114 1700 JAM, 3538 Bonilla, Houston, TX 77083 155.252 PWCPH 114 1700 Texas Women's College, Dallas, TX Total NSFNET T1 announced networks: 4740 T3 Network: 137 T1 configured Sesquinet (AS 114/280/1700) networks (not listed here) have been added to the T3 database. Network IP: 146.1 Network Name: JAM-NET Location: JAM, 3538 Bonilla, Houston, TX 77083 Country Code: US 1:114 SESQUINET Regional Network 2:1700 SESQUINET Regional Network Network IP: 155.252 Network Name: PWCPH Location: Texas Women's College, Dallas, TX Country Code: US 1:114 SESQUINET Regional Network 2:1700 SESQUINET Regional Network Network IP: 192.41.177 Network Name: SURA-NOC Location: University of Maryland, College Park, Maryland Country Code: US 42:702 Alternet Router 43:701 Alternet Router Total NSFNET T3 announced networks: 2369 The configuration reports, map information sheets, and configuration files which reflect these changes are available for anonymous ftp on nis.nsf.net as usual. nsfsites - configuration reports latest report for: - NSFNET T1 has the file extension .now - NSFNET T3 has the file extension 3.now nsfconfg - configuration files for the routing software for each NSS latest report for: - NSFNET T1 has the file format config.nss# - NSFNET T3 has the file extension .t3p Please send all requests for configuration changes to nsfnet-admin@merit.edu using the NSFNET configuration forms. The forms are available on-line from the nis.nsf.net machine. Use ftp and the anonymous login to get on the machine. Do a "cd nsfsites" and grab the files TEMPLATE.NET, TEMPLATE.GATE, and TEMPLATE.AS. --Steve Widmayer Merit/NSFNET - - - - - - - - - - - - - - - - - From bsb Fri Feb 28 07:58:39 1992 Received: by merit.edu (5.65/1123-1.0) id AA10034; Fri, 28 Feb 92 07:58:43 -0500 Received: by merit.edu (5.65/1123-1.0) id AA10030; Fri, 28 Feb 92 07:58:39 -0500 Date: Fri, 28 Feb 92 07:58:39 -0500 From: "Belinda Sue Blair" Message-Id: <9202281258.AA10030@merit.edu> To: nwg Subject: Additions to the NSFNET policy-based routing database The following networks have been added to the NSFNET policy-based routing database: T1 Network: Net # Net Name Primary Secondary Location -------- ----------- ------- --------- -------- 192.149.8 CCAC 1206 204 Community College of Allegheny County, 800 Allegheny Ave., Pittsburgh, PA 15233, USA 192.147.238 SUPERNET-DMZ 750 756 SuperNet/Supercomputing Review, 8445 Camino Santa Fe, Suite 204, San Diego, CA 92121, USA 192.147.230 ONE-NET 174 750 Open Networks Engineering, Inc., 777 East Eisenhower Parkway, Suite 315, Ann Arbor, MI 48108, USA 192.147.160 NWNET10 685 73 NorthWestNet, 15400 SE 30th Place, Suite 202, Bellevue, WA 98007, USA 192.147.44 MCIMAIL-DMZ 750 756 MCI Mail Operations, MCI Telecommunications, Inc., 501 63rd St., Downers Grove, IL 60516, USA 192.146.206 DROVERNET 93 Univ. of Science & Arts of OK, Box 82346 Chickasha OK 73018, USA 192.138.194 UHRICS 114 1700 University of Houston, College of Business, University of Houston, 4800, Calhoun, Houston, TX 77204-6282, USA 192.138.193 UHCBA 114 1700 University of Houston, College of Business, 4800, Calhoun, Houston, TX 77204-6282, USA 192.136.110 WESTNMUNIV 209 210 Western New Mexico University, P.O.Box 680, Silver City, NM 88062, USA 192.135.78 NCPC-NET 86 279 National Capital Planning Commission, NCPC, 801 Pennsylvannia Ave., NW, Suite 301, Wash., DC 20576, USA 192.103.12 USRA-NET 297 372 Universities Space Research Association, The Washington Office Center, 409 Third Street, SW, Suite 330, Washington, DC 20024, USA 192.77.173 PSINET-C-173 174 750 PSI, 165 Jordan Road, Troy, NY 12180, USA 192.70.171 MIAMI-MATH 194 University of Miami, Department of Mathematics and Computer Science, 1365 Memorial Drive, Room 515, Coral Gables, FL 33146, USA 192.70.57 FNET-CNET139 1238 FNET, Institut National de Recherche en Informatique et Automatique, Domaine de Voluceau, Rocquencourt, BP 105, F-78153 Le Chesnay CEDEX, FRANCE 192.31.89 MIAMI-CS-NET 194 University of Miami, Department of Mathematics and Computer Science, 1365 Memorial Drive, Room 515, Coral Gables, FL 33146, USA 157.199 HKR 174 750 Healthcare Knowledge Resources, Inc., 24 Frank Lloyd Wright Drive, P.O. Box 301, Ann Arbor, MI 48106-0301, USA 157.151 HOLONET 174 750 Information Access Technologies, Inc., HoloNet Internet Services, 46 Shattuck Square, Suite 11, Berkeley, CA 94704, USA 155.244 COCO-NET 174 750 Rome Research Corp., RL/C3DA, Griffiss AFB Building #3, Rome, NY 13441-5700, USA 152.106 RAUNET 701 702 Rand Afrikaans University, Johannesburg, REPUBLIC OF SOUTH AFRICA 151.160 MILLSAPS 279 86 Millsaps College, 1701 North State Street, Jackson, MS 39210, USA 150.148 DIMES 86 279 Parklawn Computer Center / DIMES HQ, Departmental Information Management Exchange system, Food & Drug Administration Room 2B57, 5600 Fishers Lane, Rockville, MD 20857, USA 138.65 FRANKFURT-GW1 184 164 Frankfurt Regional Information Center, V Corps Heasdquareters, Abrams Complex, Building 1, Frankfurt, GERMANY 137.19 ALLIED 555 Allied-Signal Corporation, P.O. Box 5016, 50 East Algonquin Road, Des Plaines, IL 60017-5016, USA 136.218 NUERNBERG-GW1 184 164 Nuernberg CDOIM, Building 1, W.O. Darby Kaserne, 8510 Fuerth, GERMANY 136.216 KARLSRUHE-GW1 184 164 CDOIM Karlsruhe, Smiley Barracks, Kanalweg 20, 7500 Karlsruhe, GERMANY 136.213 GRAFENWOEHR-GW1 184 164 CDOIM Grafenwoehr, Lager Gebaeude 8484, Camp Tunisia, 6144 Grafenwoehr, GERMANY 130.210 LINKNET 174 750 Link Flight Simulation Corporation, Industrial Park, Binghamton, NY 13902, USA 147.36 PIRMASENS-NET1 184 164 DCSOPS, 5th Signal Command, Pirmasens, GERMANY 144.215 TTI 1740 754 TTI/Citycorp, 3100 Ocean Park Blvd., Santa Monica, Ca. 90405, USA 143.53 BRAD-UNI 274 60 Bradford University, Computer Centre, Bradford, West Yorkshire BD7 1DP, UNITED KINGDOM 147.40 MANNHEIM-NET1 184 164 DCSOPS, 5th Signal Command, Mannheim, GERMANY 140.154 DARMSTADT-GW1 184 164 Darmstadt CDOIM, Building 4001, Cambrai Fritsch Kaserne, Darmstadt, GERMANY 139.222 UEA 274 60 University of East Anglia, University Plain, Norwich NR4 7TJ, UNITED KINGDOM 139.139 GIESSEN-GW1 184 164 Giessen, Pendleton Barracks, GERMANY 138.251 ST-AND 274 60 : LOCATION The University of St. Andrews, Fife, UNITED KINGDOM 146.182 UOVS 701 702 University of the Orange-Free State, Computer Centre, Bloemfontein 9300, REPUBLIC OF SOUTH AFRICA Total NSFNET T1 announced networks: 4775 T3 Network: Network IP: 130.210 Network Name: LINKNET Location: Link Flight Simulation Corporation, Industrial Park, Binghamton, NY 13902, USA Country Code: US 1:174 NYSERNET Regional Network / PSI Network IP: 131.214 Network Name: ROMENET Location: Rome Air Development Center/DCLD, Griffiss Air Force Base, Building 3, Rome, NY 13441-5700, USA Country Code: US 1:174 NYSERNET Regional Network / PSI Network IP: 144.215 Network Name: TTI Location: TTI/Citycorp, 3100 Ocean Park Blvd., Santa Monica, Ca. 90405, USA Country Code: US 1:1740 CERFnet Network IP: 146.182 Network Name: UOVS Location: University of the Orange-Free State, Computer Centre, Bloemfontein 9300, REPUBLIC OF SOUTH AFRICA Country Code: ZA 42:702 Alternet Router 43:701 Alternet Router Network IP: 150.148 Network Name: DIMES Location: Parklawn Computer Center / DIMES HQ, Departmental Information Management Exchange system, Food & Drug Administration Room 2B57, 5600 Fishers Lane, Rockville, MD 20857, USA Country Code: US 1:86 ENSS 136, College Park 2:279 Georgia Tech Network IP: 151.160 Network Name: MILLSAPS Location: Millsaps College, 1701 North State Street, Jackson, MS 39210, USA Country Code: US 1:279 Georgia Tech 2:86 ENSS 136, College Park Network IP: 152.106 Network Name: RAUNET Location: Rand Afrikaans University, Johannesburg, REPUBLIC OF SOUTH AFRICA Country Code: ZA 42:702 Alternet Router 43:701 Alternet Router Network IP: 155.244 Network Name: COCO-NET Location: Rome Air Development Center/DCLD, Griffiss Air Force Base, Building 3, Rome, NY 13441-5700, USA Country Code: US 1:174 NYSERNET Regional Network / PSI Network IP: 157.151 Network Name: HOLONET Location: Information Access Technologies, Inc., HoloNet Internet Services, 46 Shattuck Square, Suite 11, Berkeley, CA 94704, USA Country Code: US 1:174 NYSERNET Regional Network / PSI Network IP: 157.199 Network Name: HKR Location: Healthcare Knowledge Resources, Inc., 24 Frank Lloyd Wright Drive, P.O. Box 301, Ann Arbor, MI 48106-0301, USA Country Code: US 1:174 NYSERNET Regional Network / PSI Network IP: 192.73.216 Network Name: MDC Location: Mead Data Central, 933 Springboro Pike, Miamisburg, OH 45342, USA Country Code: US 1:1325 ANS Cleveland - DNSS 43 Network IP: 192.77.173 Network Name: PSINET-C-173 Location: PSI, 165 Jordan Road, Troy, NY 12180, USA Country Code: US 1:174 NYSERNET Regional Network / PSI Network IP: 192.132.29 Network Name: HUDSON Location: Hudson High School, 77 North Oviatt Street, Hudson, OH . Country Code: US 1:600 OARNET, Cleveland, OH Network IP: 192.135.78 Network Name: NCPC-NET Location: National Capital Planning Commission, NCPC, 801 Pennsylvannia Ave., NW, Suite 301, Wash., DC 20576, USA Country Code: US 1:86 ENSS 136, College Park 2:279 Georgia Tech Network IP: 192.138.193 Network Name: UHCBA Location: University of Houston, College of Business, 4800, Calhoun, Houston, TX 77204-6282, USA Country Code: US 1:114 SESQUINET Regional Network 2:1700 SESQUINET Regional Network Network IP: 192.138.194 Network Name: UHRICS Location: University of Houston, College of Business, University of Houston, 4800, Calhoun, Houston, TX 77204, USA Country Code: US 1:114 SESQUINET Regional Network 2:1700 SESQUINET Regional Network Network IP: 192.147.44 Network Name: MCIMAIL-DMZ Location: MCI Mail Operations, MCI Telecommunications, Inc., 501 63rd St., Downers Grove, IL 60516, USA Country Code: US 1:1323 ANS Chicago - DNSS 27 Network IP: 192.147.230 Network Name: ONE-NET Location: Open Networks Engineering, Inc., 777 East Eisenhower Parkway, Suite 315, Ann Arbor, MI 48108, USA Country Code: US 1:174 NYSERNET Regional Network / PSI Network IP: 192.147.238 Network Name: SUPERNET-DMZ Location: SuperNet/Supercomputing Review, 8445 Camino Santa Fe, Suite 204, San Diego, CA 92121, USA Country Code: US 1:1322 ANS Los Angeles - DNSS 19 Network IP: 192.149.8 Network Name: CCAC Location: Community College of Allegheny County, 800 Allegheny Ave., Pittsburgh, PA 15233, USA Country Code: US 1:1206 PSCNET Network IP: 192.147.44 Network Name: MCIMAIL-DMZ Location: MCI Mail Operations, MCI Telecommunications, Inc., 501 63rd St., Downers Grove, IL 60516, USA Country Code: US 1:1323 ANS Chicago - DNSS 27 Network IP: 192.147.230 Network Name: ONE-NET Location: Open Networks Engineering, Inc., 777 East Eisenhower Parkway, Suite 315, Ann Arbor, MI 48108, USA Country Code: US 1:174 NYSERNET Regional Network / PSI Network IP: 192.147.238 Network Name: SUPERNET-DMZ Location: SuperNet/Supercomputing Review, 8445 Camino Santa Fe, Suite 204, San Diego, CA 92121, USA Country Code: US 1:1322 ANS Los Angeles - DNSS 19 Network IP: 192.149.8 Network Name: CCAC Location: Community College of Allegheny County, 800 Allegheny Ave., Pittsburgh, PA 15233, USA Country Code: US 1:1206 PSCNET T3 special additions: ENSS 144 - NASA Ames ENSS 145 - College Park #2 Total NSFNET T3 announced networks: 2390 The configuration reports, map information sheets, and configuration files which reflect these changes are available for anonymous ftp on nis.nsf.net as usual. nsfsites - configuration reports latest report for: - NSFNET T1 has the file extension .now - NSFNET T3 has the file extension 3.now nsfconfg - configuration files for the routing software for each NSS latest report for: - NSFNET T1 has the file format config.nss# - NSFNET T3 has the file extension .t3p Please send all requests for configuration changes to nsfnet-admin@merit.edu using the NSFNET configuration forms. The forms are available on-line from the nis.nsf.net machine. Use ftp and the anonymous login to get on the machine. Do a "cd nsfsites" and grab the files TEMPLATE.NET, TEMPLATE.GATE, and TEMPLATE.AS. ************** -B. Sue Blair Merit Network Operations - - - - - - - - - - - - - - - - - From mak Fri Feb 28 18:53:01 1992 Received: from fox.merit.edu by merit.edu (5.65/1123-1.0) id AA00404; Fri, 28 Feb 92 18:53:01 -0500 Received: by fox.merit.edu (4.1/client-0.9) id AA25419; Fri, 28 Feb 92 18:53:07 EST Date: Fri, 28 Feb 92 18:53:07 EST From: mak Message-Id: <9202282353.AA25419@fox.merit.edu> To: regional-techs Subject: Preview of ANSNET/NSFNET Backbone Engineering Report We will include a more detailed report in the February Internet Monthly Report, but this summary gives a general report of events on the backbones over the last month. Mark ANSNET/NSFNET Backbone Engineering Report Preview of February, 1992 End-Of-Month Report ============================================= Mark Knopper, Merit Jordan Becker, ANS Summary ======= The T3 network continues to perform extremely well as it has since last November. During February, we have cut over a significant load of traffic from the T1 backbone to the T3 backbone. Midlevel networks that were cutover to use T3 in February include SURAnet (at both College Park and Atlanta), NyserNet/PSI, San Diego (SDSC and CERFNet), and SesquiNet. These are in addition to the other midlevel & regional networks that have previously been cut over to use the T3 system. We are coordinating with several other midlevel networks that we plan to cutover to T3 during the month of March. The midlevel networks continue to peer with both the T1 and T3 networks, and continue to use the T1 backbone to communicate with sites that have not yet cut over to the T3 backbone. This minimizes the load on the T1/T3 interconnect gateways in Ann Arbor, Houston, and San Diego. The interconnect gateway load has decreased as we have added load to the T3 system. We are also in the process of installing a 4th interconnect gateway at Princeton. T3 Network Status ================= Performance on the T3 network has been very good. There have been reports of intermittent packet loss, but this has been isolated to sources outside of the T3/T1 systems. As we migrate additional traffic onto the T3 network we are collecting daily reports on peak traffic load, and any packet discards on all CNSS/ENSS nodes in order to detect any problems caused by the added load. We are now measuring daily average sustained loads of about 5Mbps across a typical CNSS node (all interfaces) with an average packet size of about 200 bytes. The T3 backbone continues to be very reliable. There was a hardware problem on the backbone CNSS machine at Cleveland that resulted in two outages. We also continue to experience an occasional black link on CNSS-CNSS links. With the redundancy in the T3 network, none of these problems resulted in extended outages for any end users. There was also a routing software problem with the flooding of external BGP updates between the IBM and Cisco routers which we have worked around, and an SNMP monitoring problem which was identified and corrected. T1 Network Status Summary ========================= Performance and reliability on the T1 backbone has not been as good as T3 during February, but this is improving as we have (1) cut significant traffic over to the T3 system (2) are fixing several chronic problems that have been isolated and focused on during the last month. Some of these chronic problems and fixes include: - Congestion at NSS10 has been minimized by cutover of PSI/NyserNet traffic to the T3 system. We also replaced the PSP- 10-16 node to ensure that we were not having any intermittent hardware problems. - We recorded an above average number of T1 circuit outages reported during February. The increase in outages was largely due to two unrelated fiber cuts in the MCI network during the week of 2/17. - The "DCD Waffle" problem reported previously has been further diagnosed as two separate problems, and software corrections to these problems have already been partially deployed with the remaining software updates being tested on the research network for deployment during the coming week. A detailed description of these problems will be documented in the February Internet Monthly report. - An intermittent PSP crash problem is still being investigated. We suspect that this involves an RT kernel bug in the virtual memory system. - The fix to the "internally generated" ICMP net unreachable message problem has been successfully tested on the research network and will be deployed on the production network during the coming week. This should serve to minimize host problems resulting from any routing instabilities in the T1 network. - A new interior routing problem was identified where IS-IS link state PDUs were being truncated at sites where the regional was announcing over 2000 networks to the T1 backbone. A patch to the routing software to allow up to 2200 networks announced to a single NSS was already deployed as a near term fix. A new routing daemon that compresses the encoding of networks in the IS-IS link state packet is now being tested for deployment as a longer term solution. - - - - - - - - - - - - - - - - -