- Test - lists.nanog.org

NOC Phone Number Time (Re: Microsoft NOC?)
by Sean Donelan 09 May '98

09 May '98

>The reason it is imperative that there be a telephone number for an >ISP is that it's really hard to use e-mail to contact an ISP if the >network connectivity to the ISP is not working. I guess its that time again. Between May 11 and May 15 I will be conducting my Emergency NOC Phone Test. This is an unannounced test where I call each of the phone numbers given to me by providers I interconnect with. The rules are listed on <http://dranet.dra.com/verify-contact.html>. Although I say its 'unannounced' if you want to tell your NOC folks I'll be calling next week go ahead. In practice I've found corporate culture tends to overwhelm any special advance notice. In case you are interested, the very best performance in the last emergency NOC phone contact test was by the Defense Communications Agency/DISA NOC. They earned four stars, out of five, losing only one point because the operator did not know how to call their NOC from outside the US. 1-800 numbers are difficult to dial outside the US. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Microsoft NOC?
by Kit Knox 08 May '98

08 May '98

425-882-8080 as listed by whois for Microsoft is not their NOC. When you call this number you are told that they will only transfer by a persons name or extension and offer no other assitance. If anyone has any other contact information it would be appreciated. -- Kit Knox [kit(a)connectnet.com] - CONNECTnet INS, Inc.

5 4

Re (2): Core router bakeoff?
by jkucic＠kpmg.com 08 May '98

08 May '98

Hi, Richard Welty <rwelty(a)neworks.net>,Internet writes: >it was the 4700, and it is my understanding that the agreement between >cabletron and cisco fell through, so the 4700 blades are all sitting >around, and cabletron can't legally sell them. Yeah, they have them in Rochester, NH and use them internally on developmental projects. Thanks, Joe Kucic

1 0

Mail loop?
by Eric Germann 08 May '98

08 May '98

Majordomo take a dump here. Seem to be looping messages on NANOG... Eric

3 2

RE: CiscoSecure NT vs CS UNIX
by Eric Germann 08 May '98

08 May '98

Err, buy decent hardware and it will. 400,000 hits per day. Six months with narry a hiccup. PPro 200 with 128MB RAM. Also, if you're looking for a Radius solution to interface with a real relational db, NT works out a LOT cheaper than Sybase or Oracle on Unix. Eric At 08:06 AM 5/8/98 -0400, jeyers(a)ialn.com wrote: >Depends on the size of your network. "Scaleability and stability" and >NT rarely go together... > >Jerry > >> -----Original Message----- >> From: Martin, Christian [SMTP:CMartin@mercury.balink.com] >> Sent: Thursday, May 07, 1998 8:48 PM >> To: 'nanog(a)merit.edu' >> Subject: CiscoSecure NT vs CS UNIX >> >> All Ye NANOG readers, >> >> Does anyone use CiscoSecure ACS for NT to control router access? If >> so, >> has anyone used the UNIX one and done a comparison? I need to >> evaluate >> these tools as a replacement for the TACACS+ daemon available from >> Cisco. Any info would be appreciated, particularly scalability and >> stability. >> >> Regards, >> Christian >

2 1

Re: Core router bakeoff?
by Blake Willis 08 May '98

08 May '98

Except this one has two full T1s on it, and we have added and removed routes and customers from it more than a few times since its last reboot. I believe it was rebooted 269 days ago because we turned on OSPF, which requires a systems reset. -Blake --------------------------------------------------------------------------- Blake Willis 703-448-4470x483 Network Engineer, New Customers blakew(a)cais.net CAIS Internet, a CGX Communications Company --------------------------------------------------------------------------- On Fri, 8 May 1998, Robert E. Seastrom wrote: > > heh, if i had a dyingston at my place, it could reasonably be expected > to stay up forever. completely idle machines which nobody ever > touches have a way of doing that... > > Command> ver > Livingston PortMaster IRX ComOS 3.5R > System uptime is 269 days 20 hours 2 minutes > > No comment. > >

1 0

The Cidr Report
by Tony Bates 08 May '98

08 May '98

This is an auto-generated mail on Fri May 8 12:00:00 PDT 1998 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 08May98 0) General Status Table History ------------- Date Prefixes 010598 51507 020598 51483 030598 51464 040598 51619 050598 51640 060598 51724 070598 51403 080598 51559 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 222.222.222.0 from AS701 AS Summary ---------- Number of ASes in routing system: 3529 Number of ASes announcing only one prefix: 1666 (868 cidr, 798 classful) Largest number of cidr routes: 378 announced by AS3561 Largest number of classful routes: 1105 announced by AS701 1) Gains by aggregating at the origin AS level --- 08May98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 611 376 235 38.5% iSTAR Internet, Inc. AS816 691 464 227 32.9% UUNET Canada (ASN-UUNETCA-AS4) AS4293 452 228 224 49.6% IMCI AS174 826 633 193 23.4% Performance Systems International AS701 1105 924 181 16.4% Alternet AS3602 482 309 173 35.9% Sprint Canada Inc. AS3749 207 65 142 68.6% TECNET AS8505 156 30 126 80.8% Middle East Technical University AS5668 116 46 70 60.3% Century Telephone Inc. AS2048 161 91 70 43.5% LaNet AS3221 110 41 69 62.7% EENet Autonomous System AS4755 94 27 67 71.3% Videsh Sanchar Nigam Ltd. India AS10928 108 42 66 61.1% UNKNOWN AS1221 310 247 63 20.3% AARNET-AS AS3804 200 142 58 29.0% Bell Solutions AS1239 554 499 55 9.9% SprintLink Backbone AS549 210 156 54 25.7% ONet Backbone AS7046 184 132 52 28.3% UUNET-CUSTOMER AS271 101 50 51 50.5% BCnet Backbone AS72 84 36 48 57.1% Schlumberger Information Network AS4763 123 76 47 38.2% Telstra New Zealand AS7545 101 60 41 40.6% TPG Internet Pty Ltd AS852 157 117 40 25.5% AGT Advance Communication AS684 94 55 39 41.5% Manitoba Regional Network Backbon AS4740 372 333 39 10.5% ASN-OZEMAIL (Ozemail Pty Ltd) AS762 118 80 38 32.2% WELLFLEET-AS AS4200 124 86 38 30.6% AGIS (Apex Global Information Ser AS3493 163 125 38 23.3% INTERLINK AS6392 69 32 37 53.6% MidWest Communications, Inc. AS6181 65 28 37 56.9% FUSE-NET For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Re: Core router bakeoff?
by James B. Slayden Jr. 08 May '98

08 May '98

Yep, That's about average for us to (see included SNMP gets): James S. Name: ACT Model: products.17 Why? power-on Uptime: 21 weeks, 1 days, 19 hours, 41 minutes Name: LNK Model: products.17 Why? power-on Uptime: 23 weeks, 5 days, 18 hours, 50 minutes Name: AGU Model: products.17 Why? reload Uptime: 41 weeks, 6 days, 12 hours, 36 minutes Name: CPI Model: products.17 Why? reload Uptime: 61 weeks, 0 days, 19 hours, 22 minutes (over a year!!) Just a sampling of our many tailsite routers (around 200 or so) ----------------------------------------------------------------------------- James B. Slayden Jr. Network Engineer/DNS Administrator slayden(a)nsipo.nasa.gov NASA Integrated Network Services (NISN) 650-604-6404 NASA Ames Research Center ----------------------------------------------------------------------------- > From owner-nanog(a)merit.edu Thu May 7 20:11:05 1998 > Date: Thu, 7 May 1998 21:30:21 -0500 > From: Karl Denninger <karl(a)mcs.net> > To: "Jason L. Weisberger" <jweis(a)softaware.com> > Cc: nanog(a)merit.edu > Subject: Re: Core router bakeoff? > Mime-Version: 1.0 > Content-Type> : > text/plain> ; > charset=us-ascii> > X-Mailer: Mutt 0.84 > Sender: owner-nanog(a)merit.edu > Content-Length: 2376 > > On Thu, May 07, 1998 at 06:45:46PM -0700, Jason L. Weisberger wrote: > > On Thu, 7 May 1998, Karl Denninger wrote: > > > > > Well, the GRF has its good and bad points. I've tested one rather > > > extensively, although I admit it was some time (~8-9 months) ago. > > > > I've been rather upset with Ascend over their lack of reaction to the bug > > in the Pipe 150 that had it publishing ARP statments for every ip address > > that went by its ethernet interface. Have you found their other products > > to be better supported and safer to fire and forget? > > > > jlw > > Well, I got rather, uh, pissed at the MAX 4000s desire to publish both a > /32 and a /29 route for all OSPF announcements on dial interfaces (which > went unaddressed in the code for literally months) - particularly troublesome > when you consider the limited RAM in those boxes (and the consequence of > running out of it - it would just drop the OSPF process entirely!), not > to mention a direct violation of the OSPF specifications and the cause of > many complaints from other equipment which this generated. > > I've heard they have cleaned up their software act in the last several > months; other than P130s as customer routers for DS1 users (of which we have > a boatload deployed) I have zero *current* operational experience with their > equipment, so my knowledge base on them is ~6-9 months old. > > Then again, I'm a SOB when it comes to standards complience, especially when > lack thereof breaks something that we *NEED* around here (such as reliable > service :-). > > I still don't like CISCO's RAS implementations, but I have to say this - > for all their warts, including some business policies that I consider > nothing short of INSANE, their router hardware and IOS still win the prize > for uptime in my experience. > > A real example from our core: > > XXXXXXX-CoreX uptime is 38 weeks, 1 day, 7 hours, 49 minutes > System restarted by power-on > > That's pretty typical around here; the last "power on" was to do routine > maintenance on that particular device. :-) > > -- > -- > Karl Denninger (karl(a)MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin > http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV > | NEW! Corporate ISDN Prices dropped by up to 50%! > Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS > Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost >

1 0

Re: Core router bakeoff?
by Paul Vixie 08 May '98

08 May '98

> > Yeah, but you'll have trouble getting decent T3 cards for it. Its true > > that 100Mbps ethernet should be fine. > > SDL makes decent (tho not perfect) T3 cards for PCs. So does <URL:http://www.lanmedia.com/products.htm>. > > BTW, NetBSD with the recent flow cache mods can handle at least > > 150,000 packets per second. We haven't seen what the actual upper > > limit is, but that number doesn't seem to be eating a lot of CPU. > > Interesting. Have you done any scalability testing? Per-flow state has > been shown to scale poorly in Internet backbones. That was with one flow. The idea of "there basically aren't flows" is not obvious on first approach to these problems, wouldn't you say, Tony :-)? -- Paul Vixie La Honda, CA <paul(a)vix.com> "Many NANOG members have been around pacbell!vixie!paul longer than most." --Jim Fleming

3 2

Re: Microsoft NOC?
by ""C. Philip Wood"" 08 May '98

08 May '98

Try the number at the end of this mess: traceroute to microsoft.com (207.46.130.139), 30 hops max, 40 byte packets 1 cdiv-gw.lanl.gov (128.165.114.241) 0.866 ms 0.794 ms 0.75 ms 2 cisco-fire1.lanl.gov (128.165.4.241) 1.791 ms 2.426 ms 1.725 ms 3 esnet-rt1.lanl.gov (192.16.1.241) 2.207 ms 1.487 ms 1.394 ms 4 ames-atms.es.net (134.55.24.19) 471.276 ms 369.954 ms 325.106 ms 5 san-jose3.ca.alter.net (198.32.136.42) 34.239 ms 33.689 ms 33.696 ms 6 118.ATM11-0-0.XR1.SJC1.ALTER.NET (146.188.144.138) 34.482 ms 34.527 ms 34.897 ms 7 193.ATM2-0.TR3.SCL1.ALTER.NET (146.188.147.202) 40.57 ms 37.708 ms 36.856 ms 8 177.ATM9-0-0.TR1.SEA1.ALTER.NET (146.188.138.22) 67.626 ms 66.954 ms 67.397 ms 9 100.ATM4-0-0.XR1.SEA1.ALTER.NET (146.188.200.97) 67.318 ms 67.659 ms 67.205 ms 10 195.ATM11-0-0.GW2.SEA1.ALTER.NET (146.188.200.57) 68.349 ms 66.824 ms 67.954 ms 11 ms4-gw.customer.ALTER.NET (137.39.136.166) 70.007 ms 67.991 ms 68.478 ms 12 207.46.129.5 (207.46.129.5) 60.632 ms 140.872 ms 291.818 ms 13 * * * 14 * * * 15 * * cynosure? dowho 207.46.129.5 WHOIS for 207.46.129.0 FROM ARIN: Microsoft (NETBLK-MICROSOFT-GLOBAL-NET) One Microsoft Way Redmond, WA 98052-6399 Netname: MICROSOFT-GLOBAL-NET Netblock: 207.46.0.0 - 207.46.255.255 Coordinator: Whipple, David (DW727-ARIN) dwhipple(a)MICROSOFT.COM 206-703-3876 Domain System inverse mapping provided by: DNS4.MOSWEST.MSN.NET 204.255.246.20 DNS5.MOSWEST.MSN.NET 204.255.246.21 In message <Pine.LNX.3.96.980507153410.19913H-100000@kit> you wrote: > > 425-882-8080 as listed by whois for Microsoft is not their NOC. When you > call this number you are told that they will only transfer by a persons > name or extension and offer no other assitance. > > If anyone has any other contact information it would be appreciated. > > -- > > Kit Knox [kit(a)connectnet.com] - CONNECTnet INS, Inc. > >

1 0