- NANOG - lists.nanog.org

Re: Core router bakeoff?
by Sean Donelan 10 May '98

10 May '98

>A real example from our core: > >XXXXXXX-CoreX uptime is 38 weeks, 1 day, 7 hours, 49 minutes >System restarted by power-on XXXXXX>show version Cisco Internetwork Operating System Software IOS (tm) GS Software (RSP-K-M), Version 10.3(7), RELEASE SOFTWARE (fc1) Copyright (c) 1986-1995 by cisco Systems, Inc. Compiled Wed 01-Nov-95 14:07 by vatran Image text-base: 0x600087E0, data-base: 0x60530000 ROM: System Bootstrap, Version 5.3(16645) [szhang 571], INTERIM SOFTWARE ROM: GS Bootstrap Software (RSP-BOOT-M), Version 10.3(8), RELEASE SOFTWARE (fc2) XXXXXX uptime is 102 weeks, 1 day, 8 hours, 47 minutes System restarted by reload 10.3 was a fairly stable release. The longest running devices on our network are likely some DECserver 100's stuck somewhere long since forgotten. Every year or two, we get a phone call about terminals not working and it turns out the original load host for the terminal server had been upgraded several times in the last decade, and eventually retired from service. There is something to the saying "If it ain't broke, don't fix it." -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

5 4

Vendor support (Re: Core router bakeoff?)
by Sean Donelan 10 May '98

10 May '98

We pay for 4-hour premium 24x7 on-site response supposedly so I don't have to argue with Cisco whether they will have a tech on-site now, or next tuesday (Next business day from Saturday==Tuesday). At least that's the theory. Most of the time it works well, but last weekend we ended up having to escalate things through cisco's call center of the hour (wherever "M27542" ends up) because the cisco person on the other end kept insisting that 4-hour response meant only Monday through Friday. grrrrrrrrrrrrrrrrr! I was thinking up some very interesting variations of Cisco Certified I.... in my head. >An anecdote that is related to this... > >In January, on the day we (NACS.NET) had our open house, the RSP-2 >board in our 7513 (which we bought used) died. > >Cisco worked with us to get a replacement in four hours, even though they >were only contractually obligated to 24 hours. > >Kudos to Cisco's Cleveland office for going WAY beyond the call of duty. > >And when I'm ready to buy a dedicated router, it WILL be a Cisco. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Y2K
by Sean Donelan 10 May '98

10 May '98

Since the rest of this has nothing to do with routers, for Randy: clock set 00:00:00 1 jan 2000 >I don't but its an opportunity to sell the client. And if you don't test it I >recommend you don't get quoted saying it doesn't matter unless you want a >lawsuit if anything happens. > >Customers want everything in writing to be Year 200 compliant or not having any >affect on their operation and in many cases regulators are mandating it in >writing. Funny how the customer wants it to be Y2K compliant, but they have no problem with the rest of the software licenses that says "In no event does xxxxx warrant that the Software is error free or that Customer will be able to operate the Software without problems or interruptions." Quoted directly from a very well-known vendor's license agreement, who has issued big press releases about their Year 2000 Compliance program. Its even going to be 'certified.' Whoopie! How about a challange, instead of issuing press releases about the Y2K compliance, just remove the above sentence from your license agreement and stand behind your product. If something fails, does it really matter why it fails? The problem is it failed. Some users have become so accustomed to using CTL-ALT-DEL, they think its a normal part of the software function. Why do I have this feeling on January 3, 2000 (fortunately Jan 1, 2000 is a Saturday), the same number of users are going to get the 'blue-screen of death' as on every other day between now and then; but on the CBS evening news Dan Rather's replacement will gravely report that millions of computers got the 'blue screen of death' because its the year 2000. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

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

09 May '98

Eric Germann <ekgermann(a)cctec.com>,Internet writes: Given that Cisco built their routers for them, and then they pissed off Cisco to the point where they didn't renew there code license for IOS in there hubs because of their anti Cisco marketing campaign. It was a limited 4000 Router. Only two slots instead of three. Cabletron is now pushing their new SmartSwitch Router that they acquired when they purchased YAGO systems. They claim its an ISP backbone quality router (honest its on their web page). But I don't believe it does BGP4. Cabletron has a bad rap with consultants. Don't ever try to partner with them and walk them in someplace. They are the borg, you will be assimilated. Hey, you haven't spoken with your local Cabletron rep lately; Cabletron is pushing channel relationships again. Now that I ragged on em, they do have solid stuff. I have one client who has had their MMAC hubs up and running for about 8 years with narry a hiccup. And these are in rotten basements. You are right but is it Year 2000 compliant? Thanks, Joe Kucic

5 4

Re: Core router bakeoff?
by shields＠crosslink.net 09 May '98

09 May '98

In article <199805081728.NAA19463(a)persephone.ny.ans.net>, Selina Priestley <selina(a)ans.net> wrote: > One PC remote management win is that you can actually have secure > encrypted access/authentication for remote management, rather than > relying passwords in the clear and tftp. This is lacking in all > router venders at this instant, far as I know. Cisco has support for Kerberized telnet in some images -- good luck getting it to work, though. -- Shields, CrossLink.

1 0

Re: Core router bakeoff?
by Selina Priestley 09 May '98

09 May '98

> > In short, unless you have numbers to indicate otherwise, I can't say > that PCs cost you much, in the short term or the long term. > > What Cisco's will buy you is better handling of T3s, SONET, etc., and > the ability to handle much higher performance lines. They also have > much better remote management facilities, in so far as the things have > real serial consoles and such, which PCs don't. > > Perry One PC remote management win is that you can actually have secure encrypted access/authentication for remote management, rather than relying passwords in the clear and tftp. This is lacking in all router venders at this instant, far as I know. Selina

3 2

RE: Microsoft NOC?
by Kurt Parent 09 May '98

09 May '98

Microsoft's NOC is best accessed via the msnnoc(a)microsoft.com e-mail alias. The peering(a)microsoft.com alias handles (what else) peering inquiries and internal communication. thanks, kurt- Kurt Parent kparent(a)microsoft.com > -----Original Message----- > From: Reid B. Fishler [SMTP:redhead@cloudy.lightning.net] > Sent: Thursday, May 07, 1998 3:44 PM > To: kit(a)connectnet.com > Cc: nanog(a)merit.edu > Subject: Re: Microsoft NOC? > > try writing peering(a)microsoft.com. I got a live person there...In their > networking dept. > > Reid > > > > > > 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. > >

6 5

sprint's outage list
by Dean Gaudet 09 May '98

09 May '98

Ya know, I really hate to do this. But I've tried through all the correct/expected channels. But sprint won't remove me from their outage list. I've mailed majordomo(a)sprint.net @sprintlink.net @mercury.res.sprintlink.net, and they all claim I'm not a list member. I've mailed postmaster, owner-outage, outage-owner, postout, outage-request. I even sent it to outage-outgoing, even though I knew it wouldn't get through. I've sent the request to the tech contact for sprint.net, which is the same as the tech contact for the reverse DNS of a few of their nets, and is the same as the address listed in their SOA records. I sent it to the tech contact for AS1239 (noc(a)sprint.net) I considered sending it to all the mail contacts for MAINT-AS1239 (radb), but most of them don't even appear to be sprint employees. As you can see from the headers below, the message is delivered to dgaudet-list-outage(a)arctic.org. I've tried all of the above using that as the envelope sender -- I'm not just some stupid luser that doesn't understand this crap. All to no avail. So here I come, hoping to embarass some sprint employee to take me off their damn list. I'm sorry to waste the rest of your time. Thanks Dean ---------- Forwarded message ---------- Return-Path: <owner-outage(a)sprint.net> Delivered-To: dgaudet-list-outage(a)arctic.org Received: (qmail 15150 invoked from network); 9 May 1998 08:07:29 -0000 Received: from gate1.sprintlink.net (199.0.233.2) by twinlark.arctic.org with SMTP; 9 May 1998 08:07:29 -0000 Received: from mercury.res.sprintlink.net by gate1.sprintlink.net via smtpd (for twinlark.arctic.org [204.62.130.91]) with SMTP; 9 May 1998 08:07:29 UT Received: (from root@localhost) by mercury.res.sprintlink.net (8.7.3/8.6.12) id DAA05866 for outage-outgoing; Sat, 9 May 1998 03:24:57 -0400 (EDT) Received: from elle.res.sprintlink.net (elle.res.sprintlink.net [199.0.234.34]) by mercury.res.sprintlink.net (8.7.3/8.6.12) with ESMTP id DAA05861 for <outage(a)mercury.res.sprintlink.net>; Sat, 9 May 1998 03:24:56 -0400 (EDT) Received: from gate1dmz.res.sprintlink.net (gate1dmz.res.sprintlink.net [199.0.234.1]) by elle.res.sprintlink.net (8.8.5/8.8.5) with SMTP id DAA17852 for <outage(a)sprint.net>; Sat, 9 May 1998 03:51:23 -0400 (EDT) Received: from jay.sprintlink.net ([199.0.233.8]) by gate1dmz.res.sprintlink.net via smtpd (for elle.res.sprintlink.net [199.0.234.34]) with SMTP; 9 May 1998 07:49:53 UT Received: from gate1.sprintlink.net (gate1.sprintlink.net [199.0.233.2]) by kay.sprintlink.net (8.8.5/0.0.0) with SMTP id DAA21247 for <outage(a)sprint.net>; Sat, 9 May 1998 03:50:27 -0400 (EDT) Received: from vas.res.sprintlink.net by gate1.sprintlink.net via smtpd (for jay.sprintlink.net [199.0.233.8]) with SMTP; 9 May 1998 07:49:52 UT Received: (from httpd@localhost) by vas.res.sprintlink.net (8.8.5/8.6.12) id DAA13839; Sat, 9 May 1998 03:48:49 -0400 (EDT) Date: Sat, 9 May 1998 03:48:49 -0400 (EDT) Message-Id: <199805090748.DAA13839(a)vas.res.sprintlink.net> From: Outage Poster <postout(a)sprint.net> To: outage(a)sprint.net Subject: Outage in Fort Worth area Sender: owner-outage(a)sprint.net Precedence: bulk Sat May 9 03:48:48 EDT 1998 OUTAGE MESSAGE The problem that was reported of the outages in the Fort Worth area (@ 00:05 EDT on 5/09/98) has been fixed. There should not be any more problems in the area. Thank you for bearing with us. Andrew Jacobsen, -Sprintlink NOC ===================================================================== For Sprintlink network status, call 1-800-232-6895; option 1, 1. For Sprintlink scheduled maintenance activities, go to http://www.sprint.net/maint/

1 0

Re: Core router bakeoff?
by Tony Li 09 May '98

09 May '98

perry(a)piermont.com (Perry E. Metzger) writes: > > Interesting. Have you done any scalability testing? Per-flow state has > > been shown to scale poorly in Internet backbones. > > I agree with you that it doesn't scale well to huge routers. I am > certain that it would work very badly in MCI's backbone. It probably > will work just fine in a small provider, though, and those are most of > the guys who want to roll their own out of PCs anyway. Not a foregone conclusion. Recall that it's not the absolute volume of the traffic that's the difficulty but the diversity and 'hit ratio' of the particular traffic patterns. If the flow cache is small and stable, then you could push terabits. The problem that has been seen is that anything connected to the Internet with a significant community behind it has critical mass to churn the flow cache. > If you want to pump half a gigabit through on a giant peering router, > caches will lose, and the only thing that will do you right is > real router hardware. I wouldn't know anything about that. Tony

1 0

Re: Core router bakeoff?
by Tony Li 09 May '98

09 May '98

paul(a)vix.com (Paul Vixie) writes: > > > 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 :-)? Not obvious to some, but we sat and watched a significant router vendor make that mistake (despite good advice to the contrary) anyhow. I'd hate to see someone else repeat that mistake. Tony

1 0