Re: Core router bakeoff?

["James B. Slayden Jr." <slayden () nsipo arc nasa gov>]

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 () nsipo nasa gov               NASA Integrated Network Services (NISN)
650-604-6404                    NASA Ames Research Center       
-----------------------------------------------------------------------------

>  From owner-nanog () merit edu  Thu May  7 20:11:05 1998
>  Date: Thu, 7 May 1998 21:30:21 -0500
>  From: Karl Denninger  <karl () mcs net>
>  To: "Jason L. Weisberger" <jweis () softaware com>
>  Cc: nanog () 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 () 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 () 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
>