- Test - lists.nanog.org

CERT Advisory - Michelangelo PC Virus Warning
by CERT Advisory 06 Feb '92

06 Feb '92

=========================================================================== 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(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

The CIX and the NSFNET regionals - a dilemma
by Vince Fuller 05 Feb '92

05 Feb '92

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.

3 2

The CIX and the NSFNET regionals - a dilemma
by brian＠lloyd.com 05 Feb '92

05 Feb '92

> From: Martin Lee Schoffstall <schoff(a)psi.com> > 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(a)lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392

2 1

Re: The CIX and the NSFNET regionals - a dilemma
by Martin Lee Schoffstall 05 Feb '92

05 Feb '92

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 <schoff(a)psi.com> > 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

1 0

Re: The CIX and the NSFNET regionals - a dilemma
by Joe Ragland 05 Feb '92

05 Feb '92

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

3 2

Re: The CIX and the NSFNET regionals - a dilemma
by John Curran 05 Feb '92

05 Feb '92

-------- 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 <jcurran(a)nic.near.net> 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

1 0

Re: The CIX and the NSFNET regionals - a dilemma
by Joe Ragland 05 Feb '92

05 Feb '92

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

1 0

Re: The CIX and the NSFNET regionals - a dilemma
by Dennis Ferguson 05 Feb '92

05 Feb '92

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

1 0

Additions to the NSFNET policy-based routing database
by Belinda Sue Blair 04 Feb '92

04 Feb '92

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(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. ************** -B. Sue Blair Merit Network Operations

1 0

CERFnet Weekly Report for the week of Monday, January 27, 1992.
by Donna Bigley 03 Feb '92

03 Feb '92

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

1 0