May 2003 - Test - lists.nanog.org

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

Wireless border crossings
by Timothy Brown 29 May '03

29 May '03

I'm looking for organizations or individuals that have existing wireless (802.11, MMDS, etc) connectivity across international borders in eastern Europe (former Soviet republics), Asia, Africa, or the Middle East. Also of interest are connections that are in the planning stages that are running into difficulty with the governing authorities. Information will be kept confidential; please reply off-list. Tim

2 1

RE: Need DNS server outside my own network
by Mike Damm 29 May '03

29 May '03

I would recommend the DNS-Swap list (http://www.ironclad.net.au/lists/dns-swap/) It's very low volume (<2 posts/mo) but when someone actually posts something you generally receive some good responses. It covers the entire spectrum from swapping secondary for a few zones to swapping colo for offsite secondary. --- Michael Damm, MIS Department, Irwin Research & Development V: 509.457.5080 x298 F: 509.577.0301 E: miked(a)irwinresearch.com -----Original Message----- From: Stephan Schwab [mailto:sns@caimito.net] Sent: Wednesday, May 28, 2003 3:39 PM To: nanog(a)merit.edu Subject: Need DNS server outside my own network Hello all, I'm seeking co-location or a dedicated server outside my own network for a DNS and MX server. I do not want to rent a box from some of the huge companies, but prefer working with a fellow ISP. My systems are currently located at an MFN facility in Frankfurt, Germany. Maybe someone on this list is using cabinets at Miami Data Vault. That would be the place of choice for me as I plan to grow at their location in the near future. Kind regards Stephan Schwab -- Caimito Technologies, LLC http://www.caimito.net 18851 NE 29th Avenue Internet Service Provider Aventura, FL 33180, USA Networking and Security Consulting

1 0