- Test - lists.nanog.org

CSU/DSU selection
by Vince Fuller 20 Feb '92

20 Feb '92

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(a)stanford.edu - I'll summarize if there is interest. --Vince

1 0

OSI Survey for Regionals attached to the Internet
by skh 19 Feb '92

19 Feb '92

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(a)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?

1 0

Re: The CIX and the NSFNET regionals - a dilemma
by Allen Cole 19 Feb '92

19 Feb '92

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(a)cc.utah.edu

1 0

Additions to the NSFNET policy-based routing database
by Steven K. Widmayer 18 Feb '92

18 Feb '92

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(a)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

1 0

CERT Advisory - Internet Intruder Activity
by CERT Advisory 17 Feb '92

17 Feb '92

=========================================================================== 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(a)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).

1 0

CERFnet Weekly Report for the week of Monday, February 10, 1992.
by Donna Bigley 17 Feb '92

17 Feb '92

############################################################################### 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(a)cerf.net or help(a)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

1 0

[Merit Network Operations Center: 02/14/92 NSS 8 Princeton Unreachable 20:26 - ? EDT]
by skennedy＠BBN.COM 15 Feb '92

15 Feb '92

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: <noc(a)merit.edu> 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 <noc(a)merit.edu> Message-Id: <9202150149.AA06453(a)merit.edu> To: nsr(a)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

1 0

Additions to the NSFNET policy-based routing database
by Steven K. Widmayer 14 Feb '92

14 Feb '92

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(a)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

1 0

T3 backbone stability
by Mark Knopper 13 Feb '92

13 Feb '92

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(a)merit.edu From: oleary(a)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

1 0

T3 backbone stability
by oleary＠sura.net 12 Feb '92

12 Feb '92

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

1 0