- NANOG - lists.nanog.org

Re: ANS to CIX Interconnection
by rrv＠cody.cso.uiuc.edu 02 Oct '92

02 Oct '92

It seems to me that something is missing here. Perhaps I missed it, but I don't think I've seen anything about what CO+RE will be announcing to the CIX. I seem to recall a statement that the CIX does not use default, but that's it. What does ANS CO+RE plan on announcing to the CIX? Ross

1 0

ANS-CIX Interconnection
by Jordan Becker 02 Oct '92

02 Oct '92

> From: bjp(a)sura.net > Subject: Re: ANS to CIX Interconnection > Cc: regional-techs(a)merit.edu > Date: Wed, 30 Sep 1992 20:52:58 GMT > To: mak(a)merit.edu > > Can you tell me why you aren't keeping complete information in the > CNSSs instead of the ENSSs? Both ENSSs and CNSSs normally have complete routing information. The ENSSs will selectively announce commercial destination networks only to the participating service providers. It is possible for an ENSS to have partial routing information. However, one problem with this is that multiple regionals peer with the same ENSS at several locations. If an ENSS had partial information to administer some restriction policy, this would affect all regionals that peer with that ENSS. That might adversely affect those regionals that wish to receive the additional routes, and would certainly result in more work to maintain the policy routing database, and routing software, not to mention the management of consensus between each regional that shares an ENSS. There are ways for a regional to block this traffic, even if they continue to use default routes (e.g. create a static route for the commercial destinations to "black hole" the traffic). However it does require some effort by the regional as several people have correctly pointed out. > I can't see the problem you are solving by > engaging in this activity. The basic problem is to give remote CIX members (e.g. some regionals) access to the CIX using the ANSNET as transit. Jordan

1 0

Re: ANS to CIX Interconnection
by Vince Fuller 01 Oct '92

01 Oct '92

While this might be possible this scheme would cause some administrative problems. Currently the backbone ENSS's and CNSS's carry full external routes in their tables, with each ENSS having an IBGP session with all other nodes. I think a better long term solution would be to try to move away from using default and on to full routing information exchange at AS borders (using aggregation of course). An example of the kind of problem we would run into using the ENSS-filtering approach is that all peers of that ENSS would have to use the same policy. Why not split the ENSS's out of the IBGP "cloud" and use external-BGP between the ENSS's and CNSS's? This would likely require that an addition AS number and non-140.222 network be assigned to each ENSS, but it seems to fit more logically into the CNSS/ENSS architecture. It would also greatly reduce the number of IBGP sessions inside the T3 backbone. Comments? --Vince

1 0

Soviet Network
by Jordan Becker 01 Oct '92

01 Oct '92

> From: Rick Adams > > So, to sum up, ANS is discriminating against users of a network > because of their natural origin and there is no basis in law to > support this position. Pretty xenophobic for a group that claims to be > an international provider. As a matter of business policy, we attempt to ascertain the country of origin for any network announced over the ANSNET backbone. We already know that it is illegal (according to Dept. of Treasury and Commerce) for us to exchange traffic with certain countries under any circumstances (e.g. Irag), and only when granted a special license for other countries (e.g. Libya, North Korea, Cuba, Vietnam, and Cambodia). CIX assumes no liability or responsibility for the networks they announce to ANSNET. We do not get up-to-date information on the nets announced by the CIX including the country of origin other than by inspecting dumps of the CIX router tables. We only recently became aware of the former Soviet Union network announcement from the CIX routing table dump. Until recently, the Soviet Union was on one of the dept. of Commerce restriction lists. While we have recieved some preliminary advise that carrying transit traffic to/from the former Soviet Union is ok, we are still awaiting verification through independent counsel that there are no other legal liabilities. We expect a positive reply to this shortly (perhaps by the the actual config. run). We do not view this as a matter of paranoia (although others may), and this has nothing to do with NSF, other than they have asked us not to announce this net to the federal agency networks. We view this verification simply as prudent business practice. Jordan

1 0

Re: ANS to CIX Interconnection
by skw 01 Oct '92

01 Oct '92

>Mark, the main problem for us is if you don't filter out the 97 some odd >nets out of the AS 1957 routes you send us. If you are willing to do >that, then we still don't have any new administrative load, and from NSI's >point of view, we're happy. Did I read your statement right? If so, we'd >definitely like to take you up on this offer! > Milo, The current plan is to NOT explicitly announce AS 1957 routes to anyone except a subset of ANS CO+RE/CIX members. We also agreed not to announce the CIX nets to the T1 via the T1-T3 interconnect, to avoid having the routes leak into sites via the interconnect. So, sites like NSI that don't do default routing will not suffer an increased administrative burden in any way. --Steve W.

2 1

Re: ANS to CIX Interconnection
by Curtis Villamizar 01 Oct '92

01 Oct '92

> So what you're saying then is that you are not an independant entity and > are require to follow federal policy. > > NSF has a policy against it. that has nothing to do with legality. > > NSF also has a policy against carrying commercial traffic? Did you > adopt that? > > You are not being conservative. You're way into paranoid. > > So, to sum up, ANS is discriminating against users of a network because of > their natural origin and there is no basis in law to support this > position. Pretty xenophobic for a group that claims to be an international > provider. > > Now I've seen everything. Gordan Cook forging mail as Rick Adams. ;-) As I understand it this represents a compromise between the policy that the regionals and other direct attachments are required to enforce their applicable APU in whatever way they see fit (which in some cases is to do nothing more than issue a statment to users that outlines the AUP), and the strong sentiment among government agencies and the NSF not to have the xSU net announced until they are prepared to deal with it more thoroughly than plain vanilla commercial traffic. Whether this has basis in NSF policy or law is not something that Mark (or I) really cares that much about (unless it does turn out to be based on law and we get into big trouble). I'm not sure if this is even permanent, but I suspect (speculation alert!!!) that once there is a technical solution that prevents routing between the feds doing there state of the art FIX default route thing (and anyone else that doesn't want to talk to them), and the other major international providers doing their default route thing, we might just pipe the xSU net in and let them do business in the US and talk to US R&Es that are willing to talk to them. Until then we will be exersizing prejudice against the xSU. What are we talking about here folks - one class C net? If you need access to that net right now, join the CIX - 'cause ye can't get thar frm here. Curtis <<<INSERT BIG DISCLAIMER HERE - I don't speak for ANS>>>

2 1

Re: ANS to CIX Interconnection
by rick＠uunet.uu.net 01 Oct '92

01 Oct '92

> One of the new networks originates in the former Soviet Union, > and traffic between US Government sponsored networks and the former > Soviet Union is prohibited at this time. Therefore accordingly, the > ANSNET will not re-distribute or announce any routes to this network. Well, the obvious question is what does this have to do with anything? The whole point of the CIX is to not have to screw around with outdated government policy. So, either ANS CO+RE isn't REALLY the commericial separate entity it claims to be or the above statement makes no sense and should be retracted. Which is it? ---rick

2 4

Re: ANS to CIX Interconnection
by bjp＠sura.net 30 Sep '92

30 Sep '92

>>Is there a reason why complete information is in the ENSS rather than the >> CNSS? >> My understanding of the agreement is that it is for the benefit of ANSnet >> and the CIX, so why should the regionals have to adjust the way they are set >> up? I'm not just saying this to be contrary (Honest). I am really >> interested in knowing why this method was chosen. As others have pointed >> out it move the burden of enforcing policy restriction to individual >> AS pairs. Comments? > > Brad, > You are correct that our interpretation of the AUP situation is that > the burden is on the regionals/midlevels to enforce the policies as > they apply to their institutions. This can be done by simply issuing > a public statement to all users that people should only use the > NSFNET for purposes of research and education. Or it can be done > a bit more drastically by filtering out routes. The actual > implementation of filters needs to be done in the regional's > peer router when default routing is used. > Does this help? It does provide something of a clarification BUT I still have many questions. Does this mean that NSFnet will now take NACRs for any network and we no longer need to claim that people will abide by the AUP? This seems to me to be a radical change in policy. What is the reason for this shift? If people are still bound by the AUP and regionals can not submit NACRs for non AUP sites than it appears to me that we now have two classes of citizens on the Net. Those that can transmit any kind of packet and make the rest of the people bear the burden of preventing traffic we don't want and those of us who can't :-( I can understand that Merit does not want to enforce specific regional access policys *but* the regionals have been able to count on getting traffic that fits a specific AUP requirement from the NSFnet. This is no longer true. Can you tell me how this change benefits the regionals or even NSFnet? Can you tell me why you aren't keeping complete information in the CNSSs instead of the ENSSs? I can't see the problem you are solving by engaging in this activity. Brad Passwaters (301)(982-3214) SURAnet Operations bjp(a)sura.net <My name, My opinions>

1 0

ANS to CIX Interconnection
by mak 30 Sep '92

30 Sep '92

To: Regional, Midlevel and Federal Network Operators From: Mark Knopper Merit/NSFNET Internet Engineering Subject: ANS to CIX Interconnection Plan Hi. Enclosed is a note from ANS describing their plan for the CIX to ANS network interconnection. Please let me know if you have questions or comments. Mark --------Forwarded Message To: Mark Knopper <mak(a)merit.edu> From: Jordan Becker <becker(a)ans.net> Subject: ANS-CIX Interconnection Plan Mark, Here is a description of the routing and configuration plan for the CIX to ANS connection. Please forward this to regionals, midlevels, etc. as appropriate. Jordan ----------------------------------- During an upcoming T3 network router configuration update window, there will be about 94 new networks configured in the policy routing database to support the interconnection between ANS CO+RE and the CIX. A new ANSNET router, ENSS187 has been connected via a T1 link to the CIX router. This new ENSS (AS1957) peers via BGP with the CIX router (AS1280). Ethernet ------- T1 ------------ | --------| | cix |----------------| enss187 |-----| | | | ags+ | | | |-----| Cnss11| ------- ------------ | | | | |-------- 1280 BGP 1957 BGP 690 There will be initially 987 networks announced to the T3 system via the CIX (AS1280). Most of these networks have previously been configured in the policy routing database and are already announced to the NSFNET backbone service at other T3 ENSS nodes. About 94 of these networks are not already announced to the T3 system via other ENSS nodes and will be announced via AS1280 for the first time. All CIX networks announced via AS1280 will be considered as ANS CO+RE services (commercial restriction free). An ASCII text file listing of all ANS CO+RE announced network numbers, network names, AS numbers and available service provider information is maintained by ANS and may be retrieved via anonymous ftp from FTP.ANS.NET as /pub/info/co+re/core.nets or NIS.NSF.NET as /nsfnet/core.nets. Updates to this file will be made a few days prior to any configuration updates for the T3 backbone that involve the CIX (AS1280). One of the new networks originates in the former Soviet Union, and traffic between US Government sponsored networks and the former Soviet Union is prohibited at this time. Therefore accordingly, the ANSNET will not re-distribute or announce any routes to this network. Note that the 94 new networks will potentially be generating traffic which does not comply with the NSFNET Acceptable Use Policy. The new network numbers will be announced by the ANSNET to the peer networks that are both ANS CO+RE and CIX members. Those regionals or midlevels who are using default routing to point their traffic to the NSFNET backbone may wish to explicitly prohibit traffic between their users and these new networks if their internal policies require it. This may be done by either internal means (eg. informing users), or by filtering in routers operated by the midlevel network. Regionals may contact Merit to discuss other options for blocking this traffic if required.

2 1

CERFnet Weekly Report for the week of Monday, Sept. 21, 1992.
by Donna Bigley 29 Sep '92

29 Sep '92

############################################################################### This is the CERFnet weekly activity report for the period of Monday, September 21st through Sunday, September 27th, 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: 27-sept-92.txt All times are in Pacific Daylight 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: TICKET #: 1301 SITE: CICESE SITES AFFECTED: CICESE TIME STARTED: FRI. 09-11-92 11:28 TIME ENDED: THU. 09-17-92 13:39 TIME STARTED: THU. 09-17-92 18:07 (Intermittent Access) TIME ENDED: WED. 09-23-92 21:34 (SAT NET reinstalled modem) TIME ELAPSED: 12 days 5 hours 38 min. REASON: Unscheduled Outage/Link Failure TICKET #: 1330 SITE: UCI-CIT T3 SITES AFFECTED: UCI-CIT T3 TIME STARTED: SAT. 09-19-92 07:03 TIME ENDED: THU. 09-24-92 15:52 TIME ELAPSED: 5 days 8 hours 49 min. REASON: Link Failure (CALTECH side of the circuit) TICKET #: 1339 SITE: MARKV SITES AFFECTED: MARKV TIME STARTED: TUE. 09-22-92 11:11 TIME ENDED: THU. 09-24-92 10:38 TIME ELAPSED: 1 day 23 hours 27 min. REASON: Equipment Trouble TICKET #: 1341 SITE: COAST COMMUNITY COLLEGE DISTRICT SITES AFFECTED: COAST COMMUNITY COLLEGE DISTRICT TIME STARTED: WED. 09-23-92 05:30 TIME ENDED: WED. 09-23-92 06:32 TIME ELAPSED: 1 hour 2 min. REASON: Unknown TICKET #: 1342 SITE: REDE RIO/BRAZIL SITES AFFECTED: REDE RIO/BRAZIL TIME STARTED: WED. 09-23-92 16:17 TIME ENDED: WED. 09-23-92 17:42 TIME ELAPSED: 1 hour 25 min. (MCI Link Failure between Lodi and N.Y.) REASON: Link Failure TICKET #: 1300 SITE: CALTECH SITES AFFECTED: CALTECH DIAL N' CERF, CALTECH NetBlazer, AJA, COH, OXY, DISNEY, CLAREMONT, CADAM, SCAQMD, and HUGHES-CIT. TIME STARTED: THU. 09-24-92 10:25 TIME ENDED: THU. 09-24-92 10:40 TIME ELAPSED: 15 min. (New Router Installed) REASON: CERFnet Scheduled Maintenance TICKET #: 1339 SITE: MARKV SITES AFFECTED: MARKV TIME STARTED: THU. 09-24-92 16:33 TIME ENDED: FRI. 09-25-92 10:19 TIME STARTED: FRI. 09-25-92 13:24 TIME ENDED: FRI. 09-25-92 13:57 TIME STARTED: SAT. 09-26-92 16:58 TIME ENDED: SUN. 09-27-92 17:22 TIME ELAPSED: 1 day 18 hours 43 min. REASON: Site Scheduled Maintenance TICKET #: 1343 SITE: SERI/KOREA SITES AFFECTED: SERI/KOREA TIME STARTED: THU. 09-24-92 17:41 TIME ENDED: THU. 09-24-92 17:58 TIME ELAPSED: 17 min. (Worldcom Unknown) REASON: Unknown (Cisco Box didn't restart) TICKET #: 1345 SITE: HUGHES SITES AFFECTED: HUGHES TIME STARTED: THU. 09-24-92 19:21 TIME ENDED: FRI. 09-25-92 10:42 TIME ELAPSED: 15 hours 21 min. REASON: Site Activity (UCI Side) TICKET #: 1344 SITE: CERFnet SITES AFFECTED: ALL CERFnet Backbones, Sites, and peering with CIX, ESNET, and CSUnet. TIME STARTED: THU. 09-24-92 21:20 TIME ENDED: THU. 09-24-92 23:26 TIME ELAPSED: 2 hours 6 min. (MCI outage in San Diego) REASON: Link Failure TICKET #: 1340 SITE: IRVINE COMPILER CORPORATION SITES AFFECTED: IRVINE COMPILER CORPORATION TIME STARTED: FRI. 09-25-92 04:55 TIME ENDED: FRI. 09-25-92 11:00 TIME ELAPSED: 6 hours 5 min. REASON: Equipment Trouble TICKET #: 1347 SITE: McDonnell Douglas SITES AFFECTED: McDonnell Douglas TIME STARTED: FRI. 09-25-92 10:40 TIME ENDED: FRI. 09-25-92 14:49 TIME ELAPSED: 4 hours 9 min. REASON: Site Activity (Loopback Set) TICKET #: 1319 SITE: UCOP SITES AFFECTED: UCOP DIAL N' CERF, UCOP NETBLAZER, CIX, NETLABS, LSIL, INTEL, CISCO, APPLE AND FARALLON. TIME STARTED: FRI. 09-25-92 14:00 TIME ENDED: FRI. 09-25-92 14:08 TIME ELAPSED: 8 min. (Router Upgrade) REASON: CERFnet Scheduled Maintenance TICKET #: 1351 SITE: CALTECH-SDSC T1 SITES AFFECTED: CALTECH-SDSC T1 TIME STARTED: SAT. 09-26-92 09:17 TIME ENDED: SAT. 09-26-92 09:23 TIME ELAPSED: 6 min. (CERFnet) REASON: Site Activity TICKET #: 1352 SITE: REDE RIO/BRAZIL SITES AFFECTED: REDE RIO/BRAZIL TIME STARTED: SAT. 09-26-92 13:09 TIME ENDED: MON. 09-28-92 05:06 TIME ELAPSED: 1 day 15 hours 57 min. REASON: Ticket Still Open ------------------------------------------------------------------------ CERFNET TRAFFIC CAPACITY USAGE AT EACH CIRCUIT LINK LINK SPEED CAPACITY PEAK HOUR (PDT) UCI/CALTECH 45.000 mbps 00.1% 16:00 SDSC/GA 10.000 mbps 00.1% 02:00 SDSC/CALTECH 1.544 mbps 16.0% 16:00 SDSC/UCI 1.544 mbps 06.8% 16:00 SDSC/UCLA 1.544 mbps 12.9% 16:00 SDSC/UCOP 1.544 mbps 06.1% 16:00 UCI/UCLA 1.544 mbps 01.8% 16:00 SDSC/UCR 512 kbps 03.1% 07:00 UCLA/UCSB 512 kbps 16.3% 16:00 CALTECH/HUGHES 1.544 mbps 02.0% 10:00 SDSC/AGI 1.544 mbps 00.2% 17:00 SDSC/BIOSYM 1.544 mbps 00.3% 14:00 SDSC/GD 1.544 mbps 02.1% 09:00 SDSC/SAIC 1.544 mbps 01.4% 16:00 SDSC/SEASPACE 1.544 mbps 03.1% 16:00 UCI/CSU CO(SWRL) 1.544 mbps 04.5% 16:00 UCI/MDC 1.544 mbps 02.0% 15:00 UCLA/GETTY 1.544 mbps 00.1% 16:00 UCOP/APPLE 1.544 mbps 01.2% 10:00 UCOP/CISCO 1.544 mbps 00.2% 19:00 UCR/LLUMC 1.544 mbps 00.5% 07:00 CALTECH/AJS 56 kbps 02.0% 13:00 CALTECH/CADAM 56 kbps 01.4% 09:00 CALTECH/CITY OF HOPE 56 kbps 01.0% 09:00 CALTECH/CLAREMONT 56 kbps 28.4% 16:00 CALTECH/DISNEY 56 kbps 08.1% 15:00 CALTECH/OXY 56 kbps 09.3% 13:00 CALTECH/SCAQMD 56 kbps 00.7% 16:00 SDSC/API 56 kbps 07.1% 20:00 SDSC/CICESE 56 kbps 05.1% 14:00 SDSC/KOREA 56 kbps 14.8% 21:00 SDSC/QUALCOMM 56 kbps 13.8% 22:00 SDSC/REDE-RIO 56 kbps 07.9% 10:00 SDSC/SCIH 56 kbps 03.9% 10:00 SDSC/SDG&E 56 kbps 04.1% 21:00 SDSC/USD 56 kbps 06.9% 09:00 SDSC/USIU 56 kbps 03.4% 20:00 UCI/BECKMAN 56 kbps 06.4% 16:00 UCI/CCCD 56 kbps 06.2% 13:00 UCI/CMD 56 kbps 00.8% 16:00 UCI/EMULEX 56 kbps 02.5% 16:00 UCI/FULLERTON 56 kbps 11.2% 23:00 UCI/HUGHES 56 kbps 23.2% 16:00 UCI/ICC 56 kbps 05.9% 21:00 UCI/MTI 56 kbps 05.3% 06:00 UCI/SPARTA 56 kbps 09.3% 06:00 UCI/UNOCAL 56 kbps 12.2% 16:00 UCLA/CRSS 56 kbps 00.3% 16:00 UCLA/DATAPRODUCTS 56 kbps 01.4% 13:00 UCLA/GTE 56 kbps 06.2% 16:00 UCLA/ISX 56 kbps 03.7% 17:00 UCLA/LITTON 56 kbps 00.3% 10:00 UCLA/PEPPERDINE 56 kbps 01.8% 12:00 UCLA/QUOTRON 56 kbps 87.5% 23:00 UCLA/SMC 56 kbps 02.3% 14:00 UCOP/FARALLON 56 kbps 08.8% 16:00 UCOP/INTEL 56 kbps 28.2% 10:00 UCOP/LSIL 56 kbps 08.8% 16:00 UCOP/NETLABS 56 kbps 12.9% 19:00 ------------------------------------------------------------------------------ SITE CISCO BOX UPTIME SINCE LAST REBOOT (as of 00:15 PDT on Sept. 28, 1992): CERFnet BACKBONE CALTECH [131.215.139.253] Up: 03 days 12 hours 32 minutes [CERFnet Scheduled Maintenance- See Ticket #1300] SDSC LongBoard [134.24.99.254] Up: 104 days 08 hours 21 minutes SDSC Drzog [132.249.16.13] Up: 137 days 14 hours 24 minutes SDSC Hang10 [132.249.16.15] Up: 137 days 14 hours 24 minutes UCI [128.200.1.101] Up: 03 days 07 hours 47 minutes [CERFnet Site Activity] UCLA [128.97.130.10] Up: 175 days 06 hours 28 minutes UCOP [134.24.52.112] Up: 02 days 10 hours 08 minutes [CERFnet Scheduled Maintenance- See Ticket #1319] UCR [134.24.108.105] Up: 78 days 12 hours 36 minutes CERF 1544 AGI [134.24.202.110] Up: 78 days 09 hours 43 minutes APPLE [134.24.70.200] Up: 08 days 11 hours 19 minutes BIOSYM [134.24.57.200] Up: 108 days 07 hours 13 minutes CISCO Systems [134.24.54.200] Up: 17 days 11 hours 26 minutes CSUCO/SWRL [130.150.102.200] Up: 58 days 18 hours 22 minutes GA [134.24.20.10] Up: 07 days 00 hours 12 minutes GD [134.24.60.200] Up: 150 days 16 hours 18 minutes GETTY [134.24.235.200] Up: 45 days 07 hours 02 minutes HUGHES_CIT [134.24.103.200] Up: 07 days 11 hours 11 minutes LLUMC [134.24.208.200] Up: 57 days 13 hours 45 minutes MDC [134.24.65.200] Up: 37 days 08 hours 00 minutes SAIC [134.24.53.208] Up: 137 days 14 hours 10 minutes UCSB [134.24.107.107] Up: 03 days 10 hours 33 minutes [Unknown] CERF 56 AJS [134.24.225.101] Up: 47 days 13 hours 24 minutes API [134.24.224.200] Up: 94 days 13 hours 18 minutes BECKMAN [134.24.237.200] Up: 117 days 12 hours 10 minutes CADAM [134.24.229.200] Up: 30 days 06 hours 23 minutes CCCD [134.24.219.200] Up: 91 days 19 hours 14 minutes CICESE [134.24.227.200] Up: 131 days 09 hours 43 minutes CITY_OF_HOPE [134.24.233.200] Up: 00 days 16 hours 38 minutes [Equipment Trouble] CLAREMONT [134.24.206.109] Up: 05 days 07 hours 31 minutes [Power Outage] CMD [134.24.218.200] Up: 23 days 07 hours 29 minutes CRSS [134.24.232.200] Up: 53 days 12 hours 16 minutes DATAPRODUCTS [134.24.211.200] Up: 180 days 13 hours 01 minutes DISNEY [134.24.207.211] Up: 41 days 19 hours 57 minutes EMULEX [134.24.209.212] Up: 29 days 07 hours 37 minutes FARALLON [134.24.56.200] Up: 55 days 15 hours 51 minutes FULLERTON [134.24.214.217] Up: 91 days 17 hours 55 minutes GTE [134.24.212.200] Up: 196 days 16 hours 57 minutes HUGHES [134.24.204.200] Up: 02 days 13 hours 34 minutes [Site Acitivty - See Ticket #1345] INTEL [134.24.73.200] Up: 183 days 11 hours 34 minutes ICC [134.24.238.200] Up: 03 days 13 hours 15 minutes [Equipment Trouble - See Ticket #1340] LITTON [134.24.213.200] Up: 37 days 13 hours 29 minutes LSIL [134.24.72.200] Up: 145 days 08 hours 26 minutes MTI [134.24.216.100] Up: 33 days 08 hours 48 minutes NETLABS [134.24.71.200] Up: 60 days 09 hours 33 minutes OXY [134.24.205.108] Up: 03 days 12 hours 16 minutes [Unknown] PEPPERDINE [134.24.203.218] Up: 170 days 21 hours 42 minutes QUALCOMM [134.24.200.201] Up: 14 days 00 hours 14 minutes QUOTRON [134.24.230.202] Up: 35 days 06 hours 06 minutes REDE_RIO [134.24.112.200] Up: Still Down at the time. [Ticket Still Open - See Ticket #1352] SANTA MONICA [134.24.210.219] Up: 60 days 13 hours 40 minutes SCAQMD [134.24.234.200] Up: 05 days 07 hours 55 minutes [Equipment Trouble] SCI-HOR [134.24.109.205] Up: 138 days 06 hours 02 minutes SDG&E [134.24.226.200] Up: 117 days 13 hours 39 minutes SEASPACE [134.24.80.200] Up: 172 days 11 hours 26 minutes SERI/KOREA [134.24.223.200] Up: 16 days 05 hours 58 minutes SPARTA [134.24.215.200] Up: 181 days 10 hours 57 minutes UNOCAL [134.24.217.200] Up: 206 days 01 hours 57 minutes USD [134.24.201.106] Up: 48 days 17 hours 00 minutes USIU [134.24.222.215] Up: 449 days 17 hours 07 minutes DIAL n' CERF Plus 14.4 CITOH [161.1.1.1] Up: 07 days 10 hours 09 minutes MARKV [192.122.251.6] Up: 00 days 14 hours 00 minutes [Site Scheduled Maintenance - See ticket #1339] PEREGRINE [192.72.253.97] Up: 12 days 13 hours 51 minutes DIAL n' CERF DNC-SDSC [134.24.1.2] Up: 06 days 04 hours 58 minutes [Unknown] DNC-UCI [134.24.2.2] Up: 08 days 17 hours 12 minutes DNC-UCLA [134.24.3.2] Up: 04 days 12 hours 09 minutes [Equipment Trouble] DNC-CALTECH [134.24.4.2] Up: 03 days 13 hours 36 minutes [CERFnet Scheduled Maintenance- See Ticket #1300] DNC-UCOP [134.24.5.2] Up: 90 days 04 hours 29 minutes CIT-NETBLAZER [130.152.104.1] Up: 03 days 08 hours 35 minutes [CERFnet Scheduled Maintenance- See Ticket #1300] SDSC-NETBLAZER [192.102.249.25] Up: 03 days 04 hours 39 minutes [Unknown] UCI-NETBLAZER [134.24.92.2] Up: 08 days 17 hours 12 minutes UCLA-NETBLAZER [134.24.93.2] Up: 39 days 06 hours 54 minutes UCOP-NETBLAZER [134.24.250.2] Up: 187 days 23 hours 54 minutes

1 0