May 2003 - Test - lists.nanog.org

RE: .mil domain
by McBurnett, Jim 31 May '03

31 May '03

Let me say this: I am former military.. Worked in Military IT. AND worst case situation, use www.cert.mil Or if not that bad.. Call the public affairs officer at the branch of service.. Tell him you need help, tell him to put you in contact with the local Info systems type. and away u go.. I wish I still had the DoD and BoS NOC #'s but I don't.. If you want to complain to a US Military net admin and just find one, well it is not for lack of contact info.. It is lack of trying. And yes I have sent stuff to the military.. Recently got a huge nessus scan and DoS attack attempt from a military block.. went to that services web site and found the Info systems # on the web.. AND IT WORKED..... We used to say a Marine was not happy unless he had something to complain about... But it is the same for most all of us..... just my 10 cents worth.. Inflation ya know... J Lazyness is just the act of being tired before doing the work.... > > Your escalation route goes to the OSD-CIO (Office of Secretary > Defense) in the 5-sided building. That was Art Money's office but > I don't know if he's still there. I'd cc: the Inspector General > for whichever branch as well...and the FTC. > In other words, when one can't get a response, check with NANOG. :) -Jack

1 0

Level3 and BBNow (BroadbandNow) ??
by John Brown 31 May '03

31 May '03

seems that there is an ongoing many hour issue between level3 and broadband now anyone have any news. can't get anyone to answer at bbnow, and level 3 isn't saying anything john

1 0

.mil domain
by Steve Waddington 30 May '03

30 May '03

Our whole netblock 202.154.64.0/18 seems to be barred from anything .mil. Domain name resolution, MX, IP traceroute, the lot. Anyone able to shed any light on this? Any advice/feedback appreciated. Regards, Steve

17 21

Salt Lake NANOG Dinner and Movie, Reloaded
by Pete Kruckenberg 30 May '03

30 May '03

For those who will be in Salt Lake for NANOG on Sunday evening, June 1, and looking for fun socializing: Aviva Garrett from Juniper suggested a NANOG field trip Sunday evening to see Matrix Reloaded. Great idea. I will make the necessary arrangements (reservation at Happy Sumo Sushi Bar, hotel shuttle to get back) for anyone who will RSVP. We would leave right after the 5:00pm tutorial Sunday evening, ride TRAX light rail to The Gateway for a 6:00pm dinner at Happy Sumo (or any Gateway restaurant you'd like, see http://www.boyercompany.com/gateway/directory-a.html for a complete list). We'd catch the 8:15 (or if we eat fast, the 7:15) Reloaded show, then ride the hotel shuttle back at 11:00 (or 10:00 if we catch the 7:15 show). Let me know if you are interested, I will make the necessary arrangements. If you want to come just for dinner or for the movie, RSVP anyways and let me know that. This is a pay-your-own-way event. Though any vendors willing to fund the field trip will not be turned down. Pete.

2 1

RE: .mil domain
by Mike Damm 30 May '03

30 May '03

Counter: leave everything as it is. If they are willing to provide the hardware, bandwidth, and administrative costs to run root servers, they can block whoever they want. Just like if you run a web server you can block anyone from accessing it that you want. If you don't like it, start up your own root zone, there isn't anything stopping you. Not that it matters much in the big scheme of things; most modern resolvers will give preference to root servers they can actually reach. I for one am pretty happy with where E, G, and H are. Cogent and VeriSign's networks can hardly handle power cycles, let alone nuclear wars. --- Michael Damm, MIS Department, Irwin Research & Development V: 509.457.5080 x298 F: 509.577.0301 E: miked(a)irwinresearch.com -----Original Message----- From: Mark Borchers [mailto:mborchers@igillc.com] Sent: Friday, May 30, 2003 12:09 PM To: nanog(a)merit.edu Cc: stephen(a)sprunk.org; listuser(a)numbnuts.net; Mike Tancsa Subject: RE: .mil domain Suggestion: migrate the current MIL root servers to the DREN network. Thus they would be easily accessible from DoD's networks, while residining in front of any MIL filters or blackhole routers relative to the rest of the Internet. > On Fri, 30 May 2003, Mike Tancsa wrote: > > > > > At 01:15 PM 30/05/2003 -0500, Stephen Sprunk wrote: > > > > >For the same reason anyone else accepts their routes -- > because they want to > > >be able to reach them. If they don't want to reach _you_, that's their > > >choice. > > > > As Sean Donelan pointed out, the fact that 2 of the root name > servers are > > inside their network, there is more to the issue than you > suggest.... I for > > example want people in Australia to be able to reliably lookup > DNS info on > > my domains. The .mil people have decided to hamper this process. > > I agree. The root servers should have no filtering in place to block any > demographics (unless of course a given node is DoSing them). > > The last time I tried to contact a .mil to report an open relay that was > being abused, I was accused of being a spammer that had "hacked" their > server. Since that time I reject .mil mail. > > Justin >

2 1

UPS failure modes (was: fire at NAC)
by Robert Boyle 30 May '03

30 May '03

At 12:27 AM 5/29/2003 -0400, you wrote: >Sheesh. Heh. > >We're still here. > >Part of a rectifier in a Liebert UPS let loose, causing a momentary fire. >That is, until the FM200 quenched it. > >Since there seems to be interest, I will post the post-mortem to the list. I had a little 2000VA rackmount Liebert UPS catch fire in 1997 and another new and improved Liebert model almost catch fire about a year later. Both were operating well within specified input, load, and temperature parameters. I haven't really trusted them since.I bought dual MGE UPSes for our datacenter in 2002. I figured if E****s can flip them on and off randomly and massively overload them all in an environment which is 95 degrees F, then they should hold up nicely for us when lightly loaded at 65 degrees F. :) The reason for this rambling post is to ask if others have had similar problems with other UPS brands. I think they should have enough fail-safes built-in that they are never the CAUSE of an outage much less a fire! Based on my experience and NAC's incident today, is that an unreasonable expectation? I don't think manufacturers specify MTBF (mean time before fire) figures for UPS units. What have others experienced as the failure mode(s) for their UPS(s)? The static transfer switch should drop the load onto line/bypass power immediately and shut down the inverter while tripping the battery disconnect at the first sign of trouble - does this work as designed and advertised most of the time or just some of the time? Of those with UPS failure histories, what has happened in your situation? 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

21 32

Re: Moving G and H off .MIL hosts (was Re: .mil domain)
by Kevin Day 30 May '03

30 May '03

> >If the .MIL network can't provide International Internet service, is it >time to move the g.root-servers.net and h.root-servers.net off their >current .MIL hosts to better locations to serve the entire Internet. >Otherwise .MIL policies reduce the robustness of the overall Internet. > >Heck, even when Paul Vixie did his original black-hole lists, he made >certain that even the worst spammers could still use f.root-servers.net. Whatever filtering some .MIL sites may or may not be doing, I don't believe that g or h.root-servers.net are affected. I've tried tracing to them from systems in .uk, .tw, .ru, .kr, .and hk and I get the same results from them as I do from my ARIN allocated US IP blocks. (trace to G with no problem, H has ICMP blocked at gw328-hroot.arl.army.mil, but UDP port 53 seems to get though fine) To be honest, I'd be rather surprised if .MIL as a whole did ANYTHING jointly. The number of independant networks, AS's, borders and administrators would make it really difficult for any blanket policy to take effect everywhere. -- Kevin

1 0

Off topic - New "Nanog" gene
by Joseph T. Klein 30 May '03

30 May '03

"In recognition of that power, the researchers have named the gene "nanog," a reference to the mythological Celtic land of Tir Nan Og, whose fairy-like residents are said to stay forever young." http://www.washingtonpost.com/wp-dyn/articles/A55817-2003May29.html -- Joseph T. Klein <This space available. Ask for my resume.> PSTN: +1 415 462 1534 Mobile: +1 414 628 3380

4 3

Re: IANA reserved Address Space
by bmanning＠karoshi.com 30 May '03

30 May '03

> > > Bill Manning wrote: > > that said, as long as your lab is never going to > > connect to the Internet, you may want to consider > > using the following prefixes: > > [..] > > 127.0.0.0/8 > > I would not use 127.0.0.0/8 for anything. > > Michel. > that would be you. in 1989, i built a 6,000 node network w/ 400 subnets out of that address range. worked a treat. since then the UNIX fascists have tightened their grip on what the enterprising admin can do w/ that portion of the address map. now 127.0.0.0/8 seems mostly good for things like NTP and "host" addresses, not tied to any specific interface. still useful for some of us. --bill

1 0

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

30 May '03

Here you go: http://www.liebert.com/dynamic/displayproduct.asp?ID=1042&cycles=60Hz -----Original Message----- From: Temkin, David Sent: Thursday, May 29, 2003 7:49 PM To: 'E.B. Dreger'; nanog(a)merit.edu Subject: RE: "They all suck!" Re: UPS failure modes (was: fire at NAC) 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.

3 2