- NANOG - lists.nanog.org

Re: GBLX congestion in Dallas area
by Fergie (Paul Ferguson) 08 Jun '05

08 Jun '05

I concur. - ferg -- Dave Stewart <dbs(a)dbscom.com> wrote: But I think NANOG is certainly an appropriate forum for medium/large-scale outages - unless someone's created an outage list someplace. I will agree that it's not the place to bitch about a vendor not giving more specifics, dumping on vendors in any way, actually... -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

2 1

RE: Slight OT: NASA World Wind project looking for support from network operators.
by Matt Mills 08 Jun '05

08 Jun '05

Since there seems to be a lot of list-related chatter suggesting we use bittorrent for our distribution needs, I'd like to respond on-list to those. Why we don't use Bittorrent for distribution of the program: Actually, theirs no real problem here, we have used bittorrent in the past. The only real issue is that there are so many non-savvy users, that most of the users just click past the bittorrent link and go straight for the HTTP links. Why we don't use Bittorrent for the distribution of the satellite data: This is just where P2P and satellite data don't mesh. In order for the program to work and not be incredibly frustrating and boring, the tiles (imagery and elevation) have to be loaded at a somewhat speedy rate. Due to the way P2P has to find and connect to peers before it can start downloading tiles, it is just too slow for it to work well (and not make everyone unhappy/ the program useless). The other problem here is that there is hundreds of gigabytes composing of millions of files, so to be able to get full coverage of just one dataset would be an enormous effort. I also received a few responses recommending Coral CDN. Unfortunately for the program, Coral has a file size limit of 50 MB (Client is currently 188 MB). Unfortunately for the satellite data, since there are so many small files, it would be quickly pushed out of the cache. Also, coral isn't all that speedy with responses, so it makes the program moderately sluggish. Also, while I'm posting, I'd like to ask if anyone has contact information for someone at Archive.org, could you please contact me with it? I've been trying to get in reach with someone over there but all my emails seem to find a black hole. Thanks to all. Matt Mills

3 2

Onsite Generation: A Reminder [was: Battery Maint in LEC equipment]
by Frank Coluccio 08 Jun '05

08 Jun '05

There's been much said here and over in the Cybertelecom list recently about battery provisions by telcos and cable operators, but relatively little has been mentioned about onsite generation. I sometimes point my staff and clients to the messages that were posted here in NANOG, including those of my own, immediately following the attacks of September 11th and lasting into the next month or two. Many here will recall that at that time many hubs and enterprises alike in the downtown area of Manhattan, including the area's Internet exchanges and colos, received a first-hand lesson on the need to maintain preparedness with functioning generators, including fuel and spare parts. Not to mention the need to modify air intakes and exhausts for a new form of threat: Airborne Debris. Frank On Tue Jun 7 15:34 , Jerry Pasker sent: > >Even though it is fed with N+1 UPS power, Qwest put N+1 rectifiers & >batteries for their fiber cabinet they installed for me a few years >ago. At the time, batteries were required no matter what, and they >say they will replace them every 5 years. A little-town independent >telco however, refused to even install a data center fiber shelf >unless I provided them with DC power. It just seems to depend on the >whim of the telco. > >As prices fall, so does level of service. NANOGers all know >providing uninterruptible power in the current evolving networks is >hard as the communications infrastructure continues to decentralize. >Providing non stop power for long term power failures with generators >scattered all over the place is insanely hard. Keeping them running >during a widespread 'event' is even harder. Everyone wants (expects) >"always on" dial tone. And everyone wants cheap calling and cheep >bandwidth. Batteries, generators, and their maintenance/operation >are expensive. A resilient built network is much more expensive than >a non resilient one. Eventually the public will start to realize >this, and start to demand laws to maintain certain minimum levels of >service. It won't happen until some large disaster, or touching news >story about some preventable tragedy brings it in front of the >public. People will have to die for this trend to change. > >The non-reliable VOIP as a lifeline, even if it's not intended as >one, is the tip of this iceberg. > >(by the way, like many other forms of regulation, the same goes for >internet regulation.... if some shady network somewhere ever turns >out to be the root cause of some incident where a number of deaths >occur, regulation will soon follow) > >Aside from human error, right now the weakest link in the net is the >grid, and that is a link that isn't apparently getting any stronger.

1 0

RE: GBLX congestion in Dallas area
by Paul Jasa 07 Jun '05

07 Jun '05

Agreed. I joined Nanog initially to be alerted of medium/large-scale outages (used to work for a telco), but then I was pleasantly surprised by the deeper technical "edge" of most participants on this fabulous list. Best of both worlds, IMO. Thanks and regards to all, pj -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Fergie (Paul Ferguson) Sent: Tuesday, June 07, 2005 6:53 PM To: dbs(a)dbscom.com Cc: nanog(a)merit.edu Subject: Re: GBLX congestion in Dallas area I concur. - ferg -- Dave Stewart <dbs(a)dbscom.com> wrote: But I think NANOG is certainly an appropriate forum for medium/large-scale outages - unless someone's created an outage list someplace. I will agree that it's not the place to bitch about a vendor not giving more specifics, dumping on vendors in any way, actually... -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/ The information contained in this e-mail and any attached documents may be privileged, confidential and protected from disclosure. If you are not the intended recipient you may not read, copy, distribute or use this information. If you have received this communication in error, please notify the sender immediately by replying to this message and then delete it from your system.

1 0

Problems with Qwest Frame Relay?
by John Neiberger 07 Jun '05

07 Jun '05

By any chance, are any of you seeing any problems with Qwest frame relay or iQ in Colorado? We just had a whole bunch of frame relay PVCs all over the area go down. I've opened a ticket with Qwest, of course, but I haven't heard back from them since I opened it and I'm now on eternal hold with their IP NOC. Have any of you heard anything? Did a frame relay switch bite the dust? Thanks, John --

1 0

Re: Micorsoft's Sender ID Authentication......?
by Brandon Butterworth 07 Jun '05

07 Jun '05

> DomainKeys are the work of the devil Well it is one of the most untidy headers DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:mime-version:content-type:x-mailer:x-mimeole:thread-index:in-reply-to:message-id; b=A7ZrgGGQFcA2+oJOMAHBFh6JTlNevGsVUn6qe8hx+7flOVzwxxJ6qB+V5EE3ylz0ZmILAfhBu6b3GKwDJdw0NfF4AqsshdQ0xEyvMpFHUytXunQ50ui37DQjqvk3KK+5SxYt4kbVhyk8UWn16Ory0MqKJJ5q12iITUtxIGIWLDs= brandon

1 0

Is anyone from XO monitoring?
by Drew Weaver 07 Jun '05

07 Jun '05

Please contact offlist asap. Thanks, -Drew

1 0

GBLX congestion in Dallas area
by Joel Perez 07 Jun '05

07 Jun '05

Is anybody seeing any congestion in the Dallas area for Global Crossing? I'm seeing packet loss to some of my equipment up there. Thanks, -------------------------------------------- Joel Perez | Network Engineer 305.914.3412 | Ntera --------------------------------------------

2 1

drone armies C&C report - May/2005
by Gadi Evron 07 Jun '05

07 Jun '05

Below is a periodic public report from the drone armies / botnets research and mitigation mailing list. For this report it should be noted that we base our analysis on the data we have accumulated from various sources. According to our incomplete analysis of information we have thus far, we now publish our regular two reports. This month we would especially like to commend Staminus, who contacted us and have since made incredible efforts to deal with the threat. Also, we'd like to mention Internap for their continuous efforts. The ISP's that are most often plagued with botnet C&C's (command & control) are, by the order listed: ---------------------------------- Top 15 with open non-resolved suspect C&Cs by Name: ASN Responsible Party Unique C&Cs Open-unresolved 6517 YIPESCOM - Yipes Communication 60 41 21840 SAGONET-TPA - Sago Networks 90 24 25761 STAMINUS-COMM - Staminus Commu 86 20 4766 KIXS-AS-KR Korea Telecom 43 20 13680 AS13680 Hostway Corporation Ta 22 19 21698 NEBRIX-CA - Nebrix Communicati 24 18 13301 UNITEDCOLO-AS Autonomous Syste 27 17 21788 NOC - Network Operations Cente 29 16 29415 EUROWAN-ASN OVANET - EuroWan d 16 15 13749 EVERYONES-INTERNET - Everyones 24 14 30083 SERVER4YOU - Server4You Inc. 21 14 25700 SWIFTDESK - SWIFTDESK VENTURE 13 13 23522 CIT-FOONET - CREATIVE INTERNET 14 12 27595 ATRIVO-AS - Atrivo 31 11 13237 LAMBDANET-AS European Backbone 11 11 The following table is a historical ranking of the top 10 Responsible parties listed by the number of unique C&Cs in the BBL along with the current number of C&Cs responding as open at the time of the survey. ASN Responsible Party Unique C&Cs Open-unresolved 21840 SAGONET-TPA - Sago Networks 90 24 10913 INTERNAP (Block 1,3,4,5) 90 1-5 13790 19024 14742 25761 STAMINUS-COMM - Staminus Commu 86 20 6517 YIPESCOM - Yipes Communication 60 41 4766 KIXS-AS-KR Korea Telecom 43 20 27595 ATRIVO-AS - Atrivo 31 11 21844 THEPLANET-AS - THE PLANET 31 1-5 21788 NOC - Network Operations Cente 29 16 13301 UNITEDCOLO-AS Autonomous Syste 27 17 3356 LEVEL3 Level 3 Communications 25 1-5 * We would gladly like to establish a trusted relationship with these and any organizations to help them in the future. * By previous requests here is an explanation of what "ASN" is, by Joe St Sauver: http://darkwing.uoregon.edu/~joe/one-pager-asn.pdf The Trojan horses most used in botnets: --------------------------------------- 1. Korgobot. 2. SpyBot. 3. Optix Pro. 4. rBot. 5. Other SpyBot variants and strains (AgoBot, PhatBot, actual SDbots, etc.). This report is unchanged. Credit for gathering the data and compiling the statistics should go to: Prof. Randal Vaughn <Randy_Vaughn(a)baylor.edu> -- Gadi Evron, Israeli Government CERT Manager, Tehila, Ministry of Finance. gadi(a)CERT.gov.il Office: +972-2-5317890 Fax: +972-2-5317801 The opinions, views, facts or anything else expressed in this email message are not necessarily those of the Israeli Government.

1 0

Needed : AOL Network Contact
by David Brinks 07 Jun '05

07 Jun '05

I seem to have a couple Class Cs that AOL's portal servers are blocking and I would like to contact someone at AOL to discuss getting the blocks removed. I've tried going through their tech support but after multiple dead-ends and being told "AOL is a content provider and doesn't have Network Support group, nor servers nor any people who take care of servers" multiple times I'm wondering if any one you may have a backside phone number or email I could try. (I've already tried the number listed in their whois information but that only gets met to their Postmaster group and they also tell me they have no group that takes care of routers, IPs or servers.) Thank-you for your time and any help anyone may be able to offer. David Brinks --- Power-Net Internet Services --- Network Manager brinks(a)power-net.net

3 2