- Test - lists.nanog.org

Re: "They all suck!" Re: UPS failure modes (was: fire at NAC)
by Dan Armstrong 29 May '03

29 May '03

I agree, of course it is ludicrous to think otherwise. It has always bothered me that we rectify AC power to store it in batteries, then re-invert it to power AC servers only for them to rectify it again.... Dan. "Tom (UnitedLayer)" wrote: > > Or we could all take a page from the book of telecom, and run with DC systems. > > It'd be nice to be able to tell our customers: > "Oh hey, you can only use DC power supplies, so you'll need to change out > all of the power supplies in your 1U's, Sun Boxes/etc" > > Yes, I have run an installation of servers that were all DC, and it was > neat, but hardwiring everything was not an exciting task. It was also hard > to find people who were experienced with DC. Most sysadmins have never > worked with DC, and the process of pulling a fuse, unscrewing some > terminals/etc/etc before working on gear isn't always remembered. > > > If only the equipment manufacturers would stop gauging on price for > > DC equipment/power supplies. > > Amen! > You'd think there might actually be less components in the things :)

3 2

RE: "They all suck!" Re: UPS failure modes (was: fire at NAC)
by Temkin, David 29 May '03

29 May '03

Liebert makes one, actually. The model # escapes me, but we considered using it for equipment that's single powered. (We have uber power redundancy..) -----Original Message----- From: E.B. Dreger [mailto:eddy+public+spam@noc.everquick.net] Sent: Thursday, May 29, 2003 7:38 PM To: nanog(a)merit.edu Subject: Re: "They all suck!" Re: UPS failure modes (was: fire at NAC) SD> Date: Thu, 29 May 2003 16:53:43 -0400 (EDT) SD> From: Sean Donelan SD> Yep, tieing together "redundant" systems with parelleling gears SD> turns two independent systems into one "co-dependent" system. In a SD> failure situation, you want to compartmentalize the failure. SD> Loosing half your systems may be better than loosing all your SD> systems. Too bad a substantial amount of equipment doesn't allow for redundant plugins. The ability to plug { servers | routers | whatever } into two totally separate power feeds is nice. Anyone for building a rackmount transfer switch for two inputs? Assuming it didn't fail (!) -- would the economies of scale work for or against it compared to big transfer switches? Between dealing with _much_ smaller current levels and the opportunity for mass production, what are the chances of something like this working? Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist(a)brics.com> To: blacklist(a)brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist(a)brics.com>, or you are likely to be blocked. IMPORTANT:The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

Update to the bogon route-server project
by Rob Thomas 29 May '03

29 May '03

Hi, NANOGers. We're pleased to announce the release of version 1.7 of the Bogon Route-Server Project. The major change in release 1.7 is the addition of three more bogon route-servers to the bogon route-server project, for a total of four. These are all managed by Team Cymru, and provide additional redundancy for the project. All of the bogon route-servers announce the same bogon prefixes and use the same ASN and community. Folks are free to peer with as many as they like, though we recommend a minimum of two. Peering with the bogon route-servers is *FREE*, though you are welcome to buy a cup of coffee for Rob at the SLC NANOG if you feel kindly. :) You can read more about the project here: <http://www.cymru.com/BGP/bogon-rs.html> You can read more about bogon filtering and tracking here: <http://www.cymru.com/Bogons/> Thanks! Rob, for Team Cymru. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);

1 0

Re: Does anyone have an up to date list of ASN allocations?
by Herb Leong 29 May '03

29 May '03

E.B. Dreger [eddy+public+spam(a)noc.everquick.net] wrote: #HL> Date: Wed, 28 May 2003 17:28:45 -0700 #HL> From: Herb Leong # # #HL> Does anyone have an up to date list of ASN assignments? #HL> All of the usual places that I normaly check are now out #HL> of date. Searches come up with ziltch... # #ftp://ftp.arin.net/info/asn.txt That was quick! Thanks much! /herb

2 1

LH/ELH Recommendations?
by Deepak Jain 29 May '03

29 May '03

Last time I asked the list for recommendations on how to solve a short reach fiber problem I got some amazing answers and suggestions -- for which, I am still appreciative of. I summarized for everyone who asked and will gladly do so if anyone else would like to know. I've got a new pickle I am trying to work through and have been wholly unexcited by the solutions various vendors are talking about (read: $=x^n). I am trying to signal over a dark fiber (SMF) loop of about 200 miles. (150mi on one leg and 50mi on the other). I would _like_ to find a 10GE solution (say a XENPAK module that will do 150miles), but GE would do if it supports some kind of xWDM. I am afraid I am going to have to go Lucent LamdaXtreme or Cisco ONS 15800, but am hoping that is just overkill. Heck, a source for used LH/ELH SONET OADMs would be fanastic if a router-based solution isn't obvious. I am certain many on this list have tackled this kind of problem in particularly ingenious ways. Your pointers are very much appreciated. Thanks in advance, DJ

3 3

RE: "They all suck!" Re: UPS failure modes (was: fire at NAC)
by Shaun Bryant 29 May '03

29 May '03

One thing people seam to have forgotten is that with added redundancy comes added complexity that is many cases out ways the gain. Shaun > -----Original Message----- > From: Alex Rubenstein [mailto:alex@nac.net] > Sent: Thursday, May 29, 2003 1:40 PM > To: Sean Donelan > Cc: nanog(a)merit.edu > Subject: Re: "They all suck!" Re: UPS failure modes (was: fire at NAC) > > > > > > UPSes (and UPS batteries) do fail, sometimes in catastrophic ways. I > > would not design any critical system on the assumption that any > particular > > component won't fail. High availability is about designing for failure. > > Sometimes there is a long time between failures, other times they occur > > early and often. The most annoying thing about UPSes is they fail at > > exactly the time they are needed most. > > Except, that: > > Even in instances where 'High availability' is designed, in the case where > one of the units has a failure that causes a fire and FM200 dump, either > the FM200 will still trigger an EPO, or the fire department will. > > So, the second 'high available' unit will generally not prevent you from > dropping the critical load, but instead, will help you get back on line > quicker. > > A much cheaper and easier to implement external maintenance > make-before-break bypass will accomplish the same thing. > > I've heard many a story of the paralleling gear causing the problem in the > first place, as well... > > > > -- Alex Rubenstein, AR97, K2AHR, alex(a)nac.net, latency, Al Reuben -- > -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --

1 0

Re: "They all suck!" Re: UPS failure modes (was: fire at NAC)
by Robert Boyle 29 May '03

29 May '03

At 04:39 PM 5/29/2003 -0400, you wrote: >A much cheaper and easier to implement external maintenance >make-before-break bypass will accomplish the same thing. > >I've heard many a story of the paralleling gear causing the problem in the >first place, as well... We have two MGE 150KVA UPSes at our Newton facility. When I designed the electrical system, I originally specified a make-before-break 208V 450A 3PH switch. This would enable us to isolate our internal and customer load panels from the two UPSes and their respective static transfer switches and output transformers - so we would have completely redundant dynamic A/B switching. The ONLY vendor at any price I could find was for a switch made for the FAA for their regional approach control centers critical power systems. It cost $250,000 wholesale with a six month lead time!!! I decided I would take my chances with the integrated MGE static transfer switches and use one output transformer. For that amount of money, I can buy two more UPS units when my load grows to 75% (to minimize the stress on the circuit components and to control the transformer temperature by running it well within limits) and still have $90k in the bank. Since we designed and installed everything ourselves, I know we can bypass one UPS if we ever have a catastrophic failure of the internal static transfer switch. In retrospect, I think it may have been better to have a split output for UPS #2 one feeding the bypass for UPS #1 and one feeding a break-before-make manual switch which normally connects the output of #1 to our circuit panels for quick service restoration in the event that UPS #1 fails in the critical path such as the output transformer or the static transfer switch. The comments about two MGE units failing due to component failure is a bit scary since our serial numbers are actually the same and we just have different suffixes due to being purchased on the same PO! Whatever components are defective on one are probably defective on the other also. So far, 16 months and zero problems... (knock on wood) -Robert Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Good will, like a good name, is got by many actions, and lost by one." - Francis Jeffrey

1 0

fire at NAC
by alex＠yuriev.com 29 May '03

29 May '03

Fire at nac.net http://www.nac.net Alex

9 9

Re: UPS failure modes (was: fire at NAC)
by Steven M. Bellovin 29 May '03

29 May '03

In message <20030529144110.J31299(a)kod.inch.com>, Gerald writes: > >On Thu, 29 May 2003, Bill Woodcock wrote: > >> I've seen two previous APCs (both Matrixes) fry batteries... The >> batteries balloon up, and get really hot, and are too big to extract from >> the chassis. > >I've also personally witnessed an APC do this. I'm not a fan of APC. >They sent us a replacement APC but I still prefer the rack mount Tripp >Lites we used at the last company I worked for. > There was a recent recall of some of their home/SOHO UPSs -- battery overheating, with risk of fire. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)

2 1

Issues in New York?
by Rob Thomas 29 May '03

29 May '03

Hi, NANOGers. This post is on behalf of Alif Terranson. If anyone can lend a hand or share insight, please pass it along! Thanks! We have all manner of equipment freaking out at State Street's POP, and can find no reason for it: M20's, BSNs, Yurie's, etc. Some of this equipment isn't even on public networks, or in any way connected to other "freaking" equipment, so we are at a loss as to what's happening. Some of our stuff has rebooted, and some of it has simply ceased to function: obviously, our #1 candidate is a local power issue, so we are looking for any "me too" incidents we can find. Is anyone else having issues down there? Replies on or off list appreciated. Alif Terranson Savvis Communications (314) 628-7602 Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);

1 0