From charles at thewybles.com Wed Jul 1 00:24:16 2009 From: charles at thewybles.com (Charles Wyble) Date: Tue, 30 Jun 2009 22:24:16 -0700 Subject: Nanog Webcast Equipment In-Reply-To: <4A4AE8BC.4050109@sandboxitsolutions.com> References: <4A4AE8BC.4050109@sandboxitsolutions.com> Message-ID: <4A4AF300.6030101@thewybles.com> > You can reply off-list if you wish. Would love to see replies and/or summary on list if possible. It's a somewhat complex problem, and there are many solutions out there. Having feedback on what was used and any feedback on it would be great! From KaeglerM at tessco.com Wed Jul 1 09:18:16 2009 From: KaeglerM at tessco.com (Kaegler, Mike) Date: Wed, 01 Jul 2009 10:18:16 -0400 Subject: Nanog Webcast Equipment In-Reply-To: <4A4AF300.6030101@thewybles.com> Message-ID: On 7/1/09 1:24 AM, "Charles Wyble" wrote: > Would love to see replies and/or summary on list if possible. Since theres interest, I'll share a multicast solution that has so far worked for us for internal use. (Abilene/Internet2 connected institutions may use this publically too.) After getting multicast working, we used a DV camera that our marketing team had (camcorders work too) and connected it via firewire to a laptop. We ran a product called Wirecast (we used MacOS, Wintel version is available too), which can switch between multiple video sources, static images, video files, and even presentation computers (signal is network-delivered) etc... And output simultaneously to several destinations which can include multicast and unicast addresses, with each stream at a different quality. We had to be sure quicktime was installed on the client machines, and we created a web page with the benefit of AC_Quicktime.js (google for it; you'll find a copy with full instructions) which allowed clients to subscribe to the "large" multicast feed. For remote sites with small links, one could provide a link to a smaller multicast feed. For clients who could not do multicast for whatever reason, the "small" multicast feed was subscribed to by an OSX server running the Quicktime Streaming Server (built-in). It retransmitted the video in unicast. (You have to do this by placing the SDP file in the "Movies/" directory of the server.) The wirecast license cost is $450 for the big one and theres a free demo. The number of viewers is limited by your network and user support infrastructure. All the other components we already owned. And, as any photography nerd will tell you, quality isn't a function of codec and bandwidth alone. A webcam produced a usable but unremarkable image. Using the Real Camera made a world of difference and made the stream look broadcast-quality. The opportunity to do a company-wide multicast hasn't come up yet, but we keep it in our back pocket. Company-wide testing went without a hitch. -porkchop -- Michael Kaegler, TESSCO Technologies: Engineering, 410 229 1295 Your wireless success, nothing less. http://www.tessco.com/ From tkapela at gmail.com Wed Jul 1 10:15:31 2009 From: tkapela at gmail.com (Anton Kapela) Date: Wed, 1 Jul 2009 11:15:31 -0400 Subject: Nanog Webcast Equipment In-Reply-To: <4A4AF300.6030101@thewybles.com> References: <4A4AE8BC.4050109@sandboxitsolutions.com> <4A4AF300.6030101@thewybles.com> Message-ID: <2e9d8ae50907010815u10c51569s9f5e5cc5acca48ef@mail.gmail.com> On Wed, Jul 1, 2009 at 1:24 AM, Charles Wyble wrote: > Would love to see replies and/or summary on list if possible. It's a > somewhat complex problem, and there are many solutions out there. Having > feedback on what was used and any feedback on it would be great! For the benefit of all, I'll jot a list of the "parts" that comprise the NANOG video rig. In actuality, there are three, sometimes four "rigs" (input->encoder->server/relay->viewer/listener chains) operating at NANOG in parallel. Primary Video Encoder -highish-end multi-core p4 desktop system -wirecast (http://www.telestream.net/wire-cast/overview.htm) for genlock- and sync-less video input mixing -prep'd and networked presenter laptop for feeding "VNC-like" screen-scrapes directly to the encoder system, the preferred method for acquiring slideware "video" (check the wirecast docs for the "presenter network transport" stuff) -s-vid/composite, direct-show interface compatible video ADC's (analog to digital converters--"capture cards," etc. direct-show is a "standard" way for userland apps to interface to video framebuffer sources, inputs, etc) -two ntsc cameras (using s-video baseband signals, over baluns for coax to UTP conversion) -two pan-tilt-zoom serially controlled "mounts" for said cameras (though the ones nanog uses today are integrated camera/ptz+planar actuators) -audio source from "house PA" system passed through small mixer for gain staging/gain control/rough tone control -standard 'sound card' for audio ADC (usually mono, 48khz sample rate) -serial ptz controller itself, with multiple "memory" positions (i.e push-button preset pan/tilt/zoom settings are issued to the cameras by the MERIT/NANOG video rig operator to follow Q/A sessions, speakers on stage/mics, etc) -svga to ntsc/s-vid scan converter -vga buffer/isolator with integrated amplifier and splitter (send video to both projectors, drive/equalize long-ish VGA analog cabling, isolate outputs from each other, and feed the input of the vga->ntsc scan converter) -more vga/utp baluns, etc -rs232/utp baluns/buffered isolators for ptz camera controls/ancillary device control Once inputs arrive at the encoder system, the operator selects transitions (fade/dissolve/blend/etc) and real-time mixes the presenter camera, the Q/A mic camera, drives and selects the PTZ to follow the speaking/questioning, and chooses when and how to overlay/superimpose/picture-in-picture the VGA scan converted signal vs. the "presenter network" source. The wirecast application does both the mixing, as well as encoding of "raw" YUV video into a mpeg4 h.264 output stream. We usually configure the wirecast "transport" output as a pair of RTP streams, one carrying audio, the other video. These RTP streams 'land' on a RTP->RTSP controlled gateway (i.e. what we call "quicktime" stream on the nanog webpage). Alongside this mp4/rtp stream, we'll typically configure a windows media 9 a/v stream, using MMS and ASF wrappers/transports. A windows media relay server at MERIT or I2 (I forget which) provides viewers a place to connect to the "windows media" stream. Secondary Video Encoder -average p4 laptop -usb interface ntsc s-vid ADC/capture device, supported via directshow software library -wirecast or real producer pro, somtimes windows media encoder -given single input from presenter camera, typically, and audio feed from hotel/building PA system -records to local disk (external USB attached disk, etc) -intended for "backup" archival meeting video in the the case of the primary system failing, crashing, etc. Primary Audio-Only Encoder -average $anything laptop -usb or built in ADC for PA audio input -Winamp + DSP plugin using win32 LAME library for mpeg1 layer 3 audio encoding -DSP plugin sends shoutcast stream to icecast/shoutcast relay server $somewhere (iirc, Tim Pozar is involved with this platform, he may be able to provide more details). -Usually target a mono, 22.05Khz, 24 kbit/sec stream profile. The goal is to make the audio program, at least, accessible to V.whatever users on POTS. Occasional "HD lite" Video Encoder -average p4/p3 laptop -firewire input card/port -Canon HV20/30 HDV camera (using on-camera audio input from house PA system, to preserve a/v sync) -DVTS or VLC acting as "firewire" mpeg2 transport stream relay, sending the raw ~25 mbit HDV mpeg2 stream over IP/UDP to an off-network transcoder system -VLC running on a linux 2.6.x 8-core system (of which ~half end up idle), transcoding mpeg2 a/v into a h.264 video/mp4 AAC stream, ~1 mbit/sec -Stream is relayed to viewers via external VLC acting as a tcp "tee" - i.e. raw mp2 transport stream over http/tcp (very much a "yea, it works, not a specification" way to simply toss raw mp2ts bitstream over the internets) This results in a 1440x1088 (non-square pixels, 16:9 display aspect ratio, however) video stream at 30 progressive frames/sec, usually with ~64kbits allocated to mpeg4 AAC monaural audio, 48 khz sample rate. Conference talking-head video fits well into a h.264 stream in this case due to the use of a "long Group of Pictures" in the VLC/h264 encoder configuration. We typically set the GOP anywhere from 90 to 100 frames, meaning that we can allocate lots more bits to the Keyframe (making it 'less blocky), then using the remaining bits of the GOP to signal predicted (ie. delta) frames. This is perhaps the most tricky of the four encoder rigs to "get right" given the degrees of freedom that VLC provides for h.264 encoding. However, feedback has been positive even with it's limited appearance (and lack of slide input, Q/A mic coverage, etc). HTH, -Tk From llynch at civil-tongue.net Wed Jul 1 11:12:46 2009 From: llynch at civil-tongue.net (Lucy Lynch) Date: Wed, 1 Jul 2009 09:12:46 -0700 (PDT) Subject: ISOC Fellowship to the IETF Message-ID: All - Please forward this on to anyone you think may be interested in this sponsored opportunity to attend the IETF. Thanks - - Lucy ************************** Dear Colleagues, The Internet Society has announced that it is seeking applications for the next round of the ISOC Fellowship to the IETF program, part of its Future Internet Leaders program (www.isoc.org/leaders). The program offers engineers from developing countries fellowships that fund the cost of attending an Internet Engineering Task Force (IETF) meeting. As you know, the IETF is the Internet's premier standards-making body, responsible for the development of protocols used in IP-based networks. IETF participants represent an international community of network designers, operators, vendors, and researchers involved in the technical operation of the Internet and the continuing evolution of Internet architecture. Fellowships will be awarded through a competitive application process. The Internet Society is currently accepting fellowship applications for the next two IETF meetings: * IETF 76 being held in Hiroshima, Japan, 8-13 November 2009 * IETF 77 being held in Anaheim, USA, 21-26 March 2010 Up to six fellowships will be awarded for each IETF meeting. Full details on the ISOC Fellowship to the IETF, including how to apply, are located on the ISOC website at : http://www.isoc.org/educpillar/fellowship Fellowship applications for both IETF meetings are due by 31 July 2009. The Internet Society formally launched the ISOC Fellowship to the IETF program in January 2007 after successfully piloting the program during 2006 at IETF 66 in Montreal and IETF 67 in San Diego. Forty seven individuals from 29 countries have participated in the program since its inception. I encourage you to pass information about this program to individuals involved in your regional operators' groups that have a keen interest in the Internet standardisation activities of the IETF. You also may consider being a reference for the applicant. If you have questions, please do not hesiate to contact Connie Kendig or Mirjam Kuehne . Kind Regards, Connie J Kendig ISOC From rs at seastrom.com Wed Jul 1 12:12:42 2009 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 01 Jul 2009 13:12:42 -0400 Subject: Telephones for Noisy Data Centers In-Reply-To: <4A39C2AD.9000503@west.net> (Jay Hennigan's message of "Wed, 17 Jun 2009 21:29:33 -0700") References: <1245288718.6350.516.camel@mike-desktop> <4A39C2AD.9000503@west.net> Message-ID: <86vdmc9vjp.fsf@seastrom.com> Jay Hennigan writes: > Replace microphone element with noise-canceling microphone. Best one > is Roanwell Confidencer available from Mike Sandman, Graybar, etc. > Also good is Walker - Clarity NoiseCensor or Allen-Tel GB117 > (available from Graybar). +1 on the Confidencer - back when I worked for a trading firm, these +were standard issue on all phones on the floor. They work great. -r From jay at west.net Wed Jul 1 12:25:33 2009 From: jay at west.net (Jay Hennigan) Date: Wed, 01 Jul 2009 10:25:33 -0700 Subject: Telephones for Noisy Data Centers In-Reply-To: <86vdmc9vjp.fsf@seastrom.com> References: <1245288718.6350.516.camel@mike-desktop> <4A39C2AD.9000503@west.net> <86vdmc9vjp.fsf@seastrom.com> Message-ID: <4A4B9C0D.8000207@west.net> Robert E. Seastrom wrote: > Jay Hennigan writes: > >> Replace microphone element with noise-canceling microphone. Best one >> is Roanwell Confidencer available from Mike Sandman, Graybar, etc. >> Also good is Walker - Clarity NoiseCensor or Allen-Tel GB117 >> (available from Graybar). > > +1 on the Confidencer - back when I worked for a trading firm, these > +were standard issue on all phones on the floor. They work great. Indeed. The other solutions work great for a single user on a cellular phone, but I prefer a plain old wired telephone with a handset for the emergency phone at a data center. It's usable by anyone. Ever try handing your bluetooth headset with custom earmold to the electrician working on the UPS? Data centers tend to be noisy in more than just the acoustic spectrum, mobile reception often isn't the greatest. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From tkapela at gmail.com Wed Jul 1 13:59:47 2009 From: tkapela at gmail.com (Anton Kapela) Date: Wed, 1 Jul 2009 14:59:47 -0400 Subject: Telephones for Noisy Data Centers In-Reply-To: <4A4B9C0D.8000207@west.net> References: <1245288718.6350.516.camel@mike-desktop> <4A39C2AD.9000503@west.net> <86vdmc9vjp.fsf@seastrom.com> <4A4B9C0D.8000207@west.net> Message-ID: <2e9d8ae50907011159t243e95d4h1ebb200b0c09176d@mail.gmail.com> List, On Wed, Jul 1, 2009 at 1:25 PM, Jay Hennigan wrote: [snip] > emergency phone at a data center. ?It's usable by anyone. ?Ever try handing > your bluetooth headset with custom earmold to the electrician working on the > UPS? > > Data centers tend to be noisy in more than just the acoustic spectrum, > mobile reception often isn't the greatest. I wanted to mention that, surprisingly, the cisco 7921 wifi** voip handset (skinny only, so far...), in both g711 and g722 wideband mode (i.e. intra facility paging, noc/colo dialog, etc) has yielded simply amazing results where I've deployed or tried it within colo environments. Perhaps it's the noise canceler within the phone or some white noise-reducing aspect of g722 itself--whatever the reason, results are simply excellent. When the call is within the 'wideband capable' call manager domain, even better results seem to occur (at least that's what staff tell me...). Imagine calling your colo team and not having to repeat yourself due to noise or low-fidelity. Too bad we can't transport this (g722) over the PSTN; perhaps we'd have fewer "oops, I thought you said XYZ should be power-cycled!" experiences with them driving "remote hands" around. -Tk **In colos where I've had the chance to install .11g+.11a WIFI for customer and casual access, the coverage invariably ends up being quite good (stash enough AP1231's on 'clean' spectrum, anything works) -- but YMMV, no warranties, etc. From ilopezlists at sandboxitsolutions.com Wed Jul 1 23:46:42 2009 From: ilopezlists at sandboxitsolutions.com (Israel Lopez-LISTS) Date: Wed, 01 Jul 2009 21:46:42 -0700 Subject: Nanog Webcast Equipment In-Reply-To: <2e9d8ae50907010815u10c51569s9f5e5cc5acca48ef@mail.gmail.com> References: <4A4AE8BC.4050109@sandboxitsolutions.com> <4A4AF300.6030101@thewybles.com> <2e9d8ae50907010815u10c51569s9f5e5cc5acca48ef@mail.gmail.com> Message-ID: <4A4C3BB2.8040103@sandboxitsolutions.com> Thanks to everyone for commenting on this issue. It's shed light on what it would take to put on a bitchin' live show. For now we are going to do our best with what we have, run the pilot and take it from there. If people are interested about watching the live event watch this space: http://www.uuasc.org/oc.html Thanks again! -Israel From scott at doc.net.au Thu Jul 2 01:15:42 2009 From: scott at doc.net.au (Scott Howard) Date: Wed, 1 Jul 2009 23:15:42 -0700 Subject: Level 3 - "legacy" Wiltel/Looking Glass bandwidth Message-ID: We're looking at getting connectivity via Level 3 in a particular datacenter, but we're being told that it's "legacy Wiltel/Looking Glass" rather than "true" Level 3. Given that both of these acquisitions occurred years ago should I be worried, or is this "legacy" connectivity the same as L3 at any other datacenter? Scott. From drais at icantclick.org Thu Jul 2 08:18:02 2009 From: drais at icantclick.org (david raistrick) Date: Thu, 2 Jul 2009 09:18:02 -0400 (EDT) Subject: Level 3 - "legacy" Wiltel/Looking Glass bandwidth In-Reply-To: References: Message-ID: On Wed, 1 Jul 2009, Scott Howard wrote: > We're looking at getting connectivity via Level 3 in a particular > datacenter, but we're being told that it's "legacy Wiltel/Looking Glass" > rather than "true" Level 3. > > Given that both of these acquisitions occurred years ago should I be > worried, or is this "legacy" connectivity the same as L3 at any other > datacenter? As recently as a year ago, I had circuit issues in a L3 gateway facility (-not- an aquisition facility). It took 8 hours, and a VP level escalation to get resolved. The excuse that -every- tech save the last one gave? "we don't have access to some of the legacy [wiltel] equipment in the path, we can't diagnose further" YMMV, etc etc etc. But full integration may still be far from complete... [full disclosure: L3's purchase of Wiltel, then Telcove and Progress, destroyed my formerly reasonable opinion of L3 as they suddenly became the monopoly player in my town and were completely unable to deliver or maintain anything. later issues in L3's own Gateway facilities further enforced my low opinion of them] --- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From george at montco.net Thu Jul 2 09:47:15 2009 From: george at montco.net (George Carey) Date: Thu, 02 Jul 2009 10:47:15 -0400 Subject: Level 3 - =?iso-8859-1?Q?=22legacy=22?= Wiltel/Looking Glass bandwidth In-Reply-To: References: Message-ID: <20090702144715.16537.qmail@duff.careygraphics.net> As a Level 3 customer who had connectivity to some legacy Wiltel equipment I can also attest that service levels were pretty bad following that merger. We had a few memorable outages where escalations were necessary to get things resolved and folks familiar with the equipment were hard to find. In meeting with our account team we were able to get them to agree to roll us off the old gear which was really inadequate anyway for the purpose which happened to be an Option A MPLS NNI. It took them a long time to get that done but since then I would say that service levels have returned to the normal albeit somewhat less than desirable levels. We have had relatively few problems with our vanilla transit connections though. The same goes for some long haul that they inherited with the Broadwing acquisition. There were some glitches with some of the fiber grooming they did a while back but that seems to have passed. I also seem to be receiving less maintenance notifications overall from Level 3 as a general trend. Hope it continues. George From jml at packetpimp.org Thu Jul 2 09:57:06 2009 From: jml at packetpimp.org (Jason LeBlanc) Date: Thu, 02 Jul 2009 10:57:06 -0400 Subject: Level 3 - "legacy" Wiltel/Looking Glass bandwidth In-Reply-To: <20090702144715.16537.qmail@duff.careygraphics.net> References: <20090702144715.16537.qmail@duff.careygraphics.net> Message-ID: <4A4CCAC2.9050008@packetpimp.org> We're not very happy with Level3 anymore either, terrible support, no RFO is ever given, tickets are closed with no explanation at all. They bought so many providers close together that they have a lot of work to do to integrate everything into a workable set of products. George Carey wrote: > As a Level 3 customer who had connectivity to some legacy Wiltel > equipment I can also attest that service levels were pretty bad > following that merger. We had a few memorable outages where > escalations were necessary to get things resolved and folks familiar > with the equipment were hard to find. In meeting with our account team > we were able to get them to agree to roll us off the old gear which > was really inadequate anyway for the purpose which happened to be an > Option A MPLS NNI. It took them a long time to get that done but since > then I would say that service levels have returned to the normal > albeit somewhat less than desirable levels. > We have had relatively few problems with our vanilla transit > connections though. The same goes for some long haul that they > inherited with the Broadwing acquisition. There were some glitches > with some of the fiber grooming they did a while back but that seems > to have passed. > I also seem to be receiving less maintenance notifications overall > from Level 3 as a general trend. Hope it continues. > > George > From dhubbard at dino.hostasaurus.com Thu Jul 2 10:01:26 2009 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Thu, 2 Jul 2009 11:01:26 -0400 Subject: Level 3 - "legacy" Wiltel/Looking Glass bandwidth Message-ID: From: nanog at nanog.org > > We're not very happy with Level3 anymore either, terrible support, no > RFO is ever given, tickets are closed with no explanation at > all. They > bought so many providers close together that they have a lot > of work to > do to integrate everything into a workable set of products. Haven't had any support issues, but we've had a billing dispute that's been going back and forth for 14 months now, yes, months, and during that time we've gone through three different sales reps, the newest one brought on more than three months ago and I've yet to hear from the guy. Good times... David From markk at arin.net Thu Jul 2 10:06:44 2009 From: markk at arin.net (Mark Kosters) Date: Thu, 2 Jul 2009 11:06:44 -0400 Subject: ARIN and DNSSEC Message-ID: <20090702150644.GB12635@arin.net> Hi ARIN is now signing the /8 zones that it is authoritative for (eg 192.in-addr.arpa, etc). This the phase two of a three-phase process. Given that in-addr.arpa is not yet signed, we have published a list of trust anchors that you can download to configure on your local recursive resolvers. Additional details are at http://www.arin.net/about_us/dnssec/ Regards, Mark Kosters ARIN CTO From alex at blastro.com Thu Jul 2 10:22:55 2009 From: alex at blastro.com (Alex Thurlow) Date: Thu, 02 Jul 2009 10:22:55 -0500 Subject: Level 3 - "legacy" Wiltel/Looking Glass bandwidth In-Reply-To: References: Message-ID: <4A4CD0CF.8020904@blastro.com> We were a former Wiltel customer that was bought out by Level 3. Wiltel service had been great, and then as soon as level 3 took over, things went downhill. We had GigE service, and wanted another line, but Level 3 said they didn't want to sell any more ports on Wiltel gear. We also had serious problems even when we tried to disconnect. They didn't have access to any of the Wiltel records, so they couldn't even tell who had ordered what. Big mess overall. I'm not going to be working with Level 3 anymore if I can avoid it, and I definitely wouldn't get in on legacy Wiltel stuff under Level 3. Alex Thurlow Blastro Networks http://www.blastro.com http://www.roxwel.com http://www.yallwire.com On 7/2/2009 10:01 AM, David Hubbard wrote: > From: nanog at nanog.org > >> We're not very happy with Level3 anymore either, terrible support, no >> RFO is ever given, tickets are closed with no explanation at >> all. They >> bought so many providers close together that they have a lot >> of work to >> do to integrate everything into a workable set of products. >> > > Haven't had any support issues, but we've had a billing > dispute that's been going back and forth for 14 months now, > yes, months, and during that time we've gone through three > different sales reps, the newest one brought on more than > three months ago and I've yet to hear from the guy. > > Good times... > > David > > From michaelfox100 at gmail.com Thu Jul 2 11:31:55 2009 From: michaelfox100 at gmail.com (Michael Fox) Date: Thu, 2 Jul 2009 11:31:55 -0500 Subject: AT&T ANIRA issues? Message-ID: Is anyone experiencing AT&T issues with their ANIRA service. We are getting a vague "infrastructure issues" answer from AT&T. This is affecting us nationwide. Michael From will at loopfree.net Thu Jul 2 11:38:23 2009 From: will at loopfree.net (Will Orton) Date: Thu, 2 Jul 2009 09:38:23 -0700 Subject: Level 3 - "legacy" Wiltel/Looking Glass bandwidth In-Reply-To: References: Message-ID: <20090702163823.GA26674@loopfree.net> We have an old Wiltel DS3 homed from their Anaheim POP... all traffic that's not going to destinations on the old 7911 backbone seems to be backhauled to Level3 in San Jose before getting anywhere else, like so: 1 (internal) 2 (internal) 3 (internal) 4 anhmca1wcx1-atm10-0-0.wcg.net (64.200.142.169) 8.017 ms 8.596 ms 8.138 ms 5 anhmca1wcx3-oc48.wcg.net (64.200.143.65) 9.325 ms 8.056 ms 9.485 ms 6 64.200.249.122 (64.200.249.122) 79.108 ms 251.438 ms 222.596 ms 7 64.200.249.142 (64.200.249.142) 16.357 ms 16.167 ms 17.004 ms 8 te-3-2-70.car4.SanJose1.Level3.net (4.68.110.25) 12.568 ms 13.195 ms 13.384 ms So they don't seem to interconnect 7911 and 3356 in Los Angeles. We complained about this a year ago and they basically said, "tough, you bought IP transit, we're giving you IP transit". Anyway, so in the meantime we bougt a new gig-e to 3356 in San Jose... 1 (internal) 2 (internal) 3 (internal) 4 (internal) 5 ge-x-x.car4.SanJose1.Level3.net (4.71.x.x) 9.063 ms 7.780 ms 8.460 ms So it almost looks like my gig-e in San Jose is off the same router they backhaul 7911/Anaheim via. I wouldn't take a new connection to 7911 unless you're okay with this sort of thing. Performance has been fine other than the 5-10ms of extra latency, but the asthetics bug me more than anything. If they communicated more about what they're doing on the 7911 net and what the PLAN is for transitioning things, I'd be happier. But it's been this way for years now so we're just disconencting the old one, which is probably what they're waiting for everyone to do rather than really merge the networks. -Will On Wed, Jul 01, 2009 at 11:15:42PM -0700, Scott Howard wrote: > Date: Wed, 1 Jul 2009 23:15:42 -0700 > Subject: Level 3 - "legacy" Wiltel/Looking Glass bandwidth > From: Scott Howard > To: nanog at nanog.org > > We're looking at getting connectivity via Level 3 in a particular > datacenter, but we're being told that it's "legacy Wiltel/Looking Glass" > rather than "true" Level 3. > > Given that both of these acquisitions occurred years ago should I be > worried, or is this "legacy" connectivity the same as L3 at any other > datacenter? > > Scott. From eric.nowland at wyoming.com Thu Jul 2 12:21:21 2009 From: eric.nowland at wyoming.com (Eric Nowland, Wyoming.com) Date: Thu, 02 Jul 2009 11:21:21 -0600 Subject: Level 3 - "legacy" Wiltel/Looking Glass bandwidth In-Reply-To: <20090702163823.GA26674@loopfree.net> References: <20090702163823.GA26674@loopfree.net> Message-ID: <4A4CEC91.3070600@wyoming.com> Will Orton wrote: > We have an old Wiltel DS3 homed from their Anaheim POP... all traffic that's > not going to destinations on the old 7911 backbone seems to be backhauled to > Level3 in San Jose before getting anywhere else, like so: > > 1 (internal) > 2 (internal) > 3 (internal) > 4 anhmca1wcx1-atm10-0-0.wcg.net (64.200.142.169) 8.017 ms 8.596 ms 8.138 ms > 5 anhmca1wcx3-oc48.wcg.net (64.200.143.65) 9.325 ms 8.056 ms 9.485 ms > 6 64.200.249.122 (64.200.249.122) 79.108 ms 251.438 ms 222.596 ms > 7 64.200.249.142 (64.200.249.142) 16.357 ms 16.167 ms 17.004 ms > 8 te-3-2-70.car4.SanJose1.Level3.net (4.68.110.25) 12.568 ms 13.195 ms 13.384 ms > > So they don't seem to interconnect 7911 and 3356 in Los Angeles. We complained > about this a year ago and they basically said, "tough, you bought IP transit, > we're giving you IP transit". > > Anyway, so in the meantime we bougt a new gig-e to 3356 in San Jose... > > > 1 (internal) > 2 (internal) > 3 (internal) > 4 (internal) > 5 ge-x-x.car4.SanJose1.Level3.net (4.71.x.x) 9.063 ms 7.780 ms 8.460 ms > > We have had the same issues with the Broadwing network. Our OC-3 connections are in Wyoming and they lugged everything through Salt Lake and then to San Jose adding about 30 - 50 ms. We placed orders with Level 3 to move them onto the Level 3 POP's last year and so far we have one of them up that they finished last week. > So it almost looks like my gig-e in San Jose is off the same router they > backhaul 7911/Anaheim via. > > I wouldn't take a new connection to 7911 unless you're okay with this sort of > thing. Performance has been fine other than the 5-10ms of extra latency, but the > asthetics bug me more than anything. If they communicated more about what > they're doing on the 7911 net and what the PLAN is for transitioning things, I'd > be happier. But it's been this way for years now so we're just disconencting the > old one, which is probably what they're waiting for everyone to do rather than > really merge the networks. > > -Will > > > On Wed, Jul 01, 2009 at 11:15:42PM -0700, Scott Howard wrote: > >> Date: Wed, 1 Jul 2009 23:15:42 -0700 >> Subject: Level 3 - "legacy" Wiltel/Looking Glass bandwidth >> From: Scott Howard >> To: nanog at nanog.org >> >> We're looking at getting connectivity via Level 3 in a particular >> datacenter, but we're being told that it's "legacy Wiltel/Looking Glass" >> rather than "true" Level 3. >> >> Given that both of these acquisitions occurred years ago should I be >> worried, or is this "legacy" connectivity the same as L3 at any other >> datacenter? >> >> Scott. >> > > > We have also had the fun of the musical sales reps as we are on our 4th one since they took of Broadwing... Thanks Eric Nowland Sr Network Engineer Cerento/Wyoming.com From deepak at ai.net Thu Jul 2 13:50:17 2009 From: deepak at ai.net (Deepak Jain) Date: Thu, 2 Jul 2009 14:50:17 -0400 Subject: Level 3 (was: "legacy" Wiltel/Looking Glass bandwidth) In-Reply-To: <4A4CEC91.3070600@wyoming.com> References: <20090702163823.GA26674@loopfree.net> <4A4CEC91.3070600@wyoming.com> Message-ID: Without continuing the L3 pile-on, one can easily glean from their public filings that they have never properly filled out their management depth in acquisition absorption and/or sufficiently empowered those folks. The billions in revenue lost from acquisitions like Genuity and others have told this story more than once. L3 is not alone in this. Worldcomm's failure to integrate acquisitions led to a much larger operational cash need than VZ has shown for the same assets (verio, lots of other names here). This is because VZ understands how traditional businesses acquire others, better, in my opinion. Unfortunately, L3 has shown little interest in making the "real world, tough business" cuts in heads and absorbing the real (internal) pain of acquisitions and seems to have a pretty laissez-faire attitude towards its customers, even at its senior management levels (Cxx). I think this will be (and has been) the biggest problem for them. Even a possible merger/JV with Sprint may not be sufficient to solve that. Their resolution of billing disputes is much more typical of WCOM than VZ. They are a big fish in lots, and lots, of markets. They enjoy being able to dictate pricing in them. IMO, however, they don't have the maturity of (say, AT&T or others) to take that big fish status and leave you still happy with the service. (colloquially: if [good companies] are going to take advantage, at least they don't make it more painful than necessary). Operationally, where you have options (because of pricing, locality, etc) it's long-term good to support competitors, diversity in connectivity, etc. History has shown time and time again that when an industry consolidates a lot of business with a certain vendor, bad things can and do occur. Deepak Jain AiNET From sronan at fattoc.com Thu Jul 2 14:20:46 2009 From: sronan at fattoc.com (Shane Ronan) Date: Thu, 2 Jul 2009 15:20:46 -0400 Subject: Level 3 (was: "legacy" Wiltel/Looking Glass bandwidth) In-Reply-To: References: <20090702163823.GA26674@loopfree.net> <4A4CEC91.3070600@wyoming.com> Message-ID: I could not agree with the points below more. Prior to the mergers, I had multiple services each with Looking Glass, Wiltel and Broadwing and Level3. After Level3's round of acquisitions the service level for all four of them went way down. I've had the experience of not being able to resolve issues with Wiltel circuits because there was no techs available who could access the gear, been told they no longer wished to provide me with a Type 2 service sold to me by Looking Glass or Broadwing, and had billing and implementation issues that have lasted almost two years with Level3, because they started moving services from one billing system to another. Given that Level3's prices are usually not even close to competitive with solutions provided by other providers, I would suggest that people look elsewhere for reliable, reasonably priced services. Shane On Jul 2, 2009, at 2:50 PM, Deepak Jain wrote: > > Without continuing the L3 pile-on, one can easily glean from their > public filings that they have never properly filled out their > management depth in acquisition absorption and/or sufficiently > empowered those folks. The billions in revenue lost from > acquisitions like Genuity and others have told this story more than > once. > > L3 is not alone in this. Worldcomm's failure to integrate > acquisitions led to a much larger operational cash need than VZ has > shown for the same assets (verio, lots of other names here). This is > because VZ understands how traditional businesses acquire others, > better, in my opinion. > > Unfortunately, L3 has shown little interest in making the "real > world, tough business" cuts in heads and absorbing the real > (internal) pain of acquisitions and seems to have a pretty laissez- > faire attitude towards its customers, even at its senior management > levels (Cxx). I think this will be (and has been) the biggest > problem for them. Even a possible merger/JV with Sprint may not be > sufficient to solve that. Their resolution of billing disputes is > much more typical of WCOM than VZ. > > They are a big fish in lots, and lots, of markets. They enjoy being > able to dictate pricing in them. IMO, however, they don't have the > maturity of (say, AT&T or others) to take that big fish status and > leave you still happy with the service. (colloquially: if [good > companies] are going to take advantage, at least they don't make it > more painful than necessary). > > Operationally, where you have options (because of pricing, locality, > etc) it's long-term good to support competitors, diversity in > connectivity, etc. History has shown time and time again that when > an industry consolidates a lot of business with a certain vendor, > bad things can and do occur. > > Deepak Jain > AiNET > > > From adam.lafountain at googlemail.com Thu Jul 2 17:48:44 2009 From: adam.lafountain at googlemail.com (Adam LaFountain) Date: Thu, 2 Jul 2009 15:48:44 -0700 Subject: Level 3 (was: "legacy" Wiltel/Looking Glass bandwidth) Message-ID: > > >> Without continuing the L3 pile-on, one can easily glean from their public >> filings that they have never properly filled out their management depth in >> acquisition absorption and/or sufficiently empowered those folks. The >> billions in revenue lost from acquisitions like Genuity and others have told >> this story more than once. >> >> L3 is not alone in this. Worldcomm's failure to integrate acquisitions led >> to a much larger operational cash need than VZ has shown for the same assets >> (verio, lots of other names here). This is because VZ understands how >> traditional businesses acquire others, better, in my opinion. >> >> Unfortunately, L3 has shown little interest in making the "real world, >> tough business" cuts in heads and absorbing the real (internal) pain of >> acquisitions and seems to have a pretty laissez-faire attitude towards its >> customers, even at its senior management levels (Cxx). I think this will be >> (and has been) the biggest problem for them. Even a possible merger/JV with >> Sprint may not be sufficient to solve that. Their resolution of billing >> disputes is much more typical of WCOM than VZ. >> >> They are a big fish in lots, and lots, of markets. They enjoy being able >> to dictate pricing in them. IMO, however, they don't have the maturity of >> (say, AT&T or others) to take that big fish status and leave you still happy >> with the service. (colloquially: if [good companies] are going to take >> advantage, at least they don't make it more painful than necessary). >> >> Operationally, where you have options (because of pricing, locality, etc) >> it's long-term good to support competitors, diversity in connectivity, etc. >> History has shown time and time again that when an industry consolidates a >> lot of business with a certain vendor, bad things can and do occur. >> >> Deepak Jain >> AiNET >> > Not to mention they have also been the subject of several class action suits for this very reason regarding the integration of acquired assets, or lack thereof: http://finance.yahoo.com/news/The-Shuman-Law-Firm-Announces-pz-14325037.html?x=1 http://finance.yahoo.com/news/The-Pomerantz-Firm-Charges-pz-14430251.html?x=1 http://biz.yahoo.com/iw/090330/0486160.html Adam LaFountain From morrowc.lists at gmail.com Thu Jul 2 21:01:20 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 2 Jul 2009 22:01:20 -0400 Subject: ARIN and DNSSEC In-Reply-To: <20090702150644.GB12635@arin.net> References: <20090702150644.GB12635@arin.net> Message-ID: <75cb24520907021901t5317eb0yf135096bb15f46d4@mail.gmail.com> On Thu, Jul 2, 2009 at 11:06 AM, Mark Kosters wrote: > Hi > > ARIN is now signing the /8 zones that it is authoritative for (eg > 192.in-addr.arpa, etc). Thanks! (in case no one else mentioned it) -Chris > > This the phase two of a three-phase process. Given that in-addr.arpa is > not yet signed, we have published a list of trust anchors that you can > download to configure on your local recursive resolvers. > > Additional details are at http://www.arin.net/about_us/dnssec/ > > Regards, > Mark Kosters > ARIN CTO > > From randy at psg.com Thu Jul 2 22:21:36 2009 From: randy at psg.com (Randy Bush) Date: Fri, 03 Jul 2009 12:21:36 +0900 Subject: ARIN and DNSSEC In-Reply-To: <75cb24520907021901t5317eb0yf135096bb15f46d4@mail.gmail.com> References: <20090702150644.GB12635@arin.net> <75cb24520907021901t5317eb0yf135096bb15f46d4@mail.gmail.com> Message-ID: > On Thu, Jul 2, 2009 at 11:06 AM, Mark Kosters wrote: >> ARIN is now signing the /8 zones that it is authoritative for (eg >> 192.in-addr.arpa, etc). > Thanks! indeed! randy From timothy.arnold at uksolutions.co.uk Fri Jul 3 04:15:05 2009 From: timothy.arnold at uksolutions.co.uk (Timothy Arnold) Date: Fri, 3 Jul 2009 10:15:05 +0100 Subject: OT: Bringing Cisco equipment to US In-Reply-To: References: <9C25883F-4BCF-44BA-914E-8F41EA4394FB@hopcount.ca> Message-ID: > The courier will likely charge you less than a customs broker will for > a single item - the brokers are mainly used for large transactions. > While you're legally entitled to bring this equipment in carry-on > luggage, proving and authenticating your right can be a costly and > timely exercise. Jumping on the back of this thread, does anyone have any recommendations for suppliers of Cisco kit in the states? I don't fancy dealing with customs & international shipping. Thanks Tim Timothy Arnold Senior Engineer, Operations (Network, Security & Facilities Group), UKSolutions Telephone: 0845 004 1333, option 2 Email: timothy.arnold at uksolutions.co.uk Web: http://www.uksolutions.co.uk/ UKS Ltd, Birmingham Road, Studley, Warwickshire, B80 7BG Registered in England Number 3036806 This email must be read in conjunction with the legal & service notices on http://www.uksolutions.co.uk/disclaimer From darren at bolding.org Fri Jul 3 06:19:02 2009 From: darren at bolding.org (Darren Bolding) Date: Fri, 3 Jul 2009 04:19:02 -0700 Subject: Fire, Power loss at Fisher Plaza in Seattle Message-ID: <5a318d410907030419s4feae434o64ceec30a5affd4f@mail.gmail.com> Fisher Plaza, a self-styled carrier hotel in Seattle, and home to multiple datacenter and colocation providers, has had a major issue in one of its buildings late last night, early this morning. The best information I am aware of is that there was a failure in the main/generator transfer switch which resulted in a fire. The sprinkler system activated. From speaking to the fire battalion chief, I am under the impression that Seattle Fire did use water on the fire as well, but I am unsure of this. Given the failure location, generator power was not available, and cooling failed. UPS power to systems continued, and I can personally vouch that they held out for well over an hour. When we were able to access our equipment, ambient air temps were well over 100 degrees in the room our equipment is located in. At least some, if not many circuits were affected. Several large co-location providers and other datacenters are located in the facility, these facilities have no power. As this was the main/generator switch, and it is now highly damaged, the circuits in the area are damaged, and the entire area is doused in water, a rapid restoration of power does not seem likely. Fisher Plaza's phone numbers now result in fast-busy signals, so I have no recent update from them directly. Interestingly, this building is also the production studios for several Seattle TV and radio stations. There is no ETA for resolution. --D -- -- Darren Bolding -- -- darren at bolding.org -- From joe at disconformity.net Fri Jul 3 06:40:42 2009 From: joe at disconformity.net (Joe Richards) Date: Fri, 03 Jul 2009 04:40:42 -0700 Subject: Fire, Power loss at Fisher Plaza in Seattle In-Reply-To: <5a318d410907030419s4feae434o64ceec30a5affd4f@mail.gmail.com> References: <5a318d410907030419s4feae434o64ceec30a5affd4f@mail.gmail.com> Message-ID: <1246621242.7838.9.camel@nomad.disconformity.net> Multiple folks on Twitter who are in the area are reporting a 5-6 hour ETA. -Joe -- Joe Richards -- ipv4: http://www.disconformity.net [ 72.29.169.48/28 ] ipv6: http://ipv6.disconformity.net [ 2001:48c0:1001:1::/64 ] blog: http://www.mainlined.org From cidr-report at potaroo.net Fri Jul 3 07:00:10 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 3 Jul 2009 22:00:10 +1000 (EST) Subject: BGP Update Report Message-ID: <200907031200.n63C0A1E006829@bogong.rand.apnic.net> BGP Update Report Interval: 25-Jun-09 -to- 02-Jul-09 (8 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9198 86810 4.5% 299.3 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - AS4755 31871 1.6% 26.5 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 3 - AS17488 28227 1.4% 24.6 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 4 - AS10474 17094 0.9% 416.9 -- NETACTIVE 5 - AS22783 14699 0.8% 2449.8 -- WEBPOWER - WebPower, Inc. 6 - AS21104 14329 0.7% 1023.5 -- AM-NETSYS-AS Netsys JVC Autonomous System Yerevan, Armenia 7 - AS6389 14119 0.7% 3.3 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 8 - AS21491 12942 0.7% 479.3 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 9 - AS23700 12849 0.7% 31.0 -- BM-AS-ID PT. Broadband Multimedia, Tbk 10 - AS33783 11714 0.6% 90.8 -- EEPAD 11 - AS30890 11347 0.6% 27.1 -- EVOLVA Evolva Telecom 12 - AS47408 11043 0.6% 525.9 -- MANDARIN-AS Mandarin WIMAX Sicilia SpA 13 - AS30969 10906 0.6% 605.9 -- TAN-NET TransAfrica Networks 14 - AS4812 10307 0.5% 11.5 -- CHINANET-SH-AP China Telecom (Group) 15 - AS8452 8289 0.4% 8.6 -- TEDATA TEDATA 16 - AS1221 8218 0.4% 14.1 -- ASN-TELSTRA Telstra Pty Ltd 17 - AS4134 8065 0.4% 8.2 -- CHINANET-BACKBONE No.31,Jin-rong Street 18 - AS8151 7899 0.4% 5.4 -- Uninet S.A. de C.V. 19 - AS24863 7693 0.4% 8.8 -- LINKdotNET-AS 20 - AS5668 7672 0.4% 7.5 -- AS-5668 - CenturyTel Internet Holdings, Inc. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS22783 14699 0.8% 2449.8 -- WEBPOWER - WebPower, Inc. 2 - AS36616 5425 0.3% 1356.2 -- AGTLD - VeriSign Global Registry Services 3 - AS47640 1315 0.1% 1315.0 -- TRICOMPAS Tricomp Sp. z. o. o. 4 - AS21104 14329 0.7% 1023.5 -- AM-NETSYS-AS Netsys JVC Autonomous System Yerevan, Armenia 5 - AS29508 850 0.0% 850.0 -- TANAT-AS TANAT LLC 6 - AS41189 719 0.0% 719.0 -- ICONCEPT-AS iConcept 7 - AS37011 3721 0.2% 620.2 -- MSTARTEL-AS 8 - AS30969 10906 0.6% 605.9 -- TAN-NET TransAfrica Networks 9 - AS47408 11043 0.6% 525.9 -- MANDARIN-AS Mandarin WIMAX Sicilia SpA 10 - AS25546 4205 0.2% 525.6 -- BROOKLANDCOMP-AS Brookland Computer Services 11 - AS35400 2555 0.1% 511.0 -- MFIST Interregoinal Organization Network Technologies 12 - AS27653 2015 0.1% 503.8 -- Alpha Communications Network 13 - AS21491 12942 0.7% 479.3 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 14 - AS10474 17094 0.9% 416.9 -- NETACTIVE 15 - AS13403 415 0.0% 415.0 -- ALAWEB-INTERNET - ALAWEB Internet Services 16 - AS36975 403 0.0% 403.0 -- CBA-AS 17 - AS37083 403 0.0% 403.0 -- hiqos-as 18 - AS38136 764 0.0% 382.0 -- MBTELTRANSIT-BD MB TELECCOM LIMITED, INTERNET SERVICE PROVIDER 19 - AS33074 370 0.0% 370.0 -- ISC-NBO1 ISC, Nairobi, Kenya 20 - AS5050 5932 0.3% 348.9 -- PSC-EXT - Pittsburgh Supercomputing Center TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 95.59.8.0/23 10566 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - 95.59.2.0/23 10565 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 3 - 95.59.4.0/22 10565 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 4 - 92.46.244.0/23 10561 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 5 - 89.218.220.0/23 10561 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 6 - 89.218.218.0/23 10560 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 7 - 95.59.1.0/24 9892 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 8 - 88.204.221.0/24 9866 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 9 - 80.86.238.0/24 7170 0.3% AS21104 -- AM-NETSYS-AS Netsys JVC Autonomous System Yerevan, Armenia 10 - 80.86.239.0/24 6938 0.3% AS21104 -- AM-NETSYS-AS Netsys JVC Autonomous System Yerevan, Armenia 11 - 72.23.246.0/24 5834 0.3% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 12 - 205.246.203.0/24 5686 0.3% AS22783 -- WEBPOWER - WebPower, Inc. 13 - 63.163.66.0/24 5684 0.3% AS22783 -- WEBPOWER - WebPower, Inc. 14 - 65.113.57.0/24 5413 0.3% AS36616 -- AGTLD - VeriSign Global Registry Services 15 - 196.27.104.0/21 4399 0.2% AS30969 -- TAN-NET TransAfrica Networks 16 - 196.27.108.0/22 4383 0.2% AS30969 -- TAN-NET TransAfrica Networks 17 - 193.201.184.0/21 4156 0.2% AS25546 -- BROOKLANDCOMP-AS Brookland Computer Services 18 - 65.212.89.0/24 3311 0.2% AS22783 -- WEBPOWER - WebPower, Inc. 19 - 192.12.120.0/24 2596 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 20 - 90.150.0.0/24 2527 0.1% AS35400 -- MFIST Interregoinal Organization Network Technologies Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 3 07:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 3 Jul 2009 22:00:00 +1000 (EST) Subject: The Cidr Report Message-ID: <200907031200.n63C00FR006821@bogong.rand.apnic.net> This report has been generated at Fri Jul 3 21:13:55 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 26-06-09 295286 183129 27-06-09 295497 183044 28-06-09 295496 183041 29-06-09 295193 183133 30-06-09 295131 183378 01-07-09 295500 183533 02-07-09 295531 183261 03-07-09 295814 183377 AS Summary 31731 Number of ASes in routing system 13470 Number of ASes announcing only one prefix 4291 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 89737216 Largest address span announced by an AS (/32s) AS27064: DNIC-ASBLK-27032-27159 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 03Jul09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 295702 183220 112482 38.0% All ASes AS6389 4266 337 3929 92.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4291 1806 2485 57.9% TWTC - tw telecom holdings, inc. AS4766 1811 528 1283 70.8% KIXS-AS-KR Korea Telecom AS17488 1537 279 1258 81.8% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1213 193 1020 84.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1705 689 1016 59.6% AS-PAETEC-NET - PaeTec Communications, Inc. AS22773 1071 71 1000 93.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 1062 95 967 91.1% COVAD - Covad Communications Co. AS8151 1460 558 902 61.8% Uninet S.A. de C.V. AS19262 1017 235 782 76.9% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8452 994 272 722 72.6% TEDATA TEDATA AS18101 754 115 639 84.7% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS17908 684 57 627 91.7% TCISL Tata Communications AS6478 1206 617 589 48.8% ATT-INTERNET3 - AT&T WorldNet Services AS4804 681 109 572 84.0% MPX-AS Microplex PTY LTD AS9498 641 75 566 88.3% BBIL-AP BHARTI Airtel Ltd. AS7029 612 107 505 82.5% WINDSTREAM - Windstream Communications Inc AS11492 1122 619 503 44.8% CABLEONE - CABLE ONE, INC. AS17676 564 80 484 85.8% GIGAINFRA Softbank BB Corp. AS4808 651 170 481 73.9% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS22047 601 126 475 79.0% VTR BANDA ANCHA S.A. AS10620 920 457 463 50.3% TV Cable S.A. AS7018 1504 1048 456 30.3% ATT-INTERNET4 - AT&T WorldNet Services AS4134 977 530 447 45.8% CHINANET-BACKBONE No.31,Jin-rong Street AS24560 724 278 446 61.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS9443 521 82 439 84.3% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7545 830 414 416 50.1% TPG-INTERNET-AP TPG Internet Pty Ltd AS7011 984 570 414 42.1% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4668 693 285 408 58.9% LGNET-AS-KR LG CNS AS7303 573 165 408 71.2% Telecom Argentina S.A. Total 35669 10967 24702 69.3% Top 30 total Possible Bogus Routes 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 41.223.112.0/22 AS5713 SAIX-NET 41.223.176.0/22 AS36981 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.31.59.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.31.60.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 100.100.100.0/30 AS38676 AS33005-AS-KR wizsolution co.,Ltd 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.10.0/24 AS38236 121.50.13.0/24 AS38236 121.50.15.0/24 AS17625 BLAZENET-IN-AP BlazeNet's Network 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 137.0.0.0/13 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 158.222.5.0/24 AS21580 DIRCON - Direct Connect 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 168.253.0.0/16 AS13649 ASN-VINS - ViaWest 168.253.0.0/21 AS13649 ASN-VINS - ViaWest 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.132.58.0/24 AS20141 QUALITYTECH-SUW-300 - Quality Technology Services, LLC. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 193.33.148.0/23 AS30890 EVOLVA Evolva Telecom 193.104.229.0/26 AS34444 EUTELSAT-BACKBONE-AS EUTELSAT S.A. 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.5.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.19.0.0/24 AS3848 WORLDLINX-2 - WorldLinx Telecommunications, Inc. 199.114.0.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 ITCOMM - IT Communications 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.84.10.0/23 AS9308 CHINA-ABITCOOL Abitcool(China) Inc. 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.92.48.0/20 AS23704 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS2764 AAPT AAPT Limited 202.124.195.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.125.112.0/24 AS23674 MBL-AS-AP Micronet Broadband (Pvt) Ltd. 202.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.154.0/23 AS9583 SIFY-AS-IN Sify Limited 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.13.140.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.141.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.142.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.143.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.184.0/23 AS35967 204.13.186.0/23 AS35967 204.13.186.0/24 AS35967 204.13.187.0/24 AS35967 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.138.167.0/24 AS18990 AIRBAND-DALLAS - Airband Communications, Inc 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.151.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.158.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.177.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.178.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.88.0/21 AS36835 208.77.224.0/24 AS36835 208.77.225.0/24 AS36835 208.77.226.0/24 AS36835 208.77.227.0/24 AS36835 208.77.228.0/24 AS36835 208.77.229.0/24 AS36835 208.77.230.0/24 AS36835 208.77.231.0/24 AS36835 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.177.93.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 209.217.224.0/19 AS6130 AIS-WEST - American Internet Services, LLC. 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 213.181.70.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.80.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.81.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.82.0/23 AS17175 NSS-UK New Skies Satellites UK AS 213.181.82.0/24 AS17175 NSS-UK New Skies Satellites UK AS 213.181.83.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.84.0/22 AS17175 NSS-UK New Skies Satellites UK AS 213.181.84.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.85.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.86.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.87.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.88.0/21 AS17175 NSS-UK New Skies Satellites UK AS 213.181.88.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.89.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.90.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.91.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.92.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.93.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.94.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.95.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.163.152.0/22 AS7132 SBIS-AS - AT&T Internet Services 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.72.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.73.0/24 AS12491 IPPLANET-AS Gilat Satcom Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From smb at cs.columbia.edu Fri Jul 3 09:58:28 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Fri, 3 Jul 2009 10:58:28 -0400 Subject: ARIN and DNSSEC In-Reply-To: References: <20090702150644.GB12635@arin.net> <75cb24520907021901t5317eb0yf135096bb15f46d4@mail.gmail.com> Message-ID: <20090703105828.58616579@cs.columbia.edu> On Fri, 03 Jul 2009 12:21:36 +0900 Randy Bush wrote: > > On Thu, Jul 2, 2009 at 11:06 AM, Mark Kosters wrote: > >> ARIN is now signing the /8 zones that it is authoritative for (eg > >> 192.in-addr.arpa, etc). > > Thanks! > > indeed! > Wonderful! --Steve Bellovin, http://www.cs.columbia.edu/~smb From matthew at walster.org Fri Jul 3 11:03:16 2009 From: matthew at walster.org (Matthew Walster) Date: Fri, 3 Jul 2009 17:03:16 +0100 Subject: Wireless bridge In-Reply-To: <23ab01c9f07f$b7aa6480$26ff2d80$@com> References: <005c01c9f015$852ae490$8f80adb0$@com> <877585b00906180753s47617a64la780d7ac1f8c05ca@mail.gmail.com> <09ef01c9f02d$221f21f0$665d65d0$@com> <1245341463.1310.22.camel@legolas.orthanc.ca> <0e9401c9f033$24f4a160$6edde420$@com> <23ab01c9f07f$b7aa6480$26ff2d80$@com> Message-ID: 2009/6/19 Peter Boone > > - Get off the 2.4 GHz range. Move up to 5. As for licensed vs. unlicensed, > I'm getting mixed input. I'm fairly certain that if the price is right and > the frequency is 5GHz+, it won't be a factor. Also, I'll be very glad to > separate the bridge from the client access points so that allows for more > options. Every solution at this range can easily do 20+ Mbps so throughput > is no longer a factor. > It looks like your fresnel zone is 14ft (according to a previous poster) and you're currently using relatively low power radio waves. Have you considered using something like Free Space Optics? For under $100, you can build yourself a couple of RONJAs[1] and test out what the signal is going to be like - that runs at 10Mbit, and can stay in place as a backup once you then buy a FSO device from a proper manufacturer (MRV make some nice ones) and you're looking at 100Mbit for some money, 1000Mbit for quite a lot of money and 10000Mbit for "it would have been cheaper to lay fiber". I'd heartily recommend giving infra-red FSO a go, no Fresnel zone and it's essentially bridged ethernet - no funky routing required, though I would still set up OSPF or similar with it, to fail back to a slower link such as the RONJA. Matthew Walster [1] http://ronja.twibright.com/ From matthew at eeph.com Fri Jul 3 11:14:35 2009 From: matthew at eeph.com (Matthew Kaufman) Date: Fri, 03 Jul 2009 09:14:35 -0700 Subject: Wireless bridge In-Reply-To: References: <005c01c9f015$852ae490$8f80adb0$@com> <877585b00906180753s47617a64la780d7ac1f8c05ca@mail.gmail.com> <09ef01c9f02d$221f21f0$665d65d0$@com> <1245341463.1310.22.camel@legolas.orthanc.ca> <0e9401c9f033$24f4a160$6edde420$@com> <23ab01c9f07f$b7aa6480$26ff2d80$@com> Message-ID: <4A4E2E6B.5030307@eeph.com> Matthew Walster wrote: > I'd heartily recommend giving infra-red FSO a go, no Fresnel zone... A nitpick, but there's nothing special about infra-red that makes it not electromagnetic just like microwave. So there's still a Fresnel zone, only smaller in diameter. Also for this kind of link, 60 GHz gear is often cheaper and easier to deal with, so what I would recommend. Matthew Kaufman From jmamodio at gmail.com Fri Jul 3 11:54:57 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 3 Jul 2009 11:54:57 -0500 Subject: Wireless bridge In-Reply-To: <4A4E2E6B.5030307@eeph.com> References: <005c01c9f015$852ae490$8f80adb0$@com> <877585b00906180753s47617a64la780d7ac1f8c05ca@mail.gmail.com> <09ef01c9f02d$221f21f0$665d65d0$@com> <1245341463.1310.22.camel@legolas.orthanc.ca> <0e9401c9f033$24f4a160$6edde420$@com> <23ab01c9f07f$b7aa6480$26ff2d80$@com> <4A4E2E6B.5030307@eeph.com> Message-ID: <202705b0907030954v6855fa39p53fb17e559964eec@mail.gmail.com> > Also for this kind of link, 60 GHz gear is often cheaper and easier to deal > with, so what I would recommend. I'd also take a look at 60GHz, check http://www.bridgewave.com/, I believe they have some sort of promotion going on for 60/80GHz gear. My .02 From sethm at rollernet.us Fri Jul 3 12:00:46 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 03 Jul 2009 10:00:46 -0700 Subject: Fire, Power loss at Fisher Plaza in Seattle In-Reply-To: <5a318d410907030419s4feae434o64ceec30a5affd4f@mail.gmail.com> References: <5a318d410907030419s4feae434o64ceec30a5affd4f@mail.gmail.com> Message-ID: <4A4E393E.8090400@rollernet.us> Darren Bolding wrote: > > Interestingly, this building is also the production studios for several > Seattle TV and radio stations. > > There is no ETA for resolution. > Apparently it took authorize.net with it, too: http://twitter.com/authorizenet ~Seth From jesus_leung at ahm.honda.com Fri Jul 3 12:01:24 2009 From: jesus_leung at ahm.honda.com (jesus_leung at ahm.honda.com) Date: Fri, 3 Jul 2009 10:01:24 -0700 Subject: CN=Jesus Leung/OU=AHM/OU=AM/O=HONDA is out of the office. Message-ID: I will be out of the office starting 07/03/2009 and will not return until 07/09/2009. From dhubbard at dino.hostasaurus.com Fri Jul 3 12:05:16 2009 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Fri, 3 Jul 2009 13:05:16 -0400 Subject: Fire, Power loss at Fisher Plaza in Seattle Message-ID: From: Seth Mattinen [mailto:sethm at rollernet.us] > > Apparently it took authorize.net with it, too: > http://twitter.com/authorizenet > > ~Seth No technical explanation of course but it also took down their 'backup facility' according to them on twitter; I assume some bad routing/DNS if they do actually have a backup facility. Lots of online stores are offline right now because of this, and the holiday is unfortunately keeping those store owners from knowing they are not making sales right now. Life in ecommerce... David From joelja at bogus.com Fri Jul 3 12:14:33 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 03 Jul 2009 10:14:33 -0700 Subject: Wireless bridge In-Reply-To: <202705b0907030954v6855fa39p53fb17e559964eec@mail.gmail.com> References: <005c01c9f015$852ae490$8f80adb0$@com> <877585b00906180753s47617a64la780d7ac1f8c05ca@mail.gmail.com> <09ef01c9f02d$221f21f0$665d65d0$@com> <1245341463.1310.22.camel@legolas.orthanc.ca> <0e9401c9f033$24f4a160$6edde420$@com> <23ab01c9f07f$b7aa6480$26ff2d80$@com> <4A4E2E6B.5030307@eeph.com> <202705b0907030954v6855fa39p53fb17e559964eec@mail.gmail.com> Message-ID: <4A4E3C79.7090507@bogus.com> You've got to recall that the genesis of this is dicsussion was the replacement of a pair for open-wrtized linksys wrt-54g routers, which have 30mW 2.4ghz radios being used for an 800meter link... There are a vast continuum (both in terms of performance and cost) of solutions between that and a pair of 60ghz mm wave part 15 radios. joel Jorge Amodio wrote: >> Also for this kind of link, 60 GHz gear is often cheaper and easier to deal >> with, so what I would recommend. > > I'd also take a look at 60GHz, check http://www.bridgewave.com/, > I believe they have some sort of promotion going on for 60/80GHz gear. > > My .02 > From tomb at byrneit.net Fri Jul 3 12:20:35 2009 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Fri, 3 Jul 2009 10:20:35 -0700 Subject: Fire, Power loss at Fisher Plaza in Seattle In-Reply-To: References: Message-ID: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> This begs the question of what basic parameters should be for a "carrier hotel" or co-lo. Given that we're getting designated "Critical Infrastructure", we'd getter start coming up with some, or we'll have them defined for us. The old NEBS standards were too much of a straightjacket, but the current situation, where any buffoon who wants to can claim to be something they aren't (redundant and reliable) undermines the business of those who actually spend the money, and make the effort, to provide a true "carrier grade" co-lo. This is life in the current Internet: Overpromise, and Underdeliver. >-----Original Message----- >From: David Hubbard [mailto:dhubbard at dino.hostasaurus.com] >Sent: Friday, July 03, 2009 10:05 AM >To: NANOG list >Subject: RE: Fire, Power loss at Fisher Plaza in Seattle > >From: Seth Mattinen [mailto:sethm at rollernet.us] >> >> Apparently it took authorize.net with it, too: >> http://twitter.com/authorizenet >> >> ~Seth > >No technical explanation of course but it also took down >their 'backup facility' according to them on twitter; >I assume some bad routing/DNS if they do actually have >a backup facility. Lots of online stores are >offline right now because of this, and the holiday is >unfortunately keeping those store owners from knowing >they are not making sales right now. Life in ecommerce... > >David From sethm at rollernet.us Fri Jul 3 12:40:55 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 03 Jul 2009 10:40:55 -0700 Subject: Fire, Power loss at Fisher Plaza in Seattle In-Reply-To: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> Message-ID: <4A4E42A7.9020707@rollernet.us> Tomas L. Byrnes wrote: > This begs the question of what basic parameters should be for a "carrier > hotel" or co-lo. > > Given that we're getting designated "Critical Infrastructure", we'd > getter start coming up with some, or we'll have them defined for us. > > The old NEBS standards were too much of a straightjacket, but the > current situation, where any buffoon who wants to can claim to be > something they aren't (redundant and reliable) undermines the business > of those who actually spend the money, and make the effort, to provide a > true "carrier grade" co-lo. Absolutely. Then your pricing is so far out of whack with the apparent competition that it's hard to get customers when it appears one can get the same/better for far less. Me, personally, I just don't say things like "100% uptime" or claim to be a carrier-grade facility. But I think that scares people off when my competitors (and I've seen the insides of some of the horrid trash heaps they call a NOC) claim they do. > > This is life in the current Internet: Overpromise, and Underdeliver. > "Our flywheel systems are so failure-proof and thinking outside the box that we don't need a silly battery UPS that can cold-start!" I know outages and related discussion end up attracting the off-topic hammer here on NANOG, but I do find them interesting and worthwhile. ~Seth From cscora at apnic.net Fri Jul 3 13:12:21 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 4 Jul 2009 04:12:21 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200907031812.n63ICLRX016802@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 04 Jul, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 289924 Prefixes after maximum aggregation: 137398 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 143783 Total ASes present in the Internet Routing Table: 31638 Prefixes per ASN: 9.16 Origin-only ASes present in the Internet Routing Table: 27506 Origin ASes announcing only one prefix: 13385 Transit ASes present in the Internet Routing Table: 4132 Transit-only ASes present in the Internet Routing Table: 99 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 478 Unregistered ASNs in the Routing Table: 134 Number of 32-bit ASNs allocated by the RIRs: 193 Prefixes from 32-bit ASNs in the Routing Table: 65 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 345 Number of addresses announced to Internet: 2063493440 Equivalent to 122 /8s, 254 /16s and 105 /24s Percentage of available address space announced: 55.7 Percentage of allocated address space announced: 64.4 Percentage of available address space allocated: 86.4 Percentage of address space in use by end-sites: 78.1 Total number of prefixes smaller than registry allocations: 143430 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 69259 Total APNIC prefixes after maximum aggregation: 24587 APNIC Deaggregation factor: 2.82 Prefixes being announced from the APNIC address blocks: 68669 Unique aggregates announced from the APNIC address blocks: 31173 APNIC Region origin ASes present in the Internet Routing Table: 3691 APNIC Prefixes per ASN: 18.60 APNIC Region origin ASes announcing only one prefix: 1002 APNIC Region transit ASes present in the Internet Routing Table: 566 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 463130240 Equivalent to 27 /8s, 154 /16s and 206 /24s Percentage of available APNIC address space announced: 86.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 180/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 123352 Total ARIN prefixes after maximum aggregation: 65801 ARIN Deaggregation factor: 1.87 Prefixes being announced from the ARIN address blocks: 124082 Unique aggregates announced from the ARIN address blocks: 51892 ARIN Region origin ASes present in the Internet Routing Table: 13054 ARIN Prefixes per ASN: 9.51 ARIN Region origin ASes announcing only one prefix: 5015 ARIN Region transit ASes present in the Internet Routing Table: 1280 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 1009850048 Equivalent to 60 /8s, 49 /16s and 22 /24s Percentage of available ARIN address space announced: 194.2 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 66420 Total RIPE prefixes after maximum aggregation: 39205 RIPE Deaggregation factor: 1.69 Prefixes being announced from the RIPE address blocks: 66083 Unique aggregates announced from the RIPE address blocks: 44429 RIPE Region origin ASes present in the Internet Routing Table: 13245 RIPE Prefixes per ASN: 4.99 RIPE Region origin ASes announcing only one prefix: 6913 RIPE Region transit ASes present in the Internet Routing Table: 1987 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 22 Number of RIPE addresses announced to Internet: 496075456 Equivalent to 29 /8s, 145 /16s and 130 /24s Percentage of available RIPE address space announced: 105.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 24366 Total LACNIC prefixes after maximum aggregation: 5991 LACNIC Deaggregation factor: 4.07 Prefixes being announced from the LACNIC address blocks: 24217 Unique aggregates announced from the LACNIC address blocks: 13477 LACNIC Region origin ASes present in the Internet Routing Table: 1135 LACNIC Prefixes per ASN: 21.34 LACNIC Region origin ASes announcing only one prefix: 362 LACNIC Region transit ASes present in the Internet Routing Table: 187 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 21 Number of LACNIC addresses announced to Internet: 71888384 Equivalent to 4 /8s, 72 /16s and 238 /24s Percentage of available LACNIC address space announced: 71.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 6117 Total AfriNIC prefixes after maximum aggregation: 1492 AfriNIC Deaggregation factor: 4.10 Prefixes being announced from the AfriNIC address blocks: 6514 Unique aggregates announced from the AfriNIC address blocks: 2536 AfriNIC Region origin ASes present in the Internet Routing Table: 303 AfriNIC Prefixes per ASN: 21.50 AfriNIC Region origin ASes announcing only one prefix: 93 AfriNIC Region transit ASes present in the Internet Routing Table: 64 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 20174592 Equivalent to 1 /8s, 51 /16s and 215 /24s Percentage of available AfriNIC address space announced: 60.1 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1702 6934 405 Korea Telecom (KIX) 17488 1537 138 95 Hathway IP Over Cable Interne 4755 1213 308 144 TATA Communications formerly 9583 1132 91 548 Sify Limited 4134 977 17080 375 CHINANET-BACKBONE 7545 806 198 101 TPG Internet Pty Ltd 9829 797 611 14 BSNL National Internet Backbo 23577 783 34 666 Korea Telecom (ATM-MPLS) 18101 754 200 32 Reliance Infocom Ltd Internet 24560 724 230 172 Bharti Airtel Ltd. Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4266 3643 323 bellsouth.net, inc. 4323 1887 1047 384 Time Warner Telecom 1785 1705 714 139 PaeTec Communications, Inc. 7018 1503 5909 1046 AT&T WorldNet Services 20115 1396 1462 687 Charter Communications 2386 1267 671 921 AT&T Data Communications Serv 6478 1206 274 317 AT&T Worldnet Services 3356 1199 10961 443 Level 3 Communications, LLC 11492 1122 208 12 Cable One 22773 1071 2604 66 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 474 578 6 Uni2 Autonomous System 3292 457 1902 394 TDC Tele Danmark 702 429 1861 345 UUNET - Commercial IP service 30890 414 88 194 Evolva Telecom 35805 354 40 5 United Telecom of Georgia 8866 351 109 21 Bulgarian Telecommunication C 3301 347 1684 309 TeliaNet Sweden 3320 344 7067 300 Deutsche Telekom AG 3215 342 3049 107 France Telecom Transpac 29049 317 26 3 AzerSat LLC. Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1465 2883 232 UniNet S.A. de C.V. 10620 921 211 103 TVCABLE BOGOTA 28573 611 570 31 NET Servicos de Comunicao S.A 22047 601 302 14 VTR PUNTO NET S.A. 7303 572 304 90 Telecom Argentina Stet-France 11830 487 293 55 Instituto Costarricense de El 6471 439 96 31 ENTEL CHILE S.A. 11172 439 99 68 Servicios Alestra S.A de C.V 7738 404 794 28 Telecomunicacoes da Bahia S.A 3816 373 191 85 Empresa Nacional de Telecomun Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 994 188 7 TEDATA 24863 892 88 46 LINKdotNET AS number 20858 319 34 5 EgyNet 3741 276 856 236 The Internet Solution 2018 243 215 143 Tertiary Education Network 6713 175 166 16 Itissalat Al-MAGHRIB 33783 152 10 8 EEPAD TISP TELECOM & INTERNET 29571 139 15 8 Ci Telecom Autonomous system 5536 123 8 9 Internet Egypt Network 5713 116 508 67 Telkom SA Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4266 3643 323 bellsouth.net, inc. 4323 1887 1047 384 Time Warner Telecom 1785 1705 714 139 PaeTec Communications, Inc. 4766 1702 6934 405 Korea Telecom (KIX) 17488 1537 138 95 Hathway IP Over Cable Interne 7018 1503 5909 1046 AT&T WorldNet Services 8151 1465 2883 232 UniNet S.A. de C.V. 20115 1396 1462 687 Charter Communications 2386 1267 671 921 AT&T Data Communications Serv 4755 1213 308 144 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 1785 1705 1566 PaeTec Communications, Inc. 4323 1887 1503 Time Warner Telecom 17488 1537 1442 Hathway IP Over Cable Interne 4766 1702 1297 Korea Telecom (KIX) 8151 1465 1233 UniNet S.A. de C.V. 11492 1122 1110 Cable One 4755 1213 1069 TATA Communications formerly 18566 1062 1052 Covad Communications 22773 1071 1005 Cox Communications, Inc. 8452 994 987 TEDATA Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.112.0/22 5713 Telkom SA Ltd 41.223.176.0/22 36981 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.251.0/24 22555 Universal Talkware Corporatio 64.31.32.0/19 11955 ServiceCo LLC - Road Runner Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:22 /11:58 /12:168 /13:351 /14:607 /15:1164 /16:10513 /17:4752 /18:8211 /19:17006 /20:20404 /21:20177 /22:26229 /23:25863 /24:151711 /25:899 /26:1028 /27:559 /28:150 /29:8 /30:7 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2779 4266 bellsouth.net, inc. 4766 1401 1702 Korea Telecom (KIX) 17488 1283 1537 Hathway IP Over Cable Interne 1785 1177 1705 PaeTec Communications, Inc. 11492 1048 1122 Cable One 18566 1043 1062 Covad Communications 9583 984 1132 Sify Limited 2386 983 1267 AT&T Data Communications Serv 4323 961 1887 Time Warner Telecom 8452 918 994 TEDATA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:207 12:2143 13:8 15:19 16:3 17:4 20:34 24:1096 32:51 34:2 38:575 40:97 41:1746 43:1 44:2 47:22 52:5 55:2 56:3 57:24 58:578 59:653 60:461 61:1079 62:1107 63:2041 64:3684 65:2415 66:3594 67:1619 68:806 69:2664 70:555 71:146 72:1676 73:2 74:1611 75:170 76:335 77:851 78:557 79:360 80:978 81:835 82:563 83:456 84:634 85:1035 86:400 87:676 88:353 89:1448 90:50 91:2377 92:353 93:1125 94:1244 95:1116 96:148 97:215 98:253 99:23 110:170 111:49 112:168 113:136 114:261 115:304 116:1159 117:538 118:338 119:708 120:147 121:777 122:1045 123:705 124:979 125:1389 128:218 129:238 130:127 131:400 132:74 133:9 134:185 135:39 136:224 137:162 138:164 139:78 140:442 141:119 142:391 143:351 144:365 145:48 146:386 147:154 148:520 149:235 150:178 151:193 152:145 153:145 154:2 155:274 156:165 157:301 158:117 159:344 160:284 161:153 162:271 163:162 164:479 165:501 166:456 167:359 168:664 169:174 170:479 171:41 172:10 173:306 174:233 178:1 186:97 187:100 188:102 189:445 190:2855 192:5803 193:4259 194:3312 195:2689 196:1094 198:3590 199:3353 200:5135 201:1311 202:7705 203:8256 204:3880 205:2154 206:2429 207:2712 208:3875 209:3391 210:2546 211:1127 212:1618 213:1652 214:73 215:24 216:4526 217:1318 218:396 219:443 220:1114 221:484 222:301 End of report From eriks at nationalfastfreight.com Fri Jul 3 13:13:38 2009 From: eriks at nationalfastfreight.com (Erik Soosalu) Date: Fri, 3 Jul 2009 14:13:38 -0400 Subject: Fire, Power loss at Fisher Plaza in Seattle In-Reply-To: References: Message-ID: <0B224A2FE01CC54C860290D42474BF6003C173BC@exchange.nff.local> http://seattletimes.nwsource.com/html/localnews/2009415571_apwafisherpla zafire1stldwritethru.html -----Original Message----- From: David Hubbard [mailto:dhubbard at dino.hostasaurus.com] Sent: Friday, July 03, 2009 1:05 PM To: NANOG list Subject: RE: Fire, Power loss at Fisher Plaza in Seattle From: Seth Mattinen [mailto:sethm at rollernet.us] > > Apparently it took authorize.net with it, too: > http://twitter.com/authorizenet > > ~Seth No technical explanation of course but it also took down their 'backup facility' according to them on twitter; I assume some bad routing/DNS if they do actually have a backup facility. Lots of online stores are offline right now because of this, and the holiday is unfortunately keeping those store owners from knowing they are not making sales right now. Life in ecommerce... David From herrin-nanog at dirtside.com Fri Jul 3 13:49:57 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Fri, 3 Jul 2009 14:49:57 -0400 Subject: Fire, Power loss at Fisher Plaza in Seattle In-Reply-To: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> Message-ID: <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> On Fri, Jul 3, 2009 at 1:20 PM, Tomas L. Byrnes wrote: > This begs the question of what basic parameters should be for a > "carrier hotel" or co-lo. [...] The old NEBS standards were too much > of a straightjacket. Tomas, There is a useful standard: ANSI/TIA-942. It offers specifications for four tiers of data centers ranging from tier 1 (a basic data center with no redundancy) to tier 4 (fully fault tolerant). http://www.tiaonline.org/standards/catalog/search.cfm?standards_criteria=TIA-942 (the 2005 one) Judging from http://www.techlinks.net/community/articles/article/1-article-submission-forms/14833-a-quick-primer-on-data-center-tier-classifications there's even research that projects what sort of annual downtime you can expect for each of the tiers described by the standard. When I walk into a data center, I make a habit of asking which tier they achieve, at least for the HVAC and electrical systems. And then I ask to see the components which the tier claim says they should have. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mksmith at adhost.com Fri Jul 3 12:57:56 2009 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Fri, 3 Jul 2009 10:57:56 -0700 Subject: Fire, Power loss at Fisher Plaza in Seattle References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> Message-ID: <17838240D9A5544AAA5FF95F8D52031603E7A639@ad-exh01.adhost.lan> -----Original Message----- From: Tomas L. Byrnes [mailto:tomb at byrneit.net] Sent: Fri 7/3/2009 10:20 AM To: David Hubbard; NANOG list Subject: RE: Fire, Power loss at Fisher Plaza in Seattle This begs the question of what basic parameters should be for a "carrier hotel" or co-lo. Given that we're getting designated "Critical Infrastructure", we'd getter start coming up with some, or we'll have them defined for us. ---- I think the more important question is, "what do you consider redundancy?" We have facilities in Plaza East (no down) and Plaza West (unaffected). If you are critical infrastructure there is no amount of redundancy that you should offload onto a colo provider. Instead, you build your redundancy across different data centers, different providers, different everything. If you rely on a single provider for any of the aforementioned then you have built in at least one single point of failure, regardless of the resiliency of the underlying provider. My .02, worth almost every penny. Mike From sean at donelan.com Fri Jul 3 14:22:14 2009 From: sean at donelan.com (Sean Donelan) Date: Fri, 3 Jul 2009 15:22:14 -0400 (EDT) Subject: Fire, Power loss at Fisher Plaza in Seattle In-Reply-To: <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> Message-ID: <200907031515080.2D3A1E03.15233@clifden.donelan.com> On Fri, 3 Jul 2009, William Herrin wrote: > There is a useful standard: ANSI/TIA-942. It offers specifications for > four tiers of data centers ranging from tier 1 (a basic data center > with no redundancy) to tier 4 (fully fault tolerant). Are you better off with a single "tier 4" data center, multiple "tier 1" data centers, or something in between? Distance and quantity versus complexity and scaling versus cost and risk. Sometimes no matter what you choose, you might be wrong. Earth is a single point of failure, where is your backup site? From stuart at tech.org Fri Jul 3 15:10:55 2009 From: stuart at tech.org (Stephen Stuart) Date: Fri, 03 Jul 2009 20:10:55 +0000 Subject: Fire, Power loss at Fisher Plaza in Seattle In-Reply-To: Your message of "Fri, 03 Jul 2009 15:22:14 -0400." <200907031515080.2D3A1E03.15233@clifden.donelan.com> Message-ID: <200907032010.n63KAt6l040164@nb.tech.org> > Earth is a single point of failure, where is your backup site? This reminds me of the 1996 thread about how MAE-East still had no generator. Same topic, roughly, some of the same people (hi, Sean). Sure, the line about the Earth SPOF is catchy, but in terms of more likely scenarios: how many people stand *outside* the "tier 4" datacenter and imagine a fire marshal pointing at the building and saying, "Turn *that* off, now." I've seen that happen a couple times since the WilTel POP thing in 1996. Stephen From tomb at byrneit.net Fri Jul 3 15:21:20 2009 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Fri, 3 Jul 2009 13:21:20 -0700 Subject: Fire, Power loss at Fisher Plaza in Seattle In-Reply-To: <200907031515080.2D3A1E03.15233@clifden.donelan.com> References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org><3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> Message-ID: <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> > >Earth is a single point of failure, where is your backup site? [TLB:] Given that all my customers are on Earth, I don't need one if my customers also are "down". From jeffrey.lyon at blacklotus.net Fri Jul 3 15:29:08 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 3 Jul 2009 16:29:08 -0400 Subject: Fire, Power loss at Fisher Plaza in Seattle In-Reply-To: <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> Message-ID: <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> Wasn't Authorize.net affected by this? We received a support ticket about why Authorize.net is down today (I don't know either, I don't ask too many questions). Jeff On Fri, Jul 3, 2009 at 4:21 PM, Tomas L. Byrnes wrote: > > >> >>Earth is a single point of failure, where is your backup site? > > [TLB:] Given that all my customers are on Earth, I don't need one if my > customers also are "down". > > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From bc-list at beztech.net Fri Jul 3 15:29:35 2009 From: bc-list at beztech.net (Ben Carleton) Date: Fri, 3 Jul 2009 16:29:35 -0400 Subject: Fire, Power loss at Fisher Plaza in Seattle In-Reply-To: <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> Message-ID: <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> Yes it was. On Jul 3, 2009, at 4:29 PM, Jeffrey Lyon wrote: > Wasn't Authorize.net affected by this? We received a support ticket > about why Authorize.net is down today (I don't know either, I don't > ask too many questions). > > Jeff > > On Fri, Jul 3, 2009 at 4:21 PM, Tomas L. Byrnes > wrote: >> >> >>> >>> Earth is a single point of failure, where is your backup site? >> >> [TLB:] Given that all my customers are on Earth, I don't need one >> if my >> customers also are "down". >> >> >> >> > > > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications of The IRC Company, Inc. > > Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th > at Booth #401. > From bicknell at ufp.org Fri Jul 3 15:39:57 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 3 Jul 2009 16:39:57 -0400 Subject: Fire, Power loss at Fisher Plaza in Seattle In-Reply-To: <200907031515080.2D3A1E03.15233@clifden.donelan.com> References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> Message-ID: <20090703203957.GA75570@ussenterprise.ufp.org> In a message written on Fri, Jul 03, 2009 at 03:22:14PM -0400, Sean Donelan wrote: > Are you better off with a single "tier 4" data center, multiple > "tier 1" data centers, or something in between? It depends entirely on your dependency on connectivity. One extreme is something like a Central Office. Lots of cables from end-sites terminate in the building. Having a duplicate of the head end termination equipment on the opposite coast is darn near useless. If the building goes down, the users going through it go down. "Tier 4" is probably a good idea. The other extreme is a pure content play (YouTube, Google Search). Users don't care which data center they hit (within reason), and indeed often don't know. You're better off having data centers spread out all over, both so you're more likely to only loose one at a time, but also so that the loss of one is relatively unimportant. Once you're already in this architecture, Tier 1 is generally cheaper. There are two problems though. First, most folks don't fit neatly in one of these buckets. They have some ties to local infrastructure, and some items which are not tied. Latency as a performance penality is very subjective. A backup 1000 miles away is fine for many things, and very bad for some things. Second, most folks don't have choices. It would be nice if most cities had three each Tier 1, 2, 3 and 4 data centers available so there was choice and competition but that's rare. Very few companies consider these choices rationally; often because choices are made by different groups. I am amazed how many times inside of an ISP the folks deploying the DNS and mail servers are firewalled from the folks deploying the network, to the point where you have to get to the President to reach common management. This leads to them making choices in opposite directions that end up costing extra money the company, and often resulting in a much lower uptimes than expected. Having the network group deploy a single point of failure to the "Tier 4" data center the server guys required is, well, silly. However, more important than all of this is testing your infrastructure. Would you feel comfortable walking into your data center and ripping the power cable out of some bit of equipment at random _right now_? If not, you have no faith your equipment will work in an outage. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 825 bytes Desc: not available URL: From darren at bolding.org Fri Jul 3 15:57:03 2009 From: darren at bolding.org (Darren Bolding) Date: Fri, 3 Jul 2009 13:57:03 -0700 Subject: Fire, Power loss at Fisher Plaza in Seattle In-Reply-To: <20090703203957.GA75570@ussenterprise.ufp.org> References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <20090703203957.GA75570@ussenterprise.ufp.org> Message-ID: <5a318d410907031357h3fe22112s9ed6e9bdf851379@mail.gmail.com> Power to some of the affected sections of the building has been restored via existing onsite generators. The central power risers cannot be connected to current generators in a timely manner due to excessive damage to the electrical switching equipment (and those generators may still be in standing water). These provide power to a number of colocated systems. Temporary generators are on order to be connected to the central risers, and the site expects that to be complete sometime late this evening. As best I can tell, there is still no utility power connected to any of the systems. The AC systems (chiller and crac) are currently not working. It is not clear to me whether these will be brought back on line when the temporary generators are available, but I am assuming so. It was pleasant to see the general positive attitude, sharing of information and offers of assistance that were made by representatives of the various tenants, customers and carriers that were on the scene. The usual suspects (companies and individuals) stepped up and took care of things, as they always seem to. --D On Fri, Jul 3, 2009 at 1:39 PM, Leo Bicknell wrote: > In a message written on Fri, Jul 03, 2009 at 03:22:14PM -0400, Sean Donelan > wrote: > > Are you better off with a single "tier 4" data center, multiple > > "tier 1" data centers, or something in between? > > It depends entirely on your dependency on connectivity. > > One extreme is something like a Central Office. Lots of cables > from end-sites terminate in the building. Having a duplicate of > the head end termination equipment on the opposite coast is darn > near useless. If the building goes down, the users going through > it go down. "Tier 4" is probably a good idea. > > The other extreme is a pure content play (YouTube, Google Search). > Users don't care which data center they hit (within reason), and > indeed often don't know. You're better off having data centers > spread out all over, both so you're more likely to only loose one > at a time, but also so that the loss of one is relatively unimportant. > Once you're already in this architecture, Tier 1 is generally > cheaper. > > There are two problems though. First, most folks don't fit neatly > in one of these buckets. They have some ties to local infrastructure, > and some items which are not tied. Latency as a performance penality > is very subjective. A backup 1000 miles away is fine for many > things, and very bad for some things. > > Second, most folks don't have choices. It would be nice if most > cities had three each Tier 1, 2, 3 and 4 data centers available so > there was choice and competition but that's rare. > > Very few companies consider these choices rationally; often because > choices are made by different groups. I am amazed how many times > inside of an ISP the folks deploying the DNS and mail servers are > firewalled from the folks deploying the network, to the point where > you have to get to the President to reach common management. This > leads to them making choices in opposite directions that end up > costing extra money the company, and often resulting in a much lower > uptimes than expected. Having the network group deploy a single point > of failure to the "Tier 4" data center the server guys required is, > well, silly. > > However, more important than all of this is testing your infrastructure. > Would you feel comfortable walking into your data center and ripping > the power cable out of some bit of equipment at random _right now_? > If not, you have no faith your equipment will work in an outage. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > -- -- Darren Bolding -- -- darren at bolding.org -- From tme at americafree.tv Fri Jul 3 15:59:41 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 3 Jul 2009 16:59:41 -0400 Subject: Fire, Power loss at Fisher Plaza in Seattle In-Reply-To: <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> Message-ID: <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> On Jul 3, 2009, at 4:29 PM, Ben Carleton wrote: > Yes it was. > > On Jul 3, 2009, at 4:29 PM, Jeffrey Lyon wrote: > >> Wasn't Authorize.net affected by this? We received a support ticket >> about why Authorize.net is down today (I don't know either, I don't >> ask too many questions). >> Authorize.net was for a while completely off the air, and companies that relied upon them were not getting credit card authorizations (and, thus, no ecommerce). I think it is still only partially functional. Authorize.net has been communicating with customers mostly (entirely ?) with twitter - they are @AuthorizeNet with a hash tab of #authorizenet If you go there, you will see a lot of status messages like #authorizenet (cont.) Do not manually submit ARB transactions b/c you run the risk of your merchants being double billed. 10 minutes ago from web (i.e., 4:47 EDT). You will also see a lot of posts from annoyed people if you search on #authorizenet It's an interesting use of Web 2.0 for emergency communications. Regards Marshall >> Jeff >> >> On Fri, Jul 3, 2009 at 4:21 PM, Tomas L. Byrnes >> wrote: >>> >>> >>>> >>>> Earth is a single point of failure, where is your backup site? >>> >>> [TLB:] Given that all my customers are on Earth, I don't need one >>> if my >>> customers also are "down". >>> >>> >>> >>> >> >> >> >> -- >> Jeffrey Lyon, Leadership Team >> jeffrey.lyon at blacklotus.net | http://www.blacklotus.net >> Black Lotus Communications of The IRC Company, Inc. >> >> Look for us at HostingCon 2009 in Washington, DC on August 10th - >> 12th >> at Booth #401. >> > > > From jeffrey.lyon at blacklotus.net Fri Jul 3 16:11:01 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 3 Jul 2009 17:11:01 -0400 Subject: Fire, Power loss at Fisher Plaza in Seattle In-Reply-To: <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> Message-ID: <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> That's a great idea, use some lame Web 2.0 trend to communicate with actual real life customers. Jeff On Fri, Jul 3, 2009 at 4:59 PM, Marshall Eubanks wrote: > > On Jul 3, 2009, at 4:29 PM, Ben Carleton wrote: > >> Yes it was. >> >> On Jul 3, 2009, at 4:29 PM, Jeffrey Lyon wrote: >> >>> Wasn't Authorize.net affected by this? We received a support ticket >>> about why Authorize.net is down today (I don't know either, I don't >>> ask too many questions). >>> > > Authorize.net was for a while completely off the air, and companies that > relied upon them > were not getting credit card authorizations (and, thus, no ecommerce). I > think it is still only > partially functional. > > Authorize.net has been communicating with customers mostly (entirely ?) with > twitter - they are > > @AuthorizeNet with a hash tab of #authorizenet > > If you go there, you will see a lot of status messages like > > #authorizenet (cont.) Do not manually submit ARB transactions b/c you run > the risk of your merchants being double billed. > 10 minutes ago from web > > (i.e., 4:47 EDT). > > You will also see a lot of posts from annoyed people if you search on > ?#authorizenet > > It's an interesting use of Web 2.0 for emergency communications. > > Regards > Marshall > > >>> Jeff >>> >>> On Fri, Jul 3, 2009 at 4:21 PM, Tomas L. Byrnes wrote: >>>> >>>> >>>>> >>>>> Earth is a single point of failure, where is your backup site? >>>> >>>> [TLB:] Given that all my customers are on Earth, I don't need one if my >>>> customers also are "down". >>>> >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Jeffrey Lyon, Leadership Team >>> jeffrey.lyon at blacklotus.net | http://www.blacklotus.net >>> Black Lotus Communications of The IRC Company, Inc. >>> >>> Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th >>> at Booth #401. >>> >> >> >> > > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From mike at m5computersecurity.com Fri Jul 3 16:22:04 2009 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Fri, 03 Jul 2009 14:22:04 -0700 Subject: Fire, Power loss at Fisher Plaza in Seattle In-Reply-To: <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> Message-ID: <1246656124.6564.186.camel@mike-desktop> On Fri, 2009-07-03 at 13:21 -0700, Tomas L. Byrnes wrote: > > > > >Earth is a single point of failure, where is your backup site? > > [TLB:] Given that all my customers are on Earth, I don't need one if my > customers also are "down". Bad Day ! From cidr-report at potaroo.net Fri Jul 3 17:00:05 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 3 Jul 2009 22:00:05 GMT Subject: BGP Update Report Message-ID: <200907032200.n63M05SF040985@wattle.apnic.net> BGP Update Report Interval: 25-Jun-09 -to- 02-Jul-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9198 86810 4.5% 299.3 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - AS4755 31871 1.6% 26.5 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 3 - AS17488 28227 1.4% 24.6 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 4 - AS10474 17094 0.9% 416.9 -- NETACTIVE 5 - AS22783 14699 0.8% 2449.8 -- WEBPOWER - WebPower, Inc. 6 - AS21104 14329 0.7% 1023.5 -- AM-NETSYS-AS Netsys JVC Autonomous System Yerevan, Armenia 7 - AS6389 14119 0.7% 3.3 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 8 - AS21491 12942 0.7% 479.3 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 9 - AS23700 12849 0.7% 31.0 -- BM-AS-ID PT. Broadband Multimedia, Tbk 10 - AS33783 11714 0.6% 90.8 -- EEPAD 11 - AS30890 11347 0.6% 27.1 -- EVOLVA Evolva Telecom 12 - AS47408 11043 0.6% 525.9 -- MANDARIN-AS Mandarin WIMAX Sicilia SpA 13 - AS30969 10906 0.6% 605.9 -- TAN-NET TransAfrica Networks 14 - AS4812 10307 0.5% 11.5 -- CHINANET-SH-AP China Telecom (Group) 15 - AS8452 8289 0.4% 8.6 -- TEDATA TEDATA 16 - AS1221 8218 0.4% 14.1 -- ASN-TELSTRA Telstra Pty Ltd 17 - AS4134 8065 0.4% 8.2 -- CHINANET-BACKBONE No.31,Jin-rong Street 18 - AS8151 7899 0.4% 5.4 -- Uninet S.A. de C.V. 19 - AS24863 7693 0.4% 8.8 -- LINKdotNET-AS 20 - AS5668 7672 0.4% 7.5 -- AS-5668 - CenturyTel Internet Holdings, Inc. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS22783 14699 0.8% 2449.8 -- WEBPOWER - WebPower, Inc. 2 - AS36616 5425 0.3% 1356.2 -- AGTLD - VeriSign Global Registry Services 3 - AS47640 1315 0.1% 1315.0 -- TRICOMPAS Tricomp Sp. z. o. o. 4 - AS21104 14329 0.7% 1023.5 -- AM-NETSYS-AS Netsys JVC Autonomous System Yerevan, Armenia 5 - AS29508 850 0.0% 850.0 -- TANAT-AS TANAT LLC 6 - AS41189 719 0.0% 719.0 -- ICONCEPT-AS iConcept 7 - AS37011 3721 0.2% 620.2 -- MSTARTEL-AS 8 - AS30969 10906 0.6% 605.9 -- TAN-NET TransAfrica Networks 9 - AS47408 11043 0.6% 525.9 -- MANDARIN-AS Mandarin WIMAX Sicilia SpA 10 - AS25546 4205 0.2% 525.6 -- BROOKLANDCOMP-AS Brookland Computer Services 11 - AS35400 2555 0.1% 511.0 -- MFIST Interregoinal Organization Network Technologies 12 - AS27653 2015 0.1% 503.8 -- Alpha Communications Network 13 - AS21491 12942 0.7% 479.3 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 14 - AS10474 17094 0.9% 416.9 -- NETACTIVE 15 - AS13403 415 0.0% 415.0 -- ALAWEB-INTERNET - ALAWEB Internet Services 16 - AS36975 403 0.0% 403.0 -- CBA-AS 17 - AS37083 403 0.0% 403.0 -- hiqos-as 18 - AS38136 764 0.0% 382.0 -- MBTELTRANSIT-BD MB TELECCOM LIMITED, INTERNET SERVICE PROVIDER 19 - AS33074 370 0.0% 370.0 -- ISC-NBO1 ISC, Nairobi, Kenya 20 - AS5050 5932 0.3% 348.9 -- PSC-EXT - Pittsburgh Supercomputing Center TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 95.59.8.0/23 10566 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - 95.59.2.0/23 10565 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 3 - 95.59.4.0/22 10565 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 4 - 92.46.244.0/23 10561 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 5 - 89.218.220.0/23 10561 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 6 - 89.218.218.0/23 10560 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 7 - 95.59.1.0/24 9892 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 8 - 88.204.221.0/24 9866 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 9 - 80.86.238.0/24 7170 0.3% AS21104 -- AM-NETSYS-AS Netsys JVC Autonomous System Yerevan, Armenia 10 - 80.86.239.0/24 6938 0.3% AS21104 -- AM-NETSYS-AS Netsys JVC Autonomous System Yerevan, Armenia 11 - 72.23.246.0/24 5834 0.3% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 12 - 205.246.203.0/24 5686 0.3% AS22783 -- WEBPOWER - WebPower, Inc. 13 - 63.163.66.0/24 5684 0.3% AS22783 -- WEBPOWER - WebPower, Inc. 14 - 65.113.57.0/24 5413 0.3% AS36616 -- AGTLD - VeriSign Global Registry Services 15 - 196.27.104.0/21 4399 0.2% AS30969 -- TAN-NET TransAfrica Networks 16 - 196.27.108.0/22 4383 0.2% AS30969 -- TAN-NET TransAfrica Networks 17 - 193.201.184.0/21 4156 0.2% AS25546 -- BROOKLANDCOMP-AS Brookland Computer Services 18 - 65.212.89.0/24 3311 0.2% AS22783 -- WEBPOWER - WebPower, Inc. 19 - 192.12.120.0/24 2596 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 20 - 90.150.0.0/24 2527 0.1% AS35400 -- MFIST Interregoinal Organization Network Technologies Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 3 17:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 3 Jul 2009 22:00:00 GMT Subject: The Cidr Report Message-ID: <200907032200.n63M00Fr040978@wattle.apnic.net> This report has been generated at Fri Jul 3 21:11:48 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 26-06-09 295351 183129 27-06-09 295423 183044 28-06-09 295023 183041 29-06-09 295221 183133 30-06-09 295170 183378 01-07-09 295242 183533 02-07-09 295543 183261 03-07-09 295814 183137 AS Summary 31727 Number of ASes in routing system 13462 Number of ASes announcing only one prefix 4292 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 89737216 Largest address span announced by an AS (/32s) AS27064: DNIC-ASBLK-27032-27159 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 03Jul09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 295944 183131 112813 38.1% All ASes AS6389 4266 337 3929 92.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4292 1804 2488 58.0% TWTC - tw telecom holdings, inc. AS4766 1811 528 1283 70.8% KIXS-AS-KR Korea Telecom AS17488 1537 279 1258 81.8% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1212 193 1019 84.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1705 689 1016 59.6% AS-PAETEC-NET - PaeTec Communications, Inc. AS22773 1071 71 1000 93.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 1062 95 967 91.1% COVAD - Covad Communications Co. AS8151 1464 552 912 62.3% Uninet S.A. de C.V. AS19262 1017 235 782 76.9% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8452 994 272 722 72.6% TEDATA TEDATA AS18101 770 115 655 85.1% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS17908 684 63 621 90.8% TCISL Tata Communications AS6478 1207 614 593 49.1% ATT-INTERNET3 - AT&T WorldNet Services AS4804 681 109 572 84.0% MPX-AS Microplex PTY LTD AS9498 641 76 565 88.1% BBIL-AP BHARTI Airtel Ltd. AS7029 612 107 505 82.5% WINDSTREAM - Windstream Communications Inc AS11492 1120 618 502 44.8% CABLEONE - CABLE ONE, INC. AS17676 564 80 484 85.8% GIGAINFRA Softbank BB Corp. AS7303 575 92 483 84.0% Telecom Argentina S.A. AS4808 651 170 481 73.9% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS22047 601 126 475 79.0% VTR BANDA ANCHA S.A. AS10620 921 458 463 50.3% TV Cable S.A. AS7018 1503 1047 456 30.3% ATT-INTERNET4 - AT&T WorldNet Services AS4134 977 530 447 45.8% CHINANET-BACKBONE No.31,Jin-rong Street AS24560 724 283 441 60.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS9443 521 82 439 84.3% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7545 830 414 416 50.1% TPG-INTERNET-AP TPG Internet Pty Ltd AS7011 984 570 414 42.1% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4668 693 285 408 58.9% LGNET-AS-KR LG CNS Total 35690 10894 24796 69.5% Top 30 total Possible Bogus Routes 24.50.128.0/20 AS33497 SEMO-COM - Semo Communications Inc 24.54.96.0/23 AS40285 NORTHLAND-CABLE - NORTHLAND CABLE TELEVISION INC. 24.54.98.0/23 AS40285 NORTHLAND-CABLE - NORTHLAND CABLE TELEVISION INC. 24.54.100.0/24 AS40285 NORTHLAND-CABLE - NORTHLAND CABLE TELEVISION INC. 24.54.101.0/24 AS40285 NORTHLAND-CABLE - NORTHLAND CABLE TELEVISION INC. 24.54.102.0/23 AS40285 NORTHLAND-CABLE - NORTHLAND CABLE TELEVISION INC. 24.54.104.0/23 AS40285 NORTHLAND-CABLE - NORTHLAND CABLE TELEVISION INC. 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 41.216.192.0/24 AS37105 NEOLOGY-AS 41.216.193.0/24 AS37105 NEOLOGY-AS 41.216.196.0/24 AS37105 NEOLOGY-AS 41.216.208.0/21 AS14988 BTC-GATE1 41.217.128.0/20 AS15964 CAMNET-AS 41.217.144.0/20 AS37034 RINGO 41.217.160.0/19 AS24863 LINKdotNET-AS 41.217.220.0/24 AS17175 NSS-UK New Skies Satellites UK AS 41.217.224.0/21 AS37031 MIST-EG 41.217.224.0/24 AS37031 MIST-EG 41.217.225.0/24 AS37031 MIST-EG 41.218.0.0/18 AS15706 Sudatel 41.218.0.0/20 AS15706 Sudatel 41.218.16.0/20 AS15706 Sudatel 41.218.16.0/22 AS15706 Sudatel 41.218.20.0/22 AS15706 Sudatel 41.218.24.0/22 AS15706 Sudatel 41.218.28.0/22 AS15706 Sudatel 41.218.32.0/20 AS15706 Sudatel 41.218.32.0/22 AS15706 Sudatel 41.218.48.0/20 AS15706 Sudatel 41.218.56.0/22 AS15706 Sudatel 41.218.60.0/22 AS15706 Sudatel 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.112.0/22 AS5713 SAIX-NET 41.223.176.0/22 AS36981 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.31.59.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.31.60.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 67.20.32.0/20 AS11381 NFIS - NEW FRONTIERS INTERNET SERVICES 67.43.48.0/20 AS30008 COLOGUYS - ColoGuys, Inc. 67.220.176.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 67.220.177.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 67.220.178.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 67.220.179.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 67.220.180.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 67.220.181.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 67.220.182.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 67.220.183.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 67.220.184.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 67.220.185.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 67.220.186.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 67.220.187.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 67.220.188.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 67.220.189.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 67.220.190.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 67.220.191.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 67.221.16.0/24 AS5069 CLEARBLUE-AS - ClearBlue Technologies 67.221.144.0/20 AS46882 ONCL-KMLP - On Call Internet Services Ltd. 67.221.176.0/20 AS11403 NYINTERNET - The New York Internet Company 67.226.224.0/19 AS40304 DRYTEL - DMTS 67.231.160.0/20 AS19212 PRTC-LAURENS - Piedmont Rural Telephone Cooperative, Incorporated 67.231.176.0/20 AS31772 OMEGABYTE-COMPUTER-CORPORATION - Omegabyte Computer Corporation 67.231.192.0/20 AS36676 SCRATCHASN - Scratch Telecom 67.231.224.0/20 AS16948 STRATUSWAVE - StratusWave Communications 67.231.240.0/20 AS40244 TURNKEY-INTERNET - Turnkey Internet Inc. 68.67.16.0/20 AS14559 BRTCC - Ballard Rural Telephone Cooperative Corporation Inc. 68.67.80.0/20 AS6327 SHAW - Shaw Communications Inc. 68.67.112.0/20 AS16610 BLUEBIRD-WIRELESS - Bluebird Wireless Broadband Services, L.L.C. 68.67.192.0/20 AS29812 ONEZERO - One Zero Hosting Inc. 68.68.32.0/20 AS22781 RBLHST - Reliablehosting.com 68.68.80.0/20 AS11550 SDL-20-AS - Smithville Digital, LLC 68.71.80.0/20 AS46529 COMFLUENT-PEARL - Comfluent 68.71.240.0/20 AS20093 ZEROLAG - Zero Lag Communications 68.168.16.0/20 AS33333 LAFIBER - LAFiber, LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.169.96.0/19 AS33597 INFORELAY - InfoRelay Online Systems, Inc. 69.169.96.0/20 AS46801 DIALWAVE-INTERNATIONAL - Dialwave International 69.169.98.0/24 AS29812 ONEZERO - One Zero Hosting Inc. 69.169.112.0/24 AS33597 INFORELAY - InfoRelay Online Systems, Inc. 69.169.113.0/24 AS29812 ONEZERO - One Zero Hosting Inc. 69.169.116.0/24 AS33597 INFORELAY - InfoRelay Online Systems, Inc. 69.169.117.0/24 AS33597 INFORELAY - InfoRelay Online Systems, Inc. 69.169.124.0/24 AS33597 INFORELAY - InfoRelay Online Systems, Inc. 69.169.127.0/24 AS33597 INFORELAY - InfoRelay Online Systems, Inc. 69.196.96.0/19 AS36503 CLUBCORP - ClubCorp USA, Inc. 69.196.224.0/19 AS22556 BLACKBOARD - Blackboard Inc. 72.44.192.0/18 AS12025 IO-DATA-CENTERS - IO Data Centers 72.251.192.0/18 AS29791 VOXEL-DOT-NET - Voxel Dot Net, Inc. 74.108.0.0/16 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.109.0.0/17 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.109.128.0/19 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.114.4.0/22 AS209 ASN-QWEST - Qwest Communications Corporation 74.114.40.0/24 AS46991 SWEDISH-MEDICAL-CENTER-SHS - SWEDISH MEDICAL CENTER 74.114.41.0/24 AS46991 SWEDISH-MEDICAL-CENTER-SHS - SWEDISH MEDICAL CENTER 74.114.48.0/22 AS33418 HRNIT - HRN IT Co. 74.114.52.0/24 AS40818 AS-PLATEM - Platinum eMedia Inc. 74.114.72.0/21 AS40867 NETFLASH - Continuum Online Services Ltd. 74.114.80.0/21 AS7782 ALSK-7782 - Alaska Communications Systems Group, Inc. 74.114.88.0/22 AS6939 HURRICANE - Hurricane Electric, Inc. 74.114.92.0/22 AS27297 PGTECHNOLOGY - PG TECHNOLOGY, INC. 74.114.100.0/22 AS40191 AS-PRE2POST-1 - Zerofail 74.114.104.0/21 AS11966 GLOBALDATASYSTEMS-ASN - GLOBAL DATA SYSTEMS INC. 74.114.112.0/22 AS22338 MBTRADING1 - MB Trading Futures, Inc. 74.114.116.0/22 AS13760 SOUTHERN-LIGHT - Southern Light, LLC 74.114.124.0/22 AS46990 ZETTA-INC - Zetta, Inc. 74.114.128.0/22 AS32695 NEXECOMP-INC - NexeComp, Inc. 74.114.140.0/22 AS32757 KABALLERO-COM-LLC-ACC - KABALLERO.COM LLC ACC BUSINESS 74.114.140.0/24 AS32757 KABALLERO-COM-LLC-ACC - KABALLERO.COM LLC ACC BUSINESS 74.114.160.0/21 AS4323 TWTC - tw telecom holdings, inc. 74.114.168.0/24 AS25973 MZIMA - Mzima Networks, Inc. 74.114.169.0/24 AS25973 MZIMA - Mzima Networks, Inc. 74.114.170.0/24 AS25973 MZIMA - Mzima Networks, Inc. 74.114.171.0/24 AS25973 MZIMA - Mzima Networks, Inc. 74.114.184.0/22 AS19888 ISTA-US01 - ISTA Pharmaceuticals, Inc. 74.114.188.0/24 AS14556 PTC - Pilot Travel Centers, LLC 74.114.189.0/24 AS14556 PTC - Pilot Travel Centers, LLC 74.114.192.0/22 AS46992 SUMO0101 - IguanaNet 74.114.223.0/24 AS39470 ATRIUMNETWORK ATRIUM NETWORK 74.114.232.0/24 AS46817 MTAINC - Midwest Telecom of America, Inc 74.114.233.0/24 AS46817 MTAINC - Midwest Telecom of America, Inc 74.114.234.0/24 AS46817 MTAINC - Midwest Telecom of America, Inc 74.114.240.0/22 AS47060 BMA - Bermuda Monetary Authority 74.115.1.0/24 AS26642 AFAS - AnchorFree Inc. 74.115.12.0/24 AS20251 SOLARWINDSAUSTIN - SolarWinds, Inc. 74.115.13.0/24 AS20251 SOLARWINDSAUSTIN - SolarWinds, Inc. 74.115.16.0/21 AS46529 COMFLUENT-PEARL - Comfluent 74.115.25.0/24 AS47069 LYON-LABS - Lyon Labs, Inc 74.115.26.0/24 AS47069 LYON-LABS - Lyon Labs, Inc 74.115.32.0/24 AS36529 AXXA-RACKCO - Rackco.com 74.115.33.0/24 AS36529 AXXA-RACKCO - Rackco.com 74.115.48.0/23 AS27647 WEEBLY - Weebly, Inc. 74.115.50.0/23 AS27647 WEEBLY - Weebly, Inc. 74.115.72.0/22 AS36100 MTC-BROADBAND - MTC Broadband, Inc. 74.115.76.0/24 AS36100 MTC-BROADBAND - MTC Broadband, Inc. 74.115.77.0/24 AS36100 MTC-BROADBAND - MTC Broadband, Inc. 74.115.78.0/24 AS36100 MTC-BROADBAND - MTC Broadband, Inc. 74.115.96.0/22 AS10940 FONALITY - Fonality, Inc. 75.75.224.0/19 AS19181 CWIE - CWIE LLC 75.75.224.0/20 AS19181 CWIE - CWIE LLC 75.103.64.0/18 AS14992 CRYSTALTECH - CrystalTech Web Hosting Inc. 76.10.224.0/20 AS19223 NTEGRATED-SOLUTIONS - Ntegrated Solutions 79.142.240.0/20 AS12552 IPO-EU IP-Only 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 80.90.240.0/20 AS8331 RINET-AS Cronyx Plus Ltd (RiNet ISP) Autonomous System 80.93.32.0/20 AS28919 STWKUFSTEIN-AS Stadtwerke Kufstein GmbH 80.243.96.0/20 AS29321 CENTRONETAS Centronet, a.s. 81.161.208.0/20 AS9177 MZRTA-AS Mezhdurechensk factory of radio equipment repair, Ltd 83.142.104.0/21 AS15713 GCN-UA Global-City-Net JSC 89.0.0.0/15 AS8422 NETCOLOGNE NETCOLOGNE AS 91.198.181.0/24 AS34224 NETERRA-AS Neterra Ltd. 91.209.190.0/24 AS9167 WEBPARTNER WEBPARTNER A/S is a Danish Internet Service Provider 91.212.213.0/24 AS49364 SERVGE-AS Serv.Ge LTD 91.212.214.0/24 AS49359 RTSQUARE-AS Dmitry Kozhushko 91.212.215.0/24 AS49405 MOTTO-VOIP-AS Motto Voip BV 91.212.216.0/24 AS49397 CAMBRIDGEIMAGING Cambridge Imaging Systems Limited 91.212.219.0/24 AS49355 ASPASIEL ASPASIEL SRL 91.212.221.0/24 AS49394 WIFI48-AS RusLan Ltd 91.212.223.0/24 AS49370 PKN_ORLEN Polski Koncern Naftowy ORLEN S.A. 91.212.224.0/24 AS44398 TDCH-AS TDC Hosting 91.212.225.0/24 AS12306 PLUSLINE Plus.Line AG IP-Services 91.212.226.0/24 AS44042 ROOT-AS root eSolutions 91.212.227.0/24 AS49379 VERIDA-AS SC Verida Credit IFN SA 91.212.228.0/24 AS43071 PCL PCL-Data AB, Sweden 91.212.229.0/24 AS49385 MULTIELECTRONIC-AS SC MULTIELECTRONIC SRL 91.212.230.0/24 AS49410 FRB First Republic Bank JSC 91.212.231.0/24 AS49398 ENERGA-OP5-AS ENERGA-OPERATOR SA Oddzial w Koszalinie 91.212.233.0/24 AS42734 PLAYTIME-AS Playtime Ltd 91.212.234.0/24 AS49525 PARADOX-ENGINEERING-AS PARADOX ENGINEERING SAGL 91.212.235.0/24 AS49401 B-IX-AS DGT Services EOOD 91.212.237.0/24 AS24875 NL-ISPSERVICES ISP Services BV 91.212.240.0/24 AS49132 CATAL-YAZILIM-AS AS for ali catal yazilim 91.212.242.0/24 AS49420 STEFNETAS SPOLDZIELCZA KASA OSZCZEDNOSCIOWO-KREDYTOWA IM FRANCISZKA STEFCZYKA 91.212.243.0/24 AS3320 DTAG Deutsche Telekom AG 91.212.245.0/24 AS13237 LAMBDANET-AS European Backbone of LambdaNet 91.212.246.0/24 AS49425 DATECHNIKHR Datentechnik d.o.o. 91.212.247.0/24 AS49428 EXORHR EXOR informaticki inzenjering d.o.o 91.212.248.0/24 AS49444 LUTACOM-AS Lutacom Network 91.212.250.0/24 AS15467 ENTERNET-LIBERCOM-AS Enternet 2001 Ltd., Hungary 91.212.251.0/24 AS3212 TRIERA TRIERA 91.212.252.0/24 AS49433 RFB-AS Bank Refah Kargaran 91.212.254.0/24 AS49437 INCDFP-AS Institutul National de Cercetare Dezvoltare pentru Fizica Pamantului - INCDFP RA 91.212.255.0/24 AS29313 LEXMARK Lexmark International SAS 91.213.1.0/24 AS12735 ASTURKNET TurkNet Iletisim Hizmetleri A.S 91.213.3.0/24 AS30367 STRATEGIC-VALUE-PARTNERS-LLC STRATEGIC VALUE PARTNERS LLC 91.213.8.0/24 AS49466 XSERVER XServer AS 91.213.9.0/24 AS15467 ENTERNET-LIBERCOM-AS Enternet 2001 Ltd., Hungary 91.213.12.0/24 AS49482 MERCATOR-B-EOOD-AS Mercator-B EOOD 91.213.13.0/24 AS16131 GRAFIX-IS GrafiX Internet B.V. 91.213.14.0/24 AS34784 RUSAT-AS AS a Satellite Teleport RuSat 91.213.17.0/24 AS34932 FUZION Fuzion is a Danish Internet Service Provider 91.213.19.0/24 AS49496 ALFREDO-AS SC Alfredo Foods SRL 91.213.21.0/24 AS8881 VERSATEL Versatel West GmbH 91.213.24.0/24 AS3303 SWISSCOM Swisscom (Switzerland) Ltd 91.213.26.0/24 AS8304 AS8304 ECRITEL Company 91.213.29.0/24 AS23456 -Reserved AS- 91.214.64.0/24 AS49356 ITT-E-AS IT&T-E LTD 91.214.65.0/24 AS30822 MAGEAL-AS Enterprise Mageal 91.214.66.0/24 AS49356 ITT-E-AS IT&T-E LTD 91.214.67.0/24 AS49356 ITT-E-AS IT&T-E LTD 91.214.76.0/22 AS49373 UCT-AS JSC "Universal Card Technologies" 91.214.80.0/22 AS39529 MTRX-ALCHEVSK-AS Matrix-Alchevsk 91.214.84.0/22 AS3.169 91.214.88.0/22 AS44746 SILA5-AS Satellithuset i Limmared AB 91.214.92.0/24 AS49448 INTECH INTECH GLOBAL SOLUTIONS LTD 91.214.93.0/24 AS49448 INTECH INTECH GLOBAL SOLUTIONS LTD 91.214.94.0/24 AS49448 INTECH INTECH GLOBAL SOLUTIONS LTD 91.214.95.0/24 AS49448 INTECH INTECH GLOBAL SOLUTIONS LTD 91.214.96.0/22 AS49380 SOKRATEL-AS Sokratel Ltd. 91.214.104.0/22 AS49498 SNT-HR-AS S&T Hrvatska d.o.o. 91.214.120.0/22 AS49411 NATA-INFO-AS Nata-Info Ltd 91.214.124.0/22 AS49417 AOL-UA-NET Tikhon S.Zyuzikov 91.214.128.0/22 AS3.97 91.214.132.0/22 AS48748 MY-HOME-AS PE Zaglada Mihajlo Oleksandrovich 91.214.136.0/22 AS44007 RADA-AS Rada Ltd 91.214.144.0/22 AS49481 ULTRACOM-AS Ultracom JSC 91.214.160.0/22 AS49461 PODOL-INTELECT-SYSTEM-AS PP Podilsky Intelectualni sistemy 91.214.180.0/22 AS28724 SOFTLINE-KIEV-AS JSC "SOFTLINE" Kiev, Ukraine 91.214.192.0/22 AS24971 MASTER-AS Master Internet s.r.o / Czech Republic / www.master.cz 91.215.8.0/22 AS49022 TUPOLEVANET-AS Pochechuiev Oleksandr Grigorovich, PE 92.42.32.0/21 AS49467 INETMAR Inetmar internet Hizmetleri San. Tic. Ltd. Sti 93.157.128.0/21 AS44056 TRYTECH-AS Trytech Ltd. 94.137.192.0/19 AS8345 DSIJSC-AS DSI Autonomous system 94.140.192.0/19 AS35000 PROMETEY Prometey Ltd. Autonomous System 94.140.204.0/22 AS49304 GRIZABLE Grizable Ltd 94.140.216.0/22 AS48105 LANCOM-AS Lancom Ltd. 94.231.224.0/20 AS29512 TVK-WROC-AS TVK Tel-Ka Wroclaw 95.81.64.0/18 AS47262 HAMARA-AS Hamara System Tabriz Engineering Company 95.84.192.0/18 AS42610 NCNET-AS National Cable Networks 95.141.32.0/20 AS49367 SEFLOW Seflow S.N.C. Di Marco Brame' & C. 95.141.48.0/24 AS41833 MOSCANET Moscanet (WISE) 95.141.49.0/24 AS41833 MOSCANET Moscanet (WISE) 95.141.50.0/24 AS41833 MOSCANET Moscanet (WISE) 95.141.51.0/24 AS41833 MOSCANET Moscanet (WISE) 95.141.52.0/24 AS41833 MOSCANET Moscanet (WISE) 95.141.53.0/24 AS41833 MOSCANET Moscanet (WISE) 95.141.54.0/24 AS41833 MOSCANET Moscanet (WISE) 95.141.55.0/24 AS41833 MOSCANET Moscanet (WISE) 95.141.80.0/20 AS49409 DATAOPPDRAG DataOppdrag AS 95.141.96.0/20 AS16211 STELLA-NET Stella-Net is a French ISP 95.141.128.0/24 AS35104 KTC-AS AS JSC "KazTransCom" 95.141.129.0/24 AS35104 KTC-AS AS JSC "KazTransCom" 95.141.130.0/24 AS35104 KTC-AS AS JSC "KazTransCom" 95.141.136.0/24 AS35104 KTC-AS AS JSC "KazTransCom" 95.141.137.0/24 AS35104 KTC-AS AS JSC "KazTransCom" 95.141.144.0/20 AS8468 ENTANET ENTANET International Ltd 95.141.160.0/21 AS6908 DATAHOP Datahop Autonomous System 95.141.176.0/20 AS42514 SIGNAL-AS Signal Service, Autonomous System 95.141.192.0/20 AS44158 ALTURA-AS "Altura" Co., ISP, Saratov 96.62.0.0/16 AS35908 VPLSNET - VPLS Inc. d/b/a Krypt Technologies 100.100.100.0/30 AS38676 AS33005-AS-KR wizsolution co.,Ltd 110.232.160.0/22 AS10222 INFOVISION-AS-PH Infovision Data Services AS Data Center 110.232.164.0/22 AS10222 INFOVISION-AS-PH Infovision Data Services AS Data Center 110.232.168.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 110.232.172.0/22 AS10222 INFOVISION-AS-PH Infovision Data Services AS Data Center 110.232.184.0/23 AS45744 AUSENCO-AS-AP Ausenco multihomed network 110.232.184.0/24 AS45744 AUSENCO-AS-AP Ausenco multihomed network 110.232.185.0/24 AS45744 AUSENCO-AS-AP Ausenco multihomed network 110.232.186.0/23 AS45744 AUSENCO-AS-AP Ausenco multihomed network 110.232.186.0/24 AS45744 AUSENCO-AS-AP Ausenco multihomed network 110.232.187.0/24 AS45744 AUSENCO-AS-AP Ausenco multihomed network 110.232.192.0/19 AS17941 BIT-ISLE Bit-isle Co.,Ltd. 110.232.224.0/21 AS7672 FITWEB Hokuden Information System Service Co.,Ltd. 110.232.232.0/22 AS7672 FITWEB Hokuden Information System Service Co.,Ltd. 110.232.236.0/22 AS17957 CTS SOUTH TOKYO CABLETELEVISION 111.64.0.0/16 AS2510 INFOWEB FUJITSU LIMITED 111.65.128.0/22 AS17573 MINS-AS-KR Qrix Daegu, inc 111.65.132.0/22 AS17573 MINS-AS-KR Qrix Daegu, inc 111.65.136.0/22 AS17573 MINS-AS-KR Qrix Daegu, inc 111.65.140.0/22 AS17573 MINS-AS-KR Qrix Daegu, inc 111.65.144.0/22 AS17573 MINS-AS-KR Qrix Daegu, inc 111.65.148.0/22 AS17573 MINS-AS-KR Qrix Daegu, inc 111.65.152.0/22 AS17573 MINS-AS-KR Qrix Daegu, inc 111.65.156.0/22 AS17573 MINS-AS-KR Qrix Daegu, inc 111.65.160.0/22 AS17573 MINS-AS-KR Qrix Daegu, inc 111.65.164.0/22 AS17573 MINS-AS-KR Qrix Daegu, inc 111.65.168.0/22 AS17573 MINS-AS-KR Qrix Daegu, inc 111.65.172.0/22 AS17573 MINS-AS-KR Qrix Daegu, inc 111.65.176.0/22 AS17573 MINS-AS-KR Qrix Daegu, inc 111.65.180.0/22 AS17573 MINS-AS-KR Qrix Daegu, inc 111.65.184.0/22 AS17573 MINS-AS-KR Qrix Daegu, inc 111.65.188.0/22 AS17573 MINS-AS-KR Qrix Daegu, inc 111.65.192.0/19 AS9614 OCT Oita Cable Telecom Co,ltd. 111.65.224.0/20 AS18202 ASN-NZ-NET24 # AS-NZ-NET24 CONVERTED TO ASN-NZ-NET24 FOR RPSL COMPLIANCE Net24 Limited 111.67.0.0/21 AS45454 WEB24-VIC-AU Web24 Virtual & Dedicated hosting service provider, Melb, Australia 111.67.8.0/21 AS45454 WEB24-VIC-AU Web24 Virtual & Dedicated hosting service provider, Melb, Australia 111.67.48.0/20 AS38840 VMAXTELECOM-NET VMAX Telecom Co., Ltd 111.67.48.0/24 AS38840 VMAXTELECOM-NET VMAX Telecom Co., Ltd 111.67.49.0/24 AS38840 VMAXTELECOM-NET VMAX Telecom Co., Ltd 111.67.50.0/24 AS38840 VMAXTELECOM-NET VMAX Telecom Co., Ltd 111.67.51.0/24 AS38840 VMAXTELECOM-NET VMAX Telecom Co., Ltd 111.67.52.0/24 AS38840 VMAXTELECOM-NET VMAX Telecom Co., Ltd 111.67.53.0/24 AS38840 VMAXTELECOM-NET VMAX Telecom Co., Ltd 111.67.54.0/24 AS38840 VMAXTELECOM-NET VMAX Telecom Co., Ltd 111.67.55.0/24 AS38840 VMAXTELECOM-NET VMAX Telecom Co., Ltd 111.67.56.0/24 AS38840 VMAXTELECOM-NET VMAX Telecom Co., Ltd 111.67.57.0/24 AS38840 VMAXTELECOM-NET VMAX Telecom Co., Ltd 111.67.58.0/24 AS38840 VMAXTELECOM-NET VMAX Telecom Co., Ltd 111.67.59.0/24 AS38840 VMAXTELECOM-NET VMAX Telecom Co., Ltd 111.67.60.0/24 AS38840 VMAXTELECOM-NET VMAX Telecom Co., Ltd 111.67.61.0/24 AS38840 VMAXTELECOM-NET VMAX Telecom Co., Ltd 111.67.62.0/24 AS38840 VMAXTELECOM-NET VMAX Telecom Co., Ltd 111.67.63.0/24 AS38840 VMAXTELECOM-NET VMAX Telecom Co., Ltd 111.67.64.0/24 AS45786 ATP-AS-ID-AP ATP - ISP's 111.67.65.0/24 AS45786 ATP-AS-ID-AP ATP - ISP's 111.67.66.0/24 AS45786 ATP-AS-ID-AP ATP - ISP's 111.67.67.0/24 AS45786 ATP-AS-ID-AP ATP - ISP's 111.67.80.0/24 AS45786 ATP-AS-ID-AP ATP - ISP's 111.67.81.0/24 AS45786 ATP-AS-ID-AP ATP - ISP's 111.67.82.0/24 AS45786 ATP-AS-ID-AP ATP - ISP's 111.67.83.0/24 AS45786 ATP-AS-ID-AP ATP - ISP's 111.67.96.0/24 AS45348 CHUANWEI-AS-KH Regency Square, Complex B, 111.67.98.0/24 AS45348 CHUANWEI-AS-KH Regency Square, Complex B, 111.67.112.0/21 AS10010 TOKAI VICTOKAI Corporation 111.67.120.0/22 AS10010 TOKAI VICTOKAI Corporation 111.67.124.0/22 AS10010 TOKAI VICTOKAI Corporation 111.67.128.0/19 AS7524 HANSHIN ITEC HANKYU HANSHIN CO.,LTD. 111.67.192.0/20 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 111.67.208.0/24 AS38676 AS33005-AS-KR wizsolution co.,Ltd 111.67.209.0/24 AS38676 AS33005-AS-KR wizsolution co.,Ltd 111.67.210.0/24 AS38676 AS33005-AS-KR wizsolution co.,Ltd 111.67.211.0/24 AS38676 AS33005-AS-KR wizsolution co.,Ltd 111.67.212.0/24 AS38676 AS33005-AS-KR wizsolution co.,Ltd 111.67.213.0/24 AS38676 AS33005-AS-KR wizsolution co.,Ltd 111.67.217.0/24 AS38676 AS33005-AS-KR wizsolution co.,Ltd 111.67.218.0/24 AS38676 AS33005-AS-KR wizsolution co.,Ltd 111.68.0.0/20 AS9381 NEWTT-IP-AP Wharf T&T Ltd. 111.68.16.0/21 AS2497 IIJ Internet Initiative Japan Inc. 111.68.24.0/21 AS45324 GMEDIA-AS-ID Global Media Teknologi, PT 111.68.24.0/24 AS45324 GMEDIA-AS-ID Global Media Teknologi, PT 111.68.25.0/24 AS45324 GMEDIA-AS-ID Global Media Teknologi, PT 111.68.26.0/24 AS45324 GMEDIA-AS-ID Global Media Teknologi, PT 111.68.32.0/22 AS23944 SKYBB8-AS-AP AS-SKYBroadband SKYCable Corporation 111.68.36.0/22 AS23944 SKYBB8-AS-AP AS-SKYBroadband SKYCable Corporation 111.68.40.0/22 AS23944 SKYBB8-AS-AP AS-SKYBroadband SKYCable Corporation 111.68.44.0/22 AS23944 SKYBB8-AS-AP AS-SKYBroadband SKYCable Corporation 111.68.48.0/22 AS23944 SKYBB8-AS-AP AS-SKYBroadband SKYCable Corporation 111.68.52.0/22 AS23944 SKYBB8-AS-AP AS-SKYBroadband SKYCable Corporation 111.68.56.0/22 AS23944 SKYBB8-AS-AP AS-SKYBroadband SKYCable Corporation 111.68.60.0/22 AS23944 SKYBB8-AS-AP AS-SKYBroadband SKYCable Corporation 111.68.96.0/24 AS45773 HECPERN-AS-PK PERN AS Content Servie Provider, Islamabad, Pakistan 111.68.97.0/24 AS45773 HECPERN-AS-PK PERN AS Content Servie Provider, Islamabad, Pakistan 111.68.98.0/24 AS45773 HECPERN-AS-PK PERN AS Content Servie Provider, Islamabad, Pakistan 111.68.99.0/24 AS45773 HECPERN-AS-PK PERN AS Content Servie Provider, Islamabad, Pakistan 111.68.112.0/24 AS45287 VARNION-AS-ID Varnion Technology Semesta, PT 111.68.113.0/24 AS45287 VARNION-AS-ID Varnion Technology Semesta, PT 111.68.128.0/17 AS2914 NTT-COMMUNICATIONS-2914 - NTT America, Inc. 111.69.0.0/16 AS23655 SNAP-NZ-AS Snap Internet Limited 111.72.0.0/13 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 111.84.0.0/17 AS24378 ENGTAC-AS-TH-AP Total Access Communication PLC. 111.84.0.0/18 AS24378 ENGTAC-AS-TH-AP Total Access Communication PLC. 111.84.64.0/18 AS24378 ENGTAC-AS-TH-AP Total Access Communication PLC. 111.84.128.0/17 AS24378 ENGTAC-AS-TH-AP Total Access Communication PLC. 111.85.0.0/16 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 111.89.0.0/16 AS2514 INFOSPHERE NTT PC Communications, Inc. 111.90.0.0/17 AS4721 JCN Japan Cablenet Limited 111.90.160.0/21 AS23639 NTT-BIZLINK NTT Bizlink, Inc. 111.91.0.0/17 AS38457 HNS-AS-AP Honesty Net Solution (I) Pvt Ltd 111.91.0.0/24 AS38457 HNS-AS-AP Honesty Net Solution (I) Pvt Ltd 111.91.26.0/24 AS38457 HNS-AS-AP Honesty Net Solution (I) Pvt Ltd 111.91.240.0/20 AS10000 NCM Nagasaki Cable Media Inc. 111.92.0.0/18 AS17465 ASIANET Cable ISP in India 111.92.0.0/24 AS17465 ASIANET Cable ISP in India 111.92.7.0/24 AS17465 ASIANET Cable ISP in India 111.92.64.0/23 AS17465 ASIANET Cable ISP in India 111.92.72.0/21 AS17465 ASIANET Cable ISP in India 111.92.80.0/21 AS17465 ASIANET Cable ISP in India 111.92.88.0/21 AS17465 ASIANET Cable ISP in India 111.92.96.0/21 AS17465 ASIANET Cable ISP in India 111.92.104.0/21 AS17465 ASIANET Cable ISP in India 111.92.112.0/21 AS17465 ASIANET Cable ISP in India 111.92.120.0/21 AS17465 ASIANET Cable ISP in India 111.92.160.0/24 AS23671 JMN-ID-AP PT. Saranainsan Mudaselaras 111.92.161.0/24 AS23671 JMN-ID-AP PT. Saranainsan Mudaselaras 111.94.0.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.0.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.4.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.8.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.8.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.12.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.16.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.16.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.20.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.24.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.24.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.28.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.32.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.32.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.36.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.40.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.40.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.44.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.48.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.48.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.52.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.56.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.56.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.60.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.64.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.64.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.68.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.72.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.72.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.76.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.80.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.80.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.84.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.88.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.88.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.92.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.96.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.96.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.100.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.104.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.104.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.108.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.112.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.112.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.116.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.120.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.120.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.124.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.128.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.128.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.132.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.136.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.136.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.140.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.144.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.144.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.148.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.152.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.152.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.156.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.160.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.160.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.164.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.168.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.168.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.172.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.176.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.176.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.180.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.184.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.184.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.188.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.192.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.192.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.196.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.200.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.200.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.204.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.208.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.208.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.212.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.216.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.216.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.220.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.224.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.224.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.228.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.232.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.232.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.236.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.240.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.240.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.244.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.248.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.248.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.94.252.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.0.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.0.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.4.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.8.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.8.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.12.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.16.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.16.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.20.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.24.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.24.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.28.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.32.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.32.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.36.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.40.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.40.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.44.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.48.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.48.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.52.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.56.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.56.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.60.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.64.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.64.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.68.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.72.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.72.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.76.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.80.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.80.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.84.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.88.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.88.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.92.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.96.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.96.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.100.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.104.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.104.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.108.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.112.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.112.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.116.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.120.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.120.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.124.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.128.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.128.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.132.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.136.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.136.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.140.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.144.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.144.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.148.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.152.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.152.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.156.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.160.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.160.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.164.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.168.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.168.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.172.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.176.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.176.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.180.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.184.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.184.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.188.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.192.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.192.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.196.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.200.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.200.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.204.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.208.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.208.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.212.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.216.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.216.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.220.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.224.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.224.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.228.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.232.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.232.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.236.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.240.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.240.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.244.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.248.0/21 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.248.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.95.252.0/22 AS23700 BM-AS-ID PT. Broadband Multimedia, Tbk 111.96.0.0/16 AS2516 KDDI KDDI CORPORATION 111.97.0.0/16 AS2516 KDDI KDDI CORPORATION 111.98.0.0/16 AS2516 KDDI KDDI CORPORATION 111.99.0.0/16 AS2516 KDDI KDDI CORPORATION 111.100.0.0/16 AS2516 KDDI KDDI CORPORATION 111.101.0.0/16 AS2516 KDDI KDDI CORPORATION 111.102.0.0/16 AS2516 KDDI KDDI CORPORATION 111.103.0.0/16 AS2516 KDDI KDDI CORPORATION 111.114.0.0/15 AS4538 ERX-CERNET-BKB China Education and Research Network Center 111.116.0.0/15 AS4538 ERX-CERNET-BKB China Education and Research Network Center 111.118.128.0/19 AS38623 VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE. 111.118.128.0/20 AS38623 VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE. 111.118.128.0/21 AS38623 VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE. 111.118.136.0/21 AS38623 VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE. 111.118.140.0/22 AS38623 VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE. 111.118.144.0/20 AS38623 VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE. 111.118.144.0/21 AS38623 VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE. 111.118.144.0/22 AS38623 VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE. 111.118.148.0/22 AS38623 VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE. 111.118.152.0/22 AS38623 VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE. 111.118.156.0/22 AS38623 VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE. 111.119.0.0/22 AS22822 LLNW - Limelight Networks, Inc. 111.171.0.0/17 AS38109 HINET-AS-KR Taegu Cable Network Co., Ltd 111.171.0.0/19 AS38109 HINET-AS-KR Taegu Cable Network Co., Ltd 111.171.32.0/19 AS38109 HINET-AS-KR Taegu Cable Network Co., Ltd 111.171.64.0/19 AS38109 HINET-AS-KR Taegu Cable Network Co., Ltd 111.171.96.0/19 AS38109 HINET-AS-KR Taegu Cable Network Co., Ltd 111.171.96.0/20 AS38109 HINET-AS-KR Taegu Cable Network Co., Ltd 111.171.112.0/20 AS38109 HINET-AS-KR Taegu Cable Network Co., Ltd 111.171.128.0/17 AS2510 INFOWEB FUJITSU LIMITED 111.172.0.0/14 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 111.176.0.0/13 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 111.184.0.0/15 AS9416 MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 111.184.0.0/16 AS9416 MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 111.185.0.0/16 AS9416 MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 111.186.0.0/15 AS4538 ERX-CERNET-BKB China Education and Research Network Center 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 137.0.0.0/13 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 158.222.5.0/24 AS21580 DIRCON - Direct Connect 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 168.253.0.0/16 AS13649 ASN-VINS - ViaWest 168.253.0.0/21 AS13649 ASN-VINS - ViaWest 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 173.183.0.0/17 AS852 ASN852 - Telus Advanced Communications 173.183.128.0/17 AS852 ASN852 - Telus Advanced Communications 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 186.14.224.0/21 AS21826 Internet Cable Plus C. A. 186.14.240.0/21 AS21826 Internet Cable Plus C. A. 186.14.253.0/24 AS21826 Internet Cable Plus C. A. 186.14.254.0/24 AS21826 Internet Cable Plus C. A. 186.14.255.0/24 AS21826 Internet Cable Plus C. A. 186.16.128.0/23 AS23201 Telecel S.A. 186.16.130.0/23 AS23201 Telecel S.A. 186.16.132.0/23 AS23201 Telecel S.A. 186.16.134.0/23 AS23201 Telecel S.A. 186.16.136.0/23 AS23201 Telecel S.A. 186.16.138.0/23 AS23201 Telecel S.A. 186.16.140.0/23 AS23201 Telecel S.A. 186.16.142.0/23 AS23201 Telecel S.A. 186.16.144.0/23 AS23201 Telecel S.A. 186.16.146.0/23 AS23201 Telecel S.A. 186.16.148.0/23 AS23201 Telecel S.A. 186.16.150.0/23 AS23201 Telecel S.A. 186.16.152.0/23 AS23201 Telecel S.A. 186.16.154.0/23 AS23201 Telecel S.A. 186.16.156.0/23 AS23201 Telecel S.A. 186.16.158.0/23 AS23201 Telecel S.A. 186.40.0.0/17 AS27680 TELEFONICA MOVIL DE CHILE S.A. 186.42.0.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.1.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.2.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.3.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.4.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.5.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.6.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.7.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.8.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.9.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.10.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.11.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.12.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.13.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.14.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.15.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.16.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.17.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.18.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.19.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.20.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.21.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.22.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.23.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.24.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.25.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.26.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.27.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.28.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.29.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.30.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.31.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.32.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.33.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.34.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.35.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.36.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.37.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.38.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.39.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.40.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.41.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.42.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.43.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.44.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.45.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.46.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.47.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.48.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.49.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.50.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.51.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.52.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.53.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.54.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.55.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.56.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.57.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.58.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.59.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.60.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.61.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.62.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 186.42.63.0/24 AS14420 CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 188.93.208.0/21 AS49352 LOGOL-AS LTD Hosting Service 188.93.216.0/21 AS29252 ODR-TKG-AS ODR Technologie und Service GmbH. 188.93.224.0/21 AS43006 CGEST Cgest S.A. 188.93.232.0/21 AS49349 DOTSI DotSi - Servicos de Internet 188.93.240.0/21 AS48734 UTS United TeleSystems Ltd. 188.93.248.0/21 AS39885 EUROPAY-AS Europay Austria Zahlungsverkehrssystem GmbH 188.94.8.0/21 AS49388 INTERCOMGI-BCN Intercom Telematica Girona, S.L. 188.94.16.0/21 AS44611 TALKINTERNET Talk Internet 188.94.24.0/21 AS20694 NMMN-AS New Media Markets and Networks in Hamburg, Germany 188.94.32.0/21 AS49368 DOMOLAN-AS DomoLAN Ltd. 188.94.72.0/21 AS49485 HA-SDC High Availability Hosting Limited 188.94.88.0/21 AS49400 PAGEMASTER-AS PageMaster Ltd 188.94.104.0/21 AS34816 AEG AEG Europe 188.94.120.0/21 AS47358 NTRNET NTRnet s.r.l. 188.94.144.0/21 AS6.176 188.94.152.0/21 AS41371 SKYNET Sky Silk AS 188.94.160.0/24 AS49426 LINTECSAS1-AS LInTeCS AS 188.94.161.0/24 AS49426 LINTECSAS1-AS LInTeCS AS 188.94.162.0/24 AS49426 LINTECSAS1-AS LInTeCS AS 188.94.163.0/24 AS49426 LINTECSAS1-AS LInTeCS AS 188.94.164.0/24 AS49426 LINTECSAS1-AS LInTeCS AS 188.94.165.0/24 AS49426 LINTECSAS1-AS LInTeCS AS 188.94.166.0/24 AS49426 LINTECSAS1-AS LInTeCS AS 188.94.167.0/24 AS49426 LINTECSAS1-AS LInTeCS AS 188.94.176.0/21 AS9044 SOLNET SolNet Internet Solution Provider 188.94.176.0/22 AS9044 SOLNET SolNet Internet Solution Provider 188.94.248.0/22 AS25560 RHTEC-AS rh-tec IP Backbone 188.95.16.0/24 AS12874 FASTWEB Fastweb Autonomous System 188.95.24.0/24 AS48424 GLOBITEL-AS GLOBITEL Sp. z o.o. 188.95.32.0/21 AS49515 SERVERCENTRALEN Colocation & Outsourcing i Norrort AB 188.95.39.0/24 AS42695 CNHAB City Network Hosting AB 188.95.72.0/21 AS47927 WIFIWEB Wifiweb s.r.l. 188.95.88.0/21 AS49045 ATN-NETWORKS ATN Networks 188.95.104.0/21 AS44300 KRASTELCOM-AS OOO "KrasTelCom" 188.115.192.0/18 AS49363 OAR-DC "Orange Armenia" CJSC 188.116.0.0/18 AS43333 NEPHAX-AS CIS NEPHAX 188.116.128.0/18 AS34629 ORNRU-AS "Resurs-Svyaz" Ltd. 188.117.0.0/18 AS29422 NBLNETWORKS-AS Nebula Oy Autonomous System 188.117.64.0/18 AS41176 SAHARANET-AS Sahara Net Main NOC AS 188.117.128.0/18 AS31242 TKPSA-AS TKP S.A. is 3S.pl network operator. 188.117.192.0/18 AS21360 EMPIRION Empirion Telekommunikations Services GmbH 188.118.128.0/18 AS15747 OSNATEL osnatel GmbH 188.118.192.0/18 AS3248 SIL-AT SILVER SERVER GmbH 188.122.32.0/19 AS31290 MURPHX-UK-AS murphx UK Network 188.122.64.0/23 AS29550 EUROCONNEX-AS Blueconnex Networks Ltd 188.122.68.0/23 AS34309 LINK11 Link11 GmbH 188.122.128.0/19 AS44581 SE-ALLTELE-AS AllTele Allmanna Svenska Telefonaktiebolaget 188.122.224.0/19 AS8439 AISTNET AIST Autonomous System 188.123.128.0/19 AS44877 MAXIMALI-AS Vtel-Georgia 188.123.128.0/21 AS44877 MAXIMALI-AS Vtel-Georgia 188.123.160.0/19 AS39559 SAMA Sama Telecom 188.123.192.0/19 AS35434 PIRXNET-AS PirxNet ISP Silesia, Poland 188.123.224.0/19 AS15582 AKADO-STOLITSA-AS AKADO-Stolitsa Autonomous System 188.124.0.0/19 AS44565 VITAL VITAL TEKNOLOJI 188.124.224.0/19 AS39792 ANDERS-AS Anders Business Group Global IP Network 188.141.128.0/17 AS35632 IRIS64-AS IRIS64 188.142.128.0/19 AS34588 FIBERNET-HU-AS FiberNet Communication Inc 188.143.0.0/17 AS44067 MEDIANETWORK-UKRAINE MediaNetwork Ukraine 188.143.128.0/17 AS44050 PIN-AS Petersburg Internet Network LLC 188.158.0.0/15 AS39501 NGSAS Neda Gostar Saba Data Transfer Company Private Joint 188.163.0.0/16 AS12530 GOLDENTELECOM-UKRAINE Golden Telecom 188.163.0.0/17 AS12421 GT-FIBER Golden-Fiber Project (FTTB) 188.163.32.0/21 AS12421 GT-FIBER Golden-Fiber Project (FTTB) 188.163.40.0/21 AS12421 GT-FIBER Golden-Fiber Project (FTTB) 188.164.0.0/17 AS31733 LINKTEL-AS ISP Link Telecom 188.164.128.0/17 AS31733 LINKTEL-AS ISP Link Telecom 188.165.0.0/16 AS16276 OVH OVH 188.167.0.0/16 AS6830 UPC UPC Broadband 188.167.0.0/17 AS6830 UPC UPC Broadband 188.167.128.0/17 AS6830 UPC UPC Broadband 188.169.0.0/16 AS35805 UTG-AS United Telecom AS 188.200.0.0/13 AS286 KPN KPN Internet Backbone AS 188.200.0.0/14 AS286 KPN KPN Internet Backbone AS 188.204.0.0/14 AS286 KPN KPN Internet Backbone AS 188.220.0.0/14 AS35228 BEUNLIMITED Avatar Broadband Limited 188.220.0.0/18 AS35228 BEUNLIMITED Avatar Broadband Limited 188.220.64.0/18 AS35228 BEUNLIMITED Avatar Broadband Limited 188.220.128.0/18 AS35228 BEUNLIMITED Avatar Broadband Limited 188.220.192.0/18 AS35228 BEUNLIMITED Avatar Broadband Limited 188.221.0.0/18 AS35228 BEUNLIMITED Avatar Broadband Limited 188.221.64.0/18 AS35228 BEUNLIMITED Avatar Broadband Limited 188.221.128.0/18 AS35228 BEUNLIMITED Avatar Broadband Limited 188.221.192.0/18 AS35228 BEUNLIMITED Avatar Broadband Limited 188.222.0.0/18 AS35228 BEUNLIMITED Avatar Broadband Limited 188.222.64.0/18 AS35228 BEUNLIMITED Avatar Broadband Limited 188.222.128.0/18 AS35228 BEUNLIMITED Avatar Broadband Limited 188.222.192.0/18 AS35228 BEUNLIMITED Avatar Broadband Limited 188.223.0.0/18 AS35228 BEUNLIMITED Avatar Broadband Limited 188.223.64.0/18 AS35228 BEUNLIMITED Avatar Broadband Limited 188.223.128.0/18 AS35228 BEUNLIMITED Avatar Broadband Limited 188.223.192.0/18 AS35228 BEUNLIMITED Avatar Broadband Limited 188.225.0.0/17 AS48684 INTERNA-AS ISP interna, Moscow, Russia 188.225.128.0/17 AS1680 NetVision Ltd. 188.226.0.0/17 AS12668 EXTRIM-AS EXTRIM AUTONOMOUS SYSTEM 190.15.176.0/24 AS3549 GBLX Global Crossing Ltd. 190.15.177.0/24 AS3549 GBLX Global Crossing Ltd. 190.82.64.0/18 AS15311 Telefonica Empresas 190.97.32.0/23 AS27833 BVNET S.A. 190.97.34.0/23 AS27833 BVNET S.A. 190.97.36.0/23 AS27833 BVNET S.A. 190.97.38.0/23 AS27833 BVNET S.A. 190.97.40.0/23 AS27833 BVNET S.A. 190.97.42.0/23 AS27833 BVNET S.A. 190.97.44.0/23 AS27833 BVNET S.A. 190.97.46.0/23 AS27833 BVNET S.A. 190.97.48.0/23 AS27833 BVNET S.A. 190.97.50.0/23 AS27833 BVNET S.A. 190.97.52.0/23 AS27833 BVNET S.A. 190.97.54.0/23 AS27833 BVNET S.A. 190.97.56.0/23 AS27833 BVNET S.A. 190.97.58.0/23 AS27833 BVNET S.A. 190.97.60.0/23 AS27833 BVNET S.A. 190.97.62.0/23 AS27833 BVNET S.A. 190.107.112.0/24 AS28015 MERCO COMUNICACIONES 190.107.113.0/24 AS28015 MERCO COMUNICACIONES 190.107.114.0/24 AS28015 MERCO COMUNICACIONES 190.107.115.0/24 AS28015 MERCO COMUNICACIONES 190.107.116.0/24 AS28015 MERCO COMUNICACIONES 190.107.117.0/24 AS28015 MERCO COMUNICACIONES 190.107.118.0/24 AS28015 MERCO COMUNICACIONES 190.107.119.0/24 AS28015 MERCO COMUNICACIONES 190.107.120.0/24 AS28015 MERCO COMUNICACIONES 190.107.121.0/24 AS28015 MERCO COMUNICACIONES 190.107.122.0/24 AS28015 MERCO COMUNICACIONES 190.107.123.0/24 AS28015 MERCO COMUNICACIONES 190.107.126.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A. 190.107.127.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A. 190.111.176.0/20 AS27589 EOS - MOJOHOST 190.122.128.0/24 AS27953 Coop. El?ct. y de Obras y Serv. P?blico Ltda de Justiniano Posse 190.122.129.0/24 AS27953 Coop. El?ct. y de Obras y Serv. P?blico Ltda de Justiniano Posse 190.122.130.0/24 AS27953 Coop. El?ct. y de Obras y Serv. P?blico Ltda de Justiniano Posse 190.122.131.0/24 AS27953 Coop. El?ct. y de Obras y Serv. P?blico Ltda de Justiniano Posse 190.122.132.0/24 AS27953 Coop. El?ct. y de Obras y Serv. P?blico Ltda de Justiniano Posse 190.122.133.0/24 AS27953 Coop. El?ct. y de Obras y Serv. P?blico Ltda de Justiniano Posse 190.122.134.0/24 AS27953 Coop. El?ct. y de Obras y Serv. P?blico Ltda de Justiniano Posse 190.122.135.0/24 AS27953 Coop. El?ct. y de Obras y Serv. P?blico Ltda de Justiniano Posse 190.122.136.0/24 AS27953 Coop. El?ct. y de Obras y Serv. P?blico Ltda de Justiniano Posse 190.122.137.0/24 AS27953 Coop. El?ct. y de Obras y Serv. P?blico Ltda de Justiniano Posse 190.122.138.0/24 AS27953 Coop. El?ct. y de Obras y Serv. P?blico Ltda de Justiniano Posse 190.122.139.0/24 AS27953 Coop. El?ct. y de Obras y Serv. P?blico Ltda de Justiniano Posse 190.122.140.0/24 AS27953 Coop. El?ct. y de Obras y Serv. P?blico Ltda de Justiniano Posse 190.122.141.0/24 AS27953 Coop. El?ct. y de Obras y Serv. P?blico Ltda de Justiniano Posse 190.122.142.0/24 AS27953 Coop. El?ct. y de Obras y Serv. P?blico Ltda de Justiniano Posse 190.122.143.0/24 AS27953 Coop. El?ct. y de Obras y Serv. P?blico Ltda de Justiniano Posse 190.241.64.0/20 AS3790 RADIGRAFICA COSTARRICENSE 190.241.80.0/20 AS3790 RADIGRAFICA COSTARRICENSE 190.241.96.0/20 AS3790 RADIGRAFICA COSTARRICENSE 190.241.112.0/20 AS3790 RADIGRAFICA COSTARRICENSE 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.132.58.0/24 AS20141 QUALITYTECH-SUW-300 - Quality Technology Services, LLC. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 193.16.242.0/24 AS8437 UTA-AS UTA.AT Backbone 193.33.148.0/23 AS30890 EVOLVA Evolva Telecom 193.169.30.0/24 AS3.167 193.169.31.0/24 AS3.167 193.169.32.0/23 AS49346 CORD-AS Cord Ltd. 193.169.34.0/23 AS49369 AORS-AS Staff Governor and Government of the Orenburg region 193.169.36.0/23 AS49350 TINET-AS Tinet JSC 193.169.38.0/23 AS49361 YUGORSKGAZTELECOM-AS Gazprom Transgaz Yugorsk Ltd 193.169.40.0/24 AS40824 WZCOM-US - WZ Communications Inc. 193.169.42.0/23 AS2116 ASN-CATCHCOM Ventelo 193.169.48.0/23 AS49402 HERMES-SOFTLAB-AS Hermes Softlab d.o.o. 193.169.50.0/23 AS49385 MULTIELECTRONIC-AS SC MULTIELECTRONIC SRL 193.169.52.0/23 AS47165 OMKC-AS Omskie kabelnye seti Ltd. 193.169.62.0/23 AS49439 LINK-SPB-AS Link Ltd 193.169.64.0/23 AS38926 SYSTONIC-AS AS for BDL-SYSTEME SA (aka Systonic) 193.169.70.0/23 AS49456 RAFAEL RAFAEL - ARMAMENT DEVELOPMENT AUTHORITY LTD 193.169.72.0/23 AS42652 DELUNET German-Luxemburg joint Network 193.169.74.0/23 AS3292 TDC TDC Data Networks 193.169.78.0/23 AS15694 ATMAN ATMAN Autonomous System 193.169.80.0/23 AS49491 THERNET-AS PE Sukonnik Mukola Valeriyovuch 193.169.90.0/24 AS49503 CLOUDDATA Cloud Data Ltd 193.169.91.0/24 AS49503 CLOUDDATA Cloud Data Ltd 193.169.92.0/23 AS49509 BANK-ADMIRALTEISKY-AS CB Admiralteisky Ltd. 193.169.93.0/24 AS49509 BANK-ADMIRALTEISKY-AS CB Admiralteisky Ltd. 193.169.96.0/23 AS49510 TCV-AS TCV Ltd 193.169.100.0/23 AS44683 AIQU-AS Aiqu Finland Oy 193.169.108.0/23 AS16131 GRAFIX-IS GrafiX Internet B.V. 193.169.116.0/23 AS6714 ATOMNET ATOM SA 193.169.120.0/23 AS10753 LVLT-10753 - Level 3 Communications, Inc. 193.200.50.0/23 AS41297 ABAKS-AS ABAKS Adam Dlugosz 193.238.36.0/22 AS29436 ASN-IMPERIAL Imperial ISP 194.0.9.0/24 AS2484 FRNIC-DNS-ANYCAST-1 AFNIC 194.0.10.0/24 AS49488 AS_AT_TLD_SERVICES nic.at Internet Betriebs- und Verwaltungs GmbH 194.9.224.0/20 AS48166 FORTEX-AS Fortex Telecom 194.145.235.0/24 AS48445 FAVN Favorit Network SL 195.138.213.0/24 AS44683 AIQU-AS Aiqu Finland Oy 195.144.14.0/24 AS49389 STEALTH-AS Privately owned enterprise Alexsandrov Yuriy Viktorovich 195.182.13.0/24 AS49548 ASLEASEPLAN Leaseplan Corporation N.V. 195.182.214.0/23 AS49486 JUBMES-AS JUBMES banka a.d. Beograd 195.182.214.0/24 AS49486 JUBMES-AS JUBMES banka a.d. Beograd 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.216.245.0/24 AS6453 GLOBEINTERNET TATA Communications 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.5.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.19.0.0/24 AS3848 WORLDLINX-2 - WorldLinx Telecommunications, Inc. 199.114.0.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 ITCOMM - IT Communications 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.114.88.0/21 AS18747 IFX-NW - IFX Communication Ventures, Inc. 202.6.176.0/20 AS24316 202.43.66.0/24 AS18003 FPLN2-AS-AP Faktortel Pty Ltd. 202.43.67.0/24 AS45154 APPNOMIC-AS-AP Appnomic Systems Pvt Ltd 202.43.88.0/24 AS45704 INTERDATA-AS-ID MEDIA INTERDATA, PT 202.43.89.0/24 AS45704 INTERDATA-AS-ID MEDIA INTERDATA, PT 202.43.90.0/24 AS24222 OFFICETIGER-ANNANAGAR-INDIA-AS OFFICETIGER DATABASE SYSTEMS INDIA PVT LTD 202.43.100.0/24 AS45785 TECHAVENUE-IPTRANSIT-AS-AP Techavenue Sdn Bhd, Global IP Transit AS Provider, KL, Malaysia 202.43.101.0/24 AS45785 TECHAVENUE-IPTRANSIT-AS-AP Techavenue Sdn Bhd, Global IP Transit AS Provider, KL, Malaysia 202.43.102.0/24 AS45785 TECHAVENUE-IPTRANSIT-AS-AP Techavenue Sdn Bhd, Global IP Transit AS Provider, KL, Malaysia 202.43.103.0/24 AS45785 TECHAVENUE-IPTRANSIT-AS-AP Techavenue Sdn Bhd, Global IP Transit AS Provider, KL, Malaysia 202.43.112.0/23 AS45325 PC24-AS-ID PC24 Cyber Indonesia, PT 202.43.116.0/24 AS45707 PRIMELINK-AS-ID Prime Link Communication, PT 202.43.117.0/24 AS45707 PRIMELINK-AS-ID Prime Link Communication, PT 202.43.120.0/22 AS9919 NCIC-TW New Century InfoComm Tech Co., Ltd. 202.43.124.0/24 AS38193 TWA-AS-AP Transworld (Pvt.) Ltd. 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.92.48.0/20 AS23704 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS2764 AAPT AAPT Limited 202.124.195.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.89.151.0/24 AS45825 LISTER-TECHNOLOGIES Lister Technologies (P) Ltd. 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.135.189.0/24 AS45802 GENENET-AP 1 DNA Way 203.135.190.0/23 AS45808 UTP-MY Bandar Seri Iskandar 203.152.154.0/23 AS9583 SIFY-AS-IN Sify Limited 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.217.132.0/23 AS45709 GMNUSANTARA-AS-ID Graha Multimedia Nusantara, PT 203.217.134.0/23 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 203.217.140.0/24 AS45293 UT-AS-ID Universitas Terbuka 203.217.156.0/22 AS10000 NCM Nagasaki Cable Media Inc. 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.12.0.0/18 AS20021 LNH-INC - HostMySite 204.12.192.0/18 AS32097 WII-KC - WholeSale Internet, Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.13.140.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.141.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.142.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.143.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.184.0/23 AS35967 204.13.186.0/23 AS35967 204.13.186.0/24 AS35967 204.13.187.0/24 AS35967 204.19.14.0/23 AS577 BACOM - Bell Canada 204.51.64.0/18 AS23148 TERREMARK Terremark 204.51.128.0/17 AS26228 SERVEPATH - ServePath, LLC 204.52.96.0/20 AS31851 101-WEB-HOSTING-SERVICE-LLC - 101 Web Hosting Services, LLC 204.63.0.0/20 AS32335 PACIFICINTERNETEXCHANGE-NET - Pacific Internet Exchange LLC. 204.74.208.0/20 AS20248 TAKE2 - Take 2 Hosting, Inc. 204.74.224.0/20 AS46717 EVERN-1 - Evernet Hosting 204.77.224.0/19 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.93.128.0/18 AS23352 SERVERCENTRAL - Server Central Network 204.138.167.0/24 AS18990 AIRBAND-DALLAS - Airband Communications, Inc 204.145.96.0/20 AS7459 GRANDECOM-AS1 - Grande Communications Networks, Inc. 204.188.192.0/18 AS46844 ST-BGP - SHARKTECH INTERNET SERVICES 204.232.64.0/20 AS21570 ACI-1 - Accelerated Connections Inc. 204.236.64.0/18 AS8014 BATELNET - Bahamas Telecommunications Corporation 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.151.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.158.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.177.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.178.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.177.93.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 212.80.0.0/19 AS44889 AZMA-AS AZMA GROUP - FACC Compnay 212.80.0.0/21 AS44889 AZMA-AS AZMA GROUP - FACC Compnay 212.80.8.0/21 AS44889 AZMA-AS AZMA GROUP - FACC Compnay 212.80.16.0/21 AS44889 AZMA-AS AZMA GROUP - FACC Compnay 212.80.24.0/21 AS44889 AZMA-AS AZMA GROUP - FACC Compnay 212.101.224.0/24 AS31126 SODETEL-AS SODETEL SAL 212.101.225.0/24 AS31126 SODETEL-AS SODETEL SAL 213.108.24.0/22 AS34305 EUROACCESS Euroaccess Global Autonomous System 213.108.29.0/24 AS34305 EUROACCESS Euroaccess Global Autonomous System 213.108.30.0/23 AS39326 GOSCOMB-AS Goscomb Technologies Limited 213.108.32.0/21 AS47333 HIGHLINK-SPB-AS HighLink Ltd 213.175.128.0/21 AS44972 COBBETT Cobbett Hill Earth Station Limited 213.175.136.0/24 AS44972 COBBETT Cobbett Hill Earth Station Limited 213.175.137.0/24 AS44972 COBBETT Cobbett Hill Earth Station Limited 213.175.140.0/22 AS44972 COBBETT Cobbett Hill Earth Station Limited 213.181.70.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.80.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.81.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.82.0/23 AS17175 NSS-UK New Skies Satellites UK AS 213.181.82.0/24 AS17175 NSS-UK New Skies Satellites UK AS 213.181.83.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.84.0/22 AS17175 NSS-UK New Skies Satellites UK AS 213.181.84.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.85.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.86.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.87.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.88.0/21 AS17175 NSS-UK New Skies Satellites UK AS 213.181.88.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.89.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.90.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.91.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.92.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.93.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.94.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.95.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.229.64.0/18 AS29550 EUROCONNEX-AS Blueconnex Networks Ltd 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.26.16.0/20 AS41783 ITAEC-AS ITaEC LLC autonomous system 217.73.80.0/20 AS44291 INFOMIR-NET Infomir JSC 217.78.71.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.72.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.73.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.172.128.0/21 AS33854 HOST-IT-AS Host-It Internet Solutions Datacentre 217.174.48.0/21 AS29084 COMNET-AS Comnet Bulgaria Holding Ltd. 217.174.56.0/22 AS29084 COMNET-AS Comnet Bulgaria Holding Ltd. 217.174.61.0/24 AS29084 COMNET-AS Comnet Bulgaria Holding Ltd. 217.174.62.0/24 AS29084 COMNET-AS Comnet Bulgaria Holding Ltd. 217.174.63.0/24 AS29084 COMNET-AS Comnet Bulgaria Holding Ltd. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From tme at americafree.tv Fri Jul 3 18:23:20 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 3 Jul 2009 19:23:20 -0400 Subject: Fire, Power loss at Fisher Plaza in Seattle In-Reply-To: <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> Message-ID: <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> On Jul 3, 2009, at 5:11 PM, Jeffrey Lyon wrote: > That's a great idea, use some lame Web 2.0 trend to communicate with > actual real life customers. > I would assume they figured it was better than just remaining silent. Regards Marshall > Jeff > > > On Fri, Jul 3, 2009 at 4:59 PM, Marshall Eubanks > wrote: >> >> On Jul 3, 2009, at 4:29 PM, Ben Carleton wrote: >> >>> Yes it was. >>> >>> On Jul 3, 2009, at 4:29 PM, Jeffrey Lyon wrote: >>> >>>> Wasn't Authorize.net affected by this? We received a support ticket >>>> about why Authorize.net is down today (I don't know either, I don't >>>> ask too many questions). >>>> >> >> Authorize.net was for a while completely off the air, and companies >> that >> relied upon them >> were not getting credit card authorizations (and, thus, no >> ecommerce). I >> think it is still only >> partially functional. >> >> Authorize.net has been communicating with customers mostly >> (entirely ?) with >> twitter - they are >> >> @AuthorizeNet with a hash tab of #authorizenet >> >> If you go there, you will see a lot of status messages like >> >> #authorizenet (cont.) Do not manually submit ARB transactions b/c >> you run >> the risk of your merchants being double billed. >> 10 minutes ago from web >> >> (i.e., 4:47 EDT). >> >> You will also see a lot of posts from annoyed people if you search on >> #authorizenet >> >> It's an interesting use of Web 2.0 for emergency communications. >> >> Regards >> Marshall >> >> >>>> Jeff >>>> >>>> On Fri, Jul 3, 2009 at 4:21 PM, Tomas L. Byrnes >>>> wrote: >>>>> >>>>> >>>>>> >>>>>> Earth is a single point of failure, where is your backup site? >>>>> >>>>> [TLB:] Given that all my customers are on Earth, I don't need >>>>> one if my >>>>> customers also are "down". >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Jeffrey Lyon, Leadership Team >>>> jeffrey.lyon at blacklotus.net | http://www.blacklotus.net >>>> Black Lotus Communications of The IRC Company, Inc. >>>> >>>> Look for us at HostingCon 2009 in Washington, DC on August 10th - >>>> 12th >>>> at Booth #401. >>>> >>> >>> >>> >> >> >> >> > > > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications of The IRC Company, Inc. > > Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th > at Booth #401. > > Regards Marshall Eubanks CEO / AmericaFree.TV From lists at internetpolicyagency.com Sat Jul 4 05:17:49 2009 From: lists at internetpolicyagency.com (Roland Perry) Date: Sat, 4 Jul 2009 11:17:49 +0100 Subject: Using twitter as an outage notification (was: Fire, Power loss at Fisher Plaza in Seattle) In-Reply-To: <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> Message-ID: In article <786BA8C0-B534-40FF-9126-1E33BD11CB3C at americafree.tv>, Marshall Eubanks writes >> That's a great idea, use some lame Web 2.0 trend to communicate with >> actual real life customers. >> >I would assume they figured it was better than just remaining silent. I'm about to recommend to an organisation that it [a twitter account] is better than posting news of an outage on their low-volume website, which will get swamped when too many people poll it for news. What does the team think? Paying a lot more to host the website with higher "burst" capacity during an emergency, isn't an option. The only other idea I've had is to sign all the customers up to receive an SMS via some sort of broadcast service (the news will fit easily in one SMS). -- Roland Perry From brandon at rd.bbc.co.uk Sat Jul 4 07:22:57 2009 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sat, 4 Jul 2009 13:22:57 +0100 (BST) Subject: Using twitter as an outage notification (was: Fire, Power loss at Fisher Plaza in Seattle) Message-ID: <200907041222.NAA23352@sunf10.rd.bbc.co.uk> > Paying a lot more to host the website with higher "burst" capacity > during an emergency, isn't an option. > > The only other idea I've had is to sign all the customers up to receive > an SMS via some sort of broadcast service (the news will fit easily in > one SMS). If the event is suitably calamitous we will do that for you - http://news.bbc.co.uk/1/hi/help/5194672.stm brandon From lists at internetpolicyagency.com Sat Jul 4 07:52:39 2009 From: lists at internetpolicyagency.com (Roland Perry) Date: Sat, 4 Jul 2009 13:52:39 +0100 Subject: Using twitter as an outage notification (was: Fire, Power loss at Fisher Plaza in Seattle) In-Reply-To: <200907041222.NAA23352@sunf10.rd.bbc.co.uk> References: <200907041222.NAA23352@sunf10.rd.bbc.co.uk> Message-ID: In article <200907041222.NAA23352 at sunf10.rd.bbc.co.uk>, Brandon Butterworth writes >> Paying a lot more to host the website with higher "burst" capacity >> during an emergency, isn't an option. >> >> The only other idea I've had is to sign all the customers up to receive >> an SMS via some sort of broadcast service (the news will fit easily in >> one SMS). > >If the event is suitably calamitous we will do that for you - > >http://news.bbc.co.uk/1/hi/help/5194672.stm The "event" (typically closing a High School because of snow, but we have swine flu these days too) is currently reported mainly by local radio stations. However it doesn't scale - there are perhaps two hundred of them trying to phone in to one radio station during the same 15 minutes after they made the decision, half an hour before the school is supposed to open for the day. Another problem with a literally "broadcast" system is that it takes them too long to read out the names of the schools which are closed, even if trying to cover just one county. Nor does it matter to anyone except a particular closed group of perhaps 1000 households whether any one school is closed - so telling everyone is a bit of a waste. So it seemed to me that a Tweet from the school would be an ideal solution. But a system like yours, if it could be divided up into a few tens of thousands of SIGs (one for each school), is the kind of "more traditional" solution I was thinking about. -- Roland Perry From tme at americafree.tv Sat Jul 4 08:47:58 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Sat, 4 Jul 2009 09:47:58 -0400 Subject: Using twitter as an outage notification (was: Fire, Power loss at Fisher Plaza in Seattle) In-Reply-To: References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> Message-ID: On Jul 4, 2009, at 6:17 AM, Roland Perry wrote: > In article <786BA8C0-B534-40FF-9126-1E33BD11CB3C at americafree.tv>, > Marshall Eubanks writes >>> That's a great idea, use some lame Web 2.0 trend to communicate with >>> actual real life customers. >>> >> I would assume they figured it was better than just remaining silent. > > I'm about to recommend to an organisation that it [a twitter > account] is better than posting news of an outage on their low- > volume website, which will get swamped when too many people poll it > for news. > What if the outage takes out their website too ? I don't think that their website was up, and I would guess that they didn't have email either. That is a bad situation to be in. Note, BTW, that twitter itself is subject to frequent planned and unplanned outages. Marshall > What does the team think? > > Paying a lot more to host the website with higher "burst" capacity > during an emergency, isn't an option. > > The only other idea I've had is to sign all the customers up to > receive an SMS via some sort of broadcast service (the news will fit > easily in one SMS). > -- > Roland Perry > > Regards Marshall Eubanks CEO / AmericaFree.TV From jcdill.lists at gmail.com Sat Jul 4 08:50:52 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Sat, 04 Jul 2009 06:50:52 -0700 Subject: Using twitter as an outage notification In-Reply-To: References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> Message-ID: <4A4F5E3C.5040301@gmail.com> Roland Perry wrote: > In article <786BA8C0-B534-40FF-9126-1E33BD11CB3C at americafree.tv>, > Marshall Eubanks writes >>> That's a great idea, use some lame Web 2.0 trend to communicate with >>> actual real life customers. >>> >> I would assume they figured it was better than just remaining silent. > > I'm about to recommend to an organisation that it [a twitter account] > is better than posting news of an outage on their low-volume website, > which will get swamped when too many people poll it for news. > > What does the team think? I don't understand why this is an either/or question. Why not post to both? Twitter is a great method of communication, for those that use twitter. But some people don't use twitter. So use every avenue you have. If you have a customer mailing list for announcements, send email. If you have a blog, post to the blog. I'm in the process of setting up posterous to post to a blog, myspace, facebook, and twitter all with one email. Can't get much simpler than that for getting the word out via all the channels (assuming that outbound email is working). (Obviously some businesses don't want/need myspace or facebook, but if you use them, post there too.) http://posterous.com/autopost Quoting: How does autoposting work? Just set up your other accounts here. The next time you post to posterous, we will instantly autopost everywhere else. Facebook profile newsfeeds will be updated each time you post to notify your friends. You can also autopost photos to your photo album and embed your blog directly in your profile. Twitter messages will use the title of your post up to 130 characters, and then append a shortened post.ly url. Flickr photos will be put automatically in your photostream. If you attach multiple photos, we'll post them all in the order we receive them. Blogs will be updated with the full content you send us. We'll host your images, music and files, so you don't have to lift a finger. You control where we post. Just email the right address and we'll do the right thing. Post Everywhere? post at posterous.com as usual Twitter? twitter at posterous.com Flickr? flickr at posterous.com Facebook? facebook at posterous.com Tumblr? tumblr at posterous.com Any other blog? blog at posterous.com Posterous only? posterous at posterous.com Combine them! flickr+twitter at posterous.com You can also address an email to #{text}@posterous.com and it will post to any site where the url contains that text. #apple at posterous.com will go to apple.wordpress.com and flickr.com/apple, but NOT banana.blogspot.com. jc From lists at internetpolicyagency.com Sat Jul 4 09:43:16 2009 From: lists at internetpolicyagency.com (Roland Perry) Date: Sat, 4 Jul 2009 15:43:16 +0100 Subject: Using twitter as an outage notification (was: Fire, Power loss at Fisher Plaza in Seattle) In-Reply-To: References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> Message-ID: In article , Marshall Eubanks writes >>>> That's a great idea, use some lame Web 2.0 trend to communicate with >>>> actual real life customers. >>>> >>> I would assume they figured it was better than just remaining silent. >> >> I'm about to recommend to an organisation that it [a twitter account] >>is better than posting news of an outage on their low- volume website, >>which will get swamped when too many people poll it for news. > >What if the outage takes out their website too ? The website is hosted elsewhere, however the entire message can be delivered in one Tweet, so there's no need to confirm by looking at a website. >I don't think that their website was up, and I would guess that they >didn't have email either. That is a bad situation to be in. They don't plan to respond to email in real time. >Note, BTW, that twitter itself is subject to frequent planned and >unplanned outages. The question being, how often will they co-incide with the events I'm trying to track? fwiw, I've been using twitter for about three months now, and have never encountered either kind of outage. -- Roland Perry From jeffrey.lyon at blacklotus.net Sat Jul 4 09:47:53 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 4 Jul 2009 10:47:53 -0400 Subject: Using twitter as an outage notification (was: Fire, Power loss at Fisher Plaza in Seattle) In-Reply-To: References: <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> Message-ID: <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> Personally, I find it difficult to take Twitter seriously. It seems like more of a kids toy than a business tool. Something like a blogspot account would make a lot more sense. Jeff On 7/4/09, Marshall Eubanks wrote: > > On Jul 4, 2009, at 6:17 AM, Roland Perry wrote: > > > > In article > <786BA8C0-B534-40FF-9126-1E33BD11CB3C at americafree.tv>, > Marshall Eubanks writes > > > > > > > > > That's a great idea, use some lame Web 2.0 trend to communicate with > > > > actual real life customers. > > > > > > > > > > > I would assume they figured it was better than just remaining silent. > > > > > > > I'm about to recommend to an organisation that it [a twitter account] is > better than posting news of an outage on their low-volume website, which > will get swamped when too many people poll it for news. > > > > > > What if the outage takes out their website too ? > > I don't think that their website was up, and I would guess that they didn't > have email either. That > is a bad situation to be in. > > Note, BTW, that twitter itself is subject to frequent planned and unplanned > outages. > > Marshall > > > > What does the team think? > > > > Paying a lot more to host the website with higher "burst" capacity during > an emergency, isn't an option. > > > > The only other idea I've had is to sign all the customers up to receive an > SMS via some sort of broadcast service (the news will fit easily in one > SMS). > > -- > > Roland Perry > > > > > > > > Regards > Marshall Eubanks > CEO / AmericaFree.TV > > > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From lists at internetpolicyagency.com Sat Jul 4 09:50:08 2009 From: lists at internetpolicyagency.com (Roland Perry) Date: Sat, 4 Jul 2009 15:50:08 +0100 Subject: Using twitter as an outage notification In-Reply-To: <4A4F5E3C.5040301@gmail.com> References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <4A4F5E3C.5040301@gmail.com> Message-ID: In article <4A4F5E3C.5040301 at gmail.com>, JC Dill writes >>>> That's a great idea, use some lame Web 2.0 trend to communicate with >>>> actual real life customers. >>>> >>> I would assume they figured it was better than just remaining silent. >> >> I'm about to recommend to an organisation that it [a twitter account] >>is better than posting news of an outage on their low-volume website, >>which will get swamped when too many people poll it for news. >> >> What does the team think? > >I don't understand why this is an either/or question. Why not post to both? Yes, that can be done. What I'm trying to anticipate is the objection to *also* posting to Twitter, which might be raised on the grounds that it's too "unofficial", or "unsupported" or something like that. >You control where we post. > >Just email the right address and we'll do the right thing. >Post Everywhere? post at posterous.com as usual >Twitter? twitter at posterous.com >Flickr? flickr at posterous.com >Facebook? facebook at posterous.com >Tumblr? tumblr at posterous.com >Any other blog? blog at posterous.com >Posterous only? posterous at posterous.com >Combine them! flickr+twitter at posterous.com It's this richness which confuses the ordinary person. How are they to know which bit of the scattergun approach is the right one to use? Or whether "posting everywhere" has some hidden disadvantage. -- Roland Perry From m.hallgren at free.fr Sat Jul 4 09:58:18 2009 From: m.hallgren at free.fr (Michael Hallgren) Date: Sat, 04 Jul 2009 16:58:18 +0200 Subject: Using twitter as an outage notification (was: Fire, Power loss at Fisher Plaza in Seattle) In-Reply-To: <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> References: <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> Message-ID: <1246719498.4172.15.camel@home> Le samedi 04 juillet 2009 ? 10:47 -0400, Jeffrey Lyon a ?crit : > Personally, I find it difficult to take Twitter seriously. It seems > like more of a kids toy than a business tool. Something like a > blogspot account would make a lot more sense. Yes. What about (continue to) use old email (inc lists), coupled with some roughly out-of-band like cell/pots/sms service? And in parallel old irc, et al. Any severe problem with, asking us to move over to "portal services"? mh > > Jeff > > > > On 7/4/09, Marshall Eubanks wrote: > > > > On Jul 4, 2009, at 6:17 AM, Roland Perry wrote: > > > > > > > In article > > <786BA8C0-B534-40FF-9126-1E33BD11CB3C at americafree.tv>, > > Marshall Eubanks writes > > > > > > > > > > > > That's a great idea, use some lame Web 2.0 trend to communicate with > > > > > actual real life customers. > > > > > > > > > > > > > > I would assume they figured it was better than just remaining silent. > > > > > > > > > > I'm about to recommend to an organisation that it [a twitter account] is > > better than posting news of an outage on their low-volume website, which > > will get swamped when too many people poll it for news. > > > > > > > > > > What if the outage takes out their website too ? > > > > I don't think that their website was up, and I would guess that they didn't > > have email either. That > > is a bad situation to be in. > > > > Note, BTW, that twitter itself is subject to frequent planned and unplanned > > outages. > > > > Marshall > > > > > > > What does the team think? > > > > > > Paying a lot more to host the website with higher "burst" capacity during > > an emergency, isn't an option. > > > > > > The only other idea I've had is to sign all the customers up to receive an > > SMS via some sort of broadcast service (the news will fit easily in one > > SMS). > > > -- > > > Roland Perry > > > > > > > > > > > > > Regards > > Marshall Eubanks > > CEO / AmericaFree.TV > > > > > > > > > > > > -- michael hallgren, mh2198-ripe From jcdill.lists at gmail.com Sat Jul 4 10:02:13 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Sat, 04 Jul 2009 08:02:13 -0700 Subject: Using twitter as an outage notification In-Reply-To: References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <4A4F5E3C.5040301@gmail.com> Message-ID: <4A4F6EF5.9030502@gmail.com> Roland Perry wrote: > > What I'm trying to anticipate is the objection to *also* posting to > Twitter, which might be raised on the grounds that it's too > "unofficial", or "unsupported" or something like that. Anyone who makes that argument is just showing how little they know about Twitter. It would be like complaining you shouldn't use email because "not everyone has email". >> You control where we post. >> >> Just email the right address and we'll do the right thing. >> Post Everywhere? post at posterous.com as usual >> Twitter? twitter at posterous.com >> Flickr? flickr at posterous.com >> Facebook? facebook at posterous.com >> Tumblr? tumblr at posterous.com >> Any other blog? blog at posterous.com >> Posterous only? posterous at posterous.com >> Combine them! flickr+twitter at posterous.com > > It's this richness which confuses the ordinary person. That's a lot like saying Perl is too complicated for the ordinary person so never use Perl. :-) > How are they to know which bit of the scattergun approach is the right > one to use? Or whether "posting everywhere" has some hidden disadvantage. You can configure it and use it however YOU want. If it's too confusing to use it selectively - sometimes posting in all places, sometimes posting in just one place, then configure it for your preferred use and use the regular "post everywhere" method each time you post. For network outage announcements it would work perfectly to post to Twitter and your company blog(s) in one step. Bonus - if it can't reach one system at least the post gets posted on the other system. For this reason your company may want to setup a shadow blog on one of the free blogging platforms, in addition to a blog on the company website. This way if your website is down, the news on the other blog is still out there for those that follow the blog to find/read. The configurable aspects of posterous are most helpful for people who have more diverse posting habits - who want to post news to some (but not all) channels, who sometimes post chatty things they want to go to facebook, sometimes post business things they don't want to go to facebook, who post photos they want to go to flickr and facebook but not their blog, etc. If you are active with social networking it would be perfect. I you just use it as an announcement tool, just use the defaults. jc From lists at internetpolicyagency.com Sat Jul 4 10:07:52 2009 From: lists at internetpolicyagency.com (Roland Perry) Date: Sat, 4 Jul 2009 16:07:52 +0100 Subject: Using twitter as an outage notification (was: Fire, Power loss at Fisher Plaza in Seattle) In-Reply-To: <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> References: <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> Message-ID: In article <16720fe00907040747k67ca1206kb871420deb5e8163 at mail.gmail.com>, Jeffrey Lyon writes >Personally, I find it difficult to take Twitter seriously. It seems >like more of a kids toy than a business tool. Something like a >blogspot account would make a lot more sense. That's the kind of "marketing-led" response I was hoping to hear. But the UK National Rail system now uses Tweets to tell customers about disruptions on the trains, and several major UK government departments and news organisations use it for announcements and "Breaking News". So has it become "respectable" yet? -- Roland Perry From lists at internetpolicyagency.com Sat Jul 4 10:16:27 2009 From: lists at internetpolicyagency.com (Roland Perry) Date: Sat, 4 Jul 2009 16:16:27 +0100 Subject: Using twitter as an outage notification In-Reply-To: <4A4F6EF5.9030502@gmail.com> References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <4A4F5E3C.5040301@gmail.com> <4A4F6EF5.9030502@gmail.com> Message-ID: <9GmVknjLJ3TKFAsq@perry.co.uk> In article <4A4F6EF5.9030502 at gmail.com>, JC Dill writes >> What I'm trying to anticipate is the objection to *also* posting to >>Twitter, which might be raised on the grounds that it's too >>"unofficial", or "unsupported" or something like that. >Anyone who makes that argument is just showing how little they know >about Twitter. So that's 98% of the population then... >It would be like complaining you shouldn't use email because "not >everyone has email". But email has become respectable, although I still see "people who know better" starting speeches with 'of course, ten years ago none of us used email, but now....' which shows they are very late adopters themselves. >>> You control where we post. >>> >>> Just email the right address and we'll do the right thing. >>> Post Everywhere? post at posterous.com as usual >>> Twitter? twitter at posterous.com >>> Flickr? flickr at posterous.com >>> Facebook? facebook at posterous.com >>> Tumblr? tumblr at posterous.com >>> Any other blog? blog at posterous.com >>> Posterous only? posterous at posterous.com >>> Combine them! flickr+twitter at posterous.com >> >> It's this richness which confuses the ordinary person. >That's a lot like saying Perl is too complicated for the ordinary >person so never use Perl. :-) You are confusing the tool with the platform. >> How are they to know which bit of the scattergun approach is the >>right one to use? Or whether "posting everywhere" has some hidden >>disadvantage. > >You can configure it and use it however YOU want. Again, that's about the platform called posterous. How can I explain to the School Board that posterous has enough credibility to be used. I don't think it has. All they ever hear about other Web2.0 like Facebook and Bebo is how dangerous they are for kids. But I'm beginning to think that finally maybe Twitter has the right profile for this application. -- Roland Perry From up at 3.am Sat Jul 4 10:20:24 2009 From: up at 3.am (up at 3.am) Date: Sat, 4 Jul 2009 11:20:24 -0400 (EDT) Subject: Level 3 - "legacy" Wiltel/Looking Glass bandwidth In-Reply-To: References: Message-ID: On Wed, 1 Jul 2009, Scott Howard wrote: > We're looking at getting connectivity via Level 3 in a particular > datacenter, but we're being told that it's "legacy Wiltel/Looking Glass" > rather than "true" Level 3. > > Given that both of these acquisitions occurred years ago should I be > worried, or is this "legacy" connectivity the same as L3 at any other > datacenter? While I cannot speak directly to their treatment of former Wiltel customers, I can tell you that once they acquired Broadwing, service in their Norristown, PA data center went from not-so-great to completely unacceptable. IIRC, we've had about 6 multi-hour outages in the past year. Apparently, that data center is connected to their Philly POP via a Foundry Big Iron switch that suffers from broadcast storms periodically, which can only be fixed by their dispatching a tech to Philly to power-cycle it, which for some reason takes from 1 to 4 hours. Why they're not familiar with remote-power cycling equipment is beyond me, let alone why they haven't resolved the issue properly, despite having supposedly replaced hardware at one point. My 3 year contract is up next month, after which I am so out of there. The fact that L3 tried to double their price on me in the middle of that contract, only backing down after getting two lawyers involved, didn't help my opinion of them as a company, either. James Smallacombe PlantageNet, Inc. CEO and Janitor up at 3.am http://3.am ========================================================================= From chaz at chaz6.com Sat Jul 4 10:22:04 2009 From: chaz at chaz6.com (Chris Hills) Date: Sat, 04 Jul 2009 17:22:04 +0200 Subject: Using twitter as an outage notification In-Reply-To: References: <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> Message-ID: On 04/07/09 17:07, Roland Perry wrote: > That's the kind of "marketing-led" response I was hoping to hear. > > But the UK National Rail system now uses Tweets to tell customers about > disruptions on the trains, and several major UK government departments > and news organisations use it for announcements and "Breaking News". > > So has it become "respectable" yet? When there are open-source equivalents available (e.g. Laconica, OpenMicroBlogger - both of which incidentally are compatible since they are based upon the OMB spec), I do wonder why a commercial or government entity would use a closed-source, non-domestic service. From m.hallgren at free.fr Sat Jul 4 10:26:16 2009 From: m.hallgren at free.fr (Michael Hallgren) Date: Sat, 04 Jul 2009 17:26:16 +0200 Subject: Using twitter as an outage notification (was: Fire, Power loss at Fisher Plaza in Seattle) In-Reply-To: <1246719498.4172.15.camel@home> References: <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> <1246719498.4172.15.camel@home> Message-ID: <1246721176.4172.24.camel@home> Le samedi 04 juillet 2009 ? 16:58 +0200, Michael Hallgren a ?crit : > Le samedi 04 juillet 2009 ? 10:47 -0400, Jeffrey Lyon a ?crit : > > Personally, I find it difficult to take Twitter seriously. It seems > > like more of a kids toy than a business tool. Something like a > > blogspot account would make a lot more sense. > > Yes. > > What about (continue to) use old email (inc lists), coupled with > some roughly out-of-band like cell/pots/sms service? And in parallel > old irc, et al. > > Any severe problem with, asking us to move over to "portal > services"? Of course not negative with respect to new innovative means... But if we didn't have pidgin: msn, yahoo!, gtalk, icq, facebook,... ... would be hard to manage... and remember who's message to track via what channel... So, the channel I think is much dependent on the audience. The crowd small enough, most any means will be fine. The crowd more universal, well-known, stable communication protocols should be a natural choice. No? mh > > mh > > > > Jeff > > > > > > > > On 7/4/09, Marshall Eubanks wrote: > > > > > > On Jul 4, 2009, at 6:17 AM, Roland Perry wrote: > > > > > > > > > > In article > > > <786BA8C0-B534-40FF-9126-1E33BD11CB3C at americafree.tv>, > > > Marshall Eubanks writes > > > > > > > > > > > > > > > That's a great idea, use some lame Web 2.0 trend to communicate with > > > > > > actual real life customers. > > > > > > > > > > > > > > > > > I would assume they figured it was better than just remaining silent. > > > > > > > > > > > > > I'm about to recommend to an organisation that it [a twitter account] is > > > better than posting news of an outage on their low-volume website, which > > > will get swamped when too many people poll it for news. > > > > > > > > > > > > > > What if the outage takes out their website too ? > > > > > > I don't think that their website was up, and I would guess that they didn't > > > have email either. That > > > is a bad situation to be in. > > > > > > Note, BTW, that twitter itself is subject to frequent planned and unplanned > > > outages. > > > > > > Marshall > > > > > > > > > > What does the team think? > > > > > > > > Paying a lot more to host the website with higher "burst" capacity during > > > an emergency, isn't an option. > > > > > > > > The only other idea I've had is to sign all the customers up to receive an > > > SMS via some sort of broadcast service (the news will fit easily in one > > > SMS). > > > > -- > > > > Roland Perry > > > > > > > > > > > > > > > > > > Regards > > > Marshall Eubanks > > > CEO / AmericaFree.TV > > > > > > > > > > > > > > > > > > > -- michael hallgren, mh2198-ripe From mike at delusion.org Sat Jul 4 10:33:02 2009 From: mike at delusion.org (mike) Date: Sat, 04 Jul 2009 08:33:02 -0700 Subject: Using twitter as an outage notification In-Reply-To: References: <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> Message-ID: <4A4F762E.8070503@delusion.org> Roland Perry wrote: > In article > <16720fe00907040747k67ca1206kb871420deb5e8163 at mail.gmail.com>, Jeffrey > Lyon writes >> Personally, I find it difficult to take Twitter seriously. It seems >> like more of a kids toy than a business tool. Something like a >> blogspot account would make a lot more sense. > > That's the kind of "marketing-led" response I was hoping to hear. > > But the UK National Rail system now uses Tweets to tell customers > about disruptions on the trains, and several major UK government > departments and news organisations use it for announcements and > "Breaking News". > > So has it become "respectable" yet? there are plenty of examples where twitter is being used for useful notifications. in the sf bay area, there's a user maintained version of what you describe for our commuter rail. a large example of this is comcast's customer service (see http://twitter.com/comcastcares) personally, i like the twitter idea. i can follow/unfollow at will, i can set up sms alerts for specific "users" i follow, etc. sure, twitter had some stability issues, but i think if we're being fair, they've been very stable of late. sure, twitter might be down at the same time, but it seems more likely that the website for the provider in question would be affected and twitter can be updated very quickly using a cell phone either with a twitter app or simply via sms. just my $0.02 worth (perhaps $0.03 and perhaps not worth over $0.01) +m From lists at internetpolicyagency.com Sat Jul 4 10:37:38 2009 From: lists at internetpolicyagency.com (Roland Perry) Date: Sat, 4 Jul 2009 16:37:38 +0100 Subject: Using twitter as an outage notification In-Reply-To: References: <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> Message-ID: <2XUHAbmCd3TKFAtT@perry.co.uk> In article , Chris Hills writes >> That's the kind of "marketing-led" response I was hoping to hear. >> >> But the UK National Rail system now uses Tweets to tell customers about >> disruptions on the trains, and several major UK government departments >> and news organisations use it for announcements and "Breaking News". >> >> So has it become "respectable" yet? > >When there are open-source equivalents available (e.g. Laconica, >OpenMicroBlogger - both of which incidentally are compatible since they >are based upon the OMB spec), I do wonder why a commercial or >government entity would use a closed-source, non-domestic service. That's fair comment, but how do you get your customers to install quirky niche solutions to what's a once-a-year problem? They all seem pretty happy using a multitude of other "non-domestic" solutions, which probably accounts for 99% of the stuff they have on their PCs. So "not sufficiently mature" we can get away with as an excuse, but "Made in America" isn't going to put many people off :) -- Roland Perry From frnkblk at iname.com Sat Jul 4 15:43:33 2009 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 4 Jul 2009 15:43:33 -0500 Subject: Fire, Power loss at Fisher Plaza in Seattle In-Reply-To: <20090703203957.GA75570@ussenterprise.ufp.org> References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <20090703203957.GA75570@ussenterprise.ufp.org> Message-ID: Leo: That presumes the people at the bottom care about the big picture. I'd hazard to guess that the people who participate in this listserv *do* care, but if Dilbert has even any correlation to real life, then just as often there are people who build DNS/DHCP/etc redundantly because that's what they were told to do, but don't have the initiative or weren't directed to look at the bigger picture. At the end of the day it depends on these grunts' managers to be sure that things are being designed and implemented properly. And even then, we know how personalities, resources, and internal inertia more of than not develop and grow networks that aren't BCP-friendly. Frank -----Original Message----- From: Leo Bicknell [mailto:bicknell at ufp.org] Sent: Friday, July 03, 2009 3:40 PM To: NANOG list Subject: Re: Fire, Power loss at Fisher Plaza in Seattle Very few companies consider these choices rationally; often because choices are made by different groups. I am amazed how many times inside of an ISP the folks deploying the DNS and mail servers are firewalled from the folks deploying the network, to the point where you have to get to the President to reach common management. This leads to them making choices in opposite directions that end up costing extra money the company, and often resulting in a much lower uptimes than expected. Having the network group deploy a single point of failure to the "Tier 4" data center the server guys required is, well, silly. From frnkblk at iname.com Sat Jul 4 15:59:48 2009 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 4 Jul 2009 15:59:48 -0500 Subject: Using twitter as an outage notification In-Reply-To: <2XUHAbmCd3TKFAtT@perry.co.uk> References: <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> <2XUHAbmCd3TKFAtT@perry.co.uk> Message-ID: When the local power companies uses twitter, then maybe I'll consider using twitter for our customers. There's the temptation by some of companies to leverage the latest technology to appear "cool" and "in tune" with customers, but by far and large, when something goes down customers either do no nothing, wait, or call in. I think the best use of everyone's time is to make sure their call center/support desk has the capability to post an announcement to those that call in. And then make sure something gets posted to the website. SMS, Facebook, and Twitter fall in line after all that. Frank -----Original Message----- From: Roland Perry [mailto:lists at internetpolicyagency.com] Sent: Saturday, July 04, 2009 10:38 AM To: nanog at merit.edu Subject: Re: Using twitter as an outage notification In article , Chris Hills writes >> That's the kind of "marketing-led" response I was hoping to hear. >> >> But the UK National Rail system now uses Tweets to tell customers about >> disruptions on the trains, and several major UK government departments >> and news organisations use it for announcements and "Breaking News". >> >> So has it become "respectable" yet? > >When there are open-source equivalents available (e.g. Laconica, >OpenMicroBlogger - both of which incidentally are compatible since they >are based upon the OMB spec), I do wonder why a commercial or >government entity would use a closed-source, non-domestic service. That's fair comment, but how do you get your customers to install quirky niche solutions to what's a once-a-year problem? They all seem pretty happy using a multitude of other "non-domestic" solutions, which probably accounts for 99% of the stuff they have on their PCs. So "not sufficiently mature" we can get away with as an excuse, but "Made in America" isn't going to put many people off :) -- Roland Perry From marc at let.de Sat Jul 4 16:07:22 2009 From: marc at let.de (Marc Manthey) Date: Sat, 4 Jul 2009 23:07:22 +0200 Subject: Using twitter as an outage notification In-Reply-To: References: <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> <2XUHAbmCd3TKFAtT@perry.co.uk> Message-ID: Am 04.07.2009 um 22:59 schrieb Frank Bulk: > When the local power companies uses twitter, then maybe I'll > consider using > twitter for our customers. well it seems popular http://www.dell.com/twitter dell made some money with it too http://en.community.dell.com/blogs/direct2dell/archive/2009/06/11/delloutlet-surpasses-2-million-on-twitter.aspx :-)) > > There's the temptation by some of companies to leverage the latest > technology to appear "cool" and "in tune" with customers, but by far > and > large, when something goes down customers either do no nothing, > wait, or > call in. I think the best use of everyone's time is to make sure > their call > center/support desk has the capability to post an announcement to > those that > call in. And then make sure something gets posted to the website. > SMS, > Facebook, and Twitter fall in line after all that. > > Frank > > -----Original Message----- > From: Roland Perry [mailto:lists at internetpolicyagency.com] > Sent: Saturday, July 04, 2009 10:38 AM > To: nanog at merit.edu > Subject: Re: Using twitter as an outage notification > > In article , Chris Hills > writes >>> That's the kind of "marketing-led" response I was hoping to hear. >>> >>> But the UK National Rail system now uses Tweets to tell customers >>> about >>> disruptions on the trains, and several major UK government >>> departments >>> and news organisations use it for announcements and "Breaking News". >>> >>> So has it become "respectable" yet? >> >> When there are open-source equivalents available (e.g. Laconica, >> OpenMicroBlogger - both of which incidentally are compatible since >> they >> are based upon the OMB spec), I do wonder why a commercial or >> government entity would use a closed-source, non-domestic service. > > That's fair comment, but how do you get your customers to install > quirky > niche solutions to what's a once-a-year problem? > > They all seem pretty happy using a multitude of other "non-domestic" > solutions, which probably accounts for 99% of the stuff they have on > their PCs. > > So "not sufficiently mature" we can get away with as an excuse, but > "Made in America" isn't going to put many people off :) > -- > Roland Perry > > > -- Les enfants teribbles - research / deployment Marc Manthey Vogelsangerstrasse 97 D - 50823 K?ln - Germany Vogelsangerstrasse 97 Geo: 50.945554, 6.920293 PGP/GnuPG: 0x1ac02f3296b12b4d Tel.:0049-221-29891489 Mobil:0049-1577-3329231 web : http://www.let.de Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. From sethm at rollernet.us Sat Jul 4 16:09:07 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 04 Jul 2009 14:09:07 -0700 Subject: Using twitter as an outage notification In-Reply-To: References: <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> <2XUHAbmCd3TKFAtT@perry.co.uk> Message-ID: <4A4FC4F3.2010301@rollernet.us> Frank Bulk wrote: > When the local power companies uses twitter, then maybe I'll consider using > twitter for our customers. > > There's the temptation by some of companies to leverage the latest > technology to appear "cool" and "in tune" with customers, but by far and > large, when something goes down customers either do no nothing, wait, or > call in. I think the best use of everyone's time is to make sure their call > center/support desk has the capability to post an announcement to those that > call in. And then make sure something gets posted to the website. SMS, > Facebook, and Twitter fall in line after all that. > A plain-text status website and recorded message before the phone tree scale quite well in the event of a major problem. But yeah, Twitter will attract the "what's cool right now" demographic. ~Seth From n6mod at milewski.org Sat Jul 4 16:10:20 2009 From: n6mod at milewski.org (Aleksandr Milewski) Date: Sat, 04 Jul 2009 14:10:20 -0700 Subject: Using twitter as an outage notification In-Reply-To: References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <4A4F5E3C.5040301@gmail.com> Message-ID: <4A4FC53C.3090603@milewski.org> On 7/4/09 7:50 AM, Roland Perry wrote: > What I'm trying to anticipate is the objection to *also* posting to > Twitter, which might be raised on the grounds that it's too > "unofficial", or "unsupported" or something like that. Anecdotal, of course, but I found twitter to be very useful during the SF Bay Area fiber cuts a few months back. I was able to fairly quickly get reports of who was down (UnitedLayer) and who wasn't (everyone else), and made some good contacts, some of whom I've done business with since (Cernio). Set up a twitter account for outage/event notifications, and don't *ever* use it for marketing. From mem at mv.mv.com Sat Jul 4 16:12:14 2009 From: mem at mv.mv.com (Mark E. Mallett) Date: Sat, 4 Jul 2009 17:12:14 -0400 Subject: Using twitter as an outage notification In-Reply-To: References: <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> <2XUHAbmCd3TKFAtT@perry.co.uk> Message-ID: <20090704211214.GW21847@osmium.mv.net> On Sat, Jul 04, 2009 at 03:59:48PM -0500, Frank Bulk wrote: > When the local power companies uses twitter, then maybe I'll consider using > twitter for our customers. During the ice storm we had here last winter, the local power company did just that. "psnh" "ice storm" "twitter" etc are all good search terms. I haven't been following this thread closely, so I dunno if that had already been mentioned and your remark was a sardonic one. Nevertheless.. -mm- (probably due for an annual nanog posting) From wbailey at gci.com Sat Jul 4 16:16:47 2009 From: wbailey at gci.com (Warren Bailey) Date: Sat, 4 Jul 2009 13:16:47 -0800 Subject: Using twitter as an outage notification Message-ID: <5B3743FC2D0D8B41B27EE4F5EACA79D108970FBF@DTN1EX01.gci.com> Why aren't you all out getting drunk like me?? ;) ----- Original Message ----- From: Mark E. Mallett To: Frank Bulk Cc: nanog at merit.edu Sent: Sat Jul 04 13:12:14 2009 Subject: Re: Using twitter as an outage notification On Sat, Jul 04, 2009 at 03:59:48PM -0500, Frank Bulk wrote: > When the local power companies uses twitter, then maybe I'll consider using > twitter for our customers. During the ice storm we had here last winter, the local power company did just that. "psnh" "ice storm" "twitter" etc are all good search terms. I haven't been following this thread closely, so I dunno if that had already been mentioned and your remark was a sardonic one. Nevertheless.. -mm- (probably due for an annual nanog posting) From jcdill.lists at gmail.com Sat Jul 4 17:19:55 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Sat, 04 Jul 2009 15:19:55 -0700 Subject: Using twitter as an outage notification In-Reply-To: <9GmVknjLJ3TKFAsq@perry.co.uk> References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <4A4F5E3C.5040301@gmail.com> <4A4F6EF5.9030502@gmail.com> <9GmVknjLJ3TKFAsq@perry.co.uk> Message-ID: <4A4FD58B.2000703@gmail.com> Roland Perry wrote: > In article <4A4F6EF5.9030502 at gmail.com>, JC Dill > writes > >>> What I'm trying to anticipate is the objection to *also* posting to >>> Twitter, which might be raised on the grounds that it's too >>> "unofficial", or "unsupported" or something like that. > >> Anyone who makes that argument is just showing how little they know >> about Twitter. > > So that's 98% of the population then... We aren't talking about the general population. IMHO anyone in Network Operations or NOC management who doesn't know about emerging and cutting edge communications is in the wrong job or the wrong industry. > >> It would be like complaining you shouldn't use email because "not >> everyone has email". > > But email has become respectable, although I still see "people who > know better" starting speeches with 'of course, ten years ago none of > us used email, but now....' which shows they are very late adopters > themselves. How many of them are running Internet Networks? >>> >>> It's this richness which confuses the ordinary person. > >> That's a lot like saying Perl is too complicated for the ordinary >> person so never use Perl. :-) > > You are confusing the tool with the platform. Twitter is a tool just like Perl. You can reach twitter from any browser, and most mobile phones. > >>> How are they to know which bit of the scattergun approach is the >>> right one to use? Or whether "posting everywhere" has some hidden >>> disadvantage. >> >> You can configure it and use it however YOU want. > > Again, that's about the platform called posterous. How can I explain > to the School Board that posterous has enough credibility to be used. You explain that it's a tool. You configure it and then you give a demonstration. Send a post, then show them how users who keep up with local news will find the info depending on what channels they use most often to get important info. Even easier, you make an email address on your system that is an alias to posterous. So they send to "post at schoolsystem.edu" which .forwards out to posterous, which posts to the school blog, myspace, facebook, twitter, and any other system you configure. Show them how a radio station can retweet the info and then announce "to get info on school closings, follow us on twitter at...." and everyone can send the info TO the radio station and get the info FROM the radio station quickly and easily. > I don't think it has. All they ever hear about other Web2.0 like > Facebook and Bebo is how dangerous they are for kids. Sheesh. Cars and bikes are far more dangerous for kids than Facebook and Bebo. That's why kids are taught the rules of the road, to always wear bike helmets, to always buckle up in the car, and they get driver training. > But I'm beginning to think that finally maybe Twitter has the right > profile for this application. Again, why limit yourself? Use all the tools available. jc From netfortius at gmail.com Sat Jul 4 18:34:27 2009 From: netfortius at gmail.com (Stefan) Date: Sat, 4 Jul 2009 18:34:27 -0500 Subject: Using twitter as an outage notification In-Reply-To: <4A4FD58B.2000703@gmail.com> References: <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <4A4F5E3C.5040301@gmail.com> <4A4F6EF5.9030502@gmail.com> <9GmVknjLJ3TKFAsq@perry.co.uk> <4A4FD58B.2000703@gmail.com> Message-ID: For DR issues (among many others, of course) think of Twitter as a paging system of global proportions: not a lot to be said, but if you get the message right its broadcast and amplification capabilities are unmatched. -- ***Stefan http://twitter.com/netfortius On Sat, Jul 4, 2009 at 5:19 PM, JC Dill wrote: > Roland Perry wrote: > >> In article <4A4F6EF5.9030502 at gmail.com>, JC Dill >> writes >> >> What I'm trying to anticipate is the objection to *also* posting to >>>> Twitter, which might be raised on the grounds that it's too "unofficial", or >>>> "unsupported" or something like that. >>>> >>> >> Anyone who makes that argument is just showing how little they know about >>> Twitter. >>> >> >> So that's 98% of the population then... >> > > We aren't talking about the general population. IMHO anyone in Network > Operations or NOC management who doesn't know about emerging and cutting > edge communications is in the wrong job or the wrong industry. > >> >> It would be like complaining you shouldn't use email because "not >>> everyone has email". >>> >> >> But email has become respectable, although I still see "people who know >> better" starting speeches with 'of course, ten years ago none of us used >> email, but now....' which shows they are very late adopters themselves. >> > How many of them are running Internet Networks? > > >>>> It's this richness which confuses the ordinary person. >>>> >>> >> That's a lot like saying Perl is too complicated for the ordinary person >>> so never use Perl. :-) >>> >> >> You are confusing the tool with the platform. >> > Twitter is a tool just like Perl. You can reach twitter from any browser, > and most mobile phones. > > >> How are they to know which bit of the scattergun approach is the right >>>> one to use? Or whether "posting everywhere" has some hidden disadvantage. >>>> >>> >>> You can configure it and use it however YOU want. >>> >> >> Again, that's about the platform called posterous. How can I explain to >> the School Board that posterous has enough credibility to be used. >> > > You explain that it's a tool. You configure it and then you give a > demonstration. Send a post, then show them how users who keep up with local > news will find the info depending on what channels they use most often to > get important info. > > Even easier, you make an email address on your system that is an alias to > posterous. So they send to "post at schoolsystem.edu" which .forwards out > to posterous, which posts to the school blog, myspace, facebook, twitter, > and any other system you configure. Show them how a radio station can > retweet the info and then announce "to get info on school closings, follow > us on twitter at...." and everyone can send the info TO the radio station > and get the info FROM the radio station quickly and easily. > > > I don't think it has. All they ever hear about other Web2.0 like Facebook >> and Bebo is how dangerous they are for kids. >> > > Sheesh. Cars and bikes are far more dangerous for kids than Facebook and > Bebo. That's why kids are taught the rules of the road, to always wear bike > helmets, to always buckle up in the car, and they get driver training. > > But I'm beginning to think that finally maybe Twitter has the right >> profile for this application. >> > > Again, why limit yourself? Use all the tools available. > > jc > > From frnkblk at iname.com Sat Jul 4 18:51:14 2009 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 4 Jul 2009 18:51:14 -0500 Subject: Using twitter as an outage notification In-Reply-To: <4A4FD58B.2000703@gmail.com> References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <4A4F5E3C.5040301@gmail.com> <4A4F6EF5.9030502@gmail.com> <9GmVknjLJ3TKFAsq@perry.co.uk> <4A4FD58B.2000703@gmail.com> Message-ID: So does twitter address the mass public, or those who are Web 2.0 literate or techies? I'm glad to see that Dell reached two million people, but how many more people call in or visit its web page every day? My point in another fork of this thread is that for most people, the traditional forms of communication are *it*. I'm not saying that twitter hasn't been used and found a way to reach the some portion of the population -- the traditional methods (announcement at top of phone tree & note on homepage) should be maintained and as one more additional way to communication. I think you mentioned that yourself a few posts ago. =) Frank -----Original Message----- From: JC Dill [mailto:jcdill.lists at gmail.com] Sent: Saturday, July 04, 2009 5:20 PM Cc: nanog at merit.edu Subject: Re: Using twitter as an outage notification Roland Perry wrote: > In article <4A4F6EF5.9030502 at gmail.com>, JC Dill > writes > >>> What I'm trying to anticipate is the objection to *also* posting to >>> Twitter, which might be raised on the grounds that it's too >>> "unofficial", or "unsupported" or something like that. > >> Anyone who makes that argument is just showing how little they know >> about Twitter. > > So that's 98% of the population then... We aren't talking about the general population. IMHO anyone in Network Operations or NOC management who doesn't know about emerging and cutting edge communications is in the wrong job or the wrong industry. > >> It would be like complaining you shouldn't use email because "not >> everyone has email". > > But email has become respectable, although I still see "people who > know better" starting speeches with 'of course, ten years ago none of > us used email, but now....' which shows they are very late adopters > themselves. How many of them are running Internet Networks? >>> >>> It's this richness which confuses the ordinary person. > >> That's a lot like saying Perl is too complicated for the ordinary >> person so never use Perl. :-) > > You are confusing the tool with the platform. Twitter is a tool just like Perl. You can reach twitter from any browser, and most mobile phones. > >>> How are they to know which bit of the scattergun approach is the >>> right one to use? Or whether "posting everywhere" has some hidden >>> disadvantage. >> >> You can configure it and use it however YOU want. > > Again, that's about the platform called posterous. How can I explain > to the School Board that posterous has enough credibility to be used. You explain that it's a tool. You configure it and then you give a demonstration. Send a post, then show them how users who keep up with local news will find the info depending on what channels they use most often to get important info. Even easier, you make an email address on your system that is an alias to posterous. So they send to "post at schoolsystem.edu" which .forwards out to posterous, which posts to the school blog, myspace, facebook, twitter, and any other system you configure. Show them how a radio station can retweet the info and then announce "to get info on school closings, follow us on twitter at...." and everyone can send the info TO the radio station and get the info FROM the radio station quickly and easily. > I don't think it has. All they ever hear about other Web2.0 like > Facebook and Bebo is how dangerous they are for kids. Sheesh. Cars and bikes are far more dangerous for kids than Facebook and Bebo. That's why kids are taught the rules of the road, to always wear bike helmets, to always buckle up in the car, and they get driver training. > But I'm beginning to think that finally maybe Twitter has the right > profile for this application. Again, why limit yourself? Use all the tools available. jc From tomb at byrneit.net Sat Jul 4 23:01:04 2009 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Sat, 4 Jul 2009 21:01:04 -0700 Subject: Using twitter as an outage notification In-Reply-To: References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <4A4F5E3C.5040301@gmail.com> <4A4F6EF5.9030502@gmail.com><9GmVknjLJ3TKFAsq@perry.co.uk> <4A4FD58B.2000703@gmail.com> Message-ID: <70D072392E56884193E3D2DE09C097A91F423A@pascal.zaphodb.org> >-----Original Message----- >From: Frank Bulk [mailto:frnkblk at iname.com] >Sent: Saturday, July 04, 2009 4:51 PM >To: 'JC Dill' >Cc: nanog at merit.edu >Subject: RE: Using twitter as an outage notification > >So does twitter address the mass public, [TLB:] The whole point of Twitter is that it works with SMS. > >My point in another fork of this thread is that for most people, the >traditional forms of communication are *it*. I'm not saying that >twitter >hasn't been used and found a way to reach the some portion of the >population >-- the traditional methods (announcement at top of phone tree & note on >homepage) should be maintained and as one more additional way to >communication. I think you mentioned that yourself a few posts ago. =) > >Frank > [TLB:] I think everyone agrees it's not an "Either/Or". The argument that Twitter is a good, inexpensive, way to mass communicate operational issues with those that are able to use it, is kind of axiomatic. I'm not, in general, a fan of Twitter. To me, twits are those in my killfile (yes, I know they call it "tweets"), however, as a way of using Other People's Money to reduce your OPEX while improving CSI, it seems like a no-brainer to me. From tvhawaii at shaka.com Sat Jul 4 23:29:22 2009 From: tvhawaii at shaka.com (Michael Painter) Date: Sat, 4 Jul 2009 18:29:22 -1000 Subject: Using twitter as an outage notification References: <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> <2XUHAbmCd3TKFAtT@perry.co.uk> Message-ID: <9BA5CD407BEA458CA591C6B0DF5D8C69@DELL16> ----- Original Message ----- From: "Frank Bulk" Sent: Saturday, July 04, 2009 10:59 AM Subject: RE: Using twitter as an outage notification > When the local power companies uses twitter, then maybe I'll consider using > twitter for our customers. > > There's the temptation by some of companies to leverage the latest > technology to appear "cool" and "in tune" with customers, but by far and > large, when something goes down customers either do no nothing, wait, or > call in. I think the best use of everyone's time is to make sure their call > center/support desk has the capability to post an announcement to those that > call in. And then make sure something gets posted to the website. SMS, > Facebook, and Twitter fall in line after all that. > > Frank I thought this was interesting: "Bonnie Smalley has Internet bragging rights: She has been blocked by Twitter for hand-typing too many tweets in an hour. They thought she was a computer program made to spew spam. Ms. Smalley, it turns out, is a 100 percent human customer service representative for Comcast. She is one of 10 representatives who reach out to customers through social networks, rather than waiting for them to find Comcast's support site." http://www.nytimes.com/2009/07/02/technology/personaltech/02basics.html?partner=rss&emc=rss From pauldotwall at gmail.com Sun Jul 5 01:59:45 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Sun, 5 Jul 2009 02:59:45 -0400 Subject: 151 Front Street in Toronto Fire (TorIX and others) Message-ID: <620fd17c0907042359n1830f2c2q936c24c340c16b5d@mail.gmail.com> FYI There is a fire at 151 Front Street in Toronto, which is home to TorIX as well as a variety of other network providers. Rumor is the fire may have ORIGINated in the Peer1 suite. Seems a bad weekend for fires given what happened in Seattle as well. Drive Slow From erik_list at caneris.com Sun Jul 5 01:46:44 2009 From: erik_list at caneris.com (Erik (Caneris)) Date: Sun, 5 Jul 2009 02:46:44 -0400 Subject: Fire at 151 Front St, Toronto Message-ID: 151 Front St is on fire. I just woke up from a flood of monitoring SMSs about 25 minutes ago. http://www.toronto.ca/fire/cadinfo/livecad.htm shows a two alarm fire with 17 fire vehicles dispatched currently. More details as we have them. Erik From sethm at rollernet.us Sun Jul 5 02:15:19 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 05 Jul 2009 00:15:19 -0700 Subject: Fire at 151 Front St, Toronto In-Reply-To: References: Message-ID: <4A505307.9020905@rollernet.us> Erik (Caneris) wrote: > 151 Front St is on fire. I just woke up from a flood of monitoring SMSs about 25 minutes ago. > http://www.toronto.ca/fire/cadinfo/livecad.htm shows a two alarm fire with 17 fire vehicles dispatched currently. > > More details as we have them. > As in, lp0 on fire? ~Seth From sethm at rollernet.us Sun Jul 5 02:38:27 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 05 Jul 2009 00:38:27 -0700 Subject: 151 Front Street in Toronto Fire (TorIX and others) In-Reply-To: <620fd17c0907042359n1830f2c2q936c24c340c16b5d@mail.gmail.com> References: <620fd17c0907042359n1830f2c2q936c24c340c16b5d@mail.gmail.com> Message-ID: <4A505873.6000709@rollernet.us> Paul Wall wrote: > FYI > > There is a fire at 151 Front Street in Toronto, which is home to TorIX > as well as a variety of other network providers. Rumor is the fire may > have ORIGINated in the Peer1 suite. > > Seems a bad weekend for fires given what happened in Seattle as well. > Peer1 confirms it on their status page: http://forums.peer1.com/viewtopic.php?f=37&t=117 They say power was cut to the whole building. A post on webhostingtalk says only their suite and one below. From erik_list at caneris.com Sun Jul 5 02:51:50 2009 From: erik_list at caneris.com (Erik (Caneris)) Date: Sun, 5 Jul 2009 03:51:50 -0400 Subject: 151 Front Street in Toronto Fire (TorIX and others) In-Reply-To: <4A505873.6000709@rollernet.us> References: <620fd17c0907042359n1830f2c2q936c24c340c16b5d@mail.gmail.com>, <4A505873.6000709@rollernet.us> Message-ID: > > Peer1 confirms it on their status page: > > http://forums.peer1.com/viewtopic.php?f=37&t=117 > > They say power was cut to the whole building. A post on webhostingtalk > says only their suite and one below. > > That's incorrect unless the rest of us are running on generators now. We are on the 7th floor. We are partially up, therefore clearly power was not entirely cut to the whole building. The "one below" may refer to their 7th floor suite, not sure. BTW, we're glad to help out those affected in any way we can...feel free to contact me off-list. Erik From sethm at rollernet.us Sun Jul 5 03:03:47 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 05 Jul 2009 01:03:47 -0700 Subject: 151 Front Street in Toronto Fire (TorIX and others) In-Reply-To: References: <620fd17c0907042359n1830f2c2q936c24c340c16b5d@mail.gmail.com>, <4A505873.6000709@rollernet.us> Message-ID: <4A505E63.8020607@rollernet.us> Erik (Caneris) wrote: >> Peer1 confirms it on their status page: >> >> http://forums.peer1.com/viewtopic.php?f=37&t=117 >> >> They say power was cut to the whole building. A post on webhostingtalk >> says only their suite and one below. >> >> > That's incorrect unless the rest of us are running on generators now. We are on the 7th floor. We are partially up, therefore clearly power was not entirely cut to the whole building. The "one below" may refer to their 7th floor suite, not sure. > > BTW, we're glad to help out those affected in any way we can...feel free to contact me off-list. > Yeah, I didn't really believe their "whole building" claim; high rise fires usually only result in specific floors/areas being cut and alerting one above and one below. Since this seems to be a fire-on-the-floor issue (aren't these relatively rare?) vs. utility vault, I'd be very interested to know what kind of fire suppression was in place and how effective it was. As I check now they've redacted the whole building claim and are now saying 7th and 8th floors. ~Seth From darcy at druid.net Sun Jul 5 04:47:41 2009 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Sun, 5 Jul 2009 05:47:41 -0400 Subject: 151 Front Street in Toronto Fire (TorIX and others) In-Reply-To: <4A505E63.8020607@rollernet.us> References: <620fd17c0907042359n1830f2c2q936c24c340c16b5d@mail.gmail.com> <4A505873.6000709@rollernet.us> <4A505E63.8020607@rollernet.us> Message-ID: <20090705054741.70f68805.darcy@druid.net> On Sun, 05 Jul 2009 01:03:47 -0700 Seth Mattinen wrote: > As I check now they've redacted the whole building claim and are now > saying 7th and 8th floors. I (http://www.Vex.Net/) am on the seventh floor and we never went down. All my screen sessions are still up and running. I can't find any evidence in the logs that we lost any connectivity at any point. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From lists at internetpolicyagency.com Sun Jul 5 05:01:43 2009 From: lists at internetpolicyagency.com (Roland Perry) Date: Sun, 5 Jul 2009 11:01:43 +0100 Subject: Using twitter as an outage notification In-Reply-To: References: <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> <2XUHAbmCd3TKFAtT@perry.co.uk> Message-ID: In article , Frank Bulk writes >When the local power companies uses twitter, then maybe I'll consider using >twitter for our customers. That's a poor example as far as the UK's concerned. You can't get information from the power company for days if you are a domestic customer. >There's the temptation by some of companies to leverage the latest >technology to appear "cool" and "in tune" with customers, but by far and >large, when something goes down customers either do no nothing, wait, or >call in. I think the best use of everyone's time is to make sure their call >center/support desk has the capability to post an announcement to those that >call in. It's a High School. They don't have a "support desk" (or more than handful of phone lines [1]). Even the local radio station can't cope with one call per school asking them to broadcast the news that they have closed due to bad weather. >And then make sure something gets posted to the website. Unfortunately, the number of students polling the website for news means it can't cope with the traffic. I don't believe they can justify paying more for better web hosting, just to manage this once-a-year half hour event. -- Roland Perry From lists at internetpolicyagency.com Sun Jul 5 05:10:10 2009 From: lists at internetpolicyagency.com (Roland Perry) Date: Sun, 5 Jul 2009 11:10:10 +0100 Subject: Using twitter as an outage notification In-Reply-To: <4A4FC4F3.2010301@rollernet.us> References: <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> <2XUHAbmCd3TKFAtT@perry.co.uk> <4A4FC4F3.2010301@rollernet.us> Message-ID: In article <4A4FC4F3.2010301 at rollernet.us>, Seth Mattinen writes >Twitter will attract the "what's cool right now" demographic. But has it gone from "cool" to "useful" (for this kind of application), in a way that Facebook and other such sites haven't? I remember an employer of mine when I was trying to persuade him to build a modem into a PC so people could exchange what we'd now call emails, and he said "Roland, come back and ask me again, when I can pay your wages through that modem thing". Unfortunately I didn't get the opportunity, as I left there twenty years ago, and Paypal wasn't invented until about ten years ago. -- Roland Perry From adrian at creative.net.au Sun Jul 5 05:12:38 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Sun, 5 Jul 2009 18:12:38 +0800 Subject: Using twitter as an outage notification In-Reply-To: References: <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> <2XUHAbmCd3TKFAtT@perry.co.uk> Message-ID: <20090705101237.GC14222@skywalker.creative.net.au> On Sun, Jul 05, 2009, Roland Perry wrote: > Unfortunately, the number of students polling the website for news means > it can't cope with the traffic. I don't believe they can justify paying > more for better web hosting, just to manage this once-a-year half hour > event. Is Twitter making a profit or not? This discussion about (ab)using a publicly available message system which isn't currently being charged for would makes me worried^Wamused as hell. (Not that I can't see possible ways of making money off twitter - especially if you offer reliable message dissemination services to companies for a fee, but AFAIK they aren't doing this at the moment.) Adrian From lists at internetpolicyagency.com Sun Jul 5 05:23:37 2009 From: lists at internetpolicyagency.com (Roland Perry) Date: Sun, 5 Jul 2009 11:23:37 +0100 Subject: Using twitter as an outage notification In-Reply-To: <4A4FD58B.2000703@gmail.com> References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <4A4F5E3C.5040301@gmail.com> <4A4F6EF5.9030502@gmail.com> <9GmVknjLJ3TKFAsq@perry.co.uk> <4A4FD58B.2000703@gmail.com> Message-ID: In article <4A4FD58B.2000703 at gmail.com>, JC Dill writes >Even easier, you make an email address on your system that is an alias >to posterous. So they send to "post at schoolsystem.edu" which .forwards >out to posterous, which posts to the school blog, myspace, facebook, >twitter, It doesn't have any of those, that's the point really. Is twitter the one I should get them started with first? >Show them how a radio station can retweet the info It's have to be automated as there are hundreds to do over a periods of a few tens of minutes (the schools don't generally announce they are closing until they see how many teachers made it to work, and that's not long before they have to open - students get marked down for being late, even in bad weather, so can't delay setting out from home; it's an interesting operational model.) >and then announce "to get info on school closings, follow us on twitter >at...." http://twitter.com/trentfmnews (but it's not exactly high traffic) >and everyone can send the info TO the radio station and get the info >FROM the radio station quickly and easily. The radio station would probably be overwhelmed if they got much more than one tweet per school. >> I don't think it has. All they ever hear about other Web2.0 like >>Facebook and Bebo is how dangerous they are for kids. > >Sheesh. Cars and bikes are far more dangerous for kids than Facebook >and Bebo. That's why kids are taught the rules of the road, to always >wear bike helmets, to always buckle up in the car, and they get driver >training. Part of my day job is getting that sort of training about using the Internet, into schools. So far most of them have only got as far as teaching the students how to operate Powerpoint (yes I know that's not an Internet application), and installing filters to try to keep them off YouTube during lessons. >> But I'm beginning to think that finally maybe Twitter has the right >>profile for this application. > >Again, why limit yourself? Use all the tools available. One step at a time :) -- Roland Perry From rdobbins at arbor.net Sun Jul 5 05:31:31 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 5 Jul 2009 17:31:31 +0700 Subject: Using twitter as an outage notification In-Reply-To: <20090705101237.GC14222@skywalker.creative.net.au> References: <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> <2XUHAbmCd3TKFAtT@perry.co.uk> <20090705101237.GC14222@skywalker.creative.net.au> Message-ID: On Jul 5, 2009, at 5:12 PM, Adrian Chadd wrote: > Is Twitter making a profit or not? The other consideration is scalability and reliability. Twitter has been subject to numerous feature disablements due to capacity issues, as well as complete outages. Furthermore, Twitter does not appear to be deployed in a distributed, highly-available architecture. The Twitter *aggregation/attention model* is what is of great interest, any merits of the specific service aside. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From tme at americafree.tv Sun Jul 5 05:39:10 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Sun, 5 Jul 2009 06:39:10 -0400 Subject: Using twitter as an outage notification In-Reply-To: <20090705101237.GC14222@skywalker.creative.net.au> References: <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> <2XUHAbmCd3TKFAtT@perry.co.uk> <20090705101237.GC14222@skywalker.creative.net.au> Message-ID: <9589B202-ED92-4C49-98EE-EEBAA43C87AA@americafree.tv> On Jul 5, 2009, at 6:12 AM, Adrian Chadd wrote: > On Sun, Jul 05, 2009, Roland Perry wrote: > >> Unfortunately, the number of students polling the website for news >> means >> it can't cope with the traffic. I don't believe they can justify >> paying >> more for better web hosting, just to manage this once-a-year half >> hour >> event. > > Is Twitter making a profit or not? > The word on the street is that they have not yet "found a revenue model". In other words, they make no money. They seem very dot com 1.0 unconcerned with this. That obviously cannot last. The speculation on how to fix that tend to be either focused advertising http://www.readwriteweb.com/archives/the_ultimate_twitter_revenue_model.php ecommerce http://blogs.imediaconnection.com/2009/6/22/A-real-Twitter-revenue-model---gasp-_731.aspx or Google type data mining models (you can detect trends very quickly on twitter). These can obviously be combined; who knows if they would be sufficient. > This discussion about (ab)using a publicly available message system > which > isn't currently being charged for would makes me worried^Wamused as > hell. > I don't think it violates the terms of use. But, yes, as I said before, this is a service that goes down. I would not rely on it as the only way to communicate. > (Not that I can't see possible ways of making money off twitter - > especially > if you offer reliable message dissemination services to companies > for a fee, > but AFAIK they aren't doing this at the moment.) > > No. I haven't even heard this mentioned as a possible revenue model. Good idea, though. Regards Marshall > > Adrian > > > Regards Marshall Eubanks CEO / AmericaFree.TV From marc at let.de Sun Jul 5 05:40:28 2009 From: marc at let.de (Marc Manthey) Date: Sun, 5 Jul 2009 12:40:28 +0200 Subject: Using twitter as an outage notification In-Reply-To: References: <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> <2XUHAbmCd3TKFAtT@perry.co.uk> <20090705101237.GC14222@skywalker.creative.net.au> Message-ID: <6EAFE935-42F2-41C1-A5AA-E1DCDD11BC67@let.de> > >> Is Twitter making a profit or not? > > The other consideration is scalability and reliability. Twitter has > been subject to numerous feature disablements due to capacity > issues, as well as complete outages. Furthermore, Twitter does not > appear to be deployed in a distributed, highly-available architecture. > > The Twitter *aggregation/attention model* is what is of great > interest, any merits of the specific service aside. exactly, its like VHS versus BETAMAX , not the better system wins,its just better maketing and popularity. just my 2 cents http://identi.ca/macbroadcast/ < the opensource distributed alternative > http://laconi.ca/ -- Les enfants teribbles - research / deployment Marc Manthey Vogelsangerstrasse 97 D - 50823 K?ln - Germany Vogelsangerstrasse 97 Geo: 50.945554, 6.920293 PGP/GnuPG: 0x1ac02f3296b12b4d Tel.:0049-221-29891489 Mobil:0049-1577-3329231 web : http://www.let.de Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. From orion at pirk.com Sun Jul 5 05:43:14 2009 From: orion at pirk.com (Steve Pirk) Date: Sun, 5 Jul 2009 03:43:14 -0700 (PDT) Subject: Using twitter as an outage notification In-Reply-To: References: <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> <2XUHAbmCd3TKFAtT@perry.co.uk> Message-ID: On Sun, 5 Jul 2009, Roland Perry wrote: >> There's the temptation by some of companies to leverage the latest >> technology to appear "cool" and "in tune" with customers, but by far and >> large, when something goes down customers either do no nothing, wait, or >> call in. I think the best use of everyone's time is to make sure their >> call >> center/support desk has the capability to post an announcement to those >> that >> call in. > > It's a High School. They don't have a "support desk" (or more than handful of > phone lines [1]). Even the local radio station can't cope with one call per > school asking them to broadcast the news that they have closed due to bad > weather. > If your resources are that tight, do what our local school district did, mandate that all bus schedules will only be available on the web site. >> And then make sure something gets posted to the website. > > Unfortunately, the number of students polling the website for news means it > can't cope with the traffic. I don't believe they can justify paying more for > better web hosting, just to manage this once-a-year half hour event. > Roland, sounds like you should have a few "public service" announcements saying that school closures will be delivered via a certain twitter username. Also send a flyer home with the students. The radio station can pick up the twitter feed like everyone else, and announce closures. That is the way a certain group of people are doing it in the middle east right now, word gets around and word gets out... In your case, the community will know quickly, all from a couple of people logging into twitter and sending a few messages. Sounds like a simple, ideal solution given your budget constraints. -- steve From tme at americafree.tv Sun Jul 5 06:01:45 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Sun, 5 Jul 2009 07:01:45 -0400 Subject: Using twitter as an outage notification In-Reply-To: References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <4A4F5E3C.5040301@gmail.com> <4A4F6EF5.9030502@gmail.com> <9GmVknjLJ3TKFAsq@perry.co.uk> <4A4FD58B.2000703@gmail.com> Message-ID: <0D357934-85DE-4935-8F58-02F5FCC1DC8A@americafree.tv> On Jul 5, 2009, at 6:23 AM, Roland Perry wrote: > In article <4A4FD58B.2000703 at gmail.com>, JC Dill > writes >> Even easier, you make an email address on your system that is an >> alias to posterous. So they send to "post at schoolsystem.edu" >> which .forwards out to posterous, which posts to the school blog, >> myspace, facebook, twitter, > > It doesn't have any of those, that's the point really. > > Is twitter the one I should get them started with first? I would say this partially would depend on how and what you want to communicate. If there is just going to be one pronouncement per day (the school is up / down / delayed), then facebook and / or myspace would suggest themselves. They are to date free, and the students will know what they are. I would start with facebook. If you look at the #AuthorizeNet situation, there was a lot of back and forth. Will the schools have a need for back and forth ? If they do, then, yes, twitter might be part of the solution and you might start with it. It's free, cross-platform, and you can also assume that the students (if not their parents) know what it is. This might also be a good for teachers and the school to communicate, say by DM (direct messages). Note that this will take people answering questions / dealing with issues on twitter. Specifically, someone would have to pay attention to it during any quasi-emergency period - do the schools have such a person ? Also, if the school looses power in a storm, is there a backup means of getting to the Internet ? Regards Marshall > > >> Show them how a radio station can retweet the info > > It's have to be automated as there are hundreds to do over a periods > of a few tens of minutes (the schools don't generally announce they > are closing until they see how many teachers made it to work, and > that's not long before they have to open - students get marked down > for being late, even in bad weather, so can't delay setting out from > home; it's an interesting operational model.) > >> and then announce "to get info on school closings, follow us on >> twitter at...." > > http://twitter.com/trentfmnews (but it's not exactly high traffic) > >> and everyone can send the info TO the radio station and get the >> info FROM the radio station quickly and easily. > > The radio station would probably be overwhelmed if they got much > more than one tweet per school. > >>> I don't think it has. All they ever hear about other Web2.0 like >>> Facebook and Bebo is how dangerous they are for kids. >> >> Sheesh. Cars and bikes are far more dangerous for kids than >> Facebook and Bebo. That's why kids are taught the rules of the >> road, to always wear bike helmets, to always buckle up in the car, >> and they get driver training. > > Part of my day job is getting that sort of training about using the > Internet, into schools. So far most of them have only got as far as > teaching the students how to operate Powerpoint (yes I know that's > not an Internet application), and installing filters to try to keep > them off YouTube during lessons. > >>> But I'm beginning to think that finally maybe Twitter has the >>> right profile for this application. >> >> Again, why limit yourself? Use all the tools available. > > One step at a time :) > -- > Roland Perry > > Regards Marshall Eubanks CEO / AmericaFree.TV From jbfixurpc at gmail.com Sun Jul 5 06:08:27 2009 From: jbfixurpc at gmail.com (Joe Blanchard) Date: Sun, 5 Jul 2009 07:08:27 -0400 Subject: Using twitter as an outage notification In-Reply-To: Message-ID: <002401c9fd60$ef632630$0101a8c0@E520> My gosh, Ok, how about we use Facebook, myspace and the other assorted community websites/services, no better yet lets use AOL! Can we kill this thread please (for those that are still on AOL that's PLZ) This list is for professional content, not for boasting about high school websties/services that will die out in the next year or so. > -----Original Message----- > From: Steve Pirk [mailto:orion at pirk.com] > Sent: Sunday, July 05, 2009 6:43 AM > To: Roland Perry > Cc: nanog at merit.edu > Subject: Re: Using twitter as an outage notification > > On Sun, 5 Jul 2009, Roland Perry wrote: > >> There's the temptation by some of companies to leverage the latest > >> technology to appear "cool" and "in tune" with customers, bunch of $h1t, bunch of $h1t... bunch of $h1t, bunch of $h1t... bunch of $h1t, bunch of $h1t... bunch of $h1t, bunch of $h1t... bunch of $h1t, bunch of $h1t... bunch of $h1t, bunch of $h1t... bunch of $h1t, bunch of $h1t... bunch of $h1t, bunch of $h1t... bunch of $h1t, bunch of $h1t... From mpalmer at hezmatt.org Sun Jul 5 06:32:48 2009 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sun, 5 Jul 2009 21:32:48 +1000 Subject: Using twitter as an outage notification In-Reply-To: References: <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> <2XUHAbmCd3TKFAtT@perry.co.uk> Message-ID: <20090705113248.GP1499@hezmatt.org> On Sun, Jul 05, 2009 at 11:01:43AM +0100, Roland Perry wrote: [snow day notifications] > Unfortunately, the number of students polling the website for news means > it can't cope with the traffic. I don't believe they can justify paying > more for better web hosting, just to manage this once-a-year half hour > event. There are web hosting providers whose 18c/year hosting plans can't handle a few thousand requests to a static page over a period of maybe 15 minutes without falling over? The mind boggles. - Matt From karim.adel at gmail.com Sun Jul 5 06:56:03 2009 From: karim.adel at gmail.com (Kasper Adel) Date: Sun, 5 Jul 2009 14:56:03 +0300 Subject: sniffing x.25 on SUN/Solaris Message-ID: Hello, I am trying to capture x.25 traffic from a Sun Machine and i wonder if snoop supports it because i asked my customer to capture it and send it over but the trace doesnt include anything x/25 related. Regards, Kas From arievayner at gmail.com Sun Jul 5 07:30:31 2009 From: arievayner at gmail.com (Arie Vayner) Date: Sun, 5 Jul 2009 15:30:31 +0300 Subject: sniffing x.25 on SUN/Solaris In-Reply-To: References: Message-ID: <20b13c6b0907050530x1714677cl942a09ca5052c269@mail.gmail.com> Kas, I would assume that the x.25 traffic is using async ports on the Sun (or is it over IP)? If its async, you are out of luck, and should use some RS232 (I assume...) sniffer which can recognize x.25 Arie On Sun, Jul 5, 2009 at 2:56 PM, Kasper Adel wrote: > Hello, > > I am trying to capture x.25 traffic from a Sun Machine and i wonder if > snoop > supports it because i asked my customer to capture it and send it over but > the trace doesnt include anything x/25 related. > > Regards, > Kas > From martin at airwire.ie Sun Jul 5 07:59:53 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Sun, 05 Jul 2009 13:59:53 +0100 Subject: Using twitter as an outage notification In-Reply-To: <4A4FC53C.3090603@milewski.org> References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <4A4F5E3C.5040301@gmail.com> <4A4FC53C.3090603@milewski.org> Message-ID: <4A50A3C9.3080009@airwire.ie> Aleksandr Milewski wrote: > On 7/4/09 7:50 AM, Roland Perry wrote: > >> What I'm trying to anticipate is the objection to *also* posting to >> Twitter, which might be raised on the grounds that it's too >> "unofficial", or "unsupported" or something like that. > > Anecdotal, of course, but I found twitter to be very useful during the > SF Bay Area fiber cuts a few months back. I was able to fairly quickly > get reports of who was down (UnitedLayer) and who wasn't (everyone > else), and made some good contacts, some of whom I've done business with > since (Cernio). > > Set up a twitter account for outage/event notifications, and don't > *ever* use it for marketing. > I'd agree on this one. We use it for outage/event/coverage expansion notifications. Originally, we thought a blog style website somewhere outside our network was the way to go, but twitter has so many more angles, like RSS feed capability, an API to integrate it somewhere on your website and mobile clients. On top of that, you can update it via SMS if needed. The hype some people are pushing twitter on, I can't follow, but for those type of notifications, it's perfect, also because it's not part of your own infrastructure. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-865 968 From lists at internetpolicyagency.com Sun Jul 5 08:03:08 2009 From: lists at internetpolicyagency.com (Roland Perry) Date: Sun, 5 Jul 2009 14:03:08 +0100 Subject: Using twitter as an outage notification In-Reply-To: <0D357934-85DE-4935-8F58-02F5FCC1DC8A@americafree.tv> References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <4A4F5E3C.5040301@gmail.com> <4A4F6EF5.9030502@gmail.com> <9GmVknjLJ3TKFAsq@perry.co.uk> <4A4FD58B.2000703@gmail.com> <0D357934-85DE-4935-8F58-02F5FCC1DC8A@americafree.tv> Message-ID: In article <0D357934-85DE-4935-8F58-02F5FCC1DC8A at americafree.tv>, Marshall Eubanks writes >I would say this partially would depend on how and what you want to >communicate. If there is just going to be >one pronouncement per day (the school is up / down / delayed), then >facebook and / or myspace would suggest themselves. There's going to be a handful a year. Such as "school closed today due to snow". or "remember - school closed today for staff training" [a curious British phenomenon]. >They are to date free, and the students will know what they are. I >would start with facebook. > >If you look at the #AuthorizeNet situation, there was a lot of back and >forth. Will the schools have a need for >back and forth ? No, if the school's closed, it's closed. No debate allowed. >Note that this will take people answering questions / dealing with >issues on twitter. Specifically, someone would have to pay attention >to it during any quasi-emergency period - do the schools have such a >person ? Such a person could be designated. >Also, if the school looses power in a storm, Schools in urban areas here very rarely lose power in storms. All the cables are underground. Of course, losing power would be another excuse to close the school :) >is there a backup means of getting to the Internet ? A laptop with a 3g modem would suffice, or for Twitter someone with a suitably configure mobile phone. -- Roland Perry From lists at internetpolicyagency.com Sun Jul 5 08:06:20 2009 From: lists at internetpolicyagency.com (Roland Perry) Date: Sun, 5 Jul 2009 14:06:20 +0100 Subject: Using twitter as an outage notification In-Reply-To: <20090705101237.GC14222@skywalker.creative.net.au> References: <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> <2XUHAbmCd3TKFAtT@perry.co.uk> <20090705101237.GC14222@skywalker.creative.net.au> Message-ID: In article <20090705101237.GC14222 at skywalker.creative.net.au>, Adrian Chadd writes >Is Twitter making a profit or not? > >This discussion about (ab)using a publicly available message system which >isn't currently being charged for would makes me worried^Wamused as hell. I've seen debates about whether it's possible to monetise Twitter. Operationally, it's an issue if they fail financially, but I don't think the investment in setting up an account is large enough to worry about. Counter-intuitively, I've probably seen more subscription-based services fail, than free ones. -- Roland Perry From lists at internetpolicyagency.com Sun Jul 5 08:10:37 2009 From: lists at internetpolicyagency.com (Roland Perry) Date: Sun, 5 Jul 2009 14:10:37 +0100 Subject: Using twitter as an outage notification In-Reply-To: <9589B202-ED92-4C49-98EE-EEBAA43C87AA@americafree.tv> References: <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> <2XUHAbmCd3TKFAtT@perry.co.uk> <20090705101237.GC14222@skywalker.creative.net.au> <9589B202-ED92-4C49-98EE-EEBAA43C87AA@americafree.tv> Message-ID: In article <9589B202-ED92-4C49-98EE-EEBAA43C87AA at americafree.tv>, Marshall Eubanks writes >as I said before, this is a service that goes down. I would not rely >on it as the only way to communicate. I'd be proposing it as an additional way to communicate[1], but people could come to rely upon it. [1] the present system seems to be those few students who can get through to the school then SMS the news to their friends. -- Roland Perry From lists at internetpolicyagency.com Sun Jul 5 08:16:27 2009 From: lists at internetpolicyagency.com (Roland Perry) Date: Sun, 5 Jul 2009 14:16:27 +0100 Subject: Using twitter as an outage notification In-Reply-To: References: <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> <2XUHAbmCd3TKFAtT@perry.co.uk> Message-ID: In article , Steve Pirk writes >> It's a High School. They don't have a "support desk" (or more than >>handful of phone lines [1]). Even the local radio station can't cope >>with one call per school asking them to broadcast the news that they >>have closed due to bad weather. >> >If your resources are that tight, do what our local school district >did, mandate that all bus schedules will only be available on the web >site. The school doesn't have any buses. About 80% of the students walk (the average distance maybe a little over a mile) and most of the rest get taken in their parents car. >Roland, sounds like you should have a few "public service" >announcements saying that school closures will be delivered via a >certain twitter username. That's what my objective is - to build a sturdy enough case for the school to have a twitter account to use during these events. >Also send a flyer home with the students. Only about half of those ever reach home (no-one knows where they end up, but it's probably the same place as all those lost Biros). But if the school had a twitter account I'm sure the news would spread rapidly. Most of the students spend hours online every day, even if the school doesn't. >The radio station can pick up the twitter feed like everyone else, and >announce closures. That is the way a certain group of people are doing >it in the middle east right now, word gets around and word gets out... >In your case, the community will know quickly, all from a couple of >people logging into twitter and sending a few messages. Sounds like a >simple, ideal solution given your budget constraints. I hope so. -- Roland Perry From lists at internetpolicyagency.com Sun Jul 5 08:19:20 2009 From: lists at internetpolicyagency.com (Roland Perry) Date: Sun, 5 Jul 2009 14:19:20 +0100 Subject: Using twitter as an outage notification In-Reply-To: <20090705113248.GP1499@hezmatt.org> References: <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> <2XUHAbmCd3TKFAtT@perry.co.uk> <20090705113248.GP1499@hezmatt.org> Message-ID: In article <20090705113248.GP1499 at hezmatt.org>, Matthew Palmer writes >There are web hosting providers whose 18c/year hosting plans can't handle a >few thousand requests to a static page over a period of maybe 15 minutes >without falling over? The mind boggles. Apparently so. Of course, they could be deliberately throttled, rather than run on inherently low-bandwidth kit. Which raises the issue of whether such throttling schemes should take account of short bursts. -- Roland Perry From lists at internetpolicyagency.com Sun Jul 5 08:21:08 2009 From: lists at internetpolicyagency.com (Roland Perry) Date: Sun, 5 Jul 2009 14:21:08 +0100 Subject: Using twitter as an outage notification In-Reply-To: <4A50A3C9.3080009@airwire.ie> References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <4A4F5E3C.5040301@gmail.com> <4A4FC53C.3090603@milewski.org> <4A50A3C9.3080009@airwire.ie> Message-ID: In article <4A50A3C9.3080009 at airwire.ie>, Martin List-Petersen writes >for those type of notifications, it's perfect, also because it's not >part of your own infrastructure. From an operational resilience point of view, that's a very important feature. -- Roland Perry From martin at airwire.ie Sun Jul 5 08:37:59 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Sun, 05 Jul 2009 14:37:59 +0100 Subject: Using twitter as an outage notification In-Reply-To: References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <4A4F5E3C.5040301@gmail.com> <4A4FC53C.3090603@milewski.org> <4A50A3C9.3080009@airwire.ie> Message-ID: <4A50ACB7.6070901@airwire.ie> Roland Perry wrote: > In article <4A50A3C9.3080009 at airwire.ie>, Martin List-Petersen > writes > >> for those type of notifications, it's perfect, also because it's not >> part of your own infrastructure. > > From an operational resilience point of view, that's a very important > feature. It's the main reason for choosing something like twitter, blogspot etc. If you want to communicate an outage, it might be as bad as your infrastructure is gone, even though that you'd might hope, that you've designed your network in a way, that it never happens. But let's just take the scenario, where some event basically whipes your ASN of the face of global BGP :) . It doesn't have to be a physical outage, that causes it. Talking about monetizing twitter, there's a very simple approach, just based on this type of service: Service Providers, Carriers etc., that use Twitter can pay a monthly fee for the service and twitter sends them responses, private messages etc. by more organized means. Just my 2c on another approach, but I can see that happening and I wouldn't mind paying a few bob for the service. As for some responses on this tread and also some reactions from a few customers (childish, "my kids use twitter, i don't", etc.): - some people think twitter is a hype, that's ignorant in my eyes. Sure it's overhyped by some, it doesn't make twitter a hype. - some people think twitter is a child's toy. It can be used as such, but that's not it's primary function or intention. - some people say it's the next Google. I can pretty much see, where that idea comes from. Real time search, while Google didn't pick very fast up on the fires (Seattle, Toronto), you'd be able to find tweets on them within minutes on Twitter. It would take hours before any of it appears on Google. - and as the last thing, with companies like AT&T, authorize.net and various others using it for service notifications or interaction with customers, my above point actually is just even more valid. Calling it a lame web 2.0 is pretty much off, when it's actually used for something sensible. Just my 2c Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-865 968 From lists at internetpolicyagency.com Sun Jul 5 09:15:07 2009 From: lists at internetpolicyagency.com (Roland Perry) Date: Sun, 5 Jul 2009 15:15:07 +0100 Subject: Using twitter as an outage notification In-Reply-To: <4A50ACB7.6070901@airwire.ie> References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <4A4F5E3C.5040301@gmail.com> <4A4FC53C.3090603@milewski.org> <4A50A3C9.3080009@airwire.ie> <4A50ACB7.6070901@airwire.ie> Message-ID: In article <4A50ACB7.6070901 at airwire.ie>, Martin List-Petersen writes >Calling it a lame web 2.0 is pretty much off, when it's actually used >for something sensible. I seem to be trying to find the middle ground between members of the public who think "The Internet isn't appropriate because they didn't teach it to me in college 20 years ago" and those who say "Web 2.0 isn't appropriate because they didn't teach it to me in college 5 years ago". Shouldn't we at least be giving it the benefit of the doubt? -- Roland Perry From peterc at luddite.com.au Sun Jul 5 09:23:11 2009 From: peterc at luddite.com.au (Peter J. Cherny) Date: Mon, 06 Jul 2009 00:23:11 +1000 Subject: sniffing x.25 on SUN/Solaris In-Reply-To: References: Message-ID: <4A50B74F.9070400@luddite.com.au> On 05/07/2009 21:56, Kasper Adel wrote: > I am trying to capture x.25 traffic from a Sun Machine and i wonder if snoop > supports it because i asked my customer to capture it and send it over ... Try http://docs.sun.com esp. "Solstice X.25 9.2 Administration Guide" x25trace probably does what you want. From martin at airwire.ie Sun Jul 5 09:41:11 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Sun, 05 Jul 2009 15:41:11 +0100 Subject: Using twitter as an outage notification In-Reply-To: References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <4A4F5E3C.5040301@gmail.com> <4A4FC53C.3090603@milewski.org> <4A50A3C9.3080009@airwire.ie> <4A50ACB7.6070901@airwire.ie> Message-ID: <4A50BB87.8000301@airwire.ie> Roland Perry wrote: > In article <4A50ACB7.6070901 at airwire.ie>, Martin List-Petersen > writes >> Calling it a lame web 2.0 is pretty much off, when it's actually used >> for something sensible. > > I seem to be trying to find the middle ground between members of the > public who think "The Internet isn't appropriate because they didn't > teach it to me in college 20 years ago" and those who say "Web 2.0 isn't > appropriate because they didn't teach it to me in college 5 years ago". > > Shouldn't we at least be giving it the benefit of the doubt? Since when has, what has been teached in college ever been a defining standard for what is happening on the internet or what the trend in computing is ? A lot of people never touch Linux during studies, and don't get any of it in college, however are faced with it in the corporate or public world. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-865 968 From jcdill.lists at gmail.com Sun Jul 5 10:17:21 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Sun, 05 Jul 2009 08:17:21 -0700 Subject: Using twitter as an outage notification In-Reply-To: References: <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> <2XUHAbmCd3TKFAtT@perry.co.uk> Message-ID: <4A50C401.9070307@gmail.com> Roland Perry wrote: >> There's the temptation by some of companies to leverage the latest >> technology to appear "cool" and "in tune" with customers, but by far and >> large, when something goes down customers either do no nothing, wait, or >> call in. I think the best use of everyone's time is to make sure >> their call >> center/support desk has the capability to post an announcement to >> those that >> call in. > > It's a High School. They don't have a "support desk" (or more than > handful of phone lines [1]). Even the local radio station can't cope > with one call per school asking them to broadcast the news that they > have closed due to bad weather. > >> And then make sure something gets posted to the website. > > Unfortunately, the number of students polling the website for news > means it can't cope with the traffic. Really? Um, wow. How big is this school? Is the webserver on an ISDN line? > I don't believe they can justify paying more for better web hosting, > just to manage this once-a-year half hour event. This is a case where it makes *perfect* sense to offload emergency notifications to another, larger system such as twitter, *as well as* post to the school website (ideally via a blog, so you can use posterus to do both actions in one email). There's no fee, the cost to "set up"[1] is your time to securely configure a posterus account and a list to send to posterus (see below) and then to send an announcement post to posterus (and thus post on the school blog and on twitter) and to send an email to all students and parents notifying them so they can follow the school's announcement feed on twitter. jc [1] To setup: create an announcement mailing list with a name like post72045gh at school.edu - the name is kept private. The mailing list will send to posterus (and yourself - do NOT use this list to send to regular users - if you want to do that make a different list, a public list). This prevents students from sending out snow day emails by forging the school's secretary's email address and sending to posterus themselves - they would need to guess the name of the mailing list and send "from" that name to posterus to forge a snow day email. For even more security, set the list to no approved posters. The people who are authorized to send out the announcement will be authorized to *approve* posts from non-members (who are everyone). Anyone on the school staff can post (but still, keep the address private, only distribute it to those who need to know!). The posts are held for moderation and are sent to the people who can approve, and they have to click on the approval link and approve the post before it gets distributed. Test this system with the people who will use it, so that they understand what happens if they are the first one to click on the approval link, and what happens if someone else is first (no messages left to approve). Also, make sure they can remember the password for moderating the private email list - the whole thing grinds to a halt if none of them can remember their password at 4 am when they try to send a snowday announcement and it remains stuck in the distribution list and never gets out and posted. The usual system people use to remember an infrequently used password (of having a password on a note by the computer in the office) doesn't work at 4 am when everyone is at home. jc From Skywing at valhallalegends.com Sun Jul 5 11:20:01 2009 From: Skywing at valhallalegends.com (Skywing) Date: Sun, 5 Jul 2009 11:20:01 -0500 Subject: Using twitter as an outage notification Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D601304DDB555B@caralain.haven.nynaeve.net> Hmm... doesn't that kind of defeat the point of using Twitter instead of your own infrastructure to begin with, aside from adding another (Posterous) single point of failure for all your communication mechanisms? Perhaps it is not so important for snow days vs. outage situations, but it seems to me like it would be simpler and more reliable to go directly to the source and not use Posterous. (Besides, I suspect the chances are reasonable that between mail/www/Twitter, you're going to have a low set of users in the other social networking sites crowd who don't have any overlap to begin with. Diminishing returns?) - S -----Original Message----- From: JC Dill Sent: Sunday, July 05, 2009 08:18 Cc: nanog at merit.edu Subject: Re: Using twitter as an outage notification Roland Perry wrote: >> There's the temptation by some of companies to leverage the latest >> technology to appear "cool" and "in tune" with customers, but by far and >> large, when something goes down customers either do no nothing, wait, or >> call in. I think the best use of everyone's time is to make sure >> their call >> center/support desk has the capability to post an announcement to >> those that >> call in. > > It's a High School. They don't have a "support desk" (or more than > handful of phone lines [1]). Even the local radio station can't cope > with one call per school asking them to broadcast the news that they > have closed due to bad weather. > >> And then make sure something gets posted to the website. > > Unfortunately, the number of students polling the website for news > means it can't cope with the traffic. Really? Um, wow. How big is this school? Is the webserver on an ISDN line? > I don't believe they can justify paying more for better web hosting, > just to manage this once-a-year half hour event. This is a case where it makes *perfect* sense to offload emergency notifications to another, larger system such as twitter, *as well as* post to the school website (ideally via a blog, so you can use posterus to do both actions in one email). There's no fee, the cost to "set up"[1] is your time to securely configure a posterus account and a list to send to posterus (see below) and then to send an announcement post to posterus (and thus post on the school blog and on twitter) and to send an email to all students and parents notifying them so they can follow the school's announcement feed on twitter. jc [1] To setup: create an announcement mailing list with a name like post72045gh at school.edu - the name is kept private. The mailing list will send to posterus (and yourself - do NOT use this list to send to regular users - if you want to do that make a different list, a public list). This prevents students from sending out snow day emails by forging the school's secretary's email address and sending to posterus themselves - they would need to guess the name of the mailing list and send "from" that name to posterus to forge a snow day email. For even more security, set the list to no approved posters. The people who are authorized to send out the announcement will be authorized to *approve* posts from non-members (who are everyone). Anyone on the school staff can post (but still, keep the address private, only distribute it to those who need to know!). The posts are held for moderation and are sent to the people who can approve, and they have to click on the approval link and approve the post before it gets distributed. Test this system with the people who will use it, so that they understand what happens if they are the first one to click on the approval link, and what happens if someone else is first (no messages left to approve). Also, make sure they can remember the password for moderating the private email list - the whole thing grinds to a halt if none of them can remember their password at 4 am when they try to send a snowday announcement and it remains stuck in the distribution list and never gets out and posted. The usual system people use to remember an infrequently used password (of having a password on a note by the computer in the office) doesn't work at 4 am when everyone is at home. jc From lists at internetpolicyagency.com Sun Jul 5 11:57:37 2009 From: lists at internetpolicyagency.com (Roland Perry) Date: Sun, 5 Jul 2009 17:57:37 +0100 Subject: Using twitter as an outage notification In-Reply-To: <4A50BB87.8000301@airwire.ie> References: <70D072392E56884193E3D2DE09C097A91F4234@pascal.zaphodb.org> <3c3e3fca0907031149s726425e8ob76aa1faff2148ea@mail.gmail.com> <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <4A4F5E3C.5040301@gmail.com> <4A4FC53C.3090603@milewski.org> <4A50A3C9.3080009@airwire.ie> <4A50ACB7.6070901@airwire.ie> <4A50BB87.8000301@airwire.ie> Message-ID: In article <4A50BB87.8000301 at airwire.ie>, Martin List-Petersen writes >>> Calling it a lame web 2.0 is pretty much off, when it's actually used >>> for something sensible. >> >> I seem to be trying to find the middle ground between members of the >> public who think "The Internet isn't appropriate because they didn't >> teach it to me in college 20 years ago" and those who say "Web 2.0 isn't >> appropriate because they didn't teach it to me in college 5 years ago". >> >> Shouldn't we at least be giving it the benefit of the doubt? > >Since when has, what has been teached in college ever been a defining >standard for what is happening on the internet or what the trend in >computing is ? It shouldn't be, but I'm guessing this is where much of the conservatism is coming from. -- Roland Perry From bbillon-nanog at splio.fr Sun Jul 5 11:59:43 2009 From: bbillon-nanog at splio.fr (Benjamin Billon) Date: Sun, 05 Jul 2009 18:59:43 +0200 Subject: Using twitter as an outage notification In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D601304DDB555B@caralain.haven.nynaeve.net> References: <982D8D05B6407A49AD506E6C3AC8E7D601304DDB555B@caralain.haven.nynaeve.net> Message-ID: <4A50DBFF.7050905@splio.fr> I agree. It seems (I didn't look for solid proofs of that) twitter went down when MJ's die was revealed. I don't want to know why (not enough cloud computing stuff?), but I still believe there is maybe not always an ultimate solution to all problems. Twitter and its friends may sometimes help, that's for sure. But at an higher level, we don't need the info right here right now, we only want the issues to be solved. Still meaning the DC/ISP/hosting company has to keep a straight and up-to-date list of customers in order to contact them directly if necessary (but this is not part of the problems' resolution, this is commercial/relational matter), which I never saw in real life. Furthermore, I personnaly don't use Twitter and as few "social networking whatever" websites as I can. Ben Skywing a ?crit : > Hmm... doesn't that kind of defeat the point of using Twitter instead of your own infrastructure to begin with, aside from adding another (Posterous) single point of failure for all your communication mechanisms? > > Perhaps it is not so important for snow days vs. outage situations, but it seems to me like it would be simpler and more reliable to go directly to the source and not use Posterous. > > (Besides, I suspect the chances are reasonable that between mail/www/Twitter, you're going to have a low set of users in the other social networking sites crowd who don't have any overlap to begin with. Diminishing returns?) > > - S > > -----Original Message----- > From: JC Dill > Sent: Sunday, July 05, 2009 08:18 > Cc: nanog at merit.edu > Subject: Re: Using twitter as an outage notification > > > Roland Perry wrote: > >>> There's the temptation by some of companies to leverage the latest >>> technology to appear "cool" and "in tune" with customers, but by far and >>> large, when something goes down customers either do no nothing, wait, or >>> call in. I think the best use of everyone's time is to make sure >>> their call >>> center/support desk has the capability to post an announcement to >>> those that >>> call in. >>> >> It's a High School. They don't have a "support desk" (or more than >> handful of phone lines [1]). Even the local radio station can't cope >> with one call per school asking them to broadcast the news that they >> have closed due to bad weather. >> >> >>> And then make sure something gets posted to the website. >>> >> Unfortunately, the number of students polling the website for news >> means it can't cope with the traffic. >> > Really? Um, wow. How big is this school? Is the webserver on an ISDN > line? > >> I don't believe they can justify paying more for better web hosting, >> just to manage this once-a-year half hour event. >> > This is a case where it makes *perfect* sense to offload emergency > notifications to another, larger system such as twitter, *as well as* > post to the school website (ideally via a blog, so you can use posterus > to do both actions in one email). There's no fee, the cost to "set > up"[1] is your time to securely configure a posterus account and a list > to send to posterus (see below) and then to send an announcement post to > posterus (and thus post on the school blog and on twitter) and to send > an email to all students and parents notifying them so they can follow > the school's announcement feed on twitter. > > jc > > [1] To setup: create an announcement mailing list with a name like > post72045gh at school.edu - the name is kept private. The mailing list > will send to posterus (and yourself - do NOT use this list to send to > regular users - if you want to do that make a different list, a public > list). This prevents students from sending out snow day emails by > forging the school's secretary's email address and sending to posterus > themselves - they would need to guess the name of the mailing list and > send "from" that name to posterus to forge a snow day email. > > For even more security, set the list to no approved posters. The people > who are authorized to send out the announcement will be authorized to > *approve* posts from non-members (who are everyone). Anyone on the > school staff can post (but still, keep the address private, only > distribute it to those who need to know!). The posts are held for > moderation and are sent to the people who can approve, and they have to > click on the approval link and approve the post before it gets > distributed. Test this system with the people who will use it, so that > they understand what happens if they are the first one to click on the > approval link, and what happens if someone else is first (no messages > left to approve). Also, make sure they can remember the password for > moderating the private email list - the whole thing grinds to a halt if > none of them can remember their password at 4 am when they try to send a > snowday announcement and it remains stuck in the distribution list and > never gets out and posted. The usual system people use to remember an > infrequently used password (of having a password on a note by the > computer in the office) doesn't work at 4 am when everyone is at home. > > jc > > > From lists at internetpolicyagency.com Sun Jul 5 12:04:10 2009 From: lists at internetpolicyagency.com (Roland Perry) Date: Sun, 5 Jul 2009 18:04:10 +0100 Subject: Using twitter as an outage notification In-Reply-To: <4A50C401.9070307@gmail.com> References: <200907031515080.2D3A1E03.15233@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A91F4236@pascal.zaphodb.org> <16720fe00907031329kf3c0b00y8b698ee5b31a59f@mail.gmail.com> <0E7F941E-5675-4B41-A904-444EC5CD7DEF@beztech.net> <9DFFBBB7-1C83-4008-B175-FB7FA31FB488@americafree.tv> <16720fe00907031411m504b68can5604edef4e200244@mail.gmail.com> <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <16720fe00907040747k67ca1206kb871420deb5e8163@mail.gmail.com> <2XUHAbmCd3TKFAtT@perry.co.uk> <4A50C401.9070307@gmail.com> Message-ID: In article <4A50C401.9070307 at gmail.com>, JC Dill writes >> Unfortunately, the number of students polling the website for news >>means it can't cope with the traffic. >Really? Um, wow. How big is this school? Is the webserver on an ISDN >line? It appears to be at a co-location centre in a distant city. I expect it's provided as part of a package by one of the $5 domain hosting companies. The bandwidth limiting is more likely a quota than a lack of connectivity. >> I don't believe they can justify paying more for better web hosting, >>just to manage this once-a-year half hour event. >This is a case where it makes *perfect* sense to offload emergency >notifications to another, larger system such as twitter, That's my current view, too. > you can use posterus It's going to be hard enough getting them to be comfortable with Twitter. -- Roland Perry From kngspook at gmail.com Sun Jul 5 15:50:22 2009 From: kngspook at gmail.com (Neil) Date: Sun, 5 Jul 2009 13:50:22 -0700 Subject: Using twitter as an outage notification In-Reply-To: References: <786BA8C0-B534-40FF-9126-1E33BD11CB3C@americafree.tv> <4A4F5E3C.5040301@gmail.com> <4A4FC53C.3090603@milewski.org> <4A50A3C9.3080009@airwire.ie> <4A50ACB7.6070901@airwire.ie> Message-ID: <77e4079b0907051350k2e6a35c7jd5ce1012092ac0e4@mail.gmail.com> On Sun, Jul 5, 2009 at 7:15 AM, Roland Perry wrote: > In article <4A50ACB7.6070901 at airwire.ie>, Martin List-Petersen < > martin at airwire.ie> writes > >> Calling it a lame web 2.0 is pretty much off, when it's actually used >> for something sensible. >> > > I seem to be trying to find the middle ground between members of the public > who think "The Internet isn't appropriate because they didn't teach it to me > in college 20 years ago" and those who say "Web 2.0 isn't appropriate > because they didn't teach it to me in college 5 years ago". > > Shouldn't we at least be giving it the benefit of the doubt? Well, I'm no social media expert, and I don't spend a whole lot of time on any of the social networking sites (I particularly dislike Facebook, actually). (And yet, I'm probably about as qualified for the SME title as 90% of those who claim to be...) However, I was a student fairly recently, and so maybe my perspective will hold some value. I really like the Posterous+Twitter+Facebook+etc. combo. To manage the Fb side, you could probably tap a trusted student to make the School an Fb page. A lot of the students will check there. Parents will probably check the Posterous or Twitter pages. Some of the more tech-savvy students and parents will sign up for Twitter and get SMS notifications. And then, additionally, there are plenty of ways to grab that data and copy it onto the school website as well (at least until it crumbles under the load), and you could broadcast it over a mailing list to people's email address. The idea, I think, is to deliver your message to as much of your audience as you can. By delivering your message over multiple mediums, you're making it easy for your audience to hear the message, since they can do it in the way that's most comfortable to them. And the redundancy doesn't hurt. From j at arpa.com Sun Jul 5 18:24:40 2009 From: j at arpa.com (jamie rishaw) Date: Sun, 5 Jul 2009 18:24:40 -0500 Subject: Soooo... (Was Re: Using twitter as an outage notification) Message-ID: How do I configure my router for that? Router(config)# no ML jibber-jabber ^ % Invalid input detected at 'twitter' marker. -j -- Jamie Rishaw // .com.arpa at j <- reverse it. ish. [Impressive C-level Title Here], arpa / arpa labs From eriks at nationalfastfreight.com Mon Jul 6 08:11:12 2009 From: eriks at nationalfastfreight.com (Erik Soosalu) Date: Mon, 6 Jul 2009 09:11:12 -0400 Subject: 151 Front Street in Toronto Fire (TorIX and others) In-Reply-To: <20090705054741.70f68805.darcy@druid.net> References: <620fd17c0907042359n1830f2c2q936c24c340c16b5d@mail.gmail.com><4A505873.6000709@rollernet.us><4A505E63.8020607@rollernet.us> <20090705054741.70f68805.darcy@druid.net> Message-ID: <0B224A2FE01CC54C860290D42474BF6003C173C5@exchange.nff.local> http://forums.peer1.com/viewtopic.php?f=37&t=117 -----Original Message----- From: D'Arcy J.M. Cain [mailto:darcy at druid.net] Sent: Sunday, July 05, 2009 5:48 AM To: Seth Mattinen Cc: NANOG Operators Group Subject: Re: 151 Front Street in Toronto Fire (TorIX and others) On Sun, 05 Jul 2009 01:03:47 -0700 Seth Mattinen wrote: > As I check now they've redacted the whole building claim and are now > saying 7th and 8th floors. I (http://www.Vex.Net/) am on the seventh floor and we never went down. All my screen sessions are still up and running. I can't find any evidence in the logs that we lost any connectivity at any point. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From dwhite at olp.net Mon Jul 6 09:35:56 2009 From: dwhite at olp.net (Dan White) Date: Mon, 06 Jul 2009 09:35:56 -0500 Subject: ARIN and DNSSEC In-Reply-To: <20090702150644.GB12635@arin.net> References: <20090702150644.GB12635@arin.net> Message-ID: <4A520BCC.8000303@olp.net> Hi Mark, Are there any high level operational details you could share? Specifically, are you using any commercial/OSS software to handle the (automated?) periodic key roll overs? Are you using bind? Do you have any experience or suggestions on what version to start with? Given that phase 3 is still a work in progress - do you anticipate giving ARIN members an automated/scripted way to submit their delegation records? Thanks! - Dan Mark Kosters wrote: > Hi > > ARIN is now signing the /8 zones that it is authoritative for (eg > 192.in-addr.arpa, etc). > > This the phase two of a three-phase process. Given that in-addr.arpa is > not yet signed, we have published a list of trust anchors that you can > download to configure on your local recursive resolvers. > > Additional details are at http://www.arin.net/about_us/dnssec/ > > Regards, > Mark Kosters > ARIN CTO > > From michael.holstein at csuohio.edu Mon Jul 6 10:00:52 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Mon, 06 Jul 2009 11:00:52 -0400 Subject: Using twitter as an outage notification (was: Fire, Power loss at Fisher Plaza in Seattle) In-Reply-To: References: <200907041222.NAA23352@sunf10.rd.bbc.co.uk> Message-ID: <4A5211A4.6050603@csuohio.edu> > However it doesn't scale Anyone who's seen the "fail whale" might argue the same about Twitter. Cheers, Michael Holstein Cleveland State University From nevin at enginehosting.com Mon Jul 6 10:08:50 2009 From: nevin at enginehosting.com (nevin at enginehosting.com) Date: Mon, 6 Jul 2009 10:08:50 -0500 (CDT) Subject: =?UTF-8?Q?Re:=20Using=20twitter=20as=20an=20outage=20notification=20(was?= =?UTF-8?Q?:=20Fire, =20Power=20loss=20at=20Fisher=20Plaza=20in=20Seattle)?= In-Reply-To: <4A5211A4.6050603@csuohio.edu> References: <200907041222.NAA23352@sunf10.rd.bbc.co.uk> <4A5211A4.6050603@csuohio.edu> Message-ID: <1246892930.78626960@192.168.1.71> On Monday, July 6, 2009 10:00am, "Michael Holstein" said: > >> However it doesn't scale > > Anyone who's seen the "fail whale" might argue the same about Twitter. > > Cheers, > > Michael Holstein > Cleveland State University With a past week of highly visible outages in the data center/provider industry, take a look at the section: "Crisis Communications Moves Fast" in this story, for another view of using communications channels like Twitter. http://www.datacenterknowledge.com/archives/2009/07/06/the-day-after-a-brutal-week-for-uptime/ -- Nevin Lyne -- CTO -- EngineHosting.com From black at csulb.edu Mon Jul 6 16:10:11 2009 From: black at csulb.edu (Matthew Black) Date: Mon, 06 Jul 2009 14:10:11 -0700 Subject: Possible outage in Camarillo, CA USA In-Reply-To: Message-ID: A colleague reports that Verizon and ATT have a cut cable in Camarillo, CA, in the vacinity of Lewis Road and Dawson. Anyone have more information on this outage? Thanks. matthew black e-mail postmaster california state university, long beach From jtrooney at nexdlevel.com Mon Jul 6 16:11:56 2009 From: jtrooney at nexdlevel.com (Jeff Rooney) Date: Mon, 6 Jul 2009 16:11:56 -0500 Subject: Wisconsin DC Message-ID: Does anyone know of any decent data centers in Wisconsin, preferably Madison or Milwaukee, that offer private caged environments or suites? Thanks in advance. -- Jeff From chaim.rieger at gmail.com Mon Jul 6 16:17:50 2009 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Mon, 06 Jul 2009 14:17:50 -0700 Subject: Possible outage in Camarillo, CA USA In-Reply-To: References: Message-ID: <4A5269FE.30003@gmail.com> Matthew Black wrote: > A colleague reports that Verizon and ATT have a cut cable in Camarillo, > CA, in the vacinity of Lewis Road and Dawson. Anyone have more > information on this outage? Thanks. > confirmed outage CalTrans went through an major fiber line, landlines, T1, Cell, and 911 are all down, in Oxnard, Camarillo, Thousand Oaks, etc... Vzw Fios is not affected VZW is on scene working on it, no ETA yet From charles at thewybles.com Mon Jul 6 16:22:04 2009 From: charles at thewybles.com (Charles Wyble) Date: Mon, 06 Jul 2009 14:22:04 -0700 Subject: Possible outage in Camarillo, CA USA In-Reply-To: <4A5269FE.30003@gmail.com> References: <4A5269FE.30003@gmail.com> Message-ID: <4A526AFC.8060803@thewybles.com> Chaim Rieger wrote: > Matthew Black wrote: >> A colleague reports that Verizon and ATT have a cut cable in Camarillo, >> CA, in the vacinity of Lewis Road and Dawson. Anyone have more >> information on this outage? Thanks. >> > confirmed outage > > CalTrans went through an major fiber line, > landlines, T1, Cell, and 911 are all down, in Oxnard, Camarillo, > Thousand Oaks, etc... > > Vzw Fios is not affected > > VZW is on scene working on it, no ETA yet > See outages list for some discussion. Also http://twitter.com/socalincidents 911 is back up in Ventura. From charles at thewybles.com Mon Jul 6 16:22:47 2009 From: charles at thewybles.com (Charles Wyble) Date: Mon, 06 Jul 2009 14:22:47 -0700 Subject: Possible outage in Camarillo, CA USA In-Reply-To: <4A5269FE.30003@gmail.com> References: <4A5269FE.30003@gmail.com> Message-ID: <4A526B27.3070508@thewybles.com> Chaim Rieger wrote: > > CalTrans went through an major fiber line, What's your source for CalTrans being the culprit? From chaim.rieger at gmail.com Mon Jul 6 16:33:06 2009 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Mon, 06 Jul 2009 14:33:06 -0700 Subject: Possible outage in Camarillo, CA USA In-Reply-To: References: Message-ID: <4A526D92.6020703@gmail.com> Matthew Black wrote: > A colleague reports that Verizon and ATT have a cut cable in Camarillo, > CA, in the vacinity of Lewis Road and Dawson. Anyone have more > information on this outage? Thanks. > ETA for 4 PM for the fix sorry for the noise. From sethm at rollernet.us Mon Jul 6 16:39:59 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 06 Jul 2009 14:39:59 -0700 Subject: Possible outage in Camarillo, CA USA In-Reply-To: References: Message-ID: <4A526F2F.3010703@rollernet.us> Matthew Black wrote: > A colleague reports that Verizon and ATT have a cut cable in Camarillo, > CA, in the vacinity of Lewis Road and Dawson. Anyone have more > information on this outage? Thanks. > outages.org P.S. It would be really cool not to open new topics under old threads. From justin at justinshore.com Tue Jul 7 06:17:00 2009 From: justin at justinshore.com (Justin Shore) Date: Tue, 07 Jul 2009 06:17:00 -0500 Subject: Level 3 - "legacy" Wiltel/Looking Glass bandwidth In-Reply-To: References: Message-ID: <4A532EAC.40501@justinshore.com> Scott Howard wrote: > We're looking at getting connectivity via Level 3 in a particular > datacenter, but we're being told that it's "legacy Wiltel/Looking Glass" > rather than "true" Level 3. > > Given that both of these acquisitions occurred years ago should I be > worried, or is this "legacy" connectivity the same as L3 at any other > datacenter? We were initially homed to the old Telcove network. Never had any trouble with those guys. When Level3 bought them they canned all the local IP folks. That forced you to work with the remaining overworked IP folks back on the East coast (Angela and a guy who's name I forget). Their local transport techs are good but there are very few of them left now, as compared to seeing dozens of their trucks roam the streets daily. We eventually asked to be moved off of 19094 and onto 3356. The extra Telcove hop made for some less preferred and inefficient routing. All they did was extend 3356 to the local 7600 though. The single Wichita 7600 gets on the old ring in a very fugly way. Working != correct, proper, reliable or SP-grade. We just turned up a new 200Mbps circuit to them. Wichita was flagged as not allowing any more high-speed circuits so they provisioned our circuit on a new ring to St Louis. I'm actually glad that's the case. I'm hoping that it's more stable than the KC-Wichita-Houston-Dallas ring has been in the past. We had several complete and partial outages (read: dozen plus in 2 years time) on that ring. The most recent was a few months ago when we suddenly lost all but about 2000 routes from L3. I spent close to 6 hours on that problem in the wee hours, trying to get someone to diagnose the issue. When we turned up the new 200Mbps circuit we asked for a way to do a speedtest on it. We got nothing. Apparently L3 forced Telcove to take down their own speedtest site which were pointed to after we turned up the 100Mbps circuit. L3 apparently doesn't offer a speedtest site of their own. I find that to be completely unacceptable. Every time we tried to take this position we got the same old line of "we've got everything in the path configured correctly; you'll get the full 200Mbps" to which I'd reply with a reminder that we got the same assurance when we turned up the 100Mbps with them a year prior only to later discover a cap of around 50Mbps somewhere in the middle. Our account team's hands are tied. There isn't anything that they can do about it. I've got it documented in email so if we suddenly flatline again at some percentage under 100% we'll raise an unholy hell with them. We've also had significant problems getting some planned maintenance notifications after the fact (ie, after the window and what appears like an outage to us). YMMV but if I had the choice I'd try to get connected to the real L3 backbone and not that of an acquisition. The acquisition networks were probably much more reliable before they got bought. Now that they've been stripped of their resources the legacy edges are showing signs of old age, alzheimer's, and senile dementia. It's a shame to see them reduced to that. Justin From streiner at cluebyfour.org Tue Jul 7 09:24:51 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 7 Jul 2009 10:24:51 -0400 (EDT) Subject: Level 3 - "legacy" Wiltel/Looking Glass bandwidth In-Reply-To: <4A532EAC.40501@justinshore.com> References: <4A532EAC.40501@justinshore.com> Message-ID: On Tue, 7 Jul 2009, Justin Shore wrote: > Every time we tried to take this position we got the same old line of > "we've got everything in the path configured correctly; you'll get the > full 200Mbps" to which I'd reply with a reminder that we got the same > assurance when we turned up the 100Mbps with them a year prior only to > later discover a cap of around 50Mbps somewhere in the middle. Our > account team's hands are tied. There isn't anything that they can do > about it. I've got it documented in email so if we suddenly flatline > again at some percentage under 100% we'll raise an unholy hell with them. I ran into similar problems with Verizon on a long-haul EPL circuit a few years ago. Speed problems were aggravated by the fact that this was still a very new service for them, so almost none of their NCC folks were trained in provisioning or troubleshooting them. Assuming that L3 provisions circuits like this over a SONET transport, then they're basically bonding four STS-1s into a 200 meg logical pipe. If the bonding and mapping isn't done properly all the way through the system, including the end terminals where the Ethernet <-> SONET conversions happen, then you don't get the full bandwidth. You might also see other odd side effects like unexplainable jitter, occasional retransmits, or other throughput killers. jms From dylan.ebner at crlmed.com Tue Jul 7 11:00:23 2009 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Tue, 7 Jul 2009 10:00:23 -0600 Subject: Wisconsin DC In-Reply-To: References: Message-ID: <6286FF05EBE33C4596F6C6C237626867023135E0@VS11.EXCHPROD.USA.NET> CDW just opened a new DC outside madison or milwaukee. Operated by burbee who they bought a few years ago. From tkapela at gmail.com Tue Jul 7 11:06:35 2009 From: tkapela at gmail.com (Anton Kapela) Date: Tue, 7 Jul 2009 12:06:35 -0400 Subject: Wisconsin DC In-Reply-To: References: Message-ID: <2e9d8ae50907070906t6bcde129u28ecc81c97893501@mail.gmail.com> On Mon, Jul 6, 2009 at 5:11 PM, Jeff Rooney wrote: > Does anyone know of any decent data centers in Wisconsin, preferably > Madison or Milwaukee, that offer private caged environments or suites? There are a few colo facilities of note in the Madison area (Berbee, owned by "CDW", SupraNet, and TDS has some customer colo at a few CO's..). However, if your needs include space *and* transport/transit, there's only one richly connected spot -- network222 (marketing name for 222 West washington avenue, http://www.network222.com/). If memory serves, the following networks sell transit or transport within network222: -WVFiber/host.net -Charter Business Networks -US-Signal -CenturyTel -Norlight/KDL -ATT (222ww is <1000 feet from MSDNWI11 and MDSNWI13) -Global Crossing -Spiralight Network -TDS Metrocom -WIN (Wisconsin Independent Network) There's a number of local networks who also can sell IP transit and metro-area transport around madison, but which don't have a footprint outside of the state. I'd be happy to provide references if you need. Nearly every shop within network222 (with the exception of AS20115) peers or interconnects openly at the local IX, MadIX (http://kb.wisc.edu/ns/page.php?id=6636), which is a free service supported by the University of Wisconsin. It's small, but surprisingly active for a town of ~200k people. Stats at http://stats.net.wisc.edu/madix.html Incidentally, my company (5nines Data), is host to several of the aforementioned transit/transport providers, making the site a convent spot for several applications. Cages and private suites are available; feel free to follow up off-list if you'd like. In Milwaukee, your choices are slim. The only "place to be" is 324 E Wisconsin Ave. If you're able to cope with raw space, direct deals with the building are possible. For something ready-to-go, a few of the existing tenants, all of whom have sunk serious cash into conditioning their space(s), are the best choice. The two that come to mind are NetWurx and TSR Solutions. Of the regional transport/transit shops in my Madison colo space, only Spiralight, US-Signal, TDS Metro, and Nortlight/KDL have gear within 324E and 222WW. 324E does, however, have a local Cogent pop, though in practice, WV has been able to match pricing and often able to turn-up quite rapidly (come to madison, man!). Hope this is at least minimally orienting for you (and tangentially of interest to the list!), -Tk From tkapela at gmail.com Tue Jul 7 11:15:08 2009 From: tkapela at gmail.com (Anton Kapela) Date: Tue, 7 Jul 2009 12:15:08 -0400 Subject: Wisconsin DC In-Reply-To: <6286FF05EBE33C4596F6C6C237626867023135E0@VS11.EXCHPROD.USA.NET> References: <6286FF05EBE33C4596F6C6C237626867023135E0@VS11.EXCHPROD.USA.NET> Message-ID: <2e9d8ae50907070915g3ceb7227x656b7450156e8843@mail.gmail.com> On Tue, Jul 7, 2009 at 12:00 PM, Dylan Ebner wrote: > CDW just opened a new DC outside madison or milwaukee. Operated by > burbee who they bought a few years ago. Indeed, I didn't focus on it in my previous note, but http://www.team-companies.com/, CDW/Berbee, and a few other interests pooled resources and financing commitments to build a greenfield, high-end facility. More goodies at: http://www.team-companies.com/#/Technologies/DataCenter/Madison/ Berbee's original facility: http://maps.google.com/maps?f=q&source=s_q&view=text&gl=us&q=madison+wi&ie=UTF8&ll=43.005736,-89.425114&spn=0.000932,0.002033&t=h&z=19&layer=c&cbll=43.005736,-89.425114&panoid=RmTe0cej-vWy3wm7MRfKzg&cbp=12,355.28,,0,-3.91 The new TEAM/CDW facility resides in the large field at the end of Nobel Drive: http://maps.google.com/maps?f=q&source=s_q&view=text&gl=us&q=madison+wi&ie=UTF8&ll=42.996283,-89.419034&spn=0.007455,0.016265&t=h&z=16 IIRC, Charter Business, ATT, and Spiralight serve the facility presently, though more of them could have arrived since I last checked. Best, -Tk From markk at arin.net Tue Jul 7 12:12:52 2009 From: markk at arin.net (Mark Kosters) Date: Tue, 7 Jul 2009 13:12:52 -0400 Subject: ARIN and DNSSEC In-Reply-To: <4A520BCC.8000303@olp.net> References: <20090702150644.GB12635@arin.net> <4A520BCC.8000303@olp.net> Message-ID: <20090707171251.GA2797@arin.net> On Mon, Jul 06, 2009 at 10:35:56AM -0400, Dan White wrote: > Are there any high level operational details you could share? > > Specifically, are you using any commercial/OSS software to handle the > (automated?) periodic key roll overs? We looked at Secure64's product but decided to follow the open source route. We are using ISC's bind (9.6.1) for resolution service on ARIN-hosted servers and I'm not sure what VerSign does on theirs (they secondary the /8's as well) but it is modern enough to support NSEC RR's. As far as the zone signing and key management is concerned, we are using zkt (http://www.hznet.de/dns/zkt/) and are basically following RIPE's model for zone signing. > Are you using bind? Do you have any experience or suggestions on what > version to start with? Depends on what you want to do. For example, we are using plain old NSEC which bind has supported for a while. If you want to support the shiny new NSEC3 that .org emits, you need to have Bind 9.6.1 or later. There are other authoritative servers that support DNSSEC as well - NSD comes to mind but I'm sure there are others as well. > Given that phase 3 is still a work in progress - do you anticipate > giving ARIN members an automated/scripted way to submit their delegation > records? ARIN Online is going to have a management interface to insert DS RR's. It would be good to hear from you and others on what sorts of ways you would want to interface with us on bulk data transfers/uploads etc. We had a BOF related to this with SWIPS at the last ARIN meeting and received a lot of good feedback with the conclusion that using a restful service would be a useful transport for this type of data transfer. We certainly need your feedback on future services and encourage you and others to join an upcoming ARIN meeting so that we can get good direction from you and others. Regards, Mark From tme at americafree.tv Tue Jul 7 14:50:01 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 7 Jul 2009 15:50:01 -0400 Subject: =?US-ASCII?Q?Re:_Using_twitter_as_an_outage_notification_=28was_?= =?US-ASCII?Q?=3D=3FUTF-8=3FQ=3F:=3D20Fire,_=3D20Power=3D20loss?= =?US-ASCII?Q?=3D20at=3D20Fisher=3D20Plaza=3D20in=3D20Seattle=29?= =?US-ASCII?Q?=3F=3D?= In-Reply-To: <1246892930.78626960@192.168.1.71> References: <200907041222.NAA23352@sunf10.rd.bbc.co.uk> <4A5211A4.6050603@csuohio.edu> <1246892930.78626960@192.168.1.71> Message-ID: <6C2F8996-BB8E-4399-815F-9B7DA0207A3D@americafree.tv> On Jul 6, 2009, at 11:08 AM, nevin at enginehosting.com wrote: > On Monday, July 6, 2009 10:00am, "Michael Holstein" > said: >> >>> However it doesn't scale >> >> Anyone who's seen the "fail whale" might argue the same about >> Twitter. >> >> Cheers, >> >> Michael Holstein >> Cleveland State University > > With a past week of highly visible outages in the data center/ > provider industry, take a look at the section: "Crisis > Communications Moves Fast" in this story, for another view of using > communications channels like Twitter. http://www.datacenterknowledge.com/archives/2009/07/06/the-day-after-a-brutal-week-for-uptime/ > > -- Nevin Lyne > -- CTO > -- EngineHosting.com > > Just to add something to this, twitter has been slow all afternoon and now I am getting the "fail whale" Twitter is over capacity. Too many tweets! Please wait a moment and try again I presume that this has something to do with the Michael Jackson Memorial Service now underway. I just thought I would point out in real time the obvious danger of using a backup service that itself could fail under load, especially if your outage and the load could be correlated, say in a disaster or public emergency situation. Regards Marshall > > Regards Marshall Eubanks CEO / AmericaFree.TV From marc at let.de Tue Jul 7 15:03:31 2009 From: marc at let.de (Marc Manthey) Date: Tue, 7 Jul 2009 22:03:31 +0200 Subject: =?US-ASCII?Q?Re:_Using_twitter_as_an_outage_notification_=28was_?= =?US-ASCII?Q?=3D=3FUTF-8=3FQ=3F:=3D20Fire,_=3D20Power=3D20loss?= =?US-ASCII?Q?=3D20at=3D20Fisher=3D20Plaza=3D20in=3D20Seattle=29?= =?US-ASCII?Q?=3F=3D?= In-Reply-To: <6C2F8996-BB8E-4399-815F-9B7DA0207A3D@americafree.tv> References: <200907041222.NAA23352@sunf10.rd.bbc.co.uk> <4A5211A4.6050603@csuohio.edu> <1246892930.78626960@192.168.1.71> <6C2F8996-BB8E-4399-815F-9B7DA0207A3D@americafree.tv> Message-ID: <177336C6-4A98-44DF-A970-93D48A46B29D@let.de> >>>> However it doesn't scale >>> >>> Anyone who's seen the "fail whale" might argue the same about >>> Twitter. > > Just to add something to this, twitter has been slow all afternoon > and now I am getting the "fail whale" > > > I just thought I would point out in real time the obvious danger of > using a backup service that itself could fail under load, > especially if your outage and the load could be correlated, say in a > disaster or public emergency situation. yep, got that too several time, but everytime i "reload" the page it works , there were plenty of outages before twitter got the 35 million cash injection , but your absolutly right , its centralisted , so there will be serverfarms over serverfarms to get over these "event" peaks. Would a decentralised system like http://laconi.ca/ not a better choice ? just my 50 cents http://identi.ca/macbroadcast/ -- Les enfants teribbles - research / deployment Marc Manthey Vogelsangerstrasse 97 D - 50823 K?ln - Germany Vogelsangerstrasse 97 Geo: 50.945554, 6.920293 PGP/GnuPG: 0x1ac02f3296b12b4d Tel.:0049-221-29891489 Mobil:0049-1577-3329231 web : http://www.let.de Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. From tme at americafree.tv Tue Jul 7 15:10:48 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 7 Jul 2009 16:10:48 -0400 Subject: =?US-ASCII?Q?Re:_Using_twitter_as_an_outage_notification_=28was_?= =?US-ASCII?Q?=3D=3FUTF-8=3FQ=3F:=3D20Fire,_=3D20Power=3D20loss?= =?US-ASCII?Q?=3D20at=3D20Fisher=3D20Plaza=3D20in=3D20Seattle=29?= =?US-ASCII?Q?=3F=3D?= In-Reply-To: <177336C6-4A98-44DF-A970-93D48A46B29D@let.de> References: <200907041222.NAA23352@sunf10.rd.bbc.co.uk> <4A5211A4.6050603@csuohio.edu> <1246892930.78626960@192.168.1.71> <6C2F8996-BB8E-4399-815F-9B7DA0207A3D@americafree.tv> <177336C6-4A98-44DF-A970-93D48A46B29D@let.de> Message-ID: <60801372-A264-4BFD-BDA6-35B53C345016@americafree.tv> On Jul 7, 2009, at 4:03 PM, Marc Manthey wrote: > >>>>> However it doesn't scale >>>> >>>> Anyone who's seen the "fail whale" might argue the same about >>>> Twitter. >> >> Just to add something to this, twitter has been slow all afternoon >> and now I am getting the "fail whale" >> >> >> I just thought I would point out in real time the obvious danger of >> using a backup service that itself could fail under load, >> especially if your outage and the load could be correlated, say in >> a disaster or public emergency situation. > > yep, got that too several time, but everytime i "reload" the page it > works , there were plenty of outages before twitter > got the 35 million cash injection , but your absolutly right , its > centralisted , so there will be serverfarms over serverfarms to get > over > these "event" peaks. Would a decentralised system like http://laconi.ca/ > not a better choice ? > In a real crisis, redundancy rules. Regards Marshall > just my 50 cents > > http://identi.ca/macbroadcast/ > -- Les enfants teribbles - research / deployment > Marc Manthey > Vogelsangerstrasse 97 > D - 50823 K?ln - Germany > Vogelsangerstrasse 97 > Geo: 50.945554, 6.920293 > PGP/GnuPG: 0x1ac02f3296b12b4d > Tel.:0049-221-29891489 > Mobil:0049-1577-3329231 > web : http://www.let.de > > Opinions expressed may not even be mine by the time you read them, > and certainly don't reflect those of any other entity (legal or > otherwise). > > Please note that according to the German law on data retention, > information on every electronic information exchange with me is > retained for a period of six months. > > > Regards Marshall Eubanks CEO / AmericaFree.TV From swmike at swm.pp.se Tue Jul 7 15:24:27 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 7 Jul 2009 22:24:27 +0200 (CEST) Subject: Using twitter as an outage notification (was =?UTF-8?Q?:=20Fire, =20Power=20loss=20at=20Fisher=20Plaza=20in=20Seattle)?= In-Reply-To: <60801372-A264-4BFD-BDA6-35B53C345016@americafree.tv> References: <200907041222.NAA23352@sunf10.rd.bbc.co.uk> <4A5211A4.6050603@csuohio.edu> <1246892930.78626960@192.168.1.71> <6C2F8996-BB8E-4399-815F-9B7DA0207A3D@americafree.tv> <177336C6-4A98-44DF-A970-93D48A46B29D@let.de> <60801372-A264-4BFD-BDA6-35B53C345016@americafree.tv> Message-ID: On Tue, 7 Jul 2009, Marshall Eubanks wrote: > In a real crisis, redundancy rules. ... and simplicity. It's always "fun" when those outages pages rely on sql backends etc, so they're capable of tens or hundreds of users, so they look fine normally. When an outage happens and people really need the information and want it, things stop working. I've been advocating a distributed system with static HTML pages being generated and pushed out when things change. Huge load capability, you can put it anycasted at multiple IXes so it's geographically and ISP resiliant, larger ISPs can even request to get their own mirror. Keeping it simple. No takers yet though, people seem to have too much confidence in complicated, centralized, nice looking solutions. -- Mikael Abrahamsson email: swmike at swm.pp.se From brandon.galbraith at gmail.com Tue Jul 7 15:28:33 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Tue, 7 Jul 2009 15:28:33 -0500 Subject: Using twitter as an outage notification (was : Fire, Power loss at Fisher Plaza in Seattle) In-Reply-To: References: <200907041222.NAA23352@sunf10.rd.bbc.co.uk> <4A5211A4.6050603@csuohio.edu> <1246892930.78626960@192.168.1.71> <6C2F8996-BB8E-4399-815F-9B7DA0207A3D@americafree.tv> <177336C6-4A98-44DF-A970-93D48A46B29D@let.de> <60801372-A264-4BFD-BDA6-35B53C345016@americafree.tv> Message-ID: <366100670907071328o521586eidc9984626e0995f2@mail.gmail.com> On Tue, Jul 7, 2009 at 3:24 PM, Mikael Abrahamsson wrote: > On Tue, 7 Jul 2009, Marshall Eubanks wrote: > >> In a real crisis, redundancy rules. > > ... and simplicity. > > It's always "fun" when those outages pages rely on sql backends etc, so > they're capable of tens or hundreds of users, so they look fine normally. > When an outage happens and people really need the information and want it, > things stop working. > > I've been advocating a distributed system with static HTML pages being > generated and pushed out when things change. Huge load capability, you can > put it anycasted at multiple IXes so it's geographically and ISP resiliant, > larger ISPs can even request to get their own mirror. Keeping it simple. > > No takers yet though, people seem to have too much confidence in > complicated, centralized, nice looking solutions. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > > http://www.coralcdn.org/ -- Brandon Galbraith Mobile: 630.400.6992 From tme at americafree.tv Tue Jul 7 15:29:07 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 7 Jul 2009 16:29:07 -0400 Subject: =?US-ASCII?Q?Re:_Using_twitter_as_an_outage_notification_=28was_?= =?US-ASCII?Q?=3D=3FUTF-8=3FQ=3F:=3D20Fire,__=3D20Power=3D20loss?= =?US-ASCII?Q?=3D20at=3D20Fisher=3D20Plaza=3D20in=3D20Seattle=29?= =?US-ASCII?Q?=3F=3D?= In-Reply-To: References: <200907041222.NAA23352@sunf10.rd.bbc.co.uk> <4A5211A4.6050603@csuohio.edu> <1246892930.78626960@192.168.1.71> <6C2F8996-BB8E-4399-815F-9B7DA0207A3D@americafree.tv> <177336C6-4A98-44DF-A970-93D48A46B29D@let.de> <60801372-A264-4BFD-BDA6-35B53C345016@americafree.tv> Message-ID: On Jul 7, 2009, at 4:24 PM, Mikael Abrahamsson wrote: > On Tue, 7 Jul 2009, Marshall Eubanks wrote: > >> In a real crisis, redundancy rules. > > ... and simplicity. > > It's always "fun" when those outages pages rely on sql backends etc, > so they're capable of tens or hundreds of users, so they look fine > normally. When an outage happens and people really need the > information and want it, things stop working. > > I've been advocating a distributed system with static HTML pages > being generated and pushed out when things change. Huge load > capability, you can put it anycasted at multiple IXes so it's > geographically and ISP resiliant, larger ISPs can even request to > get their own mirror. Keeping it simple. > This would seem to be ideal for P2P, which is decentralized and has proven quite resilient under attack. > No takers yet though, people seem to have too much confidence in > complicated, centralized, nice looking solutions. > Have you talked to the guys at BitTorrent ? I could make introductions during the Stockholm IETF if you need them. > -- > Mikael Abrahamsson email: swmike at swm.pp.se > > Regards Marshall Eubanks AmericaFree.TV From swmike at swm.pp.se Tue Jul 7 15:35:11 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 7 Jul 2009 22:35:11 +0200 (CEST) Subject: Using twitter as an outage notification (was : Fire, Power loss at Fisher Plaza in Seattle) In-Reply-To: <366100670907071328o521586eidc9984626e0995f2@mail.gmail.com> References: <200907041222.NAA23352@sunf10.rd.bbc.co.uk> <4A5211A4.6050603@csuohio.edu> <1246892930.78626960@192.168.1.71> <6C2F8996-BB8E-4399-815F-9B7DA0207A3D@americafree.tv> <177336C6-4A98-44DF-A970-93D48A46B29D@let.de> <60801372-A264-4BFD-BDA6-35B53C345016@americafree.tv> <366100670907071328o521586eidc9984626e0995f2@mail.gmail.com> Message-ID: On Tue, 7 Jul 2009, Brandon Galbraith wrote: > http://www.coralcdn.org/ Nice, looks very much like the thing I was advocating. Hard part is getting authorities et al interested in such an "ad hoc" solution. Preferrably they could do both and then we can see which one works best in an emergency :P -- Mikael Abrahamsson email: swmike at swm.pp.se From marka at isc.org Tue Jul 7 20:09:49 2009 From: marka at isc.org (Mark Andrews) Date: Wed, 08 Jul 2009 11:09:49 +1000 Subject: ARIN and DNSSEC In-Reply-To: Your message of "Tue, 07 Jul 2009 13:12:52 -0400." <20090707171251.GA2797@arin.net> References: <20090702150644.GB12635@arin.net> <4A520BCC.8000303@olp.net> <20090707171251.GA2797@arin.net> Message-ID: <200907080109.n6819nwv028701@drugs.dv.isc.org> In message <20090707171251.GA2797 at arin.net>, Mark Kosters writes: > On Mon, Jul 06, 2009 at 10:35:56AM -0400, Dan White wrote: > > Are there any high level operational details you could share? > > > > Specifically, are you using any commercial/OSS software to handle the > > (automated?) periodic key roll overs? > > We looked at Secure64's product but decided to follow the open source > route. We are using ISC's bind (9.6.1) for resolution service > on ARIN-hosted servers and I'm not sure what VerSign does on theirs > (they secondary the /8's as well) but it is modern enough to support > NSEC RR's. As far as the zone signing and key management is concerned, we > are using zkt (http://www.hznet.de/dns/zkt/) and are basically following > RIPE's model for zone signing. > > > Are you using bind? Do you have any experience or suggestions on what > > version to start with? > > Depends on what you want to do. For example, we are using plain > old NSEC which bind has supported for a while. If you want to support the > shiny new NSEC3 that .org emits, you need to have Bind 9.6.1 or later. > There are other authoritative servers that support DNSSEC as well > - NSD comes to mind but I'm sure there are others as well. > > > Given that phase 3 is still a work in progress - do you anticipate > > giving ARIN members an automated/scripted way to submit their delegation > > records? > > ARIN Online is going to have a management interface to insert DS RR's. > It would be good to hear from you and others on what sorts of ways > you would want to interface with us on bulk data transfers/uploads > etc. We had a BOF related to this with SWIPS at the last ARIN meeting and > received a lot of good feedback with the conclusion that using a restful > service would be a useful transport for this type of data transfer. > We certainly need your feedback on future services and encourage you > and others to join an upcoming ARIN meeting so that we can get good > direction from you and others. > > Regards, > Mark DS (DNSKEY?) to parent is a general problem which needs to be solved for all delegations. It would be nice if this could be completely in-band child master to parent master so humans were completely out of the loop except to establish the initial DS RRset in the parent. Nanog however isn't the venue to discuss this. I would think IETF DNSEXT WG would be a reasonable place to hold the discussion. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bmanning at vacation.karoshi.com Tue Jul 7 20:38:05 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 8 Jul 2009 01:38:05 +0000 Subject: ARIN and DNSSEC In-Reply-To: <200907080109.n6819nwv028701@drugs.dv.isc.org> References: <20090702150644.GB12635@arin.net> <4A520BCC.8000303@olp.net> <20090707171251.GA2797@arin.net> <200907080109.n6819nwv028701@drugs.dv.isc.org> Message-ID: <20090708013805.GA1838@vacation.karoshi.com.> On Wed, Jul 08, 2009 at 11:09:49AM +1000, Mark Andrews wrote: > > In message <20090707171251.GA2797 at arin.net>, Mark Kosters writes: > > On Mon, Jul 06, 2009 at 10:35:56AM -0400, Dan White wrote: > > > Are there any high level operational details you could share? > > > > > > Specifically, are you using any commercial/OSS software to handle the > > > (automated?) periodic key roll overs? > > > > We looked at Secure64's product but decided to follow the open source > > route. We are using ISC's bind (9.6.1) for resolution service > > on ARIN-hosted servers and I'm not sure what VerSign does on theirs > > (they secondary the /8's as well) but it is modern enough to support > > NSEC RR's. As far as the zone signing and key management is concerned, we > > are using zkt (http://www.hznet.de/dns/zkt/) and are basically following > > RIPE's model for zone signing. > > > > > Are you using bind? Do you have any experience or suggestions on what > > > version to start with? > > > > Depends on what you want to do. For example, we are using plain > > old NSEC which bind has supported for a while. If you want to support the > > shiny new NSEC3 that .org emits, you need to have Bind 9.6.1 or later. > > There are other authoritative servers that support DNSSEC as well > > - NSD comes to mind but I'm sure there are others as well. > > > > > Given that phase 3 is still a work in progress - do you anticipate > > > giving ARIN members an automated/scripted way to submit their delegation > > > records? > > > > ARIN Online is going to have a management interface to insert DS RR's. > > It would be good to hear from you and others on what sorts of ways > > you would want to interface with us on bulk data transfers/uploads > > etc. We had a BOF related to this with SWIPS at the last ARIN meeting and > > received a lot of good feedback with the conclusion that using a restful > > service would be a useful transport for this type of data transfer. > > We certainly need your feedback on future services and encourage you > > and others to join an upcoming ARIN meeting so that we can get good > > direction from you and others. > > > > Regards, > > Mark > > DS (DNSKEY?) to parent is a general problem which needs to > be solved for all delegations. It would be nice if this > could be completely in-band child master to parent master > so humans were completely out of the loop except to establish > the initial DS RRset in the parent. > > Nanog however isn't the venue to discuss this. I would > think IETF DNSEXT WG would be > a reasonable place to hold the discussion. > > Mark hey, thats what the CADR tool does. fully in-band maintainace for the child/parent interactions. only needs manual re-keying if a party loses control of the credential. --bill From marka at isc.org Tue Jul 7 20:58:17 2009 From: marka at isc.org (Mark Andrews) Date: Wed, 08 Jul 2009 11:58:17 +1000 Subject: ARIN and DNSSEC In-Reply-To: Your message of "Wed, 08 Jul 2009 01:38:05 GMT." <20090708013805.GA1838@vacation.karoshi.com.> References: <20090702150644.GB12635@arin.net> <4A520BCC.8000303@olp.net> <20090707171251.GA2797@arin.net> <200907080109.n6819nwv028701@drugs.dv.isc.org> <20090708013805.GA1838@vacation.karoshi.com.> Message-ID: <200907080158.n681wH9h029222@drugs.dv.isc.org> In message <20090708013805.GA1838 at vacation.karoshi.com.>, bmanning at vacation.kar oshi.com writes: > On Wed, Jul 08, 2009 at 11:09:49AM +1000, Mark Andrews wrote: > > > > In message <20090707171251.GA2797 at arin.net>, Mark Kosters writes: > > > On Mon, Jul 06, 2009 at 10:35:56AM -0400, Dan White wrote: > > > > Are there any high level operational details you could share? > > > > > > > > Specifically, are you using any commercial/OSS software to handle the > > > > (automated?) periodic key roll overs? > > > > > > We looked at Secure64's product but decided to follow the open source > > > route. We are using ISC's bind (9.6.1) for resolution service > > > on ARIN-hosted servers and I'm not sure what VerSign does on theirs > > > (they secondary the /8's as well) but it is modern enough to support > > > NSEC RR's. As far as the zone signing and key management is concerned, we > > > > are using zkt (http://www.hznet.de/dns/zkt/) and are basically following > > > RIPE's model for zone signing. > > > > > > > Are you using bind? Do you have any experience or suggestions on what > > > > version to start with? > > > > > > Depends on what you want to do. For example, we are using plain > > > old NSEC which bind has supported for a while. If you want to support the > > > > shiny new NSEC3 that .org emits, you need to have Bind 9.6.1 or later. > > > There are other authoritative servers that support DNSSEC as well > > > - NSD comes to mind but I'm sure there are others as well. > > > > > > > Given that phase 3 is still a work in progress - do you anticipate > > > > giving ARIN members an automated/scripted way to submit their delegatio > n > > > > records? > > > > > > ARIN Online is going to have a management interface to insert DS RR's. > > > It would be good to hear from you and others on what sorts of ways > > > you would want to interface with us on bulk data transfers/uploads > > > etc. We had a BOF related to this with SWIPS at the last ARIN meeting and > > > > received a lot of good feedback with the conclusion that using a restful > > > service would be a useful transport for this type of data transfer. > > > We certainly need your feedback on future services and encourage you > > > and others to join an upcoming ARIN meeting so that we can get good > > > direction from you and others. > > > > > > Regards, > > > Mark > > > > DS (DNSKEY?) to parent is a general problem which needs to > > be solved for all delegations. It would be nice if this > > could be completely in-band child master to parent master > > so humans were completely out of the loop except to establish > > the initial DS RRset in the parent. > > > > Nanog however isn't the venue to discuss this. I would > > think IETF DNSEXT WG would be > > a reasonable place to hold the discussion. > > > > Mark > > hey, thats what the CADR tool does. fully in-band maintainace > for the child/parent interactions. only needs manual re-keying > if a party loses control of the credential. It would be nice if http://www.rs.net/cadr/ wan't a blank page. Mark > --bill -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bmanning at vacation.karoshi.com Tue Jul 7 21:58:54 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 8 Jul 2009 02:58:54 +0000 Subject: CADR In-Reply-To: <200907080158.n681wH9h029222@drugs.dv.isc.org> References: <20090702150644.GB12635@arin.net> <4A520BCC.8000303@olp.net> <20090707171251.GA2797@arin.net> <200907080109.n6819nwv028701@drugs.dv.isc.org> <20090708013805.GA1838@vacation.karoshi.com.> <200907080158.n681wH9h029222@drugs.dv.isc.org> Message-ID: <20090708025854.GA1519@vacation.karoshi.com.> On Wed, Jul 08, 2009 at 11:58:17AM +1000, Mark Andrews wrote: > > > > > received a lot of good feedback with the conclusion that using a restful > > > > service would be a useful transport for this type of data transfer. > > > > We certainly need your feedback on future services and encourage you > > > > and others to join an upcoming ARIN meeting so that we can get good > > > > direction from you and others. > > > > > > > > Regards, > > > > Mark (Kosters) > > > > > > DS (DNSKEY?) to parent is a general problem which needs to > > > be solved for all delegations. It would be nice if this > > > could be completely in-band child master to parent master > > > so humans were completely out of the loop except to establish > > > the initial DS RRset in the parent. > > > > > > Mark (Andrews) > > > > hey, thats what the CADR tool does. fully in-band maintainace > > for the child/parent interactions. only needs manual re-keying > > if a party loses control of the credential. > > -- bill > > It would be nice if http://www.rs.net/cadr/ wan't a blank page. > > Mark (Andrews) > You mean someone wants the code? I'll be happy to put it back up if folks are interested. --bill From bmanning at vacation.karoshi.com Tue Jul 7 22:08:01 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 8 Jul 2009 03:08:01 +0000 Subject: CADR In-Reply-To: <200907080158.n681wH9h029222@drugs.dv.isc.org> References: <20090702150644.GB12635@arin.net> <4A520BCC.8000303@olp.net> <20090707171251.GA2797@arin.net> <200907080109.n6819nwv028701@drugs.dv.isc.org> <20090708013805.GA1838@vacation.karoshi.com.> <200907080158.n681wH9h029222@drugs.dv.isc.org> Message-ID: <20090708030801.GA1694@vacation.karoshi.com.> On Wed, Jul 08, 2009 at 11:58:17AM +1000, Mark Andrews wrote: > > > > > hey, thats what the CADR tool does. fully in-band maintainace > > for the child/parent interactions. only needs manual re-keying > > if a party loses control of the credential. > > -- bill > > It would be nice if http://www.rs.net/cadr/ wan't a blank page. > > Mark > for you, the pages are back. --bill From marka at isc.org Tue Jul 7 22:15:59 2009 From: marka at isc.org (Mark Andrews) Date: Wed, 08 Jul 2009 13:15:59 +1000 Subject: CADR In-Reply-To: Your message of "Wed, 08 Jul 2009 02:58:54 GMT." <20090708025854.GA1519@vacation.karoshi.com.> References: <20090702150644.GB12635@arin.net> <4A520BCC.8000303@olp.net> <20090707171251.GA2797@arin.net> <200907080109.n6819nwv028701@drugs.dv.isc.org> <20090708013805.GA1838@vacation.karoshi.com.> <200907080158.n681wH9h029222@drugs.dv.isc.org> <20090708025854.GA1519@vacation.karoshi.com.> Message-ID: <200907080315.n683Fxxn030407@drugs.dv.isc.org> In message <20090708025854.GA1519 at vacation.karoshi.com.>, bmanning at vacation.kar oshi.com writes: > On Wed, Jul 08, 2009 at 11:58:17AM +1000, Mark Andrews wrote: > > > > > > > received a lot of good feedback with the conclusion that using a rest > ful > > > > > service would be a useful transport for this type of data transfer. > > > > > We certainly need your feedback on future services and encourage you > > > > > and others to join an upcoming ARIN meeting so that we can get good > > > > > direction from you and others. > > > > > > > > > > Regards, > > > > > Mark (Kosters) > > > > > > > > DS (DNSKEY?) to parent is a general problem which needs to > > > > be solved for all delegations. It would be nice if this > > > > could be completely in-band child master to parent master > > > > so humans were completely out of the loop except to establish > > > > the initial DS RRset in the parent. > > > > > > > > Mark (Andrews) > > > > > > hey, thats what the CADR tool does. fully in-band maintainace > > > for the child/parent interactions. only needs manual re-keying > > > if a party loses control of the credential. > > > -- bill > > > > It would be nice if http://www.rs.net/cadr/ wan't a blank page. > > > > Mark (Andrews) > > > You mean someone wants the code? I'll be happy to put it back up > if folks are interested. I wanted to look at it. Updating the parent is something that need to be automated and if this does it well enough why re-invent the wheel if we don't have to. I can see several way to do it within the DNS frame work. Can I presume you are willing to have the method turned into a RFC? Mark > --bill -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nanog-list at nrg4u.com Wed Jul 8 05:01:20 2009 From: nanog-list at nrg4u.com (Andre Oppermann) Date: Wed, 08 Jul 2009 12:01:20 +0200 Subject: Point to Point Ethernet Message-ID: <4A546E70.9090604@nrg4u.com> A few time already I've wished for a fully standardized and vendor interoperable way of doing a true point to point ethernet link. It would work just like an old leased line or synchronous serial interface and completely do away with ARP, MAC addresses and all that stuff. Obviously no switches in between would be allowed. Each side would run in "promiscuous mode" where every ethernet frame is received and passed up to the network stack (just like on a serial link). Since MAC addresses are useless they can be scrapped and only the ethertype field remains. This increases the effective MTU by 12 bytes. The framing overhead goes away and the packet can directly be directly placed on the wire without taking a detour through L3->L2 lookup and encapsulation step. More importantly one can specify the just the outgoing interface again instead of the next hop: ip route 10.0.0.0 255.0.0.0 g0/1 Do you think this is useful? Maybe vendors will hear me/us. -- Andre From dot at dotat.at Wed Jul 8 08:01:51 2009 From: dot at dotat.at (Tony Finch) Date: Wed, 8 Jul 2009 14:01:51 +0100 Subject: CADR In-Reply-To: <20090708025854.GA1519@vacation.karoshi.com.> References: <20090702150644.GB12635@arin.net> <4A520BCC.8000303@olp.net> <20090707171251.GA2797@arin.net> <200907080109.n6819nwv028701@drugs.dv.isc.org> <20090708013805.GA1838@vacation.karoshi.com.> <200907080158.n681wH9h029222@drugs.dv.isc.org> <20090708025854.GA1519@vacation.karoshi.com.> Message-ID: On Wed, 8 Jul 2009, bmanning at vacation.karoshi.com wrote: > > You mean someone wants the code? I'll be happy to put it back up > if folks are interested. Thanks for putting the web pages back up. Is it possibl to publish the code too? Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From ip at ioshints.info Wed Jul 8 08:17:55 2009 From: ip at ioshints.info (Ivan Pepelnjak) Date: Wed, 8 Jul 2009 15:17:55 +0200 Subject: Point to Point Ethernet In-Reply-To: <4A546E70.9090604@nrg4u.com> References: <4A546E70.9090604@nrg4u.com> Message-ID: <000e01c9ffce$82a1afb0$0a00000a@nil.si> We're halfway there (OK, a bit less, they've messed up OSPF) with the unnumbered VLAN interfaces. http://wiki.nil.com/Unnumbered_Ethernet_VLAN_interfaces What's missing is the removal of MAC layer header, but that would require modifications to the NIC chipsets (= expensive). Ivan http://www.ioshints.info/about http://blog.ioshints.info/ > -----Original Message----- > From: Andre Oppermann [mailto:nanog-list at nrg4u.com] > Sent: Wednesday, July 08, 2009 12:01 PM > To: nanog at nanog.org > Subject: Point to Point Ethernet > > A few time already I've wished for a fully standardized and > vendor interoperable way of doing a true point to point ethernet link. > > It would work just like an old leased line or synchronous > serial interface and completely do away with ARP, MAC > addresses and all that stuff. Obviously no switches in > between would be allowed. > Each side would run in "promiscuous mode" where every > ethernet frame is received and passed up to the network stack > (just like on a serial link). Since MAC addresses are > useless they can be scrapped and only the ethertype field > remains. This increases the effective MTU by 12 bytes. > > The framing overhead goes away and the packet can directly be > directly placed on the wire without taking a detour through > L3->L2 lookup and encapsulation step. > > More importantly one can specify the just the outgoing > interface again instead of the next hop: > > ip route 10.0.0.0 255.0.0.0 g0/1 > > Do you think this is useful? Maybe vendors will hear me/us. > > -- > Andre > > > From jml at packetpimp.org Wed Jul 8 08:30:39 2009 From: jml at packetpimp.org (Jason LeBlanc) Date: Wed, 08 Jul 2009 09:30:39 -0400 Subject: Level 3 In-Reply-To: References: <20090702163823.GA26674@loopfree.net> <4A4CEC91.3070600@wyoming.com> Message-ID: <4A549F7F.7050203@packetpimp.org> To boot almost all the original Telcove crew we had are gone. They're losing the better people through attrition as they're frustrated at not being able to help their customers. I also have a feeling Level3 makes changes during business hours that are not announced. I have no proof but I have a feeling due to some odd changes in routing I see every now and then. Shane Ronan wrote: > I could not agree with the points below more. > > Prior to the mergers, I had multiple services each with Looking Glass, > Wiltel and Broadwing and Level3. After Level3's round of acquisitions > the service level for all four of them went way down. > > I've had the experience of not being able to resolve issues with > Wiltel circuits because there was no techs available who could access > the gear, been told they no longer wished to provide me with a Type 2 > service sold to me by Looking Glass or Broadwing, and had billing and > implementation issues that have lasted almost two years with Level3, > because they started moving services from one billing system to another. > > Given that Level3's prices are usually not even close to competitive > with solutions provided by other providers, I would suggest that > people look elsewhere for reliable, reasonably priced services. > > Shane > > On Jul 2, 2009, at 2:50 PM, Deepak Jain wrote: > >> >> Without continuing the L3 pile-on, one can easily glean from their >> public filings that they have never properly filled out their >> management depth in acquisition absorption and/or sufficiently >> empowered those folks. The billions in revenue lost from acquisitions >> like Genuity and others have told this story more than once. >> >> L3 is not alone in this. Worldcomm's failure to integrate >> acquisitions led to a much larger operational cash need than VZ has >> shown for the same assets (verio, lots of other names here). This is >> because VZ understands how traditional businesses acquire others, >> better, in my opinion. >> >> Unfortunately, L3 has shown little interest in making the "real >> world, tough business" cuts in heads and absorbing the real >> (internal) pain of acquisitions and seems to have a pretty >> laissez-faire attitude towards its customers, even at its senior >> management levels (Cxx). I think this will be (and has been) the >> biggest problem for them. Even a possible merger/JV with Sprint may >> not be sufficient to solve that. Their resolution of billing disputes >> is much more typical of WCOM than VZ. >> >> They are a big fish in lots, and lots, of markets. They enjoy being >> able to dictate pricing in them. IMO, however, they don't have the >> maturity of (say, AT&T or others) to take that big fish status and >> leave you still happy with the service. (colloquially: if [good >> companies] are going to take advantage, at least they don't make it >> more painful than necessary). >> >> Operationally, where you have options (because of pricing, locality, >> etc) it's long-term good to support competitors, diversity in >> connectivity, etc. History has shown time and time again that when an >> industry consolidates a lot of business with a certain vendor, bad >> things can and do occur. >> >> Deepak Jain >> AiNET >> >> >> > > From thegameiam at yahoo.com Wed Jul 8 08:47:05 2009 From: thegameiam at yahoo.com (David Barak) Date: Wed, 8 Jul 2009 06:47:05 -0700 (PDT) Subject: Point to Point Ethernet In-Reply-To: <000e01c9ffce$82a1afb0$0a00000a@nil.si> Message-ID: <236301.31359.qm@web31812.mail.mud.yahoo.com> > > Do you think this is useful? Maybe vendors will > hear me/us. > > > > -- > > Andre We also need functional remote loop testing, of the "remote hands guy plugs in a loopback plug" or "I send remote-triggered loop" type. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From herrin-nanog at dirtside.com Wed Jul 8 09:30:00 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Wed, 8 Jul 2009 10:30:00 -0400 Subject: Point to Point Ethernet In-Reply-To: <4A546E70.9090604@nrg4u.com> References: <4A546E70.9090604@nrg4u.com> Message-ID: <3c3e3fca0907080730x5a2e184cte493f29ddcc48822@mail.gmail.com> On Wed, Jul 8, 2009 at 6:01 AM, Andre Oppermann wrote: > Do you think this is useful? Andre, Some thoughts on this: 1. What's the point of increasing the max MTU from 9000 to 9012? If we want a higher MTU, why not just ask for one in the next standard? 2. Why do we need to save 12 bytes per packet by eliminating the MAC address? Why not just get the next larger ethernet size? 3. Could we be better served by using RFC1918 addresses that we define as link-local and asking the router vendors to support a "link local" config option that causes it to use the address from loopback0 for any communications it initiates over that interface instead of using the interface IP address? In other words, if your loop0 is 199.33.224.1 and your g0/0 is 10.3.2.1/30 the link-local option would cause the router to send any host-unreachable messages out g0/0 from 199.33.225.1 instead of 10.3.2.1. Likewise, pings and snmp traps would originate from 199.33.224.1. Only packets to 10.3.2.2 would originate from 10.3.2.1. Such a software-only change would be less expensive to implement than custom ethernet hardware and it would be applicable on all interface types, not just ethernet. And of course we already have tools to prevent such link-local addresses from entering the routing protocol. At a software level, we could also declare a specific remote address as the point-to-point destination so that we could use the interface name as shorthand elsewhere in the config if that proves desirable. 4. L3->L2 lookup is a pretty negligible cost. It's cached for a good long while. And you already have tools to hardcode it if so desired. With Ciscos at least, you can even hardcode addresses to ffff.ffff.ffff though this causes some unexpected behavior. Regards, Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From scott at sberkman.net Wed Jul 8 09:35:07 2009 From: scott at sberkman.net (Scott Berkman) Date: Wed, 8 Jul 2009 10:35:07 -0400 Subject: Point to Point Ethernet In-Reply-To: <236301.31359.qm@web31812.mail.mud.yahoo.com> References: <000e01c9ffce$82a1afb0$0a00000a@nil.si> <236301.31359.qm@web31812.mail.mud.yahoo.com> Message-ID: <009f01c9ffd9$4a897bc0$df9c7340$@net> There are lots of great little cable testers that can "loop" an Ethernet link or even blink the switchport (this one is copper only): http://www.jdsu.com/products/communications-test-measurement/products/a-z-pr oduct-list/lanscaper.html The remote-triggered is harder, but there are a number of switches I have seen that have some form of line testing built in, so that might be close to a decent solution. One example is the "Integrated Cable Test" and Optical Transceiver Diagnostics in the Dell PowerConnect switches. -Scott -----Original Message----- From: David Barak [mailto:thegameiam at yahoo.com] Sent: Wednesday, July 08, 2009 9:47 AM To: 'Andre Oppermann'; nanog at nanog.org; Ivan Pepelnjak Subject: RE: Point to Point Ethernet > > Do you think this is useful? Maybe vendors will > hear me/us. > > > > -- > > Andre We also need functional remote loop testing, of the "remote hands guy plugs in a loopback plug" or "I send remote-triggered loop" type. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From swmike at swm.pp.se Wed Jul 8 09:37:07 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 8 Jul 2009 16:37:07 +0200 (CEST) Subject: Point to Point Ethernet In-Reply-To: <3c3e3fca0907080730x5a2e184cte493f29ddcc48822@mail.gmail.com> References: <4A546E70.9090604@nrg4u.com> <3c3e3fca0907080730x5a2e184cte493f29ddcc48822@mail.gmail.com> Message-ID: On Wed, 8 Jul 2009, William Herrin wrote: > 1. What's the point of increasing the max MTU from 9000 to 9012? If we > want a higher MTU, why not just ask for one in the next standard? To me the only reason for this would be to lessen overhead on small packets. Also, afaik standard payload MTU is 1500 for ethernet, anything else is vendor extension, outside the standard. Ethernet overhead compared to HDLC is pretty big... -- Mikael Abrahamsson email: swmike at swm.pp.se From frnkblk at iname.com Wed Jul 8 09:42:35 2009 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 8 Jul 2009 09:42:35 -0500 Subject: Point to Point Ethernet In-Reply-To: <236301.31359.qm@web31812.mail.mud.yahoo.com> References: <000e01c9ffce$82a1afb0$0a00000a@nil.si> <236301.31359.qm@web31812.mail.mud.yahoo.com> Message-ID: Visit the Accedian website to learn about Ethernet demarcation and related standards. They market me heavily (and it apparently works). Frank -----Original Message----- From: David Barak [mailto:thegameiam at yahoo.com] Sent: Wednesday, July 08, 2009 8:47 AM To: 'Andre Oppermann'; nanog at nanog.org; Ivan Pepelnjak Subject: RE: Point to Point Ethernet > > Do you think this is useful? Maybe vendors will > hear me/us. > > > > -- > > Andre We also need functional remote loop testing, of the "remote hands guy plugs in a loopback plug" or "I send remote-triggered loop" type. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From tme at americafree.tv Wed Jul 8 09:50:21 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Wed, 8 Jul 2009 10:50:21 -0400 Subject: Point to Point Ethernet In-Reply-To: References: <4A546E70.9090604@nrg4u.com> <3c3e3fca0907080730x5a2e184cte493f29ddcc48822@mail.gmail.com> Message-ID: <802992E1-BA3A-4FE7-9B63-2409E678E1F1@americafree.tv> On Jul 8, 2009, at 10:37 AM, Mikael Abrahamsson wrote: > On Wed, 8 Jul 2009, William Herrin wrote: > >> 1. What's the point of increasing the max MTU from 9000 to 9012? If >> we want a higher MTU, why not just ask for one in the next standard? > From what I have been told, IEEE 802 refuses to make a Jumbo frame standard, for backwards compatibility reasons. Joe St Sauver's jumbo frame site : http://darkwing.uoregon.edu/~joe/jumbo-clean-gear.html shows what a mess this is. There isn't a standard now, and if you "ask for one in the next standard" you may be in for a long wait. > To me the only reason for this would be to lessen overhead on small > packets. Also, afaik standard payload MTU is 1500 for ethernet, > anything else is vendor extension, outside the standard. > > Ethernet overhead compared to HDLC is pretty big... > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > > Regards Marshall AmericaFree.TV From sthaug at nethelp.no Wed Jul 8 09:52:25 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 08 Jul 2009 16:52:25 +0200 (CEST) Subject: Point to Point Ethernet In-Reply-To: References: <4A546E70.9090604@nrg4u.com> <3c3e3fca0907080730x5a2e184cte493f29ddcc48822@mail.gmail.com> Message-ID: <20090708.165225.74685502.sthaug@nethelp.no> > > 1. What's the point of increasing the max MTU from 9000 to 9012? If we > > want a higher MTU, why not just ask for one in the next standard? > > To me the only reason for this would be to lessen overhead on small > packets. Also, afaik standard payload MTU is 1500 for ethernet, anything > else is vendor extension, outside the standard. > > Ethernet overhead compared to HDLC is pretty big... Also, there would be small point in getting rid of the normal Ethernet headers if you still needed to use the standard Ethernet preamble and inter frame gap (a total of 20 bytes). These were really only needed for 10 Mbps Ethernet. I find it highly unlikely that such a change would be accepted - also I don't really see the big point. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From kratzers at pa.net Wed Jul 8 09:57:06 2009 From: kratzers at pa.net (Stephen Kratzer) Date: Wed, 8 Jul 2009 10:57:06 -0400 Subject: Point to Point Ethernet In-Reply-To: <4A546E70.9090604@nrg4u.com> References: <4A546E70.9090604@nrg4u.com> Message-ID: <200907081057.07822.kratzers@pa.net> My first thought was that there's really no use ripping the guts out of a protocol whose core mechanisms are aimed at dealing with the complexities of operating on a shared medium only to use it in an environment in which none of those complexities exist. But, if interfaces would be made to support both Ethernet II and some new Addressless Ethernet (or some other moniker) frames, the additional costs, real or administrative, wouldn't be outstanding. You might want to first try proving that reducing the Ethernet frame overhead by 2/3 and, in turn, reducing the average frame size by 12 / [average frame size] percent is worthwhile. Or try making the frame overhead reduction argument only a small piece of the larger argument for getting rid of multi-access cruft in point-to-point environments. But good luck pushing the principle argument of making things "as simple as possible but no simpler" without good technical and (hence) business cases. Stephen Kratzer Network Engineer CTI Networks, Inc. On Wednesday 08 July 2009 06:01:20 Andre Oppermann wrote: > A few time already I've wished for a fully standardized and vendor > interoperable way of doing a true point to point ethernet link. > > It would work just like an old leased line or synchronous serial > interface and completely do away with ARP, MAC addresses and all > that stuff. Obviously no switches in between would be allowed. > Each side would run in "promiscuous mode" where every ethernet > frame is received and passed up to the network stack (just like > on a serial link). Since MAC addresses are useless they can be > scrapped and only the ethertype field remains. This increases > the effective MTU by 12 bytes. > > The framing overhead goes away and the packet can directly be > directly placed on the wire without taking a detour through L3->L2 > lookup and encapsulation step. > > More importantly one can specify the just the outgoing interface > again instead of the next hop: > > ip route 10.0.0.0 255.0.0.0 g0/1 > > Do you think this is useful? Maybe vendors will hear me/us. From herrin-nanog at dirtside.com Wed Jul 8 10:03:40 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Wed, 8 Jul 2009 11:03:40 -0400 Subject: Point to Point Ethernet In-Reply-To: <802992E1-BA3A-4FE7-9B63-2409E678E1F1@americafree.tv> References: <4A546E70.9090604@nrg4u.com> <3c3e3fca0907080730x5a2e184cte493f29ddcc48822@mail.gmail.com> <802992E1-BA3A-4FE7-9B63-2409E678E1F1@americafree.tv> Message-ID: <3c3e3fca0907080803g7d9d84b5w4ed051c0c7d3fc51@mail.gmail.com> On Wed, Jul 8, 2009 at 10:50 AM, Marshall Eubanks wrote: > On Jul 8, 2009, at 10:37 AM, Mikael Abrahamsson wrote: >> On Wed, 8 Jul 2009, William Herrin wrote: >> >>> 1. What's the point of increasing the max MTU from 9000 to 9012? If we >>> want a higher MTU, why not just ask for one in the next standard? >> To me the only reason for this would be to lessen overhead on small >> packets. Mikael, At the cost of low-volume production run hardware which is A. much more expensive (because of the low volume), B. restricted to a few supported routers and C. less thoroughly tested. I don't see how you come out ahead in that calculation. >> Also, afaik standard payload MTU is 1500 for ethernet, anything >> else is vendor extension, outside the standard. > > From what I have been told, IEEE 802 refuses to make a Jumbo frame standard, > for backwards compatibility reasons. Marshall, My understanding is that 9000 is a standard for GigE and up but for compatibility with earlier ethernets it's not the default. You have to explicitly configure it and you must configure it the same on every host and switch within the broadcast zone. For a point to point link, this should be trivial. Or am I mistaken? I gather from your list that not everything which supports gige also supports jumbo frames but that most things do. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From sthaug at nethelp.no Wed Jul 8 10:07:54 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 08 Jul 2009 17:07:54 +0200 (CEST) Subject: Point to Point Ethernet In-Reply-To: <3c3e3fca0907080803g7d9d84b5w4ed051c0c7d3fc51@mail.gmail.com> References: <802992E1-BA3A-4FE7-9B63-2409E678E1F1@americafree.tv> <3c3e3fca0907080803g7d9d84b5w4ed051c0c7d3fc51@mail.gmail.com> Message-ID: <20090708.170754.41697476.sthaug@nethelp.no> > My understanding is that 9000 is a standard for GigE and up but for > compatibility with earlier ethernets it's not the default. Your understanding is wrong. The only IEEE standard is 1500 bytes. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From shon at unwiredbb.com Wed Jul 8 10:08:13 2009 From: shon at unwiredbb.com (Shon Elliott) Date: Wed, 08 Jul 2009 08:08:13 -0700 Subject: Traffic Statistics for Yesterday Message-ID: <4A54B65D.4010700@unwiredbb.com> Does anyone have any data on how the memorial event for Michael Jackson effected the global backbones? This was seen as another inaugural type of traffic day to most of the people I've talked to. -S From herrin-nanog at dirtside.com Wed Jul 8 10:17:09 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Wed, 8 Jul 2009 11:17:09 -0400 Subject: Point to Point Ethernet In-Reply-To: <20090708.170754.41697476.sthaug@nethelp.no> References: <802992E1-BA3A-4FE7-9B63-2409E678E1F1@americafree.tv> <3c3e3fca0907080803g7d9d84b5w4ed051c0c7d3fc51@mail.gmail.com> <20090708.170754.41697476.sthaug@nethelp.no> Message-ID: <3c3e3fca0907080817s666458eflf8f31507a7faa23@mail.gmail.com> On Wed, Jul 8, 2009 at 11:07 AM, wrote: >> My understanding is that 9000 is a standard for GigE and up but for >> compatibility with earlier ethernets it's not the default. > > Your understanding is wrong. The only IEEE standard is 1500 bytes. Steinar, I 'spose I could have consulted wikipedia and gotten the answer: "The IEEE 802 standards committee does not recognize jumbo frames, as doing so would remove interoperability with other 802 protocols, including 802.5 Token Ring and 802.11 Wireless LAN. The use of 9,000 bytes as preferred size for jumbo frames arose from discussions within the Joint Engineering Team of Internet2 and the U.S. federal government networks. Their recommendation has been adopted by all other national research and education networks. In order to meet this mandatory purchasing criterion, manufacturers have in turn adopted 9,000 bytes as the conventional jumbo frame size." So 9000 for gige and up is a convention, not a standard. My bad. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From pierre.francois at uclouvain.be Wed Jul 8 10:37:25 2009 From: pierre.francois at uclouvain.be (Pierre Francois) Date: Wed, 08 Jul 2009 17:37:25 +0200 Subject: Seeking people who experienced BGP policy violations Message-ID: <4A54BD35.9030900@uclouvain.be> Hi, I would like to trigger feedback from you (people running BGP) on http://tools.ietf.org/html/draft-francois-limited-scope-specifics-00 This draft documents a threat to the respect of BGP policies of an AS. These can be violated due to the injection of more specific routes whose propagation is limited by misbehavior/mis-configurations of *other* ASes. That is, your peer screw up, and you perform transit for free to him as a result. I'd like to receive information about operational experiences of this issue from people who know they already experienced such violations, either by being the victim or being the unfortunate attacker. Info would be : How did you detect the violation ? How did you / your peers reacted ? Did you take actions to avoid the problem in the future ? Up to know, I've only found people who've been the attacker by mistake. I'd like to hear the victims ! I'd also like to hear about people who know they've never been the victim/attacker : just tell me how you know it ;-) As the doc is an internet-draft, I'd ask you to answer in private or on grow at ietf.org (subscribe at https://www.ietf.org/mailman/listinfo/grow ) Best regards, Pierre Francois. From swmike at swm.pp.se Wed Jul 8 10:42:10 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 8 Jul 2009 17:42:10 +0200 (CEST) Subject: Point to Point Ethernet In-Reply-To: <3c3e3fca0907080803g7d9d84b5w4ed051c0c7d3fc51@mail.gmail.com> References: <4A546E70.9090604@nrg4u.com> <3c3e3fca0907080730x5a2e184cte493f29ddcc48822@mail.gmail.com> <802992E1-BA3A-4FE7-9B63-2409E678E1F1@americafree.tv> <3c3e3fca0907080803g7d9d84b5w4ed051c0c7d3fc51@mail.gmail.com> Message-ID: On Wed, 8 Jul 2009, William Herrin wrote: > At the cost of low-volume production run hardware which is A. much more > expensive (because of the low volume), B. restricted to a few supported > routers and C. less thoroughly tested. I don't see how you come out > ahead in that calculation. The only way to do it would be to make this a standard in the next evolution of Ethernet, perhaps 400GE. I don't see this happening though. But the only REASON to do it, would be to lessen overhead for small packets. I don't see how you can not see this. > My understanding is that 9000 is a standard for GigE and up but for > compatibility with earlier ethernets it's not the default. You have to > explicitly configure it and you must configure it the same on every host > and switch within the broadcast zone. For a point to point link, this > should be trivial. No, IEEE says only 1500 payload MTU. This was discussed in 40GE and 100GE, and IEEE left the framesize the same way it's always been. > I gather from your list that not everything which supports gige also > supports jumbo frames but that most things do. Yes, but that doesn't make it standard. It makes it common. -- Mikael Abrahamsson email: swmike at swm.pp.se From tme at americafree.tv Wed Jul 8 10:45:12 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Wed, 8 Jul 2009 11:45:12 -0400 Subject: Traffic Statistics for Yesterday In-Reply-To: <4A54B65D.4010700@unwiredbb.com> References: <4A54B65D.4010700@unwiredbb.com> Message-ID: <1C7107D1-A427-4C01-BAA5-DA9C1DF5FCE2@americafree.tv> On Jul 8, 2009, at 11:08 AM, Shon Elliott wrote: > Does anyone have any data on how the memorial event for Michael > Jackson effected > the global backbones? This was seen as another inaugural type of > traffic day to > most of the people I've talked to. > > > -S > Don't know about backbones, but this is the best statistical summary I have seen. TECHCRUNCH : Michael Jackson?s Memorial, By The Numbers http://ow.ly/15H7Op > Regards Marshall Eubanks @AmericaFreeTV on twitter > From william.allen.simpson at gmail.com Wed Jul 8 10:50:41 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Wed, 08 Jul 2009 11:50:41 -0400 Subject: Point to Point Ethernet In-Reply-To: <200907081057.07822.kratzers@pa.net> References: <4A546E70.9090604@nrg4u.com> <200907081057.07822.kratzers@pa.net> Message-ID: <4A54C051.6060905@gmail.com> Speaking from a personal interest, has the Point-to-Point Protocol stopped being useful? After all, PPP over Sonet/SDH was specifically designed for just this case. Once upon a time, it worked well for intra-site connections, as originally specified in RFC1619: PPP encapsulation over high speed private point-to-point links, such as intra-campus single-mode fiber which may already be installed and unused. It was only after others crammed stuff in to make it work on inferior quality long distance links that it became more expensive and complicated. Still, it has all the testing and link configuration mentioned. And very low overhead. And works on copper wiring, too.... From sthaug at nethelp.no Wed Jul 8 10:59:34 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 08 Jul 2009 17:59:34 +0200 (CEST) Subject: Point to Point Ethernet In-Reply-To: <4A54C051.6060905@gmail.com> References: <4A546E70.9090604@nrg4u.com> <200907081057.07822.kratzers@pa.net> <4A54C051.6060905@gmail.com> Message-ID: <20090708.175934.71153885.sthaug@nethelp.no> > Speaking from a personal interest, has the Point-to-Point Protocol > stopped being useful? > > After all, PPP over Sonet/SDH was specifically designed for just this case. Absolutely, and it still works great for that purpose. However, given a provider backbone with Ethernet being the underlying technology, I don't see why anybody would want to use PPP on top of Ethernet instead of just plain Ethernet. After all we're *not* talking about DSL or dialup here, there's no need to authenticate users etc. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From jgreco at ns.sol.net Wed Jul 8 11:04:10 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 8 Jul 2009 11:04:10 -0500 (CDT) Subject: Point to Point Ethernet In-Reply-To: <4A546E70.9090604@nrg4u.com> from "Andre Oppermann" at Jul 08, 2009 12:01:20 PM Message-ID: <200907081604.n68G4Ab4036154@aurora.sol.net> > More importantly one can specify the just the outgoing interface > again instead of the next hop: > > ip route 10.0.0.0 255.0.0.0 g0/1 > > Do you think this is useful? Maybe vendors will hear me/us. No. What makes Ethernet useful and successful is that, unlike most other network/interconnection technologies, it is cheap and plentiful, out of necessity. Any time you have something that is high volume, demand creates pressure to produce more cheaply, and costs slide as volumes spike. There are absolutely "better" choices for point to point circuits, and there are certainly ways to make a point to point version of Ethernet, but doing so invariably seems to involve a lot of reworking of the underlying mechanisms, which means that you've just invented a way to make your special-case Ethernet ... expensive. Anything that can be done exclusively in software, without modifying the silicon, is probably the only practical way to accomplish this. However, then you're still leaving more cans of worms to open, because then there'll be someone who wants to be able to do "something like" this but have vlan support so they can break out an expensive Foundry port on inexpensive switches and still do your new point to point protocol, etc. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jason at lixfeld.ca Wed Jul 8 11:04:33 2009 From: jason at lixfeld.ca (Jason Lixfeld) Date: Wed, 8 Jul 2009 12:04:33 -0400 Subject: Traffic Statistics for Yesterday In-Reply-To: <4A54B65D.4010700@unwiredbb.com> References: <4A54B65D.4010700@unwiredbb.com> Message-ID: <855AFAE9-F001-42EF-A506-F456357C8E99@lixfeld.ca> On 8-Jul-09, at 11:08 AM, Shon Elliott wrote: > Does anyone have any data on how the memorial event for Michael > Jackson effected > the global backbones? This was seen as another inaugural type of > traffic day to > most of the people I've talked to. Not sure if this qualifies as backbone, per se but a quick scan of a few IX public data graphs shows roughly the following increase for the day over the previous Tuesday: SIX: 25% increase TorIX: 23% increase LAIIX: 21% increase NYIIX: 19% increase From jbates at brightok.net Wed Jul 8 11:14:02 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 08 Jul 2009 11:14:02 -0500 Subject: Traffic Statistics for Yesterday In-Reply-To: <4A54B65D.4010700@unwiredbb.com> References: <4A54B65D.4010700@unwiredbb.com> Message-ID: <4A54C5CA.2060003@brightok.net> Shon Elliott wrote: > Does anyone have any data on how the memorial event for Michael Jackson effected > the global backbones? This was seen as another inaugural type of traffic day to > most of the people I've talked to. We are far from a global backbone, though the eyeballs transiting through us appear to have not needed more bandwidth. Was there high bandwidth apps for the memorial? Seems strange to charge for something you'd give out free over the Internet. Jack From ekujawski at softlayer.com Wed Jul 8 11:25:15 2009 From: ekujawski at softlayer.com (Eric Kujawski) Date: Wed, 8 Jul 2009 11:25:15 -0500 Subject: Traffic Statistics for Yesterday In-Reply-To: <4A54C5CA.2060003@brightok.net> References: <4A54B65D.4010700@unwiredbb.com> <4A54C5CA.2060003@brightok.net> Message-ID: Speaking from a provider's view, this is what we saw/heard during the event. Total concurrent streams (across the board not just us): 781,000 Traffic wise, we peaked at close to 45G over our daily average across all locations during the MJ event. This was all live streaming traffic for one of the well known sites. Thanks, Eric Kujawski Director of Engineering ekujawski at softlayer.com 214-442-0583 direct dial 469-586-9636 cell 866-398-7638?toll-free 214-442-0601?fax SoftLayer Technologies, Inc. 6400 International Parkway, Suite 2000 Plano, TX 75093 http://www.softlayer.com -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Wednesday, July 08, 2009 11:14 AM To: Shon Elliott Cc: nanog at nanog.org Subject: Re: Traffic Statistics for Yesterday Shon Elliott wrote: > Does anyone have any data on how the memorial event for Michael Jackson effected > the global backbones? This was seen as another inaugural type of traffic day to > most of the people I've talked to. We are far from a global backbone, though the eyeballs transiting through us appear to have not needed more bandwidth. Was there high bandwidth apps for the memorial? Seems strange to charge for something you'd give out free over the Internet. Jack The contents of this email message and any attachments are confidential and are intended solely for the addressee. The information may also be legally privileged. This transmission is sent in trust for the sole purpose of delivery to the intended recipient. If you have received this transmission in error; any use, reproduction or dissemination of this transmission is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply email and delete this message and all associated attachments. From sthaug at nethelp.no Wed Jul 8 11:52:22 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 08 Jul 2009 18:52:22 +0200 (CEST) Subject: [SPAM-HEADER] - Re: Point to Point Ethernet - Email has different SMTP TO: and MIME TO: fields in the email addresses In-Reply-To: <951329872-1247069403-cardhu_decombobulator_blackberry.rim.net-1796983442-@bxe1003.bisx.produk.on.blackberry> References: <951329872-1247069403-cardhu_decombobulator_blackberry.rim.net-1796983442-@bxe1003.bisx.produk.on.blackberry> Message-ID: <20090708.185222.104094922.sthaug@nethelp.no> > The reality is that is an SDH/SONET backbone underlying most of these Ethernet networks. That may be so (however, numbers for the national provider I work for do not tend to bear this out). But does it matter? People presumably use Ethernet because it is inexpensive, easily available, well known, etc. Yes, if the underlying technology is SDH *or* DWDM with an SDH type interface, I know *I* would prefer to use the SDH interface - because it gives me the SDH OAM we all know and love. But if my router vendor charges me a 10-30% premium for using cards with an SDH interface, then Ethernet is going to win every time... There are vendors that supply cards where the optics can be reconfigured for 10Gig Ethernet LAN *or* WAN (SDH) interface, and where you don't have to pay a premium. The Juniper MX series is an example. But real SDH cards with the corresponding lower encapsulation overhead still come at (high) price. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From charles at thewybles.com Wed Jul 8 11:55:51 2009 From: charles at thewybles.com (Charles Wyble) Date: Wed, 08 Jul 2009 09:55:51 -0700 Subject: Level 3 In-Reply-To: <4A549F7F.7050203@packetpimp.org> References: <20090702163823.GA26674@loopfree.net> <4A4CEC91.3070600@wyoming.com> <4A549F7F.7050203@packetpimp.org> Message-ID: <4A54CF97.3000700@thewybles.com> So..... where is all this talent going? NTT? AT&T? Verizon? Dare I say it.... cogent? :) Also has anyone filed complaints with the FTC or DOJ? Jason LeBlanc wrote: > To boot almost all the original Telcove crew we had are gone. They're > losing the better people through attrition as they're frustrated at not > being able to help their customers. I also have a feeling Level3 makes > changes during business hours that are not announced. I have no proof > but I have a feeling due to some odd changes in routing I see every now > and then. > From nanog-list at nrg4u.com Wed Jul 8 12:12:52 2009 From: nanog-list at nrg4u.com (Andre Oppermann) Date: Wed, 08 Jul 2009 19:12:52 +0200 Subject: Point to Point Ethernet In-Reply-To: <200907081604.n68G4Ab4036154@aurora.sol.net> References: <200907081604.n68G4Ab4036154@aurora.sol.net> Message-ID: <4A54D394.2070604@nrg4u.com> On 08.07.2009 18:04, Joe Greco wrote: >> More importantly one can specify the just the outgoing interface >> again instead of the next hop: >> >> ip route 10.0.0.0 255.0.0.0 g0/1 >> >> Do you think this is useful? Maybe vendors will hear me/us. > > No. What makes Ethernet useful and successful is that, unlike most > other network/interconnection technologies, it is cheap and plentiful, > out of necessity. Any time you have something that is high volume, > demand creates pressure to produce more cheaply, and costs slide as > volumes spike. > > There are absolutely "better" choices for point to point circuits, > and there are certainly ways to make a point to point version of > Ethernet, but doing so invariably seems to involve a lot of reworking > of the underlying mechanisms, which means that you've just invented a > way to make your special-case Ethernet ... expensive. > > Anything that can be done exclusively in software, without modifying > the silicon, is probably the only practical way to accomplish this. > However, then you're still leaving more cans of worms to open, because > then there'll be someone who wants to be able to do "something like" > this but have vlan support so they can break out an expensive Foundry > port on inexpensive switches and still do your new point to point > protocol, etc. This shouldn't require any hardware change. The PHY doesn't care at all and the MAC (Media Access Controller) can be told to ignore the DST MAC address and pass up any packet. So it ends up being only a software change. That is disabling the ARP lookup and the L3->L2 mapping table. I'm not attached to losing the ethernet header as long as a fixed MAC address as destination can be put there and every such incoming packet is accepted. -- Andre From samk at playboy.com Wed Jul 8 12:27:25 2009 From: samk at playboy.com (Kretchmer, Sam) Date: Wed, 08 Jul 2009 12:27:25 -0500 Subject: Bandcon In-Reply-To: <4A54CF97.3000700@thewybles.com> Message-ID: Anyone on here care to comment on Bandcon transit services? Anyone even using them? They are offering me an incredible deal on transit, and I was wondering what their reputation is. thanks From jfbeam at gmail.com Wed Jul 8 13:26:26 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 08 Jul 2009 14:26:26 -0400 Subject: Point to Point Ethernet In-Reply-To: <4A546E70.9090604@nrg4u.com> References: <4A546E70.9090604@nrg4u.com> Message-ID: On Wed, 08 Jul 2009 06:01:20 -0400, Andre Oppermann wrote: > ... completely do away with ARP, MAC addresses and all > that stuff. Removing "all that stuff" means it's no longer ethernet. > Do you think this is useful? Maybe vendors will hear me/us. No. I do not. Ethernet is not a point-to-point technology. It is a multi-point (broadcast, bus, etc.) technology with DECADES of optimization and adoption. No one has gotten IEEE to adopt a larger frame size, and you want to drop *fundamental* elements of ethernet?!? --Ricky From swmike at swm.pp.se Wed Jul 8 13:33:18 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 8 Jul 2009 20:33:18 +0200 (CEST) Subject: Point to Point Ethernet In-Reply-To: References: <4A546E70.9090604@nrg4u.com> Message-ID: On Wed, 8 Jul 2009, Ricky Beam wrote: > Ethernet is not a point-to-point technology. It is a multi-point > (broadcast, bus, etc.) technology with DECADES of optimization and > adoption. No one has gotten IEEE to adopt a larger frame size, and you > want to drop *fundamental* elements of ethernet?!? I think the latest suggestion was to do away with the mechanisms, not change the frame format. It's like when you take a /30, run isis/ospf over it and tell the routing protocol it's a point to point link so it doesn't have to create a node for the "multi access network" that really isn't there. Same way here, putting the ethernet link in "p2p" mode would mean it wouldnt do arp anymore, didn't care about source or destination MACs, it just installed static ARP entry for other end and sent out packets, other end would be in promisc mode and accept anything. I don't see much gain from this though, and it's another way things can be configured wrong and cause havoc if you connect this interface to a LAN. -- Mikael Abrahamsson email: swmike at swm.pp.se From exstatica at gmail.com Wed Jul 8 13:44:00 2009 From: exstatica at gmail.com (Andrew Matthews) Date: Wed, 8 Jul 2009 11:44:00 -0700 Subject: Bandcon In-Reply-To: References: <4A54CF97.3000700@thewybles.com> Message-ID: <10f379910907081144v5e932791ya79f3590193949d1@mail.gmail.com> On Wed, Jul 8, 2009 at 10:27 AM, Kretchmer, Sam wrote: > Anyone on here care to comment on Bandcon transit services? Anyone even > using them? They are offering me an incredible deal on transit, and I was > wondering what their reputation is. I've used Bandcon in the past, and we are actually going to be pickin up some new transit from them shortly.... They have great deals.... but Their support sucks really really bad. I had a level 3 outtage and it took 10 calls to finally get them to do something. Things might have improved by now, but no promises. If you are getting a large amount of bandwidth ask for direct access to the carriers noc. That how we do it. From pstewart at nexicomgroup.net Wed Jul 8 13:47:01 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Wed, 8 Jul 2009 14:47:01 -0400 Subject: Bandcon In-Reply-To: <10f379910907081144v5e932791ya79f3590193949d1@mail.gmail.com> References: <4A54CF97.3000700@thewybles.com> <10f379910907081144v5e932791ya79f3590193949d1@mail.gmail.com> Message-ID: Remember that they resell bandwidth similar to that of WBS, but just like WBS they also have their own transit networks in place now it seems.... never been a customer of either but have talked to them.... Paul -----Original Message----- From: Andrew Matthews [mailto:exstatica at gmail.com] Sent: Wednesday, July 08, 2009 2:44 PM To: nanog at nanog.org Subject: Re: Bandcon On Wed, Jul 8, 2009 at 10:27 AM, Kretchmer, Sam wrote: > Anyone on here care to comment on Bandcon transit services? Anyone even > using them? They are offering me an incredible deal on transit, and I was > wondering what their reputation is. I've used Bandcon in the past, and we are actually going to be pickin up some new transit from them shortly.... They have great deals.... but Their support sucks really really bad. I had a level 3 outtage and it took 10 calls to finally get them to do something. Things might have improved by now, but no promises. If you are getting a large amount of bandwidth ask for direct access to the carriers noc. That how we do it. ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From rrodriguez at ifbyphone.com Wed Jul 8 13:52:13 2009 From: rrodriguez at ifbyphone.com (Robin Rodriguez) Date: Wed, 8 Jul 2009 13:52:13 -0500 Subject: Bandcon In-Reply-To: References: Message-ID: <842AF4EC-5A19-472A-ABB9-B7DC1A616F65@ifbyphone.com> On Jul 8, 2009, at 12:27 PM, Kretchmer, Sam wrote: > Anyone on here care to comment on Bandcon transit services? Anyone > even > using them? They are offering me an incredible deal on transit, and > I was > wondering what their reputation is. > > thanks > > I don't have any usage experience, but would be very interested from anyone who does as well. We have spoken with them about long-haul circuits (with small to no commit) and their prices are indeed incredible. The prices we heard were for Equinix to Equinix circuits (specifically CHI1 & CHI3 to DAL1 & NJ2) they also quoted us great deals on resold IBX-link to get to IBX's that they don't have a physical presence in (they aren't in CHI3 for example). I do wonder how they can undercut everyone's price by such a margin. Were you seeing great quotes into non Equinix facilities? -- Robin D. Rodriguez Systems Engineer Ifbyphone, Inc. Phone: (866) 250-1663 Fax: (847) 676-6553 rrodriguez at ifbyphone.com http://www.ifbyphone.com From jasondearborn at gmail.com Wed Jul 8 13:59:28 2009 From: jasondearborn at gmail.com (Jason Dearborn) Date: Wed, 8 Jul 2009 11:59:28 -0700 Subject: Bandcon In-Reply-To: <10f379910907081144v5e932791ya79f3590193949d1@mail.gmail.com> References: <4A54CF97.3000700@thewybles.com> <10f379910907081144v5e932791ya79f3590193949d1@mail.gmail.com> Message-ID: <4296d7270907081159t4bdf2de4t35f2547c75fc515@mail.gmail.com> > Their support sucks really really bad. I had a level 3 outtage and > it took 10 calls to finally get them to do something. Things might > have improved by now, but no promises. If you are getting a large > amount of bandwidth ask for direct access to the carriers noc. That > how we do it. They may have also been getting the runaround from Level3. I had a hard down issue about a year ago when a L3 tech unpatched a mislabeled cable in the MMR. It took getting my local sales rep and his boss involved to have someone drive back out and fix it. To get back to the point, there's no excuse for Bandcon or any reseller not to return calls promptly and provide regular status updates -- even if their upstream support is unresponsive. Network Innovations, another reseller, has fantastic customer support. From sean76 at gmail.com Wed Jul 8 15:11:50 2009 From: sean76 at gmail.com (Sean) Date: Wed, 8 Jul 2009 15:11:50 -0500 Subject: GoDaddy issues this morning? Message-ID: Anyone know what was the deal with GoDaddy this morning? I sporadically could not resolve a domain I own this morning. Checked the authoritative and it was fine... then noticed that it was completely not working from some ISPs but OK from others, etc. Went to GoDaddy's site and finally saw a small notice on their support page saying they were having issues with Verizon customers on the east coast. Well, I'm in Illinois and I certainly don't consider this the east coast, however some people I know on a Verizon DSL account could not resolve any of the domains I had registered on GoDaddy. Also, results from a L3 DIA were sporadic as well. I really didn't have much time to look at it this morning and now the notice is gone from their site so I assume it's fixed...? Anyone shed some light on this? Registrar issues are so rare IMHO, Verizon routing issues on the other hand, I'm not really sure about as I live in AT&T/Comcast country. -Sean From justin at justinshore.com Wed Jul 8 15:39:02 2009 From: justin at justinshore.com (Justin Shore) Date: Wed, 08 Jul 2009 15:39:02 -0500 Subject: Traffic Statistics for Yesterday In-Reply-To: <4A54B65D.4010700@unwiredbb.com> References: <4A54B65D.4010700@unwiredbb.com> Message-ID: <4A5503E6.2050502@justinshore.com> Shon Elliott wrote: > Does anyone have any data on how the memorial event for Michael Jackson effected > the global backbones? This was seen as another inaugural type of traffic day to > most of the people I've talked to. 99.99% of my userbase is in the rural Midwest. Needless to say I saw no increase in bandwidth consumption. Now if it was a streaming memorial for George Strait, Garth Brooks, Little Jimmy Dickens or Willie Nelson I suspect the consumption would have been noticeably higher. I'm sure I would have had much higher bandwidth usage if the PBR National Championship was made available for streaming. Justin From tme at americafree.tv Wed Jul 8 15:46:28 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Wed, 8 Jul 2009 16:46:28 -0400 Subject: Traffic Statistics for Yesterday In-Reply-To: References: <4A54B65D.4010700@unwiredbb.com> <4A54C5CA.2060003@brightok.net> Message-ID: <393F409B-0B10-4FB3-B29D-CDDE3D962CEC@americafree.tv> On Jul 8, 2009, at 12:25 PM, Eric Kujawski wrote: > Speaking from a provider's view, this is what we saw/heard during > the event. > > Total concurrent streams (across the board not just us): 781,000 > > Traffic wise, we peaked at close to 45G over our daily average > across all locations during the MJ event. This was all live > streaming traffic for one of the well known sites. > Jeff Lunsford, CEO of Limelight (@lunk18 on twitter) says Set new traffic record today. MJ's funeral topped Obama's inauguration. Go figure... Follow @llnw for more stats later... Those "more stats" are as yet not available. Regards Marshall Eubanks email : tme at americafree.tv twitter : @TMEubanks Cut the Cord with AmericaFree.TV > Thanks, > > Eric Kujawski > Director of Engineering > ekujawski at softlayer.com > 214-442-0583 direct dial > 469-586-9636 cell > 866-398-7638 toll-free > 214-442-0601 fax > > SoftLayer Technologies, Inc. > 6400 International Parkway, Suite 2000 > Plano, TX 75093 > http://www.softlayer.com > > > > -----Original Message----- > From: Jack Bates [mailto:jbates at brightok.net] > Sent: Wednesday, July 08, 2009 11:14 AM > To: Shon Elliott > Cc: nanog at nanog.org > Subject: Re: Traffic Statistics for Yesterday > > Shon Elliott wrote: >> Does anyone have any data on how the memorial event for Michael >> Jackson effected >> the global backbones? This was seen as another inaugural type of >> traffic day to >> most of the people I've talked to. > > We are far from a global backbone, though the eyeballs transiting > through us appear to have not needed more bandwidth. Was there high > bandwidth apps for the memorial? Seems strange to charge for something > you'd give out free over the Internet. > > > Jack > > > > The contents of this email message and any attachments are > confidential and are intended solely for the addressee. The > information may also be legally privileged. This transmission is > sent in trust for the sole purpose of delivery to the intended > recipient. If you have received this transmission in error; any use, > reproduction or dissemination of this transmission is strictly > prohibited. If you are not the intended recipient, please > immediately notify the sender by reply email and delete this message > and all associated attachments. > > From tme at americafree.tv Wed Jul 8 15:55:09 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Wed, 8 Jul 2009 16:55:09 -0400 Subject: Traffic Statistics for Yesterday In-Reply-To: <393F409B-0B10-4FB3-B29D-CDDE3D962CEC@americafree.tv> References: <4A54B65D.4010700@unwiredbb.com> <4A54C5CA.2060003@brightok.net> <393F409B-0B10-4FB3-B29D-CDDE3D962CEC@americafree.tv> Message-ID: <65466307-5914-43AC-A062-AFD7D3C84597@americafree.tv> On Jul 8, 2009, at 4:46 PM, Marshall Eubanks wrote: > > > On Jul 8, 2009, at 12:25 PM, Eric Kujawski wrote: > >> Speaking from a provider's view, this is what we saw/heard during >> the event. >> >> Total concurrent streams (across the board not just us): 781,000 >> >> Traffic wise, we peaked at close to 45G over our daily average >> across all locations during the MJ event. This was all live >> streaming traffic for one of the well known sites. >> > > Jeff Lunsford, CEO of Limelight (@lunk18 on twitter) says > > Set new traffic record today. MJ's funeral topped Obama's > inauguration. Go figure... Follow @llnw for more stats later... > > Those "more stats" are as yet not available. > More statistics at Layer 4 : http://www.contentinople.com/author.asp?section_id=450&doc_id=178968 Marshall > Regards > Marshall Eubanks > email : tme at americafree.tv > twitter : @TMEubanks > Cut the Cord with AmericaFree.TV > > > >> Thanks, >> >> Eric Kujawski >> Director of Engineering >> ekujawski at softlayer.com >> 214-442-0583 direct dial >> 469-586-9636 cell >> 866-398-7638 toll-free >> 214-442-0601 fax >> >> SoftLayer Technologies, Inc. >> 6400 International Parkway, Suite 2000 >> Plano, TX 75093 >> http://www.softlayer.com >> >> >> >> -----Original Message----- >> From: Jack Bates [mailto:jbates at brightok.net] >> Sent: Wednesday, July 08, 2009 11:14 AM >> To: Shon Elliott >> Cc: nanog at nanog.org >> Subject: Re: Traffic Statistics for Yesterday >> >> Shon Elliott wrote: >>> Does anyone have any data on how the memorial event for Michael >>> Jackson effected >>> the global backbones? This was seen as another inaugural type of >>> traffic day to >>> most of the people I've talked to. >> >> We are far from a global backbone, though the eyeballs transiting >> through us appear to have not needed more bandwidth. Was there high >> bandwidth apps for the memorial? Seems strange to charge for >> something >> you'd give out free over the Internet. >> >> >> Jack >> >> >> >> The contents of this email message and any attachments are >> confidential and are intended solely for the addressee. The >> information may also be legally privileged. This transmission is >> sent in trust for the sole purpose of delivery to the intended >> recipient. If you have received this transmission in error; any >> use, reproduction or dissemination of this transmission is strictly >> prohibited. If you are not the intended recipient, please >> immediately notify the sender by reply email and delete this >> message and all associated attachments. >> >> > > > > > > Regards Marshall Eubanks email : tme at americafree.tv twitter : @TMEubanks Cut the Cord with AmericaFree.TV From jeff-kell at utc.edu Wed Jul 8 15:59:09 2009 From: jeff-kell at utc.edu (Jeff Kell) Date: Wed, 08 Jul 2009 16:59:09 -0400 Subject: Traffic Statistics for Yesterday In-Reply-To: <4A5503E6.2050502@justinshore.com> References: <4A54B65D.4010700@unwiredbb.com> <4A5503E6.2050502@justinshore.com> Message-ID: <4A55089D.2050400@utc.edu> Nothing like inauguration, but then we're on summer semester schedule and sparsely populated :-) There was a noticeable spike in OUTBOUND traffic and connections, mostly that ill-behaved Octoshape (udp/8247), used by CNN and maybe others. Jeff From beckman at angryox.com Wed Jul 8 16:31:18 2009 From: beckman at angryox.com (Peter Beckman) Date: Wed, 8 Jul 2009 17:31:18 -0400 Subject: GoDaddy issues this morning? In-Reply-To: References: Message-ID: On Wed, 8 Jul 2009, Sean wrote: > Anyone know what was the deal with GoDaddy this morning? > I sporadically could not resolve a domain I own this morning. Checked the > authoritative and it was fine... then noticed that it was completely not > working from some ISPs but OK from others, etc. Went to GoDaddy's site and > finally saw a small notice on their support page saying they were having > issues with Verizon customers on the east coast. Well, I'm in Illinois and > I certainly don't consider this the east coast, however some people I know > on a Verizon DSL account could not resolve any of the domains I had > registered on GoDaddy. Also, results from a L3 DIA were sporadic as well. > I really didn't have much time to look at it this morning and now the > notice is gone from their site so I assume it's fixed...? > > Anyone shed some light on this? > Registrar issues are so rare IMHO, Verizon routing issues on the other hand, > I'm not really sure about as I live in AT&T/Comcast country. I can confirm a lot of trouble on Verizon's network from the time I got to my desk (10am EDT) until about 1:45pm EDT. The evidence was very inconsistent: I could get all the way to the last hop before www.cnn.com, but http://www.cnn.com/ (TCP) did not work. Same with several other URLs. In another case, login.oscar.aol.com traceroutes died within Verizon's network. The fact that I could trace to IPs, but not get to them via TCP (or at least the web), was very strange. Maybe Verizon is implementing an Application Layer filter? That would be VERY disappointing. Then again, it could just be a big TCP issue, but I don't know why ICMP would work when TCP didn't. I had no noticable issues once I created an ssh SOCKS proxy through one of my hosted servers on Cox Business fiber, so the issue definitely resided somewhere on Verizon's network. Rackspace also got a lot of complaints, but they pointed the finger at Verizon. Verizon FIOS Tech support also said they were aware of the issue, so I'm guessing something went down with Verizon, not GoDaddy. Search the dslreports.com forums for loud complaining and theories about the Verizon outage. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From tkapela at gmail.com Wed Jul 8 18:04:20 2009 From: tkapela at gmail.com (Anton Kapela) Date: Wed, 8 Jul 2009 19:04:20 -0400 Subject: Point to Point Ethernet In-Reply-To: <4A546E70.9090604@nrg4u.com> References: <4A546E70.9090604@nrg4u.com> Message-ID: <2e9d8ae50907081604uabbba04wb285a40c7c66f102@mail.gmail.com> On Wed, Jul 8, 2009 at 6:01 AM, Andre Oppermann wrote: > Do you think this is useful? ?Maybe vendors will hear me/us. They sort of did a few decades back, created HDLC (5 bytes minimum) and PPP (6 bytes minimum) for P2P links. I think you're at risk of over-thinking this problem working in reverse from ethernet to something slightly-less-than-ethernet. Further, if we want to get truly sizable improvement from 'ethernet like p2p paradigm' we can *drop the damn IFG and preample.* http://sd.wareonearth.com/~phil/net/overhead/ Best case, you blow 12 bytes on IFG in gig, 20 bytes on fast-e/slow-e. No matter how you slice it, it's not getting better than what we've already got (i.e. p2p link prots). Though, I do somewhat relate to your disgust and general sentiments. In 2009 I have cheap asics that can recover clock from line code alone and we're not doing CSMA/CD, so what's the freaking point of IFG and preamble? ./rhetorical (see lanhy vs. wanphy) -Tk From fred at cisco.com Wed Jul 8 18:16:16 2009 From: fred at cisco.com (Fred Baker) Date: Wed, 8 Jul 2009 16:16:16 -0700 Subject: Point to Point Ethernet In-Reply-To: <4A546E70.9090604@nrg4u.com> References: <4A546E70.9090604@nrg4u.com> Message-ID: if it does away with MAC addresses, in what sense is it an Ethernet link? I'll go with EPON or a variety of those. Not sure what messing with the Mac frame actually buys. On Jul 8, 2009, at 3:01 AM, Andre Oppermann wrote: > A few time already I've wished for a fully standardized and vendor > interoperable way of doing a true point to point ethernet link. > > It would work just like an old leased line or synchronous serial > interface and completely do away with ARP, MAC addresses and all > that stuff. Obviously no switches in between would be allowed. > Each side would run in "promiscuous mode" where every ethernet > frame is received and passed up to the network stack (just like > on a serial link). Since MAC addresses are useless they can be > scrapped and only the ethertype field remains. This increases > the effective MTU by 12 bytes. > > The framing overhead goes away and the packet can directly be > directly placed on the wire without taking a detour through L3->L2 > lookup and encapsulation step. > > More importantly one can specify the just the outgoing interface > again instead of the next hop: > > ip route 10.0.0.0 255.0.0.0 g0/1 > > Do you think this is useful? Maybe vendors will hear me/us. > > -- > Andre > From tomb at byrneit.net Wed Jul 8 19:52:35 2009 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Wed, 8 Jul 2009 17:52:35 -0700 Subject: Point to Point Ethernet In-Reply-To: References: <4A546E70.9090604@nrg4u.com> Message-ID: <70D072392E56884193E3D2DE09C097A91F4276@pascal.zaphodb.org> The fundamental disconnect here is that a bunch of Layer 3 guys are trying to define Layer 2. History shows us that Layer 2 winds up being IEEE, and Layer 3 IETF. ITU-T and others write long "standards" that wind up not being so, due to too many "options", while spending lots of money and keeping the airlines, rental car companies, and meeting space vendors in business. If you want "Real Ethernet" (IE multiple access, not point to point) in a metro framework, then why increase the likelihood of collisions by using jumbo frames? If you want to use Ethernet in point to point, then do it, just make sure your optics are up to the task, and the endpoints are configured properly. If what you're looking for is carrier Ethernet with the sort of "craft" interfaces and features you're used to from the telco world, then you may want to talk to Ipitek. (I've done some consulting for them, but am in no way affiliated or compensated for sales.) >-----Original Message----- >From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] >Sent: Wednesday, July 08, 2009 11:33 AM >To: Ricky Beam >Cc: nanog at nanog.org >Subject: Re: Point to Point Ethernet > >On Wed, 8 Jul 2009, Ricky Beam wrote: > >> Ethernet is not a point-to-point technology. It is a multi-point >> (broadcast, bus, etc.) technology with DECADES of optimization and >> adoption. No one has gotten IEEE to adopt a larger frame size, and >you >> want to drop *fundamental* elements of ethernet?!? > >I think the latest suggestion was to do away with the mechanisms, not >change the frame format. It's like when you take a /30, run isis/ospf >over >it and tell the routing protocol it's a point to point link so it >doesn't >have to create a node for the "multi access network" that really isn't >there. > >Same way here, putting the ethernet link in "p2p" mode would mean it >wouldnt do arp anymore, didn't care about source or destination MACs, it >just installed static ARP entry for other end and sent out packets, >other >end would be in promisc mode and accept anything. > >I don't see much gain from this though, and it's another way things can >be >configured wrong and cause havoc if you connect this interface to a LAN. > >-- >Mikael Abrahamsson email: swmike at swm.pp.se From frnkblk at iname.com Wed Jul 8 20:11:11 2009 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 8 Jul 2009 20:11:11 -0500 Subject: Traffic Statistics for Yesterday In-Reply-To: <4A5503E6.2050502@justinshore.com> References: <4A54B65D.4010700@unwiredbb.com> <4A5503E6.2050502@justinshore.com> Message-ID: Ditto here. Did not see any increase. Frank -----Original Message----- From: Justin Shore [mailto:justin at justinshore.com] Sent: Wednesday, July 08, 2009 3:39 PM To: Shon Elliott Cc: nanog at nanog.org Subject: Re: Traffic Statistics for Yesterday Shon Elliott wrote: > Does anyone have any data on how the memorial event for Michael Jackson effected > the global backbones? This was seen as another inaugural type of traffic day to > most of the people I've talked to. 99.99% of my userbase is in the rural Midwest. Needless to say I saw no increase in bandwidth consumption. Now if it was a streaming memorial for George Strait, Garth Brooks, Little Jimmy Dickens or Willie Nelson I suspect the consumption would have been noticeably higher. I'm sure I would have had much higher bandwidth usage if the PBR National Championship was made available for streaming. Justin From pstewart at nexicomgroup.net Wed Jul 8 20:13:42 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Wed, 8 Jul 2009 21:13:42 -0400 Subject: Traffic Statistics for Yesterday In-Reply-To: References: <4A54B65D.4010700@unwiredbb.com> <4A5503E6.2050502@justinshore.com> Message-ID: We were 30% higher than ever seen before in our network.... quite a jump for about an hour... Paul -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: July 8, 2009 9:11 PM To: 'Justin Shore'; Shon Elliott Cc: nanog at nanog.org Subject: RE: Traffic Statistics for Yesterday Ditto here. Did not see any increase. Frank -----Original Message----- From: Justin Shore [mailto:justin at justinshore.com] Sent: Wednesday, July 08, 2009 3:39 PM To: Shon Elliott Cc: nanog at nanog.org Subject: Re: Traffic Statistics for Yesterday Shon Elliott wrote: > Does anyone have any data on how the memorial event for Michael Jackson effected > the global backbones? This was seen as another inaugural type of traffic day to > most of the people I've talked to. 99.99% of my userbase is in the rural Midwest. Needless to say I saw no increase in bandwidth consumption. Now if it was a streaming memorial for George Strait, Garth Brooks, Little Jimmy Dickens or Willie Nelson I suspect the consumption would have been noticeably higher. I'm sure I would have had much higher bandwidth usage if the PBR National Championship was made available for streaming. Justin ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From randy at psg.com Wed Jul 8 20:16:54 2009 From: randy at psg.com (Randy Bush) Date: Thu, 09 Jul 2009 10:16:54 +0900 Subject: Point to Point Ethernet In-Reply-To: <70D072392E56884193E3D2DE09C097A91F4276@pascal.zaphodb.org> References: <4A546E70.9090604@nrg4u.com> <70D072392E56884193E3D2DE09C097A91F4276@pascal.zaphodb.org> Message-ID: > History shows us that Layer 2 winds up being IEEE, and Layer 3 IETF. mpls From sthaug at nethelp.no Thu Jul 9 01:34:12 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 09 Jul 2009 08:34:12 +0200 (CEST) Subject: Point to Point Ethernet In-Reply-To: <2e9d8ae50907081604uabbba04wb285a40c7c66f102@mail.gmail.com> References: <4A546E70.9090604@nrg4u.com> <2e9d8ae50907081604uabbba04wb285a40c7c66f102@mail.gmail.com> Message-ID: <20090709.083412.74715921.sthaug@nethelp.no> > Best case, you blow 12 bytes on IFG in gig, 20 bytes on fast-e/slow-e. As far as I know Gig and 10 Gig (with LAN PHY) are exactly the same as 10 and 100 Mbps in this respect, i.e. 8 bytes of preamble and 12 bytes of IFG. So you always have an overhead of 20 bytes, no matter what. 10 Gig with WAN PHY is a whole different ballgame, of course. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From tomb at byrneit.net Thu Jul 9 01:51:05 2009 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Wed, 8 Jul 2009 23:51:05 -0700 Subject: Point to Point Ethernet In-Reply-To: <20090709.083412.74715921.sthaug@nethelp.no> References: <4A546E70.9090604@nrg4u.com><2e9d8ae50907081604uabbba04wb285a40c7c66f102@mail.gmail.com> <20090709.083412.74715921.sthaug@nethelp.no> Message-ID: <70D072392E56884193E3D2DE09C097A91F427B@pascal.zaphodb.org> Overhead shmoverhead. Seriously, we're fighting over the non-issue. It's not the "wasted" 0.02% of bandwidth (@ 1Gbps) that's the issue. It's the utility of a "come as you are" "plug and play" network that "Ethernet" (which really loosely means all IEEE 802 protocols) provides, which the current carrier networks do not. If I read the thread correctly, what you really are asking for is the ability to plug your IEEE compliant gig/10gig switch into a carrier port and just have it ARP and respond for valid IP addresses on the segment, as opposed to all the back and forth provisioning, truck rolls, and interaction with bell-head union workers that the current system requires. Now, HOW to accomplish that is an interesting discussion, and the first valid result will probably be a great business. That doesn't require breaking Ethernet, using promiscuous mode, or much except the carriers stopping trying to throw their legacy circuit-switched requirements onto a packet switched network. There's plenty of fiber in the ground. Light dark stuff with the new network, plug it into IEEE 802* compliant layer 2, and IETF compliant layer 3 infrastructure; and leave the dying Bellcore/ITU network on the old copper and SONET. >-----Original Message----- >From: sthaug at nethelp.no [mailto:sthaug at nethelp.no] >Sent: Wednesday, July 08, 2009 11:34 PM >To: tkapela at gmail.com >Cc: nanog at nanog.org >Subject: Re: Point to Point Ethernet > >> Best case, you blow 12 bytes on IFG in gig, 20 bytes on fast-e/slow-e. > >As far as I know Gig and 10 Gig (with LAN PHY) are exactly the same >as 10 and 100 Mbps in this respect, i.e. 8 bytes of preamble and 12 >bytes of IFG. So you always have an overhead of 20 bytes, no matter >what. > >10 Gig with WAN PHY is a whole different ballgame, of course. > >Steinar Haug, Nethelp consulting, sthaug at nethelp.no From msaqib at gmail.com Thu Jul 9 02:03:04 2009 From: msaqib at gmail.com (Saqib Ilyas) Date: Thu, 9 Jul 2009 12:03:04 +0500 Subject: Point to Point Ethernet In-Reply-To: <70D072392E56884193E3D2DE09C097A91F427B@pascal.zaphodb.org> References: <4A546E70.9090604@nrg4u.com> <2e9d8ae50907081604uabbba04wb285a40c7c66f102@mail.gmail.com> <20090709.083412.74715921.sthaug@nethelp.no> <70D072392E56884193E3D2DE09C097A91F427B@pascal.zaphodb.org> Message-ID: <262b67200907090003s4f486299r10c8bf331e77e889@mail.gmail.com> For the sake of my knowledge (and perhaps that of some others on the list), I would like to ask if the current work on standards by IETF, ITU and IEEE not a step to address the issue of seamlessly using Ethernet in the metro/core? IETF is working on GMPLS Ethernet Label Switching (GELS), which proposes to replace the Ethernet control plane (MAC learning, spanning tree etc) by the GMPLS control plane. This would provide explicitly routed Ethernet LSPs. ITU seems to be working on Transport MPLS (T-MPLS), and IEEE seems to be at work on the Provider Backbone Bridge (PBB) standard. Granted the difficulties and faults with the standardization process, my question is more concerned with the technical nature. Thanks and best regards On Thu, Jul 9, 2009 at 11:51 AM, Tomas L. Byrnes wrote: > Overhead shmoverhead. > > Seriously, we're fighting over the non-issue. It's not the "wasted" > 0.02% of bandwidth (@ 1Gbps) that's the issue. It's the utility of a > "come as you are" "plug and play" network that "Ethernet" (which really > loosely means all IEEE 802 protocols) provides, which the current > carrier networks do not. > > If I read the thread correctly, what you really are asking for is the > ability to plug your IEEE compliant gig/10gig switch into a carrier port > and just have it ARP and respond for valid IP addresses on the segment, > as opposed to all the back and forth provisioning, truck rolls, and > interaction with bell-head union workers that the current system > requires. > > Now, HOW to accomplish that is an interesting discussion, and the first > valid result will probably be a great business. > > That doesn't require breaking Ethernet, using promiscuous mode, or much > except the carriers stopping trying to throw their legacy > circuit-switched requirements onto a packet switched network. > > There's plenty of fiber in the ground. Light dark stuff with the new > network, plug it into IEEE 802* compliant layer 2, and IETF compliant > layer 3 infrastructure; and leave the dying Bellcore/ITU network on the > old copper and SONET. > > > >-----Original Message----- > >From: sthaug at nethelp.no [mailto:sthaug at nethelp.no] > >Sent: Wednesday, July 08, 2009 11:34 PM > >To: tkapela at gmail.com > >Cc: nanog at nanog.org > >Subject: Re: Point to Point Ethernet > > > >> Best case, you blow 12 bytes on IFG in gig, 20 bytes on > fast-e/slow-e. > > > >As far as I know Gig and 10 Gig (with LAN PHY) are exactly the same > >as 10 and 100 Mbps in this respect, i.e. 8 bytes of preamble and 12 > >bytes of IFG. So you always have an overhead of 20 bytes, no matter > >what. > > > >10 Gig with WAN PHY is a whole different ballgame, of course. > > > >Steinar Haug, Nethelp consulting, sthaug at nethelp.no > > > -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences From swmike at swm.pp.se Thu Jul 9 02:11:37 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 9 Jul 2009 09:11:37 +0200 (CEST) Subject: Point to Point Ethernet In-Reply-To: <70D072392E56884193E3D2DE09C097A91F427B@pascal.zaphodb.org> References: <4A546E70.9090604@nrg4u.com><2e9d8ae50907081604uabbba04wb285a40c7c66f102@mail.gmail.com> <20090709.083412.74715921.sthaug@nethelp.no> <70D072392E56884193E3D2DE09C097A91F427B@pascal.zaphodb.org> Message-ID: On Wed, 8 Jul 2009, Tomas L. Byrnes wrote: > There's plenty of fiber in the ground. Light dark stuff with the new > network, plug it into IEEE 802* compliant layer 2, and IETF compliant > layer 3 infrastructure; and leave the dying Bellcore/ITU network on the > old copper and SONET. Have you built an nationwide greenfield network based on dark fibre and ethernet? I have. Don't misrepresent the problems that might arise from this. It might be easier to do compared to a SONET network, but it's still a can of worms and you definitely want a lot of the "bellhead" stuff you're ridiculing. -- Mikael Abrahamsson email: swmike at swm.pp.se From david at hughes.com.au Thu Jul 9 03:51:35 2009 From: david at hughes.com.au (David Hughes) Date: Thu, 9 Jul 2009 18:51:35 +1000 Subject: Call for Presentations - AusNOG-03 Message-ID: Call for Presentations - AusNOG-03 --------------------------------- AusNOG-03 is to be held in Sydney, Australia between 31st August and 1st of September 2009 The AusNOG meeting provides the Australian community with a forum to exchange information and experiences on a number of issues relating to the operation and support of networks, with a specific focus on the coming 6-12 months. The conference is expected to have a strong technical representation from companies operating networks in Australia. Details of AusNOG-03 and past meetings can be found on the AusNOG web site at www.ausnog.net. Submissions ------------ Please read the information below carefully. Send your proposed topics and details to organisers at ausnog.net. Please include a detailed overview including the expected length and technical depth of your presentation. The program committee will confirm your application and may get back to you with any questions. Please remember this is a technical event for network operators and presentations should be representative of this. Marketing presentations or presentations focusing on specific products are not suitable for this event. Some areas of current interest to the target audience are listed below. These are simply suggested topic areas and the committee will happily consider proposals for papers covering any facet of network technology, network operation, or the industry. 1. NBN Technology. High speed access, core, edge, border... Access speeds measured at 100M will present all sort of challenges across the provider sphere. As so much is yet unknown how the NBN will land on us, will there be the ability to specify the edge device or policy. Either way talks on experience in this space is what we are seeking. 2. Backhaul. Increasing end user speeds in an NBN world will see a requirement for increased backhaul. How do you implement a multi hundred gigabit backhaul network ? What are the issues for wholesale play with this type of undertaking ? 3. Content to the Edge. Whilst we are about to enter the work of real competition in international access and bandwidth is about as inexpensive as it has ever been we are still a small population very far away from the main Internet trade routes. Experience with CDN, distributed content applications and how operators leverage servers, DNS, load balancers etc to bring about an outcome. 4. Operational Best Practices. Tools, methodologies and techniques that can improve the reliability and efficiency of IP Networks. Configuration management, configuration automation, routing registries, performance monitoring and availability monitoring are always of interest to operators. 5. Regulatory, Market Data and Overseas Trends (Regulatory and Industry Bodies Updates, Market Data and Statistics, Trends from Overseas Markets) Panel Discussions ----------------- - Required Panellists: 8-10 - Panel Length: 45 mins - Number of Panels: 2 Panels are the interactive part of the conference. The job of Panellists will be to stimulate and moderate the discussion. Whether you are on the panel or in the audience your input would be appreciated. The two Panel Topics will be related to the industry at the time of the conference. Propose a topic that you think will be interesting, or if you think you are interesting, propose yourself for inclusion to the panel :-) Keynote Addresses ----------------- - Required Speakers: 2 - Presentation Length: 45 mins - Number of Topics: 2 We are seeking 2 speakers for Keynotes Addresses. Each Keynote will be of 45 mins in length, including time for input from the industry. If you would like to be considered for a Keynote topic, please email organisers at ausnog.net with details of yourself and your topic. Important Dates --------------- - 10 July 2009 - Call for Presentations Opens - 26 July 2009 - Deadline for Proposals - 3 August 2009 - Response to presentation proposals - 10 August 2009 - Draft program published to website - 17 August 2009 - Final program published The AusNOG-03 Organisers ... From timothy.arnold at uksolutions.co.uk Thu Jul 9 04:31:13 2009 From: timothy.arnold at uksolutions.co.uk (Timothy Arnold) Date: Thu, 9 Jul 2009 10:31:13 +0100 Subject: OT: Bringing Cisco equipment to US In-Reply-To: References: <9C25883F-4BCF-44BA-914E-8F41EA4394FB@hopcount.ca> Message-ID: > Jumping on the back of this thread, does anyone have any recommendations > for suppliers of Cisco kit in the states? I don't fancy dealing with customs & > international shipping. > Thanks to the significant number of individuals who have replied. Once I've got the kit shipped to NY, I am going to need some smart hands work to kit out and perform some basic config. Does anyone have any recommendations for companies that do this? Thanks Again! Tim Timothy Arnold Senior Engineer, Operations (Network, Security & Facilities Group), UKSolutions Telephone: 0845 004 1333, option 2 Email: timothy.arnold at uksolutions.co.uk Web: http://www.uksolutions.co.uk/ UKS Ltd, Birmingham Road, Studley, Warwickshire, B80 7BG Registered in England Number 3036806 This email must be read in conjunction with the legal & service notices on http://www.uksolutions.co.uk/disclaimer From mikael at gogo6.com Thu Jul 9 05:24:14 2009 From: mikael at gogo6.com (Mikael Lind) Date: Thu, 9 Jul 2009 12:24:14 +0200 Subject: Drop in IPv6 traffic Message-ID: <54a6fa920907090324p13f1957bx744057316349a3c1@mail.gmail.com> Hi, I've seen a big drop in IPv6 traffic volume on our Freenet6 IPv6 service last night and it seems to be the same on AMS-IX. Has anyone else seen the same? Any idea why? Thanks, Mikael From marcoh at marcoh.net Thu Jul 9 06:57:38 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 9 Jul 2009 13:57:38 +0200 Subject: Drop in IPv6 traffic In-Reply-To: <54a6fa920907090324p13f1957bx744057316349a3c1@mail.gmail.com> References: <54a6fa920907090324p13f1957bx744057316349a3c1@mail.gmail.com> Message-ID: <53C686C3-5751-4D33-9817-9CF22ADDBCAA@marcoh.net> On 9 jul 2009, at 12:24, Mikael Lind wrote: > Hi, > I've seen a big drop in IPv6 traffic volume on our Freenet6 IPv6 > service last night and it seems to be the same on AMS-IX. > Has anyone else seen the same? Any idea why? Multiple options, but it must have something todo with a free usenet service. We (XS4ALL, AS3265) changed some filters at around 15:00 GMT, but I notice the drop is hours later and much bigger (se the graph at https://www.ams-ix.net/technical/stats/sflow/) . If you have trouble reaching newszilla6.xs4all.nl at port 119 please drop me a note as you might accidently got filtered and I'm happy to resolve this. From the looks of it one of our colleagues who also run a free usenet box have some issues as well, news.ipv6.eweka.nl isn't responding, which may well be the only cause of this little drop. Groet, MarcoH From labovit at arbor.net Thu Jul 9 07:10:15 2009 From: labovit at arbor.net (Craig Labovitz) Date: Thu, 9 Jul 2009 08:10:15 -0400 Subject: Traffic Statistics for Yesterday In-Reply-To: <4A54B65D.4010700@unwiredbb.com> References: <4A54B65D.4010700@unwiredbb.com> Message-ID: <8F7A5C26-159B-4A2A-8468-C418B7D61699@arbor.net> It was big (flash traffic roughly doubled globally at the peak), but not in the same ballpark as Obama inauguration. A graph of July 7 flash traffic across 97 tier1/2 ISPs compared with the daily average: http://farm3.static.flickr.com/2581/3704208402_34ca00597d.jpg?v=0 - Craig On Jul 8, 2009, at 11:08 AM, Shon Elliott wrote: > Does anyone have any data on how the memorial event for Michael > Jackson effected > the global backbones? This was seen as another inaugural type of > traffic day to > most of the people I've talked to. From eric at atlantech.net Thu Jul 9 07:26:35 2009 From: eric at atlantech.net (Eric Van Tol) Date: Thu, 9 Jul 2009 08:26:35 -0400 Subject: Traffic Statistics for Yesterday In-Reply-To: <8F7A5C26-159B-4A2A-8468-C418B7D61699@arbor.net> References: <4A54B65D.4010700@unwiredbb.com> <8F7A5C26-159B-4A2A-8468-C418B7D61699@arbor.net> Message-ID: <2C05E949E19A9146AF7BDF9D44085B86353E994FCF@exchange.aoihq.local> > -----Original Message----- > From: Craig Labovitz [mailto:labovit at arbor.net] > Sent: Thursday, July 09, 2009 8:10 AM > To: Shon Elliott > Cc: nanog at nanog.org > Subject: Re: Traffic Statistics for Yesterday > > > It was big (flash traffic roughly doubled globally at the peak), but > not in the same ballpark as Obama inauguration. > > A graph of July 7 flash traffic across 97 tier1/2 ISPs compared with > the daily average: > http://farm3.static.flickr.com/2581/3704208402_34ca00597d.jpg?v=0 > > - Craig Our traffic was doubled for MJ, actually 1/3 *more* than Obama. However, we're regional to DC, so I can only imagine that since the inauguration was a huge local event, many of our customers were either working from home that day or actually there and not watching it on the internet. -evt From jeroen at easyhosting.nl Thu Jul 9 08:27:58 2009 From: jeroen at easyhosting.nl (Jeroen Wunnink) Date: Thu, 09 Jul 2009 15:27:58 +0200 Subject: Drop in IPv6 traffic In-Reply-To: <53C686C3-5751-4D33-9817-9CF22ADDBCAA@marcoh.net> References: <54a6fa920907090324p13f1957bx744057316349a3c1@mail.gmail.com> <53C686C3-5751-4D33-9817-9CF22ADDBCAA@marcoh.net> Message-ID: <4A55F05E.4070000@easyhosting.nl> Same here, we usually do 40-100Mbit of teredo 2001::/32 anycast traffic (a lot of which is news traffic over IPv6 to artrato/XSnews) and that dropped to an all-time low a bit before 0:00 CET. I know XSnews had a free IPv6 news account service, perhaps they closed that ? Marco Hogewoning wrote: > > On 9 jul 2009, at 12:24, Mikael Lind wrote: > >> Hi, >> I've seen a big drop in IPv6 traffic volume on our Freenet6 IPv6 >> service last night and it seems to be the same on AMS-IX. >> Has anyone else seen the same? Any idea why? > > > Multiple options, but it must have something todo with a free usenet > service. > > We (XS4ALL, AS3265) changed some filters at around 15:00 GMT, but I > notice the drop is hours later and much bigger (se the graph at > https://www.ams-ix.net/technical/stats/sflow/). > > If you have trouble reaching newszilla6.xs4all.nl at port 119 please > drop me a note as you might accidently got filtered and I'm happy to > resolve this. > > From the looks of it one of our colleagues who also run a free usenet > box have some issues as well, news.ipv6.eweka.nl isn't responding, > which may well be the only cause of this little drop. > > Groet, > > MarcoH > > -- Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer at easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl From gdt at gdt.id.au Thu Jul 9 08:31:31 2009 From: gdt at gdt.id.au (Glen Turner) Date: Thu, 09 Jul 2009 23:01:31 +0930 Subject: OT: Bringing Cisco equipment to US In-Reply-To: References: <9C25883F-4BCF-44BA-914E-8F41EA4394FB@hopcount.ca> Message-ID: <4A55F133.10604@gdt.id.au> On 30/06/09 07:59, John Edwards wrote: > The courier will likely charge you less than a customs broker will for a > single item - the brokers are mainly used for large transactions. While > you're legally entitled to bring this equipment in carry-on luggage, > proving and authenticating your right can be a costly and timely exercise. The other problem is that an import implies a change of ownership from an overseas company to a US company. Setting up a US holding company to "own" your "imported" US assets is a major pain and best avoided where possible. Especially as that company may be a a "foreign telecommunications carrier" and the US has rather wonderful laws covering those. I've done a lot of Australia-US import/export, and I'd very much suggest building a good relationship with a customs broker. That's hardly an expense you want for two switches, so buying the switches in the US (where they come with a valid warranty and correct power leads) is a good idea. I wouldn't recommend importing the switches through your luggage. The few times I've tried that arranging all of the documentation prior to travel has really sucked. As a trivial example of what can go wrong, if you unknowingly choose an airport where customs works 9am-5pm and your flight arrives at 2am, then you've got a rather long wait in the walkway between Immigration and Customs. So long a wait that you're likely to encounter some other difficulty from the airport authorities. -- Glen Turner From jhary at unsane.co.uk Thu Jul 9 08:50:48 2009 From: jhary at unsane.co.uk (Vincent Hoffman) Date: Thu, 09 Jul 2009 14:50:48 +0100 Subject: Drop in IPv6 traffic In-Reply-To: <4A55F05E.4070000@easyhosting.nl> References: <54a6fa920907090324p13f1957bx744057316349a3c1@mail.gmail.com> <53C686C3-5751-4D33-9817-9CF22ADDBCAA@marcoh.net> <4A55F05E.4070000@easyhosting.nl> Message-ID: <4A55F5B8.1030908@unsane.co.uk> Jeroen Wunnink wrote: > Same here, we usually do 40-100Mbit of teredo 2001::/32 anycast traffic > (a lot of which is news traffic over IPv6 to artrato/XSnews) and that > dropped to an all-time low a bit before 0:00 CET. > > I know XSnews had a free IPv6 news account service, perhaps they closed > that ? Assuming that the graph at http://www.xsnews.com/ipv6/ isnt broken for any other reason, you may well be right Vince > > Marco Hogewoning wrote: >> >> On 9 jul 2009, at 12:24, Mikael Lind wrote: >> >>> Hi, >>> I've seen a big drop in IPv6 traffic volume on our Freenet6 IPv6 >>> service last night and it seems to be the same on AMS-IX. >>> Has anyone else seen the same? Any idea why? >> >> >> Multiple options, but it must have something todo with a free usenet >> service. >> >> We (XS4ALL, AS3265) changed some filters at around 15:00 GMT, but I >> notice the drop is hours later and much bigger (se the graph at >> https://www.ams-ix.net/technical/stats/sflow/). >> >> If you have trouble reaching newszilla6.xs4all.nl at port 119 please >> drop me a note as you might accidently got filtered and I'm happy to >> resolve this. >> >> From the looks of it one of our colleagues who also run a free usenet >> box have some issues as well, news.ipv6.eweka.nl isn't responding, >> which may well be the only cause of this little drop. >> >> Groet, >> >> MarcoH >> >> > From jeroen at easyhosting.nl Thu Jul 9 08:53:41 2009 From: jeroen at easyhosting.nl (Jeroen Wunnink) Date: Thu, 09 Jul 2009 15:53:41 +0200 Subject: Drop in IPv6 traffic In-Reply-To: <4A55F05E.4070000@easyhosting.nl> References: <54a6fa920907090324p13f1957bx744057316349a3c1@mail.gmail.com> <53C686C3-5751-4D33-9817-9CF22ADDBCAA@marcoh.net> <4A55F05E.4070000@easyhosting.nl> Message-ID: <4A55F665.80003@easyhosting.nl> Just spoke with Michiel of Atrato / XSnews, they had some issues with an internal part of XSnews which also affected their IPv6 enabled services. Jeroen Wunnink wrote: > Same here, we usually do 40-100Mbit of teredo 2001::/32 anycast > traffic (a lot of which is news traffic over IPv6 to artrato/XSnews) > and that dropped to an all-time low a bit before 0:00 CET. > > I know XSnews had a free IPv6 news account service, perhaps they > closed that ? > > Marco Hogewoning wrote: >> >> On 9 jul 2009, at 12:24, Mikael Lind wrote: >> >>> Hi, >>> I've seen a big drop in IPv6 traffic volume on our Freenet6 IPv6 >>> service last night and it seems to be the same on AMS-IX. >>> Has anyone else seen the same? Any idea why? >> >> >> Multiple options, but it must have something todo with a free usenet >> service. >> >> We (XS4ALL, AS3265) changed some filters at around 15:00 GMT, but I >> notice the drop is hours later and much bigger (se the graph at >> https://www.ams-ix.net/technical/stats/sflow/). >> >> If you have trouble reaching newszilla6.xs4all.nl at port 119 please >> drop me a note as you might accidently got filtered and I'm happy to >> resolve this. >> >> From the looks of it one of our colleagues who also run a free usenet >> box have some issues as well, news.ipv6.eweka.nl isn't responding, >> which may well be the only cause of this little drop. >> >> Groet, >> >> MarcoH >> >> > -- Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer at easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl From michiel.muhlenbaumer at atratoip.net Thu Jul 9 08:58:06 2009 From: michiel.muhlenbaumer at atratoip.net (michiel.muhlenbaumer at atratoip.net) Date: Thu, 9 Jul 2009 15:58:06 +0200 (CEST) Subject: Drop in IPv6 traffic In-Reply-To: <4A55F665.80003@easyhosting.nl> References: <54a6fa920907090324p13f1957bx744057316349a3c1@mail.gmail.com> <53C686C3-5751-4D33-9817-9CF22ADDBCAA@marcoh.net> <4A55F05E.4070000@easyhosting.nl> <4A55F665.80003@easyhosting.nl> Message-ID: <4f965b32e937218e58e30be0c7fbf113.squirrel@www.atrato.nl> Hi Jeroen & others, Yep, looks like we are doing a great portion of AMSIX's IPv6 traffic and our (free) IPv6 service was affected because of an internal error last night around 00.30 am. I'll put it up in a few hours for you free leechers :-) Cheers, Michiel > Just spoke with Michiel of Atrato / XSnews, they had some issues with an > internal part of XSnews which also affected their IPv6 enabled services. > > > Jeroen Wunnink wrote: >> Same here, we usually do 40-100Mbit of teredo 2001::/32 anycast >> traffic (a lot of which is news traffic over IPv6 to artrato/XSnews) >> and that dropped to an all-time low a bit before 0:00 CET. >> >> I know XSnews had a free IPv6 news account service, perhaps they >> closed that ? >> >> Marco Hogewoning wrote: >>> >>> On 9 jul 2009, at 12:24, Mikael Lind wrote: >>> >>>> Hi, >>>> I've seen a big drop in IPv6 traffic volume on our Freenet6 IPv6 >>>> service last night and it seems to be the same on AMS-IX. >>>> Has anyone else seen the same? Any idea why? >>> >>> >>> Multiple options, but it must have something todo with a free usenet >>> service. >>> >>> We (XS4ALL, AS3265) changed some filters at around 15:00 GMT, but I >>> notice the drop is hours later and much bigger (se the graph at >>> https://www.ams-ix.net/technical/stats/sflow/). >>> >>> If you have trouble reaching newszilla6.xs4all.nl at port 119 please >>> drop me a note as you might accidently got filtered and I'm happy to >>> resolve this. >>> >>> From the looks of it one of our colleagues who also run a free usenet >>> box have some issues as well, news.ipv6.eweka.nl isn't responding, >>> which may well be the only cause of this little drop. >>> >>> Groet, >>> >>> MarcoH >>> >>> >> > > -- > > Met vriendelijke groet, > > Jeroen Wunnink, > EasyHosting B.V. Systeembeheerder > systeembeheer at easyhosting.nl > > telefoon:+31 (035) 6285455 Postbus 48 > fax: +31 (035) 6838242 3755 ZG Eemnes > > http://www.easyhosting.nl > http://www.easycolocate.nl > > > > From patrick at ianai.net Thu Jul 9 09:10:24 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 9 Jul 2009 10:10:24 -0400 Subject: Drop in IPv6 traffic In-Reply-To: <4f965b32e937218e58e30be0c7fbf113.squirrel@www.atrato.nl> References: <54a6fa920907090324p13f1957bx744057316349a3c1@mail.gmail.com> <53C686C3-5751-4D33-9817-9CF22ADDBCAA@marcoh.net> <4A55F05E.4070000@easyhosting.nl> <4A55F665.80003@easyhosting.nl> <4f965b32e937218e58e30be0c7fbf113.squirrel@www.atrato.nl> Message-ID: On Jul 9, 2009, at 9:58 AM, michiel.muhlenbaumer at atratoip.net wrote: > Hi Jeroen & others, > > Yep, looks like we are doing a great portion of AMSIX's IPv6 traffic > and > our (free) IPv6 service was affected because of an internal error last > night around 00.30 am. Michiel, Thank you for the information. Could you let us know if XS4All's free v6 news feed went to zero, or was just dropped by some percentage? I ask because the AMS-IX is frequently used as an example that v6 is being heavily adopted. If it is all one source for one application, that is important information to the people fighting for v6 adoption. Going from peaks of 1.4 Gbps to 0.4 Gbps is impressive. If that 0.4 Gbps still includes some of your traffic, it is very impressive. -- TTFN, patrick > I'll put it up in a few hours for you free leechers :-) > > Cheers, > Michiel > >> Just spoke with Michiel of Atrato / XSnews, they had some issues >> with an >> internal part of XSnews which also affected their IPv6 enabled >> services. >> >> >> Jeroen Wunnink wrote: >>> Same here, we usually do 40-100Mbit of teredo 2001::/32 anycast >>> traffic (a lot of which is news traffic over IPv6 to artrato/XSnews) >>> and that dropped to an all-time low a bit before 0:00 CET. >>> >>> I know XSnews had a free IPv6 news account service, perhaps they >>> closed that ? >>> >>> Marco Hogewoning wrote: >>>> >>>> On 9 jul 2009, at 12:24, Mikael Lind wrote: >>>> >>>>> Hi, >>>>> I've seen a big drop in IPv6 traffic volume on our Freenet6 IPv6 >>>>> service last night and it seems to be the same on AMS-IX. >>>>> Has anyone else seen the same? Any idea why? >>>> >>>> >>>> Multiple options, but it must have something todo with a free >>>> usenet >>>> service. >>>> >>>> We (XS4ALL, AS3265) changed some filters at around 15:00 GMT, but I >>>> notice the drop is hours later and much bigger (se the graph at >>>> https://www.ams-ix.net/technical/stats/sflow/). >>>> >>>> If you have trouble reaching newszilla6.xs4all.nl at port 119 >>>> please >>>> drop me a note as you might accidently got filtered and I'm happy >>>> to >>>> resolve this. >>>> >>>> From the looks of it one of our colleagues who also run a free >>>> usenet >>>> box have some issues as well, news.ipv6.eweka.nl isn't responding, >>>> which may well be the only cause of this little drop. >>>> >>>> Groet, >>>> >>>> MarcoH >>>> >>>> >>> >> >> -- >> >> Met vriendelijke groet, >> >> Jeroen Wunnink, >> EasyHosting B.V. Systeembeheerder >> systeembeheer at easyhosting.nl >> >> telefoon:+31 (035) 6285455 Postbus 48 >> fax: +31 (035) 6838242 3755 ZG Eemnes >> >> http://www.easyhosting.nl >> http://www.easycolocate.nl >> >> >> >> > > > From cayle.spandon at gmail.com Thu Jul 9 09:29:56 2009 From: cayle.spandon at gmail.com (Cayle Spandon) Date: Thu, 9 Jul 2009 10:29:56 -0400 Subject: Point to Point Ethernet In-Reply-To: References: <4A546E70.9090604@nrg4u.com> <2e9d8ae50907081604uabbba04wb285a40c7c66f102@mail.gmail.com> <20090709.083412.74715921.sthaug@nethelp.no> <70D072392E56884193E3D2DE09C097A91F427B@pascal.zaphodb.org> Message-ID: <71c13900907090729q5a6cc243s27aafd06d67ce288@mail.gmail.com> I frequently run into scenarios where two devices (two routers, or a router and a host) need a point-to-point connection to each other with a capacity of (much) more than 10 Gbps. For cost reasons, Ethernet is often used. Since more than 10 Gbps is needed, we end up with multiple parallel 10GE point-to-point connections. Because the devices often don't support LAG or have limitations on the number of links in a LAG, we often cannot use LAG at all or cannot put all 10GE links in a single LAG group. So, we end up with multiple parallel layer-3 point-to-point connections where each connections is either an Ethernet or a LAG group. Furthermore, in order to conserve IP addresses, there is a desire to make these interfaces unnumbered. The involved devices have a numbered loopback interface whose address is used as the "donor" for the unnumbered Ethernet / LAG interfaces. Most router vendors already support unnumbered point-to-point Ethernet, see for example: http://www.juniper.net/techpubs/en_US/junos9.5/information-products/topic-collections/config-guide-network-interfaces/interfaces-configuring-an-unnumbered-interface.html#id-10432956 However, there are some interoperability issues / open questions related to point-to-point unnumbered Ethernet, see for example: http://forums.juniper.net/jnet/board/message?board.id=JUNOS&message.id=130 http://forums.juniper.net/jnet/board/message?board.id=switch&thread.id=835 I would be very interested in some standards (i.e. an IETF BCP) to describe the best current practices for these applications of Ethernet. I am not particularly interested in re-inventing a new flavor of Ethernet for this application. All that is needed, in my opinion, is some clarifications or best practices on how to use the existing standards to create point-to-point unnumbered Ethernet connections. PS -- I am also aware of some esoteric BRAS applications of Ethernet where one side is numbered and the other side is unnumbered. From marcoh at marcoh.net Thu Jul 9 09:29:45 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 9 Jul 2009 16:29:45 +0200 Subject: Drop in IPv6 traffic In-Reply-To: References: <54a6fa920907090324p13f1957bx744057316349a3c1@mail.gmail.com> <53C686C3-5751-4D33-9817-9CF22ADDBCAA@marcoh.net> <4A55F05E.4070000@easyhosting.nl> <4A55F665.80003@easyhosting.nl> <4f965b32e937218e58e30be0c7fbf113.squirrel@www.atrato.nl> Message-ID: Hi Patrick , On 9 jul 2009, at 16:10, Patrick W. Gilmore wrote: > On Jul 9, 2009, at 9:58 AM, michiel.muhlenbaumer at atratoip.net wrote: > >> Hi Jeroen & others, >> >> Yep, looks like we are doing a great portion of AMSIX's IPv6 >> traffic and >> our (free) IPv6 service was affected because of an internal error >> last >> night around 00.30 am. > > Michiel, > > Thank you for the information. Could you let us know if XS4All's > free v6 news feed went to zero, or was just dropped by some > percentage? Please note Michiel isn't from XS4ALL :) We (XS4ALL) did not have any outage on the usenet service, everything is still running and passing traffic. The only thing we did was adjust some filters so if you are depend on more specifics and not announcing the /32 you might have been dropped from the table around 15:00 GMT. The remaining traffic at ams-ix matches our internal graphs, so I guess I'm the only bulk sender at the moment. > I ask because the AMS-IX is frequently used as an example that v6 is > being heavily adopted. If it is all one source for one application, > that is important information to the people fighting for v6 > adoption. Going from peaks of 1.4 Gbps to 0.4 Gbps is impressive. > If that 0.4 Gbps still includes some of your traffic, it is very > impressive. There are 3 open usenet servers at amsterdam that I know off: - XS4ALL (at newszilla6.xs4all.nl) - Highwinds/Eweka (news.ipv6.eweka.nl) - XSnews I think we, once again, have proof 99% of the ams-ix traffic. The remaining bit possibly is google and the traffic on this mailinglist (and ripe.net). As an exercise we could see if spikes in nanog activity can be matched to spikes in the v6 traffic :) Groet, MarcoH From michiel.muhlenbaumer at atratoip.net Thu Jul 9 09:34:45 2009 From: michiel.muhlenbaumer at atratoip.net (michiel.muhlenbaumer at atratoip.net) Date: Thu, 9 Jul 2009 16:34:45 +0200 (CEST) Subject: Drop in IPv6 traffic In-Reply-To: References: <54a6fa920907090324p13f1957bx744057316349a3c1@mail.gmail.com> <53C686C3-5751-4D33-9817-9CF22ADDBCAA@marcoh.net> <4A55F05E.4070000@easyhosting.nl> <4A55F665.80003@easyhosting.nl> <4f965b32e937218e58e30be0c7fbf113.squirrel@www.atrato.nl> Message-ID: <85e2f36481960982cd1e9a770e5c6ef9.squirrel@www.atrato.nl> > Michiel, > > Thank you for the information. Could you let us know if XS4All's free > v6 news feed went to zero, or was just dropped by some percentage? > > I ask because the AMS-IX is frequently used as an example that v6 is > being heavily adopted. If it is all one source for one application, > that is important information to the people fighting for v6 adoption. > Going from peaks of 1.4 Gbps to 0.4 Gbps is impressive. If that 0.4 > Gbps still includes some of your traffic, it is very impressive. > > -- > TTFN, > patrick Hi Patrick, The XS4All IPv6 service is run by .. XS4All. We (XS News) run a separate service and we were responsible for the drop from ~950Mbit IPv6 traffic to 300M IPv6 traffic at 00.30 AM last night. I'll put the service up again (wasn't notified) and we can continue adopting IPv6 again ;) Cheers, Michiel From jeroen at easyhosting.nl Thu Jul 9 09:34:53 2009 From: jeroen at easyhosting.nl (Jeroen Wunnink) Date: Thu, 09 Jul 2009 16:34:53 +0200 Subject: Drop in IPv6 traffic In-Reply-To: References: <54a6fa920907090324p13f1957bx744057316349a3c1@mail.gmail.com> <53C686C3-5751-4D33-9817-9CF22ADDBCAA@marcoh.net> <4A55F05E.4070000@easyhosting.nl> <4A55F665.80003@easyhosting.nl> <4f965b32e937218e58e30be0c7fbf113.squirrel@www.atrato.nl> Message-ID: <4A56000D.7040002@easyhosting.nl> If I look at a tcpdump of our teredo relay which is announced to all our AMS-IX peers (and some partial and full transits), there's a lot of nntp and quite some torrent packets going over there, so it seems the majority of IPv6 traffic is due to content providers like XSnews providing 'freebies' to what otherwise would be a paid service. We've seen the same with our Eweka/Highwinds partial transit, once we announce 2001::/32 there, there's suddenly a big increase in traffic over our teredo from other exchange points prefixes we get from them, heading to free IPv6 news services some dutch providers hand out. Also, coincedence ?: http://www.sixxs.net/misc/traffic/ Patrick W. Gilmore wrote: > On Jul 9, 2009, at 9:58 AM, michiel.muhlenbaumer at atratoip.net wrote: > >> Hi Jeroen & others, >> >> Yep, looks like we are doing a great portion of AMSIX's IPv6 traffic and >> our (free) IPv6 service was affected because of an internal error last >> night around 00.30 am. > > Michiel, > > Thank you for the information. Could you let us know if XS4All's free > v6 news feed went to zero, or was just dropped by some percentage? > > I ask because the AMS-IX is frequently used as an example that v6 is > being heavily adopted. If it is all one source for one application, > that is important information to the people fighting for v6 adoption. > Going from peaks of 1.4 Gbps to 0.4 Gbps is impressive. If that 0.4 > Gbps still includes some of your traffic, it is very impressive. > -- Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer at easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl From jcdill.lists at gmail.com Thu Jul 9 09:39:14 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 09 Jul 2009 07:39:14 -0700 Subject: OT: Bringing Cisco equipment to US In-Reply-To: <4A55F133.10604@gdt.id.au> References: <9C25883F-4BCF-44BA-914E-8F41EA4394FB@hopcount.ca> <4A55F133.10604@gdt.id.au> Message-ID: <4A560112.20008@gmail.com> Glen Turner wrote: > > I wouldn't recommend importing the switches through your luggage. > The few times I've tried that arranging all of the documentation > prior to travel has really sucked. YMMV - I had no problems arranging the documentation. > As a trivial example of what can > go wrong, if you unknowingly choose an airport where customs works > 9am-5pm and your flight arrives at 2am, then you've got a rather > long wait in the walkway between Immigration and Customs. So long > a wait that you're likely to encounter some other difficulty from > the airport authorities. FUD. I have never encountered an International Airport where Immigration & Customs Enforcement was closed during the hours that International flights arrived. Everyone who arrives on an International flight (there may be some exceptions for flights to/from Canada and Mexico because of NAFTA) MUST go thru ICE after they get off the flight. The whole flight would be held up if ICE were not open. The main thing that "can go wrong" is you don't have the right paperwork for your switches and have to pay more customs duty than you would if you had the proper paperwork. Otherwise it's no different than carrying more than 1 laptop, or expensive camera gear, or jewelry, or any other expensive item with you thru an International airport when you travel. jc From jeroen at unfix.org Thu Jul 9 09:40:32 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 09 Jul 2009 16:40:32 +0200 Subject: Drop in IPv6 traffic In-Reply-To: References: <54a6fa920907090324p13f1957bx744057316349a3c1@mail.gmail.com> <53C686C3-5751-4D33-9817-9CF22ADDBCAA@marcoh.net> <4A55F05E.4070000@easyhosting.nl> <4A55F665.80003@easyhosting.nl> <4f965b32e937218e58e30be0c7fbf113.squirrel@www.atrato.nl> Message-ID: <4A560160.1050704@spaghetti.zurich.ibm.com> Patrick W. Gilmore wrote: [..] > I ask because the AMS-IX is frequently used as an example that v6 is > being heavily adopted. If it is all one source for one application, > that is important information to the people fighting for v6 adoption. > Going from peaks of 1.4 Gbps to 0.4 Gbps is impressive. If that 0.4 > Gbps still includes some of your traffic, it is very impressive. I thought it was well known that 99% of the Internet was for warez & p0rn.... In the case of IPv6 (and mostly the reason why "normal people" sign up for Tunnel brokers), the most traffic is NNTP because of "free news servers" (google for it, you'll find loads of tutorials) oh and BitTorrent is also a nice hefty piece. I also though that this was already 'revealed' in several presentations where people actually looked at was going through their boxes. Fortunately there are also people who realize that IPv6 can be used for connecting to all the boxes at home. /me always wonders about: http://arstechnica.com/tech-policy/news/2009/07/judge-throws-book-at-usenetcom-in-riaa-lawsuit.ars when he sees ISPs selling basically a fast link to a NNTP server thoug Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From mikael at gogo6.com Thu Jul 9 09:46:34 2009 From: mikael at gogo6.com (Mikael Lind) Date: Thu, 9 Jul 2009 16:46:34 +0200 Subject: Drop in IPv6 traffic In-Reply-To: <4A56000D.7040002@easyhosting.nl> References: <54a6fa920907090324p13f1957bx744057316349a3c1@mail.gmail.com> <53C686C3-5751-4D33-9817-9CF22ADDBCAA@marcoh.net> <4A55F05E.4070000@easyhosting.nl> <4A55F665.80003@easyhosting.nl> <4f965b32e937218e58e30be0c7fbf113.squirrel@www.atrato.nl> <4A56000D.7040002@easyhosting.nl> Message-ID: <54a6fa920907090746o10d63e9avd06991700a0a6735@mail.gmail.com> Freenet6 went from about 200Mb/s to less than 10Mb/s when we lost both XSnews and XS4all. I thought it would be more torrent traffic but I guess we now know what it actually is. Cheers, Mikael On Thu, Jul 9, 2009 at 4:34 PM, Jeroen Wunnink wrote: > If I look at a tcpdump of our teredo relay which is announced to all our > AMS-IX peers (and some partial and full transits), there's a lot of nntp and > quite some torrent packets going over there, so it seems the majority of > IPv6 traffic is due to content providers like XSnews providing 'freebies' to > what otherwise would be a paid service. > > We've seen the same with our Eweka/Highwinds partial transit, once we > announce 2001::/32 there, there's suddenly a big increase in traffic over > our teredo from other exchange points prefixes we get from them, heading to > free IPv6 news services some dutch providers hand out. > > Also, coincedence ?: http://www.sixxs.net/misc/traffic/ > > From patrick at ianai.net Thu Jul 9 09:58:21 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 9 Jul 2009 10:58:21 -0400 Subject: Drop in IPv6 traffic In-Reply-To: <4A560160.1050704@spaghetti.zurich.ibm.com> References: <54a6fa920907090324p13f1957bx744057316349a3c1@mail.gmail.com> <53C686C3-5751-4D33-9817-9CF22ADDBCAA@marcoh.net> <4A55F05E.4070000@easyhosting.nl> <4A55F665.80003@easyhosting.nl> <4f965b32e937218e58e30be0c7fbf113.squirrel@www.atrato.nl> <4A560160.1050704@spaghetti.zurich.ibm.com> Message-ID: On Jul 9, 2009, at 10:40 AM, Jeroen Massar wrote: > Patrick W. Gilmore wrote: > [..] >> I ask because the AMS-IX is frequently used as an example that v6 is >> being heavily adopted. If it is all one source for one application, >> that is important information to the people fighting for v6 adoption. >> Going from peaks of 1.4 Gbps to 0.4 Gbps is impressive. If that 0.4 >> Gbps still includes some of your traffic, it is very impressive. > > I thought it was well known that 99% of the Internet was for warez & > p0rn.... As with many things, what is "well known" is factually incorrect. :) YouTube, every Akamai customer, Yahoo!, other Google properties, etc., make up more than 1%, and none of those are pr0n or war3z. > In the case of IPv6 (and mostly the reason why "normal people" sign up > for Tunnel brokers), the most traffic is NNTP because of "free news > servers" (google for it, you'll find loads of tutorials) oh and > BitTorrent is also a nice hefty piece. > > I also though that this was already 'revealed' in several > presentations > where people actually looked at was going through their boxes. I ask here because I have seen presentations at NANOG showing that v6 is growing and citing these graphs as evidence. When asking / commenting that most of that traffic is NNTP, I was told that was not confirmed. Guess I got my confirmation. :) -- TTFN, patrick > Fortunately there are also people who realize that IPv6 can be used > for > connecting to all the boxes at home. > > /me always wonders about: > http://arstechnica.com/tech-policy/news/2009/07/judge-throws-book-at-usenetcom-in-riaa-lawsuit.ars > when he sees ISPs selling basically a fast link to a NNTP server thoug > > Greets, > Jeroen > > > From tme at americafree.tv Thu Jul 9 13:22:22 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 9 Jul 2009 14:22:22 -0400 Subject: Traffic Statistics for Yesterday In-Reply-To: <8F7A5C26-159B-4A2A-8468-C418B7D61699@arbor.net> References: <4A54B65D.4010700@unwiredbb.com> <8F7A5C26-159B-4A2A-8468-C418B7D61699@arbor.net> Message-ID: On Jul 9, 2009, at 8:10 AM, Craig Labovitz wrote: > > It was big (flash traffic roughly doubled globally at the peak), but > not in the same ballpark as Obama inauguration. > > A graph of July 7 flash traffic across 97 tier1/2 ISPs compared with > the daily average: > http://farm3.static.flickr.com/2581/3704208402_34ca00597d.jpg?v=0 > Dear Craig; Are you planning to write this up along the lines of your Iranian election work ? http://asert.arbornetworks.com/2009/06/iranian-traffic-engineering/ Regards Marshall > - Craig > > > > On Jul 8, 2009, at 11:08 AM, Shon Elliott wrote: >> Does anyone have any data on how the memorial event for Michael >> Jackson effected >> the global backbones? This was seen as another inaugural type of >> traffic day to >> most of the people I've talked to. > > > email : tme at americafree.tv twitter : @TMEubanks Cut the Cord with AmericaFree.TV From pauldotwall at gmail.com Thu Jul 9 13:49:41 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Thu, 9 Jul 2009 14:49:41 -0400 Subject: Bandcon In-Reply-To: <842AF4EC-5A19-472A-ABB9-B7DC1A616F65@ifbyphone.com> References: <842AF4EC-5A19-472A-ABB9-B7DC1A616F65@ifbyphone.com> Message-ID: <620fd17c0907091149t8a7a867pf245cad639c042d4@mail.gmail.com> On Wed, Jul 8, 2009 at 11:52 AM, Robin Rodriguez wrote: > I don't have any usage experience, but would be very interested from anyone > who does as well. We have spoken with them about long-haul circuits (with > small to no commit) and their prices are indeed incredible. The prices we > heard were for Equinix to Equinix circuits (specifically CHI1 & CHI3 to DAL1 > & NJ2) they also quoted us great deals on resold IBX-link to get to IBX's > that they don't have a physical presence in (they aren't in CHI3 for > example). I do wonder how they can undercut everyone's price by such a > margin. Were you seeing great quotes into non Equinix facilities? Simple, they're oversubscribing their transport circuits and letting users fight for bandwidth. Basically what they're doing is buying a 10GE unprotected wavelength from a carrier, dropping a switch on the ends, and loading up multiple customer VLANs onto the circuit. There are no bandwidth controls, no reservations, no traffic engineering, nothing to keep and the circuit uncongested, and these are unprotected waves so they go down on a regular basis whenever their carrier does a maintenance. How they implement multi-point service is even scarier, they just slap all your locations into one big VLAN and let unknown unicast flooding and MAC learning sort it out. Most serious customers run screaming, I'm sure you can find some former customers who can describe the horror in more detail off-list. When things break, their support is nothing to write home about. ?They often brag that they have a former Level3 engineer on payroll, unfortunately he's nowhere to be found, and their suport people aren't terribly sharp on those rare occasoions when they *do* answer the phone or respond to e-mail. ?Like someone else pointed out, multi-day outages aren't at all uncommon, so if you end up going with Bandcon, make sure you have sufficient redundancy in place. Since they can't really compete on quality, they compete instead on price. ?Their sales force spams and cold-calls every website, ARIN, peeringdb, etc on a regular basis, and can't take "no" for an answer. The following exchange sums it up nicely (warning: foul language): http://attrition.org/postal/z/034/0931.html They are currently running a $2.50/mg transit promotion, which makes me wonder how they're doing on their Level3 and Global Crossing bandwidth commits and whether or not they're solvent. Drive Slow, Paul Wall From zartash at gmail.com Thu Jul 9 15:33:10 2009 From: zartash at gmail.com (Zartash Uzmi) Date: Fri, 10 Jul 2009 01:33:10 +0500 Subject: Point to Point Ethernet In-Reply-To: <71c13900907090729q5a6cc243s27aafd06d67ce288@mail.gmail.com> References: <4A546E70.9090604@nrg4u.com> <2e9d8ae50907081604uabbba04wb285a40c7c66f102@mail.gmail.com> <20090709.083412.74715921.sthaug@nethelp.no> <70D072392E56884193E3D2DE09C097A91F427B@pascal.zaphodb.org> <71c13900907090729q5a6cc243s27aafd06d67ce288@mail.gmail.com> Message-ID: <4fff97de0907091333h6cb58f5drada2a0265f51e9b6@mail.gmail.com> Cayle, This may be partial hijack of the thread or even a trivial query but I ask this since you mentioned "For cost reasons, Ethernet is often used". We hear this argument all the time. The standard unabridged reason I have learned is the ubiquity of Ethernet devices, whatever that means. Can you say why precisely the cost of Ethernet is low compared to other viable alternatives? Zartash On Thu, Jul 9, 2009 at 7:29 PM, Cayle Spandon wrote: > I frequently run into scenarios where two devices (two routers, or a > router and a host) need a point-to-point connection to each other with > a capacity of (much) more than 10 Gbps. > > For cost reasons, Ethernet is often used. > > Since more than 10 Gbps is needed, we end up with multiple parallel > 10GE point-to-point connections. > > Because the devices often don't support LAG or have limitations on the > number of links in a LAG, we often cannot use LAG at all or cannot put > all 10GE links in a single LAG group. > > So, we end up with multiple parallel layer-3 point-to-point > connections where each connections is either an Ethernet or a LAG > group. > > Furthermore, in order to conserve IP addresses, there is a desire to > make these interfaces unnumbered. > > The involved devices have a numbered loopback interface whose address > is used as the "donor" for the unnumbered Ethernet / LAG interfaces. > Most router vendors already support unnumbered point-to-point > Ethernet, see for example: > > > http://www.juniper.net/techpubs/en_US/junos9.5/information-products/topic-collections/config-guide-network-interfaces/interfaces-configuring-an-unnumbered-interface.html#id-10432956 > > However, there are some interoperability issues / open questions > related to point-to-point unnumbered Ethernet, see for example: > > http://forums.juniper.net/jnet/board/message?board.id=JUNOS&message.id=130 > > http://forums.juniper.net/jnet/board/message?board.id=switch&thread.id=835 > > I would be very interested in some standards (i.e. an IETF BCP) to > describe the best current practices for these applications of > Ethernet. > > I am not particularly interested in re-inventing a new flavor of > Ethernet for this application. All that is needed, in my opinion, is > some clarifications or best practices on how to use the existing > standards to create point-to-point unnumbered Ethernet connections. > > PS -- I am also aware of some esoteric BRAS applications of Ethernet > where one side is numbered and the other side is unnumbered. > > From tbraning at gmail.com Thu Jul 9 15:43:05 2009 From: tbraning at gmail.com (tb) Date: Thu, 9 Jul 2009 13:43:05 -0700 Subject: Bandcon Message-ID: <42d378020907091343h60a4d031hbcb52ab83041720b@mail.gmail.com> Hi All, My name is Todd Braning, I work on the technical side of the BandCon house. I am afraid Paul's email is inaccurate. Here are a few facts: BandCon offers transport services that can be configured as unprotected or protected. If you buy an unprotected circuit, and the underlying transport has issues, your VC will have issues. However that is not the case if you purchase a protected service. BandCon does not "just slap all your locations into one big VLAN and let unknown unicast flooding and MAC learning sort it out". All circuits are provisioned as separate point to point MPLS VCs. We do, in fact, utilize traffic engineering and do not oversubscribe our wavelengths. Regarding our NOC. It is true that in the past, our NOC was sub par. This is no longer the case. About a year ago we replaced all NOC technicians, brought in an experienced NOC manager and have made significant progress. Paul - I cannot find you in our customer database so I am not sure what services you bought from BandCon. However, I would be happy to speak with you, or anyone else interested, regarding the technical merits of our transport services. If anyone is interested, please contact me. Thanks, Todd Braning From swmike at swm.pp.se Thu Jul 9 16:09:40 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 9 Jul 2009 23:09:40 +0200 (CEST) Subject: Point to Point Ethernet In-Reply-To: <4fff97de0907091333h6cb58f5drada2a0265f51e9b6@mail.gmail.com> References: <4A546E70.9090604@nrg4u.com> <2e9d8ae50907081604uabbba04wb285a40c7c66f102@mail.gmail.com> <20090709.083412.74715921.sthaug@nethelp.no> <70D072392E56884193E3D2DE09C097A91F427B@pascal.zaphodb.org> <71c13900907090729q5a6cc243s27aafd06d67ce288@mail.gmail.com> <4fff97de0907091333h6cb58f5drada2a0265f51e9b6@mail.gmail.com> Message-ID: On Fri, 10 Jul 2009, Zartash Uzmi wrote: > Can you say why precisely the cost of Ethernet is low compared to other > viable alternatives? The components going into ethernet devices are cheaper because of high volume, but it's also that the SONET/SDH stuff is grossly overpriced "because we can" by short sighted vendors. There are cheap ethernet ports for cheap platforms, there are basically no cheap SONET/SDH ports anywhere. POS is technically better compared to Ethernet for carrier links imho, but for instance Cisco price their SPA-TENGE-XFP at 1/6 the cost of SPA-OC192-XFP. I know quite a lot of people who would gladly pay more for POS, but not that much more. -- Mikael Abrahamsson email: swmike at swm.pp.se From jfbeam at gmail.com Thu Jul 9 16:29:03 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 09 Jul 2009 17:29:03 -0400 Subject: Point to Point Ethernet In-Reply-To: <4fff97de0907091333h6cb58f5drada2a0265f51e9b6@mail.gmail.com> References: <4A546E70.9090604@nrg4u.com> <2e9d8ae50907081604uabbba04wb285a40c7c66f102@mail.gmail.com> <20090709.083412.74715921.sthaug@nethelp.no> <70D072392E56884193E3D2DE09C097A91F427B@pascal.zaphodb.org> <71c13900907090729q5a6cc243s27aafd06d67ce288@mail.gmail.com> <4fff97de0907091333h6cb58f5drada2a0265f51e9b6@mail.gmail.com> Message-ID: On Thu, 09 Jul 2009 16:33:10 -0400, Zartash Uzmi wrote: > ... Can you say why > precisely the cost of Ethernet is low compared to other viable > alternatives? Volume. Economies of scale. Etc. Ethernet is cheap because it's everywhere, and built into almost everything. (however, the likes of Cisco and Juniper still charge insane amounts for line cards, be they ethernet, T1, or OC48.) Given the choice of buying a $4k DS3 card or just plugging into an existing, builtin ethernet port, which do you think most people will choose? And it doesn't take a multi-thousand dollar Router(tm) to deal with ethernet -- a 200$ "trash" PC can handle routing (and NAT) for a great deal of traffic. (in many cases, *better* than the high priced kit.) Case in point, our voice/data line from TW enters the building as fiber (along with about 4000 other circuits), crawls up the inside of the building as HDSL (single pair) to a box in my "closet" where 8 POTS line and an ethernet are handed to me. The ethernet runs to a switch and then to the firewall. If it wasn't handed to me as ethernet, I'd need a router to turn it into ethernet. (On the other wall... $8k worth of gear to turn a DS3 into ethernet. Yes, the Optera Metro shelf at the other end of that DS3 could just as easily be an ethernet port -- but that would require TW and VZB to play nice with each other; it was enough of a pain to get the DS3 to work. But that's miles off topic.) --Ricky From charles at thewybles.com Thu Jul 9 16:35:14 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 09 Jul 2009 14:35:14 -0700 Subject: Request for contact and procedure information Message-ID: <4A566292.6030300@thewybles.com> All, I'm currently experiencing a DDOS attack on my home DSL connection. Thousands of requests to port 80. I'm on an SBC business class account. I'm guessing that calling the regular customer support won't get me anywhere. Any suggestions? From joelja at bogus.com Thu Jul 9 16:45:28 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 09 Jul 2009 14:45:28 -0700 Subject: Point to Point Ethernet In-Reply-To: <4fff97de0907091333h6cb58f5drada2a0265f51e9b6@mail.gmail.com> References: <4A546E70.9090604@nrg4u.com> <2e9d8ae50907081604uabbba04wb285a40c7c66f102@mail.gmail.com> <20090709.083412.74715921.sthaug@nethelp.no> <70D072392E56884193E3D2DE09C097A91F427B@pascal.zaphodb.org> <71c13900907090729q5a6cc243s27aafd06d67ce288@mail.gmail.com> <4fff97de0907091333h6cb58f5drada2a0265f51e9b6@mail.gmail.com> Message-ID: <4A5664F8.2080103@bogus.com> Zartash Uzmi wrote: > Can you say why precisely the cost of Ethernet is low compared to other viable alternatives? Becuase there's a lot of it? Gigabit ethernet ports cost less than 9600bps terminal server ports. From jeffrey.lyon at blacklotus.net Thu Jul 9 17:23:51 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 9 Jul 2009 18:23:51 -0400 Subject: Request for contact and procedure information In-Reply-To: <4A566292.6030300@thewybles.com> References: <4A566292.6030300@thewybles.com> Message-ID: <16720fe00907091523n47d909cfudbef1b7f371fe37f@mail.gmail.com> Charles, You're going to need an enterprise grade DDoS protection provider and should expect to spend anywhere from hundreds to thousands per month for this service. This is not a service the majority of transit providers are capable of offering. Best regards, Jeff On Thu, Jul 9, 2009 at 5:35 PM, Charles Wyble wrote: > All, > > I'm currently experiencing a DDOS attack on my home DSL connection. > > Thousands of requests to port 80. > > I'm on an SBC business class account. > > I'm guessing that calling the regular customer support won't get me > anywhere. > > Any suggestions? > > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From ktokash at hotmail.com Thu Jul 9 18:28:06 2009 From: ktokash at hotmail.com (keith tokash) Date: Thu, 9 Jul 2009 23:28:06 +0000 Subject: Bandcon In-Reply-To: References: <842AF4EC-5A19-472A-ABB9-B7DC1A616F65@ifbyphone.com> <620fd17c0907091149t8a7a867pf245cad639c042d4@mail.gmail.com> Message-ID: We've run our circuits pretty hot and not noticed anything that would indicate a lack of shaping/policing. And while the flame war with the attrition guys was pretty funny (I'm a sucker for classics) I wouldn't really use that as any type of barometer of ... well anything really. This email may be accurate, but I'll pretend I'm an engineer for a moment and ask for something to back up allegations before I believe them. Even with the internet's stellar reputation for accuracy via intuition. --- Keith Tokash, CCIE #21236 Network blah blah blah, Myspace.com -----Original Message----- From: Paul Wall [mailto:pauldotwall at gmail.com] Sent: Thursday, July 09, 2009 11:50 AM To: Robin Rodriguez Cc: nanog at nanog.org Subject: Re: Bandcon On Wed, Jul 8, 2009 at 11:52 AM, Robin Rodriguez wrote: > I don't have any usage experience, but would be very interested from anyone > who does as well. We have spoken with them about long-haul circuits (with > small to no commit) and their prices are indeed incredible. The prices we > heard were for Equinix to Equinix circuits (specifically CHI1 & CHI3 to DAL1 > & NJ2) they also quoted us great deals on resold IBX-link to get to IBX's > that they don't have a physical presence in (they aren't in CHI3 for > example). I do wonder how they can undercut everyone's price by such a > margin. Were you seeing great quotes into non Equinix facilities? Simple, they're oversubscribing their transport circuits and letting users fight for bandwidth. Basically what they're doing is buying a 10GE unprotected wavelength from a carrier, dropping a switch on the ends, and loading up multiple customer VLANs onto the circuit. There are no bandwidth controls, no reservations, no traffic engineering, nothing to keep and the circuit uncongested, and these are unprotected waves so they go down on a regular basis whenever their carrier does a maintenance. How they implement multi-point service is even scarier, they just slap all your locations into one big VLAN and let unknown unicast flooding and MAC learning sort it out. Most serious customers run screaming, I'm sure you can find some former customers who can describe the horror in more detail off-list. When things break, their support is nothing to write home about. They often brag that they have a former Level3 engineer on payroll, unfortunately he's nowhere to be found, and their suport people aren't terribly sharp on those rare occasoions when they *do* answer the phone or respond to e-mail. Like someone else pointed out, multi-day outages aren't at all uncommon, so if you end up going with Bandcon, make sure you have sufficient redundancy in place. Since they can't really compete on quality, they compete instead on price. Their sales force spams and cold-calls every website, ARIN, peeringdb, etc on a regular basis, and can't take "no" for an answer. The following exchange sums it up nicely (warning: foul language): http://attrition.org/postal/z/034/0931.html They are currently running a $2.50/mg transit promotion, which makes me wonder how they're doing on their Level3 and Global Crossing bandwidth commits and whether or not they're solvent. Drive Slow, Paul Wall _________________________________________________________________ Windows Live? SkyDrive?: Get 25 GB of free online storage. http://windowslive.com/online/skydrive?ocid=TXT_TAGLM_WL_SD_25GB_062009 From mprice at tqhosting.com Thu Jul 9 20:25:48 2009 From: mprice at tqhosting.com (Mark Price) Date: Thu, 9 Jul 2009 21:25:48 -0400 Subject: Request for contact and procedure information In-Reply-To: <4A566292.6030300@thewybles.com> References: <4A566292.6030300@thewybles.com> Message-ID: <61b6fbec0907091825n4c5f649dha7484dae692e5865@mail.gmail.com> Turn off your DSL modem for awhile, and hope for a new dynamic IP? Mark On Thu, Jul 9, 2009 at 5:35 PM, Charles Wyble wrote: > All, > > I'm currently experiencing a DDOS attack on my home DSL connection. > > Thousands of requests to port 80. > > I'm on an SBC business class account. > > I'm guessing that calling the regular customer support won't get me > anywhere. > > Any suggestions? > > > > From john-nanog at johnpeach.com Thu Jul 9 20:35:28 2009 From: john-nanog at johnpeach.com (John Peach) Date: Thu, 09 Jul 2009 21:35:28 -0400 Subject: Request for contact and procedure information In-Reply-To: <61b6fbec0907091825n4c5f649dha7484dae692e5865@mail.gmail.com> References: <4A566292.6030300@thewybles.com> <61b6fbec0907091825n4c5f649dha7484dae692e5865@mail.gmail.com> Message-ID: <20090709213528.772dc622@maggie.peachfamily.net> Turn off whatever you have listening on port 80. On Thu, 9 Jul 2009 21:25:48 -0400 Mark Price wrote: > Turn off your DSL modem for awhile, and hope for a new dynamic IP? > > > Mark > > > > On Thu, Jul 9, 2009 at 5:35 PM, Charles Wyble > wrote: > > All, > > > > I'm currently experiencing a DDOS attack on my home DSL connection. > > > > Thousands of requests to port 80. > > > > I'm on an SBC business class account. > > > > I'm guessing that calling the regular customer support won't get me > > anywhere. > > > > Any suggestions? > > > > > > > > > From charles at thewybles.com Thu Jul 9 21:20:59 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 09 Jul 2009 19:20:59 -0700 Subject: Request for contact and procedure information In-Reply-To: <61b6fbec0907091825n4c5f649dha7484dae692e5865@mail.gmail.com> References: <4A566292.6030300@thewybles.com> <61b6fbec0907091825n4c5f649dha7484dae692e5865@mail.gmail.com> Message-ID: <4A56A58B.5050103@thewybles.com> I have a static range. :( Mark Price wrote: > Turn off your DSL modem for awhile, and hope for a new dynamic IP? > > > Mark > From charles at thewybles.com Thu Jul 9 21:21:19 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 09 Jul 2009 19:21:19 -0700 Subject: Request for contact and procedure information In-Reply-To: <20090709213528.772dc622@maggie.peachfamily.net> References: <4A566292.6030300@thewybles.com> <61b6fbec0907091825n4c5f649dha7484dae692e5865@mail.gmail.com> <20090709213528.772dc622@maggie.peachfamily.net> Message-ID: <4A56A59F.7090705@thewybles.com> I did. Still getting pounded. John Peach wrote: > Turn off whatever you have listening on port 80. > > On Thu, 9 Jul 2009 21:25:48 -0400 > Mark Price wrote: > >> Turn off your DSL modem for awhile, and hope for a new dynamic IP? >> >> >> Mark >> >> >> >> On Thu, Jul 9, 2009 at 5:35 PM, Charles Wyble >> wrote: >>> All, >>> >>> I'm currently experiencing a DDOS attack on my home DSL connection. >>> >>> Thousands of requests to port 80. >>> >>> I'm on an SBC business class account. >>> >>> I'm guessing that calling the regular customer support won't get me >>> anywhere. >>> >>> Any suggestions? >>> >>> >>> >>> > > From adrian at creative.net.au Thu Jul 9 21:35:39 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Fri, 10 Jul 2009 10:35:39 +0800 Subject: Request for contact and procedure information In-Reply-To: <4A56A59F.7090705@thewybles.com> References: <4A566292.6030300@thewybles.com> <61b6fbec0907091825n4c5f649dha7484dae692e5865@mail.gmail.com> <20090709213528.772dc622@maggie.peachfamily.net> <4A56A59F.7090705@thewybles.com> Message-ID: <20090710023539.GA31882@skywalker.creative.net.au> On Thu, Jul 09, 2009, Charles Wyble wrote: > I did. Still getting pounded. And its not covered by your SLA? Adrian From dwhite at olp.net Thu Jul 9 21:42:07 2009 From: dwhite at olp.net (Dan White) Date: Thu, 09 Jul 2009 21:42:07 -0500 Subject: Request for contact and procedure information In-Reply-To: <4A56A59F.7090705@thewybles.com> References: <4A566292.6030300@thewybles.com> <61b6fbec0907091825n4c5f649dha7484dae692e5865@mail.gmail.com> <20090709213528.772dc622@maggie.peachfamily.net> <4A56A59F.7090705@thewybles.com> Message-ID: <4A56AA7F.4030107@olp.net> Have you spoken with your provider? They should be giving you options, like changing your static address, or null routing the attackers upstream, or perhaps blocking port 80 to you, to limit your ingress traffic. - Dan Charles Wyble wrote: > I did. Still getting pounded. > > John Peach wrote: >> Turn off whatever you have listening on port 80. >> From william.mccall at gmail.com Thu Jul 9 21:44:43 2009 From: william.mccall at gmail.com (William McCall) Date: Thu, 9 Jul 2009 21:44:43 -0500 Subject: Request for contact and procedure information In-Reply-To: <4A56AA7F.4030107@olp.net> References: <4A566292.6030300@thewybles.com> <61b6fbec0907091825n4c5f649dha7484dae692e5865@mail.gmail.com> <20090709213528.772dc622@maggie.peachfamily.net> <4A56A59F.7090705@thewybles.com> <4A56AA7F.4030107@olp.net> Message-ID: Dude, he's on SBC man. They're not going to do anything but tell him to restart the modem. On Thu, Jul 9, 2009 at 9:42 PM, Dan White wrote: > Have you spoken with your provider? They should be giving you options, like > changing your static address, or null routing the attackers upstream, or > perhaps blocking port 80 to you, to limit your ingress traffic. > > - Dan > > Charles Wyble wrote: >> >> I did. Still getting pounded. >> >> John Peach wrote: >>> >>> Turn off whatever you have listening on port 80. >>> > > > From alan at routingloop.com Thu Jul 9 22:21:12 2009 From: alan at routingloop.com (Alan Hannan) Date: Thu, 9 Jul 2009 20:21:12 -0700 Subject: Bandcon In-Reply-To: <42d378020907091343h60a4d031hbcb52ab83041720b@mail.gmail.com> References: <42d378020907091343h60a4d031hbcb52ab83041720b@mail.gmail.com> Message-ID: <8341826f0907092021u52f69ab0j581cbb8710439e33@mail.gmail.com> In a former life, I used Bandcon for point to point transport between POPs. We did not use them for IP Transit. I found Bandcon to be professional, responsive, and their technical design and delivery quality very high. Problems were extremely rare, and when they occurred they were dealt with promptly. I won't get involved in a point by point debate, as Todd seems to have set the record reasonably straight and I trust happy customers will step up to the plate, but I found them to be a positive vendor that stuck to their contracts and delivered what they said they would deliver. -alan On Thu, Jul 9, 2009 at 1:43 PM, tb wrote: > Hi All, > > My name is Todd Braning, I work on the technical side of the BandCon > house. I am afraid Paul's email is inaccurate. > > Here are a few facts: > > BandCon offers transport services that can be configured as > unprotected or protected. If you buy an unprotected circuit, and the > underlying transport has issues, your VC will have issues. However > that is not the case if you purchase a protected service. > > BandCon does not "just slap all your locations into one big VLAN and > let unknown unicast flooding and MAC learning sort it out". All > circuits are provisioned as separate point to point MPLS VCs. We do, > in fact, utilize traffic engineering and do not oversubscribe our > wavelengths. > > Regarding our NOC. It is true that in the past, our NOC was sub par. > This is no longer the case. About a year ago we replaced all NOC > technicians, brought in an experienced NOC manager and have made > significant progress. > > Paul - I cannot find you in our customer database so I am not sure > what services you bought from BandCon. However, I would be happy to > speak with you, or anyone else interested, regarding the technical > merits of our transport services. If anyone is interested, please > contact me. > > > Thanks, > > Todd Braning > > From sethm at rollernet.us Thu Jul 9 22:36:21 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 09 Jul 2009 20:36:21 -0700 Subject: Request for contact and procedure information In-Reply-To: <4A56AA7F.4030107@olp.net> References: <4A566292.6030300@thewybles.com> <61b6fbec0907091825n4c5f649dha7484dae692e5865@mail.gmail.com> <20090709213528.772dc622@maggie.peachfamily.net> <4A56A59F.7090705@thewybles.com> <4A56AA7F.4030107@olp.net> Message-ID: <4A56B735.1040805@rollernet.us> Dan White wrote: > Have you spoken with your provider? They should be giving you options, > like changing your static address, or null routing the attackers > upstream, or perhaps blocking port 80 to you, to limit your ingress > traffic. > For DSL? I've never had that kind of luck with SBC's (now AT&T) home products, and I've been using their DSL since 2001. This is one instance where paying the big bucks for at least a T1 can show some some return. Even if it's "business DSL" it's still treated the same as "drooling user DSL". Purely my personal experience. ~Seth From jcdill.lists at gmail.com Thu Jul 9 22:48:58 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 09 Jul 2009 20:48:58 -0700 Subject: Request for contact and procedure information In-Reply-To: <4A566292.6030300@thewybles.com> References: <4A566292.6030300@thewybles.com> Message-ID: <4A56BA2A.30807@gmail.com> Good, Fast, Cheap, pick any two. Consumer grade AT&T DSL is fast and cheap, and now you realize why Good is not included when you go with Fast and Cheap. jc Charles Wyble wrote: > All, > > I'm currently experiencing a DDOS attack on my home DSL connection. > > Thousands of requests to port 80. > > I'm on an SBC business class account. > > I'm guessing that calling the regular customer support won't get me > anywhere. > > Any suggestions? > > > > From Jon.Kibler at aset.com Thu Jul 9 22:52:11 2009 From: Jon.Kibler at aset.com (Jon Kibler) Date: Thu, 09 Jul 2009 23:52:11 -0400 Subject: Request for contact and procedure information In-Reply-To: <4A566292.6030300@thewybles.com> References: <4A566292.6030300@thewybles.com> Message-ID: <4A56BAEB.2030801@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Charles Wyble wrote: > All, > > I'm currently experiencing a DDOS attack on my home DSL connection. > > Thousands of requests to port 80. > > I'm on an SBC business class account. > > I'm guessing that calling the regular customer support won't get me > anywhere. > > Any suggestions? Okay, this is going to sound REALLY lame, but IMHO it may be your best bet to get action from SBC: 1) File a police report with your local law enforcement agency and (CRITICAL) get a case number. (You should have well documented when the attack started, too. If asked why you waited so long to report it, explain that you were not familiar with procedures. You may also be asked what you have that someone wants to attack. "I don't know" is an acceptable answer, if that is the truth.) When local law enforcement completes taking the report, request that your local law enforcement escalate the case to the local/regional FBI office (specifically mention InfraGuard). 2) Call your local FBI office and ask to speak to the InfraGuard coordinator. (If it is a small office, they may refer you to your regional office.) Tell them you are being DDOSed, that you have filed a report with local law enforcement (give them agency and case number), tell them who is your ISP and contact information, and tell them ISP has been uncooperative at resolution. Ask them can they please help -- at a minimum, can they contact the ISP and get them to start null routing DDOS traffic. Just out of curiosity, do you have any traffic capture? If so, what type of attack is it? SYN flood, Apache instance starvation, etc.? You may want to do some packet capture for hand-over to law enforcement. I know this sounds lame, but I also CONSTANTLY hear from InfraGuard that they want to be informed of these types of attacks, and they will help when resources permit. Don't expect miracles. But it is better than nothing. Finally, document, document, document!!! Jon - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-813-2924 (NEW!) s: 843-564-4224 http://www.linkedin.com/in/jonrkibler My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpWuusACgkQUVxQRc85QlNN1gCeJzqVXPfYpeOxcFJxDaTbU1q4 8IoAn1E5QjOZB1usTJO39qp2EIkJpdqW =VM8D -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From Jon.Kibler at aset.com Thu Jul 9 23:02:21 2009 From: Jon.Kibler at aset.com (Jon Kibler) Date: Fri, 10 Jul 2009 00:02:21 -0400 Subject: Request for contact and procedure information In-Reply-To: <4A56BAEB.2030801@aset.com> References: <4A566292.6030300@thewybles.com> <4A56BAEB.2030801@aset.com> Message-ID: <4A56BD4D.6050504@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jon Kibler wrote: > Charles Wyble wrote: >> All, > >> I'm currently experiencing a DDOS attack on my home DSL connection. > >> Thousands of requests to port 80. > >> I'm on an SBC business class account. > >> I'm guessing that calling the regular customer support won't get me >> anywhere. > >> Any suggestions? > > Okay, this is going to sound REALLY lame, but IMHO it may be your best bet to > get action from SBC: > > 1) File a police report with your local law enforcement agency and (CRITICAL) > get a case number. (You should have well documented when the attack started, > too. If asked why you waited so long to report it, explain that you were not > familiar with procedures. You may also be asked what you have that someone wants > to attack. "I don't know" is an acceptable answer, if that is the truth.) When > local law enforcement completes taking the report, request that your local law > enforcement escalate the case to the local/regional FBI office (specifically > mention InfraGuard). > > 2) Call your local FBI office and ask to speak to the InfraGuard coordinator. > (If it is a small office, they may refer you to your regional office.) Tell them > you are being DDOSed, that you have filed a report with local law enforcement > (give them agency and case number), tell them who is your ISP and contact > information, and tell them ISP has been uncooperative at resolution. Ask them > can they please help -- at a minimum, can they contact the ISP and get them to > start null routing DDOS traffic. > > Just out of curiosity, do you have any traffic capture? If so, what type of > attack is it? SYN flood, Apache instance starvation, etc.? > > You may want to do some packet capture for hand-over to law enforcement. > > I know this sounds lame, but I also CONSTANTLY hear from InfraGuard that they > want to be informed of these types of attacks, and they will help when resources > permit. > > Don't expect miracles. But it is better than nothing. > > Finally, document, document, document!!! > > Jon I hate to reply to my own email... but as soon as I hit "SEND", I realized I left off something important... You said you have Business Class DSL. Is this for a business? If so, have your lawyer contact SBC. S/he should request to talk with the department manager for small business services. That, too, may help get action. Be sure to provide him/her with written documentation on everything you can regarding the attack. The more information that s/he has, the better to beat up on SBC with. Finally, what does your TOS/SLA say about DDoS? Most have something to say about ISP liability in the mitigation of such attacks. GOOD LUCK! Jon - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-813-2924 (NEW!) s: 843-564-4224 http://www.linkedin.com/in/jonrkibler My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpWvU0ACgkQUVxQRc85QlO21wCffh5vK5V39ffWJGZPgoA4a9ii RpcAnjdVCx4l693Pw6vYz58xjZt//Cdx =UTXU -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From jeffrey.lyon at blacklotus.net Fri Jul 10 01:11:49 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 10 Jul 2009 02:11:49 -0400 Subject: Request for contact and procedure information In-Reply-To: <4A56BD4D.6050504@aset.com> References: <4A566292.6030300@thewybles.com> <4A56BAEB.2030801@aset.com> <4A56BD4D.6050504@aset.com> Message-ID: <16720fe00907092311n1d28a7cs99e8259c544b90d@mail.gmail.com> All, There are few if any ISP that will help you with something like this. Law enforcement also does not have the resources to even begin to look at a single DSL line being attacked unless you can show 7+ figures in damage or some type of major threat to national infrastructure. Your options are basically as follows: 1) Use csf . If properly tuned this should be sufficient to filter minor attacks. 2) Invest in a decent firewall like a Juniper Netscreen and set session limits. This won't stop an attack but it will limit the amount of traffic you have to filter locally. 3) Ask SBC to null route the IP completely 4) Invest in an actual protection service. Jeff On Fri, Jul 10, 2009 at 12:02 AM, Jon Kibler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jon Kibler wrote: >> Charles Wyble wrote: >>> All, >> >>> I'm currently experiencing a DDOS attack on my home DSL connection. >> >>> Thousands of requests to port 80. >> >>> I'm on an SBC business class account. >> >>> I'm guessing that calling the regular customer support won't get me >>> anywhere. >> >>> Any suggestions? >> >> Okay, this is going to sound REALLY lame, but IMHO it may be your best bet to >> get action from SBC: >> >> ? ?1) File a police report with your local law enforcement agency and (CRITICAL) >> get a case number. (You should have well documented when the attack started, >> too. If asked why you waited so long to report it, explain that you were not >> familiar with procedures. You may also be asked what you have that someone wants >> to attack. "I don't know" is an acceptable answer, if that is the truth.) When >> local law enforcement completes taking the report, request that your local law >> enforcement escalate the case to the local/regional FBI office (specifically >> mention InfraGuard). >> >> ? ?2) Call your local FBI office and ask to speak to the InfraGuard coordinator. >> (If it is a small office, they may refer you to your regional office.) Tell them >> you are being DDOSed, that you have filed a report with local law enforcement >> (give them agency and case number), tell them who is your ISP and contact >> information, and tell them ISP has been uncooperative at resolution. Ask them >> can they please help -- at a minimum, can they contact the ISP and get them to >> start null routing DDOS traffic. >> >> Just out of curiosity, do you have any traffic capture? If so, what type of >> attack is it? SYN flood, Apache instance starvation, etc.? >> >> You may want to do some packet capture for hand-over to law enforcement. >> >> I know this sounds lame, but I also CONSTANTLY hear from InfraGuard that they >> want to be informed of these types of attacks, and they will help when resources >> permit. >> >> Don't expect miracles. But it is better than nothing. >> >> Finally, document, document, document!!! >> >> Jon > > > I hate to reply to my own email... but as soon as I hit "SEND", I realized I > left off something important... > > You said you have Business Class DSL. Is this for a business? If so, have your > lawyer contact SBC. S/he should request to talk with the department manager for > small business services. That, too, may help get action. Be sure to provide > him/her with written documentation on everything you can regarding the attack. > The more information that s/he has, the better to beat up on SBC with. > > Finally, what does your TOS/SLA say about DDoS? Most have something to say about > ISP liability in the mitigation of such attacks. > > GOOD LUCK! > > Jon > - -- > Jon R. Kibler > Chief Technical Officer > Advanced Systems Engineering Technology, Inc. > Charleston, SC ?USA > o: 843-849-8214 > c: 843-813-2924 (NEW!) > s: 843-564-4224 > http://www.linkedin.com/in/jonrkibler > > My PGP Fingerprint is: > BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkpWvU0ACgkQUVxQRc85QlO21wCffh5vK5V39ffWJGZPgoA4a9ii > RpcAnjdVCx4l693Pw6vYz58xjZt//Cdx > =UTXU > -----END PGP SIGNATURE----- > > > > > ================================================== > Filtered by: TRUSTEM.COM's Email Filtering Service > http://www.trustem.com/ > No Spam. No Viruses. Just Good Clean Email. > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From sethm at rollernet.us Fri Jul 10 01:27:55 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 09 Jul 2009 23:27:55 -0700 Subject: Request for contact and procedure information In-Reply-To: <16720fe00907092311n1d28a7cs99e8259c544b90d@mail.gmail.com> References: <4A566292.6030300@thewybles.com> <4A56BAEB.2030801@aset.com> <4A56BD4D.6050504@aset.com> <16720fe00907092311n1d28a7cs99e8259c544b90d@mail.gmail.com> Message-ID: <4A56DF6B.5060306@rollernet.us> Jeffrey Lyon wrote: > All, > > There are few if any ISP that will help you with something like this. > Law enforcement also does not have the resources to even begin to look > at a single DSL line being attacked unless you can show 7+ figures in > damage or some type of major threat to national infrastructure. > > Your options are basically as follows: > > 1) Use csf . If properly tuned this should be sufficient to filter > minor attacks. > 2) Invest in a decent firewall like a Juniper Netscreen and set > session limits. This won't stop an attack but it will limit the amount > of traffic you have to filter locally. > 3) Ask SBC to null route the IP completely > 4) Invest in an actual protection service. > Last time I had to deal with a DDoS coming over a Sprint circuit (multilink T1) they transferred me to someone in security and they started null routing things. Initially they were treating it as trouble because the BGP session kept resetting, but once we all figured out it was a DDoS the resolution was quick and painless. Maybe my experience is abnormal? I don't know. ~Seth From bpasdar at batblue.com Fri Jul 10 07:17:43 2009 From: bpasdar at batblue.com (Babak Pasdar) Date: Fri, 10 Jul 2009 08:17:43 -0400 Subject: ISP BGP Resources Message-ID: <20090710121743.a4a823da@concur.batblue.com> Hello, We are in the process of rolling out communities that our customers can use to manipulate their routes. Are there any resources (books, web sites, mailing lists, etc..) that anyone can recommend? Thank you, Babak From jaitken at aitken.com Fri Jul 10 07:50:52 2009 From: jaitken at aitken.com (Jeff Aitken) Date: Fri, 10 Jul 2009 12:50:52 +0000 Subject: ISP BGP Resources In-Reply-To: <20090710121743.a4a823da@concur.batblue.com> References: <20090710121743.a4a823da@concur.batblue.com> Message-ID: <20090710125052.GA83005@eagle.aitken.com> On Fri, Jul 10, 2009 at 08:17:43AM -0400, Babak Pasdar wrote: > Are there any resources (books, web sites, mailing lists, etc..) that > anyone can recommend? Richard Steenbergen did a nice preso on this subject a couple years ago: http://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf --Jeff From jackson.tim at gmail.com Fri Jul 10 07:56:19 2009 From: jackson.tim at gmail.com (Tim Jackson) Date: Fri, 10 Jul 2009 07:56:19 -0500 Subject: ISP BGP Resources In-Reply-To: <20090710121743.a4a823da@concur.batblue.com> References: <20090710121743.a4a823da@concur.batblue.com> Message-ID: <4407932e0907100556v5b3458ffv3fef1f4ee7242cb@mail.gmail.com> http://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf Great presentation. On 7/10/09, Babak Pasdar wrote: > Hello, > > We are in the process of rolling out communities that our customers can use > to manipulate their routes. Are there any resources (books, web sites, > mailing lists, etc..) that anyone can recommend? > > Thank you, > > Babak > -- Sent from my mobile device From iljitsch at muada.com Fri Jul 10 08:05:27 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 10 Jul 2009 15:05:27 +0200 Subject: ISP BGP Resources In-Reply-To: <20090710121743.a4a823da@concur.batblue.com> References: <20090710121743.a4a823da@concur.batblue.com> Message-ID: <4DBAD1C7-84F5-49A9-930A-5714937888DF@muada.com> On 10 jul 2009, at 14:17, Babak Pasdar wrote: > We are in the process of rolling out communities that our customers > can use to manipulate their routes. Are there any resources (books, > web sites, mailing lists, etc..) that anyone can recommend? Since you ask... My book has a few pages about this: "BGP" from O'Reilly. From dwhite at olp.net Fri Jul 10 08:10:12 2009 From: dwhite at olp.net (Dan White) Date: Fri, 10 Jul 2009 08:10:12 -0500 Subject: Request for contact and procedure information In-Reply-To: <4A56B735.1040805@rollernet.us> References: <4A566292.6030300@thewybles.com> <61b6fbec0907091825n4c5f649dha7484dae692e5865@mail.gmail.com> <20090709213528.772dc622@maggie.peachfamily.net> <4A56A59F.7090705@thewybles.com> <4A56AA7F.4030107@olp.net> <4A56B735.1040805@rollernet.us> Message-ID: <4A573DB4.7030505@olp.net> Seth Mattinen wrote: > Dan White wrote: > >> Have you spoken with your provider? They should be giving you options, >> like changing your static address, or null routing the attackers >> upstream, or perhaps blocking port 80 to you, to limit your ingress >> traffic. >> >> > > For DSL? I've never had that kind of luck with SBC's (now AT&T) home > products, and I've been using their DSL since 2001. This is one instance > where paying the big bucks for at least a T1 can show some some return. > Even if it's "business DSL" it's still treated the same as "drooling > user DSL". > > Purely my personal experience. > > ~Seth > > I guess complaining that your provider won't do anything to help you, and not calling them to find out otherwise is a self fulfilling prophecy. - Dan From jbaltz at altzman.com Fri Jul 10 09:10:50 2009 From: jbaltz at altzman.com (Jerry B. Altzman) Date: Fri, 10 Jul 2009 10:10:50 -0400 Subject: YES I'VE TRIED MANY VENUES looking for mail admin @ nist.gov Message-ID: <4A574BEA.4050504@altzman.com> Hi, Yes, I've tried google, I've tried www.nist.gov, I've tried postmaster/hostmaster/abuse at nist.gov, I've even tried the phone. Could someone give me a pointer to a mail admin at nist.gov? I've been having issues getting mail through to them from one of our servers. Thanks, and have a great weekend! //jbaltz -- jerry b. altzman jbaltz at altzman.com www.jbaltz.com thank you for contributing to the heat death of the universe. From kenf at junebug.org Fri Jul 10 09:24:34 2009 From: kenf at junebug.org (Ken Fischer) Date: Fri, 10 Jul 2009 10:24:34 -0400 Subject: YES I'VE TRIED MANY VENUES looking for mail admin @ nist.gov In-Reply-To: <4A574BEA.4050504@altzman.com> References: <4A574BEA.4050504@altzman.com> Message-ID: <16b06c440907100724t584686d7qd3a872ae37bb86b5@mail.gmail.com> Try 301-975-5375 -Ken On Fri, Jul 10, 2009 at 10:10 AM, Jerry B. Altzman wrote: > Hi, > > Yes, I've tried google, I've tried www.nist.gov, I've tried > postmaster/hostmaster/abuse at nist.gov, I've even tried the phone. > > Could someone give me a pointer to a mail admin at nist.gov? I've been > having issues getting mail through to them from one of our servers. > > Thanks, and have a great weekend! > > //jbaltz > -- > jerry b. altzman ? ? ? ?jbaltz at altzman.com ? ? www.jbaltz.com > thank you for contributing to the heat death of the universe. > > From charles at thewybles.com Fri Jul 10 09:38:21 2009 From: charles at thewybles.com (Charles Wyble) Date: Fri, 10 Jul 2009 07:38:21 -0700 Subject: Request for contact and procedure information In-Reply-To: <4A573DB4.7030505@olp.net> References: <4A566292.6030300@thewybles.com> <61b6fbec0907091825n4c5f649dha7484dae692e5865@mail.gmail.com> <20090709213528.772dc622@maggie.peachfamily.net> <4A56A59F.7090705@thewybles.com> <4A56AA7F.4030107@olp.net> <4A56B735.1040805@rollernet.us> <4A573DB4.7030505@olp.net> Message-ID: <4A57525D.2050005@thewybles.com> I spoke with SBC. 2 hours on the phone (all with US based support which was awesome) came down to e-mail abuse at sbcglobal.net. I'll let everyone know how it goes. From sethm at rollernet.us Fri Jul 10 10:36:31 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 10 Jul 2009 08:36:31 -0700 Subject: Request for contact and procedure information In-Reply-To: <4A573DB4.7030505@olp.net> References: <4A566292.6030300@thewybles.com> <61b6fbec0907091825n4c5f649dha7484dae692e5865@mail.gmail.com> <20090709213528.772dc622@maggie.peachfamily.net> <4A56A59F.7090705@thewybles.com> <4A56AA7F.4030107@olp.net> <4A56B735.1040805@rollernet.us> <4A573DB4.7030505@olp.net> Message-ID: <4A575FFF.20100@rollernet.us> Dan White wrote: > Seth Mattinen wrote: >> Dan White wrote: >> >>> Have you spoken with your provider? They should be giving you options, >>> like changing your static address, or null routing the attackers >>> upstream, or perhaps blocking port 80 to you, to limit your ingress >>> traffic. >>> >>> >> >> For DSL? I've never had that kind of luck with SBC's (now AT&T) home >> products, and I've been using their DSL since 2001. This is one instance >> where paying the big bucks for at least a T1 can show some some return. >> Even if it's "business DSL" it's still treated the same as "drooling >> user DSL". >> >> Purely my personal experience. >> >> ~Seth >> >> > > I guess complaining that your provider won't do anything to help you, > and not calling them to find out otherwise is a self fulfilling prophecy. > Can you read? Did I say that? ~Seth From cmadams at hiwaay.net Fri Jul 10 10:38:48 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 10 Jul 2009 10:38:48 -0500 Subject: Point to Point Ethernet In-Reply-To: References: <4A546E70.9090604@nrg4u.com> <2e9d8ae50907081604uabbba04wb285a40c7c66f102@mail.gmail.com> <20090709.083412.74715921.sthaug@nethelp.no> <70D072392E56884193E3D2DE09C097A91F427B@pascal.zaphodb.org> <71c13900907090729q5a6cc243s27aafd06d67ce288@mail.gmail.com> <4fff97de0907091333h6cb58f5drada2a0265f51e9b6@mail.gmail.com> Message-ID: <20090710153848.GB1049002@hiwaay.net> Once upon a time, Ricky Beam said: > Ethernet is cheap because it's everywhere, and built into almost > everything. (however, the likes of Cisco and Juniper still charge insane > amounts for line cards, be they ethernet, T1, or OC48.) Given the choice > of buying a $4k DS3 card or just plugging into an existing, builtin > ethernet port, which do you think most people will choose? Also, if you are plugging in a lower-speed link, you can plug ethernet in a <$1000 switch and trunk it to a router, while a mux for T1/T3/OCx circuits costs a lot more. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From sethm at rollernet.us Fri Jul 10 10:48:09 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 10 Jul 2009 08:48:09 -0700 Subject: Point to Point Ethernet In-Reply-To: <20090710153848.GB1049002@hiwaay.net> References: <4A546E70.9090604@nrg4u.com> <2e9d8ae50907081604uabbba04wb285a40c7c66f102@mail.gmail.com> <20090709.083412.74715921.sthaug@nethelp.no> <70D072392E56884193E3D2DE09C097A91F427B@pascal.zaphodb.org> <71c13900907090729q5a6cc243s27aafd06d67ce288@mail.gmail.com> <4fff97de0907091333h6cb58f5drada2a0265f51e9b6@mail.gmail.com> <20090710153848.GB1049002@hiwaay.net> Message-ID: <4A5762B9.7050009@rollernet.us> Chris Adams wrote: > Once upon a time, Ricky Beam said: >> Ethernet is cheap because it's everywhere, and built into almost >> everything. (however, the likes of Cisco and Juniper still charge insane >> amounts for line cards, be they ethernet, T1, or OC48.) Given the choice >> of buying a $4k DS3 card or just plugging into an existing, builtin >> ethernet port, which do you think most people will choose? > > Also, if you are plugging in a lower-speed link, you can plug ethernet > in a <$1000 switch and trunk it to a router, while a mux for T1/T3/OCx > circuits costs a lot more. > I just ordered a circuit to be delivered over Ethernet - Verizon just plugged a pair of STM-1's into an ISG5100 and it's suddenly ridiculously cheaper. ~Seth From dwhite at olp.net Fri Jul 10 10:58:52 2009 From: dwhite at olp.net (Dan White) Date: Fri, 10 Jul 2009 10:58:52 -0500 Subject: Request for contact and procedure information In-Reply-To: <4A575FFF.20100@rollernet.us> References: <4A566292.6030300@thewybles.com> <61b6fbec0907091825n4c5f649dha7484dae692e5865@mail.gmail.com> <20090709213528.772dc622@maggie.peachfamily.net> <4A56A59F.7090705@thewybles.com> <4A56AA7F.4030107@olp.net> <4A56B735.1040805@rollernet.us> <4A573DB4.7030505@olp.net> <4A575FFF.20100@rollernet.us> Message-ID: <4A57653C.5080405@olp.net> Seth Mattinen wrote: > Dan White wrote: > >> Seth Mattinen wrote: >> >>> Dan White wrote: >>> >>> >>>> Have you spoken with your provider? They should be giving you options, >>>> like changing your static address, or null routing the attackers >>>> upstream, or perhaps blocking port 80 to you, to limit your ingress >>>> traffic. >>>> >>>> >>>> >>> For DSL? I've never had that kind of luck with SBC's (now AT&T) home >>> products, and I've been using their DSL since 2001. This is one instance >>> where paying the big bucks for at least a T1 can show some some return. >>> Even if it's "business DSL" it's still treated the same as "drooling >>> user DSL". >>> >>> Purely my personal experience. >>> >>> ~Seth >>> >>> >>> >> I guess complaining that your provider won't do anything to help you, >> and not calling them to find out otherwise is a self fulfilling prophecy. >> >> > > Can you read? Did I say that? > > ~Seth > > Seth, This was obviously not a response to you, but to the original poster. - Dan From dylan.ebner at crlmed.com Fri Jul 10 10:59:21 2009 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Fri, 10 Jul 2009 09:59:21 -0600 Subject: Point to Point Ethernet In-Reply-To: <20090710153848.GB1049002@hiwaay.net> References: <4A546E70.9090604@nrg4u.com><2e9d8ae50907081604uabbba04wb285a40c7c66f102@mail.gmail.com><20090709.083412.74715921.sthaug@nethelp.no><70D072392E56884193E3D2DE09C097A91F427B@pascal.zaphodb.org><71c13900907090729q5a6cc243s27aafd06d67ce288@mail.gmail.com><4fff97de0907091333h6cb58f5drada2a0265f51e9b6@mail.gmail.com> <20090710153848.GB1049002@hiwaay.net> Message-ID: <6286FF05EBE33C4596F6C6C23762686702362592@VS11.EXCHPROD.USA.NET> It should be noted that this usually isn't recommened. Dropping an ethernet circuit directly into a switch (even if it is laywer 3) can create design issues, esecially later when you need to scale the network. One big issue that is often overlooked is many swithces do not support traffic shaping. Some support policing, but shaping can be far more efficient. There are some nortel switches that do this, but I haven't seen many in the wild. -----Original Message----- From: Chris Adams [mailto:cmadams at hiwaay.net] Sent: Friday, July 10, 2009 10:39 AM To: nanog at nanog.org Subject: Re: Point to Point Ethernet Once upon a time, Ricky Beam said: > Ethernet is cheap because it's everywhere, and built into almost > everything. (however, the likes of Cisco and Juniper still charge > insane amounts for line cards, be they ethernet, T1, or OC48.) Given > the choice of buying a $4k DS3 card or just plugging into an existing, > builtin ethernet port, which do you think most people will choose? Also, if you are plugging in a lower-speed link, you can plug ethernet in a <$1000 switch and trunk it to a router, while a mux for T1/T3/OCx circuits costs a lot more. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From pauldotwall at gmail.com Fri Jul 10 11:05:15 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Fri, 10 Jul 2009 12:05:15 -0400 Subject: Bandcon In-Reply-To: <42d378020907091343h60a4d031hbcb52ab83041720b@mail.gmail.com> References: <42d378020907091343h60a4d031hbcb52ab83041720b@mail.gmail.com> Message-ID: <620fd17c0907100905p153df9eew3fd147f9cbbbc2c3@mail.gmail.com> On Thu, Jul 9, 2009 at 4:43 PM, tb wrote: > My name is Todd Braning, I work on the technical side of the BandCon > house. ?I am afraid Paul's email is inaccurate. Yo Todd! It's good to hear that you've listened to feedback and made these key operational operational changes. I wish you the best of luck going foward. Please keep in mind that I wasn't trying to smear your company, but rather provide the original poster with real-word feedback on a particular vendor whose customers I've worked with many times over. It would be great if you could stay on the list and join us in future discussions. Keeping things topical for the NANOG list, could you tell us a little more about BandCon's transport offering as relates to backbone policy? Is IP transit traffic preferenced over your PWEs, or the other way around, or are they both FIFO'd? What TE, QoS policy, and signaling/congestion controls have you deployed to deal with multiple customers purchasing 10G pipes and competing for access to a single 10G path between metros? Do you have a general policy on oversubscription ratios you'd be able to share without going into NDA'ed territory? Also on-topic, I know a lot of community members have voiced RECENT concern with the relentless tactics of your sales force, some of it bordering on CAN-SPAM violation and criminal harassment. Could you speak a little bit to what you're doing to bring this under control? Would it be a problem if people mail you off-list with any specific problems they've encountered there? Drive Slow, Paul Wall From sethm at rollernet.us Fri Jul 10 11:06:39 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 10 Jul 2009 09:06:39 -0700 Subject: Request for contact and procedure information In-Reply-To: <4A57653C.5080405@olp.net> References: <4A566292.6030300@thewybles.com> <61b6fbec0907091825n4c5f649dha7484dae692e5865@mail.gmail.com> <20090709213528.772dc622@maggie.peachfamily.net> <4A56A59F.7090705@thewybles.com> <4A56AA7F.4030107@olp.net> <4A56B735.1040805@rollernet.us> <4A573DB4.7030505@olp.net> <4A575FFF.20100@rollernet.us> <4A57653C.5080405@olp.net> Message-ID: <4A57670F.5040504@rollernet.us> Dan White wrote: > Seth Mattinen wrote: >> Dan White wrote: >> >>> Seth Mattinen wrote: >>> >>>> Dan White wrote: >>>> >>>> >>>>> Have you spoken with your provider? They should be giving you options, >>>>> like changing your static address, or null routing the attackers >>>>> upstream, or perhaps blocking port 80 to you, to limit your ingress >>>>> traffic. >>>>> >>>>> >>>>> >>>> For DSL? I've never had that kind of luck with SBC's (now AT&T) home >>>> products, and I've been using their DSL since 2001. This is one instance >>>> where paying the big bucks for at least a T1 can show some some return. >>>> Even if it's "business DSL" it's still treated the same as "drooling >>>> user DSL". >>>> >>>> Purely my personal experience. >>>> >>>> ~Seth >>>> >>>> >>>> >>> I guess complaining that your provider won't do anything to help you, >>> and not calling them to find out otherwise is a self fulfilling prophecy. >>> >>> >> >> Can you read? Did I say that? >> >> ~Seth >> >> > Seth, > > This was obviously not a response to you, but to the original poster. > Sorry, I read that as a response to my message. ~Seth From sil at infiltrated.net Fri Jul 10 11:13:48 2009 From: sil at infiltrated.net (J. Oquendo) Date: Fri, 10 Jul 2009 12:13:48 -0400 Subject: YES I'VE TRIED MANY VENUES looking for mail admin @ nist.gov In-Reply-To: <16b06c440907100724t584686d7qd3a872ae37bb86b5@mail.gmail.com> References: <4A574BEA.4050504@altzman.com> <16b06c440907100724t584686d7qd3a872ae37bb86b5@mail.gmail.com> Message-ID: <4A5768BC.5090901@infiltrated.net> Ken Fischer wrote: > Try 301-975-5375 > > -Ken > Oy to automation "Thank you for calling NIST please listen as our menu options have changed. For Sales press 1 For Customer Support press 2 For IT related issues press 3 " (press 3) - rerouted to an APNIC block (outsourced!): "Velcome is here to en eye esh tee dish is John" "I'm having trouble with mail......" "vell have you tried reboot?" "vat vershun of vindows are you use?" *ducks -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From ge at linuxbox.org Fri Jul 10 11:16:26 2009 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 10 Jul 2009 19:16:26 +0300 Subject: YES I'VE TRIED MANY VENUES looking for mail admin @ nist.gov In-Reply-To: <4A5768BC.5090901@infiltrated.net> References: <4A574BEA.4050504@altzman.com> <16b06c440907100724t584686d7qd3a872ae37bb86b5@mail.gmail.com> <4A5768BC.5090901@infiltrated.net> Message-ID: <4A57695A.3090000@linuxbox.org> J. Oquendo wrote: > (press 3) - rerouted to an APNIC block (outsourced!): > > "Velcome is here to en eye esh tee dish is John" > "I'm having trouble with mail......" > "vell have you tried reboot?" > "vat vershun of vindows are you use?" > > *ducks http://www.youtube.com/watch?v=QpmLrz_lSuE The IT Crowd, one of the best British shows currently running. :) Gadi. From pauldotwall at gmail.com Fri Jul 10 11:30:47 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Fri, 10 Jul 2009 12:30:47 -0400 Subject: ISP BGP Resources In-Reply-To: <20090710121743.a4a823da@concur.batblue.com> References: <20090710121743.a4a823da@concur.batblue.com> Message-ID: <620fd17c0907100930pbc3e6ffh4fd2376ce8ffb56f@mail.gmail.com> On Fri, Jul 10, 2009 at 8:17 AM, Babak Pasdar wrote: > We are in the process of rolling out communities that our customers can use to manipulate their routes. ?Are there any resources (books, web sites, mailing lists, etc..) that anyone can recommend? The Steenbergen presentation is a good resource, or more generally, Internet Routing Architectures by Sam Halabi. Drive Slow, Paul Wall From shrdlu at deaddrop.org Fri Jul 10 11:34:09 2009 From: shrdlu at deaddrop.org (Etaoin Shrdlu) Date: Fri, 10 Jul 2009 09:34:09 -0700 Subject: YES I'VE TRIED MANY VENUES looking for mail admin @ nist.gov In-Reply-To: <4A574BEA.4050504@altzman.com> References: <4A574BEA.4050504@altzman.com> Message-ID: <4A576D81.8070700@deaddrop.org> Jerry B. Altzman wrote: > Hi, > > Yes, I've tried google, I've tried www.nist.gov, I've tried > postmaster/hostmaster/abuse at nist.gov, I've even tried the phone. > > Could someone give me a pointer to a mail admin at nist.gov? I've been > having issues getting mail through to them from one of our servers. Please note that Elizabeth is NOT, I repeat, N O T, a mail administrator. However, she's been responsive to other issues, and is the part of the group that supplies the ever useful group of publications under ITL. elizabeth(dot)lennon (at) nist(dot)gov At least you'll have a better chance of getting help, and perhaps this will improve the situation for others in the future. -- Bene disserere est finis logices... (To carry on a disputation well is the end or purpose of logic) Terminat hora diem; terminat auctor opus. (The hour finishes the day; the author finishes his work.) Kit Marlowe From mark at amplex.net Fri Jul 10 11:42:24 2009 From: mark at amplex.net (Mark Radabaugh) Date: Fri, 10 Jul 2009 12:42:24 -0400 Subject: BGP Growth projections Message-ID: <4A576F70.9010003@amplex.net> I'm looking for new core routers for a small ISP and having a hard time finding something appropriate and reasonably priced. We don't have huge traffic levels (<1Gb) and are mostly running Ethernet interfaces to upstreams rather than legacy interfaces (when did OC3 become legacy?). Lot's of choices for routers that can handle the existing BGP tables - but not so much in small platforms (1-10Gb traffic) if you assume that IPv6 is going to explode the routing table in the next 5 years. The manufacturers still seem to think low traffic routers don't need much memory or CPU. What projections are you using regarding the default free zone over the next 5 years when picking new hardware? -- Mark Radabaugh Amplex 419.837.5015 x21 mark at amplex.net From jlewis at lewis.org Fri Jul 10 11:50:28 2009 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 10 Jul 2009 12:50:28 -0400 (EDT) Subject: BGP Growth projections In-Reply-To: <4A576F70.9010003@amplex.net> References: <4A576F70.9010003@amplex.net> Message-ID: On Fri, 10 Jul 2009, Mark Radabaugh wrote: > I'm looking for new core routers for a small ISP and having a hard time > finding something appropriate and reasonably priced. We don't have huge > traffic levels (<1Gb) and are mostly running Ethernet interfaces to upstreams > rather than legacy interfaces (when did OC3 become legacy?). > Lot's of choices for routers that can handle the existing BGP tables - but > not so much in small platforms (1-10Gb traffic) if you assume that IPv6 is > going to explode the routing table in the next 5 years. The manufacturers > still seem to think low traffic routers don't need much memory or CPU. > What projections are you using regarding the default free zone over the next > 5 years when picking new hardware? 1-10Gb is what you consider a small ISP platform? At the low end (maybe much too low for you), the top models in cisco's 2800 series can hold 1GB of RAM. That ought to be plenty for the next few years. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From joelja at bogus.com Fri Jul 10 12:03:53 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 10 Jul 2009 10:03:53 -0700 Subject: BGP Growth projections In-Reply-To: <4A576F70.9010003@amplex.net> References: <4A576F70.9010003@amplex.net> Message-ID: <4A577479.9020703@bogus.com> Mark Radabaugh wrote: > I'm looking for new core routers for a small ISP and having a hard time > finding something appropriate and reasonably priced. We don't have > huge traffic levels (<1Gb) and are mostly running Ethernet interfaces to > upstreams rather than legacy interfaces (when did OC3 become legacy?). > Lot's of choices for routers that can handle the existing BGP tables - > but not so much in small platforms (1-10Gb traffic) if you assume that > IPv6 is going to explode the routing table in the next 5 years. More like, ipv4 is going explode the routing table in the next 5 years? On a percentage basis v6 is in fact growing faster. but one of these things is growing at 1k-2kprefixes a week and the other is ~ 2k prefixes total. It's plausible that you need 500k v4 dfz routes at or before 2012 that would be right on schedule from the 250k mark... Fitting a curve to the v6 table growth is an interesting experiment in modeling your expectations. I think it's an excellent opportunity for a synthetic futures market. > The > manufacturers still seem to think low traffic routers don't need much > memory or CPU. > What projections are you using regarding the default free zone over the > next 5 years when picking new hardware? From tbraning at gmail.com Fri Jul 10 12:41:23 2009 From: tbraning at gmail.com (tb) Date: Fri, 10 Jul 2009 10:41:23 -0700 Subject: Bandcon In-Reply-To: <620fd17c0907100905p153df9eew3fd147f9cbbbc2c3@mail.gmail.com> References: <42d378020907091343h60a4d031hbcb52ab83041720b@mail.gmail.com> <620fd17c0907100905p153df9eew3fd147f9cbbbc2c3@mail.gmail.com> Message-ID: <42d378020907101041r1d8e76adj35ea9f294feb830e@mail.gmail.com> Hi Paul, As stated in my last post, I am happy to discuss the technical merits of BandCon?s products with any individual. However, I think most here will concur, this is not the proper platform for such discussions. On a personal note, I have been an active NANOG participant for over 10 years and don?t see that changing anytime soon. -Todd Braning On Fri, Jul 10, 2009 at 9:05 AM, Paul Wall wrote: > On Thu, Jul 9, 2009 at 4:43 PM, tb wrote: >> My name is Todd Braning, I work on the technical side of the BandCon >> house. ?I am afraid Paul's email is inaccurate. > > Yo Todd! > > It's good to hear that you've listened to feedback and made these key > operational operational changes. ?I wish you the best of luck going > foward. ?Please keep in mind that I wasn't trying to smear your > company, but rather provide the original poster with real-word > feedback on a particular vendor whose customers I've worked with many > times over. ?It would be great if you could stay on the list and join > us in future discussions. > > Keeping things topical for the NANOG list, could you tell us a little > more about BandCon's transport offering ?as relates to backbone > policy? ?Is IP transit traffic preferenced over your PWEs, or the > other way around, or are they both FIFO'd? ?What TE, QoS policy, and > signaling/congestion controls have you deployed to deal with multiple > customers purchasing 10G pipes and competing for access to a single > 10G path between metros? ?Do you have a general policy on > oversubscription ratios you'd be able to share without going into > NDA'ed territory? > > Also on-topic, I know a lot of community members have voiced RECENT > concern with the relentless tactics of your sales force, some of it > bordering on CAN-SPAM violation and criminal harassment. ?Could you > speak a little bit to what you're doing to bring this under control? > Would it be a problem if people mail you off-list with any specific > problems they've encountered there? > > Drive Slow, > Paul Wall > From martin at theicelandguy.com Fri Jul 10 12:47:08 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Fri, 10 Jul 2009 13:47:08 -0400 Subject: YES I'VE TRIED MANY VENUES looking for mail admin @ nist.gov In-Reply-To: <4A574BEA.4050504@altzman.com> References: <4A574BEA.4050504@altzman.com> Message-ID: On Fri, Jul 10, 2009 at 10:10 AM, Jerry B. Altzman wrote: > Hi, > > Yes, I've tried google, I've tried www.nist.gov, I've tried > postmaster/hostmaster/abuse at nist.gov, I've even tried the phone. > > Could someone give me a pointer to a mail admin at nist.gov? I've been > having issues getting mail through to them from one of our servers. > > Thanks, and have a great weekend! I suggested the telephone to another a few weeks ago and that wasn't well received. Let me elaborate. Today is Friday. It's July. It's about 2PM. Probably lunchtime where NIST is. Calling the IT help desk at NIST is likely to get you further faster. NANOG is not really "real time". It's also NIST. I believe you can call DHS if it's that big of a deal, no? Also, try this query for a good mailbox: http://www.google.com/#hl=en&q=nist.gov+%40nanog&aq=f&oq=&aqi=&fp=epvPJ4zJz3g Best Regards, -M< -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From zeusdadog at gmail.com Fri Jul 10 12:48:15 2009 From: zeusdadog at gmail.com (Jay Nakamura) Date: Fri, 10 Jul 2009 13:48:15 -0400 Subject: AT&T and having two BGP peers Message-ID: <9418aca70907101048h452520b0sd8681585e4b2709f@mail.gmail.com> We are getting an Ethernet DIA circuit from AT&T but they insist that they can't BGP peer with 2 routers on our side. The WAN circuit can only have /30 they say. Has anyone been able to successfully talk them in to bending their rule? If so, how? I know this should have been negotiated before signing a contract but I was unfortunately not in the loop... :( It seems like a ridiculous bureaucratic restriction. From patrick at ianai.net Fri Jul 10 12:50:31 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 10 Jul 2009 13:50:31 -0400 Subject: Bandcon In-Reply-To: <620fd17c0907100905p153df9eew3fd147f9cbbbc2c3@mail.gmail.com> References: <42d378020907091343h60a4d031hbcb52ab83041720b@mail.gmail.com> <620fd17c0907100905p153df9eew3fd147f9cbbbc2c3@mail.gmail.com> Message-ID: On Jul 10, 2009, at 12:05 PM, Paul Wall wrote: > On Thu, Jul 9, 2009 at 4:43 PM, tb wrote: >> My name is Todd Braning, I work on the technical side of the BandCon >> house. I am afraid Paul's email is inaccurate. > > Yo Todd! > > It's good to hear that you've listened to feedback and made these key > operational operational changes. I wish you the best of luck going > foward. Please keep in mind that I wasn't trying to smear your > company, but rather provide the original poster with real-word > feedback on a particular vendor whose customers I've worked with many > times over. It would be great if you could stay on the list and join > us in future discussions. > > Keeping things topical for the NANOG list, could you tell us a little > more about BandCon's transport offering as relates to backbone > policy? Is IP transit traffic preferenced over your PWEs, or the > other way around, or are they both FIFO'd? What TE, QoS policy, and > signaling/congestion controls have you deployed to deal with multiple > customers purchasing 10G pipes and competing for access to a single > 10G path between metros? Do you have a general policy on > oversubscription ratios you'd be able to share without going into > NDA'ed territory? Most excellent questions. Do you have this information for other providers? I guarantee much of the rest of the community would like to know these factoids for the large backbones around the world? Or were you just banging on Todd 'cause your first flame fizzled? :) > Also on-topic, I know a lot of community members have voiced RECENT > concern with the relentless tactics of your sales force, some of it > bordering on CAN-SPAM violation and criminal harassment. Could you > speak a little bit to what you're doing to bring this under control? > Would it be a problem if people mail you off-list with any specific > problems they've encountered there? Here we agree. Todd, if you, or anyone, can fix that, we would all be appreciative. If not, it's likely the answers to Paul's previous paragraph won't matter as Bandcon will wither on the vine. -- TTFN, patrick P.S. Sorry if I'm being a little mean to "Paul", but if you don't have the guts to flame from your real name, you don't deserve mercy, or politeness. From patrick at ianai.net Fri Jul 10 12:54:08 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 10 Jul 2009 13:54:08 -0400 Subject: AT&T and having two BGP peers In-Reply-To: <9418aca70907101048h452520b0sd8681585e4b2709f@mail.gmail.com> References: <9418aca70907101048h452520b0sd8681585e4b2709f@mail.gmail.com> Message-ID: <0A3157C6-FA14-4693-8CE8-C16AA40B9EBF@ianai.net> On Jul 10, 2009, at 1:48 PM, Jay Nakamura wrote: > We are getting an Ethernet DIA circuit from AT&T but they insist that > they can't BGP peer with 2 routers on our side. The WAN circuit can > only have /30 they say. Has anyone been able to successfully talk > them in to bending their rule? If so, how? > > I know this should have been negotiated before signing a contract but > I was unfortunately not in the loop... :( > > It seems like a ridiculous bureaucratic restriction. Welcome to AT&T's "reality". Fighting people who have been set in their ways for over a century and actually capable of making the federal government bend to their will is probably not good for your stress level. -- TTFN, patrick From tony at lava.net Fri Jul 10 12:59:56 2009 From: tony at lava.net (Antonio Querubin) Date: Fri, 10 Jul 2009 07:59:56 -1000 (HST) Subject: AT&T and having two BGP peers In-Reply-To: <9418aca70907101048h452520b0sd8681585e4b2709f@mail.gmail.com> References: <9418aca70907101048h452520b0sd8681585e4b2709f@mail.gmail.com> Message-ID: On Fri, 10 Jul 2009, Jay Nakamura wrote: > We are getting an Ethernet DIA circuit from AT&T but they insist that > they can't BGP peer with 2 routers on our side. The WAN circuit can > only have /30 they say. Has anyone been able to successfully talk > them in to bending their rule? If so, how? Sounds odd. They do IPv6 tunnels using 2 tunnels/routers. The /30 reason is even more odd for an ethernet circuit. Antonio Querubin whois: AQ7-ARIN From dougm at nist.gov Fri Jul 10 13:07:45 2009 From: dougm at nist.gov (Doug Montgomery) Date: Fri, 10 Jul 2009 14:07:45 -0400 Subject: YES I'VE TRIED MANY VENUES looking for mail admin @, nist.gov In-Reply-To: References: Message-ID: <4A578371.4000004@nist.gov> >I suggested the telephone to another a few weeks ago and that wasn't well >received. Let me elaborate. Today is Friday. It's July. It's about 2PM. >Probably lunchtime where NIST is. Calling the IT help desk at NIST is >likely to get you further faster. NANOG is not really "real time". Contact me off list and I will link you up. Not all out to lunch ... dougm From cscora at apnic.net Fri Jul 10 13:12:24 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 11 Jul 2009 04:12:24 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200907101812.n6AICOfH005566@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 11 Jul, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 290262 Prefixes after maximum aggregation: 137789 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 144391 Total ASes present in the Internet Routing Table: 31706 Prefixes per ASN: 9.15 Origin-only ASes present in the Internet Routing Table: 27560 Origin ASes announcing only one prefix: 13420 Transit ASes present in the Internet Routing Table: 4146 Transit-only ASes present in the Internet Routing Table: 100 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 474 Unregistered ASNs in the Routing Table: 132 Number of 32-bit ASNs allocated by the RIRs: 198 Prefixes from 32-bit ASNs in the Routing Table: 71 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 345 Number of addresses announced to Internet: 2087524224 Equivalent to 124 /8s, 109 /16s and 23 /24s Percentage of available address space announced: 56.3 Percentage of allocated address space announced: 65.2 Percentage of available address space allocated: 86.4 Percentage of address space in use by end-sites: 78.3 Total number of prefixes smaller than registry allocations: 143711 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 69187 Total APNIC prefixes after maximum aggregation: 24705 APNIC Deaggregation factor: 2.80 Prefixes being announced from the APNIC address blocks: 68608 Unique aggregates announced from the APNIC address blocks: 31331 APNIC Region origin ASes present in the Internet Routing Table: 3695 APNIC Prefixes per ASN: 18.57 APNIC Region origin ASes announcing only one prefix: 1009 APNIC Region transit ASes present in the Internet Routing Table: 577 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 469024448 Equivalent to 27 /8s, 244 /16s and 190 /24s Percentage of available APNIC address space announced: 87.4 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 180/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 123512 Total ARIN prefixes after maximum aggregation: 65893 ARIN Deaggregation factor: 1.87 Prefixes being announced from the ARIN address blocks: 124200 Unique aggregates announced from the ARIN address blocks: 52016 ARIN Region origin ASes present in the Internet Routing Table: 13085 ARIN Prefixes per ASN: 9.49 ARIN Region origin ASes announcing only one prefix: 5027 ARIN Region transit ASes present in the Internet Routing Table: 1279 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 1027107904 Equivalent to 61 /8s, 56 /16s and 108 /24s Percentage of available ARIN address space announced: 197.5 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 66575 Total RIPE prefixes after maximum aggregation: 39344 RIPE Deaggregation factor: 1.69 Prefixes being announced from the RIPE address blocks: 66212 Unique aggregates announced from the RIPE address blocks: 44657 RIPE Region origin ASes present in the Internet Routing Table: 13271 RIPE Prefixes per ASN: 4.99 RIPE Region origin ASes announcing only one prefix: 6926 RIPE Region transit ASes present in the Internet Routing Table: 1987 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 22 Number of RIPE addresses announced to Internet: 496541888 Equivalent to 29 /8s, 152 /16s and 160 /24s Percentage of available RIPE address space announced: 105.7 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 24417 Total LACNIC prefixes after maximum aggregation: 6023 LACNIC Deaggregation factor: 4.05 Prefixes being announced from the LACNIC address blocks: 24331 Unique aggregates announced from the LACNIC address blocks: 13563 LACNIC Region origin ASes present in the Internet Routing Table: 1139 LACNIC Prefixes per ASN: 21.36 LACNIC Region origin ASes announcing only one prefix: 367 LACNIC Region transit ASes present in the Internet Routing Table: 189 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 19 Number of LACNIC addresses announced to Internet: 72246144 Equivalent to 4 /8s, 78 /16s and 99 /24s Percentage of available LACNIC address space announced: 71.8 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 6155 Total AfriNIC prefixes after maximum aggregation: 1499 AfriNIC Deaggregation factor: 4.11 Prefixes being announced from the AfriNIC address blocks: 6552 Unique aggregates announced from the AfriNIC address blocks: 2548 AfriNIC Region origin ASes present in the Internet Routing Table: 307 AfriNIC Prefixes per ASN: 21.34 AfriNIC Region origin ASes announcing only one prefix: 91 AfriNIC Region transit ASes present in the Internet Routing Table: 66 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 20229888 Equivalent to 1 /8s, 52 /16s and 175 /24s Percentage of available AfriNIC address space announced: 60.3 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1702 6934 407 Korea Telecom (KIX) 17488 1536 138 94 Hathway IP Over Cable Interne 4755 1217 308 144 TATA Communications formerly 9583 1125 87 560 Sify Limited 4134 979 17164 376 CHINANET-BACKBONE 7545 812 198 102 TPG Internet Pty Ltd 23577 781 34 665 Korea Telecom (ATM-MPLS) 9829 766 603 18 BSNL National Internet Backbo 18101 750 200 32 Reliance Infocom Ltd Internet 24560 725 230 171 Bharti Airtel Ltd. Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4261 3643 322 bellsouth.net, inc. 4323 1886 1047 384 Time Warner Telecom 1785 1709 714 140 PaeTec Communications, Inc. 7018 1504 5909 1050 AT&T WorldNet Services 20115 1405 1464 681 Charter Communications 2386 1272 671 925 AT&T Data Communications Serv 6478 1209 275 308 AT&T Worldnet Services 3356 1195 10961 442 Level 3 Communications, LLC 11492 1127 208 12 Cable One 22773 1075 2604 66 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 30890 484 92 197 Evolva Telecom 12479 476 578 6 Uni2 Autonomous System 3292 458 1902 394 TDC Tele Danmark 702 428 1861 344 UUNET - Commercial IP service 35805 356 40 5 United Telecom of Georgia 3320 348 7067 301 Deutsche Telekom AG 3301 347 1684 309 TeliaNet Sweden 3215 343 3065 108 France Telecom Transpac 8866 335 109 20 Bulgarian Telecommunication C 29049 308 26 3 AzerSat LLC. Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1457 2882 235 UniNet S.A. de C.V. 10620 923 211 104 TVCABLE BOGOTA 28573 611 570 31 NET Servicos de Comunicao S.A 7303 591 312 93 Telecom Argentina Stet-France 22047 543 302 14 VTR PUNTO NET S.A. 11830 488 294 52 Instituto Costarricense de El 11172 441 99 69 Servicios Alestra S.A de C.V 6471 439 96 31 ENTEL CHILE S.A. 7738 410 858 29 Telecomunicacoes da Bahia S.A 3816 382 190 78 Empresa Nacional de Telecomun Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 993 188 7 TEDATA 24863 894 88 46 LINKdotNET AS number 20858 322 34 5 EgyNet 3741 276 856 236 The Internet Solution 2018 243 215 143 Tertiary Education Network 6713 176 166 16 Itissalat Al-MAGHRIB 33783 152 10 8 EEPAD TISP TELECOM & INTERNET 29571 140 15 8 Ci Telecom Autonomous system 5536 123 8 9 Internet Egypt Network 33776 121 7 11 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4261 3643 322 bellsouth.net, inc. 4323 1886 1047 384 Time Warner Telecom 1785 1709 714 140 PaeTec Communications, Inc. 4766 1702 6934 407 Korea Telecom (KIX) 17488 1536 138 94 Hathway IP Over Cable Interne 7018 1504 5909 1050 AT&T WorldNet Services 8151 1457 2882 235 UniNet S.A. de C.V. 20115 1405 1464 681 Charter Communications 2386 1272 671 925 AT&T Data Communications Serv 4755 1217 308 144 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 1785 1709 1569 PaeTec Communications, Inc. 4323 1886 1502 Time Warner Telecom 17488 1536 1442 Hathway IP Over Cable Interne 4766 1702 1295 Korea Telecom (KIX) 8151 1457 1222 UniNet S.A. de C.V. 11492 1127 1115 Cable One 4755 1217 1073 TATA Communications formerly 18566 1062 1052 Covad Communications 22773 1075 1009 Cox Communications, Inc. 8452 993 986 TEDATA Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.112.0/22 5713 Telkom SA Ltd 41.223.176.0/22 36981 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.251.0/24 22555 Universal Talkware Corporatio 64.31.32.0/19 11955 ServiceCo LLC - Road Runner Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:20 /9:10 /10:23 /11:58 /12:169 /13:350 /14:611 /15:1164 /16:10527 /17:4749 /18:8201 /19:17096 /20:20431 /21:20272 /22:26049 /23:25958 /24:151912 /25:902 /26:1028 /27:561 /28:148 /29:8 /30:7 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2773 4261 bellsouth.net, inc. 4766 1401 1702 Korea Telecom (KIX) 17488 1282 1536 Hathway IP Over Cable Interne 1785 1180 1709 PaeTec Communications, Inc. 11492 1053 1127 Cable One 18566 1043 1062 Covad Communications 2386 988 1272 AT&T Data Communications Serv 9583 977 1125 Sify Limited 4323 957 1886 Time Warner Telecom 8452 917 993 TEDATA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:14 8:209 12:2141 13:8 15:19 16:3 17:5 20:35 24:1098 32:51 38:576 40:98 41:1766 43:1 44:2 47:22 52:5 55:2 56:2 57:24 58:591 59:651 60:464 61:1075 62:1115 63:2046 64:3714 65:2406 66:3595 67:1606 68:822 69:2650 70:557 71:146 72:1664 73:2 74:1606 75:171 76:341 77:844 78:562 79:354 80:981 81:841 82:569 83:459 84:634 85:1026 86:393 87:673 88:352 89:1451 90:50 91:2392 92:330 93:1115 94:1229 95:1114 96:149 97:212 98:247 99:26 110:175 111:58 112:108 113:142 114:252 115:311 116:1096 117:536 118:352 119:743 120:145 121:779 122:1052 123:709 124:983 125:1392 128:224 129:231 130:128 131:399 132:71 133:9 134:188 135:39 136:223 137:163 138:169 139:79 140:442 141:119 142:391 143:353 144:366 145:48 146:387 147:154 148:519 149:232 150:177 151:194 152:145 153:147 154:2 155:274 156:164 157:300 158:118 159:343 160:284 161:152 162:274 163:162 164:480 165:502 166:463 167:356 168:656 169:171 170:477 171:41 172:10 173:305 174:235 178:1 186:96 187:99 188:246 189:473 190:2875 192:5789 193:4254 194:3311 195:2682 196:1103 198:3601 199:3361 200:5107 201:1317 202:7707 203:8267 204:3890 205:2153 206:2444 207:2740 208:3870 209:3375 210:2540 211:1133 212:1633 213:1636 214:73 215:24 216:4533 217:1335 218:400 219:441 220:1114 221:481 222:303 End of report From r.hyunseog at ieee.org Fri Jul 10 13:18:58 2009 From: r.hyunseog at ieee.org (Alex H. Ryu) Date: Fri, 10 Jul 2009 13:18:58 -0500 Subject: AT&T and having two BGP peers In-Reply-To: References: <9418aca70907101048h452520b0sd8681585e4b2709f@mail.gmail.com> Message-ID: <4A578612.1010600@ieee.org> If it is the way AT&T have designed their product, there may be no other way around. >From AT&T's viewpoint, it will add more complexity to troubleshoot. If you pay extra, AT&T may have some solution for you. Alex Antonio Querubin wrote: > On Fri, 10 Jul 2009, Jay Nakamura wrote: > >> We are getting an Ethernet DIA circuit from AT&T but they insist that >> they can't BGP peer with 2 routers on our side. The WAN circuit can >> only have /30 they say. Has anyone been able to successfully talk >> them in to bending their rule? If so, how? > > Sounds odd. They do IPv6 tunnels using 2 tunnels/routers. The /30 > reason is even more odd for an ethernet circuit. > > Antonio Querubin > whois: AQ7-ARIN > > > From duane.waddle at gmail.com Fri Jul 10 13:21:49 2009 From: duane.waddle at gmail.com (Duane Waddle) Date: Fri, 10 Jul 2009 13:21:49 -0500 Subject: OEMs for X2 10G LAN PHY optics Message-ID: <80e7195b0907101121o15ee4e5ex4b16d29268db1bbf@mail.gmail.com> Hi, I am searching for opinions on OEMs of X2 form factor 10G LAN PHY optics. We've found that most router/switch vendors mark these particular items up significantly just to provide their own sticker/EEPROM ID. As such, we'd prefer if we can to procure from the OEM (or their reseller). Is this a situation where any company who's a signatory to the MSA produces suitable modules, or are there particular OEMs to prefer (or avoid)? If it matters, the prime platform we're looking to plug optics into is the WS-X6708-10G module for a 6500/7600. Thanks in advance --Duane From wbailey at gci.com Fri Jul 10 13:23:23 2009 From: wbailey at gci.com (Warren Bailey) Date: Fri, 10 Jul 2009 10:23:23 -0800 Subject: AT&T and having two BGP peers Message-ID: <5B3743FC2D0D8B41B27EE4F5EACA79D108970FD0@DTN1EX01.gci.com> Threaten to twitter about it. Worked for the guy on myth busters.. ;) ----- Original Message ----- From: Jay Nakamura To: nanog at merit.edu Sent: Fri Jul 10 09:48:15 2009 Subject: AT&T and having two BGP peers We are getting an Ethernet DIA circuit from AT&T but they insist that they can't BGP peer with 2 routers on our side. The WAN circuit can only have /30 they say. Has anyone been able to successfully talk them in to bending their rule? If so, how? I know this should have been negotiated before signing a contract but I was unfortunately not in the loop... :( It seems like a ridiculous bureaucratic restriction. From bclark at spectraaccess.com Fri Jul 10 13:53:46 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Fri, 10 Jul 2009 14:53:46 -0400 Subject: AT&T and having two BGP peers In-Reply-To: <5B3743FC2D0D8B41B27EE4F5EACA79D108970FD0@DTN1EX01.gci.com> References: <5B3743FC2D0D8B41B27EE4F5EACA79D108970FD0@DTN1EX01.gci.com> Message-ID: <4A578E3A.1010401@spectraaccess.com> Cancel the circuit...I know most of the providers I've worked with have a 90 satisfaction guarantee. Chances are if you cancel the circuit they will mysteriously find a way to work with you. Warren Bailey wrote: > Threaten to twitter about it. Worked for the guy on myth busters.. ;) > > ----- Original Message ----- > From: Jay Nakamura > To: nanog at merit.edu > Sent: Fri Jul 10 09:48:15 2009 > Subject: AT&T and having two BGP peers > > We are getting an Ethernet DIA circuit from AT&T but they insist that > they can't BGP peer with 2 routers on our side. The WAN circuit can > only have /30 they say. Has anyone been able to successfully talk > them in to bending their rule? If so, how? > > I know this should have been negotiated before signing a contract but > I was unfortunately not in the loop... :( > > It seems like a ridiculous bureaucratic restriction. > > From r.engehausen at gmail.com Fri Jul 10 13:53:58 2009 From: r.engehausen at gmail.com (Roy) Date: Fri, 10 Jul 2009 11:53:58 -0700 Subject: YES I'VE TRIED MANY VENUES looking for mail admin @ nist.gov In-Reply-To: References: <4A574BEA.4050504@altzman.com> Message-ID: <4A578E46.9060704@gmail.com> Martin Hannigan wrote: > On Fri, Jul 10, 2009 at 10:10 AM, Jerry B. Altzman wrote: > > >> Hi, >> >> Yes, I've tried google, I've tried www.nist.gov, I've tried >> postmaster/hostmaster/abuse at nist.gov, I've even tried the phone. >> >> Could someone give me a pointer to a mail admin at nist.gov? I've been >> having issues getting mail through to them from one of our servers. >> >> Thanks, and have a great weekend! >> > > > > I suggested the telephone to another a few weeks ago and that wasn't well > received. Let me elaborate. Today is Friday. It's July. It's about 2PM. > Probably lunchtime where NIST is. Calling the IT help desk at NIST is > likely to get you further faster. NANOG is not really "real time". > > It's also NIST. I believe you can call DHS if it's that big of a deal, no? > > Also, try this query for a good mailbox: > > http://www.google.com/#hl=en&q=nist.gov+%40nanog&aq=f&oq=&aqi=&fp=epvPJ4zJz3g > > Best Regards, > > -M< > > Must be the group that is in training to handle the new health insurance plan ;-) From carlos at race.com Fri Jul 10 13:55:56 2009 From: carlos at race.com (Carlos Alcantar) Date: Fri, 10 Jul 2009 11:55:56 -0700 Subject: AT&T and having two BGP peers Message-ID: <859604546CD1FF488BDB6EA94C896AFB8AB601@racexchange.race.local> Att is hard to deal with I ran into a situation not long ago where I needed to get a t1 cross connect from one cage to another within a building. They consider floor 3 a CO and floor 7 a different CO. both floors share the same wiring frame room like on the 5th floor. Well they wouldn't allow me to order a cross connect between the 2 floors without having actual cage space on the specific floor even tho they are in the same wiring frame room. On top of that if I wanted to be on the other floor I would have to come in via the outside entrance and do meet point fibers out in the st. btw this is on the telco side what a nightmare... -carlos -----Original Message----- From: Alex H. Ryu [mailto:r.hyunseog at ieee.org] Sent: Friday, July 10, 2009 11:19 AM To: Antonio Querubin Cc: nanog at merit.edu Subject: Re: AT&T and having two BGP peers If it is the way AT&T have designed their product, there may be no other way around. >From AT&T's viewpoint, it will add more complexity to troubleshoot. If you pay extra, AT&T may have some solution for you. Alex Antonio Querubin wrote: > On Fri, 10 Jul 2009, Jay Nakamura wrote: > >> We are getting an Ethernet DIA circuit from AT&T but they insist that >> they can't BGP peer with 2 routers on our side. The WAN circuit can >> only have /30 they say. Has anyone been able to successfully talk >> them in to bending their rule? If so, how? > > Sounds odd. They do IPv6 tunnels using 2 tunnels/routers. The /30 > reason is even more odd for an ethernet circuit. > > Antonio Querubin > whois: AQ7-ARIN > > > From pstewart at nexicomgroup.net Fri Jul 10 13:56:20 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Fri, 10 Jul 2009 14:56:20 -0400 Subject: AT&T and having two BGP peers In-Reply-To: <4A578E3A.1010401@spectraaccess.com> References: <5B3743FC2D0D8B41B27EE4F5EACA79D108970FD0@DTN1EX01.gci.com> <4A578E3A.1010401@spectraaccess.com> Message-ID: That is crazy.... when we turn up new BGP customers, we always put a /29 in place now - for that reason and for others.... saves a LOT of headaches when some changes are needed down the road...;) Paul -----Original Message----- From: Bret Clark [mailto:bclark at spectraaccess.com] Sent: Friday, July 10, 2009 2:54 PM To: nanog at merit.edu Subject: Re: AT&T and having two BGP peers Cancel the circuit...I know most of the providers I've worked with have a 90 satisfaction guarantee. Chances are if you cancel the circuit they will mysteriously find a way to work with you. Warren Bailey wrote: > Threaten to twitter about it. Worked for the guy on myth busters.. ;) > > ----- Original Message ----- > From: Jay Nakamura > To: nanog at merit.edu > Sent: Fri Jul 10 09:48:15 2009 > Subject: AT&T and having two BGP peers > > We are getting an Ethernet DIA circuit from AT&T but they insist that > they can't BGP peer with 2 routers on our side. The WAN circuit can > only have /30 they say. Has anyone been able to successfully talk > them in to bending their rule? If so, how? > > I know this should have been negotiated before signing a contract but > I was unfortunately not in the loop... :( > > It seems like a ridiculous bureaucratic restriction. > > ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From braaen at zcorum.com Fri Jul 10 14:46:48 2009 From: braaen at zcorum.com (Brian Raaen) Date: Fri, 10 Jul 2009 15:46:48 -0400 Subject: Point to Point Ethernet In-Reply-To: <4A5762B9.7050009@rollernet.us> References: <4A546E70.9090604@nrg4u.com> <2e9d8ae50907081604uabbba04wb285a40c7c66f102@mail.gmail.com> <20090709.083412.74715921.sthaug@nethelp.no> <70D072392E56884193E3D2DE09C097A91F427B@pascal.zaphodb.org> <71c13900907090729q5a6cc243s27aafd06d67ce288@mail.gmail.com> <4fff97de0907091333h6cb58f5drada2a0265f51e9b6@mail.gmail.com> <20090710153848.GB1049002@hiwaay.net> <4A5762B9.7050009@rollernet.us> Message-ID: <4A579AA8.4070102@zcorum.com> Hate to say it, but also some of the cost on the circuits can be blamed on uncle Sam. ATM circuits are currently tariffed that same way are voice circuits. These tariffs are not charged to Ethernet because it is a 'data circuit'. At least that was the case a little while back. -- ----------------- Brian Raaen Network Engineer email: /braaen at zcorum.com/ // Seth Mattinen wrote: > Chris Adams wrote: > >> Once upon a time, Ricky Beam said: >> >>> Ethernet is cheap because it's everywhere, and built into almost >>> everything. (however, the likes of Cisco and Juniper still charge insane >>> amounts for line cards, be they ethernet, T1, or OC48.) Given the choice >>> of buying a $4k DS3 card or just plugging into an existing, builtin >>> ethernet port, which do you think most people will choose? >>> >> Also, if you are plugging in a lower-speed link, you can plug ethernet >> in a <$1000 switch and trunk it to a router, while a mux for T1/T3/OCx >> circuits costs a lot more. >> >> > > I just ordered a circuit to be delivered over Ethernet - Verizon just > plugged a pair of STM-1's into an ISG5100 and it's suddenly ridiculously > cheaper. > > ~Seth > > -------------- next part -------------- A non-text attachment was scrubbed... Name: braaen.vcf Type: text/x-vcard Size: 217 bytes Desc: not available URL: From jsdy at center.osis.gov Fri Jul 10 15:11:46 2009 From: jsdy at center.osis.gov (Joseph S D Yao) Date: Fri, 10 Jul 2009 16:11:46 -0400 Subject: YES I'VE TRIED MANY VENUES looking for mail admin @ nist.gov In-Reply-To: <4A578E46.9060704@gmail.com> References: <4A574BEA.4050504@altzman.com> <4A578E46.9060704@gmail.com> Message-ID: <20090710201146.GA4008@core.center.osis.gov> On Fri, Jul 10, 2009 at 11:53:58AM -0700, Roy wrote: ... > Must be the group that is in training to handle the new health insurance > plan ;-) Sorry for the OT, but now you have me confused - what does USA NIST have to do with health insurance??? Standards and Technology is more like weights and measures and atomic clocks. -- Joe Yao Qinetiq NA / Analex Contractor From morrowc.lists at gmail.com Fri Jul 10 16:10:28 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 10 Jul 2009 17:10:28 -0400 Subject: Request for contact and procedure information In-Reply-To: <16720fe00907092311n1d28a7cs99e8259c544b90d@mail.gmail.com> References: <4A566292.6030300@thewybles.com> <4A56BAEB.2030801@aset.com> <4A56BD4D.6050504@aset.com> <16720fe00907092311n1d28a7cs99e8259c544b90d@mail.gmail.com> Message-ID: <75cb24520907101410s3a88b35ek87edaaf896f992a7@mail.gmail.com> On Fri, Jul 10, 2009 at 2:11 AM, Jeffrey Lyon wrote: > All, > > There are few if any ISP that will help you with something like this. uunet/vzb would/will (for free most times even) From jeffrey.lyon at blacklotus.net Fri Jul 10 16:12:52 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 10 Jul 2009 17:12:52 -0400 Subject: Request for contact and procedure information In-Reply-To: <75cb24520907101410s3a88b35ek87edaaf896f992a7@mail.gmail.com> References: <4A566292.6030300@thewybles.com> <4A56BAEB.2030801@aset.com> <4A56BD4D.6050504@aset.com> <16720fe00907092311n1d28a7cs99e8259c544b90d@mail.gmail.com> <75cb24520907101410s3a88b35ek87edaaf896f992a7@mail.gmail.com> Message-ID: <16720fe00907101412n6fc9aabcg95f6051537f9d678@mail.gmail.com> Would what? Null route the IP? I'm talking about actually filtering the attack. Jeff On Jul 10, 2009 5:10 PM, "Christopher Morrow" wrote: On Fri, Jul 10, 2009 at 2:11 AM, Jeffrey Lyon wrote: > All, > > There a... uunet/vzb would/will (for free most times even) From asr+nanog at latency.net Fri Jul 10 16:25:43 2009 From: asr+nanog at latency.net (Adam Rothschild) Date: Fri, 10 Jul 2009 17:25:43 -0400 Subject: OEMs for X2 10G LAN PHY optics In-Reply-To: <80e7195b0907101121o15ee4e5ex4b16d29268db1bbf@mail.gmail.com> References: <80e7195b0907101121o15ee4e5ex4b16d29268db1bbf@mail.gmail.com> Message-ID: <20090710212543.GA46088@latency.net> On 2009-07-10-14:21:49, Duane Waddle wrote: > I am searching for opinions on OEMs of X2 form factor 10G LAN PHY > optics. We've found that most router/switch vendors mark these > particular items up significantly just to provide their own > sticker/EEPROM ID. As such, we'd prefer if we can to procure from the > OEM (or their reseller). Is this a situation where any company who's > a signatory to the MSA produces suitable modules, or are there > particular OEMs to prefer (or avoid)? > > If it matters, the prime platform we're looking to plug optics into is > the WS-X6708-10G module for a 6500/7600. I'd suggest looking at FluxLight (www.fluxlightinc.com) for this. Their sales and support process is nothing short of stellar, and pricing is a fair medium between "paying too much for vendor optics" and "fly-by-night eBay imports". To wit, all of their products Just Worked without ever needing Cisco's infamous 'service unsupported-transceiver' vendor lock override. -a From morrowc.lists at gmail.com Fri Jul 10 16:40:09 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 10 Jul 2009 17:40:09 -0400 Subject: Request for contact and procedure information In-Reply-To: <16720fe00907101412n6fc9aabcg95f6051537f9d678@mail.gmail.com> References: <4A566292.6030300@thewybles.com> <4A56BAEB.2030801@aset.com> <4A56BD4D.6050504@aset.com> <16720fe00907092311n1d28a7cs99e8259c544b90d@mail.gmail.com> <75cb24520907101410s3a88b35ek87edaaf896f992a7@mail.gmail.com> <16720fe00907101412n6fc9aabcg95f6051537f9d678@mail.gmail.com> Message-ID: <75cb24520907101440w1f8308f0n5132e5fede4450a1@mail.gmail.com> On Fri, Jul 10, 2009 at 5:12 PM, Jeffrey Lyon wrote: > Would what? Null route the IP? I'm talking about actually filtering the > attack. as was I. (talking about filtering the attack) > On Jul 10, 2009 5:10 PM, "Christopher Morrow" > wrote: > > On Fri, Jul 10, 2009 at 2:11 AM, Jeffrey Lyon > wrote: > All, > > There a... > > uunet/vzb would/will > > (for free most times even) > From asr+nanog at latency.net Fri Jul 10 16:40:44 2009 From: asr+nanog at latency.net (Adam Rothschild) Date: Fri, 10 Jul 2009 17:40:44 -0400 Subject: BGP Growth projections In-Reply-To: <4A576F70.9010003@amplex.net> References: <4A576F70.9010003@amplex.net> Message-ID: <20090710214044.GB46088@latency.net> On 2009-07-10-12:42:24, Mark Radabaugh wrote: [...] > What projections are you using regarding the default free zone over the > next 5 years when picking new hardware? Geoff Huston, et al provide some useful trending: http://bgp.potaroo.net/index-bgp.html With that said, I've been treating hardware forwarding of 1MM v4 prefixes (or equivalent CAM carving of v6, MPLS, ...) as a minimum requirement for Internet-facing routers with a five-year shelf life. Platforms claiming in the 500-600k range seem prohibitive just tracking current v4 prefix growth, and moreso as v6 adaptation increases and end-users begin to realize that v4 and v6 routing is fundamentally the same, and begin to de-aggregate/advertise v6 space just like they do v4... -a From luan at netcraftsmen.net Fri Jul 10 16:49:29 2009 From: luan at netcraftsmen.net (Luan Nguyen) Date: Fri, 10 Jul 2009 17:49:29 -0400 Subject: Request for contact and procedure information In-Reply-To: <75cb24520907101440w1f8308f0n5132e5fede4450a1@mail.gmail.com> References: <4A566292.6030300@thewybles.com> <4A56BAEB.2030801@aset.com> <4A56BD4D.6050504@aset.com> <16720fe00907092311n1d28a7cs99e8259c544b90d@mail.gmail.com> <75cb24520907101410s3a88b35ek87edaaf896f992a7@mail.gmail.com> <16720fe00907101412n6fc9aabcg95f6051537f9d678@mail.gmail.com> <75cb24520907101440w1f8308f0n5132e5fede4450a1@mail.gmail.com> Message-ID: <020501ca01a8$4d03d230$e70b7690$@net> Filter like in using the Cisco Guard of sort, to send the good traffic back to the customers? And that service is free through vzb? -------------------------------------- Luan Nguyen Chesapeake NetCraftsmen, LLC. [Web] http://www.netcraftsmen.net -------------------------------------- -----Original Message----- From: Christopher Morrow [mailto:morrowc.lists at gmail.com] Sent: Friday, July 10, 2009 5:40 PM To: Jeffrey Lyon Cc: nanog at nanog.org; Charles Wyble Subject: Re: Request for contact and procedure information On Fri, Jul 10, 2009 at 5:12 PM, Jeffrey Lyon wrote: > Would what? Null route the IP? I'm talking about actually filtering the > attack. as was I. (talking about filtering the attack) > On Jul 10, 2009 5:10 PM, "Christopher Morrow" > wrote: > > On Fri, Jul 10, 2009 at 2:11 AM, Jeffrey Lyon > wrote: > All, > > There a... > > uunet/vzb would/will > > (for free most times even) > From jackson.tim at gmail.com Fri Jul 10 16:54:29 2009 From: jackson.tim at gmail.com (Tim Jackson) Date: Fri, 10 Jul 2009 16:54:29 -0500 Subject: OEMs for X2 10G LAN PHY optics In-Reply-To: <20090710212543.GA46088@latency.net> References: <80e7195b0907101121o15ee4e5ex4b16d29268db1bbf@mail.gmail.com> <20090710212543.GA46088@latency.net> Message-ID: <4407932e0907101454s42440912j614d63d95cbd79f4@mail.gmail.com> I second Adam's recommendation. Fluxlight has always been awesome to deal with. On 7/10/09, Adam Rothschild wrote: > On 2009-07-10-14:21:49, Duane Waddle wrote: >> I am searching for opinions on OEMs of X2 form factor 10G LAN PHY >> optics. We've found that most router/switch vendors mark these >> particular items up significantly just to provide their own >> sticker/EEPROM ID. As such, we'd prefer if we can to procure from the >> OEM (or their reseller). Is this a situation where any company who's >> a signatory to the MSA produces suitable modules, or are there >> particular OEMs to prefer (or avoid)? >> >> If it matters, the prime platform we're looking to plug optics into is >> the WS-X6708-10G module for a 6500/7600. > > I'd suggest looking at FluxLight (www.fluxlightinc.com) for this. > Their sales and support process is nothing short of stellar, and > pricing is a fair medium between "paying too much for vendor optics" > and "fly-by-night eBay imports". > > To wit, all of their products Just Worked without ever needing Cisco's > infamous 'service unsupported-transceiver' vendor lock override. > > -a > > -- Sent from my mobile device From cidr-report at potaroo.net Fri Jul 10 17:00:02 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 10 Jul 2009 22:00:02 GMT Subject: BGP Update Report Message-ID: <200907102200.n6AM02aD087697@wattle.apnic.net> BGP Update Report Interval: 02-Jul-09 -to- 09-Jul-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9198 96848 3.9% 320.7 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - AS6389 31411 1.3% 7.3 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 3 - AS8452 15773 0.6% 15.7 -- TEDATA TEDATA 4 - AS4323 15133 0.6% 3.5 -- TWTC - tw telecom holdings, inc. 5 - AS8151 13730 0.6% 9.3 -- Uninet S.A. de C.V. 6 - AS4755 12115 0.5% 9.9 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 7 - AS7018 11916 0.5% 7.9 -- ATT-INTERNET4 - AT&T WorldNet Services 8 - AS1785 11646 0.5% 6.8 -- AS-PAETEC-NET - PaeTec Communications, Inc. 9 - AS23700 11643 0.5% 28.2 -- BM-AS-ID PT. Broadband Multimedia, Tbk 10 - AS20115 11197 0.5% 7.9 -- CHARTER-NET-HKY-NC - Charter Communications 11 - AS21491 10627 0.4% 354.2 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 12 - AS17488 10563 0.4% 6.9 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 13 - AS47408 10524 0.4% 389.8 -- MANDARIN-AS Mandarin WIMAX Sicilia SpA 14 - AS33783 9292 0.4% 59.9 -- EEPAD 15 - AS2386 9270 0.4% 7.3 -- INS-AS - AT&T Data Communications Services 16 - AS29049 9007 0.4% 28.4 -- DELTA-TELECOM-AS Delta Telecom LTD. 17 - AS4766 8885 0.4% 4.9 -- KIXS-AS-KR Korea Telecom 18 - AS6478 8624 0.3% 7.1 -- ATT-INTERNET3 - AT&T WorldNet Services 19 - AS19262 8501 0.3% 8.3 -- VZGNI-TRANSIT - Verizon Internet Services Inc. 20 - AS17447 8466 0.3% 79.9 -- NET4INDIA Net4India Ltd. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS16611 3957 0.2% 3957.0 -- 2 - AS2 1232 0.1% 4.0 -- KAL-HK Two International Finance Centre 3 - AS30969 7642 0.3% 636.8 -- TAN-NET TransAfrica Networks 4 - AS37011 1898 0.1% 632.7 -- MSTARTEL-AS 5 - AS8599 562 0.0% 562.0 -- Ulyanovsk State University Network 6 - AS27653 2223 0.1% 555.8 -- Alpha Communications Network 7 - AS25546 4608 0.2% 460.8 -- BROOKLANDCOMP-AS Brookland Computer Services 8 - AS22783 2468 0.1% 411.3 -- WEBPOWER - WebPower, Inc. 9 - AS47408 10524 0.4% 389.8 -- MANDARIN-AS Mandarin WIMAX Sicilia SpA 10 - AS47640 1127 0.1% 375.7 -- TRICOMPAS Tricomp Sp. z. o. o. 11 - AS35400 2189 0.1% 364.8 -- MFIST Interregoinal Organization Network Technologies 12 - AS21491 10627 0.4% 354.2 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 13 - AS5050 5855 0.2% 344.4 -- PSC-EXT - Pittsburgh Supercomputing Center 14 - AS4796 327 0.0% 327.0 -- BANDUNG-NET-AS-AP Institute of Technology Bandung 15 - AS9198 96848 3.9% 320.7 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 16 - AS47350 320 0.0% 320.0 -- GCX-SYSTEMS-AS GCX Systems Ltd. 17 - AS36975 320 0.0% 320.0 -- CBA-AS 18 - AS33074 319 0.0% 319.0 -- ISC-NBO1 ISC, Nairobi, Kenya 19 - AS41904 1015 0.0% 253.8 -- SGAICE-AS JSC Severgazautomatica ICE 20 - AS42214 226 0.0% 226.0 -- IWC-AS SC International Work Company SRL TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 92.46.244.0/23 10617 0.4% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - 95.59.4.0/22 10583 0.4% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 3 - 95.59.3.0/24 10582 0.4% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 4 - 95.59.2.0/23 10582 0.4% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 5 - 95.59.8.0/23 10580 0.4% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 6 - 89.218.220.0/23 10578 0.4% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 7 - 89.218.218.0/23 10578 0.4% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 8 - 88.204.221.0/24 9950 0.4% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 9 - 95.59.1.0/24 9939 0.4% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 10 - 72.23.246.0/24 5730 0.2% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 11 - 193.201.184.0/21 4567 0.2% AS25546 -- BROOKLANDCOMP-AS Brookland Computer Services 12 - 216.9.95.0/24 3957 0.2% AS16611 -- 13 - 41.233.94.0/23 3950 0.2% AS8452 -- TEDATA TEDATA 14 - 41.233.92.0/23 3900 0.1% AS8452 -- TEDATA TEDATA 15 - 196.27.104.0/21 3142 0.1% AS30969 -- TAN-NET TransAfrica Networks 16 - 196.27.108.0/22 3113 0.1% AS30969 -- TAN-NET TransAfrica Networks 17 - 192.12.120.0/24 2399 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 18 - 72.42.193.0/24 2179 0.1% AS40060 -- AAAWI - AAA Wireless, Inc. 19 - 90.150.0.0/24 2127 0.1% AS35400 -- MFIST Interregoinal Organization Network Technologies 20 - 200.113.192.0/19 2006 0.1% AS27653 -- Alpha Communications Network Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 10 17:00:01 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 10 Jul 2009 22:00:01 GMT Subject: The Cidr Report Message-ID: <200907102200.n6AM01Rn087691@wattle.apnic.net> This report has been generated at Fri Jul 10 21:11:56 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 03-07-09 295814 183157 04-07-09 295958 183245 05-07-09 296123 183445 06-07-09 296112 182493 07-07-09 296178 183018 08-07-09 296083 183374 09-07-09 296233 177784 10-07-09 296253 178388 AS Summary 31812 Number of ASes in routing system 13509 Number of ASes announcing only one prefix 5232 Largest number of prefixes announced by an AS AS8151 : Uninet S.A. de C.V. 89665792 Largest address span announced by an AS (/32s) AS27064: DNIC-ASBLK-27032-27159 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 10Jul09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 300261 179180 121081 40.3% All ASes AS6389 4259 336 3923 92.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS8151 5232 1372 3860 73.8% Uninet S.A. de C.V. AS4323 4291 1635 2656 61.9% TWTC - tw telecom holdings, inc. AS4766 1809 525 1284 71.0% KIXS-AS-KR Korea Telecom AS17488 1536 305 1231 80.1% HATHWAY-NET-AP Hathway IP Over Cable Internet AS1785 1709 611 1098 64.2% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1217 193 1024 84.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1075 70 1005 93.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 1062 244 818 77.0% COVAD - Covad Communications Co. AS19262 1018 236 782 76.8% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8452 993 255 738 74.3% TEDATA TEDATA AS3356 1195 478 717 60.0% LEVEL3 Level 3 Communications AS18101 750 41 709 94.5% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS17908 688 51 637 92.6% TCISL Tata Communications AS4804 682 67 615 90.2% MPX-AS Microplex PTY LTD AS6478 1209 611 598 49.5% ATT-INTERNET3 - AT&T WorldNet Services AS11492 1127 531 596 52.9% CABLEONE - CABLE ONE, INC. AS855 623 64 559 89.7% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS9498 625 78 547 87.5% BBIL-AP BHARTI Airtel Ltd. AS4134 979 437 542 55.4% CHINANET-BACKBONE No.31,Jin-rong Street AS24560 725 192 533 73.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS22047 543 14 529 97.4% VTR BANDA ANCHA S.A. AS10620 923 400 523 56.7% TV Cable S.A. AS7303 590 93 497 84.2% Telecom Argentina S.A. AS17676 564 78 486 86.2% GIGAINFRA Softbank BB Corp. AS4808 660 180 480 72.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7018 1504 1051 453 30.1% ATT-INTERNET4 - AT&T WorldNet Services AS9443 528 83 445 84.3% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7011 986 570 416 42.2% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS5668 780 366 414 53.1% AS-5668 - CenturyTel Internet Holdings, Inc. Total 39882 11167 28715 72.0% Top 30 total Possible Bogus Routes 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.112.0/22 AS5713 SAIX-NET 41.223.176.0/22 AS36981 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.31.59.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.31.60.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 100.100.100.0/30 AS38676 AS33005-AS-KR wizsolution co.,Ltd 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.10.0/24 AS38236 121.50.13.0/24 AS38236 121.50.15.0/24 AS17625 BLAZENET-IN-AP BlazeNet's Network 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 137.0.0.0/13 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 158.222.5.0/24 AS21580 DIRCON - Direct Connect 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 168.253.0.0/16 AS13649 ASN-VINS - ViaWest 168.253.0.0/21 AS13649 ASN-VINS - ViaWest 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.132.58.0/24 AS20141 QUALITYTECH-SUW-300 - Quality Technology Services, LLC. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 193.33.148.0/23 AS30890 EVOLVA Evolva Telecom / iLink Telecom 193.104.229.0/26 AS34444 EUTELSAT-BACKBONE-AS EUTELSAT S.A. 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.5.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.19.0.0/24 AS3848 WORLDLINX-2 - WorldLinx Telecommunications, Inc. 199.114.0.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 ITCOMM - IT Communications 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.9.115.0/24 AS10292 CWJ-1 - Cable & Wireless Jamaica 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.84.10.0/23 AS9308 CHINA-ABITCOOL Abitcool(China) Inc. 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.92.48.0/20 AS23704 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS2764 AAPT AAPT Limited 202.124.195.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.125.112.0/24 AS23674 MBL-AS-AP Micronet Broadband (Pvt) Ltd. 202.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.152.154.0/23 AS9583 SIFY-AS-IN Sify Limited 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.13.140.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.141.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.142.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.143.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.138.167.0/24 AS18990 AIRBAND-DALLAS - Airband Communications, Inc 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.151.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.158.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.177.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.178.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.88.0/21 AS36835 208.77.224.0/24 AS36835 208.77.225.0/24 AS36835 208.77.226.0/24 AS36835 208.77.227.0/24 AS36835 208.77.228.0/24 AS36835 208.77.229.0/24 AS36835 208.77.230.0/24 AS36835 208.77.231.0/24 AS36835 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.217.224.0/19 AS6130 AIS-WEST - American Internet Services, LLC. 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 213.181.70.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.80.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.81.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.82.0/23 AS17175 NSS-UK New Skies Satellites UK AS 213.181.82.0/24 AS17175 NSS-UK New Skies Satellites UK AS 213.181.83.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.84.0/22 AS17175 NSS-UK New Skies Satellites UK AS 213.181.84.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.85.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.86.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.87.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.88.0/21 AS17175 NSS-UK New Skies Satellites UK AS 213.181.88.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.89.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.90.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.91.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.92.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.93.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.94.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.95.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.163.152.0/22 AS7132 SBIS-AS - AT&T Internet Services 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.72.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.73.0/24 AS12491 IPPLANET-AS Gilat Satcom Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From morrowc.lists at gmail.com Fri Jul 10 17:16:01 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 10 Jul 2009 18:16:01 -0400 Subject: Request for contact and procedure information In-Reply-To: <020501ca01a8$4d03d230$e70b7690$@net> References: <4A566292.6030300@thewybles.com> <4A56BAEB.2030801@aset.com> <4A56BD4D.6050504@aset.com> <16720fe00907092311n1d28a7cs99e8259c544b90d@mail.gmail.com> <75cb24520907101410s3a88b35ek87edaaf896f992a7@mail.gmail.com> <16720fe00907101412n6fc9aabcg95f6051537f9d678@mail.gmail.com> <75cb24520907101440w1f8308f0n5132e5fede4450a1@mail.gmail.com> <020501ca01a8$4d03d230$e70b7690$@net> Message-ID: <75cb24520907101516w6da0ec49xfc2b526cf5f44c43@mail.gmail.com> On Fri, Jul 10, 2009 at 5:49 PM, Luan Nguyen wrote: > Filter like in using the Cisco Guard of sort, to send the good traffic back > to the customers? And that service is free through vzb? as in: "find some way to keep the customer alive and kicking" which might be: 1) null route bad destination if no one cares about it 2) acl the traffic upstream if it's not to something you care about (but need the ip to work) 3) guard/mitigate traffic and redeliver (which has some limitations or did) all of that is free to 701 customers, yes. if you have to get to step3 more than a few times I'm sure sales will want you to pay, since that part isn't 'free' to the company. point being, dropping tcp/80 syn traffic isn't hard, and it's routinely done at customer request. (or was when I was doing it there) -chris ---------------------------------- > > > -----Original Message----- > From: Christopher Morrow [mailto:morrowc.lists at gmail.com] > Sent: Friday, July 10, 2009 5:40 PM > To: Jeffrey Lyon > Cc: nanog at nanog.org; Charles Wyble > Subject: Re: Request for contact and procedure information > > On Fri, Jul 10, 2009 at 5:12 PM, Jeffrey > Lyon wrote: >> Would what? Null route the IP? I'm talking about actually filtering the >> attack. > > as was I. (talking about filtering the attack) > >> On Jul 10, 2009 5:10 PM, "Christopher Morrow" >> wrote: >> >> On Fri, Jul 10, 2009 at 2:11 AM, Jeffrey Lyon >> wrote: > All, > > There a... >> >> uunet/vzb would/will >> >> (for free most times even) >> > > From jeffrey.lyon at blacklotus.net Fri Jul 10 17:38:53 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 10 Jul 2009 18:38:53 -0400 Subject: Request for contact and procedure information In-Reply-To: <75cb24520907101516w6da0ec49xfc2b526cf5f44c43@mail.gmail.com> References: <4A566292.6030300@thewybles.com> <4A56BAEB.2030801@aset.com> <4A56BD4D.6050504@aset.com> <16720fe00907092311n1d28a7cs99e8259c544b90d@mail.gmail.com> <75cb24520907101410s3a88b35ek87edaaf896f992a7@mail.gmail.com> <16720fe00907101412n6fc9aabcg95f6051537f9d678@mail.gmail.com> <75cb24520907101440w1f8308f0n5132e5fede4450a1@mail.gmail.com> <020501ca01a8$4d03d230$e70b7690$@net> <75cb24520907101516w6da0ec49xfc2b526cf5f44c43@mail.gmail.com> Message-ID: <16720fe00907101538t1fc02470o3bc4bd87e04db96d@mail.gmail.com> Fact: Filtering TCP/80 attacks is a 3 to 4 figure job, sometimes even 5 figure. Jeff On Fri, Jul 10, 2009 at 6:16 PM, Christopher Morrow wrote: > On Fri, Jul 10, 2009 at 5:49 PM, Luan Nguyen wrote: >> Filter like in using the Cisco Guard of sort, to send the good traffic back >> to the customers? And that service is free through vzb? > > as in: "find some way to keep the customer alive and kicking" > > which might be: > 1) null route bad destination if no one cares about it > 2) acl the traffic upstream if it's not to something you care about > (but need the ip to work) > 3) guard/mitigate traffic and redeliver (which has some limitations or did) > > all of that is free to 701 customers, yes. if you have to get to step3 > more than a few times I'm sure sales will want you to pay, since that > part isn't 'free' to the company. > > point being, dropping tcp/80 syn traffic isn't hard, and it's > routinely done at customer request. (or was when I was doing it there) > > -chris > > ---------------------------------- >> >> >> -----Original Message----- >> From: Christopher Morrow [mailto:morrowc.lists at gmail.com] >> Sent: Friday, July 10, 2009 5:40 PM >> To: Jeffrey Lyon >> Cc: nanog at nanog.org; Charles Wyble >> Subject: Re: Request for contact and procedure information >> >> On Fri, Jul 10, 2009 at 5:12 PM, Jeffrey >> Lyon wrote: >>> Would what? Null route the IP? I'm talking about actually filtering the >>> attack. >> >> as was I. (talking about filtering the attack) >> >>> On Jul 10, 2009 5:10 PM, "Christopher Morrow" >>> wrote: >>> >>> On Fri, Jul 10, 2009 at 2:11 AM, Jeffrey Lyon >>> wrote: > All, > > There a... >>> >>> uunet/vzb would/will >>> >>> (for free most times even) >>> >> >> > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From sethm at rollernet.us Fri Jul 10 20:24:34 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 10 Jul 2009 18:24:34 -0700 Subject: Delay BGP peer session Message-ID: <4A57E9D2.6000209@rollernet.us> Is there any way to force a delay on a BGP session from establishing when a link comes up? Say, for example, if a link flaps and fast-external-fallover takes it down we should wait X minutes before trying to bring the session back up. ~Seth From sethm at rollernet.us Fri Jul 10 20:25:17 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 10 Jul 2009 18:25:17 -0700 Subject: Delay BGP peer session In-Reply-To: <4A57E9D2.6000209@rollernet.us> References: <4A57E9D2.6000209@rollernet.us> Message-ID: <4A57E9FD.7040406@rollernet.us> Seth Mattinen wrote: > Is there any way to force a delay on a BGP session from establishing > when a link comes up? Say, for example, if a link flaps and > fast-external-fallover takes it down we should wait X minutes before > trying to bring the session back up. > Dammit, that was supposed to go to cisco nsp. Sorry! ~Seth From morrowc.lists at gmail.com Fri Jul 10 21:57:10 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 10 Jul 2009 22:57:10 -0400 Subject: Request for contact and procedure information In-Reply-To: <16720fe00907101538t1fc02470o3bc4bd87e04db96d@mail.gmail.com> References: <4A566292.6030300@thewybles.com> <4A56BAEB.2030801@aset.com> <4A56BD4D.6050504@aset.com> <16720fe00907092311n1d28a7cs99e8259c544b90d@mail.gmail.com> <75cb24520907101410s3a88b35ek87edaaf896f992a7@mail.gmail.com> <16720fe00907101412n6fc9aabcg95f6051537f9d678@mail.gmail.com> <75cb24520907101440w1f8308f0n5132e5fede4450a1@mail.gmail.com> <020501ca01a8$4d03d230$e70b7690$@net> <75cb24520907101516w6da0ec49xfc2b526cf5f44c43@mail.gmail.com> <16720fe00907101538t1fc02470o3bc4bd87e04db96d@mail.gmail.com> Message-ID: <75cb24520907101957t56845e9ci4d5608d50f20e9c@mail.gmail.com> On Fri, Jul 10, 2009 at 6:38 PM, Jeffrey Lyon wrote: > Fact: Filtering TCP/80 attacks is a 3 to 4 figure job, sometimes even 5 figure. I was actually being serious, it's not, it doesn't have to, and in the case that started this discussion it probably would have been sufficient to just drop tcp/80 to his link since I would be it's 'business dsl' so he gets an 'SLA' not so he can run a business critical web service there. There are services you can buy that are a lot more expensive, but why would you? if there are options that are more relevant and cheaper... and in line with what you want. You can certainly pay more if you want to, I'm not sure that's the smart choice though. -Chris > On Fri, Jul 10, 2009 at 6:16 PM, Christopher > Morrow wrote: >> On Fri, Jul 10, 2009 at 5:49 PM, Luan Nguyen wrote: >>> Filter like in using the Cisco Guard of sort, to send the good traffic back >>> to the customers? And that service is free through vzb? >> >> as in: "find some way to keep the customer alive and kicking" >> >> which might be: >> 1) null route bad destination if no one cares about it >> 2) acl the traffic upstream if it's not to something you care about >> (but need the ip to work) >> 3) guard/mitigate traffic and redeliver (which has some limitations or did) >> >> all of that is free to 701 customers, yes. if you have to get to step3 >> more than a few times I'm sure sales will want you to pay, since that >> part isn't 'free' to the company. >> >> point being, dropping tcp/80 syn traffic isn't hard, and it's >> routinely done at customer request. (or was when I was doing it there) >> >> -chris >> >> ---------------------------------- >>> >>> >>> -----Original Message----- >>> From: Christopher Morrow [mailto:morrowc.lists at gmail.com] >>> Sent: Friday, July 10, 2009 5:40 PM >>> To: Jeffrey Lyon >>> Cc: nanog at nanog.org; Charles Wyble >>> Subject: Re: Request for contact and procedure information >>> >>> On Fri, Jul 10, 2009 at 5:12 PM, Jeffrey >>> Lyon wrote: >>>> Would what? Null route the IP? I'm talking about actually filtering the >>>> attack. >>> >>> as was I. (talking about filtering the attack) >>> >>>> On Jul 10, 2009 5:10 PM, "Christopher Morrow" >>>> wrote: >>>> >>>> On Fri, Jul 10, 2009 at 2:11 AM, Jeffrey Lyon >>>> wrote: > All, > > There a... >>>> >>>> uunet/vzb would/will >>>> >>>> (for free most times even) >>>> >>> >>> >> > > > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications of The IRC Company, Inc. > > Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th > at Booth #401. > From jeffrey.lyon at blacklotus.net Fri Jul 10 22:06:11 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 10 Jul 2009 23:06:11 -0400 Subject: Request for contact and procedure information In-Reply-To: <75cb24520907101957t56845e9ci4d5608d50f20e9c@mail.gmail.com> References: <4A566292.6030300@thewybles.com> <4A56BD4D.6050504@aset.com> <16720fe00907092311n1d28a7cs99e8259c544b90d@mail.gmail.com> <75cb24520907101410s3a88b35ek87edaaf896f992a7@mail.gmail.com> <16720fe00907101412n6fc9aabcg95f6051537f9d678@mail.gmail.com> <75cb24520907101440w1f8308f0n5132e5fede4450a1@mail.gmail.com> <020501ca01a8$4d03d230$e70b7690$@net> <75cb24520907101516w6da0ec49xfc2b526cf5f44c43@mail.gmail.com> <16720fe00907101538t1fc02470o3bc4bd87e04db96d@mail.gmail.com> <75cb24520907101957t56845e9ci4d5608d50f20e9c@mail.gmail.com> Message-ID: <16720fe00907102006y1c74aa6em253ca4b5dcd159f9@mail.gmail.com> I don't know of any internet access services that provide a SLA against DDoS. Jeff On Fri, Jul 10, 2009 at 10:57 PM, Christopher Morrow wrote: > On Fri, Jul 10, 2009 at 6:38 PM, Jeffrey > Lyon wrote: >> Fact: Filtering TCP/80 attacks is a 3 to 4 figure job, sometimes even 5 figure. > > I was actually being serious, it's not, it doesn't have to, and in the > case that started this discussion it probably would have been > sufficient to just drop tcp/80 to his link since I would be it's > 'business dsl' so he gets an 'SLA' not so he can run a business > critical web service there. > > There are services you can buy that are a lot more expensive, but why > would you? if there are options that are more relevant and cheaper... > and in line with what you want. You can certainly pay more if you want > to, I'm not sure that's the smart choice though. > > -Chris > >> On Fri, Jul 10, 2009 at 6:16 PM, Christopher >> Morrow wrote: >>> On Fri, Jul 10, 2009 at 5:49 PM, Luan Nguyen wrote: >>>> Filter like in using the Cisco Guard of sort, to send the good traffic back >>>> to the customers? And that service is free through vzb? >>> >>> as in: "find some way to keep the customer alive and kicking" >>> >>> which might be: >>> 1) null route bad destination if no one cares about it >>> 2) acl the traffic upstream if it's not to something you care about >>> (but need the ip to work) >>> 3) guard/mitigate traffic and redeliver (which has some limitations or did) >>> >>> all of that is free to 701 customers, yes. if you have to get to step3 >>> more than a few times I'm sure sales will want you to pay, since that >>> part isn't 'free' to the company. >>> >>> point being, dropping tcp/80 syn traffic isn't hard, and it's >>> routinely done at customer request. (or was when I was doing it there) >>> >>> -chris >>> >>> ---------------------------------- >>>> >>>> >>>> -----Original Message----- >>>> From: Christopher Morrow [mailto:morrowc.lists at gmail.com] >>>> Sent: Friday, July 10, 2009 5:40 PM >>>> To: Jeffrey Lyon >>>> Cc: nanog at nanog.org; Charles Wyble >>>> Subject: Re: Request for contact and procedure information >>>> >>>> On Fri, Jul 10, 2009 at 5:12 PM, Jeffrey >>>> Lyon wrote: >>>>> Would what? Null route the IP? I'm talking about actually filtering the >>>>> attack. >>>> >>>> as was I. (talking about filtering the attack) >>>> >>>>> On Jul 10, 2009 5:10 PM, "Christopher Morrow" >>>>> wrote: >>>>> >>>>> On Fri, Jul 10, 2009 at 2:11 AM, Jeffrey Lyon >>>>> wrote: > All, > > There a... >>>>> >>>>> uunet/vzb would/will >>>>> >>>>> (for free most times even) >>>>> >>>> >>>> >>> >> >> >> >> -- >> Jeffrey Lyon, Leadership Team >> jeffrey.lyon at blacklotus.net | http://www.blacklotus.net >> Black Lotus Communications of The IRC Company, Inc. >> >> Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th >> at Booth #401. >> > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From morrowc.lists at gmail.com Fri Jul 10 22:13:16 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 10 Jul 2009 23:13:16 -0400 Subject: Request for contact and procedure information In-Reply-To: <16720fe00907102006y1c74aa6em253ca4b5dcd159f9@mail.gmail.com> References: <4A566292.6030300@thewybles.com> <16720fe00907092311n1d28a7cs99e8259c544b90d@mail.gmail.com> <75cb24520907101410s3a88b35ek87edaaf896f992a7@mail.gmail.com> <16720fe00907101412n6fc9aabcg95f6051537f9d678@mail.gmail.com> <75cb24520907101440w1f8308f0n5132e5fede4450a1@mail.gmail.com> <020501ca01a8$4d03d230$e70b7690$@net> <75cb24520907101516w6da0ec49xfc2b526cf5f44c43@mail.gmail.com> <16720fe00907101538t1fc02470o3bc4bd87e04db96d@mail.gmail.com> <75cb24520907101957t56845e9ci4d5608d50f20e9c@mail.gmail.com> <16720fe00907102006y1c74aa6em253ca4b5dcd159f9@mail.gmail.com> Message-ID: <75cb24520907102013v3ff16bcga9e01259c8aaf36e@mail.gmail.com> On Fri, Jul 10, 2009 at 11:06 PM, Jeffrey Lyon wrote: > I don't know of any internet access services that provide a SLA against DDoS. vzb/mci/uunet used to, there is (I believe) still a 'response' SLA, and there was an SLA for their dos-mitigation service as well...likely somewhere off: http://www.verizonbusiness.com/us/products/security/managed/#services-dos I was actually talking about an SLA for his link though, not for dos-mitigation services. There used to be, and still is in some networks, the thought that consumer grade services were essentially 'un-SLA''d, while 'business class' services had some form of 'uptime' SLA associated with them. So, folks that telework often subscribe to 'business dsl' in order to get more guaranteed availabilty, lack of port filtering, static-ips, etc. -Chris > Jeff > > On Fri, Jul 10, 2009 at 10:57 PM, Christopher > Morrow wrote: >> On Fri, Jul 10, 2009 at 6:38 PM, Jeffrey >> Lyon wrote: >>> Fact: Filtering TCP/80 attacks is a 3 to 4 figure job, sometimes even 5 figure. >> >> I was actually being serious, it's not, it doesn't have to, and in the >> case that started this discussion it probably would have been >> sufficient to just drop tcp/80 to his link since I would be it's >> 'business dsl' so he gets an 'SLA' not so he can run a business >> critical web service there. >> >> There are services you can buy that are a lot more expensive, but why >> would you? if there are options that are more relevant and cheaper... >> and in line with what you want. You can certainly pay more if you want >> to, I'm not sure that's the smart choice though. >> >> -Chris >> >>> On Fri, Jul 10, 2009 at 6:16 PM, Christopher >>> Morrow wrote: >>>> On Fri, Jul 10, 2009 at 5:49 PM, Luan Nguyen wrote: >>>>> Filter like in using the Cisco Guard of sort, to send the good traffic back >>>>> to the customers? And that service is free through vzb? >>>> >>>> as in: "find some way to keep the customer alive and kicking" >>>> >>>> which might be: >>>> 1) null route bad destination if no one cares about it >>>> 2) acl the traffic upstream if it's not to something you care about >>>> (but need the ip to work) >>>> 3) guard/mitigate traffic and redeliver (which has some limitations or did) >>>> >>>> all of that is free to 701 customers, yes. if you have to get to step3 >>>> more than a few times I'm sure sales will want you to pay, since that >>>> part isn't 'free' to the company. >>>> >>>> point being, dropping tcp/80 syn traffic isn't hard, and it's >>>> routinely done at customer request. (or was when I was doing it there) >>>> >>>> -chris >>>> >>>> ---------------------------------- >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Christopher Morrow [mailto:morrowc.lists at gmail.com] >>>>> Sent: Friday, July 10, 2009 5:40 PM >>>>> To: Jeffrey Lyon >>>>> Cc: nanog at nanog.org; Charles Wyble >>>>> Subject: Re: Request for contact and procedure information >>>>> >>>>> On Fri, Jul 10, 2009 at 5:12 PM, Jeffrey >>>>> Lyon wrote: >>>>>> Would what? Null route the IP? I'm talking about actually filtering the >>>>>> attack. >>>>> >>>>> as was I. (talking about filtering the attack) >>>>> >>>>>> On Jul 10, 2009 5:10 PM, "Christopher Morrow" >>>>>> wrote: >>>>>> >>>>>> On Fri, Jul 10, 2009 at 2:11 AM, Jeffrey Lyon >>>>>> wrote: > All, > > There a... >>>>>> >>>>>> uunet/vzb would/will >>>>>> >>>>>> (for free most times even) >>>>>> >>>>> >>>>> >>>> >>> >>> >>> >>> -- >>> Jeffrey Lyon, Leadership Team >>> jeffrey.lyon at blacklotus.net | http://www.blacklotus.net >>> Black Lotus Communications of The IRC Company, Inc. >>> >>> Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th >>> at Booth #401. >>> >> > > > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications of The IRC Company, Inc. > > Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th > at Booth #401. > From hrlinneweh at sbcglobal.net Fri Jul 10 23:50:51 2009 From: hrlinneweh at sbcglobal.net (Henry Linneweh) Date: Fri, 10 Jul 2009 21:50:51 -0700 (PDT) Subject: Request for contact and procedure information In-Reply-To: <4A566292.6030300@thewybles.com> References: <4A566292.6030300@thewybles.com> Message-ID: <480402.58708.qm@web180315.mail.gq1.yahoo.com> Charles; SBC belongs to AT&T which has a ddos mitigation offering http://www.business.att.com/content/productbrochures/PB-DDoS_16651_v1_6-27-08.pdf Verizon also has such an offering under Managed Services Security Solutions Powered by Cybertrust a company they bought http://www.verizonbusiness.com/us/products/security/managed/#services-dos ________________________________ From: Charles Wyble To: "nanog at nanog.org" Sent: Thursday, July 9, 2009 2:35:14 PM Subject: Request for contact and procedure information All, I'm currently experiencing a DDOS attack on my home DSL connection. Thousands of requests to port 80. I'm on an SBC business class account. I'm guessing that calling the regular customer support won't get me anywhere. Any suggestions? From ip at ioshints.info Sat Jul 11 02:27:08 2009 From: ip at ioshints.info (Ivan Pepelnjak) Date: Sat, 11 Jul 2009 09:27:08 +0200 Subject: BGP Growth projections In-Reply-To: <4A576F70.9010003@amplex.net> References: <4A576F70.9010003@amplex.net> Message-ID: <00fb01ca01f9$00b8dc80$0a00000a@nil.si> Let me be the devil's advocate: why would you need full Internet routing? Taking reasonably sized neighborhoods of your upstreams (AS paths up to X AS numbers) plus a default to your best upstream might do the trick. Ivan http://www.ioshints.info/about http://blog.ioshints.info/ > -----Original Message----- > From: Mark Radabaugh [mailto:mark at amplex.net] > Sent: Friday, July 10, 2009 6:42 PM > To: nanog list > Subject: BGP Growth projections > > I'm looking for new core routers for a small ISP and having a > hard time > finding something appropriate and reasonably priced. We don't have > huge traffic levels (<1Gb) and are mostly running Ethernet > interfaces to > upstreams rather than legacy interfaces (when did OC3 become > legacy?). > > Lot's of choices for routers that can handle the existing BGP > tables - but not so much in small platforms (1-10Gb traffic) > if you assume that > IPv6 is going to explode the routing table in the next 5 > years. The > manufacturers still seem to think low traffic routers don't > need much memory or CPU. > > What projections are you using regarding the default free > zone over the next 5 years when picking new hardware? > > -- > > Mark Radabaugh > Amplex > 419.837.5015 x21 > mark at amplex.net > > > > From william.allen.simpson at gmail.com Sat Jul 11 03:39:44 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Sat, 11 Jul 2009 04:39:44 -0400 Subject: Point to Point Ethernet In-Reply-To: <4A579AA8.4070102@zcorum.com> References: <4A546E70.9090604@nrg4u.com> <2e9d8ae50907081604uabbba04wb285a40c7c66f102@mail.gmail.com> <20090709.083412.74715921.sthaug@nethelp.no> <70D072392E56884193E3D2DE09C097A91F427B@pascal.zaphodb.org> <71c13900907090729q5a6cc243s27aafd06d67ce288@mail.gmail.com> <4fff97de0907091333h6cb58f5drada2a0265f51e9b6@mail.gmail.com> <20090710153848.GB1049002@hiwaay.net> <4A5762B9.7050009@rollernet.us> <4A579AA8.4070102@zcorum.com> Message-ID: <4A584FD0.2040802@gmail.com> Brian Raaen wrote: > Hate to say it, but also some of the cost on the circuits can be blamed > on uncle Sam. ATM circuits are currently tariffed that same way are > voice circuits. These tariffs are not charged to Ethernet because it is > a 'data circuit'. At least that was the case a little while back. > Are you sure it's "Uncle Sam"? My experience is that voice tariffs are always cheaper than data; telco's mantra is still "I Smell Dollars Now". The telcos were mightily pissed when we redesigned protocols to pass over voice circuits instead of requiring data circuits. Usually, non-tariffed lines seem to be much more expensive, as the account manager says "Oh, that special order will have to be approved by HQ". From tom.ammon at utah.edu Sat Jul 11 03:39:56 2009 From: tom.ammon at utah.edu (Tom Ammon) Date: Sat, 11 Jul 2009 02:39:56 -0600 Subject: troubles with UTOPIA / Veracity network in Utah? Message-ID: <4A584FDC.2050705@utah.edu> I'm wondering if anyone has any experience with UTOPIA or Veracity out in Utah, specifically if they are known for frequent unannounced maintenance outages and/or crappy network uptime? I'm having problems getting a scheduled data transfer to run on a pretty regular basis and am trying to figure out where the issue is. Thanks, Tom From Rod.Beck at hiberniaatlantic.com Sat Jul 11 06:02:59 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Sat, 11 Jul 2009 12:02:59 +0100 Subject: [SPAM-HEADER] - Re: Point to Point Ethernet - Email has different SMTP TO: and MIME TO: fields in the email addresses References: <4A546E70.9090604@nrg4u.com> <2e9d8ae50907081604uabbba04wb285a40c7c66f102@mail.gmail.com><20090709.083412.74715921.sthaug@nethelp.no><70D072392E56884193E3D2DE09C097A91F427B@pascal.zaphodb.org><71c13900907090729q5a6cc243s27aafd06d67ce288@mail.gmail.com><4fff97de0907091333h6cb58f5drada2a0265f51e9b6@mail.gmail.com><20090710153848.GB1049002@hiwaay.net><4A5762B9.7050009@rollernet.us><4A579AA8.4070102@zcorum.com> <4A584FD0.2040802@gmail.com> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB016283A3@bert.HiberniaAtlantic.local> Brian Raaen wrote: >> Hate to say it, but also some of the cost on the circuits can be blamed >> on uncle Sam. ATM circuits are currently tariffed that same way are >> voice circuits. These tariffs are not charged to Ethernet because it is >> a 'data circuit'. At least that was the case a little while back. >? >Are you sure it's "Uncle Sam"? My experience is that voice tariffs are >always cheaper than data; telco's mantra is still "I Smell Dollars Now". >The telcos were mightily pissed when we redesigned protocols to pass over >voice circuits instead of requiring data circuits. >Usually, non-tariffed lines seem to be much more expensive, as the account >manager says "Oh, that special order will have to be approved by HQ". Strictly speaking, it's not Uncle Sam, but the PUCs who review the tariffs. I would view it fundamentally as a lack of competition. Who can provide ATM backhaul from central offices? In many cases just the incumbent. Roderick S. Beck Director of European Sales Hibernia Atlantic From Rod.Beck at hiberniaatlantic.com Sat Jul 11 07:18:22 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Sat, 11 Jul 2009 13:18:22 +0100 Subject: Point to Point Ethernet References: <4A546E70.9090604@nrg4u.com><2e9d8ae50907081604uabbba04wb285a40c7c66f102@mail.gmail.com><20090709.083412.74715921.sthaug@nethelp.no><70D072392E56884193E3D2DE09C097A91F427B@pascal.zaphodb.org><71c13900907090729q5a6cc243s27aafd06d67ce288@mail.gmail.com><4fff97de0907091333h6cb58f5drada2a0265f51e9b6@mail.gmail.com> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB016283B0@bert.HiberniaAtlantic.local> Prices of terrestrial SDH/SONET cards are very low for transport providers. For customers I believe there is a greater divergenc between the Ethernet and SONET/SDH costs. A strong hunch based on what clients tell me Cisco charges for SONET/SDH interfaces. Roderick S. Beck Director of European Sales Hibernia Atlantic 13-15, rue Sedaine, 75011 Paris http://www.hiberniaatlantic.com Wireless: 33+6+8692+5357. French Landline: 33+1+4355+8224 AOL Messenger: GlobalBandwidth rod.beck at hiberniaatlantic.com info at globalwholesalebandwidht.com ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein. From setient at gmail.com Sat Jul 11 09:20:25 2009 From: setient at gmail.com (Ronald Cotoni) Date: Sat, 11 Jul 2009 09:20:25 -0500 Subject: Can someone from SORBS contact me offlist? Message-ID: <2f1d68350907110720r3cf5206bje455d01f35b41d10@mail.gmail.com> I need to resolve some issues that we are having with you guys but there is a lack of timelyness with your contact forms, 28 days is simply unacceptable :( From ops.lists at gmail.com Sat Jul 11 09:30:32 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 11 Jul 2009 20:00:32 +0530 Subject: Can someone from SORBS contact me offlist? In-Reply-To: <2f1d68350907110720r3cf5206bje455d01f35b41d10@mail.gmail.com> References: <2f1d68350907110720r3cf5206bje455d01f35b41d10@mail.gmail.com> Message-ID: Sorbs was shut down just about that time ago .. On Sat, Jul 11, 2009 at 7:50 PM, Ronald Cotoni wrote: > I need to resolve some issues that we are having with you guys but there is > a lack of timelyness with your contact forms, 28 days is simply unacceptable > :( > -- Suresh Ramasubramanian (ops.lists at gmail.com) From sethm at rollernet.us Sat Jul 11 11:07:19 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 11 Jul 2009 09:07:19 -0700 Subject: Can someone from SORBS contact me offlist? In-Reply-To: <2f1d68350907110720r3cf5206bje455d01f35b41d10@mail.gmail.com> References: <2f1d68350907110720r3cf5206bje455d01f35b41d10@mail.gmail.com> Message-ID: <4A58B8B7.20809@rollernet.us> Ronald Cotoni wrote: > I need to resolve some issues that we are having with you guys but there is > a lack of timelyness with your contact forms, 28 days is simply unacceptable > :( You might also try on the spam-l.org mailing list. ~Seth From morrowc.lists at gmail.com Sat Jul 11 11:08:30 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 11 Jul 2009 12:08:30 -0400 Subject: Can someone from SORBS contact me offlist? In-Reply-To: <2f1d68350907110720r3cf5206bje455d01f35b41d10@mail.gmail.com> References: <2f1d68350907110720r3cf5206bje455d01f35b41d10@mail.gmail.com> Message-ID: <75cb24520907110908y2314f872gc505765f26cb6d90@mail.gmail.com> On Sat, Jul 11, 2009 at 10:20 AM, Ronald Cotoni wrote: > I need to resolve some issues that we are having with you guys but there is > a lack of timelyness with your contact forms, 28 days is simply unacceptable > :( >From www.sorbs.net: "It comes with great sadness that I have to announce the imminent closure of SORBS. The University of Queensland have decided not to honor their agreement with myself and SORBS and terminate the hosting contract. I have been involved with institutions such as Griffith University trying to arrange alternative hosting for SORBS, but as of 12 noon, 22nd June 2009 no hosting has been acquired and therefore I have been forced in to this announcement. SORBS is officially "For Sale" should anyone wish to purchase it as a going concern, but failing that and failing to find alternative hosting for a 42RU rack in the Brisbane area of Queensland Australia SORBS will be shutting down permanently in 28 days, on 20th July 2009 at 12 noon." uhm, I dont think they care to help... -chris From mysidia at gmail.com Sat Jul 11 11:34:58 2009 From: mysidia at gmail.com (James Hess) Date: Sat, 11 Jul 2009 11:34:58 -0500 Subject: Can someone from SORBS contact me offlist? In-Reply-To: <75cb24520907110908y2314f872gc505765f26cb6d90@mail.gmail.com> References: <2f1d68350907110720r3cf5206bje455d01f35b41d10@mail.gmail.com> <75cb24520907110908y2314f872gc505765f26cb6d90@mail.gmail.com> Message-ID: <6eb799ab0907110934i42b1ef89n5374b0cb2801ffb4@mail.gmail.com> On Sat, Jul 11, 2009 at 11:08 AM, Christopher Morrow wrote: > >From www.sorbs.net: > "It comes with great sadness that I have to announce the imminent [snip] You might want to read the June 25th update they made to the announcement, as shown on the very same page. " SORBS has had 2 offers of hosting within the Queensland/North New South Wales area, one of which is by a top hosting company in Australia. The result is at this present time I, Michelle Sullivan, feel that SORBS will not close on the date specified, though there maybe some small outages around this time. " By all appearances SORBS is still completely operational, they have not shutdown, and every indication now is that they are probably not going to shut down. -- -J From john-nanog at johnpeach.com Sat Jul 11 11:45:33 2009 From: john-nanog at johnpeach.com (John Peach) Date: Sat, 11 Jul 2009 12:45:33 -0400 Subject: Can someone from SORBS contact me offlist? In-Reply-To: <6eb799ab0907110934i42b1ef89n5374b0cb2801ffb4@mail.gmail.com> References: <2f1d68350907110720r3cf5206bje455d01f35b41d10@mail.gmail.com> <75cb24520907110908y2314f872gc505765f26cb6d90@mail.gmail.com> <6eb799ab0907110934i42b1ef89n5374b0cb2801ffb4@mail.gmail.com> Message-ID: <20090711124533.39ac39fa@milhouse.peachfamily.net> On Sat, 11 Jul 2009 11:34:58 -0500 James Hess wrote: > On Sat, Jul 11, 2009 at 11:08 AM, Christopher > Morrow wrote: > > >From www.sorbs.net: > > "It comes with great sadness that I have to announce the imminent > [snip] > > You might want to read the June 25th update they made to the > announcement, as shown on the very same page. > SORBS has never had a good reputation over removals.......... -- John From setient at gmail.com Sat Jul 11 12:05:53 2009 From: setient at gmail.com (Ronald Cotoni) Date: Sat, 11 Jul 2009 12:05:53 -0500 Subject: Can someone from SORBS contact me offlist? In-Reply-To: <20090711124533.39ac39fa@milhouse.peachfamily.net> References: <2f1d68350907110720r3cf5206bje455d01f35b41d10@mail.gmail.com> <75cb24520907110908y2314f872gc505765f26cb6d90@mail.gmail.com> <6eb799ab0907110934i42b1ef89n5374b0cb2801ffb4@mail.gmail.com> <20090711124533.39ac39fa@milhouse.peachfamily.net> Message-ID: <2f1d68350907111005m50bc2a98o756313fa3a90e640@mail.gmail.com> Yes, they are really bad. It is actually quite silly that a blacklisting service is that slow on responding to problems. On Sat, Jul 11, 2009 at 11:45 AM, John Peach wrote: > On Sat, 11 Jul 2009 11:34:58 -0500 > James Hess wrote: > > > On Sat, Jul 11, 2009 at 11:08 AM, Christopher > > Morrow wrote: > > > >From www.sorbs.net: > > > "It comes with great sadness that I have to announce the imminent > > [snip] > > > > You might want to read the June 25th update they made to the > > announcement, as shown on the very same page. > > > > SORBS has never had a good reputation over removals.......... > > -- > John > > From bruns at 2mbit.com Sat Jul 11 12:11:41 2009 From: bruns at 2mbit.com (Brielle Bruns) Date: Sat, 11 Jul 2009 11:11:41 -0600 Subject: Can someone from SORBS contact me offlist? In-Reply-To: <2f1d68350907111005m50bc2a98o756313fa3a90e640@mail.gmail.com> References: <2f1d68350907110720r3cf5206bje455d01f35b41d10@mail.gmail.com> <75cb24520907110908y2314f872gc505765f26cb6d90@mail.gmail.com> <6eb799ab0907110934i42b1ef89n5374b0cb2801ffb4@mail.gmail.com> <20090711124533.39ac39fa@milhouse.peachfamily.net> <2f1d68350907111005m50bc2a98o756313fa3a90e640@mail.gmail.com> Message-ID: <4A58C7CD.30501@2mbit.com> On 7/11/09 11:05 AM, Ronald Cotoni wrote: > Yes, they are really bad. It is actually quite silly that a blacklisting > service is that slow on responding to problems. I find it unacceptable that people demand instant service from a company they don't have prior business arrangements/relationship with. Average turn around time for the AHBL is around two weeks if we don't have an established contact and procedure with. How would you like it if a non-customer came to you demanding resolution to a problem with a free service you provide? Would you drop everything, and give that non-customer the same service you give a paying customer? -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From patrick at ianai.net Sat Jul 11 13:47:03 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 11 Jul 2009 14:47:03 -0400 Subject: Can someone from SORBS contact me offlist? In-Reply-To: <4A58C7CD.30501@2mbit.com> References: <2f1d68350907110720r3cf5206bje455d01f35b41d10@mail.gmail.com> <75cb24520907110908y2314f872gc505765f26cb6d90@mail.gmail.com> <6eb799ab0907110934i42b1ef89n5374b0cb2801ffb4@mail.gmail.com> <20090711124533.39ac39fa@milhouse.peachfamily.net> <2f1d68350907111005m50bc2a98o756313fa3a90e640@mail.gmail.com> <4A58C7CD.30501@2mbit.com> Message-ID: On Jul 11, 2009, at 1:11 PM, Brielle Bruns wrote: > On 7/11/09 11:05 AM, Ronald Cotoni wrote: >> Yes, they are really bad. It is actually quite silly that a >> blacklisting >> service is that slow on responding to problems. > > I find it unacceptable that people demand instant service from a > company they don't have prior business arrangements/relationship > with. Average turn around time for the AHBL is around two weeks if > we don't have an established contact and procedure with. > > How would you like it if a non-customer came to you demanding > resolution to a problem with a free service you provide? Would you > drop everything, and give that non-customer the same service you > give a paying customer? I don't see any demands there. I see someone commenting on the utility of the "free service" offered. If a blacklist, free or not, lists good IP addresses and takes a long time to remove them, then the blacklist is not useful. Given that you said AHBL requires two weeks to remove good IP addresses unless there is an "established contact", I'll be sure never to use said list. Suppose my business partner gets listed? Am I to ruin our relationship for two weeks because you are busy or don't like the fact we don't pay you? We didn't pay you to list us either. Besides, there are plenty of useful blacklists with very low FP rates who are responsive. Why use one that has high FP and is unresponsive? Running a blacklist sucks. It's got to be one of the hardest jobs for a white-hat to do on the 'Net. But if you don't like it, don't do it. Doing it then complaining about it after is .. silly. -- TTFN< patrick From johns at sstar.com Sat Jul 11 13:50:37 2009 From: johns at sstar.com (John Souvestre) Date: Sat, 11 Jul 2009 13:50:37 -0500 Subject: Can someone from SORBS contact me offlist? In-Reply-To: <4A58C7CD.30501@2mbit.com> References: <2f1d68350907110720r3cf5206bje455d01f35b41d10@mail.gmail.com> <75cb24520907110908y2314f872gc505765f26cb6d90@mail.gmail.com> <6eb799ab0907110934i42b1ef89n5374b0cb2801ffb4@mail.gmail.com> <20090711124533.39ac39fa@milhouse.peachfamily.net><2f1d68350907111005m50bc2a98o756313fa3a90e640@mail.gmail.com> <4A58C7CD.30501@2mbit.com> Message-ID: <3F86F62FEDED4504BEF7698473D09541@JohnS> Hi Brielle. Do they take two weeks to put a spammer on the list? Regards, John John Souvestre - New Orleans LA > -----Original Message----- > From: Brielle Bruns [mailto:bruns at 2mbit.com] > Sent: Saturday, July 11, 2009 12:12 PM > To: nanog at nanog.org > Subject: Re: Can someone from SORBS contact me offlist? > > On 7/11/09 11:05 AM, Ronald Cotoni wrote: > > Yes, they are really bad. It is actually quite silly that a blacklisting > > service is that slow on responding to problems. > > I find it unacceptable that people demand instant service from a company > they don't have prior business arrangements/relationship with. Average > turn around time for the AHBL is around two weeks if we don't have an > established contact and procedure with. > > How would you like it if a non-customer came to you demanding resolution > to a problem with a free service you provide? Would you drop > everything, and give that non-customer the same service you give a > paying customer? > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org From nuno.vieira at nfsi.pt Sat Jul 11 13:44:20 2009 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi) Date: Sat, 11 Jul 2009 19:44:20 +0100 (WEST) Subject: Can someone from SORBS contact me offlist? In-Reply-To: <4A58C7CD.30501@2mbit.com> Message-ID: <1580048455.102171247337860133.JavaMail.root@zimbra.nfsi.pt> That's good to know. I'll avoid using it. --nvieira ----- "Brielle Bruns" wrote: > Average turn around time for the AHBL is around two weeks if we don't have an > established contact and procedure with. From setient at gmail.com Sat Jul 11 13:57:53 2009 From: setient at gmail.com (Ronald Cotoni) Date: Sat, 11 Jul 2009 13:57:53 -0500 Subject: Can someone from SORBS contact me offlist? In-Reply-To: <3F86F62FEDED4504BEF7698473D09541@JohnS> References: <2f1d68350907110720r3cf5206bje455d01f35b41d10@mail.gmail.com> <75cb24520907110908y2314f872gc505765f26cb6d90@mail.gmail.com> <6eb799ab0907110934i42b1ef89n5374b0cb2801ffb4@mail.gmail.com> <20090711124533.39ac39fa@milhouse.peachfamily.net> <2f1d68350907111005m50bc2a98o756313fa3a90e640@mail.gmail.com> <4A58C7CD.30501@2mbit.com> <3F86F62FEDED4504BEF7698473D09541@JohnS> Message-ID: <2f1d68350907111157vc80e12cpe651a77efd1702a9@mail.gmail.com> Sadly, this is for remote hosts. I have no idea why someone would use such services as there are too many false positives. It is like using an IDS that is 2 weeks behind on it's definition. That brings up the point of false positives and outdated information blocking legitimate users, perhaps many which is what my company is experiencing since they deem certain reverse dns entries too "generic" and blacklisted a /18. I believe that is why no one knows if they will be bought or whatnot. Who knows. On Sat, Jul 11, 2009 at 1:50 PM, John Souvestre wrote: > Hi Brielle. > > Do they take two weeks to put a spammer on the list? > > Regards, > > John > > John Souvestre - New Orleans LA > > > -----Original Message----- > > From: Brielle Bruns [mailto:bruns at 2mbit.com] > > Sent: Saturday, July 11, 2009 12:12 PM > > To: nanog at nanog.org > > Subject: Re: Can someone from SORBS contact me offlist? > > > > On 7/11/09 11:05 AM, Ronald Cotoni wrote: > > > Yes, they are really bad. It is actually quite silly that a > blacklisting > > > service is that slow on responding to problems. > > > > I find it unacceptable that people demand instant service from a company > > they don't have prior business arrangements/relationship with. Average > > turn around time for the AHBL is around two weeks if we don't have an > > established contact and procedure with. > > > > How would you like it if a non-customer came to you demanding resolution > > to a problem with a free service you provide? Would you drop > > everything, and give that non-customer the same service you give a > > paying customer? > > > > > > -- > > Brielle Bruns > > The Summit Open Source Development Group > > http://www.sosdg.org / http://www.ahbl.org > > > From mike at mtcc.com Sat Jul 11 14:10:56 2009 From: mike at mtcc.com (Michael Thomas) Date: Sat, 11 Jul 2009 12:10:56 -0700 Subject: Can someone from SORBS contact me offlist? In-Reply-To: References: <2f1d68350907110720r3cf5206bje455d01f35b41d10@mail.gmail.com> <75cb24520907110908y2314f872gc505765f26cb6d90@mail.gmail.com> <6eb799ab0907110934i42b1ef89n5374b0cb2801ffb4@mail.gmail.com> <20090711124533.39ac39fa@milhouse.peachfamily.net> <2f1d68350907111005m50bc2a98o756313fa3a90e640@mail.gmail.com> <4A58C7CD.30501@2mbit.com> Message-ID: <4A58E3C0.8030605@mtcc.com> Patrick W. Gilmore wrote: > Given that you said AHBL requires two weeks to remove good IP addresses > unless there is an "established contact", I'll be sure never to use said > list. Suppose my business partner gets listed? Am I to ruin our > relationship for two weeks because you are busy or don't like the fact > we don't pay you? We didn't pay you to list us either. What he's describing isn't a business; it's a protection racket. > Running a blacklist sucks. It's got to be one of the hardest jobs for a > white-hat to do on the 'Net. But if you don't like it, don't do it. > Doing it then complaining about it after is .. silly. Yep. Mike From nenolod at systeminplace.net Sat Jul 11 14:34:18 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Sat, 11 Jul 2009 14:34:18 -0500 Subject: Can someone from SORBS contact me offlist? In-Reply-To: <4A58C7CD.30501@2mbit.com> References: <2f1d68350907110720r3cf5206bje455d01f35b41d10@mail.gmail.com> <75cb24520907110908y2314f872gc505765f26cb6d90@mail.gmail.com> <6eb799ab0907110934i42b1ef89n5374b0cb2801ffb4@mail.gmail.com> <20090711124533.39ac39fa@milhouse.peachfamily.net> <2f1d68350907111005m50bc2a98o756313fa3a90e640@mail.gmail.com> <4A58C7CD.30501@2mbit.com> Message-ID: <1247340858.12662.5.camel@petrie> On Sat, 2009-07-11 at 11:11 -0600, Brielle Bruns wrote: > On 7/11/09 11:05 AM, Ronald Cotoni wrote: > > Yes, they are really bad. It is actually quite silly that a blacklisting > > service is that slow on responding to problems. > > I find it unacceptable that people demand instant service from a company > they don't have prior business arrangements/relationship with. Average > turn around time for the AHBL is around two weeks if we don't have an > established contact and procedure with. Yes, but the AHBL is actually a responsible blacklist service. SORBS has policies which make me choose to not use it on my mailservers, and the general amount of complaints I have heard about it is a major turnoff. Also, I believe SORBS are the ones that require a donation to get out if you've been screwed by your upstream provider that just handed you a tainted class-C. With the shortage of IPv4 addresses becoming more and more imminent, such policy is simply unacceptable. William -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-866-519-6149 From mysidia at gmail.com Sat Jul 11 14:35:41 2009 From: mysidia at gmail.com (James Hess) Date: Sat, 11 Jul 2009 14:35:41 -0500 Subject: Can someone from SORBS contact me offlist? In-Reply-To: <4A58C7CD.30501@2mbit.com> References: <2f1d68350907110720r3cf5206bje455d01f35b41d10@mail.gmail.com> <75cb24520907110908y2314f872gc505765f26cb6d90@mail.gmail.com> <6eb799ab0907110934i42b1ef89n5374b0cb2801ffb4@mail.gmail.com> <20090711124533.39ac39fa@milhouse.peachfamily.net> <2f1d68350907111005m50bc2a98o756313fa3a90e640@mail.gmail.com> <4A58C7CD.30501@2mbit.com> Message-ID: <6eb799ab0907111235i4f1ff04fjef0285b9066ddd39@mail.gmail.com> I wouldn't condone usage of SORBS' lists, because they sometimes use robots to automatically list things that have little rational basis for being listed, which causes problems. But it may be hard to convince your mail recipients to avoid the same. Commonly, providers may give un-assigned subnets generic PTR records like "isp192-168-0-1.somedomain.com" over their IP space. SORBS automatically lists these in the DUHL. And does not automatically remove them later, when the reverse zone is populated with final hostnames. Legitimate mailservers that do not originate spam routinely appear in the DUHL (and get blocked by users of the list). > How would you like it if a non-customer came to you demanding resolution to > a problem with a free service you provide? ?Would you drop everything, and > give that non-customer the same service you give a paying customer? That depends on the service. The DNS root servers provide a free service to internet users who aren't customers. If those servers all started directing users' .COM, lookups to an incorrect TLD server, so nothing resolved, people would be upset if $root_server_operator told them to wait 2 weeks. People who consume a blacklist might get that service for free, but they only do it on reliance that the blacklist follows the policies that the maintainer had published for their blacklist. In other words, that they provide what they say they are providing, and not something different. The expectation of timeliness arises, because internet applications, services like the web and e-mail are time-critical, no ability to send e-mail may mean lost revenue. An improper blacklist entry (or even a proper one) does direct, immediate, and serious damage to the party listed, and this injury is caused directly by the actions of the blacklist provider maintaining the list entry. I would suggest blacklist services have a moral duty to take reasonable measures to ensure they are not inflicting excessive, easily avoidable damage on innocent third parties, with stale or erroneous entries in their lists. If people believed a blacklist did not take reasonable measures to correct errors quickly, then it would be understandable that their reputation suffers. -- -J From sethm at rollernet.us Sat Jul 11 15:40:26 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 11 Jul 2009 13:40:26 -0700 Subject: Can someone from SORBS contact me offlist? In-Reply-To: <1580048455.102171247337860133.JavaMail.root@zimbra.nfsi.pt> References: <1580048455.102171247337860133.JavaMail.root@zimbra.nfsi.pt> Message-ID: <4A58F8BA.4050401@rollernet.us> Nuno Vieira - nfsi wrote: > That's good to know. > > I'll avoid using it. > Holy crap, what's with all the AHBL hate? At the very least they have a responsive human and - last time I checked - they don't require an exchange of money to get off the list. I'd hazard a guess that "two weeks" includes the responsiveness of the other party. I unsuspended a domain yesterday because the other party just now got around to the notices I sent 3 months ago on their hacked content manager hosting phishing sites. People bitch and whine about free services more than when they actually pay for something. Sad. ~Seth From blakjak at blakjak.net Sat Jul 11 16:12:59 2009 From: blakjak at blakjak.net (Mark Foster) Date: Sun, 12 Jul 2009 09:12:59 +1200 (NZST) Subject: Can someone from SORBS contact me offlist? In-Reply-To: <4A58F8BA.4050401@rollernet.us> References: <1580048455.102171247337860133.JavaMail.root@zimbra.nfsi.pt> <4A58F8BA.4050401@rollernet.us> Message-ID: On Sat, 11 Jul 2009, Seth Mattinen wrote: > Nuno Vieira - nfsi wrote: >> That's good to know. >> >> I'll avoid using it. >> > > Holy crap, what's with all the AHBL hate? At the very least they have a > responsive human and - last time I checked - they don't require an exchange > of money to get off the list. I'd hazard a guess that "two weeks" includes > the responsiveness of the other party. I unsuspended a domain yesterday > because the other party just now got around to the notices I sent 3 months > ago on their hacked content manager hosting phishing sites. > > People bitch and whine about free services more than when they actually pay > for something. Sad. > People who choose to run with SORBS - yes, a free service - take a significant risk (as other posters have highlighted); the people who run SORBS (person?) take a fairly extreme approach to the idea of removing hosts.... unfortunately the combination of blacklisting a host over a questionable report / reason, and then making removal of said host all-but impossible, would point toward a system that's far from 'user friendly', from the 'victim' point of view. Ala it appears that there's no room for any view that disagrees with that which SORBS take. But it is free. And one of the simplest implementations is a yes/no based on the RBL response... as opposed to simply perhaps using it for 'scoring'. I personally used one of the SORBS BL's several years ago on my personal MTA with good effect - primarily dropping inbound connections deemed to be from dynamic IP addresses. Unfortunately after a while false positives started creeping in and the collatoral damage started accumulating. I subsequently adopted other ways of dealing with inbound spam and can't say i've missed the crap that resulted from using them. >From the other side of the coin - on a professional level I had cause to deal with Michael Sullivan on behalf of an ISP I worked for that had been listed.... again the totalitarian viewpoint taken by SORBS made negotiation all-but impossible, this caused us "customer service issues". Most recently all i've been able to do is recommend people steer clear. That recommendation stands. Spam filtering technology has evolved over the last few years and there's plenty of better ways.... ... offers no solace to the victims of providers who are still running SORBS, however. Mark. From micheal at spmedicalgroup.com Sat Jul 11 16:30:48 2009 From: micheal at spmedicalgroup.com (Micheal Patterson) Date: Sat, 11 Jul 2009 16:30:48 -0500 Subject: Can someone from SORBS contact me offlist? References: <1580048455.102171247337860133.JavaMail.root@zimbra.nfsi.pt> <4A58F8BA.4050401@rollernet.us> Message-ID: <20DF49990D824A2DA4C93D621F5DF96A@dredster> ----- Original Message ----- From: "Seth Mattinen" To: Sent: Saturday, July 11, 2009 3:40 PM Subject: Re: Can someone from SORBS contact me offlist? > Nuno Vieira - nfsi wrote: >> That's good to know. >> >> I'll avoid using it. >> > > Holy crap, what's with all the AHBL hate? At the very least they have a > responsive human and - last time I checked - they don't require an > exchange of money to get off the list. I'd hazard a guess that "two weeks" > includes the responsiveness of the other party. I unsuspended a domain > yesterday because the other party just now got around to the notices I > sent 3 months ago on their hacked content manager hosting phishing sites. > > People bitch and whine about free services more than when they actually > pay for something. Sad. > > ~Seth "Proxy removal is functioning (sort of). Any other type of removal is no longer possible. Do not contact us about removals." That's quoted from their web site. No method of communications except through the proxy, which is only "sort of" working. So, if someone is listed, and the proxy only sort or works and can't remove them, there's no recourse. -- Micheal Patterson From bruns at 2mbit.com Sat Jul 11 16:37:33 2009 From: bruns at 2mbit.com (Brielle Bruns) Date: Sat, 11 Jul 2009 15:37:33 -0600 Subject: Can someone from SORBS contact me offlist? In-Reply-To: References: <2f1d68350907110720r3cf5206bje455d01f35b41d10@mail.gmail.com> <75cb24520907110908y2314f872gc505765f26cb6d90@mail.gmail.com> <6eb799ab0907110934i42b1ef89n5374b0cb2801ffb4@mail.gmail.com> <20090711124533.39ac39fa@milhouse.peachfamily.net> <2f1d68350907111005m50bc2a98o756313fa3a90e640@mail.gmail.com> <4A58C7CD.30501@2mbit.com> Message-ID: <4A59061D.1090407@2mbit.com> On 7/11/09 12:47 PM, Patrick W. Gilmore wrote: > Given that you said AHBL requires two weeks to remove good IP addresses > unless there is an "established contact", I'll be sure never to use said > list. Suppose my business partner gets listed? Am I to ruin our > relationship for two weeks because you are busy or don't like the fact > we don't pay you? We didn't pay you to list us either. Actually, if its a simple issue with a proxy or trojan, if you use the removal tool, provided the IP comes back clean from our tester, you are removed within 12-24 hours. If it requires manual intervention, yeah, its going to take longer. Our original idea was to base removal time on how long the listing was in the AHBL. If you hosted and gladly accepted money from a spam spewer for a year, and only decided to terminate them after they didn't pay, you'd be listed for somewhere in between 6 months to a year. Those two weeks are our buffer for seeing if said spam source is really gone, or just shut off long enough to fool us. We've been lied to so many times, its hard to justify doing instant removals on request. Further, there is such thing as a local whitelist of IP addresses. > > Besides, there are plenty of useful blacklists with very low FP rates > who are responsive. Why use one that has high FP and is unresponsive? > *shrugs* Thats up to you. I never held a gun to your head telling you to use the AHBL. > Running a blacklist sucks. It's got to be one of the hardest jobs for a > white-hat to do on the 'Net. But if you don't like it, don't do it. > Doing it then complaining about it after is .. silly. I'm not complaining. People talk shit about Michelle, and yes, I will get involved. She's a friend of mine, and a fellow DNSbl maintainer. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bruns at 2mbit.com Sat Jul 11 16:50:15 2009 From: bruns at 2mbit.com (Brielle Bruns) Date: Sat, 11 Jul 2009 15:50:15 -0600 Subject: Can someone from SORBS contact me offlist? In-Reply-To: <20DF49990D824A2DA4C93D621F5DF96A@dredster> References: <1580048455.102171247337860133.JavaMail.root@zimbra.nfsi.pt> <4A58F8BA.4050401@rollernet.us> <20DF49990D824A2DA4C93D621F5DF96A@dredster> Message-ID: <4A590917.3090306@2mbit.com> On 7/11/09 3:30 PM, Micheal Patterson wrote: > > "Proxy removal is functioning (sort of). Any other type of removal is no > longer possible. > Do not contact us about removals." > > That's quoted from their web site. No method of communications except > through the proxy, which is only "sort of" working. So, if someone is > listed, and the proxy only sort or works and can't remove them, there's > no recourse. > I knew I forgot to push the update that had the new contact form. Anyways, proxy removal works fine, and the contact form works. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From patrick at ianai.net Sat Jul 11 16:58:23 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 11 Jul 2009 17:58:23 -0400 Subject: Can someone from SORBS contact me offlist? In-Reply-To: <4A59061D.1090407@2mbit.com> References: <2f1d68350907110720r3cf5206bje455d01f35b41d10@mail.gmail.com> <75cb24520907110908y2314f872gc505765f26cb6d90@mail.gmail.com> <6eb799ab0907110934i42b1ef89n5374b0cb2801ffb4@mail.gmail.com> <20090711124533.39ac39fa@milhouse.peachfamily.net> <2f1d68350907111005m50bc2a98o756313fa3a90e640@mail.gmail.com> <4A58C7CD.30501@2mbit.com> <4A59061D.1090407@2mbit.com> Message-ID: <42427C51-449D-479F-822B-1F6C6127BEAD@ianai.net> On Jul 11, 2009, at 5:37 PM, Brielle Bruns wrote: > Further, there is such thing as a local whitelist of IP addresses. Easier to just not use the BL. >> Besides, there are plenty of useful blacklists with very low FP rates >> who are responsive. Why use one that has high FP and is >> unresponsive? > > *shrugs* Thats up to you. I never held a gun to your head telling > you to use the AHBL. See we completely agree! >> Running a blacklist sucks. It's got to be one of the hardest jobs >> for a >> white-hat to do on the 'Net. But if you don't like it, don't do it. >> Doing it then complaining about it after is .. silly. > > I'm not complaining. People talk shit about Michelle, and yes, I > will get involved. She's a friend of mine, and a fellow DNSbl > maintainer. Michelle has tried very hard to do some good thing. She has succeed at some of them. She has failed miserably at others. To the point where there are many people who believe she has done more harm than good. I am on the fence about her overall utility to the 'Net. I tend to believe the balance is more good than bad, if for no other reason than she raised awareness of the issue. But I could not argue strongly against those who believe otherwise, especially those who have been forced to pay to get delisted. I strongly recommend _against_ using SORBS. I've never used your BL, but given the ambiguity of your responses ("it takes two weeks .. uh .. unless you call me out about it on a public mailing list"), I'm inclined to never use it. Which is fine with you, so hopefully that makes us both happy. If you call that talking shit, bring it on. Being a DNSBL maintainer does not make you immune to factually correct criticism. -- TTFN, patrick P.S. Anyone looking to find a good DNSBL, I would recommend Al Iverson's web page, . Hrmmm, AHBL is not listed there. Al's pretty clueful about such things and checks all the major BLs in use. Did you ask him not to rate your service? From patrick at ianai.net Sat Jul 11 17:00:39 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 11 Jul 2009 18:00:39 -0400 Subject: Can someone from SORBS contact me offlist? In-Reply-To: <4A58F8BA.4050401@rollernet.us> References: <1580048455.102171247337860133.JavaMail.root@zimbra.nfsi.pt> <4A58F8BA.4050401@rollernet.us> Message-ID: On Jul 11, 2009, at 4:40 PM, Seth Mattinen wrote: > Nuno Vieira - nfsi wrote: >> That's good to know. >> I'll avoid using it. > > Holy crap, what's with all the AHBL hate? At the very least they > have a responsive human and - last time I checked - they don't > require an exchange of money to get off the list. I'd hazard a guess > that "two weeks" includes the responsiveness of the other party. I > unsuspended a domain yesterday because the other party just now got > around to the notices I sent 3 months ago on their hacked content > manager hosting phishing sites. Definitely not what the poster was implying (one could argue outright stating). I've never met anyone who quoted "It takes X long" when X was mostly waiting for you to respond. Why do you assume they would inflate their stats and make themselves look that bad in such a silly way? > People bitch and whine about free services more than when they > actually pay for something. Sad. That is not at all clear from the post above, or anything else in this thread. Hell, I don't even see hate for AHBL. I just see .. indifference. Just 'cause I and others do not want to use a service doesn't mean we hate it. -- TTFN, patrick From randy at psg.com Sat Jul 11 17:55:27 2009 From: randy at psg.com (Randy Bush) Date: Sun, 12 Jul 2009 07:55:27 +0900 Subject: BGP Growth projections In-Reply-To: <4A577479.9020703@bogus.com> References: <4A576F70.9010003@amplex.net> <4A577479.9020703@bogus.com> Message-ID: >> IPv6 is going to explode the routing table in the next 5 years. > More like, ipv4 is going explode the routing table in the next 5 > years? more like the routing table will continue to grow, mostly proportional to growth in multi-homed sites and richer inter-provider topology. randy From jlewis at lewis.org Sat Jul 11 17:59:24 2009 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 11 Jul 2009 18:59:24 -0400 (EDT) Subject: Can someone from SORBS contact me offlist? In-Reply-To: <2f1d68350907111157vc80e12cpe651a77efd1702a9@mail.gmail.com> References: <2f1d68350907110720r3cf5206bje455d01f35b41d10@mail.gmail.com> <75cb24520907110908y2314f872gc505765f26cb6d90@mail.gmail.com> <6eb799ab0907110934i42b1ef89n5374b0cb2801ffb4@mail.gmail.com> <20090711124533.39ac39fa@milhouse.peachfamily.net> <2f1d68350907111005m50bc2a98o756313fa3a90e640@mail.gmail.com> <4A58C7CD.30501@2mbit.com> <3F86F62FEDED4504BEF7698473D09541@JohnS> <2f1d68350907111157vc80e12cpe651a77efd1702a9@mail.gmail.com> Message-ID: On Sat, 11 Jul 2009, Ronald Cotoni wrote: > Sadly, this is for remote hosts. I have no idea why someone would use such > services as there are too many false positives. Desperation in trying to limit the amount of spam delivered. > It is like using an IDS that is 2 weeks behind on it's definition. That's still going to be more effective than no IDS. Anyone blocking using DNSBLs really ought to know how to locally whitelist to override the DNSBLs. Maybe you'll need to accept mail from a host that legitimately has issues and isn't a FP. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From justin at justinshore.com Sun Jul 12 03:50:49 2009 From: justin at justinshore.com (Justin Shore) Date: Sun, 12 Jul 2009 03:50:49 -0500 Subject: BGP Growth projections In-Reply-To: <4A576F70.9010003@amplex.net> References: <4A576F70.9010003@amplex.net> Message-ID: <4A59A3E9.3010203@justinshore.com> Mark Radabaugh wrote: > I'm looking for new core routers for a small ISP and having a hard time > finding something appropriate and reasonably priced. We don't have > huge traffic levels (<1Gb) and are mostly running Ethernet interfaces to > upstreams rather than legacy interfaces (when did OC3 become legacy?). > Lot's of choices for routers that can handle the existing BGP tables - > but not so much in small platforms (1-10Gb traffic) if you assume that > IPv6 is going to explode the routing table in the next 5 years. The > manufacturers still seem to think low traffic routers don't need much > memory or CPU. > What projections are you using regarding the default free zone over the > next 5 years when picking new hardware? I'll give you the Cisco product answer since that's what I know. I'd go with the ASR 1000 product line. At 1-10Gbps you've exceeded what an 7200 (even the G2) can handle. The largest of the ISR (3845) tops out at 1/2 Gbps at max CPU in theory (far less in reality). You don't want a software router though, especially for a SP and especially not for an Internet edge router. The ASR forwards in hardware. The 1002 with no internal hardware redundancy can handle 5 or 10 Gbps and costs a little more than a 7206 w/ NPE-G2 or a 7201 (with the 5Gbps ESP). This is one consideration for replacing my edge 7200s with. The 1004 version currently scales to 20Gbps and can handle redundant RPs. The 1006 module also currently scales to 20Gbps but can handle redundant RPs and ESPs. All the ASRs have internal software redundancy so crashes should be relatively painless in theory, even with a single RP. http://www.cisco.com/en/US/products/ps9343/index.html I'm looking at using the 1002 for my Internet edge and the 1006 for the core are smaller remote POPs. The platform has been out for a year or so and appears to be fairly solid. Justin From arievayner at gmail.com Sun Jul 12 05:09:12 2009 From: arievayner at gmail.com (Arie Vayner) Date: Sun, 12 Jul 2009 13:09:12 +0300 Subject: BGP Growth projections In-Reply-To: <00fb01ca01f9$00b8dc80$0a00000a@nil.si> References: <4A576F70.9010003@amplex.net> <00fb01ca01f9$00b8dc80$0a00000a@nil.si> Message-ID: <20b13c6b0907120309k7accd61ye2d256fcb87d64b1@mail.gmail.com> I would second Ivan's comment. Unless you are a major transit operator (which beats the "small ISP" requirement), you don't really need a full view, and can do we a limited view with a default route. Arie On Sat, Jul 11, 2009 at 10:27 AM, Ivan Pepelnjak wrote: > Let me be the devil's advocate: why would you need full Internet routing? > Taking reasonably sized neighborhoods of your upstreams (AS paths up to X > AS > numbers) plus a default to your best upstream might do the trick. > > Ivan > > http://www.ioshints.info/about > http://blog.ioshints.info/ > > > > -----Original Message----- > > From: Mark Radabaugh [mailto:mark at amplex.net] > > Sent: Friday, July 10, 2009 6:42 PM > > To: nanog list > > Subject: BGP Growth projections > > > > I'm looking for new core routers for a small ISP and having a > > hard time > > finding something appropriate and reasonably priced. We don't have > > huge traffic levels (<1Gb) and are mostly running Ethernet > > interfaces to > > upstreams rather than legacy interfaces (when did OC3 become > > legacy?). > > > > Lot's of choices for routers that can handle the existing BGP > > tables - but not so much in small platforms (1-10Gb traffic) > > if you assume that > > IPv6 is going to explode the routing table in the next 5 > > years. The > > manufacturers still seem to think low traffic routers don't > > need much memory or CPU. > > > > What projections are you using regarding the default free > > zone over the next 5 years when picking new hardware? > > > > -- > > > > Mark Radabaugh > > Amplex > > 419.837.5015 x21 > > mark at amplex.net > > > > > > > > > > > From jamonation at gmail.com Sun Jul 12 08:38:10 2009 From: jamonation at gmail.com (Jamon Camisso) Date: Sun, 12 Jul 2009 09:38:10 -0400 Subject: cogent contact Message-ID: <4A59E742.7020400@gmail.com> Could someone from cogent please contact me offlist? status.cogentco.com shows no problems but we're seeing prolonged and high packet losses from multiple locations. From dwhite at olp.net Sun Jul 12 10:25:26 2009 From: dwhite at olp.net (Dan White) Date: Sun, 12 Jul 2009 10:25:26 -0500 Subject: cogent contact In-Reply-To: <4A59E742.7020400@gmail.com> References: <4A59E742.7020400@gmail.com> Message-ID: <4A5A0066.2040205@olp.net> Jamon Camisso wrote: > Could someone from cogent please contact me offlist? > status.cogentco.com shows no problems but we're seeing prolonged and > high packet losses from multiple locations. > We are also experiencing similar issues. Our site had scheduled maintenance last night and we were notified this morning that it was completed. The sites affected by that maintenance included: DFW01, DFW02, DFW03, DFW05, DFW06, and TUL01 - Dan From iljitsch at muada.com Sun Jul 12 10:41:26 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 12 Jul 2009 17:41:26 +0200 Subject: BGP Growth projections In-Reply-To: <4A577479.9020703@bogus.com> References: <4A576F70.9010003@amplex.net> <4A577479.9020703@bogus.com> Message-ID: On 10 jul 2009, at 19:03, Joel Jaeggli wrote: >> IPv6 is going to explode the routing table in the next 5 years. > More like, ipv4 is going explode the routing table in the next 5 > years? IPv6 is now at something like 1.2 - 1.4 prefixes per AS. So it will take a LONG time before we reach 100k v6 prefixes unless something changes. IPv4 is already growing very fast, and it's all the small stuff: < / 16. This is 90% of the allocations and 10% of the address space (from memory). This isn't going to be impacted much by the IPv4 depletion. There's always people going bankrupt so addresses flow back to the RIRs. The only way the v4 table is going to explode is if Comcast etc decide that rather than 1 /12 they're going to take 4000 /24s or some such. Now of course the Comcasts of this world really don't want to spend even $1/address, and I think a /24 will be more than $1 after the v4 space has depleted. But even worse: having 4000 contracts with 4000 different people with 4000 different lawyers... Suddenly switching to IPv6 doesn't seem like such a bad deal anymore. Bottom line: a router that can do 500k prefixes is probably ok for the next 3 years but not likely for the next 5. 750k or more should be enough for 5 years, though. And you don't want to buy the router you're going to use in 2015 today. From nanog at webazilla.com Sun Jul 12 10:47:00 2009 From: nanog at webazilla.com (Konstantin Bezruchenko) Date: Sun, 12 Jul 2009 18:47:00 +0300 Subject: cogent contact In-Reply-To: <4A5A0066.2040205@olp.net> References: <4A59E742.7020400@gmail.com> <4A5A0066.2040205@olp.net> Message-ID: <4A5A0574.6050705@webazilla.com> Hi, We have same issues in Dallas. - Konstantin From rmoseley at softlayer.com Sun Jul 12 11:19:10 2009 From: rmoseley at softlayer.com (Ric Moseley) Date: Sun, 12 Jul 2009 11:19:10 -0500 Subject: cogent contact In-Reply-To: <4A5A0574.6050705@webazilla.com> References: <4A59E742.7020400@gmail.com> <4A5A0066.2040205@olp.net> <4A5A0574.6050705@webazilla.com> Message-ID: So are we in the DFW area. Ric. Softlayer. www.softlayer.com Jamon Camisso wrote: > Could someone from cogent please contact me offlist? > status.cogentco.com shows no problems but we're seeing prolonged and > high packet losses from multiple locations. > We are also experiencing similar issues. Our site had scheduled maintenance last night and we were notified this morning that it was completed. The sites affected by that maintenance included: DFW01, DFW02, DFW03, DFW05, DFW06, and TUL01 - Dan -----Original Message----- From: Konstantin Bezruchenko [mailto:nanog at webazilla.com] Sent: Sunday, July 12, 2009 10:47 AM To: Dan White Cc: NANOG list Subject: Re: cogent contact Hi, We have same issues in Dallas. - Konstantin The contents of this email message and any attachments are confidential and are intended solely for the addressee. The information may also be legally privileged. This transmission is sent in trust for the sole purpose of delivery to the intended recipient. If you have received this transmission in error; any use, reproduction or dissemination of this transmission is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply email and delete this message and all associated attachments. From aiverson at spamresource.com Sun Jul 12 11:53:48 2009 From: aiverson at spamresource.com (Al Iverson) Date: Sun, 12 Jul 2009 11:53:48 -0500 Subject: Can someone from SORBS contact me offlist? Message-ID: On Jul 11, 4:58 pm, "Patrick W. Gilmore" wrote: > On Jul 11, 2009, at 5:37 PM, Brielle Bruns wrote: > P.S. Anyone looking to find a good DNSBL, I would recommend Al > Iverson's web page, . Hrmmm, AHBL is not > listed there. Al's pretty clueful about such things and checks all > the major BLs in use. Did you ask him not to rate your service? No, neither Brielle nor Andrew (back in the day) have ever asked me to avoid rating AHBL. The fact that I haven't published DNSBL stats about AHBL should not be used as a data point to indicate that there's something wrong with it. I have a strong respect for Brielle and the other folks involved in the SOSDG. If I ran AHBL, there are things I might do differently than they do. But that's okay, that's allowed, and can be said of nearly any BL out there. I haven't personally tested AHBL in a couple of years now, so I can't speak to its current effectiveness level. When I did use it, there was nothing that made me concerned about it, nothing that made me think it would be a bad choice for a BL to use. That being said, allow me to strongly second your recommendation against using SORBS. I think it is very poorly and questionably run, full stop, by somebody who gets too heated and too drawn into personality conflict, and whose ability to effectively stop spam is negatively impacted as a result. Brielle, i certainly respect that you have a right to defend somebody that you consider to be a friend, but please do me a favor and don't discount what I know you have personally observed, and consider what some other folks have gone through when dealing with SORBS. We're not all spammers and cranks and lunatics. Some reasonable people can and do think SORBS is horribly broken. By the way, those of you who disagree with SORBS or are tired of running into false positive or unfair listings, I strongly recommend doing two things: 1. Contact the admin using SORBS to block your mail, and politely ask them to reconsider, based on the false positive and personality conflict issues know about SORBS. 2. Publish a very polite and rant-free page on your website indicating why you think it is a bad idea to use it. Leave angry emotion out of it. Skip the cries of conspiracy theory and extortion and defamation. Very simply relate your experiences and what you know about SORBS. Nothing more, nothing less. You'll be doing a favor for the NEXT admin who runs into the same issue, who will have more reasonable online experiences to link to when explaining to that last SORBS-using admin why it's a poor choice. By the way, I've found this to be a very successful process. In the US, SORBS is not used by any of the top hundred ISPs. It's only in use by small hobby sites and tiny ISPs, and in most cases, the email administrator picked it and other BLs fairly randomly, without giving any consideration to what choices they're making. A reasonable request for reconsideration has a good chance of success. Regards, Al Iverson -- Al Iverson on Spam and Deliverability, see http://www.spamresource.com News, stats, info, and commentary on blacklists: http://www.dnsbl.com My personal website: http://www.aliverson.com -- Chicago, IL, USA From dwhite at olp.net Sun Jul 12 12:07:59 2009 From: dwhite at olp.net (Dan White) Date: Sun, 12 Jul 2009 12:07:59 -0500 Subject: cogent contact In-Reply-To: <4A5A0066.2040205@olp.net> References: <4A59E742.7020400@gmail.com> <4A5A0066.2040205@olp.net> Message-ID: <4A5A186F.7010306@olp.net> Dan White wrote: > Jamon Camisso wrote: >> Could someone from cogent please contact me offlist? >> status.cogentco.com shows no problems but we're seeing prolonged and >> high packet losses from multiple locations. >> > > We are also experiencing similar issues. Our site had scheduled > maintenance last night and we were notified this morning that it was > completed. The sites affected by that maintenance included: > > DFW01, DFW02, DFW03, DFW05, DFW06, and TUL01 I received a call from Cogent that this outage has been resolved. The trouble was related to failed maintenance corresponding to NA736-17. - Dan From sthaug at nethelp.no Sun Jul 12 12:23:03 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sun, 12 Jul 2009 19:23:03 +0200 (CEST) Subject: Point to Point Ethernet In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB016283B0@bert.HiberniaAtlantic.local> References: <4fff97de0907091333h6cb58f5drada2a0265f51e9b6@mail.gmail.com> <1E8B940C5E21014AB8BE70B975D40EDB016283B0@bert.HiberniaAtlantic.local> Message-ID: <20090712.192303.74713918.sthaug@nethelp.no> > Prices of terrestrial SDH/SONET cards are very low for transport providers. For customers I believe there is a greater divergenc between the Ethernet and SONET/SDH costs. > > A strong hunch based on what clients tell me Cisco charges for SONET/SDH interfaces. I doubt a lot of people would think that SDH/SONET cards for *routers* are inexpensive. And yes, I have a reasonable idea of what kind of discounts are available out there... Steinar Haug, Nethelp consulting, sthaug at nethelp.no From Rod.Beck at hiberniaatlantic.com Sun Jul 12 13:46:41 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Sun, 12 Jul 2009 19:46:41 +0100 Subject: [SPAM-HEADER] - Re: Point to Point Ethernet - Email has different SMTP TO: and MIME TO: fields in the email addresses References: <4fff97de0907091333h6cb58f5drada2a0265f51e9b6@mail.gmail.com><1E8B940C5E21014AB8BE70B975D40EDB016283B0@bert.HiberniaAtlantic.local> <20090712.192303.74713918.sthaug@nethelp.no> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB016283B4@bert.HiberniaAtlantic.local> > Prices of terrestrial SDH/SONET cards are very low for transport providers. For customers I believe there is a greater divergenc between the Ethernet and SONET/SDH costs. > > A strong hunch based on what clients tell me Cisco charges for SONET/SDH interfaces. I doubt a lot of people would think that SDH/SONET cards for *routers* are inexpensive. And yes, I have a reasonable idea of what kind of discounts are available out there... Steinar Haug, Nethelp consulting, sthaug at nethelp.no Transport in my world is not Layer 3. It's Layer 2: Ethernet, SDH, SONET, waves. But my clients are mostly Layer 3. So you and I are in fundamental agreement. Roderick S. Beck Director of European Sales Hibernia Atlantic From asr+nanog at latency.net Sun Jul 12 14:31:10 2009 From: asr+nanog at latency.net (Adam Rothschild) Date: Sun, 12 Jul 2009 15:31:10 -0400 Subject: BGP Growth projections In-Reply-To: <20b13c6b0907120309k7accd61ye2d256fcb87d64b1@mail.gmail.com> References: <4A576F70.9010003@amplex.net> <00fb01ca01f9$00b8dc80$0a00000a@nil.si> <20b13c6b0907120309k7accd61ye2d256fcb87d64b1@mail.gmail.com> Message-ID: <20090712193110.GA31689@latency.net> On 2009-07-12-06:09:12, Arie Vayner wrote: > Unless you are a major transit operator (which beats the "small ISP" > requirement), you don't really need a full view, and can do we a > limited view with a default route. Disagree. Protection against big-provider depeerings, interdomain capacity problems, etc is increasingly relevant to smaller sites interested in getting business done. While some will outsource this protection their (non-transit-free) provider, others enjoy maintaining this granularity of control themselves... -a From tomb at byrneit.net Sun Jul 12 14:50:00 2009 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Sun, 12 Jul 2009 12:50:00 -0700 Subject: Can someone from SORBS contact me offlist? In-Reply-To: <4A58F8BA.4050401@rollernet.us> References: <1580048455.102171247337860133.JavaMail.root@zimbra.nfsi.pt> <4A58F8BA.4050401@rollernet.us> Message-ID: <70D072392E56884193E3D2DE09C097A9073877@pascal.zaphodb.org> >People bitch and whine about free services more than when they actually >pay for something. Sad. That's the nature of people who want something for nothing. When you charge, even a little bit, you select the bottom part of the gene pool out of your client base. From ray at oneunified.net Sun Jul 12 14:51:28 2009 From: ray at oneunified.net (Ray Burkholder) Date: Sun, 12 Jul 2009 16:51:28 -0300 Subject: BGP Growth projections In-Reply-To: <20090712193110.GA31689@latency.net> References: <4A576F70.9010003@amplex.net><00fb01ca01f9$00b8dc80$0a00000a@nil.si><20b13c6b0907120309k7accd61ye2d256fcb87d64b1@mail.gmail.com> <20090712193110.GA31689@latency.net> Message-ID: <6E652B07CA81414CA725BCAA65450A71@oneunified.local> > On 2009-07-12-06:09:12, Arie Vayner wrote: > > Unless you are a major transit operator (which beats the "small ISP" > > requirement), you don't really need a full view, and can do we a > > limited view with a default route. > > Disagree. Protection against big-provider depeerings, > interdomain capacity problems, etc is increasingly relevant > to smaller sites interested in getting business done. While > some will outsource this protection their (non-transit-free) > provider, others enjoy maintaining this granularity of > control themselves... > Specifically, with full routes, us "small ISP" people can match ASNs with traffic in Netflow to see where our traffic goes/comes from, and thus do capacity/link/peer/transit/traffic planning and problem mitigation. -- Scanned for viruses and dangerous content at http://www.oneunified.net and is believed to be clean. From tomb at byrneit.net Sun Jul 12 15:20:33 2009 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Sun, 12 Jul 2009 13:20:33 -0700 Subject: BGP Growth projections In-Reply-To: <4A576F70.9010003@amplex.net> References: <4A576F70.9010003@amplex.net> Message-ID: <70D072392E56884193E3D2DE09C097A9073878@pascal.zaphodb.org> Give Vyatta on a decent x86 server a try. http://www.vyatta.com/downloads/appbrief/Vyatta_app_BGP.pdf -----Original Message----- From: Mark Radabaugh [mailto:mark at amplex.net] Sent: Friday, July 10, 2009 9:42 AM To: nanog list Subject: BGP Growth projections I'm looking for new core routers for a small ISP and having a hard time finding something appropriate and reasonably priced. We don't have huge traffic levels (<1Gb) and are mostly running Ethernet interfaces to upstreams rather than legacy interfaces (when did OC3 become legacy?). Lot's of choices for routers that can handle the existing BGP tables - but not so much in small platforms (1-10Gb traffic) if you assume that IPv6 is going to explode the routing table in the next 5 years. The manufacturers still seem to think low traffic routers don't need much memory or CPU. What projections are you using regarding the default free zone over the next 5 years when picking new hardware? -- Mark Radabaugh Amplex 419.837.5015 x21 mark at amplex.net Checked by AVG - www.avg.com Version: 8.5.375 / Virus Database: 270.13.12/2233 - Release Date: 07/12/09 08:20:00 From charles at thewybles.com Sun Jul 12 16:28:18 2009 From: charles at thewybles.com (Charles Wyble) Date: Sun, 12 Jul 2009 14:28:18 -0700 Subject: DDOS Followup Message-ID: <4A5A5572.5030201@thewybles.com> I had a pleasant chat with tier 2 support and they changed my IP range. All is now well. Thanks to all who replied. From jlewis at lewis.org Sun Jul 12 16:42:53 2009 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 12 Jul 2009 17:42:53 -0400 (EDT) Subject: BGP Growth projections In-Reply-To: <20b13c6b0907120309k7accd61ye2d256fcb87d64b1@mail.gmail.com> References: <4A576F70.9010003@amplex.net> <00fb01ca01f9$00b8dc80$0a00000a@nil.si> <20b13c6b0907120309k7accd61ye2d256fcb87d64b1@mail.gmail.com> Message-ID: On Sun, 12 Jul 2009, Arie Vayner wrote: > I would second Ivan's comment. > Unless you are a major transit operator (which beats the "small ISP" > requirement), you don't really need a full view, and can do we a limited > view with a default route. Until something breaks or the next big depeering chicken fight which causes you to lose reachability to some portion of the net. As Randy might say, I encourage my competitors to design their network that way. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From mark at amplex.net Sun Jul 12 20:28:54 2009 From: mark at amplex.net (Mark Radabaugh) Date: Sun, 12 Jul 2009 21:28:54 -0400 Subject: BGP Growth projections In-Reply-To: <00fb01ca01f9$00b8dc80$0a00000a@nil.si> References: <4A576F70.9010003@amplex.net> <00fb01ca01f9$00b8dc80$0a00000a@nil.si> Message-ID: <4A5A8DD6.8020106@amplex.net> Ivan Pepelnjak wrote: > Let me be the devil's advocate: why would you need full Internet routing? > Taking reasonably sized neighborhoods of your upstreams (AS paths up to X AS > numbers) plus a default to your best upstream might do the trick. > > Ivan > > We currently do exactly that - dropping anything longer than a /23 with default routes to cover anything missing. Since were replacing the routers anyway I would prefer to have the capacity to do things correctly rather than what, at least to me, seems a kludge. It is a very workable solution - just not one I am completely comfortable with. -- Mark Radabaugh Amplex 419.837.5015 x21 mark at amplex.net From kratzers at pa.net Mon Jul 13 09:36:52 2009 From: kratzers at pa.net (Stephen Kratzer) Date: Mon, 13 Jul 2009 10:36:52 -0400 Subject: AT&T and having two BGP peers In-Reply-To: <9418aca70907101048h452520b0sd8681585e4b2709f@mail.gmail.com> References: <9418aca70907101048h452520b0sd8681585e4b2709f@mail.gmail.com> Message-ID: <200907131036.52871.kratzers@pa.net> Use a /30 across the circuit and do multihop BGP using other IPs. On Friday 10 July 2009 13:48:15 Jay Nakamura wrote: > We are getting an Ethernet DIA circuit from AT&T but they insist that > they can't BGP peer with 2 routers on our side. The WAN circuit can > only have /30 they say. Has anyone been able to successfully talk > them in to bending their rule? If so, how? > > I know this should have been negotiated before signing a contract but > I was unfortunately not in the loop... :( > > It seems like a ridiculous bureaucratic restriction. From kratzers at pa.net Mon Jul 13 09:36:52 2009 From: kratzers at pa.net (Stephen Kratzer) Date: Mon, 13 Jul 2009 10:36:52 -0400 Subject: AT&T and having two BGP peers In-Reply-To: <9418aca70907101048h452520b0sd8681585e4b2709f@mail.gmail.com> References: <9418aca70907101048h452520b0sd8681585e4b2709f@mail.gmail.com> Message-ID: <200907131036.52871.kratzers@pa.net> Use a /30 across the circuit and do multihop BGP using other IPs. On Friday 10 July 2009 13:48:15 Jay Nakamura wrote: > We are getting an Ethernet DIA circuit from AT&T but they insist that > they can't BGP peer with 2 routers on our side. The WAN circuit can > only have /30 they say. Has anyone been able to successfully talk > them in to bending their rule? If so, how? > > I know this should have been negotiated before signing a contract but > I was unfortunately not in the loop... :( > > It seems like a ridiculous bureaucratic restriction. From cburnham at du.edu Mon Jul 13 11:07:06 2009 From: cburnham at du.edu (Chad Burnham) Date: Mon, 13 Jul 2009 10:07:06 -0600 Subject: OEMs for X2 10G LAN PHY optics In-Reply-To: <20090710212543.GA46088@latency.net> References: <80e7195b0907101121o15ee4e5ex4b16d29268db1bbf@mail.gmail.com> <20090710212543.GA46088@latency.net> Message-ID: HI, We have been very happy with Champion and NHR for such equipment: http://www.championone.net/ & http://www.networkhardware.com/ Stellar pricing and support. Chad Chad D Burnham Telecommunications Network Planner University Technology Services - Network Services University of Denver 2100 S. High St. #112 Denver, CO 80210 USA Desk Phone: 303-871-4441 Mobile Phone: 303-520-5657 FAX: 303-871-2298 -----Original Message----- From: Adam Rothschild [mailto:asr+nanog at latency.net] Sent: Friday, July 10, 2009 3:26 PM To: Duane Waddle Cc: nanog at merit.edu Subject: Re: OEMs for X2 10G LAN PHY optics On 2009-07-10-14:21:49, Duane Waddle wrote: > I am searching for opinions on OEMs of X2 form factor 10G LAN PHY > optics. We've found that most router/switch vendors mark these > particular items up significantly just to provide their own > sticker/EEPROM ID. As such, we'd prefer if we can to procure from the > OEM (or their reseller). Is this a situation where any company who's > a signatory to the MSA produces suitable modules, or are there > particular OEMs to prefer (or avoid)? > > If it matters, the prime platform we're looking to plug optics into is > the WS-X6708-10G module for a 6500/7600. I'd suggest looking at FluxLight (www.fluxlightinc.com) for this. Their sales and support process is nothing short of stellar, and pricing is a fair medium between "paying too much for vendor optics" and "fly-by-night eBay imports". To wit, all of their products Just Worked without ever needing Cisco's infamous 'service unsupported-transceiver' vendor lock override. -a -------------- next part -------------- A non-text attachment was scrubbed... Name: Chad Burnham.vcf Type: application/octet-stream Size: 5308 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3097 bytes Desc: not available URL: From rmoseley at softlayer.com Mon Jul 13 11:21:33 2009 From: rmoseley at softlayer.com (Ric Moseley) Date: Mon, 13 Jul 2009 11:21:33 -0500 Subject: OEMs for X2 10G LAN PHY optics In-Reply-To: References: <80e7195b0907101121o15ee4e5ex4b16d29268db1bbf@mail.gmail.com><20090710212543.GA46088@latency.net> Message-ID: Try http://www.advantageoptics.com/. Ric. Softlayer. www.softlayer.com. -----Original Message----- From: Chad Burnham [mailto:cburnham at du.edu] Sent: Monday, July 13, 2009 11:07 AM To: Adam Rothschild; Duane Waddle Cc: nanog at merit.edu Subject: RE: OEMs for X2 10G LAN PHY optics HI, We have been very happy with Champion and NHR for such equipment: http://www.championone.net/ & http://www.networkhardware.com/ Stellar pricing and support. Chad Chad D Burnham Telecommunications Network Planner University Technology Services - Network Services University of Denver 2100 S. High St. #112 Denver, CO 80210 USA Desk Phone: 303-871-4441 Mobile Phone: 303-520-5657 FAX: 303-871-2298 -----Original Message----- From: Adam Rothschild [mailto:asr+nanog at latency.net] Sent: Friday, July 10, 2009 3:26 PM To: Duane Waddle Cc: nanog at merit.edu Subject: Re: OEMs for X2 10G LAN PHY optics On 2009-07-10-14:21:49, Duane Waddle wrote: > I am searching for opinions on OEMs of X2 form factor 10G LAN PHY > optics. We've found that most router/switch vendors mark these > particular items up significantly just to provide their own > sticker/EEPROM ID. As such, we'd prefer if we can to procure from the > OEM (or their reseller). Is this a situation where any company who's > a signatory to the MSA produces suitable modules, or are there > particular OEMs to prefer (or avoid)? > > If it matters, the prime platform we're looking to plug optics into is > the WS-X6708-10G module for a 6500/7600. I'd suggest looking at FluxLight (www.fluxlightinc.com) for this. Their sales and support process is nothing short of stellar, and pricing is a fair medium between "paying too much for vendor optics" and "fly-by-night eBay imports". To wit, all of their products Just Worked without ever needing Cisco's infamous 'service unsupported-transceiver' vendor lock override. -a The contents of this email message and any attachments are confidential and are intended solely for the addressee. The information may also be legally privileged. This transmission is sent in trust for the sole purpose of delivery to the intended recipient. If you have received this transmission in error; any use, reproduction or dissemination of this transmission is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply email and delete this message and all associated attachments. From nanog at shreddedmail.com Mon Jul 13 11:23:33 2009 From: nanog at shreddedmail.com (Rick Ernst) Date: Mon, 13 Jul 2009 09:23:33 -0700 Subject: Public/testing 4to6 gateway? Message-ID: Either they don't exist, or my Google-fu is particularly bad this morning. I'm trying to get my toes wet with IPv6. I've established an internal 6to4/4to6 tunnel. I'd also like to have a testbed for access to public v6 sites. I'm also trying to find some clue at my upstreams, but figured I'd ask here as well. Are there any 4to6 gateway available? I have assigned v6 space. Thanks, From cburnham at du.edu Mon Jul 13 11:31:31 2009 From: cburnham at du.edu (Chad Burnham) Date: Mon, 13 Jul 2009 10:31:31 -0600 Subject: Public/testing 4to6 gateway? In-Reply-To: References: Message-ID: Rick, I use this one: http://www.tunnelbroker.net/ Free! Chad -----Original Message----- From: Rick Ernst [mailto:nanog at shreddedmail.com] Sent: Monday, July 13, 2009 10:24 AM To: NANOG Subject: Public/testing 4to6 gateway? Either they don't exist, or my Google-fu is particularly bad this morning. I'm trying to get my toes wet with IPv6. I've established an internal 6to4/4to6 tunnel. I'd also like to have a testbed for access to public v6 sites. I'm also trying to find some clue at my upstreams, but figured I'd ask here as well. Are there any 4to6 gateway available? I have assigned v6 space. Thanks, -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3097 bytes Desc: not available URL: From Eric.Ballard at suddenlink.com Mon Jul 13 11:39:24 2009 From: Eric.Ballard at suddenlink.com (Ballard, Eric) Date: Mon, 13 Jul 2009 11:39:24 -0500 Subject: OEMs for X2 10G LAN PHY optics In-Reply-To: References: <80e7195b0907101121o15ee4e5ex4b16d29268db1bbf@mail.gmail.com> <20090710212543.GA46088@latency.net> Message-ID: All, I would like to second the vote for NHR(Network Hardware). I have purchased from Joe Zender there for years and the support, price, warranty, and quality has been outstanding. I placed his contact info below, because it is truly a rare thing when I can say he is a great sales person. Thanks Eric Joe Zender Network Hardware Resale Phone: 805-690-3723 Fax: 805-690-1835 AIM - zenderNHR Yahoo! - nhr_joezender jzender at networkhardware.com www.networkhardware.com -----Original Message----- From: Chad Burnham [mailto:cburnham at du.edu] Sent: Monday, July 13, 2009 11:07 AM To: Adam Rothschild; Duane Waddle Cc: nanog at merit.edu Subject: RE: OEMs for X2 10G LAN PHY optics HI, We have been very happy with Champion and NHR for such equipment: http://www.championone.net/ & http://www.networkhardware.com/ Stellar pricing and support. Chad Chad D Burnham Telecommunications Network Planner University Technology Services - Network Services University of Denver 2100 S. High St. #112 Denver, CO 80210 USA Desk Phone: 303-871-4441 Mobile Phone: 303-520-5657 FAX: 303-871-2298 -----Original Message----- From: Adam Rothschild [mailto:asr+nanog at latency.net] Sent: Friday, July 10, 2009 3:26 PM To: Duane Waddle Cc: nanog at merit.edu Subject: Re: OEMs for X2 10G LAN PHY optics On 2009-07-10-14:21:49, Duane Waddle wrote: > I am searching for opinions on OEMs of X2 form factor 10G LAN PHY > optics. We've found that most router/switch vendors mark these > particular items up significantly just to provide their own > sticker/EEPROM ID. As such, we'd prefer if we can to procure from the > OEM (or their reseller). Is this a situation where any company who's > a signatory to the MSA produces suitable modules, or are there > particular OEMs to prefer (or avoid)? > > If it matters, the prime platform we're looking to plug optics into is > the WS-X6708-10G module for a 6500/7600. I'd suggest looking at FluxLight (www.fluxlightinc.com) for this. Their sales and support process is nothing short of stellar, and pricing is a fair medium between "paying too much for vendor optics" and "fly-by-night eBay imports". To wit, all of their products Just Worked without ever needing Cisco's infamous 'service unsupported-transceiver' vendor lock override. -a From peter at peter-dambier.de Mon Jul 13 11:46:53 2009 From: peter at peter-dambier.de (Peter Dambier) Date: Mon, 13 Jul 2009 18:46:53 +0200 Subject: Public/testing 4to6 gateway? In-Reply-To: References: Message-ID: <4A5B64FD.6020001@peter-dambier.de> Hello Rick, try traceroute to 192.88.99.1 (192.88.99.1), 64 hops max, 40 byte packets 1 yttrium.anul.nsa (7.19.30.39) 3 ms 1 ms 1 ms 2 217.0.116.228 (217.0.116.228) 47 ms 46 ms * 3 217.0.78.50 (217.0.78.50) 58 ms 46 ms 45 ms 4 217.239.40.177 (217.239.40.177) 48 ms 51 ms 49 ms 5 tenge2-2.cr3.fra3.content-core.net (193.159.227.138) 47 ms 48 ms 48 ms 6 Tenge2-4-42.cr2.FRA3.content-core.net (212.123.123.137) 49 ms * 70 ms So my gateway is inetnum: 212.123.122.0 - 212.123.123.255 netname: IP-PARTNER descr: IP Exchange GmbH descr: Am Tower 5 descr: 90475 Nuernberg remarks: INFRA-AW country: DE I guess your traceroute goes somewhere else. Kind regards Peter Rick Ernst wrote: > Either they don't exist, or my Google-fu is particularly bad this morning. > > I'm trying to get my toes wet with IPv6. I've established an internal > 6to4/4to6 tunnel. I'd also like to have a testbed for access to public v6 > sites. I'm also trying to find some clue at my upstreams, but figured I'd > ask here as well. Are there any 4to6 gateway available? I have assigned v6 > space. > > Thanks, -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter at peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ULA= fd80:4ce1:c66a::/48 From pstewart at nexicomgroup.net Mon Jul 13 11:48:55 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Mon, 13 Jul 2009 12:48:55 -0400 Subject: OEMs for X2 10G LAN PHY optics In-Reply-To: References: <80e7195b0907101121o15ee4e5ex4b16d29268db1bbf@mail.gmail.com><20090710212543.GA46088@latency.net> Message-ID: Yeah, just don't ask a certain female sales person there for more than a few quotes without buying... I was utterly embarrassed while dealing with NHR - never been told off by a commissioned sales person before. Requested a series of quotes on a Cisco GSR and made it very clear we already had a preferred supplier, but that I would give NHR a chance in the quotes. Their pricing was off a bit and the job went to a competitor - she freaked out on me. I have never dealt with them since. It was the most immature dealing with a company I have ever encountered, and this goes back several years now - and I'm still pissed. When I took this to their management team I was promised a phone call from their CEO and never got it. Since I talked to a senior management person and asked to removed from their internal lists - had *many* of their sales people continue to call and pester me. They finally got that part right and have not heard from anyone since (nor do I EVER wish to). Paul -----Original Message----- From: Ballard, Eric [mailto:Eric.Ballard at suddenlink.com] Sent: Monday, July 13, 2009 12:39 PM To: Chad Burnham; Adam Rothschild; Duane Waddle Cc: nanog at merit.edu Subject: RE: OEMs for X2 10G LAN PHY optics All, I would like to second the vote for NHR(Network Hardware). I have purchased from Joe Zender there for years and the support, price, warranty, and quality has been outstanding. I placed his contact info below, because it is truly a rare thing when I can say he is a great sales person. Thanks Eric Joe Zender Network Hardware Resale Phone: 805-690-3723 Fax: 805-690-1835 AIM - zenderNHR Yahoo! - nhr_joezender jzender at networkhardware.com www.networkhardware.com -----Original Message----- From: Chad Burnham [mailto:cburnham at du.edu] Sent: Monday, July 13, 2009 11:07 AM To: Adam Rothschild; Duane Waddle Cc: nanog at merit.edu Subject: RE: OEMs for X2 10G LAN PHY optics HI, We have been very happy with Champion and NHR for such equipment: http://www.championone.net/ & http://www.networkhardware.com/ Stellar pricing and support. Chad Chad D Burnham Telecommunications Network Planner University Technology Services - Network Services University of Denver 2100 S. High St. #112 Denver, CO 80210 USA Desk Phone: 303-871-4441 Mobile Phone: 303-520-5657 FAX: 303-871-2298 -----Original Message----- From: Adam Rothschild [mailto:asr+nanog at latency.net] Sent: Friday, July 10, 2009 3:26 PM To: Duane Waddle Cc: nanog at merit.edu Subject: Re: OEMs for X2 10G LAN PHY optics On 2009-07-10-14:21:49, Duane Waddle wrote: > I am searching for opinions on OEMs of X2 form factor 10G LAN PHY > optics. We've found that most router/switch vendors mark these > particular items up significantly just to provide their own > sticker/EEPROM ID. As such, we'd prefer if we can to procure from the > OEM (or their reseller). Is this a situation where any company who's > a signatory to the MSA produces suitable modules, or are there > particular OEMs to prefer (or avoid)? > > If it matters, the prime platform we're looking to plug optics into is > the WS-X6708-10G module for a 6500/7600. I'd suggest looking at FluxLight (www.fluxlightinc.com) for this. Their sales and support process is nothing short of stellar, and pricing is a fair medium between "paying too much for vendor optics" and "fly-by-night eBay imports". To wit, all of their products Just Worked without ever needing Cisco's infamous 'service unsupported-transceiver' vendor lock override. -a ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From dmm at 1-4-5.net Mon Jul 13 11:53:11 2009 From: dmm at 1-4-5.net (David Meyer) Date: Mon, 13 Jul 2009 09:53:11 -0700 Subject: NANOG 47 announcements Message-ID: <20090713165311.GA7176@1-4-5.net> Folks, A few announcements: (i). Thank everyone again for attending NANOG 46. The NANOG 46 survey is open for one more week. If you haven't taken the survey yet, please see http://www.surveymonkey.com/s.aspx?sm=MHjaY6hu6bwNs_2bpmca_2fc_2fQ_3d_3d (ii). Exciting news about NANOG 47 in Dearborn. The NANOG PC has been working with ARIN and the results are an exciting CFP. Please see http://nanog.org/meetings/nanog47/callforpresent.php (iii). Registration is open for NANOG 47. Please see https://nanog.merit.edu/registration. (iv). The NANOG 47 hotel link is up. Please see http://nanog.org/meetings/nanog47/hotel.php (v). NANOG 47 Meeting sponsorships are now being accepted (as always, sponsorship is critical to NANOG's success). Please see http://nanog.org/sponsors. We're looking forward to seeing you all in in Dearborn. Dave (for the NANOG PC) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From nanog at shreddedmail.com Mon Jul 13 12:06:30 2009 From: nanog at shreddedmail.com (Rick Ernst) Date: Mon, 13 Jul 2009 10:06:30 -0700 Subject: Public/testing 4to6 gateway? In-Reply-To: References: Message-ID: Multiple responses of tunnelbroker.net. Couldn't have been any easier to setup and get going. Thanks! On Mon, Jul 13, 2009 at 9:31 AM, Chad Burnham wrote: > Rick, > > I use this one: > > http://www.tunnelbroker.net/ > > Free! > > Chad > > -----Original Message----- > From: Rick Ernst [mailto:nanog at shreddedmail.com] > Sent: Monday, July 13, 2009 10:24 AM > To: NANOG > Subject: Public/testing 4to6 gateway? > > Either they don't exist, or my Google-fu is particularly bad this morning. > > I'm trying to get my toes wet with IPv6. I've established an internal > 6to4/4to6 tunnel. I'd also like to have a testbed for access to public v6 > sites. I'm also trying to find some clue at my upstreams, but figured I'd > ask here as well. Are there any 4to6 gateway available? I have assigned > v6 > space. > > Thanks, > From bdfleming at kanren.net Mon Jul 13 12:52:16 2009 From: bdfleming at kanren.net (Brad Fleming) Date: Mon, 13 Jul 2009 12:52:16 -0500 Subject: 3rd Party Router Comparisons and Testing Message-ID: <7218AD4A-6369-4691-A453-C96DFDD2B68A@kanren.net> Hello all, I was wondering if anyone has a good, trusted, non-partial source for 3rd party testing and/or comparisons of the major routing hardware vendors. I'm willing to pay for a subscription / membership to an organization if the information is well assembled recent. Specifically, I'd like (love) to see a comparison between Juniper MX series, Cisco 6500/7600 series, Brocade XMR/MLX series, and any others that I don't even know about. If your company has recently (say the past 18 months?) completed an analysis and you can provide the results, I can keep them private (this is only for my use, not official decision making). Does anyone happen to have a source they would be willing to pass along? Thanks in advance for any suggestions! -- Brad Fleming Kansas Research and Education Network From jkrejci at usinternet.com Mon Jul 13 13:28:58 2009 From: jkrejci at usinternet.com (Justin Krejci) Date: Mon, 13 Jul 2009 13:28:58 -0500 Subject: H3C Switches/Routers Message-ID: Nanog, I was just looking at the H3C 12500 enterprise product for which I received a slideshow presentation on its features and comparisons to Nexus 7018, Foundry/Brocade RX32, Juniper EX8218 and Force10 E1200. It does not look like they have a significant market share but make a lot of bold claims on side-by-side comparisons to comparable products from their competition. Is anyone using H3C products (enterprise or otherwise) here at all? If so, what are your thoughts on them? Are there any noticeable drawbacks? Performance issues? Support? Just an overall summary would be nice. Thanks, Justin Krejci From sethm at rollernet.us Mon Jul 13 14:42:47 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 13 Jul 2009 12:42:47 -0700 Subject: MGE UPS Systems Message-ID: <4A5B8E37.9030505@rollernet.us> I'm curious if anyone might know what the future of the MGE line of UPS systems are. My concern is that they're dead-end since being merged into APC, and APC wanting to sell me APC stuff. The problem I face is that my facility was designed with separate equipment spaces, which is great for normal electrical gear that can be backed against a wall, but not so great for a product which is designed for the "everything goes in with your racks" mindset. Any insight would be appreciated. ~Seth From Justin.Dixon at BBandT.com Mon Jul 13 14:58:40 2009 From: Justin.Dixon at BBandT.com (Dixon, Justin) Date: Mon, 13 Jul 2009 15:58:40 -0400 Subject: MGE UPS Systems In-Reply-To: <4A5B8E37.9030505@rollernet.us> References: <4A5B8E37.9030505@rollernet.us> Message-ID: <91864382B2433640BA2A447041B3DBC30B46F4EB@wil-exmb01.bbtnet.com> > I'm curious if anyone might know what the future of the MGE line of UPS > systems are. My concern is that they're dead-end since being merged into > APC, and APC wanting to sell me APC stuff. The problem I face is that my > facility was designed with separate equipment spaces, which is great for > normal electrical gear that can be backed against a wall, but not so > great for a product which is designed for the "everything goes in with > your racks" mindset. Any insight would be appreciated. > > ~Seth It looks like they are still available in the product selector on the APC website. http://www.apc.com/products/category.cfm?id=13 http://www.apc.com/products/family/index.cfm?id=361 http://www.apc.com/products/family/index.cfm?id=365 If you're wondering about long term someone from their sales dept. can probably tell you if they plan to keep the product line or discontinue it. From dan at beanfield.com Mon Jul 13 15:04:01 2009 From: dan at beanfield.com (Dan Armstrong) Date: Mon, 13 Jul 2009 16:04:01 -0400 Subject: MGE UPS Systems In-Reply-To: <4A5B8E37.9030505@rollernet.us> References: <4A5B8E37.9030505@rollernet.us> Message-ID: <242F2337-DF0F-4A1D-BDA2-4B167599EB3E@beanfield.com> We have 3 big Comet systems, and we're absolutely delighted with them. Their service is the best we receive from any vendor we deal with. On 13-Jul-09, at 3:42 PM, Seth Mattinen wrote: > I'm curious if anyone might know what the future of the MGE line of > UPS > systems are. My concern is that they're dead-end since being merged > into > APC, and APC wanting to sell me APC stuff. The problem I face is > that my > facility was designed with separate equipment spaces, which is great > for > normal electrical gear that can be backed against a wall, but not so > great for a product which is designed for the "everything goes in with > your racks" mindset. Any insight would be appreciated. > > ~Seth > From patrick at ianai.net Mon Jul 13 15:07:27 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 13 Jul 2009 16:07:27 -0400 Subject: Please do not CC NANOG when e-mailing Dean Anderson [was: Can someone from SORBS contact me offlist?] In-Reply-To: <1247513561.27995.6.camel@petrie> References: <1247513561.27995.6.camel@petrie> Message-ID: <14E40143-309D-44DB-8F82-00B9F7F281E6@ianai.net> [SNIP] Everyone, Please do not CC nanog at nanog.org when replying to one of Dean Anderson's ... uh ... missives[*]. We do not see the original, so by replying and CC'ing the list, you are helping him get his ... er ... message[*] to a wider audience. And if you have actually read any of his ... umm ... posts[*], then you should realize that is to the list's detriment. I'd suggest the same for other lists too, but definitely for NANOG related stuff. -- TTFN, patrick [*] I have been very careful to not call them what they really are for fear of the MLC. :) From adam.lafountain at googlemail.com Mon Jul 13 15:10:36 2009 From: adam.lafountain at googlemail.com (Adam LaFountain) Date: Mon, 13 Jul 2009 13:10:36 -0700 Subject: MGE UPS Systems Message-ID: > > I'm curious if anyone might know what the future of the MGE line of UPS > systems are. My concern is that they're dead-end since being merged into > APC, and APC wanting to sell me APC stuff. The problem I face is that my > facility was designed with separate equipment spaces, which is great for > normal electrical gear that can be backed against a wall, but not so > great for a product which is designed for the "everything goes in with > your racks" mindset. Any insight would be appreciated. I heard the MGE product set was designed to replace the "typical/old" UPS product sets, like the Silcon Series, and that APC branded units would be concentrated on the "Symmetra" product line. Keep in mind the Symmetras above around 30kva are self contained units that are really racked in the same rack as other equipment. From bbillon-nanog at splio.fr Mon Jul 13 15:14:29 2009 From: bbillon-nanog at splio.fr (Benjamin Billon) Date: Mon, 13 Jul 2009 22:14:29 +0200 Subject: MGE UPS Systems In-Reply-To: <91864382B2433640BA2A447041B3DBC30B46F4EB@wil-exmb01.bbtnet.com> References: <4A5B8E37.9030505@rollernet.us> <91864382B2433640BA2A447041B3DBC30B46F4EB@wil-exmb01.bbtnet.com> Message-ID: <4A5B95A5.7090904@splio.fr> Or are you talking about Eaton's? http://www.eaton.com/EatonCom/SearchResults/CT_136576 Dixon, Justin a ?crit : >> I'm curious if anyone might know what the future of the MGE line of >> > UPS > >> systems are. My concern is that they're dead-end since being merged >> > into > >> APC, and APC wanting to sell me APC stuff. The problem I face is that >> > my > >> facility was designed with separate equipment spaces, which is great >> > for > >> normal electrical gear that can be backed against a wall, but not so >> great for a product which is designed for the "everything goes in with >> your racks" mindset. Any insight would be appreciated. >> >> ~Seth >> > > It looks like they are still available in the product selector on the > APC website. > > http://www.apc.com/products/category.cfm?id=13 > http://www.apc.com/products/family/index.cfm?id=361 > http://www.apc.com/products/family/index.cfm?id=365 > > If you're wondering about long term someone from their sales dept. can > probably tell you if they plan to keep the product line or discontinue > it. > > > > > From jwininger at indianafiber.net Mon Jul 13 15:20:03 2009 From: jwininger at indianafiber.net (Jim Wininger) Date: Mon, 13 Jul 2009 16:20:03 -0400 Subject: Cisco 12000 series routers and IOS XR. Message-ID: Is anyone on the list running the Cisco 12000 Series routers with XR? We have a couple of these in our network and are having a few issues with them. Specifically the line cards will reboot for some unknown reason (12000-SIP-501). We recently replaced one of the cards and the new hardware (<6mo old) is doing the same thing. Anyone have issues with these routers? -- Jim Wininger From kwallace at pcconnection.com Mon Jul 13 15:23:26 2009 From: kwallace at pcconnection.com (Wallace Keith) Date: Mon, 13 Jul 2009 16:23:26 -0400 Subject: MGE UPS Systems In-Reply-To: <4A5B8E37.9030505@rollernet.us> References: <4A5B8E37.9030505@rollernet.us> Message-ID: <0E8773C725A1674E9F7B35EABB5EEEB105CEB5A2@MKA134.pcc.int> While I still have a bunch of MGE Comet systems running, we did take one electrical room and replace them with Symmetra PX's, It did require some conduit work as they were moved from the wall to the center (but they are not as deep as a Comet) , to give the required cleareances. These are not your typical bottom of the rack units (although they come in their own racks). We have them equipped for 125KVA Love the Comet's, I would check with APC regarding product lifecycle. -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Monday, July 13, 2009 3:43 PM To: nanog at nanog.org Subject: MGE UPS Systems I'm curious if anyone might know what the future of the MGE line of UPS systems are. My concern is that they're dead-end since being merged into APC, and APC wanting to sell me APC stuff. The problem I face is that my facility was designed with separate equipment spaces, which is great for normal electrical gear that can be backed against a wall, but not so great for a product which is designed for the "everything goes in with your racks" mindset. Any insight would be appreciated. ~Seth From damin at nacs.net Mon Jul 13 15:34:00 2009 From: damin at nacs.net (Gregory Boehnlein) Date: Mon, 13 Jul 2009 16:34:00 -0400 Subject: MGE UPS Systems In-Reply-To: <242F2337-DF0F-4A1D-BDA2-4B167599EB3E@beanfield.com> References: <4A5B8E37.9030505@rollernet.us> <242F2337-DF0F-4A1D-BDA2-4B167599EB3E@beanfield.com> Message-ID: <005b01ca03f9$44371100$cca53300$@net> > We have 3 big Comet systems, and we're absolutely delighted with > them. Their service is the best we receive from any vendor we deal > with. I'll second that. We have a 50 KVA MGE Comet and it has been rock solid, and their support is excellent. From gtb at slac.stanford.edu Mon Jul 13 15:37:34 2009 From: gtb at slac.stanford.edu (Buhrmaster, Gary) Date: Mon, 13 Jul 2009 13:37:34 -0700 Subject: MGE UPS Systems In-Reply-To: <4A5B95A5.7090904@splio.fr> References: <4A5B8E37.9030505@rollernet.us><91864382B2433640BA2A447041B3DBC30B46F4EB@wil-exmb01.bbtnet.com> <4A5B95A5.7090904@splio.fr> Message-ID: > Or are you talking about Eaton's? > > http://www.eaton.com/EatonCom/SearchResults/CT_136576 History (as I recall it). Schneider Electric bought MGE late 2003 Schneider Electric bought APC late 2006 (and merges APC/MGE product line, which has overlap) Schneider Electric sold "small" MGE product line to Eaton late 2007 (these are the office/small business type UPSs, as I recall, and overlapped the APC consumer/office/small business offerings). I do not know the plans regarding how Schneider Electric will deal with the remaining overlap in the high end APC/MGE UPS business. From Erik.Amundson at oati.net Mon Jul 13 15:48:51 2009 From: Erik.Amundson at oati.net (Erik Amundson) Date: Mon, 13 Jul 2009 15:48:51 -0500 Subject: MGE UPS Systems In-Reply-To: <4A5B8E37.9030505@rollernet.us> References: <4A5B8E37.9030505@rollernet.us> Message-ID: <635D17EE85D35A49B8F278998E6C340404A98B8EC7@EXVS.dev.oati.local> We asked our local APC rep that exact question last week. He told us that the MGE line of UPSes fill a whole that APC doesn't have in their own lineup, and they will continue being sold as the product for folks absolutely require a typical double-conversion online UPS. As opposed to the 'hybrid' model of the Symmetra... It didn't sound to me like they were planning on getting rid of the MGE line at this point. - Erik -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Monday, July 13, 2009 2:43 PM To: nanog at nanog.org Subject: MGE UPS Systems I'm curious if anyone might know what the future of the MGE line of UPS systems are. My concern is that they're dead-end since being merged into APC, and APC wanting to sell me APC stuff. The problem I face is that my facility was designed with separate equipment spaces, which is great for normal electrical gear that can be backed against a wall, but not so great for a product which is designed for the "everything goes in with your racks" mindset. Any insight would be appreciated. ~Seth From ryan.slater at tac.com Mon Jul 13 15:51:11 2009 From: ryan.slater at tac.com (ryan.slater at tac.com) Date: Mon, 13 Jul 2009 15:51:11 -0500 Subject: MGE UPS Systems In-Reply-To: References: Message-ID: Take this with the grain of salt that I do not work for APC, but for a sister company. The word that I have heard is that they are in no rush to discontinue any of the product line. In fact rumor is that APC was very happy to have the MGE products available to them for sale to customers. As a side note I have several MGE UPS in service and have had zero problem getting support and maintenance from APC for them. RS From scott at sberkman.net Mon Jul 13 16:37:15 2009 From: scott at sberkman.net (Scott Berkman) Date: Mon, 13 Jul 2009 17:37:15 -0400 Subject: Cisco 12000 series routers and IOS XR. In-Reply-To: References: Message-ID: <000f01ca0402$17390920$45ab1b60$@net> We have 2 12k's on our borders and both are running IOS GS code, but are rock solid. -Scott -----Original Message----- From: Jim Wininger [mailto:jwininger at indianafiber.net] Sent: Monday, July 13, 2009 4:20 PM To: nanog at nanog.org Subject: Cisco 12000 series routers and IOS XR. Is anyone on the list running the Cisco 12000 Series routers with XR? We have a couple of these in our network and are having a few issues with them. Specifically the line cards will reboot for some unknown reason (12000-SIP-501). We recently replaced one of the cards and the new hardware (<6mo old) is doing the same thing. Anyone have issues with these routers? -- Jim Wininger From web at typo.org Mon Jul 13 16:47:10 2009 From: web at typo.org (Wayne E. Bouchard) Date: Mon, 13 Jul 2009 14:47:10 -0700 Subject: MGE UPS Systems In-Reply-To: References: Message-ID: <20090713214710.GA81830@typo.org> See, now thats what I like to hear after an acquisition like this. You expect a certain redundancy but to have it said that, "we're not merely interested in the underlying technology, we like the products just the say they are and have no plans to change them (except maybe to standardize the management software interface," or something along those lines is a darned good thing. 'cause lemme tell ya, I like the MGE systems I have and am very glad to hear that APC thinks MGE gear is just ducky. -Wayne On Mon, Jul 13, 2009 at 03:51:11PM -0500, ryan.slater at tac.com wrote: > Take this with the grain of salt that I do not work for APC, but for a > sister company. The word that I have heard is that they are in no rush > to discontinue any of the product line. In fact rumor is that APC was > very happy to have the MGE products available to them for sale to > customers. As a side note I have several MGE UPS in service and have > had zero problem getting support and maintenance from APC for them. > > RS > > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From sliplever at gmail.com Mon Jul 13 17:15:52 2009 From: sliplever at gmail.com (Dan Snyder) Date: Mon, 13 Jul 2009 18:15:52 -0400 Subject: Cisco 12000 series routers and IOS XR. In-Reply-To: <000f01ca0402$17390920$45ab1b60$@net> References: <000f01ca0402$17390920$45ab1b60$@net> Message-ID: <1c2d53bb0907131515t4d3dadfbkc589ec85494b6dc8@mail.gmail.com> We also have a couple running full tables of BGP with XR code and they have been running solid for a couple of years now with no problems. -Dan On Mon, Jul 13, 2009 at 5:37 PM, Scott Berkman wrote: > We have 2 12k's on our borders and both are running IOS GS code, but are > rock solid. > > -Scott > > -----Original Message----- > From: Jim Wininger [mailto:jwininger at indianafiber.net] > Sent: Monday, July 13, 2009 4:20 PM > To: nanog at nanog.org > Subject: Cisco 12000 series routers and IOS XR. > > Is anyone on the list running the Cisco 12000 Series routers with XR? We > have a couple of these in our network and are having a few issues with > them. > > Specifically the line cards will reboot for some unknown reason > (12000-SIP-501). We recently replaced one of the cards and the new hardware > (<6mo old) is doing the same thing. > > Anyone have issues with these routers? > -- > Jim Wininger > > > > > From j at arpa.com Mon Jul 13 17:19:17 2009 From: j at arpa.com (jamie) Date: Mon, 13 Jul 2009 17:19:17 -0500 Subject: Please do not CC NANOG when e-mailing Dean Anderson [was: Can someone from SORBS contact me offlist?] In-Reply-To: <14E40143-309D-44DB-8F82-00B9F7F281E6@ianai.net> References: <1247513561.27995.6.camel@petrie> <14E40143-309D-44DB-8F82-00B9F7F281E6@ianai.net> Message-ID: <6ff30abd0907131519r56da7e0n70a917c124e272fd@mail.gmail.com> How about, "Don't reply to Dean Anderson". :-) On Mon, Jul 13, 2009 at 3:07 PM, Patrick W. Gilmore wrote: > [SNIP] > > Everyone, > > Please do not CC nanog at nanog.org when replying to one of Dean Anderson's > ... uh ... missives[*]. We do not see the original, so by replying and > CC'ing the list, you are helping him get his ... er ... message[*] to a > wider audience. And if you have actually read any of his ... umm ... > posts[*], then you should realize that is to the list's detriment. > > I'd suggest the same for other lists too, but definitely for NANOG related > stuff. > > -- > TTFN, > patrick > > [*] I have been very careful to not call them what they really are for fear > of the MLC. :) > > > From sethm at rollernet.us Mon Jul 13 18:32:20 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 13 Jul 2009 16:32:20 -0700 Subject: MGE UPS Systems In-Reply-To: References: Message-ID: <4A5BC404.5030400@rollernet.us> ryan.slater at tac.com wrote: > Take this with the grain of salt that I do not work for APC, but for a > sister company. The word that I have heard is that they are in no rush > to discontinue any of the product line. In fact rumor is that APC was > very happy to have the MGE products available to them for sale to > customers. As a side note I have several MGE UPS in service and have > had zero problem getting support and maintenance from APC for them. > Interesting. The reason I ask is that I'm kind of attracted to the MGE Galaxy and its paralleling N+1 capability. I had a bad experience with a frame shorting out a few years ago after it went into bypass but didn't shut off the inverter output; hilarity ensued. It seems like the Galaxy and Smart VT overlap, although the Galaxy has better specs on paper. I was also recommended a Symmetra PX 80kW frame. I asked my rep and they were kind of ambiguous about the MGE line, hence my redirect of the question here. ~Seth From jwininger at indianafiber.net Mon Jul 13 19:53:21 2009 From: jwininger at indianafiber.net (Jim Wininger) Date: Mon, 13 Jul 2009 20:53:21 -0400 Subject: Cisco 12000 series routers and IOS XR. In-Reply-To: <1c2d53bb0907131515t4d3dadfbkc589ec85494b6dc8@mail.gmail.com> Message-ID: What release are you running? We are currently at 3.6.2 (as recommended by Cisco (our SE and some upper levels)). On 7/13/09 6:15 PM, "Dan Snyder" wrote: > We also have a couple running full tables of BGP with XR code and they have > been running solid for a couple of years now with no problems. > > -Dan > > On Mon, Jul 13, 2009 at 5:37 PM, Scott Berkman wrote: >> We have 2 12k's on our borders and both are running IOS GS code, but are >> rock solid. >> >> ? ? ? ?-Scott >> >> -----Original Message----- >> From: Jim Wininger [mailto:jwininger at indianafiber.net] >> Sent: Monday, July 13, 2009 4:20 PM >> To: nanog at nanog.org >> Subject: Cisco 12000 series routers and IOS XR. >> >> Is anyone on the list running the Cisco 12000 Series routers with XR? We >> have a couple of these in our network and are having a few issues with them. >> >> Specifically the line cards will reboot for some unknown reason >> (12000-SIP-501). We recently replaced one of the cards and the new hardware >> (<6mo old) is doing the same thing. >> >> Anyone have issues with these routers? >> -- >> Jim Wininger >> >> >> >> > > -- Jim Wininger Indiana Fiber Network Desk - 317-777-7114 Cell - 317-432-7609 Office - 317-280-4636 CONFIDENTIALITY NOTICE: The information contained in this electronic mail transmission (including any attachment) is intended for the exclusive use of the named recipient and may contain information that is privileged or otherwise confidential. It is not intended for transmission to, or receipt by, anyone other than the named recipient (or person authorized to deliver it to the named recipient). It should not be copied or forwarded to any unauthorized person. If you have received this electronic mail transmission in error, please delete it from your system including any attachment without copying or forwarding it, and notify the sender of the error by return e-mail. From nanog at daork.net Mon Jul 13 20:05:19 2009 From: nanog at daork.net (Nathan Ward) Date: Tue, 14 Jul 2009 13:05:19 +1200 Subject: Public/testing 4to6 gateway? In-Reply-To: References: Message-ID: <59C47493-90A1-41EC-A0F3-A40E1D93E8FE@daork.net> On 14/07/2009, at 4:23 AM, Rick Ernst wrote: > Either they don't exist, or my Google-fu is particularly bad this > morning. > > I'm trying to get my toes wet with IPv6. I've established an internal > 6to4/4to6 tunnel. I'd also like to have a testbed for access to > public v6 > sites. I'm also trying to find some clue at my upstreams, but > figured I'd > ask here as well. Are there any 4to6 gateway available? I have > assigned v6 > space. Because I'm pedantic, 6to4 and 6in4 are two different things. It sounds like you want 6in4. They use the same encapsulation, but 6to4 has specific magic in how the outer IPv4 destination is built, taken from the inner IPv6 destination address. 6over4 is different again. I think someone wrote a draft explaining this a while back.. not sure where or what it was called. -- Nathan Ward From jeroen at unfix.org Tue Jul 14 01:45:45 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 14 Jul 2009 08:45:45 +0200 Subject: 6in4/6to4/6over4/etc (Was: Public/testing 4to6 gateway?) In-Reply-To: <59C47493-90A1-41EC-A0F3-A40E1D93E8FE@daork.net> References: <59C47493-90A1-41EC-A0F3-A40E1D93E8FE@daork.net> Message-ID: <4A5C2999.4000808@spaghetti.zurich.ibm.com> Nathan Ward wrote: [..] > I think someone wrote a draft explaining this a while back.. not sure > where or what it was called. http://en.wikipedia.org/wiki/6in4 = proto-41 http://en.wikipedia.org/wiki/6to4 = proto-41 with 2002::/16 dst http://fr.wikipedia.org/wiki/6rd = proto-41 with own 6to4 prefix http://en.wikipedia.org/wiki/6over4 = 6 over 4-multicast (*) Or for a list which also contains a few others: http://www.sixxs.net/faq/connectivity/?faq=comparison Greets, Jeroen * = the only one I really don't get and never saw used ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From nanog at shreddedmail.com Tue Jul 14 09:20:31 2009 From: nanog at shreddedmail.com (Rick Ernst) Date: Tue, 14 Jul 2009 07:20:31 -0700 Subject: Public/testing 4to6 gateway? In-Reply-To: <59C47493-90A1-41EC-A0F3-A40E1D93E8FE@daork.net> References: <59C47493-90A1-41EC-A0F3-A40E1D93E8FE@daork.net> Message-ID: Pedantry is not necessarily a bad thing, especially when the student doesn't know the right questions to ask. :) 6in4 is what I was looking for. Thanks, On Mon, Jul 13, 2009 at 6:05 PM, Nathan Ward wrote: > On 14/07/2009, at 4:23 AM, Rick Ernst wrote: > > Either they don't exist, or my Google-fu is particularly bad this morning. >> >> I'm trying to get my toes wet with IPv6. I've established an internal >> 6to4/4to6 tunnel. I'd also like to have a testbed for access to public v6 >> sites. I'm also trying to find some clue at my upstreams, but figured I'd >> ask here as well. Are there any 4to6 gateway available? I have assigned >> v6 >> space. >> > > > Because I'm pedantic, 6to4 and 6in4 are two different things. It sounds > like you want 6in4. > They use the same encapsulation, but 6to4 has specific magic in how the > outer IPv4 destination is built, taken from the inner IPv6 destination > address. > 6over4 is different again. > > I think someone wrote a draft explaining this a while back.. not sure where > or what it was called. > > -- > Nathan Ward > > > From setient at gmail.com Tue Jul 14 10:12:22 2009 From: setient at gmail.com (Ronald Cotoni) Date: Tue, 14 Jul 2009 10:12:22 -0500 Subject: several messages In-Reply-To: References: Message-ID: <2f1d68350907140812y3f2c1bbaj163b77fa7e8f9b51@mail.gmail.com> And I still have yet to get someone from sorbs to contact me off list. I wonder if they actually read email (highly doubtful at this point) From telmnstr at 757.org Tue Jul 14 10:17:20 2009 From: telmnstr at 757.org (telmnstr at 757.org) Date: Tue, 14 Jul 2009 11:17:20 -0400 (EDT) Subject: several messages In-Reply-To: <2f1d68350907140812y3f2c1bbaj163b77fa7e8f9b51@mail.gmail.com> References: <2f1d68350907140812y3f2c1bbaj163b77fa7e8f9b51@mail.gmail.com> Message-ID: > And I still have yet to get someone from sorbs to contact me off list. I > wonder if they actually read email (highly doubtful at this point) Same response that others have. They are garbage. It's pretty much hopeless. Time to relay mail through a server outside of the IP block in question. From graeme at graemef.net Tue Jul 14 10:20:57 2009 From: graeme at graemef.net (Graeme Fowler) Date: Tue, 14 Jul 2009 16:20:57 +0100 Subject: several messages In-Reply-To: <2f1d68350907140812y3f2c1bbaj163b77fa7e8f9b51@mail.gmail.com> References: <2f1d68350907140812y3f2c1bbaj163b77fa7e8f9b51@mail.gmail.com> Message-ID: <1247584857.4593.7.camel@ernie.internal.graemef.net> On Tue, 2009-07-14 at 10:12 -0500, "Ronald Cotoni" wrote: > And I still have yet to get someone from sorbs to contact me off list. I > wonder if they actually read email (highly doubtful at this point) I can almost guarantee that they don't subscribe to NANOG, so posting here will make next to no difference. As has already been pointed out, if you subscribe to SPAM-L and post there you are far more likely to get a response. That said, given the upheaval that SORBS is going through (which has also been pointed out) I'm not entirely surprised that other matters are more pressing for the proprietors. Graeme From sliplever at gmail.com Tue Jul 14 10:36:49 2009 From: sliplever at gmail.com (Dan Snyder) Date: Tue, 14 Jul 2009 11:36:49 -0400 Subject: Cisco 12000 series routers and IOS XR. In-Reply-To: References: <1c2d53bb0907131515t4d3dadfbkc589ec85494b6dc8@mail.gmail.com> Message-ID: <1c2d53bb0907140836n47301642r2cf4a2bba27d298a@mail.gmail.com> 3.4.2 On Mon, Jul 13, 2009 at 8:53 PM, Jim Wininger wrote: > What release are you running? We are currently at 3.6.2 (as recommended > by Cisco (our SE and some upper levels)). > > > > On 7/13/09 6:15 PM, "Dan Snyder" wrote: > > We also have a couple running full tables of BGP with XR code and they have > been running solid for a couple of years now with no problems. > > -Dan > > On Mon, Jul 13, 2009 at 5:37 PM, Scott Berkman wrote: > > We have 2 12k's on our borders and both are running IOS GS code, but are > rock solid. > > -Scott > > -----Original Message----- > From: Jim Wininger [mailto:jwininger at indianafiber.net] > Sent: Monday, July 13, 2009 4:20 PM > To: nanog at nanog.org > Subject: Cisco 12000 series routers and IOS XR. > > Is anyone on the list running the Cisco 12000 Series routers with XR? We > have a couple of these in our network and are having a few issues with > them. > > Specifically the line cards will reboot for some unknown reason > (12000-SIP-501). We recently replaced one of the cards and the new hardware > (<6mo old) is doing the same thing. > > Anyone have issues with these routers? > -- > Jim Wininger > > > > > > > > > -- > Jim Wininger > Indiana Fiber Network > Desk - 317-777-7114 > Cell - 317-432-7609 > Office - 317-280-4636 > > CONFIDENTIALITY NOTICE: The information contained in this electronic mail > transmission (including any attachment) is intended for the exclusive use of > the named recipient and may contain information that is privileged or > otherwise confidential. It is not intended for transmission to, or receipt > by, anyone other than the named recipient (or person authorized to deliver > it to the named recipient). It should not be copied or forwarded to any > unauthorized person. If you have received this electronic mail transmission > in error, please delete it from your system including any attachment without > copying or forwarding it, and notify the sender of the error by return > e-mail. > From jared at puck.nether.net Tue Jul 14 16:11:42 2009 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 14 Jul 2009 17:11:42 -0400 Subject: Metro Ethernet Provider in Atlanta Message-ID: <0ABC8EF0-B7A7-4ACA-ACF9-E60E71A6C67C@puck.nether.net> Can you please provide responses off-list? If someone wants a summary, I'm happy to post it later. Thanks, - Jared possible bonus points for having S&D be on-net. More details available. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Jul 14 16:47:53 2009 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 15 Jul 2009 07:17:53 +0930 Subject: Can someone from SORBS contact me offlist? In-Reply-To: <1247340858.12662.5.camel@petrie> References: <2f1d68350907110720r3cf5206bje455d01f35b41d10@mail.gmail.com> <75cb24520907110908y2314f872gc505765f26cb6d90@mail.gmail.com> <6eb799ab0907110934i42b1ef89n5374b0cb2801ffb4@mail.gmail.com> <20090711124533.39ac39fa@milhouse.peachfamily.net> <2f1d68350907111005m50bc2a98o756313fa3a90e640@mail.gmail.com> <4A58C7CD.30501@2mbit.com> <1247340858.12662.5.camel@petrie> Message-ID: <20090715071753.44cc7a2b.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> On Sat, 11 Jul 2009 14:34:18 -0500 William Pitcock wrote: > On Sat, 2009-07-11 at 11:11 -0600, Brielle Bruns wrote: > > On 7/11/09 11:05 AM, Ronald Cotoni wrote: > > > Yes, they are really bad. It is actually quite silly that a blacklisting > > > service is that slow on responding to problems. > > > > > Also, I believe SORBS are the ones that require a donation to get out if ^^^^^^^^^^^^^^^^^^ A 'required donation' sounds like a ransom to me. From patrick at ianai.net Tue Jul 14 16:58:35 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 14 Jul 2009 17:58:35 -0400 Subject: Can someone from SORBS contact me offlist? In-Reply-To: <20090715071753.44cc7a2b.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> References: <2f1d68350907110720r3cf5206bje455d01f35b41d10@mail.gmail.com> <75cb24520907110908y2314f872gc505765f26cb6d90@mail.gmail.com> <6eb799ab0907110934i42b1ef89n5374b0cb2801ffb4@mail.gmail.com> <20090711124533.39ac39fa@milhouse.peachfamily.net> <2f1d68350907111005m50bc2a98o756313fa3a90e640@mail.gmail.com> <4A58C7CD.30501@2mbit.com> <1247340858.12662.5.camel@petrie> <20090715071753.44cc7a2b.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Message-ID: <2A01D035-F542-4170-9957-B4A191205F54@ianai.net> On Jul 14, 2009, at 5:47 PM, Mark Smith wrote: > On Sat, 11 Jul 2009 14:34:18 -0500 > William Pitcock wrote: > On Sat, 2009-07-11 at 11:11 -0600, Brielle Bruns wrote: >>> On 7/11/09 11:05 AM, Ronald Cotoni wrote: >>>> Yes, they are really bad. It is actually quite silly that a >>>> blacklisting >>>> service is that slow on responding to problems. >>> >> >> >> Also, I believe SORBS are the ones that require a donation to get >> out if > > A 'required donation' sounds like a ransom to me. You make the donation to a "registered charity", not to SORBS. Michelle never sees a dime, nor does anyone else associated with SORBS. You can still call it a ransom if you like, I won't even argue, but in fairness I thought it was useful to make that distinction. In more fairness, last time I checked, all but one of the 'registered charities' asked to be removed from the SORBS list because it was doing them more harm than good. Interpretation of these facts is left up to the reader, I am not making any judgements. -- TTFN, patrick From jlewis at lewis.org Tue Jul 14 18:35:46 2009 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 14 Jul 2009 19:35:46 -0400 (EDT) Subject: Can someone from SORBS contact me offlist? In-Reply-To: <20090715071753.44cc7a2b.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> References: <2f1d68350907110720r3cf5206bje455d01f35b41d10@mail.gmail.com> <75cb24520907110908y2314f872gc505765f26cb6d90@mail.gmail.com> <6eb799ab0907110934i42b1ef89n5374b0cb2801ffb4@mail.gmail.com> <20090711124533.39ac39fa@milhouse.peachfamily.net> <2f1d68350907111005m50bc2a98o756313fa3a90e640@mail.gmail.com> <4A58C7CD.30501@2mbit.com> <1247340858.12662.5.camel@petrie> <20090715071753.44cc7a2b.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Message-ID: On Wed, 15 Jul 2009, Mark Smith wrote: >>>> Yes, they are really bad. It is actually quite silly that a blacklisting >>>> service is that slow on responding to problems. >>> >> Also, I believe SORBS are the ones that require a donation to get out if > > A 'required donation' sounds like a ransom to me. AFAIK, the donation requirement is for getting IPs off the "your IP has sent us spam" subzone of the SORBS dnsbl. Most of the people I'm aware of who've had issues with SORBS have wanted to get incorrect listings removed from the SORBS DUL dul.dnsbl.sorbs.net - Dynamic IP Address ranges (NOT a Dial Up list!) Donations won't help you there. Shouldn't someone have tried steering this thread over to spam-l or someplace other than nanog a day or two ago? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bonomi at mail.r-bonomi.com Tue Jul 14 19:57:01 2009 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Tue, 14 Jul 2009 19:57:01 -0500 (CDT) Subject: Can someone from SORBS contact me offlist? Message-ID: <200907150057.n6F0v1QU022690@mail.r-bonomi.com> > From: "Patrick W. Gilmore" > Date: Tue, 14 Jul 2009 17:58:35 -0400 > > On Jul 14, 2009, at 5:47 PM, Mark Smith wrote: > > On Sat, 11 Jul 2009 14:34:18 -0500 > > William Pitcock wrote: > > On Sat, 2009-07-11 at 11:11 -0600, Brielle Bruns wrote: > >>> On 7/11/09 11:05 AM, Ronald Cotoni wrote: > >>>> Yes, they are really bad. It is actually quite silly that a > >>>> blacklisting service is that slow on responding to problems. > >>> > >> > >> > >> Also, I believe SORBS are the ones that require a donation to get > >> out if > > > > A 'required donation' sounds like a ransom to me. > > You make the donation to a "registered charity", not to SORBS. > Michelle never sees a dime, nor does anyone else associated with SORBS. Note: the -only- thing the charitable donation 'buys' is "expedited processing" of the removal request. If the "problem" still exists, then the listing is not removed. It's not like you can 'buy your way off' the list. > You can still call it a ransom if you like, I won't even argue, but in > fairness I thought it was useful to make that distinction. 'Ransom' is _not_ an accurate description. Among other things it implies that the ransomer has possession of your property and you are paying for it's safe return. The 'best-fit' technical term would be 'extortion' -- SORBS operator _has_ consulted professional counsel on the matter, and has reason to believe that the exact form of what they do _is_ within the law. (I've had direct conversations with Michelle on that specific point -- it's 'closer to the line' than _I_ would care to operate. :) I mention that strictly from the standpoint that those who use descriptive terms which carry an implication of 0 action are _themselves_ likely crossing the line as regards libel/slander/defamation. Lastly, I'm going to suggest that this is drifting rather afar OT from the charter of the group, and suggest that the MLM may want to put the kibosh on this thread. From esavage at digitalrage.org Tue Jul 14 21:21:29 2009 From: esavage at digitalrage.org (Elijah Savage) Date: Tue, 14 Jul 2009 22:21:29 -0400 Subject: "OT" Sprint Outsourced It's Entire Network Wireless and Wireline? Message-ID: I had been told about the wireless business but the bottom of this announcement says wireline also. How did I miss this announcement? http://news.cnet.com/8301-1035_3-10283799-94.html From sethm at rollernet.us Tue Jul 14 21:24:19 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 14 Jul 2009 19:24:19 -0700 Subject: "OT" Sprint Outsourced It's Entire Network Wireless and Wireline? In-Reply-To: References: Message-ID: <4A5D3DD3.7040302@rollernet.us> Elijah Savage wrote: > I had been told about the wireless business but the bottom of this > announcement says wireline also. How did I miss this announcement? > > http://news.cnet.com/8301-1035_3-10283799-94.html > That's news to me. At the same time, I've been having trouble getting in touch with my Sprint(link) rep over the last week. ~Seth From chris.taylor at sohonet.co.uk Wed Jul 15 03:51:18 2009 From: chris.taylor at sohonet.co.uk (Chris Taylor) Date: Wed, 15 Jul 2009 09:51:18 +0100 Subject: Issues accessing hulu.com from new(ish) US range Message-ID: <4A5D9886.7080302@sohonet.co.uk> Would someone from hulu.com please contact me offlist? Alternatively, if anyone has contact details for a vaguely clueful person there, that would be appreciated. We had a new range allocated to us by ARIN around 6 months ago for our US business, and hulu are claiming it's non-us. Our guess is that it's a canned response by first-line support. Also, does anyone happen to know which geolocation databases hulu use? Thanks, Chris From ml at kenweb.org Wed Jul 15 06:15:29 2009 From: ml at kenweb.org (ML) Date: Wed, 15 Jul 2009 07:15:29 -0400 Subject: Issues accessing hulu.com from new(ish) US range In-Reply-To: <4A5D9886.7080302@sohonet.co.uk> References: <4A5D9886.7080302@sohonet.co.uk> Message-ID: <4A5DBA51.8060703@kenweb.org> Chris Taylor wrote: > Would someone from hulu.com please contact me offlist? > > Alternatively, if anyone has contact details for a vaguely clueful > person there, that would be appreciated. > > We had a new range allocated to us by ARIN around 6 months ago for our > US business, and hulu are claiming it's non-us. Our guess is that it's a > canned response by first-line support. > > Also, does anyone happen to know which geolocation databases hulu use? > > > Thanks, > Chris > Did you Swip the block? https://www.arin.net/resources/request/reassignments.html From charlie at playlouder.com Wed Jul 15 06:29:22 2009 From: charlie at playlouder.com (Charlie Allom) Date: Wed, 15 Jul 2009 12:29:22 +0100 Subject: Swedish bittorrent dropped 40Gbps with an EU law? (DCMA -like) Message-ID: <20090715112922.GB60773@eatyourpets.com> Hello, I am interested in a claim made[1] that with the implementation of EU Directive 2004/48/EC [2] that Swedish traffic dropped 40Gb/s: http://stats.autonomica.se/mrtg/sums/All.html Could this really mean that everyone in Sweden just 'turned off their bittorrent clients' on the 1st of April? It seems to me that its more likely a large peer has pulled out or closed a service. Does anyone have some interesting ideas on where to get a more balanced view on where that traffic went on the 1st of April? If you look at AMS-IX and LINX, there is a dip - but its hard to see from so high up. https://stats.linx.net/cgi-pub/aggregate-year https://www.ams-ix.net/technical/stats/cgi-bin/16all?log=totalall;png=yearly Perhaps also there is a cultural difference with Swedes being more prone to follow the law? Like a speed camera effect. What do people think? 1. http://www.swedishwire.com/business/506-illegal-filesharing-dives-in-sweden 2. http://en.wikipedia.org/wiki/Directive_on_the_enforcement_of_intellectual_property_rights -- 020 7729 4797 http://blog.playlouder.com/ From tme at americafree.tv Wed Jul 15 06:43:30 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Wed, 15 Jul 2009 07:43:30 -0400 Subject: Swedish bittorrent dropped 40Gbps with an EU law? (DCMA -like) In-Reply-To: <20090715112922.GB60773@eatyourpets.com> References: <20090715112922.GB60773@eatyourpets.com> Message-ID: <9EA16F51-6A78-454C-A557-568E587019E5@americafree.tv> On Jul 15, 2009, at 7:29 AM, Charlie Allom wrote: > Hello, > > I am interested in a claim made[1] that with the implementation of > EU Directive 2004/48/EC [2] that Swedish traffic dropped 40Gb/s: > > http://stats.autonomica.se/mrtg/sums/All.html > > Could this really mean that everyone in Sweden just 'turned off their > bittorrent clients' on the 1st of April? It seems to me that its more > likely a large peer has pulled out or closed a service. > > Does anyone have some interesting ideas on where to get a more > balanced > view on where that traffic went on the 1st of April? > > If you look at AMS-IX and LINX, there is a dip - but its hard to see > from > so high up. > https://stats.linx.net/cgi-pub/aggregate-year > https://www.ams-ix.net/technical/stats/cgi-bin/16all?log=totalall;png=yearly > > Perhaps also there is a cultural difference with Swedes being more > prone to follow the law? Like a speed camera effect. > > What do people think? That statistics are rarely manipulated as aggressively as they are in the P2P / filesharing wars. Regards Marshall > > > 1. http://www.swedishwire.com/business/506-illegal-filesharing-dives-in-sweden > 2. http://en.wikipedia.org/wiki/Directive_on_the_enforcement_of_intellectual_property_rights > > -- > 020 7729 4797 > http://blog.playlouder.com/ > > From sean at donelan.com Wed Jul 15 07:07:08 2009 From: sean at donelan.com (Sean Donelan) Date: Wed, 15 Jul 2009 08:07:08 -0400 (EDT) Subject: Shortest path to the world Message-ID: <200907150743330.32BF5B92.21943@clifden.donelan.com> The typical network architecture problem, what are the best (shortest latency, greatest bandwidth, etc) locations to connect to the every nation in the world? As you increase the number of locations, how do the choices change? If you only had small (2 3 5 7 11) number of locations, where would they be? And what data do you have to prove the choices are best? From jeroen at unfix.org Wed Jul 15 07:18:46 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 15 Jul 2009 14:18:46 +0200 Subject: Shortest path to the world In-Reply-To: <200907150743330.32BF5B92.21943@clifden.donelan.com> References: <200907150743330.32BF5B92.21943@clifden.donelan.com> Message-ID: <4A5DC926.6090004@spaghetti.zurich.ibm.com> Sean Donelan wrote: > The typical network architecture problem, what are the best (shortest > latency, greatest bandwidth, etc) locations to connect to the every > nation in the world? As you increase the number of locations, how do > the choices change? > > If you only had small (2 3 5 7 11) number of locations, where would they > be? Depends completely on what the data is and why you want to send them from A to B and if A and B are inside your network or not etc etc etc etc. aka ETOOMANYVARIABLES. > And what data do you have to prove the choices are best? Depends of course on what you want to 'prove' But things that come into mind are possibly: - Netflow/sFlow and other such data - latency tests (simple pings from A to B to global services that check latency, eg RIPE TTM boxes) - Cost for circuits - and lots lots more. It all depends, thus also how you combine the above ;) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From randy at psg.com Wed Jul 15 08:03:56 2009 From: randy at psg.com (Randy Bush) Date: Wed, 15 Jul 2009 22:03:56 +0900 Subject: Shortest path to the world In-Reply-To: <200907150743330.32BF5B92.21943@clifden.donelan.com> References: <200907150743330.32BF5B92.21943@clifden.donelan.com> Message-ID: > The typical network architecture problem, what are the best (shortest > latency, greatest bandwidth, etc) locations to connect to the every > nation in the world? As you increase the number of locations, how do the > choices change? > > If you only had small (2 3 5 7 11) number of locations, where would they > be? > > And what data do you have to prove the choices are best? it would help if you said how you measure 'best' or 'better'. if you had a completely free hand, what experiment would you set up to measure this space? randy From chris.taylor at sohonet.co.uk Wed Jul 15 08:06:54 2009 From: chris.taylor at sohonet.co.uk (Chris Taylor) Date: Wed, 15 Jul 2009 14:06:54 +0100 Subject: Issues accessing hulu.com from new(ish) US range In-Reply-To: <4A5DBA51.8060703@kenweb.org> References: <4A5D9886.7080302@sohonet.co.uk> <4A5DBA51.8060703@kenweb.org> Message-ID: <4A5DD46E.6050909@sohonet.co.uk> ML wrote: > Chris Taylor wrote: >> Would someone from hulu.com please contact me offlist? >> >> Alternatively, if anyone has contact details for a vaguely clueful >> person there, that would be appreciated. >> >> We had a new range allocated to us by ARIN around 6 months ago for our >> US business, and hulu are claiming it's non-us. Our guess is that it's >> a canned response by first-line support. >> >> Also, does anyone happen to know which geolocation databases hulu use? >> >> >> Thanks, >> Chris >> > > Did you Swip the block? > > https://www.arin.net/resources/request/reassignments.html > > Pretty certain we've done this. It wasn't myself that did it, but if I'm reading that page correctly, it updates the whois database, and that returns our US company details. Also, ip2location.com and ipinfodb.com both report a selection of IP's in the range to be US IP's. Thanks, Chris From frnkblk at iname.com Wed Jul 15 08:58:56 2009 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Wed, 15 Jul 2009 08:58:56 -0500 Subject: Issues accessing hulu.com from new(ish) US range In-Reply-To: <4A5D9886.7080302@sohonet.co.uk> References: <4A5D9886.7080302@sohonet.co.uk> Message-ID: A few others I would check: - Akamai (you can contact them via their web page, but there are also people on this listserv that can check, too) - Google (if their search pages comes up in American English, you're good to go, otherwise there's info in their help that will let you fill out a form) - MaxMind (there's a contact form on their web page) Contact me offline if you want a list of (more minor) GeoIP sites I have bookmarked. Frank -----Original Message----- From: Chris Taylor [mailto:chris.taylor at sohonet.co.uk] Sent: Wednesday, July 15, 2009 3:51 AM To: nanog at nanog.org Subject: Issues accessing hulu.com from new(ish) US range Would someone from hulu.com please contact me offlist? Alternatively, if anyone has contact details for a vaguely clueful person there, that would be appreciated. We had a new range allocated to us by ARIN around 6 months ago for our US business, and hulu are claiming it's non-us. Our guess is that it's a canned response by first-line support. Also, does anyone happen to know which geolocation databases hulu use? Thanks, Chris From zeusdadog at gmail.com Wed Jul 15 09:18:28 2009 From: zeusdadog at gmail.com (Jay Nakamura) Date: Wed, 15 Jul 2009 10:18:28 -0400 Subject: AT&T and having two BGP peers In-Reply-To: <9418aca70907101048h452520b0sd8681585e4b2709f@mail.gmail.com> References: <9418aca70907101048h452520b0sd8681585e4b2709f@mail.gmail.com> Message-ID: <9418aca70907150718ja12af72k79fc696a6541960a@mail.gmail.com> All, Thanks for the help. I just got word that AT&T approved the two BGP peering with us. I think telling them others have done it with AT&T helped. Much appreciated. -Jay On Fri, Jul 10, 2009 at 1:48 PM, Jay Nakamura wrote: > We are getting an Ethernet DIA circuit from AT&T but they insist that > they can't BGP peer with 2 routers on our side. ?The WAN circuit can > only have /30 they say. ?Has anyone been able to successfully talk > them in to bending their rule? ?If so, how? > > I know this should have been negotiated before signing a contract but > I was unfortunately not in the loop... :( > > It seems like a ridiculous bureaucratic restriction. > From woody at pch.net Wed Jul 15 10:49:22 2009 From: woody at pch.net (Bill Woodcock) Date: Wed, 15 Jul 2009 08:49:22 -0700 Subject: Shortest path to the world In-Reply-To: <200907150743330.32BF5B92.21943@clifden.donelan.com> References: <200907150743330.32BF5B92.21943@clifden.donelan.com> Message-ID: <04771E52-A7E5-4DFD-BEAF-6A063BA32FB0@pch.net> On Jul 15, 2009, at 5:07 AM, Sean Donelan wrote: > The typical network architecture problem, what are the best > (shortest latency, greatest bandwidth, etc) locations to connect to > the every nation in the world? As you increase the number of > locations, how do the choices change? > If you only had small (2 3 5 7 11) number of locations, where would > they be? > And what data do you have to prove the choices are best? As others have noted, this is a many-variables sort of problem, and to answer it well requires nailing down a few of those variables by combining the statistical output of netflow from your border routers with knowledge of the routing tables available at each potential IXP gleaned from looking-glasses at those IXes. ( http://pch.net/routing-tables being the source of such data that I can offer; the RIPE RIS program does the same thing with a partially-overlapping and partially-unique dataset; the union of the two gives the most complete available picture.) However, if one wanted the beginnings of an answer, without nailing down any of the specifics, merely looking at the quantity of routes available at each IXP would let you know, on average, how many paths there were on offer to each destination. In all likelihood, different paths available to a given destination will be of different lengths. The more paths available to each destination, the greater the likelihood that one path will be shorter than others or, more to the point, shorter than your current shortest. ( https://prefix.pch.net/applications/ixpdir/?show_active_only=0&sort=prefixes&order=desc or just go to http://pch.net/ixpdir and sort by prefixes. Only a router with a full mesh of peers at an IXP could actually show _all_ of the available routes at an IXP, so nearly all views of this sort will be substantially incomplete; take with a healthy dose of skepticism, and please let me know if you find more complete public sources.) -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From chris.taylor at sohonet.co.uk Wed Jul 15 11:24:44 2009 From: chris.taylor at sohonet.co.uk (Chris Taylor) Date: Wed, 15 Jul 2009 17:24:44 +0100 Subject: Issues accessing hulu.com from new(ish) US range In-Reply-To: References: <4A5D9886.7080302@sohonet.co.uk> Message-ID: <4A5E02CC.6040109@sohonet.co.uk> Frank Bulk - iName.com wrote: > A few others I would check: > - Akamai (you can contact them via their web page, but there are also people > on this listserv that can check, too) > - Google (if their search pages comes up in American English, you're good to > go, otherwise there's info in their help that will let you fill out a form) > - MaxMind (there's a contact form on their web page) > > Contact me offline if you want a list of (more minor) GeoIP sites I have > bookmarked. > > Frank Thanks for that Frank. I've had contacts from Akamai and a couple of others off-list now. I've also checked MaxMind - their database appears to be up to date as well. I can't check Google at this second, as I'm based in the UK - I'll be setting something up for such tests tonight or tomorrow, but I seem to remember that we've previously spoken to them about it. Thanks, Chris > > -----Original Message----- > From: Chris Taylor [mailto:chris.taylor at sohonet.co.uk] > Sent: Wednesday, July 15, 2009 3:51 AM > To: nanog at nanog.org > Subject: Issues accessing hulu.com from new(ish) US range > > Would someone from hulu.com please contact me offlist? > > Alternatively, if anyone has contact details for a vaguely clueful > person there, that would be appreciated. > > We had a new range allocated to us by ARIN around 6 months ago for our > US business, and hulu are claiming it's non-us. Our guess is that it's a > canned response by first-line support. > > Also, does anyone happen to know which geolocation databases hulu use? > > > Thanks, > Chris > > -- Chris Taylor Engineer Sohonet Limited 60 Poland Street London W1F 7NT t +44 (0)2072926909 m +44 (0)7919897978 f +44 (0)2072926901 From alexb at ripe.net Wed Jul 15 13:55:25 2009 From: alexb at ripe.net (Alex Band) Date: Wed, 15 Jul 2009 20:55:25 +0200 Subject: New IPv6 Interview: David Freedman of Claranet Message-ID: We recently added another IPv6 interview to our ipv6actnow.org and youtube pages. This time David Freedman talks about their planning and deployment, including addressing plans and training, as well as the MPLS issues that they faced. http://www.youtube.com/watch?v=HQtbz1ahRxE We plan to have interviews with Google up soon, as well as XS4ALL; the dutch ADSL provider who started rolling out IPv6 capable CPEs. Enjoy, Alex From martin at theicelandguy.com Wed Jul 15 14:19:43 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Wed, 15 Jul 2009 15:19:43 -0400 Subject: Can someone from SORBS contact me offlist? In-Reply-To: <200907150057.n6F0v1QU022690@mail.r-bonomi.com> References: <200907150057.n6F0v1QU022690@mail.r-bonomi.com> Message-ID: On Tue, Jul 14, 2009 at 8:57 PM, Robert Bonomi wrote: [ clip ] > > > Lastly, I'm going to suggest that this is drifting rather afar OT from > the charter of the group, and suggest that the MLM may want to put the > kibosh on this thread. > > > That's exactly what happened the last time we discussed the SORBS fine: http://markmail.org/message/wfg57scjoucs4mpp#query:+page:1+mid:pv6knw5ydjvxv3l2+state:results -M< -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From mike.lyon at gmail.com Wed Jul 15 16:52:44 2009 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 15 Jul 2009 14:52:44 -0700 Subject: The actual value, from a security standpoint, of using a proxy domain registrar? Message-ID: <1b5c1c150907151452k52093694mc8b93538b4707f87@mail.gmail.com> Howdy, I am curious what others in the industry think on this topic. When one registers a domain they can put in their real information or they can use a proxy, like Go-Daddy's Domains By Proxy. Now, personally, I would prefer just to get a PO Box and put that address on my domain info instead of doing a proxy. I could also put down a phone number in the registration that just goes to my general business phone line which is just a DVR. So the question I have is this: What actual security are these proxy companies providing to the end-user? My company website has my real address, my real phone number, exec bio's and pictures of them yet upper management (and our marketing company) think using a proxy is a good thing. What's the difference between using a proxy vs using a PO Box except that a PO Box is cheaper? I'd just like to get thoughts from others to see what the general feeling is on this topic. Cheers, Mike From Ray.Sanders at VillageVoiceMedia.com Wed Jul 15 17:13:26 2009 From: Ray.Sanders at VillageVoiceMedia.com (Ray Sanders) Date: Wed, 15 Jul 2009 15:13:26 -0700 Subject: The actual value, from a security standpoint, of using a proxy domain registrar? In-Reply-To: <1b5c1c150907151452k52093694mc8b93538b4707f87@mail.gmail.com> References: <1b5c1c150907151452k52093694mc8b93538b4707f87@mail.gmail.com> Message-ID: <1247696006.20069.105.camel@artoo.vvmedia.com> My opinion is that it's nothing more than a "value-add" for domain registrars. The domain registration fees these days have razor thin margins. So places like Godaddy and others offer these services to make up for their domains essentially being "loss-leaders". A lot of these places use scare tactics to convince domain buyers that "privacy" is essential, otherwise one would get spam, telemarketing calls and junk mail. Well, that's partly true, as some companies do scrape whois data. So does maintaining a P.O box, a phone number that goes direct to voice mail, as well as a separate "junk mail" email account cost you less than about $20 a year? I'm not sure, but having your number on the do not call list (if you are in the U.S) is free, receiving junk mail doesn't cost anything and neither does a hotmail/yahoo/gmail account. So, to get to my point, from a "security" standpoint my opinion is that domain "privacy" is of as much benefit as hiding under the covers of my bed if an attacker breaks into my home. On Wed, 2009-07-15 at 14:52 -0700, Mike Lyon wrote: > Howdy, > > I am curious what others in the industry think on this topic. When one > registers a domain they can put in their real information or they can use a > proxy, like Go-Daddy's Domains By Proxy. > > Now, personally, I would prefer just to get a PO Box and put that address on > my domain info instead of doing a proxy. I could also put down a phone > number in the registration that just goes to my general business phone line > which is just a DVR. > > So the question I have is this: What actual security are these proxy > companies providing to the end-user? My company website has my real > address, my real phone number, exec bio's and pictures of them yet upper > management (and our marketing company) think using a proxy is a good thing. > > What's the difference between using a proxy vs using a PO Box except that a > PO Box is cheaper? > > I'd just like to get thoughts from others to see what the general feeling is > on this topic. > > Cheers, > Mike -- "Prediction is very difficult, especially about the future." Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344 From dave at mvn.net Wed Jul 15 17:18:28 2009 From: dave at mvn.net (David E. Smith) Date: Wed, 15 Jul 2009 17:18:28 -0500 Subject: The actual value, from a security standpoint, of using a proxy domain registrar? In-Reply-To: <1b5c1c150907151452k52093694mc8b93538b4707f87@mail.gmail.com> References: <1b5c1c150907151452k52093694mc8b93538b4707f87@mail.gmail.com> Message-ID: <4A5E55B4.9030205@mvn.net> Mike Lyon wrote: > I am curious what others in the industry think on this topic. When one > registers a domain they can put in their real information or they can use a > proxy, like Go-Daddy's Domains By Proxy. > If you're using it for your business, the value is pretty slim. You probably want your business to be reachable by the public. Individuals, especially those using their domains to publish anything controversial, could benefit somewhat from the increased privacy. David Smith MVN.net From Ray.Sanders at VillageVoiceMedia.com Wed Jul 15 17:34:57 2009 From: Ray.Sanders at VillageVoiceMedia.com (Ray Sanders) Date: Wed, 15 Jul 2009 15:34:57 -0700 Subject: The actual value, from a security standpoint, of using a proxy domain registrar? In-Reply-To: <4A5E55B4.9030205@mvn.net> References: <1b5c1c150907151452k52093694mc8b93538b4707f87@mail.gmail.com> <4A5E55B4.9030205@mvn.net> Message-ID: <1247697297.20069.120.camel@artoo.vvmedia.com> And that falls right into some of the scare tactic sales pitches the domain registrars use. "they can look up your domain and find your home address!" Heck, even a p.o box could leave someone open to a stalker, if said stalker is determined enough. so yes, I'll concede that point to a certain extent. On Wed, 2009-07-15 at 17:18 -0500, David E. Smith wrote: > Mike Lyon wrote: > > I am curious what others in the industry think on this topic. When one > > registers a domain they can put in their real information or they can use a > > proxy, like Go-Daddy's Domains By Proxy. > > > If you're using it for your business, the value is pretty slim. You > probably want your business to be reachable by the public. > > Individuals, especially those using their domains to publish anything > controversial, could benefit somewhat from the increased privacy. > > David Smith > MVN.net > > -- "Prediction is very difficult, especially about the future." Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344 From mike.lyon at gmail.com Wed Jul 15 17:37:51 2009 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 15 Jul 2009 15:37:51 -0700 Subject: The actual value, from a security standpoint, of using a proxy domain registrar? In-Reply-To: <1247697297.20069.120.camel@artoo.vvmedia.com> References: <1b5c1c150907151452k52093694mc8b93538b4707f87@mail.gmail.com> <4A5E55B4.9030205@mvn.net> <1247697297.20069.120.camel@artoo.vvmedia.com> Message-ID: <1b5c1c150907151537q1cece76eq2cceef3de2943a37@mail.gmail.com> I still think it's a huge waste of money. On Wed, Jul 15, 2009 at 3:34 PM, Ray Sanders < Ray.Sanders at villagevoicemedia.com> wrote: > And that falls right into some of the scare tactic sales pitches the > domain registrars use. > > "they can look up your domain and find your home address!" > > Heck, even a p.o box could leave someone open to a stalker, if said > stalker is determined enough. > > so yes, I'll concede that point to a certain extent. > > > On Wed, 2009-07-15 at 17:18 -0500, David E. Smith wrote: > > Mike Lyon wrote: > > > I am curious what others in the industry think on this topic. When one > > > registers a domain they can put in their real information or they can > use a > > > proxy, like Go-Daddy's Domains By Proxy. > > > > > If you're using it for your business, the value is pretty slim. You > > probably want your business to be reachable by the public. > > > > Individuals, especially those using their domains to publish anything > > controversial, could benefit somewhat from the increased privacy. > > > > David Smith > > MVN.net > > > > > -- > "Prediction is very difficult, especially about the future." Niels Bohr > -- > Ray Sanders > Linux Administrator > Village Voice Media > Office: 602-744-6547 > Cell: 602-300-4344 > > From jeremy at hq.newdream.net Wed Jul 15 17:40:17 2009 From: jeremy at hq.newdream.net (Jeremy Hanmer) Date: Wed, 15 Jul 2009 15:40:17 -0700 Subject: The actual value, from a security standpoint, of using a proxy domain registrar? In-Reply-To: <1b5c1c150907151537q1cece76eq2cceef3de2943a37@mail.gmail.com> References: <1b5c1c150907151452k52093694mc8b93538b4707f87@mail.gmail.com> <4A5E55B4.9030205@mvn.net> <1247697297.20069.120.camel@artoo.vvmedia.com> <1b5c1c150907151537q1cece76eq2cceef3de2943a37@mail.gmail.com> Message-ID: Not everybody charges for the service. Shop around. On Jul 15, 2009, at 3:37 PM, Mike Lyon wrote: > I still think it's a huge waste of money. > > > On Wed, Jul 15, 2009 at 3:34 PM, Ray Sanders < > Ray.Sanders at villagevoicemedia.com> wrote: > >> And that falls right into some of the scare tactic sales pitches the >> domain registrars use. >> >> "they can look up your domain and find your home address!" >> >> Heck, even a p.o box could leave someone open to a stalker, if said >> stalker is determined enough. >> >> so yes, I'll concede that point to a certain extent. >> >> >> On Wed, 2009-07-15 at 17:18 -0500, David E. Smith wrote: >>> Mike Lyon wrote: >>>> I am curious what others in the industry think on this topic. >>>> When one >>>> registers a domain they can put in their real information or they >>>> can >> use a >>>> proxy, like Go-Daddy's Domains By Proxy. >>>> >>> If you're using it for your business, the value is pretty slim. You >>> probably want your business to be reachable by the public. >>> >>> Individuals, especially those using their domains to publish >>> anything >>> controversial, could benefit somewhat from the increased privacy. >>> >>> David Smith >>> MVN.net >>> >>> >> -- >> "Prediction is very difficult, especially about the future." Niels >> Bohr >> -- >> Ray Sanders >> Linux Administrator >> Village Voice Media >> Office: 602-744-6547 >> Cell: 602-300-4344 >> >> > From shrdlu at deaddrop.org Wed Jul 15 17:43:24 2009 From: shrdlu at deaddrop.org (Etaoin Shrdlu) Date: Wed, 15 Jul 2009 15:43:24 -0700 Subject: The actual value, from a security standpoint, of using a proxy domain registrar? In-Reply-To: <1b5c1c150907151452k52093694mc8b93538b4707f87@mail.gmail.com> References: <1b5c1c150907151452k52093694mc8b93538b4707f87@mail.gmail.com> Message-ID: <4A5E5B8C.2010302@deaddrop.org> Mike Lyon wrote: > Howdy, > > I am curious what others in the industry think on this topic. When one > registers a domain they can put in their real information or they can use a > proxy, like Go-Daddy's Domains By Proxy. > > Now, personally, I would prefer just to get a PO Box and put that address on > my domain info instead of doing a proxy. I could also put down a phone > number in the registration that just goes to my general business phone line > which is just a DVR. [snip] > What's the difference between using a proxy vs using a PO Box except that a > PO Box is cheaper? As others have already said, it doesn't really provide any security. In addition, it makes the company doing it appear amateurish. One expects professional behavior from a company. There are certainly reasons one might choose to obscure the ownership of a domain, but none of them are sound business reasons. For the sake of your management, pick a few domains at random, do a whois on them, and print them out, as examples of grown up companies (I chose lockheed.com, microsoft,com, google.com, and revlon.com myself). > I'd just like to get thoughts from others to see what the general feeling is > on this topic. Just tell them no, in the most diplomatic way possible (lucky for them it's you and not me, since I am not always so diplomatic as I ought to be). As a quick aside, I did see someone advise you that you could use the fedgov do not call list for your phone, but if it's a business phone, you cannot. -- I tried being reasonable once. I didn't like it. Cats are smarter than dogs. You can't teach eight cats to pull a sled. Stupid is doing the same thing over and over and expecting different results. From frnkblk at iname.com Wed Jul 15 18:05:51 2009 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 15 Jul 2009 18:05:51 -0500 Subject: Issues accessing hulu.com from new(ish) US range In-Reply-To: <4A5E02CC.6040109@sohonet.co.uk> References: <4A5D9886.7080302@sohonet.co.uk> <4A5E02CC.6040109@sohonet.co.uk> Message-ID: I've written up a wiki page: http://nanog.cluepon.net/index.php/GeoIP Please feel free to edit -- if you're too lazy to write but know something is wrong/missing, please shoot me an e-mail offline with your "back of the napkin" comments. Frank -----Original Message----- From: Chris Taylor [mailto:chris.taylor at sohonet.co.uk] Sent: Wednesday, July 15, 2009 11:25 AM To: nanog at nanog.org Subject: Re: Issues accessing hulu.com from new(ish) US range Frank Bulk - iName.com wrote: > A few others I would check: > - Akamai (you can contact them via their web page, but there are also people > on this listserv that can check, too) > - Google (if their search pages comes up in American English, you're good to > go, otherwise there's info in their help that will let you fill out a form) > - MaxMind (there's a contact form on their web page) > > Contact me offline if you want a list of (more minor) GeoIP sites I have > bookmarked. > > Frank Thanks for that Frank. I've had contacts from Akamai and a couple of others off-list now. I've also checked MaxMind - their database appears to be up to date as well. I can't check Google at this second, as I'm based in the UK - I'll be setting something up for such tests tonight or tomorrow, but I seem to remember that we've previously spoken to them about it. Thanks, Chris > > -----Original Message----- > From: Chris Taylor [mailto:chris.taylor at sohonet.co.uk] > Sent: Wednesday, July 15, 2009 3:51 AM > To: nanog at nanog.org > Subject: Issues accessing hulu.com from new(ish) US range > > Would someone from hulu.com please contact me offlist? > > Alternatively, if anyone has contact details for a vaguely clueful > person there, that would be appreciated. > > We had a new range allocated to us by ARIN around 6 months ago for our > US business, and hulu are claiming it's non-us. Our guess is that it's a > canned response by first-line support. > > Also, does anyone happen to know which geolocation databases hulu use? > > > Thanks, > Chris > > -- Chris Taylor Engineer Sohonet Limited 60 Poland Street London W1F 7NT t +44 (0)2072926909 m +44 (0)7919897978 f +44 (0)2072926901 From simon at darkmere.gen.nz Wed Jul 15 21:14:01 2009 From: simon at darkmere.gen.nz (NANOG Mail List Committee) Date: Thu, 16 Jul 2009 14:14:01 +1200 Subject: ADMIN: List FAQ/Monthly Post. Message-ID: This 100-line document contains 62% of what you need to know to avoid annoying 10,000 people in your email to the NANOG list. It also contains pointers to another 23%. Please take 5 minutes to read it before you post [again]. General Information =================== About NANOG: http://www.nanog.org/about/ NANOG News: http://www.nanog.org/ NANOG lists and AUP: http://www.nanog.org/mailinglist/ NANOG List FAQ: http://www.nanog.org/mailinglist/listfaqs/ To Subscribe or Unsubscribe from the list: http://mailman.nanog.org/mailman/listinfo/nanog To contact the list's admins: admins at nanog.org Posting Policy ============== The NANOG list has over 10,000 subscribers so it is very easy for a thread to have scores of posts while being off-topic and only of interest to only a small proportion of subscribers. Please consider before each post if your email will be of interest to the majority of members or might alternatively be emailed directly the people of interest or posted to another forum. Please read the FAQ and AUP policy before posting for more details. Especially the following are discouraged: * Is a certain site down? Other Outages not affecting half the Internet. Please use http://downforeveryoneorjustme.com/ or a similar site. Please post to the Outages mailing list: http://wiki.outages.org * Spam Please use SPAM-L - http://spam-l.com/mailman/listinfo * Contacting People * http://puck.nether.net/netops/ * http://www.peeringdb.com * Please try other methods of contacting sites before you post to NANOG. Saying something like "I tried calling 213-555-3333 but no answer" shows you _have_ tried alternative methods first. * Political Issues * Topics such as ICANN policy, Government Policy or Law changes that do not have short term Operational impact should be avoided. * Operation topics with more specific lists * DNS - http://lists.oarci.net/mailman/listinfo/dns-operations * Email - http://www.mailop.org/ * NANOG Mailing list policy Please use the nanog-futures list or contact admins at nanog.org Please also avoid ================= * Sending posts to the list relevant to only one or two people on this list, such as tests or traceroutes in response to another post for comparison to those originally posted. * Jokes, Puns, amusing observations, spelling corrections. Other NANOG related lists ========================= * NANOG-futures - for discussion of the evolution of NANOG, including organizational structure, policies and procedures, and agendas for NANOG meetings. Such topics aren't appropriate for the main NANOG mailing list. http://mailman.nanog.org/mailman/listinfo/nanog-futures * nanog-attendee - For discussion of venue-specific issues relevant to attendees of the current NANOG physical meeting. http://mailman.nanog.org/mailman/listinfo/nanog-attendee * nanog-announce - For announcements of NANOG meetings an other Important NANOG related announcements. Low traffic and all posts are also sent to main list. http://mailman.nanog.org/mailman/listinfo/nanog-announce Other Mailing Lists =================== Information about related lists: http://www.nanog.org/mailinglist/listfaqs/otherlists.php From marka at isc.org Wed Jul 15 21:27:28 2009 From: marka at isc.org (Mark Andrews) Date: Thu, 16 Jul 2009 12:27:28 +1000 Subject: The actual value, from a security standpoint, of using a proxy domain registrar? In-Reply-To: Your message of "Wed, 15 Jul 2009 14:52:44 MST." <1b5c1c150907151452k52093694mc8b93538b4707f87@mail.gmail.com> References: <1b5c1c150907151452k52093694mc8b93538b4707f87@mail.gmail.com> Message-ID: <200907160227.n6G2RSUx054838@drugs.dv.isc.org> In message <1b5c1c150907151452k52093694mc8b93538b4707f87 at mail.gmail.com>, Mike Lyon writes: > Howdy, > > I am curious what others in the industry think on this topic. When one > registers a domain they can put in their real information or they can use a > proxy, like Go-Daddy's Domains By Proxy. > > Now, personally, I would prefer just to get a PO Box and put that address on > my domain info instead of doing a proxy. I could also put down a phone > number in the registration that just goes to my general business phone line > which is just a DVR. > > So the question I have is this: What actual security are these proxy > companies providing to the end-user? My company website has my real > address, my real phone number, exec bio's and pictures of them yet upper > management (and our marketing company) think using a proxy is a good thing. > > What's the difference between using a proxy vs using a PO Box except that a > PO Box is cheaper? > > I'd just like to get thoughts from others to see what the general feeling is > on this topic. > > Cheers, > Mike The whois is for when you stuff up you DNS / WEB etc. There are lots of errors which are not visible except from a iterative resolver. The contacts should be reachable easily from anywhere in the world. They should be kept up to date. I don't know how often I've attempted to report a operational problem with DNS servers and delegations just to have the email bounce due to the data being out of date. Proxy services just add yet another layer that can go wrong. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From sean at donelan.com Wed Jul 15 21:39:05 2009 From: sean at donelan.com (Sean Donelan) Date: Wed, 15 Jul 2009 22:39:05 -0400 (EDT) Subject: Shortest path to the world In-Reply-To: References: <200907150743330.32BF5B92.21943@clifden.donelan.com> Message-ID: <200907152151230.32BF5B92.23971@clifden.donelan.com> On Wed, 15 Jul 2009, Randy Bush wrote: >> The typical network architecture problem, what are the best (shortest >> latency, greatest bandwidth, etc) locations to connect to the every >> nation in the world? As you increase the number of locations, how do the >> choices change? >> >> If you only had small (2 3 5 7 11) number of locations, where would they >> be? >> >> And what data do you have to prove the choices are best? > > it would help if you said how you measure 'best' or 'better'. As I said in the original message, combination of minimizing latency (smallest RTT to the most IP endpoints) and maximizing bandwidth (largest number of bits per second successfully received at the most IP endpoints in the smallest amount of time) from the locations identified as best. On Wed, 15 Jul 2009, Jareon Masser wrote: >Depends completely on what the data is and why you want to send them >from A to B and if A and B are inside your network or not etc etc etc >etc. As I said in the original message, every nation in the world. Or more specifically the largest number of IP endpoints reachable in the most nations from the locations chosen. A = the few locations you pick B = every other IP endpoint reachable from those locations If every point B in the world is inside your network, awesome. But highly unlikely. More than likely to maximize reachability, minimize latency, the highest goodput, and most availability will require some combination starting locations and ISPs. The data is IP applications in use now and in the future. Why do you want to send them from A to B, because you never know what is going to happen in the world and you want to be prepared for any point B to have the best chance of being able to effectively communicate with the chosen points A. On Wed, 15 Jul 2009, Bill Woodcock wrote: >However, if one wanted the beginnings of an answer, without nailing >down any of the specifics, merely looking at the quantity of routes >available at each IXP would let you know, on average, how many paths >there were on offer to each destination. The starting locations aren't necessarily IXPs. They could be ISPs with full transit connections at the chosen locations. But the goal includes maximizing reachability to the world, which probably means a full transit connection near many other ISPs would do better than a full transit connection far away from many other ISPs. >As others have noted, this is a many-variables sort of problem, and to >answer it well requires nailing down a few of those variables True, optimization and constraints solving is easier with fewer variables. There are also researchers that seem to spend lots of time measuring the Internet and collecting data for all sorts of reasons. When creating graphs of the Internet, one of the basic problems every mapper has to solve is deciding where are the "centers" of the map. From bicknell at ufp.org Wed Jul 15 22:06:13 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 15 Jul 2009 23:06:13 -0400 Subject: Shortest path to the world In-Reply-To: <200907152151230.32BF5B92.23971@clifden.donelan.com> References: <200907150743330.32BF5B92.21943@clifden.donelan.com> <200907152151230.32BF5B92.23971@clifden.donelan.com> Message-ID: <20090716030613.GA37362@ussenterprise.ufp.org> In a message written on Wed, Jul 15, 2009 at 10:39:05PM -0400, Sean Donelan wrote: > As I said in the original message, every nation in the world. Or more > specifically the largest number of IP endpoints reachable in the most > nations from the locations chosen. > > A = the few locations you pick > B = every other IP endpoint reachable from those locations > > If every point B in the world is inside your network, awesome. But > highly unlikely. I will assert that for all the small numbers (N < 5) the answers are non-overlapping sets. That is, not that these are the acual sites, N = 1 may be New York, N = 2 may be Amsterdam and LA, N = 3 may be Hong Kong, Chicago, Frankfurt, and so on. > More than likely to maximize reachability, minimize latency, the > highest goodput, and most availability will require some combination > starting locations and ISPs. Reachability, latency, and goodput can not be all minimized at the same time. There are more than one way to create a synthetic metric combining the three, so it's quite unclear how to answer your question. > True, optimization and constraints solving is easier with fewer variables. > There are also researchers that seem to spend lots of time measuring > the Internet and collecting data for all sorts of reasons. When creating > graphs of the Internet, one of the basic problems every mapper has to > solve is deciding where are the "centers" of the map. 95% of the mapping efforts look only at reachability, and then from incomplete data. Another 4% look at it from latency. 1% look at it from goodput. I have never seen a data set that related two, much less all three in any meaningful way. Quite frankly, your question reminds me a bit of the geography question "where is the center of the US". http://en.wikipedia.org/wiki/Geographic_center_of_the_contiguous_United_States While nifty trivia, it acutally has no useful value for well, anything. If it did, there would be more there than a small monument. If you're going to deploy something, in addition to the criteria you have listed you will have to consider cost and availability of colo, transit, exchange ports, equipment, your businesses costs and time in doing business in multiple jurisdictions, getting people to these locations to set stuff up, cost and availability of bandwidth between sites, management overhead of what you're going to deploy, and so on. One last wrench in your works. It depends on how much traffic you want to do. If you want to move 50Mbps total, the answer is entirely different than if you want to move 500Gbps. Goodput holds until links fill, and which point it falls off. Plenty of video sites have great goodput from their set of locations until a flashmob (say, Michael Jackson) comes along and then the goodput from the same set of sites crashes and burns. So, you have a question that probably can't be answered, but if it could the answer doesn't matter, and even if it did, the Internet is dynamic so it will all be different tomorrow. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 825 bytes Desc: not available URL: From sean at donelan.com Thu Jul 16 01:07:12 2009 From: sean at donelan.com (Sean Donelan) Date: Thu, 16 Jul 2009 02:07:12 -0400 (EDT) Subject: Shortest path to the world In-Reply-To: <20090716030613.GA37362@ussenterprise.ufp.org> References: <200907150743330.32BF5B92.21943@clifden.donelan.com> <200907152151230.32BF5B92.23971@clifden.donelan.com> <20090716030613.GA37362@ussenterprise.ufp.org> Message-ID: <200907160131190.32BF5B92.24355@clifden.donelan.com> On Wed, 15 Jul 2009, Leo Bicknell wrote: > Quite frankly, your question reminds me a bit of the geography > question "where is the center of the US". > http://en.wikipedia.org/wiki/Geographic_center_of_the_contiguous_United_States > While nifty trivia, it acutally has no useful value for well, > anything. If it did, there would be more there than a small monument. Unless you were Federal Express, and wanted to understand where the "center" of your service area was to help pick better airport hub locations. Add in some offsets for time zones, weather, and even more complexity and your hub ends up in Memphis. Optimal can sometimes mean its good enough, even the momument at the center of the United States isn't actually located at the precise center. http://ardent.mit.edu/airports/ASP_exercises/ASP%20matl%20for%20posting%202007/UPS%20and%20FedEx%20Hub%20Operations%20Cosmas%20Martini.pdf Operations research is filled with people trying to figure out the optimal number of hubs, hub locations, routes between them for all sorts of stuff. So where are the operations research people studying the Internet? From michiel at klaver.it Thu Jul 16 03:14:20 2009 From: michiel at klaver.it (Michiel Klaver) Date: Thu, 16 Jul 2009 10:14:20 +0200 Subject: Shortest path to the world In-Reply-To: <200907150743330.32BF5B92.21943@clifden.donelan.com> References: <200907150743330.32BF5B92.21943@clifden.donelan.com> Message-ID: <4A5EE15C.5030909@klaver.it> Sean Donelan wrote: > The typical network architecture problem, what are the best (shortest latency, greatest bandwidth, etc) locations to connect to the every nation in the world? As you increase the number of locations, how do the choices change? > > If you only had small (2 3 5 7 11) number of locations, where would they be? > > And what data do you have to prove the choices are best? Just a quick wikipedia and google search would provide you the answers to that: http://en.wikipedia.org/wiki/List_of_countries_by_number_of_Internet_users http://en.wikipedia.org/wiki/List_of_Internet_exchange_points_by_size http://www.internetworldstats.com/stats.htm http://www.internetworldstats.com/stats1.htm http://www.internetworldstats.com/stats4.htm etc... have fun with all that data! Kind regards, Michiel Klaver IT Professional From fweimer at bfk.de Thu Jul 16 03:27:58 2009 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 16 Jul 2009 08:27:58 +0000 Subject: The actual value, from a security standpoint, of using a proxy domain registrar? In-Reply-To: <1b5c1c150907151452k52093694mc8b93538b4707f87@mail.gmail.com> (Mike Lyon's message of "Wed\, 15 Jul 2009 14\:52\:44 -0700") References: <1b5c1c150907151452k52093694mc8b93538b4707f87@mail.gmail.com> Message-ID: <82vdlt8229.fsf@mid.bfk.de> * Mike Lyon: > So the question I have is this: What actual security are these proxy > companies providing to the end-user? You can register domains without alerting your competition that you plan to provide a particular service (which could be guessed based on the domain name). Or a merger is coming up, and you want to quietly get the domain for the new company name. OTOH, there doesn't seem to be a legitimate long-term use for business purposes. (In my view, the secondary domain market is not legitimate---online advertisers keep it alive to artificially increase conversion rates, essentially defrauding brand owners who are structurally unable to cope with this situation.) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From chris.taylor at sohonet.co.uk Thu Jul 16 04:57:41 2009 From: chris.taylor at sohonet.co.uk (Chris Taylor) Date: Thu, 16 Jul 2009 10:57:41 +0100 Subject: Issues accessing hulu.com from new(ish) US range In-Reply-To: <4A5D9886.7080302@sohonet.co.uk> References: <4A5D9886.7080302@sohonet.co.uk> Message-ID: <4A5EF995.6020501@sohonet.co.uk> Thanks to all that contacted me offlist and on, I believe it should be sorted shortly in all the relevant databases. Thanks again, Chris From martin at theicelandguy.com Thu Jul 16 08:00:42 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Thu, 16 Jul 2009 09:00:42 -0400 Subject: Shortest path to the world In-Reply-To: <4A5EE15C.5030909@klaver.it> References: <200907150743330.32BF5B92.21943@clifden.donelan.com> <4A5EE15C.5030909@klaver.it> Message-ID: On Thu, Jul 16, 2009 at 4:14 AM, Michiel Klaver wrote: > > Sean Donelan wrote: > > The typical network architecture problem, what are the best (shortest > latency, greatest bandwidth, etc) locations to connect to the every nation > in the world? As you increase the number of locations, how do the choices > change? > > > > If you only had small (2 3 5 7 11) number of locations, where would they > be? > > > > And what data do you have to prove the choices are best? > > > Just a quick wikipedia and google search would provide you the answers > to that: > > http://en.wikipedia.org/wiki/List_of_countries_by_number_of_Internet_users > > it's possibly useful to take into consideration _overall population since broadband penetration is likely to grow in a population vs. remain stagnant or decrease. That may suggest that the largest submarine cable landing points agggregators (Telehouse, 111 8th, etc. NOTA MIA) would be optimal for shortest reach to multitudes of networks and large amounts of capacity and give you "reach" as well as decent performance. My picks were NOTA facing the Americans, 118th/60 Hudson US, and Telehouse London for Europe. I'm not suggesting that an IX is required. Would be nice to keep costs down if that's also part of the objective, but not required. There's a project that is mapping datacenters onto Google Earth globally and if I could recall the URL I would suggest that a visualization of these answers may be interesting. Best Regards, Martin -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Data Centers and Occupants From rsk at gsp.org Thu Jul 16 08:30:23 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 16 Jul 2009 09:30:23 -0400 Subject: The actual value, from a security standpoint, of using a proxy domain registrar? In-Reply-To: <1247696006.20069.105.camel@artoo.vvmedia.com> References: <1b5c1c150907151452k52093694mc8b93538b4707f87@mail.gmail.com> <1247696006.20069.105.camel@artoo.vvmedia.com> Message-ID: <20090716133023.GA25878@gsp.org> On Wed, Jul 15, 2009 at 03:13:26PM -0700, Ray Sanders wrote: > A lot of these places use scare tactics to convince domain buyers that > "privacy" is essential, otherwise one would get spam, telemarketing > calls and junk mail. > > Well, that's partly true, as some companies do scrape whois data. Not so much anymore. It's far more cost-effective and efficient for them to buy the data in bulk, and there are plenty of suppliers offering it. Now as to whether they're bad actors inside registrars, or registrars themselves, or folks who've cracked registrar security and helped themselves to the contents of their databases: who knows? But the bottom line is that the data's out there. ---Rsk From drew.weaver at thenap.com Thu Jul 16 08:45:24 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Thu, 16 Jul 2009 09:45:24 -0400 Subject: Quick question about inbound route-selection Message-ID: Howdy, Keep in mind I am basing this 'idea' off of fixed orbit's data which can sometimes be a bit out of date, etc. (in theory, and based upon number of peers, data): If you have a network with these upstream connections to the Internet you should see inbound traffic utilization in this order: AS Name --------- 3356 Level3 7018 ATT 3549 Global Crossing 4323 Time Warner Telecom 10796 TimeWarnerCable/RR I am trying to determine why I am seeing it in this order: 3356 Level3 4323 Time Warner Telecom 3549 Global Crossing 10796 TimeWarnerCable/RR 7018 ATT I suppose there is a certain level of convergence where these providers inter-connect, and also the source network of the traffic plays a big part of it, i.e. if most of the sources are directly connected to Level3, etc. I am mainly wondering why 7018 sends us such a little amount compared to even 10796. Also, with the providers already connected, if we added a new one, which one would (in your opinion) benefit us the most on spreading the inbound traffic out better? I realize that we can use communities, and prepends to control the inbound flow, I am just speaking from a purely natural standpoint. thanks, -Drew From nanog-post at rsuc.gweep.net Thu Jul 16 08:48:32 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Thu, 16 Jul 2009 09:48:32 -0400 Subject: Quick question about inbound route-selection In-Reply-To: References: Message-ID: <20090716134832.GA97787@gweep.net> On Thu, Jul 16, 2009 at 09:45:24AM -0400, Drew Weaver wrote: > Howdy, > > Keep in mind I am basing this 'idea' off of fixed orbit's data > which can sometimes be a bit out of date, etc. Understatement. [snip] > I realize that we can use communities, and prepends to control > the inbound flow, I am just speaking from a purely natural standpoint. Since your inbound is someone else's outbound, presuming any kind of "natural flow" without accounting for the remote end's sending policies is unreasonable. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From bicknell at ufp.org Thu Jul 16 08:58:10 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 16 Jul 2009 09:58:10 -0400 Subject: Shortest path to the world In-Reply-To: <200907160131190.32BF5B92.24355@clifden.donelan.com> References: <200907150743330.32BF5B92.21943@clifden.donelan.com> <200907152151230.32BF5B92.23971@clifden.donelan.com> <20090716030613.GA37362@ussenterprise.ufp.org> <200907160131190.32BF5B92.24355@clifden.donelan.com> Message-ID: <20090716135810.GB88946@ussenterprise.ufp.org> In a message written on Thu, Jul 16, 2009 at 02:07:12AM -0400, Sean Donelan wrote: > Unless you were Federal Express, and wanted to understand where the > "center" of your service area was to help pick better airport hub > locations. Add in some offsets for time zones, weather, and even more > complexity and your hub ends up in Memphis. Optimal can sometimes mean > its good enough, even the momument at the center of the United States > isn't actually located at the precise center. The center of FedEx's world has nothing to do with geography, it has to do with flight times. JFK's prennial 1 hour delays make that flight an hour longer, even though it is no further away. Also, if I had 20 flights to the east coast, and 1 flight to the west coast, I may well "shift my center" east choosing to burn more fuel and time on one flight to save fuel on 20. Oh yeah, and then there are the other hubs in Indianapolis, Fort Worth, Oakland, Newark, Anchorage, Paris, Guangzhou, Toronto and Miami. Guess Memphis isn't the best, all by itself. Anchorage you might say? That's odd. Well, turns out a fully loaded freight aircraft have trouble making it from many Asian countries to the US on one tank of fuel. If you have to stop to refuel you might as well sort some packages while your waiting for it to pump into the plane. > Operations research is filled with people trying to figure out the optimal > number of hubs, hub locations, routes between them for all sorts of stuff. > > So where are the operations research people studying the Internet? At every ISP and content provider out there. The answer is different for every company. FedEx and UPS don't have the same hubs, because they don't serve the same customer base. Akamai, NTT, and DTAG all have different points of presense based on their customer bases. Each one has the "optimal" network for their customer base. Your question is akin to tell me the best car, house, boat, airline, ISP, operating system. Magazines love to crown the king, but we all know making the right choice has orders of magnitude more to do with your specific situation than it does with the product or service in the abstract. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 825 bytes Desc: not available URL: From jasongurtz at npumail.com Thu Jul 16 09:04:18 2009 From: jasongurtz at npumail.com (Jason Gurtz) Date: Thu, 16 Jul 2009 10:04:18 -0400 Subject: The actual value, from a security standpoint, of using a proxy domain registrar? In-Reply-To: <1b5c1c150907151452k52093694mc8b93538b4707f87@mail.gmail.com> References: <1b5c1c150907151452k52093694mc8b93538b4707f87@mail.gmail.com> Message-ID: > I am curious what others in the industry think on this topic. When one > registers a domain they can put in their real information or they can use > a proxy, like Go-Daddy's Domains By Proxy. More food for thought: ~JasonG -- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3088 bytes Desc: not available URL: From ras at e-gerbil.net Thu Jul 16 15:18:02 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Thu, 16 Jul 2009 15:18:02 -0500 Subject: Quick question about inbound route-selection In-Reply-To: References: Message-ID: <20090716201802.GQ51443@gerbil.cluepon.net> On Thu, Jul 16, 2009 at 09:45:24AM -0400, Drew Weaver wrote: > I realize that we can use communities, and prepends to control the > inbound flow, I am just speaking from a purely natural standpoint. I don't know where people are getting this "natural" bgp path selection concept from, but it is completely misguided and needs to be corrected before any more misinformation is spread. On the modern Internet, the vast majority of paths look pretty much the same across any major networks, even via metrics as irrelevent as "as-path hop length". A "natural" path selection would be based on such garbage data as "who has the lowest router id", "which network has the smallest numeric value in their igp cost scheme when setting MEDs", or the wonderfully non-deterministic "which path has been up the longest". I recently heard some complaints from a bunch of customers who were upset that they "couldn't send us any traffic using natural bgp", and they didn't want to "artificially alter bgp's best path selection" with route-maps and localprefs. After trying to explain that there was really no such thing as "natural bgp", and having it fall on deaf ears, I went to take a look at their routing tables to see what they were talking about. It turned out that we were sending them MED values based on our IGP costs while their other networks were sending them 0's, which was making the tie-breaking decision go the other way for the vast majority of the routes. The BGP best path selection algorithm is really nothing special, it provides almost no useful data for selecting between major well connected networks on the modern Internet, and if you refuse to alter any attributes you're going to end up with a giant mess of path selection which would be better accomplished by asking a magic 8ball. As for trying to determine where your inbound traffic is coming from by looking at natural bgp, this is absolutely impossible to do correctly. First off, your inbound is someone else's outbound, and the person sending the traffic outbound is in complete and total control. The vast majority of the traffic on the Internet is being picked by local-prefs based on policies like "what does this make/cost me monetarily" or "which major networks can I grab in a simple as-path regexp to balance some traffic". But even if you ignore all of that, the "natural" path selection is based on criteria which is specific to the other network or even to a specific session which you can't possibly know about remotely (e.g. their router id). -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From livio.zanol.puppim at gmail.com Thu Jul 16 15:40:33 2009 From: livio.zanol.puppim at gmail.com (Livio Zanol Puppim) Date: Thu, 16 Jul 2009 17:40:33 -0300 Subject: Border routers Message-ID: Hello guys, I need to buy 2 border routers to handle 2 155Mbps links using BGP full route with each ISP. What may I analyse at the routers hardware? I'm asking for: 1Giga Byte of RAM expansible to 1,5GB 1.000.000 FIB capacity in hardware (since 512K won't be enought soon) 1.000.000 RIB capacity. What do you recommend to ask for? Are these specifications ok? Do I need more RAM or less FIB? Is there any site I can use to see specifications for border routers? Anyone knows of any PoC involving routers? -- []'s L?vio Zanol Puppim From daryl at introspect.net Thu Jul 16 15:59:49 2009 From: daryl at introspect.net (Daryl G. Jurbala) Date: Thu, 16 Jul 2009 16:59:49 -0400 Subject: The actual value, from a security standpoint, of using a proxy domain registrar? In-Reply-To: <82vdlt8229.fsf@mid.bfk.de> References: <1b5c1c150907151452k52093694mc8b93538b4707f87@mail.gmail.com> <82vdlt8229.fsf@mid.bfk.de> Message-ID: <3DAD99E1-CBFE-4235-94F1-A54806CC53B5@introspect.net> On Jul 16, 2009, at 4:27 AM, Florian Weimer wrote: > OTOH, there doesn't seem to be a legitimate long-term use for business > purposes. (In my view, the secondary domain market is not > legitimate---online advertisers keep it alive to artificially increase > conversion rates, essentially defrauding brand owners who are > structurally unable to cope with this situation.) Don't be myopic about this. There are very legitimate business cases for these services. Example: I work for a VoIP provider that sells to large customers. Their customers sell to smaller customers that want to operate their own small scale VoIP business. No one 2 or 3 levels down knows who we are, and the people upstream want it that way. Sure, most have their own domain names, but maintaining that for SBCs and very small customers who don't have/want their own domain name (to check call logs, etc) simply isn't feasible (you can doubt this assertion, but unless you know the middle eastern VoIP markets you have no business doing so). Solution? Generic sounding domain name with private registration. Cheap. Effective. Done. Daryl From Valdis.Kletnieks at vt.edu Thu Jul 16 17:08:47 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 16 Jul 2009 18:08:47 -0400 Subject: Shortest path to the world In-Reply-To: Your message of "Wed, 15 Jul 2009 22:03:56 +0900." References: <200907150743330.32BF5B92.21943@clifden.donelan.com> Message-ID: <54872.1247782127@turing-police.cc.vt.edu> On Wed, 15 Jul 2009 22:03:56 +0900, Randy Bush said: > > The typical network architecture problem, what are the best (shortest > > latency, greatest bandwidth, etc) locations to connect to the every > > nation in the world? As you increase the number of locations, how do the > > choices change? > > And what data do you have to prove the choices are best? > > it would help if you said how you measure 'best' or 'better'. Given that it's Sean asking, I have to conclude he's either dropping a very interesting thought experiment on us, or he's just trolled us, with a long list of well-known names replying. Quite possibly both at once. Well played, Sean. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From johnl at iecc.com Thu Jul 16 17:13:36 2009 From: johnl at iecc.com (John Levine) Date: 16 Jul 2009 22:13:36 -0000 Subject: The actual value, from a security standpoint, of using a proxy domain registrar? In-Reply-To: <3DAD99E1-CBFE-4235-94F1-A54806CC53B5@introspect.net> Message-ID: <20090716221336.3299.qmail@simone.iecc.com> >Example: I work for a VoIP provider that sells to large customers. >Their customers sell to smaller customers that want to operate their >own small scale VoIP business. No one 2 or 3 levels down knows who we >are, and the people upstream want it that way. Sure. >Solution? Generic sounding domain name Right. > with private registration. Wrong. Proxy registration just makes you look sleazy. Voxbone does just dandy as a VoIP wholesaler without proxy registration. What do they know that you don't? Some proxy registration is just stupid, e.g., there's proxy registration for betamax.com, but not for their brands such as voipdiscount.com, phonefreecalls.com, internetcalls.com, and nowcall.com. R's, John PS: From bonomi at mail.r-bonomi.com Thu Jul 16 17:17:12 2009 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Thu, 16 Jul 2009 17:17:12 -0500 (CDT) Subject: The actual value, from a security standpoint, of using a proxy domain registrar? Message-ID: <200907162217.n6GMHCdj026141@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Wed Jul 15 16:52:59 2009 > Date: Wed, 15 Jul 2009 14:52:44 -0700 > Subject: The actual value, from a security standpoint, of using a proxy domain > registrar? > From: Mike Lyon > To: NANOG > > Howdy, > > I am curious what others in the industry think on this topic. When one > registers a domain they can put in their real information or they can use a > proxy, like Go-Daddy's Domains By Proxy. > > Now, personally, I would prefer just to get a PO Box and put that address on > my domain info instead of doing a proxy. I could also put down a phone > number in the registration that just goes to my general business phone line > which is just a DVR. > > So the question I have is this: What actual security are these proxy > companies providing to the end-user? My company website has my real > address, my real phone number, exec bio's and pictures of them yet upper > management (and our marketing company) think using a proxy is a good thing. > > What's the difference between using a proxy vs using a PO Box except that a > PO Box is cheaper? > > I'd just like to get thoughts from others to see what the general feeling is > on this topic. > > Cheers, > Mike > From deepak at ai.net Thu Jul 16 17:32:32 2009 From: deepak at ai.net (Deepak Jain) Date: Thu, 16 Jul 2009 18:32:32 -0400 Subject: Quick question about inbound route-selection In-Reply-To: <20090716201802.GQ51443@gerbil.cluepon.net> References: <20090716201802.GQ51443@gerbil.cluepon.net> Message-ID: > As for trying to determine where your inbound traffic is coming from by > looking at natural bgp, this is absolutely impossible to do correctly. > First off, your inbound is someone else's outbound, and the person > sending the traffic outbound is in complete and total control. The vast > majority of the traffic on the Internet is being picked by local-prefs > based on policies like "what does this make/cost me monetarily" or > "which major networks can I grab in a simple as-path regexp to balance > some traffic". But even if you ignore all of that, the "natural" path > selection is based on criteria which is specific to the other network > or > even to a specific session which you can't possibly know about remotely > (e.g. their router id). Another way to say what Richard is getting at (which was full of good information) is: Just because you aren't modifying what your BGP process sees, at this stage of the Internet's maturity, it is safe to assume almost everyone else is. Therefore, rather than pray for BGP to make a logical selection, even though its *probably* being fed prefs based on other people's engineering, you should take charge of the parts you can. HTH, Deepak Jain AiNET From Pederson at covad.com Thu Jul 16 17:56:29 2009 From: Pederson at covad.com (Pederson, Krishna) Date: Thu, 16 Jul 2009 15:56:29 -0700 Subject: Probes from root servers Message-ID: <4EF4BF1E8F43894386584BE36354494A143D45F4@ZANEMS01.cc-ntd1.covad.com> One of our IP addresses is being probed by up to 8 of the 13 root dns servers every 15 seconds. I'm looking for input on how to contact the admins for the servers or perhaps a way to figure out if perhaps someone is spoofing the affected customer IP address, causing the root servers to send the following: sh mls netflow ip destination 74.1.32.205 /32 module 2 Displaying Netflow entries in module 2 DstIP SrcIP Prot:SrcPort:DstPort Src i/f :AdjPtr ----------------------------------------------------------------------------- Pkts Bytes Age LastSeen Attributes --------------------------------------------------- 74.1.32.205 193.0.14.129 udp :dns :1039 Fa2/11 :0x0 0 0 1 22:49:03 L3 - Dynamic 74.1.32.205 202.12.27.33 udp :dns :1039 Fa2/11 :0x0 0 0 2 22:49:03 L3 - Dynamic 74.1.32.205 192.36.148.17 udp :dns :1039 Fa2/11 :0x0 0 0 2 22:49:03 L3 - Dynamic Is it practical to attempt to work the issue with the root server admins or is it quite likely this is spoofing and there's no hope to track this down? Thanks, Kris From web at typo.org Thu Jul 16 18:05:04 2009 From: web at typo.org (Wayne E. Bouchard) Date: Thu, 16 Jul 2009 16:05:04 -0700 Subject: Quick question about inbound route-selection In-Reply-To: References: <20090716201802.GQ51443@gerbil.cluepon.net> Message-ID: <20090716230504.GA4221@typo.org> On Thu, Jul 16, 2009 at 06:32:32PM -0400, Deepak Jain wrote: > > As for trying to determine where your inbound traffic is coming from by > > looking at natural bgp, this is absolutely impossible to do correctly. > > First off, your inbound is someone else's outbound, and the person > > sending the traffic outbound is in complete and total control. The vast > > majority of the traffic on the Internet is being picked by local-prefs > > based on policies like "what does this make/cost me monetarily" or > > "which major networks can I grab in a simple as-path regexp to balance > > some traffic". But even if you ignore all of that, the "natural" path > > selection is based on criteria which is specific to the other network > > or > > even to a specific session which you can't possibly know about remotely > > (e.g. their router id). I would actually disagree with that and go one step further. Look at content providers. They're not concerned about best path. They're not even concerned about shortest path. Since bandwidth consuming services are what they provide, they're interested in cheapest path as much as they are the shortest path. > Another way to say what Richard is getting at (which was full of good information) is: > > Just because you aren't modifying what your BGP process sees, at this stage of the Internet's maturity, it is safe to assume almost everyone else is. Therefore, rather than pray for BGP to make a logical selection, even though its *probably* being fed prefs based on other people's engineering, you should take charge of the parts you can. Take the traffic shaping products. They completely override the normal BGP mechanisms and force traffic out a given circuit. So as long as there is a usable route down that interface, it will get used whether the neighbor wants it or not. The long and short of it is that via MEDS, prepending, and your neighbor's community policies, you can *hint* where you want traffic to come in but ultimately you may have very little say in the matter. (Community exchanges are probably the best mechanism since the existance of them in your peer's network means they will be most likely to honor your hints.) As Deepak indicated, don't rely on the originally the protocol's best effort. Take control of your own world wherever you can. It's the only way to ensure a good measure of predictability. -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From giulianocm at uol.com.br Thu Jul 16 20:55:39 2009 From: giulianocm at uol.com.br (GIULIANO (UOL)) Date: Thu, 16 Jul 2009 22:55:39 -0300 Subject: Border routers In-Reply-To: References: Message-ID: <4A5FDA1B.10608@uol.com.br> Livio, You can use one M7i from Juniper Networks (new 09 bundle with enhanced cfeb): - 1 x M7iE-5GE-RE850-US-B or M7iE-2GE-RE850-US-B - 1 x PE-2OC3-SON-SFP It will work very well for your environment. Att, Giuliano From jtk at cymru.com Thu Jul 16 23:39:23 2009 From: jtk at cymru.com (John Kristoff) Date: Thu, 16 Jul 2009 23:39:23 -0500 Subject: Probes from root servers In-Reply-To: <4EF4BF1E8F43894386584BE36354494A143D45F4@ZANEMS01.cc-ntd1.covad.com> References: <4EF4BF1E8F43894386584BE36354494A143D45F4@ZANEMS01.cc-ntd1.covad.com> Message-ID: <20090716233923.780e1100@t61p> On Thu, 16 Jul 2009 15:56:29 -0700 "Pederson, Krishna" wrote: > One of our IP addresses is being probed by up to 8 of the 13 root dns > servers every 15 seconds. I'm looking for input on how to contact the > admins for the servers or perhaps a way to figure out if perhaps > someone is spoofing the affected customer IP address, causing the > root servers to send the following: Hi Krishna, You may want to make sure a second set of eyes confirms that these are not real responses to real queries from 74.1.32.205. If you're certain there are no outgoing queries that solicit these messages, how about getting a peek inside those packets? If you can do that, you should be able to get a better idea of what may be happening. It is somewhat peculiar that the destination port is 1039 in the 3 flow records you've shown and that you're only seeing packets from 8 of the 13 root addresses. Its a clue, but inconclusive. It seems like it might be legitimate traffic from a resolver that is not doing source port randomization. Being that its only every 15 seconds that would seem too slow for an attack against 74.1.32.205, poisoning or otherwise. Could be backscatter. I can't speak for the root ops, but I think they would prefer you perform a bit more investigation if you can. John From akhmed.aly at gmail.com Fri Jul 17 02:14:32 2009 From: akhmed.aly at gmail.com (Akhmedd Aly) Date: Fri, 17 Jul 2009 11:14:32 +0400 Subject: Using CE Router for Internet and VPN services Message-ID: <542323bf0907170014i404d1effr28fa7b7291455703@mail.gmail.com> Hi, can someone explain me why service providers (Internet and/or L3 VPN services) obligate customers to use CE routers. Why they cannot configure more than /30 (in some cases /31) subnet mask on PE interface side for me? In that case I can use cheap L2 switch and use default gateway on all my PCs in the LAN, pointing to SP PE. Please describe all benefits and detriments of using more than /30 subnet on SP PE. Some good links will be very useful for me. TIA! -- AA From peter.hicks at poggs.co.uk Fri Jul 17 05:36:43 2009 From: peter.hicks at poggs.co.uk (Peter Hicks) Date: Fri, 17 Jul 2009 11:36:43 +0100 Subject: Using CE Router for Internet and VPN services In-Reply-To: <542323bf0907170014i404d1effr28fa7b7291455703@mail.gmail.com> References: <542323bf0907170014i404d1effr28fa7b7291455703@mail.gmail.com> Message-ID: <4A60543B.8000903@poggs.co.uk> Hello Akhmedd Aly wrote: > can someone explain me why service providers (Internet and/or L3 VPN > services) obligate customers to use CE routers. Why they cannot > configure more than /30 (in some cases /31) subnet mask on PE > interface side for me? In that case I can use cheap L2 switch and use > default gateway on all my PCs in the LAN, pointing to SP PE. Managed services. The concept of "the demarcation point is an Ethernet port" is an important selling point for some people, especially when IT staff are not on-site. Another major downside is the WAN circuit type - Ethernet circuits typically don't mirror the link state correctly. Furthermore, troubleshooting is easier for the SP if it's their kit at both ends of the circuit. With this kind of technology, anything is usually possible, but restricted by the practices of the SP or their superior knowledge given that they have hundreds, maybe thousands of customers and therefore a lot more experience than many of their customers. > Please describe all benefits and detriments of using more than /30 > subnet on SP PE. Some good links will be very useful for me. We have /29s on our PE-to-CE links. This allows for the Ethernet-presented WAN circuit to come in to a Layer 2 switch at either end, and two CE and two PE routers run eBGP in a full mesh. The benefits of this aren't obvious until you do the same for a backup link via another PoP - re-use the same CE routers, but full-mesh to the other PoP site. Result - you can lose a CE router but not have to fail over to the backup PoP. Peter From jbates at brightok.net Fri Jul 17 07:56:13 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 17 Jul 2009 07:56:13 -0500 Subject: Using CE Router for Internet and VPN services In-Reply-To: <542323bf0907170014i404d1effr28fa7b7291455703@mail.gmail.com> References: <542323bf0907170014i404d1effr28fa7b7291455703@mail.gmail.com> Message-ID: <4A6074ED.8040200@brightok.net> Akhmedd Aly wrote: > Please describe all benefits and detriments of using more than /30 > subnet on SP PE. > Some good links will be very useful for me. Don't know all, but have you see the arp tables on a PE router? Have you seen some of the crazy things devices other than routers can do on ethernet? There are many advantages to CE routers. SP controlled CEs take it even further in managing demarcation, other services, and offloading of any service level restrictions to the CE. Also, I believe on ethernet, some SPs do layer 2 level security and filtering which is made easier when only 1 MAC per CE. Jack From sthaug at nethelp.no Fri Jul 17 08:16:52 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Fri, 17 Jul 2009 15:16:52 +0200 (CEST) Subject: Using CE Router for Internet and VPN services In-Reply-To: <4A6074ED.8040200@brightok.net> References: <542323bf0907170014i404d1effr28fa7b7291455703@mail.gmail.com> <4A6074ED.8040200@brightok.net> Message-ID: <20090717.151652.41699152.sthaug@nethelp.no> > > Please describe all benefits and detriments of using more than /30 > > subnet on SP PE. > > Some good links will be very useful for me. > > Don't know all, but have you see the arp tables on a PE router? Have you > seen some of the crazy things devices other than routers can do on > ethernet? Good point. We allow VPN users to have up to a /29 directly connected. Any more than that and we require a CE router. Important for scaling when you have PEs aggregating 10k or 20k customer interfaces. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From livio.zanol.puppim at gmail.com Fri Jul 17 12:19:21 2009 From: livio.zanol.puppim at gmail.com (Livio Zanol Puppim) Date: Fri, 17 Jul 2009 14:19:21 -0300 Subject: Border routers In-Reply-To: References: Message-ID: Thank you guys, This will be useful, but I still have some questions: Where can I see comparations between the routers? Also, where can I find datasheets containing FIB, RIB and BGP routes limits for cisco and Juniper? It is quite dificult! Thanks again! 2009/7/17 Larry Stites > Livio, > > Tough economic conditions and heightened environmental awareness have many > ISPs, Telcos and NOCs considering Green IT as viable option when purchasing > network hardware. As licensed resellers of previously owned network > equipment we stock and supply Juniper and Cisco routers, switches and > associated modules. > > For example: > > (1) JUNIPER M10iBASE > (2) RE-850-1536 > (2) FEB-M10I-M7I > (2) HCM-M10I-M7I > (4) PWR-M10I-M7I-AC can be switched to DC > > New, back up surplus, unused condition - $15,500 > Original box, packing, Junos and accessories > > (1) JUNIPER M10iBASE > (1) RE-850-1536 > (2) FEB-M10I-M7I > (2) HCM-M10I-M7I > (4) PWR-M10I-M7I-AC can be switched to DC > > New, back up surplus, unused condition- $11250/EA > Original box, packing, Junos and accessories > (2) bundles available in this config and condition > > (1) JUNIPER M10iBASE > (1) RE-850-1536 > (1) FEB-M10I-M7I > (2) HCM-M10I-M7I > (4) PWR-M10I-M7I-DC > > Refurbished condition- $9K > Respectfully used, very good condition > Power cords, Junos and rack kit included. > > (6) PE-1GE-SX-B $1450/each > > Also available: > > (4) Juniper M5BASE-2AC-E each configured as: > ( 4 PIC Slot Chassis: (1) Built-in Enhanced FPC, Cooling, Midplane, > Forwarding Engine Board (with Internet Processor II, ASIC, 8MB SSRAM, > Routing Engine 2.0 (333Mhz - 768Mb), (2) AC Power Supply, $3500.each > > Subject to prior sale > Warranty minimum 90 days > References available > > > -- > > Best regards, > > > Larry E. Stites > Northern California Networks, Inc. > United Network Equipment Dealers Association > CA LIC#2004 SR KH 100-484111 > Nevada City, CA 95959 > cell 530 320 4194 > land 530 265 2588 > ncnet at sbcglobal.net > www.uneda.com > -- > > > on 7/16/09 1:40 PM, Livio Zanol Puppim wrote: > > > Hello guys, > > > > I need to buy 2 border routers to handle 2 155Mbps links using BGP full > > route with each ISP. What may I analyse at the routers hardware? > > > > I'm asking for: > > 1Giga Byte of RAM expansible to 1,5GB > > 1.000.000 FIB capacity in hardware (since 512K won't be enought soon) > > 1.000.000 RIB capacity. > > > > What do you recommend to ask for? Are these specifications ok? Do I need > > more RAM or less FIB? > > Is there any site I can use to see specifications for border routers? > Anyone > > knows of any PoC involving routers? > > > > > > -- []'s L?vio Zanol Puppim From tkapela at gmail.com Fri Jul 17 12:45:11 2009 From: tkapela at gmail.com (Anton Kapela) Date: Fri, 17 Jul 2009 13:45:11 -0400 Subject: Quick question about inbound route-selection In-Reply-To: References: Message-ID: <2e9d8ae50907171045o192ddc35uaf73729061aa1b88@mail.gmail.com> Drew, > (in theory, and based upon number of peers, data): If you have a network with these upstream connections to the Internet you should see inbound traffic utilization in this order: > > AS ? Name > --------- > 3356 Level3 > 7018 ATT > 3549 Global Crossing > 4323 Time Warner Telecom > 10796 TimeWarnerCable/RR In short (and not to repeat what others have said, but simply point out a different reason), the Internet is an example of a large anisotropic system. The implication for 'inbound traffic distribution' will not only depend in Neighbor-AS policies (upstream of your own AS, mind you), but equally (if not moreso) on the traffic matrix your users (or host systems, applications, etc) generate as a consequence of their activities. Almost entire decoupled from "pull heavy," "push heavy," or so-called "balanced" (in the bits/sec sense) traffic patterns, quite simply, "what you're doing" will influence the distribution. This will change over time, too, especially if the source of the traffic reaching you via 3356 experiences a change in a business relationship (174 and 3356 de-peer, again). > I am trying to determine why I am seeing it in this order: > > 3356 Level3 > 4323 Time Warner Telecom > 3549 Global Crossing > 10796 TimeWarnerCable/RR > 7018 ATT Netflow or sflow will likely shed light on "why?" with a higher degree of certainty than AS-AS adjacencies. Knowing both the rendezvous mechanism and the application inducing the flow(s) would be the first step to answering "why did that reach us via (3) and not some other edge we know exists?" Additionally, how apps discover both the network and content is a topic being explored by several researchers and operators, and may be relevant to your question. You may be able to tease out further data by considering these mechanisms as you go about monitoring. Dave Plonka is working on as much, but as of yet, I can't find a paper - only presentations [*]. Best, -Tk [*]: "Rendezvous-based Network Traffic Analysis" - http://www.cio.wisc.edu/events/lockdown/09/presentations.aspx#plonka From cscora at apnic.net Fri Jul 17 13:13:32 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 18 Jul 2009 04:13:32 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200907171813.n6HIDW91000495@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 18 Jul, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 291194 Prefixes after maximum aggregation: 138119 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 144889 Total ASes present in the Internet Routing Table: 31769 Prefixes per ASN: 9.17 Origin-only ASes present in the Internet Routing Table: 27636 Origin ASes announcing only one prefix: 13456 Transit ASes present in the Internet Routing Table: 4133 Transit-only ASes present in the Internet Routing Table: 94 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 39 Max AS path prepend of ASN (22394) 36 Prefixes from unregistered ASNs in the Routing Table: 421 Unregistered ASNs in the Routing Table: 124 Number of 32-bit ASNs allocated by the RIRs: 205 Prefixes from 32-bit ASNs in the Routing Table: 68 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 336 Number of addresses announced to Internet: 2071237376 Equivalent to 123 /8s, 116 /16s and 147 /24s Percentage of available address space announced: 55.9 Percentage of allocated address space announced: 64.7 Percentage of available address space allocated: 86.4 Percentage of address space in use by end-sites: 78.3 Total number of prefixes smaller than registry allocations: 144294 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 69386 Total APNIC prefixes after maximum aggregation: 24781 APNIC Deaggregation factor: 2.80 Prefixes being announced from the APNIC address blocks: 68804 Unique aggregates announced from the APNIC address blocks: 31533 APNIC Region origin ASes present in the Internet Routing Table: 3708 APNIC Prefixes per ASN: 18.56 APNIC Region origin ASes announcing only one prefix: 1010 APNIC Region transit ASes present in the Internet Routing Table: 571 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 469439936 Equivalent to 27 /8s, 251 /16s and 21 /24s Percentage of available APNIC address space announced: 87.4 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 180/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 123853 Total ARIN prefixes after maximum aggregation: 66050 ARIN Deaggregation factor: 1.88 Prefixes being announced from the ARIN address blocks: 124535 Unique aggregates announced from the ARIN address blocks: 52165 ARIN Region origin ASes present in the Internet Routing Table: 13114 ARIN Prefixes per ASN: 9.50 ARIN Region origin ASes announcing only one prefix: 5050 ARIN Region transit ASes present in the Internet Routing Table: 1274 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 39 Number of ARIN addresses announced to Internet: 1010319808 Equivalent to 60 /8s, 56 /16s and 65 /24s Percentage of available ARIN address space announced: 194.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 66747 Total RIPE prefixes after maximum aggregation: 39472 RIPE Deaggregation factor: 1.69 Prefixes being announced from the RIPE address blocks: 66310 Unique aggregates announced from the RIPE address blocks: 44758 RIPE Region origin ASes present in the Internet Routing Table: 13298 RIPE Prefixes per ASN: 4.99 RIPE Region origin ASes announcing only one prefix: 6939 RIPE Region transit ASes present in the Internet Routing Table: 1991 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 496661184 Equivalent to 29 /8s, 154 /16s and 114 /24s Percentage of available RIPE address space announced: 105.7 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 24613 Total LACNIC prefixes after maximum aggregation: 6037 LACNIC Deaggregation factor: 4.08 Prefixes being announced from the LACNIC address blocks: 24551 Unique aggregates announced from the LACNIC address blocks: 13594 LACNIC Region origin ASes present in the Internet Routing Table: 1143 LACNIC Prefixes per ASN: 21.48 LACNIC Region origin ASes announcing only one prefix: 368 LACNIC Region transit ASes present in the Internet Routing Table: 191 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 20 Number of LACNIC addresses announced to Internet: 72393856 Equivalent to 4 /8s, 80 /16s and 164 /24s Percentage of available LACNIC address space announced: 71.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 6228 Total AfriNIC prefixes after maximum aggregation: 1503 AfriNIC Deaggregation factor: 4.14 Prefixes being announced from the AfriNIC address blocks: 6644 Unique aggregates announced from the AfriNIC address blocks: 2564 AfriNIC Region origin ASes present in the Internet Routing Table: 306 AfriNIC Prefixes per ASN: 21.71 AfriNIC Region origin ASes announcing only one prefix: 89 AfriNIC Region transit ASes present in the Internet Routing Table: 64 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 16 Number of AfriNIC addresses announced to Internet: 20050176 Equivalent to 1 /8s, 49 /16s and 241 /24s Percentage of available AfriNIC address space announced: 59.8 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1700 6934 407 Korea Telecom (KIX) 17488 1543 137 104 Hathway IP Over Cable Interne 4755 1219 292 144 TATA Communications formerly 9583 1126 87 559 Sify Limited 4134 990 17290 375 CHINANET-BACKBONE 7545 811 198 102 TPG Internet Pty Ltd 9829 800 611 14 BSNL National Internet Backbo 23577 785 34 666 Korea Telecom (ATM-MPLS) 18101 749 201 32 Reliance Infocom Ltd Internet 24560 729 246 168 Bharti Airtel Ltd. Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4245 3643 323 bellsouth.net, inc. 4323 1894 1048 385 Time Warner Telecom 1785 1711 714 139 PaeTec Communications, Inc. 7018 1507 5909 1049 AT&T WorldNet Services 20115 1415 1460 681 Charter Communications 2386 1267 670 918 AT&T Data Communications Serv 6478 1217 275 311 AT&T Worldnet Services 3356 1180 10961 443 Level 3 Communications, LLC 11492 1127 208 12 Cable One 22773 1076 2604 66 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 30890 483 92 196 Evolva Telecom 12479 473 578 6 Uni2 Autonomous System 3292 455 1902 391 TDC Tele Danmark 702 429 1861 345 UUNET - Commercial IP service 35805 356 40 5 United Telecom of Georgia 3320 351 7082 305 Deutsche Telekom AG 3301 348 1684 310 TeliaNet Sweden 3215 343 3065 108 France Telecom Transpac 8866 333 109 20 Bulgarian Telecommunication C 29049 308 26 3 AzerSat LLC. Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1474 2882 232 UniNet S.A. de C.V. 10620 949 216 111 TVCABLE BOGOTA 28573 613 575 32 NET Servicos de Comunicao S.A 7303 595 315 92 Telecom Argentina Stet-France 22047 543 302 14 VTR PUNTO NET S.A. 11830 488 309 56 Instituto Costarricense de El 11172 442 99 70 Servicios Alestra S.A de C.V 6471 434 96 31 ENTEL CHILE S.A. 7738 410 858 29 Telecomunicacoes da Bahia S.A 3816 383 188 79 Empresa Nacional de Telecomun Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1025 188 7 TEDATA 24863 903 90 48 LINKdotNET AS number 20858 323 34 5 EgyNet 3741 276 856 236 The Internet Solution 2018 243 215 143 Tertiary Education Network 6713 176 166 16 Itissalat Al-MAGHRIB 33783 152 10 8 EEPAD TISP TELECOM & INTERNET 29571 140 15 8 Ci Telecom Autonomous system 24835 129 46 9 RAYA Telecom - Egypt 5536 123 8 9 Internet Egypt Network Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4245 3643 323 bellsouth.net, inc. 4323 1894 1048 385 Time Warner Telecom 1785 1711 714 139 PaeTec Communications, Inc. 4766 1700 6934 407 Korea Telecom (KIX) 17488 1543 137 104 Hathway IP Over Cable Interne 7018 1507 5909 1049 AT&T WorldNet Services 8151 1474 2882 232 UniNet S.A. de C.V. 20115 1415 1460 681 Charter Communications 2386 1267 670 918 AT&T Data Communications Serv 4755 1219 292 144 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 1785 1711 1572 PaeTec Communications, Inc. 4323 1894 1509 Time Warner Telecom 17488 1543 1439 Hathway IP Over Cable Interne 4766 1700 1293 Korea Telecom (KIX) 8151 1474 1242 UniNet S.A. de C.V. 11492 1127 1115 Cable One 4755 1219 1075 TATA Communications formerly 18566 1062 1052 Covad Communications 8452 1025 1018 TEDATA 22773 1076 1010 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.112.0/22 5713 Telkom SA Ltd 41.223.176.0/22 36981 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.251.0/24 22555 Universal Talkware Corporatio 64.31.32.0/19 11955 ServiceCo LLC - Road Runner Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:23 /11:58 /12:169 /13:350 /14:612 /15:1164 /16:10530 /17:4745 /18:8215 /19:17158 /20:20481 /21:20356 /22:26143 /23:26067 /24:152392 /25:930 /26:1033 /27:560 /28:155 /29:8 /30:7 /31:1 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2756 4245 bellsouth.net, inc. 4766 1399 1700 Korea Telecom (KIX) 17488 1289 1543 Hathway IP Over Cable Interne 1785 1182 1711 PaeTec Communications, Inc. 11492 1053 1127 Cable One 18566 1043 1062 Covad Communications 2386 985 1267 AT&T Data Communications Serv 9583 979 1126 Sify Limited 4323 961 1894 Time Warner Telecom 8452 947 1025 TEDATA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:14 8:209 12:2138 13:7 15:19 16:3 17:5 20:35 24:1100 32:51 34:2 38:578 40:98 41:1788 43:1 44:2 47:22 52:6 55:2 56:2 57:24 58:600 59:648 60:461 61:1076 62:1105 63:2049 64:3711 65:2396 66:3585 67:1609 68:858 69:2662 70:555 71:152 72:1665 73:2 74:1617 75:171 76:343 77:841 78:561 79:353 80:979 81:840 82:570 83:457 84:625 85:1029 86:370 87:678 88:371 89:1444 90:50 91:2404 92:363 93:1086 94:1226 95:1120 96:151 97:215 98:251 99:26 110:174 111:91 112:110 113:142 114:255 115:318 116:1127 117:536 118:356 119:744 120:146 121:782 122:1056 123:698 124:982 125:1374 128:225 129:232 130:128 131:413 132:74 133:9 134:187 135:40 136:219 137:164 138:168 139:80 140:443 141:121 142:385 143:352 144:366 145:48 146:390 147:154 148:520 149:231 150:175 151:193 152:146 153:147 154:2 155:274 156:167 157:300 158:117 159:344 160:289 161:153 162:275 163:162 164:476 165:513 166:465 167:360 168:658 169:172 170:477 171:41 172:10 173:314 174:240 178:1 186:103 187:118 188:282 189:543 190:2923 192:5784 193:4268 194:3302 195:2703 196:1121 198:3611 199:3367 200:5139 201:1284 202:7685 203:8266 204:3897 205:2157 206:2449 207:2742 208:3880 209:3377 210:2523 211:1119 212:1652 213:1639 214:84 215:29 216:4543 217:1353 218:396 219:442 220:1113 221:480 222:326 End of report From ras at e-gerbil.net Fri Jul 17 13:55:36 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Fri, 17 Jul 2009 13:55:36 -0500 Subject: Border routers In-Reply-To: References: Message-ID: <20090717185536.GV51443@gerbil.cluepon.net> On Fri, Jul 17, 2009 at 02:19:21PM -0300, Livio Zanol Puppim wrote: > Thank you guys, This will be useful, but I still have some questions: > Where can I see comparations between the routers? Also, where can I find > datasheets containing FIB, RIB and BGP routes limits for cisco and Juniper? > It is quite dificult! You won't. All of the numbers published by vendors for such things are pretty much complete and total fabrications, and will vary greatly depending on platform, code, configuration, what features you have turned on, etc. For example, many people attempting to run code written in the last couple of years on Juniper M5/M10 have already discovered that they had to go unofficially hack^H^H^H^H upgrade the FEB DRAM to support their configuration even though the FIB (in FEB SRAM) was nowhere near capacity. Also, some routes will consume more memory than others (consider 1mil unique routes vs 4x paths of the same 250k unique routes). It is all but impossible to come up with an accurate generic description of how much horsepower you'll get out of a specific amount of memory, one would need to know the platform, code, and configuration of your network to make any kind of educated guess at all. Either find someone with experience to consult for you, or buy something new and shiny that is complete overkill and will last you for years. I think the Juniper MX is the most scalable platform in terms of FIB capacity right now, thanks to their RLDRAM architecture. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From bbillon-ml at splio.fr Fri Jul 17 14:16:07 2009 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Fri, 17 Jul 2009 21:16:07 +0200 Subject: Border routers In-Reply-To: References: Message-ID: <4A60CDF7.10001@splio.fr> Cisco routers performance comparison chart: http://www.cisco.com/web/partners/downloads/765/tools/quickreference/routerperformance.pdf If you're interested on 6500/7600 and their supervisors: http://www.cisco.com/web/partners/downloads/765/tools/quickreference/catalyst6000supervisors.pdf Our 7204VXR with NPE-G1 are working great with dual-stack full tables, using less than 300M of 1GB RAM. . If you're also thinking about IPv6, check the supervisors and processor engines data sheets about that too. Livio Zanol Puppim a ?crit : > Thank you guys, This will be useful, but I still have some questions: > Where can I see comparations between the routers? Also, where can I find > datasheets containing FIB, RIB and BGP routes limits for cisco and Juniper? > It is quite dificult! > > Thanks again! > > 2009/7/17 Larry Stites > > >> Livio, >> >> Tough economic conditions and heightened environmental awareness have many >> ISPs, Telcos and NOCs considering Green IT as viable option when purchasing >> network hardware. As licensed resellers of previously owned network >> equipment we stock and supply Juniper and Cisco routers, switches and >> associated modules. >> >> For example: >> >> (1) JUNIPER M10iBASE >> (2) RE-850-1536 >> (2) FEB-M10I-M7I >> (2) HCM-M10I-M7I >> (4) PWR-M10I-M7I-AC can be switched to DC >> >> New, back up surplus, unused condition - $15,500 >> Original box, packing, Junos and accessories >> >> (1) JUNIPER M10iBASE >> (1) RE-850-1536 >> (2) FEB-M10I-M7I >> (2) HCM-M10I-M7I >> (4) PWR-M10I-M7I-AC can be switched to DC >> >> New, back up surplus, unused condition- $11250/EA >> Original box, packing, Junos and accessories >> (2) bundles available in this config and condition >> >> (1) JUNIPER M10iBASE >> (1) RE-850-1536 >> (1) FEB-M10I-M7I >> (2) HCM-M10I-M7I >> (4) PWR-M10I-M7I-DC >> >> Refurbished condition- $9K >> Respectfully used, very good condition >> Power cords, Junos and rack kit included. >> >> (6) PE-1GE-SX-B $1450/each >> >> Also available: >> >> (4) Juniper M5BASE-2AC-E each configured as: >> ( 4 PIC Slot Chassis: (1) Built-in Enhanced FPC, Cooling, Midplane, >> Forwarding Engine Board (with Internet Processor II, ASIC, 8MB SSRAM, >> Routing Engine 2.0 (333Mhz - 768Mb), (2) AC Power Supply, $3500.each >> >> Subject to prior sale >> Warranty minimum 90 days >> References available >> >> >> -- >> >> Best regards, >> >> >> Larry E. Stites >> Northern California Networks, Inc. >> United Network Equipment Dealers Association >> CA LIC#2004 SR KH 100-484111 >> Nevada City, CA 95959 >> cell 530 320 4194 >> land 530 265 2588 >> ncnet at sbcglobal.net >> www.uneda.com >> -- >> >> >> on 7/16/09 1:40 PM, Livio Zanol Puppim wrote: >> >> >>> Hello guys, >>> >>> I need to buy 2 border routers to handle 2 155Mbps links using BGP full >>> route with each ISP. What may I analyse at the routers hardware? >>> >>> I'm asking for: >>> 1Giga Byte of RAM expansible to 1,5GB >>> 1.000.000 FIB capacity in hardware (since 512K won't be enought soon) >>> 1.000.000 RIB capacity. >>> >>> What do you recommend to ask for? Are these specifications ok? Do I need >>> more RAM or less FIB? >>> Is there any site I can use to see specifications for border routers? >>> >> Anyone >> >>> knows of any PoC involving routers? >>> >> >> >> >> >> > > > From bobbyjim at gmail.com Fri Jul 17 14:17:00 2009 From: bobbyjim at gmail.com (Bobby Mac) Date: Fri, 17 Jul 2009 14:17:00 -0500 Subject: Visio diag automations Message-ID: Hi All: I have to create Visio diagrams for sales engagements for a webhosting provider. I use the same template based on our standard architecture but vary the number/model/detail of the servers. I am sick of the cut-n-paste approach and am wondering who has automated some of these processes. What I would like to do is provide a standard data file (excel, csv, ect..) and have that populate the detailed areas of the diagram. My boss won't pay for any software but I can use open source under XP or cygwin. Thanks, Robert From jwininger at indianafiber.net Fri Jul 17 16:23:22 2009 From: jwininger at indianafiber.net (Jim Wininger) Date: Fri, 17 Jul 2009 17:23:22 -0400 Subject: Cisco 7600 (7609) as a core BGP router. Message-ID: I have an opportuniy to put two 7609s into the core of my network. Currently we have 3 upstream providers, taking full BGP routes. (2 in one router and one in another). We have 17 BGP peers/customers (peering to each router), and adding about one new BGP peer every 2-3 months. It is a modest network by most standards. We are running OSPF and BGP between the existing routers. Not rocket science, nothing special (no MPLS, no VRF etc), very simple network. Does anyone have any recommendations on the 7600's as a core BGP router? Good or bad? Have they been a stable platform in a core/BGP environment? -- Jim Wininger From pkranz at unwiredltd.com Fri Jul 17 16:26:25 2009 From: pkranz at unwiredltd.com (Peter Kranz) Date: Fri, 17 Jul 2009 14:26:25 -0700 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: References: Message-ID: <027201ca0725$3d669d80$b833d880$@com> We run the 6509-e platform in this role with Sup720-3bxl's.. and they have been rock solid. Peter Kranz Founder/CEO - Unwired Ltd www.UnwiredLtd.com Desk: 510-868-1614 x100 Mobile: 510-207-0000 pkranz at unwiredltd.com -----Original Message----- From: Jim Wininger [mailto:jwininger at indianafiber.net] Sent: Friday, July 17, 2009 2:23 PM To: nanog at nanog.org Subject: Cisco 7600 (7609) as a core BGP router. I have an opportuniy to put two 7609s into the core of my network. Currently we have 3 upstream providers, taking full BGP routes. (2 in one router and one in another). We have 17 BGP peers/customers (peering to each router), and adding about one new BGP peer every 2-3 months. It is a modest network by most standards. We are running OSPF and BGP between the existing routers. Not rocket science, nothing special (no MPLS, no VRF etc), very simple network. Does anyone have any recommendations on the 7600's as a core BGP router? Good or bad? Have they been a stable platform in a core/BGP environment? -- Jim Wininger From sking at kingrst.com Fri Jul 17 16:30:50 2009 From: sking at kingrst.com (Steven King) Date: Fri, 17 Jul 2009 17:30:50 -0400 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: References: Message-ID: <4A60ED8A.9000906@kingrst.com> We use the 7600 platform as a Customer Border device. It attaches directly to our core, and directly to our customers. This has been a solid platform. Before this we used to use the 7600 as a load balancer for a DNS cluster. Worked fairly well. We use the 6500 series for our main network infrastructure and to border/core/dist layers and they are rock solid, as long as you stay away from the SXH images. These are a bit buggy and we have had routers crash due to that image. We have deployed a few new devices with the SXI and are very happy with them currently. Jim Wininger wrote: > I have an opportuniy to put two 7609s into the core of my network. > > Currently we have 3 upstream providers, taking full BGP routes. (2 in one > router and one in another). We have 17 BGP peers/customers (peering to each > router), and adding about one new BGP peer every 2-3 months. It is a modest > network by most standards. We are running OSPF and BGP between the existing > routers. > > Not rocket science, nothing special (no MPLS, no VRF etc), very simple > network. > > Does anyone have any recommendations on the 7600's as a core BGP router? > Good or bad? Have they been a stable platform in a core/BGP environment? > -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From netfortius at gmail.com Fri Jul 17 16:59:51 2009 From: netfortius at gmail.com (Stefan) Date: Fri, 17 Jul 2009 16:59:51 -0500 Subject: Nexus 7K usage w/VDC, vPC - anybody? Message-ID: I'd be interested to know if anybody has been using the Cisco N7K platform, especially in vertical consolidation mode (aggr and core as VDCs, and dual Nexus VPC-ed together)? Any comments on this system, even outsde this narrow scope of my previous question? Anybody using these as server access systems, in DCs? Thank you, -- Sent from my mobile device ***Stefan Mititelu http://twitter.com/netfortius http://www.linkedin.com/in/netfortius From cidr-report at potaroo.net Fri Jul 17 17:00:03 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 17 Jul 2009 22:00:03 GMT Subject: BGP Update Report Message-ID: <200907172200.n6HM036e047585@wattle.apnic.net> BGP Update Report Interval: 09-Jul-09 -to- 16-Jul-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9198 102617 7.2% 337.6 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - AS8151 68199 4.8% 13.0 -- Uninet S.A. de C.V. 3 - AS8452 24845 1.7% 24.0 -- TEDATA TEDATA 4 - AS29049 24261 1.7% 76.5 -- DELTA-TELECOM-AS Delta Telecom LTD. 5 - AS47408 14408 1.0% 847.5 -- MANDARIN-AS Mandarin WIMAX Sicilia SpA 6 - AS33783 11963 0.8% 77.7 -- EEPAD 7 - AS35805 10742 0.8% 30.2 -- UTG-AS United Telecom AS 8 - AS12881 8199 0.6% 911.0 -- BIA Net 9 - AS4249 8183 0.6% 45.0 -- LILLY-AS - Eli Lilly and Company 10 - AS1659 7772 0.6% 32.2 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center 11 - AS23700 6947 0.5% 24.2 -- BM-AS-ID PT. Broadband Multimedia, Tbk 12 - AS4795 6823 0.5% 25.7 -- INDOSATM2-ID INDOSATM2 ASN 13 - AS21491 6739 0.5% 224.6 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 14 - AS30969 6446 0.5% 537.2 -- TAN-NET TransAfrica Networks 15 - AS5050 6112 0.4% 555.6 -- PSC-EXT - Pittsburgh Supercomputing Center 16 - AS15808 5975 0.4% 94.8 -- Communication Solutions Ltd is an ISP serving 17 - AS20115 5850 0.4% 4.1 -- CHARTER-NET-HKY-NC - Charter Communications 18 - AS6389 5763 0.4% 1.3 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 19 - AS17974 5714 0.4% 7.7 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 20 - AS14846 5507 0.4% 125.2 -- CGNOGE - NBC Internet TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS16611 3104 0.2% 3104.0 -- 2 - AS2 2256 0.2% 4.0 -- SIM-SG-AS-AP SIM Headquarters 3 - AS47640 1213 0.1% 1213.0 -- TRICOMPAS Tricomp Sp. z. o. o. 4 - AS8599 1088 0.1% 1088.0 -- Ulyanovsk State University Network 5 - AS12881 8199 0.6% 911.0 -- BIA Net 6 - AS47408 14408 1.0% 847.5 -- MANDARIN-AS Mandarin WIMAX Sicilia SpA 7 - AS37011 1526 0.1% 763.0 -- MSTARTEL-AS 8 - AS27653 2374 0.2% 593.5 -- Alpha Communications Network 9 - AS5050 6112 0.4% 555.6 -- PSC-EXT - Pittsburgh Supercomputing Center 10 - AS30969 6446 0.5% 537.2 -- TAN-NET TransAfrica Networks 11 - AS25546 5115 0.4% 511.5 -- BROOKLANDCOMP-AS Brookland Computer Services 12 - AS47350 510 0.0% 510.0 -- GCX-SYSTEMS-AS GCX Systems Ltd. 13 - AS5313 472 0.0% 472.0 -- DNIC-ASBLK-05120-05376 - DoD Network Information Center 14 - AS42214 380 0.0% 380.0 -- IWC-AS SC International Work Company SRL 15 - AS35400 2107 0.1% 351.2 -- MFIST Interregoinal Organization Network Technologies 16 - AS11032 340 0.0% 340.0 -- UQ - Universite du Quebec a Quebec 17 - AS9198 102617 7.2% 337.6 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 18 - AS4796 331 0.0% 331.0 -- BANDUNG-NET-AS-AP Institute of Technology Bandung 19 - AS36975 311 0.0% 311.0 -- CBA-AS 20 - AS33074 305 0.0% 305.0 -- ISC-NBO1 ISC, Nairobi, Kenya TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 92.46.244.0/23 11306 0.7% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - 89.218.218.0/23 11286 0.7% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 3 - 89.218.220.0/23 11286 0.7% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 4 - 95.59.2.0/23 11269 0.7% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 5 - 95.59.4.0/22 11269 0.7% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 6 - 95.59.3.0/24 11268 0.7% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 7 - 95.59.8.0/23 11268 0.7% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 8 - 95.59.1.0/24 10281 0.7% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 9 - 88.204.221.0/24 10265 0.7% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 10 - 41.233.92.0/23 9060 0.6% AS8452 -- TEDATA TEDATA 11 - 41.233.94.0/23 9006 0.6% AS8452 -- TEDATA TEDATA 12 - 72.23.246.0/24 6050 0.4% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 13 - 193.201.184.0/21 5099 0.3% AS25546 -- BROOKLANDCOMP-AS Brookland Computer Services 14 - 216.9.95.0/24 3104 0.2% AS16611 -- 15 - 192.12.120.0/24 2587 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 16 - 196.27.104.0/21 2454 0.2% AS30969 -- TAN-NET TransAfrica Networks 17 - 196.27.108.0/22 2432 0.2% AS30969 -- TAN-NET TransAfrica Networks 18 - 72.42.193.0/24 2329 0.1% AS40060 -- AAAWI - AAA Wireless, Inc. 19 - 169.222.0.0/24 2256 0.1% AS2 -- SIM-SG-AS-AP SIM Headquarters 20 - 90.150.0.0/24 2089 0.1% AS35400 -- MFIST Interregoinal Organization Network Technologies Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 17 17:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 17 Jul 2009 22:00:00 GMT Subject: The Cidr Report Message-ID: <200907172200.n6HM00x5047534@wattle.apnic.net> This report has been generated at Fri Jul 17 21:11:56 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 10-07-09 296253 178978 11-07-09 299820 178603 12-07-09 296274 178932 13-07-09 296416 179206 14-07-09 296519 179712 15-07-09 296861 180542 16-07-09 297739 180732 17-07-09 297646 181272 AS Summary 31869 Number of ASes in routing system 13538 Number of ASes announcing only one prefix 4295 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 89732096 Largest address span announced by an AS (/32s) AS27064: DNIC-ASBLK-27032-27159 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 17Jul09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 297884 181271 116613 39.1% All ASes AS6389 4243 336 3907 92.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4295 1643 2652 61.7% TWTC - tw telecom holdings, inc. AS4766 1806 524 1282 71.0% KIXS-AS-KR Korea Telecom AS17488 1543 310 1233 79.9% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1219 193 1026 84.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1077 70 1007 93.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS1785 1711 710 1001 58.5% AS-PAETEC-NET - PaeTec Communications, Inc. AS8151 1474 595 879 59.6% Uninet S.A. de C.V. AS18566 1062 244 818 77.0% COVAD - Covad Communications Co. AS19262 1019 237 782 76.7% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8452 1027 293 734 71.5% TEDATA TEDATA AS18101 749 41 708 94.5% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS3356 1197 503 694 58.0% LEVEL3 Level 3 Communications AS6478 1217 581 636 52.3% ATT-INTERNET3 - AT&T WorldNet Services AS17908 692 68 624 90.2% TCISL Tata Communications AS4804 684 135 549 80.3% MPX-AS Microplex PTY LTD AS4134 990 445 545 55.1% CHINANET-BACKBONE No.31,Jin-rong Street AS9498 630 88 542 86.0% BBIL-AP BHARTI Airtel Ltd. AS11492 1127 585 542 48.1% CABLEONE - CABLE ONE, INC. AS855 616 76 540 87.7% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS22047 543 14 529 97.4% VTR BANDA ANCHA S.A. AS7303 597 95 502 84.1% Telecom Argentina S.A. AS10620 949 459 490 51.6% TV Cable S.A. AS17676 564 78 486 86.2% GIGAINFRA Softbank BB Corp. AS4808 665 181 484 72.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS24560 729 246 483 66.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7018 1505 1046 459 30.5% ATT-INTERNET4 - AT&T WorldNet Services AS9443 531 83 448 84.4% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7011 988 570 418 42.3% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4668 693 284 409 59.0% LGNET-AS-KR LG CNS Total 36142 10733 25409 70.3% Top 30 total Possible Bogus Routes 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.112.0/22 AS5713 SAIX-NET 41.223.176.0/22 AS36981 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.31.59.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.31.60.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 80.88.12.0/24 AS33779 wataniya-telecom-as 100.100.100.0/30 AS38676 AS33005-AS-KR wizsolution co.,Ltd 116.50.0.0/24 AS17754 EXCELL-AS Excellmedia 116.50.1.0/24 AS17754 EXCELL-AS Excellmedia 116.50.2.0/24 AS17754 EXCELL-AS Excellmedia 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.10.0/24 AS38236 121.50.13.0/24 AS38236 121.50.15.0/24 AS17625 BLAZENET-IN-AP BlazeNet's Network 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 137.0.0.0/13 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 158.222.5.0/24 AS21580 DIRCON - Direct Connect 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 168.253.0.0/16 AS13649 ASN-VINS - ViaWest 168.253.0.0/21 AS13649 ASN-VINS - ViaWest 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 190.236.250.0/23 AS6147 Telefonica del Peru S.A.A. 190.236.252.0/22 AS6147 Telefonica del Peru S.A.A. 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.132.58.0/24 AS20141 QUALITYTECH-SUW-300 - Quality Technology Services, LLC. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 193.33.148.0/23 AS30890 EVOLVA Evolva Telecom / iLink Telecom 193.104.229.0/26 AS34444 EUTELSAT-BACKBONE-AS EUTELSAT S.A. 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.5.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.19.0.0/24 AS3848 WORLDLINX-2 - WorldLinx Telecommunications, Inc. 199.114.0.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 ITCOMM - IT Communications 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.9.115.0/24 AS10292 CWJ-1 - Cable & Wireless Jamaica 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.84.10.0/23 AS9308 CHINA-ABITCOOL Abitcool(China) Inc. 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.92.48.0/20 AS23704 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS2764 AAPT AAPT Limited 202.124.195.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.125.112.0/24 AS23674 MBL-AS-AP Micronet Broadband (Pvt) Ltd. 202.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.138.167.0/24 AS18990 AIRBAND-DALLAS - Airband Communications, Inc 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.151.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.158.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.177.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.178.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.88.0/21 AS36835 208.77.224.0/24 AS36835 208.77.225.0/24 AS36835 208.77.226.0/24 AS36835 208.77.227.0/24 AS36835 208.77.228.0/24 AS36835 208.77.229.0/24 AS36835 208.77.230.0/24 AS36835 208.77.231.0/24 AS36835 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.217.224.0/19 AS6130 AIS-WEST - American Internet Services, LLC. 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 213.181.70.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.80.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.81.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.82.0/23 AS17175 NSS-UK New Skies Satellites UK AS 213.181.82.0/24 AS17175 NSS-UK New Skies Satellites UK AS 213.181.83.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.84.0/22 AS17175 NSS-UK New Skies Satellites UK AS 213.181.84.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.85.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.86.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.87.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.88.0/21 AS17175 NSS-UK New Skies Satellites UK AS 213.181.88.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.89.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.90.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.91.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.92.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.93.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.94.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.95.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.72.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.73.0/24 AS12491 IPPLANET-AS Gilat Satcom Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From bmanning at vacation.karoshi.com Fri Jul 17 14:07:24 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 17 Jul 2009 19:07:24 +0000 Subject: Probes from root servers In-Reply-To: <4EF4BF1E8F43894386584BE36354494A143D45F4@ZANEMS01.cc-ntd1.covad.com> References: <4EF4BF1E8F43894386584BE36354494A143D45F4@ZANEMS01.cc-ntd1.covad.com> Message-ID: <20090717190724.GB5280@vacation.karoshi.com.> On Thu, Jul 16, 2009 at 03:56:29PM -0700, Pederson, Krishna wrote: > One of our IP addresses is being probed by up to 8 of the 13 root dns servers every 15 seconds. I'm looking for input on how to contact the admins for the servers or perhaps a way to figure out if perhaps someone is spoofing the affected customer IP address, causing the root servers to send the following: > > sh mls netflow ip destination 74.1.32.205 /32 module 2 > Displaying Netflow entries in module 2 > DstIP SrcIP Prot:SrcPort:DstPort Src i/f :AdjPtr > ----------------------------------------------------------------------------- > Pkts Bytes Age LastSeen Attributes > --------------------------------------------------- > 74.1.32.205 193.0.14.129 udp :dns :1039 Fa2/11 :0x0 > 0 0 1 22:49:03 L3 - Dynamic > 74.1.32.205 202.12.27.33 udp :dns :1039 Fa2/11 :0x0 > 0 0 2 22:49:03 L3 - Dynamic > 74.1.32.205 192.36.148.17 udp :dns :1039 Fa2/11 :0x0 > 0 0 2 22:49:03 L3 - Dynamic > > > Is it practical to attempt to work the issue with the root server admins or is it quite likely this is spoofing and there's no hope to track this down? > > Thanks, > Kris > i feel confident that you have received one or more private replies, but since this is a recurent complaint, it may be worth the post. Root nameservers do not gratuitously send traffic. They respond to queries they receive. based on the information above, 74.1.32.205 has sent a query to the roots and they are responding as they should. if this is unwanted/undesired, you need to look at the source of the query, not the site responding to the request for information. the root server ops will have no way to evaluate if the packets they receive are spoofed. one way to contact the root server operators is via email: comments at root-servers.org --bill From bdfleming at kanren.net Fri Jul 17 18:07:26 2009 From: bdfleming at kanren.net (Brad Fleming) Date: Fri, 17 Jul 2009 18:07:26 -0500 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: <4A60ED8A.9000906@kingrst.com> References: <4A60ED8A.9000906@kingrst.com> Message-ID: We don't run very much Cisco gear (none of their larger, hardware stuff) but I have a couple questions for the Cisco gurus out there... According to this page: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet09186a0080159856_ps4835_Products_Data_Sheet.html The Cisco WS-SUP720-3BXL can hold "1,000,000 (IPv4); 500,000 (IPv6)" route entries. 1) Does that mean a) The card can hold 1m IPv4 routes --OR-- 500K IPv6 routes or b) 1m IPv4 routes --AND-- 500K IPv6 routes? 2) I'm assuming MPLS cuts into the number somewhere but could anyone explain it briefly? 3) Do ACLs use some of these resources or do they get their own slice of memory? That page also reports "up to 40 Gbps per slot of switching capacity; 720 Gbps aggregate bandwidth". Is the 40Gbps per slot an aggregate or full-duplex value? Thanks for helping out a Cisco n00b! -- Brad Fleming On Jul 17, 2009, at 4:30 PM, Steven King wrote: > We use the 7600 platform as a Customer Border device. It attaches > directly to our core, and directly to our customers. This has been a > solid platform. Before this we used to use the 7600 as a load balancer > for a DNS cluster. Worked fairly well. We use the 6500 series for our > main network infrastructure and to border/core/dist layers and they > are > rock solid, as long as you stay away from the SXH images. These are a > bit buggy and we have had routers crash due to that image. We have > deployed a few new devices with the SXI and are very happy with them > currently. > > Jim Wininger wrote: >> I have an opportuniy to put two 7609s into the core of my network. >> >> Currently we have 3 upstream providers, taking full BGP routes. (2 >> in one >> router and one in another). We have 17 BGP peers/customers (peering >> to each >> router), and adding about one new BGP peer every 2-3 months. It is >> a modest >> network by most standards. We are running OSPF and BGP between the >> existing >> routers. >> >> Not rocket science, nothing special (no MPLS, no VRF etc), very >> simple >> network. >> >> Does anyone have any recommendations on the 7600's as a core BGP >> router? >> Good or bad? Have they been a stable platform in a core/BGP >> environment? >> > > -- > Steve King > > Network Engineer - Liquid Web, Inc. > Cisco Certified Network Associate > CompTIA Linux+ Certified Professional > CompTIA A+ Certified Professional > > > From jlewis at lewis.org Fri Jul 17 18:19:45 2009 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 17 Jul 2009 19:19:45 -0400 (EDT) Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: References: <4A60ED8A.9000906@kingrst.com> Message-ID: On Fri, 17 Jul 2009, Brad Fleming wrote: > We don't run very much Cisco gear (none of their larger, hardware stuff) but > I have a couple questions for the Cisco gurus out there... > > According to this page: > http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet09186a0080159856_ps4835_Products_Data_Sheet.html > The Cisco WS-SUP720-3BXL can hold "1,000,000 (IPv4); 500,000 (IPv6)" route > entries. > > 1) Does that mean a) The card can hold 1m IPv4 routes --OR-- 500K IPv6 routes > or b) 1m IPv4 routes --AND-- 500K IPv6 routes? OR. Or you can have 524288 v4 and 262144 v6 routes...or you can move the split around. I chose: L3 Forwarding Resources FIB TCAM usage: Total Used %Used 72 bits (IPv4, MPLS, EoM) 622592 289791 47% 144 bits (IP mcast, IPv6) 212992 8 1% Adjusting the split requires a reboot. > 2) I'm assuming MPLS cuts into the number somewhere but could anyone explain > it briefly? I think the above actually does. > 3) Do ACLs use some of these resources or do they get their own slice of > memory? Don't think so. I did a blog entry about this a while back. http://jonsblog.lewis.org/2008/02/09#sup720-20080209 > That page also reports "up to 40 Gbps per slot of switching capacity; 720 > Gbps aggregate bandwidth". > Is the 40Gbps per slot an aggregate or full-duplex value? AFAIK, cisco always reports these things as input+output = bandwidth. It makes the numbers more impressive. We've been using 6509s as BGP routers for years and they've generaly been rock stable. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From ras at e-gerbil.net Fri Jul 17 18:20:03 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Fri, 17 Jul 2009 18:20:03 -0500 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: References: <4A60ED8A.9000906@kingrst.com> Message-ID: <20090717232003.GW51443@gerbil.cluepon.net> On Fri, Jul 17, 2009 at 06:07:26PM -0500, Brad Fleming wrote: > We don't run very much Cisco gear (none of their larger, hardware > stuff) but I have a couple questions for the Cisco gurus out there... > > According to this page: > http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet09186a0080159856_ps4835_Products_Data_Sheet.html > The Cisco WS-SUP720-3BXL can hold "1,000,000 (IPv4); 500,000 (IPv6)" > route entries. > > 1) Does that mean a) The card can hold 1m IPv4 routes --OR-- 500K IPv6 > routes or b) 1m IPv4 routes --AND-- 500K IPv6 routes? > 2) I'm assuming MPLS cuts into the number somewhere but could anyone > explain it briefly? > 3) Do ACLs use some of these resources or do they get their own slice > of memory? The total size of the TCAM for forwardinging lookups is 9MB. IPv4 and MPLS routes consume 72 bits per entry, IPv6 and multicast routes consume 144 bits per entry. If you use all IPv4/MPLS, you get 1048576 entries. If you use all IPv6/multicast routes, you get 524288 entries. Your actual usage will probably be somewhere in between. ACLs and Netflow are different TCAM resources. Also, you have to pre-"partition" the TCAM capacity and reboot in order for the changes to take effect, so you'll need to decide your profile beforehand. The command to do that is "mls cef maximum-routes". You can also check your current utilization of forwarding tcam and acl/qos tcam with "show platform hardware capacity" on anything SXF or newer. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From oberman at es.net Fri Jul 17 18:31:33 2009 From: oberman at es.net (Kevin Oberman) Date: Fri, 17 Jul 2009 16:31:33 -0700 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: Your message of "Fri, 17 Jul 2009 18:07:26 CDT." Message-ID: <20090717233133.E43191CC31@ptavv.es.net> > From: Brad Fleming > Date: Fri, 17 Jul 2009 18:07:26 -0500 > > We don't run very much Cisco gear (none of their larger, hardware > stuff) but I have a couple questions for the Cisco gurus out there... > > According to this page: > http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet09186a0080159856_ps4835_Products_Data_Sheet.html > The Cisco WS-SUP720-3BXL can hold "1,000,000 (IPv4); 500,000 (IPv6)" > route entries. > > 1) Does that mean a) The card can hold 1m IPv4 routes --OR-- 500K IPv6 > routes or b) 1m IPv4 routes --AND-- 500K IPv6 routes? It means that it will hole 1M IPv4 OR 500K IPv6. It means that IPv6 addresses take twice the TCAM that IPv4 routes do, so that for every IPv6 route in TCAM, you can load two fewer IPv4 routes. Worse, TCAM is partitioned with a dedicated portion for IPv4 addresses and another for IPv6 + multicast. To adjust the partitioning, you must reload the supervisor. > 2) I'm assuming MPLS cuts into the number somewhere but could anyone > explain it briefly? Not really. The TCAM holds routes and the place to send packets destined for them. Since all TCAM is loaded based on flows and treated very much like MPLS, just without an external tag, the TCAM space should not be impacted. (I am NOT positive about this one, though.) > 3) Do ACLs use some of these resources or do they get their own slice > of memory? Nope. They are in a different TCAM in the Sup720. They have zero impact. > That page also reports "up to 40 Gbps per slot of switching capacity; > 720 Gbps aggregate bandwidth". > Is the 40Gbps per slot an aggregate or full-duplex value? I don't entirely understand the phrasing of the question, but I think you mean, do they double the numbers as router marketeers are wont to do by counting traffic in both directions? No. That is why you can drive all 4 ports of the 4x10GE card to almost the full 10G at the same time in both directions. Not quite, though. Cisco "steals" a little bandwidth on each cord for some internal signaling, so each pair of the 10GE ports is limited to about 19 GB. (I don't recall the exact number.) So they are just slightly oversubscribed. The backplane is actually a pair of 20 Gbps backplanes with the ports divided between them. On the 4x10G cards, the two top ports are on one backplane and the two bottom ones are on the other. They each have access to a full 20Gbps path less the "stolen" bandwidth. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From ras at e-gerbil.net Fri Jul 17 18:37:34 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Fri, 17 Jul 2009 18:37:34 -0500 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: References: <4A60ED8A.9000906@kingrst.com> Message-ID: <20090717233734.GX51443@gerbil.cluepon.net> On Fri, Jul 17, 2009 at 06:07:26PM -0500, Brad Fleming wrote: > That page also reports "up to 40 Gbps per slot of switching capacity; > 720 Gbps aggregate bandwidth". > Is the 40Gbps per slot an aggregate or full-duplex value? Woops, I missed this question. On CEF720 (aka the cards numbered 67xx that claim to be 40G/slot) what you actually have are two 20G fabric channels to each slot. The fabric channels are full duplex, so you could have 40G per slot coming in and out of the same card, and Cisco double-counts the packets (in and out) to get 9 fabric slots * 40G * 2 = 720. On 6704 cards, ports 1 and 2 are in one fabric channel, ports 3 and 4 are in another. On 6748 cards, even ports are in one channel and odd ports are in another. On 6724 cards, there is only one 20G fabric channel. Of course there are literally a list of caveats a mile long to explain why you won't actually get anywhere near 720G out of the box, but the big one you want to be careful of is sending traffic within the same fabric channel (i.e. from port 1 to port 2 on a 6704). This will cause a bottleneck at around 7-8G, with lots of input or output drops. You can also view the fabric utilization with "show platform hardware capacity fabric", though you should keep in mind that these counters are about as accurate as the others on this platform (wild variations at best). -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From rdobbins at arbor.net Fri Jul 17 23:09:48 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 18 Jul 2009 11:09:48 +0700 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: <4A60ED8A.9000906@kingrst.com> References: <4A60ED8A.9000906@kingrst.com> Message-ID: <176CAC5E-5836-4121-AFB4-AE84CE51593C@arbor.net> On Jul 18, 2009, at 4:30 AM, Steven King wrote: > We use the 7600 platform as a Customer Border device. The 7600 is actually quite a poor choice as an edge device (any edge) due to its caveats regarding NetFlow, ACLs, and uRPF. It's far better suited to a core role, where it can handle mpps running without the need for these critical edge features. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From deleskie at gmail.com Sat Jul 18 00:12:56 2009 From: deleskie at gmail.com (deleskie at gmail.com) Date: Sat, 18 Jul 2009 05:12:56 +0000 Subject: Cisco 7600 (7609) as a core BGP router. Message-ID: <432127307-1247893988-cardhu_decombobulator_blackberry.rim.net-597624902-@bxe1156.bisx.prod.on.blackberry> Roland, The only issue I have I with your reply is that is somehow still acceptable to not have these features in a core device. -jim ------Original Message------ From: Roland Dobbins To: NANOG list Subject: Re: Cisco 7600 (7609) as a core BGP router. Sent: Jul 18, 2009 1:09 AM On Jul 18, 2009, at 4:30 AM, Steven King wrote: > We use the 7600 platform as a Customer Border device. The 7600 is actually quite a poor choice as an edge device (any edge) due to its caveats regarding NetFlow, ACLs, and uRPF. It's far better suited to a core role, where it can handle mpps running without the need for these critical edge features. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton Sent from my BlackBerry device on the Rogers Wireless Network From patrick at ianai.net Sat Jul 18 01:02:55 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 18 Jul 2009 02:02:55 -0400 Subject: Quick question about inbound route-selection In-Reply-To: <20090716230504.GA4221@typo.org> References: <20090716201802.GQ51443@gerbil.cluepon.net> <20090716230504.GA4221@typo.org> Message-ID: <5437492A-A8F1-499C-8211-EA7554FAFD3D@ianai.net> On Jul 16, 2009, at 7:05 PM, Wayne E. Bouchard wrote: > On Thu, Jul 16, 2009 at 06:32:32PM -0400, Deepak Jain wrote: >>> As for trying to determine where your inbound traffic is coming >>> from by >>> looking at natural bgp, this is absolutely impossible to do >>> correctly. >>> First off, your inbound is someone else's outbound, and the person >>> sending the traffic outbound is in complete and total control. The >>> vast >>> majority of the traffic on the Internet is being picked by local- >>> prefs >>> based on policies like "what does this make/cost me monetarily" or >>> "which major networks can I grab in a simple as-path regexp to >>> balance >>> some traffic". But even if you ignore all of that, the "natural" >>> path >>> selection is based on criteria which is specific to the other >>> network >>> or >>> even to a specific session which you can't possibly know about >>> remotely >>> (e.g. their router id). > > I would actually disagree with that and go one step further. Look at > content providers. They're not concerned about best path. They're not > even concerned about shortest path. Since bandwidth consuming services > are what they provide, they're interested in cheapest path as much as > they are the shortest path. s/content providers/some content providers, some eyeball networks, some corporate networks, and some of just about every type of network/ OTOH: Some content providers measure latency, packet loss, and throughput and react accordingly to ensure the end users get adequate performance, no matter the path or cost. Interestingly, in either case, the 'natural' BGP selection is a poor predictor of inbound traffic. But then we already knew that. :) -- TTFN, patrick From ras at e-gerbil.net Sat Jul 18 02:24:32 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Sat, 18 Jul 2009 02:24:32 -0500 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: <176CAC5E-5836-4121-AFB4-AE84CE51593C@arbor.net> References: <4A60ED8A.9000906@kingrst.com> <176CAC5E-5836-4121-AFB4-AE84CE51593C@arbor.net> Message-ID: <20090718072432.GY51443@gerbil.cluepon.net> On Sat, Jul 18, 2009 at 11:09:48AM +0700, Roland Dobbins wrote: > > On Jul 18, 2009, at 4:30 AM, Steven King wrote: > > >We use the 7600 platform as a Customer Border device. > > The 7600 is actually quite a poor choice as an edge device (any edge) > due to its caveats regarding NetFlow, ACLs, and uRPF. It's far better > suited to a core role, where it can handle mpps running without the > need for these critical edge features. Funny, I'd argue that they're a terrible choice for a core router, due to their inability to do line rate on a "any port to any port" traffic profile, poor MPLS-TE functionality, and all of the caveats regarding port-channel hashing. I do agree that they're also a poor choice for a transit/peering edge due to their netflow issues (aka "completely worthless, don't even bother trying"), ACLs, and route-map suckage in general, but IMHO the only place they are even remotely usable is a customer aggregation device. With a customer agg router you have a lot of control about how you map the ports <-> fabric channels to avoid intra-channel traffic, on a core device you have no such luxury and you really don't want your network taking a crap when your longhaul or even metro traffic shifts around (as is going to happen on any well connected network). Once you throw in the need to do MPLS and inter-device traffic rates greater than 10G, they're an epic disaster in this role. On the other hand, you may not need netflow on the customer edge if you're doing it on your peering edge, if you structure your network right you can almost completely avoid having to do ACLs on them, and the uRPF functionality is probably the least broken thing about them. You also don't need complex routing policies, you can hang them off more competent routers as route-reflectors, and heck a datacenter agg box is probably the only place you want to be using xenpaks (or even worse, x2) anyways. But as always, your network requirements may vary. The only real argument I can come up with against using them as customer aggregation boxes is that when their interface counters break (which only happens on days that end in y) you're actually misbilling people, and maybe not in the direction you'd prefer. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From saku at ytti.fi Sat Jul 18 02:37:33 2009 From: saku at ytti.fi (Saku Ytti) Date: Sat, 18 Jul 2009 10:37:33 +0300 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: <432127307-1247893988-cardhu_decombobulator_blackberry.rim.net-597624902-@bxe1156.bisx.prod.on.blackberry> References: <432127307-1247893988-cardhu_decombobulator_blackberry.rim.net-597624902-@bxe1156.bisx.prod.on.blackberry> Message-ID: <20090718073733.GA26689@mx.ytti.net> On (2009-07-18 05:12 +0000), deleskie at gmail.com wrote: Hey, > The only issue I have I with your reply is that is somehow still acceptable to not have these features in a core device. I'm guessing point Roland was making (which he likely would have not made couple moons ago:) was related to the lack of IPv6 uRPF, chassis wide uRPF mode and IPv6 ACL either have /128 look-up and no L4 lookup or L4 lookup and accordingly reduced lookup, forcing longer prefixes to software (compression removes bits 24-39 from hardware). In practice this means, if you enable compressed mode, to allow L4 lookups in ACL, and you likely will (how else are you going to protect server, if you can't allow MGMT/ssh and internet/http and drop rest?) you will need to take care that you never do 'host 2001:db8::1' but stay within the boundaries. Typically this is non-issue, as you have rather large subnets, and typically inside this subnet there is same security policy, that is, all hosts can use same ACL. It is easy to verify if particular ACE from ACL line is in hardware or is punted, so it will be easy to fix it, before going live. This is still definitely something you need to consider. I'd agree that no IPv6/uRPF is rather show-stopper for longer term edge use, but I don't think the IPv6/ACL is deal-breaker. In core I personally have no use for uRPF or ACL, as I'm not facing customers in core. EARL8 (Nexus7k) fixes the IPv6/uRPF and IPv6/ACL issue. Someone mentioned the ACL TCAM, planning its usage is also important you can use 'shot tcam counts' to see the resource usage. Pay particular attention to 'LOU' usage (which is used for gt/lt/neq/range operators, and is hence somewhat expensive). But knowing the limitation and how ACL lines are compiled to ACEs makes it typically easy to scale as far you need to. > > -jim > ------Original Message------ > From: Roland Dobbins > To: NANOG list > Subject: Re: Cisco 7600 (7609) as a core BGP router. > Sent: Jul 18, 2009 1:09 AM > > > On Jul 18, 2009, at 4:30 AM, Steven King wrote: > > > We use the 7600 platform as a Customer Border device. > > The 7600 is actually quite a poor choice as an edge device (any edge) > due to its caveats regarding NetFlow, ACLs, and uRPF. It's far better > suited to a core role, where it can handle mpps running without the > need for these critical edge features. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Unfortunately, inefficiency scales really well. > > -- Kevin Lawton > > > > > Sent from my BlackBerry device on the Rogers Wireless Network > -- ++ytti From rdobbins at arbor.net Sat Jul 18 03:58:10 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 18 Jul 2009 15:58:10 +0700 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: <20090718073733.GA26689@mx.ytti.net> References: <432127307-1247893988-cardhu_decombobulator_blackberry.rim.net-597624902-@bxe1156.bisx.prod.on.blackberry> <20090718073733.GA26689@mx.ytti.net> Message-ID: <4D771172-1100-4FAB-B13D-97778F164347@arbor.net> On Jul 18, 2009, at 2:37 PM, Saku Ytti wrote: > I'm guessing point Roland was making (which he likely would have not > made couple moons ago:) I've made this point for years, quite publicly, actually - even when it was unpopular for me to do so in certain quarters. ;> uRPF for 7600/6500 can only be in one mode for the whole box, all interfaces. This is a major problem in many cases. The NetFlow issues render flow telemetry unusable in production situations. The ACLs work very differently on this platform due to LOU issues, as you say. Most folks don't know this, and many end up overflowing their TCAMs and not realizing it until their boxes fall over, heh. If one has fairly complex ACLs covering various ranges of ports, ACLs on 7600/6500 quickly become very difficult to manage. > EARL8 (Nexus7k) fixes the IPv6/uRPF and IPv6/ACL issue. And the NetFlow issues. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From darren at bolding.org Sat Jul 18 05:05:32 2009 From: darren at bolding.org (Darren Bolding) Date: Sat, 18 Jul 2009 03:05:32 -0700 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: <4D771172-1100-4FAB-B13D-97778F164347@arbor.net> References: <432127307-1247893988-cardhu_decombobulator_blackberry.rim.net-597624902-@bxe1156.bisx.prod.on.blackberry> <20090718073733.GA26689@mx.ytti.net> <4D771172-1100-4FAB-B13D-97778F164347@arbor.net> Message-ID: <5a318d410907180305x4b924f1aoc883b2259c841878@mail.gmail.com> Can someone provide a link, or more detail, on the netflow issues. Particularly as they relate to 6509's and sup720's. Thanks! On 7/18/09, Roland Dobbins wrote: > > On Jul 18, 2009, at 2:37 PM, Saku Ytti wrote: > >> I'm guessing point Roland was making (which he likely would have not >> made couple moons ago:) > > I've made this point for years, quite publicly, actually - even when > it was unpopular for me to do so in certain quarters. > > ;> > > uRPF for 7600/6500 can only be in one mode for the whole box, all > interfaces. This is a major problem in many cases. > > The NetFlow issues render flow telemetry unusable in production > situations. > > The ACLs work very differently on this platform due to LOU issues, as > you say. Most folks don't know this, and many end up overflowing > their TCAMs and not realizing it until their boxes fall over, heh. If > one has fairly complex ACLs covering various ranges of ports, ACLs on > 7600/6500 quickly become very difficult to manage. > >> EARL8 (Nexus7k) fixes the IPv6/uRPF and IPv6/ACL issue. > > > And the NetFlow issues. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Unfortunately, inefficiency scales really well. > > -- Kevin Lawton > > > -- Sent from my mobile device -- Darren Bolding -- -- darren at bolding.org -- From rdobbins at arbor.net Sat Jul 18 05:26:52 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 18 Jul 2009 17:26:52 +0700 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: <5a318d410907180305x4b924f1aoc883b2259c841878@mail.gmail.com> References: <432127307-1247893988-cardhu_decombobulator_blackberry.rim.net-597624902-@bxe1156.bisx.prod.on.blackberry> <20090718073733.GA26689@mx.ytti.net> <4D771172-1100-4FAB-B13D-97778F164347@arbor.net> <5a318d410907180305x4b924f1aoc883b2259c841878@mail.gmail.com> Message-ID: <090ADCCF-C69E-4741-8F9F-829307023B53@arbor.net> On Jul 18, 2009, at 5:05 PM, Darren Bolding wrote: > Can someone provide a link, or more detail, on the netflow issues. > Particularly as they relate to 6509's and sup720's. mls table can hold 256K entries at 93% efficiency, so you end up with about 239K flows total. No packet-sampled control of flow creation, so the table is likely to be overflowed in production edge situations, leading to non-deterministically skewed stats. No logical OR of TCP flags throughout a TCP flow - can't classify SYN- floods, RST-floods, et. al. No stats on dropped traffic. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From rdobbins at arbor.net Sat Jul 18 05:28:15 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 18 Jul 2009 17:28:15 +0700 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: <5a318d410907180305x4b924f1aoc883b2259c841878@mail.gmail.com> References: <432127307-1247893988-cardhu_decombobulator_blackberry.rim.net-597624902-@bxe1156.bisx.prod.on.blackberry> <20090718073733.GA26689@mx.ytti.net> <4D771172-1100-4FAB-B13D-97778F164347@arbor.net> <5a318d410907180305x4b924f1aoc883b2259c841878@mail.gmail.com> Message-ID: On Jul 18, 2009, at 5:05 PM, Darren Bolding wrote: > Can someone provide a link, or more detail, on the netflow issues. > Particularly as they relate to 6509's and sup720's. Note that these issues are all fixed on the Nexus 7000, with the EARL8 ASIC. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From saku at ytti.fi Sat Jul 18 05:43:56 2009 From: saku at ytti.fi (Saku Ytti) Date: Sat, 18 Jul 2009 13:43:56 +0300 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: <4D771172-1100-4FAB-B13D-97778F164347@arbor.net> References: <432127307-1247893988-cardhu_decombobulator_blackberry.rim.net-597624902-@bxe1156.bisx.prod.on.blackberry> <20090718073733.GA26689@mx.ytti.net> <4D771172-1100-4FAB-B13D-97778F164347@arbor.net> Message-ID: <20090718104356.GA26980@mx.ytti.net> On (2009-07-18 15:58 +0700), Roland Dobbins wrote: > uRPF for 7600/6500 can only be in one mode for the whole box, all > interfaces. This is a major problem in many cases. I referred to this as 'chassis wide uRPF'. I'm not sure if that is big issue in many networks. You run uRPF/strict to single homed customer and uRPF/loose to transit/peering. Often networks already have dedicated peering boxes. I'm not sure, but I believe technically PXF (ES20, SIP600) and EZchip (ES+) should have no trouble doing uRPF, so I think it's just software development issue, that even with these cards, you're bound to this limitation. >From my point of view, as long you can live with LAN cards in 7600 is has excellent bang for buck, with really no competing products out there. But the moment you need to terminate multiple customers to single port and provide QoS (which implies H-QoS) the box has several attractive competitors, most of them are even newer generation, such as MX. -- ++ytti From peter.hicks at poggs.co.uk Sat Jul 18 05:55:21 2009 From: peter.hicks at poggs.co.uk (Peter Hicks) Date: Sat, 18 Jul 2009 11:55:21 +0100 Subject: Visio diag automations In-Reply-To: References: Message-ID: <4A61AA19.8060704@poggs.co.uk> Bobby Mac wrote: > I have to create Visio diagrams for sales engagements for a webhosting > provider. I use the same template based on our standard architecture but > vary the number/model/detail of the servers. I am sick of the cut-n-paste > approach and am wondering who has automated some of these processes. What I > would like to do is provide a standard data file (excel, csv, ect..) and > have that populate the detailed areas of the diagram. My boss won't pay for > any software but I can use open source under XP or cygwin. I attempted to do data-driven diagrams with Visio, but quickly gave up. I don't think Visio is the right tool for the job. Have you thought about writing the diagram in HTML+CSS and laying it out that way? Diagramming is one of the biggest problems I've had in the 10+ years I've been doing networking. Poggs From frnkblk at iname.com Sat Jul 18 11:10:52 2009 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 18 Jul 2009 11:10:52 -0500 Subject: Visio diag automations In-Reply-To: References: Message-ID: This thread may be helpful: http://markmail.org/thread/4o4bn3whbqdmhaol Frank -----Original Message----- From: Bobby Mac [mailto:bobbyjim at gmail.com] Sent: Friday, July 17, 2009 2:17 PM To: nanog at nanog.org Subject: Visio diag automations Hi All: I have to create Visio diagrams for sales engagements for a webhosting provider. I use the same template based on our standard architecture but vary the number/model/detail of the servers. I am sick of the cut-n-paste approach and am wondering who has automated some of these processes. What I would like to do is provide a standard data file (excel, csv, ect..) and have that populate the detailed areas of the diagram. My boss won't pay for any software but I can use open source under XP or cygwin. Thanks, Robert From ras at e-gerbil.net Sat Jul 18 14:00:02 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Sat, 18 Jul 2009 14:00:02 -0500 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: <5a318d410907180305x4b924f1aoc883b2259c841878@mail.gmail.com> References: <432127307-1247893988-cardhu_decombobulator_blackberry.rim.net-597624902-@bxe1156.bisx.prod.on.blackberry> <20090718073733.GA26689@mx.ytti.net> <4D771172-1100-4FAB-B13D-97778F164347@arbor.net> <5a318d410907180305x4b924f1aoc883b2259c841878@mail.gmail.com> Message-ID: <20090718190002.GZ51443@gerbil.cluepon.net> On Sat, Jul 18, 2009 at 03:05:32AM -0700, Darren Bolding wrote: > Can someone provide a link, or more detail, on the netflow issues. > Particularly as they relate to 6509's and sup720's. The long and short of it is the current hardware (EARL7) is incapable of doing sampling (i.e. looking at 1 out of every Nth packets). It gathers all of the flow data into tcam and THEN does sampling in software, but by that point its already too late because the tcam is exhausted. Turning on sampling actually makes it worse, because it forces a flowmask which fills the tcam even faster. In my experience, even with extremely aggressive aging and a dest only flowmask (discarding all src and L4 port information to make it fit better), it tops out at around 2Gbps of "generic wholesale IP" traffic you can sample. Obviously when it runs out of steam is dependent on the number of flows in your network, you could be much better or much worse depending on your traffic, but the point is it usually doesn't work for most people. Adding DFC daughterboards makes this capacity scale linearly, i.e. you go from 2Gbps system-wide capacity to 2Gbps per slot capacity, but this typically doesn't make any difference. The only recent improvement is that in SXH+ and SRB+ software you can now enable netflow on a per-interface basis rather than a global basis (before this, all traffic was sampled globally regardless of what you configured on the interfaces). This can let you exclude interfaces you don't care about (such as core links) use your limited resources only on interfaces you do care about (such as edge links). Until they come out with the EARL8 SUPs (what have they pushed that back to now, 2011? :P) you are basically SOL in the netflow dept. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From marc at let.de Sat Jul 18 14:31:56 2009 From: marc at let.de (Marc Manthey) Date: Sat, 18 Jul 2009 21:31:56 +0200 Subject: Outages in wales ? Message-ID: <25D3869E-FBA8-4ED3-AD58-DB5CDDC25DBC@let.de> hey peoples sorry for my question but a buddy in wales have massive problems with internet connectivity can someone confirm ? thanks so much marc -- Les enfants teribbles - research / deployment Marc Manthey Vogelsangerstrasse 97 D - 50823 K?ln - Germany Vogelsangerstrasse 97 Geo: 50.945554, 6.920293 PGP/GnuPG: 0x1ac02f3296b12b4d Tel.:0049-221-29891489 Mobil:0049-1577-3329231 web : http://www.let.de Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. From simon at slimey.org Sat Jul 18 15:03:35 2009 From: simon at slimey.org (Simon Lockhart) Date: Sat, 18 Jul 2009 21:03:35 +0100 Subject: Outages in wales ? In-Reply-To: <25D3869E-FBA8-4ED3-AD58-DB5CDDC25DBC@let.de> References: <25D3869E-FBA8-4ED3-AD58-DB5CDDC25DBC@let.de> Message-ID: <20090718200335.GM2898@virtual.bogons.net> On Sat Jul 18, 2009 at 09:31:56PM +0200, Marc Manthey wrote: > hey peoples sorry for my question > but a buddy in wales have massive problems with internet connectivity > can someone confirm ? I'm just on the welsh border, and I've not seen any issues reported - my home ADSL is up, our office connectivity (in the Welsh valleys) is up, and customer networks in Wales are up. Sounds like it's a more localised problem. Simon From marc at let.de Sat Jul 18 15:17:49 2009 From: marc at let.de (Marc Manthey) Date: Sat, 18 Jul 2009 22:17:49 +0200 Subject: Outages in wales ? In-Reply-To: <20090718200335.GM2898@virtual.bogons.net> References: <25D3869E-FBA8-4ED3-AD58-DB5CDDC25DBC@let.de> <20090718200335.GM2898@virtual.bogons.net> Message-ID: >> hey peoples sorry for my question >> but a buddy in wales have massive problems with internet connectivity >> can someone confirm ? > > I'm just on the welsh border, and I've not seen any issues reported > - my > home ADSL is up, our office connectivity (in the Welsh valleys) is > up, and > customer networks in Wales are up. > > Sounds like it's a more localised problem. i c , thank you very much for the info simon must be the local is then. marc > Simon From internetplumber at gmail.com Sat Jul 18 15:47:37 2009 From: internetplumber at gmail.com (Rob Evans) Date: Sat, 18 Jul 2009 21:47:37 +0100 Subject: Outages in wales ? In-Reply-To: <25D3869E-FBA8-4ED3-AD58-DB5CDDC25DBC@let.de> References: <25D3869E-FBA8-4ED3-AD58-DB5CDDC25DBC@let.de> Message-ID: <9a8fa98b0907181347m1a55abd8j81dc3f7a76cc88e@mail.gmail.com> > but a buddy in wales have massive problems with internet connectivity For those that don't know, Wales is a relatively small constituent country of the United Kingdom (size-wise, it is 'about the size of Wales'): Small as it is, it has a number of different internet providers using ADSL, cable, leased lines and DWDM. For it to be on NANOG, I assume there is reason to believe the outage is widespread and your buddy has already contacted their Internet Service Provider? For what is is worth, I'm not seeing any outages to the academic sites in Wales. Or maybe there has been a bit of storm which has blown it 3,500 miles to the west. If it has, please look after it, especially mid-Wales and North Wales, they really are quite beautiful. :) Best regards, Rob From rshughes at gmail.com Sat Jul 18 17:51:33 2009 From: rshughes at gmail.com (Ryan Hughes) Date: Sat, 18 Jul 2009 18:51:33 -0400 Subject: Nexus 7K usage w/VDC, vPC - anybody? In-Reply-To: References: Message-ID: Currenet 4.1 is a little flaky for vPC; running a set up with 4.1.5ES (TAC release) - recommendation is to wait and go with 4.2.1 when that releases. Haven't had any issues with the VDC features - still using 6500 in the core for the time being. Most installs I've seen have resulted in some TAC case or another. I've had pretty good results with the N5K platform as whole. Ryan On Fri, Jul 17, 2009 at 5:59 PM, Stefan wrote: > I'd be interested to know if anybody has been using the Cisco N7K > platform, especially in vertical consolidation mode (aggr and core as > VDCs, and dual Nexus VPC-ed together)? Any comments on this system, > even outsde this narrow scope of my previous question? Anybody using > these as server access systems, in DCs? > > Thank you, > > > -- > Sent from my mobile device > > ***Stefan Mititelu > http://twitter.com/netfortius > http://www.linkedin.com/in/netfortius > > From john at sackheads.org Sat Jul 18 19:43:28 2009 From: john at sackheads.org (John Payne) Date: Sat, 18 Jul 2009 20:43:28 -0400 Subject: Outages in wales ? In-Reply-To: <20090718200335.GM2898@virtual.bogons.net> References: <25D3869E-FBA8-4ED3-AD58-DB5CDDC25DBC@let.de> <20090718200335.GM2898@virtual.bogons.net> Message-ID: <21C7C89B-D453-49D9-A93E-3000A6840A4D@sackheads.org> On Jul 18, 2009, at 4:03 PM, Simon Lockhart wrote: > On Sat Jul 18, 2009 at 09:31:56PM +0200, Marc Manthey wrote: >> hey peoples sorry for my question >> but a buddy in wales have massive problems with internet connectivity >> can someone confirm ? > > I'm just on the welsh border, and I've not seen any issues reported > - my > home ADSL is up, our office connectivity (in the Welsh valleys) is > up, and > customer networks in Wales are up. > > Sounds like it's a more localised problem. I think my parents are still on plus.net, and I was on our multi hour video chat when this question was posed, so I'm pretty sure Cardiff ADSL was ok :) From marc at let.de Sun Jul 19 05:53:07 2009 From: marc at let.de (Marc Manthey) Date: Sun, 19 Jul 2009 12:53:07 +0200 Subject: Outages in wales ? In-Reply-To: <21C7C89B-D453-49D9-A93E-3000A6840A4D@sackheads.org> References: <25D3869E-FBA8-4ED3-AD58-DB5CDDC25DBC@let.de> <20090718200335.GM2898@virtual.bogons.net> <21C7C89B-D453-49D9-A93E-3000A6840A4D@sackheads.org> Message-ID: <82C29D4A-30F1-441F-9EFE-BBCDF36E3482@let.de> > >> On Sat Jul 18, 2009 at 09:31:56PM +0200, Marc Manthey wrote: >>> hey peoples sorry for my question >>> but a buddy in wales have massive problems with internet >>> connectivity >>> can someone confirm ? >> >> I'm just on the welsh border, and I've not seen any issues reported >> - my >> home ADSL is up, our office connectivity (in the Welsh valleys) is >> up, and >> customer networks in Wales are up. >> >> Sounds like it's a more localised problem. > > I think my parents are still on plus.net, and I was on our multi > hour video chat when this question was posed, so I'm pretty sure > Cardiff ADSL was ok :) thanks john, rob and simon i hope i can visit wales someday :-))) , it looks very nice, but the accent is for me as an europen non native english speaker nearly incomprehensible :-0 greetings Marc -- Les enfants teribbles - research / deployment Marc Manthey Vogelsangerstrasse 97 D - 50823 K?ln - Germany Vogelsangerstrasse 97 Geo: 50.945554, 6.920293 PGP/GnuPG: 0x1ac02f3296b12b4d Tel.:0049-221-29891489 Mobil:0049-1577-3329231 web : http://www.let.de Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. From peter at peter-dambier.de Sun Jul 19 06:31:53 2009 From: peter at peter-dambier.de (Peter Dambier) Date: Sun, 19 Jul 2009 13:31:53 +0200 Subject: Outages in wales ? In-Reply-To: <82C29D4A-30F1-441F-9EFE-BBCDF36E3482@let.de> References: <25D3869E-FBA8-4ED3-AD58-DB5CDDC25DBC@let.de> <20090718200335.GM2898@virtual.bogons.net> <21C7C89B-D453-49D9-A93E-3000A6840A4D@sackheads.org> <82C29D4A-30F1-441F-9EFE-BBCDF36E3482@let.de> Message-ID: <4A630429.3000600@peter-dambier.de> Marc Manthey wrote: > > i hope i can visit wales someday :-))) , it looks very nice, but the > accent is for me as an europen non native english speaker > > nearly incomprehensible :-0 > Hello Marc, it is not an accent. It is a language. In fact most welsh do pronounce english better than either the londoners or the oxford people do. Welsh is kind of a catalan for the gaelic like catalan is for latin. Cheers Peter and Karin -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter at peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ULA= fd80:4ce1:c66a::/48 From brunner at nic-naa.net Sun Jul 19 09:43:52 2009 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sun, 19 Jul 2009 10:43:52 -0400 Subject: Outages in wales ? In-Reply-To: <4A630429.3000600@peter-dambier.de> References: <25D3869E-FBA8-4ED3-AD58-DB5CDDC25DBC@let.de> <20090718200335.GM2898@virtual.bogons.net> <21C7C89B-D453-49D9-A93E-3000A6840A4D@sackheads.org> <82C29D4A-30F1-441F-9EFE-BBCDF36E3482@let.de> <4A630429.3000600@peter-dambier.de> Message-ID: <4A633128.1040309@nic-naa.net> Peter Dambier wrote: > Marc Manthey wrote: > > > i hope i can visit wales someday :-))) , it looks very nice, but the > >> accent is for me as an europen non native english speaker >> >> nearly incomprehensible :-0 >> >> > > Hello Marc, > > it is not an accent. It is a language. > In fact most welsh do pronounce english > better than either the londoners or the > oxford people do. > > Welsh is kind of a catalan for the gaelic like > catalan is for latin. > OT and all but there will be a linguistic and cultural application for Welsh in 2009/2010, using the 2004/2005 linguistic and cultural application for Catalan. From netfortius at gmail.com Sun Jul 19 12:23:17 2009 From: netfortius at gmail.com (Stefan) Date: Sun, 19 Jul 2009 12:23:17 -0500 Subject: Nexus 7K usage w/VDC, vPC - anybody? In-Reply-To: References: Message-ID: Thank you, Ryan, for the info. Interesting your choice of 6500s at the core. I would have expected that layer to be the first "recipient" of N7Ks, then slowly moving into aggr., access, .... You are not running some services modules in the core chassis, are you? On 7/18/09, Ryan Hughes wrote: > Currenet 4.1 is a little flaky for vPC; running a set up with 4.1.5ES (TAC > release) - recommendation is to wait and go with 4.2.1 when that releases. > Haven't had any issues with the VDC features - still using 6500 in the core > for the time being. Most installs I've seen have resulted in some TAC case > or another. I've had pretty good results with the N5K platform as whole. > > Ryan > > On Fri, Jul 17, 2009 at 5:59 PM, Stefan wrote: > >> I'd be interested to know if anybody has been using the Cisco N7K >> platform, especially in vertical consolidation mode (aggr and core as >> VDCs, and dual Nexus VPC-ed together)? Any comments on this system, >> even outsde this narrow scope of my previous question? Anybody using >> these as server access systems, in DCs? >> >> Thank you, >> >> >> -- >> Sent from my mobile device >> >> ***Stefan Mititelu >> http://twitter.com/netfortius >> http://www.linkedin.com/in/netfortius >> >> > -- Sent from my mobile device ***Stefan Mititelu http://twitter.com/netfortius http://www.linkedin.com/in/netfortius From rshughes at gmail.com Sun Jul 19 12:37:53 2009 From: rshughes at gmail.com (Ryan Hughes) Date: Sun, 19 Jul 2009 13:37:53 -0400 Subject: Nexus 7K usage w/VDC, vPC - anybody? In-Reply-To: References: Message-ID: It was an early implementation of Nexus for an enterprise customer for their existing data center. We did the implementation of the Nexus very early on (January) to aggregate HP bladecenter 10G server access. Honestly, N5K's would have made more sense at the end of the day but that wasn't the initial design when they bought the gear. Lots of layer8 issues prevented us from making the Nexus the ASBR/ABR for the core - most specifically was training for the NOC. Llack of service modules didn't win any favoritism either (ACE/NAM). Ryan On Sun, Jul 19, 2009 at 1:23 PM, Stefan wrote: > Thank you, Ryan, for the info. Interesting your choice of 6500s at the > core. I would have expected that layer to be the first "recipient" of > N7Ks, then slowly moving into aggr., access, .... You are not running > some services modules in the core chassis, are you? > > > On 7/18/09, Ryan Hughes wrote: > > Currenet 4.1 is a little flaky for vPC; running a set up with 4.1.5ES > (TAC > > release) - recommendation is to wait and go with 4.2.1 when that > releases. > > Haven't had any issues with the VDC features - still using 6500 in the > core > > for the time being. Most installs I've seen have resulted in some TAC > case > > or another. I've had pretty good results with the N5K platform as whole. > > > > Ryan > > > > On Fri, Jul 17, 2009 at 5:59 PM, Stefan wrote: > > > >> I'd be interested to know if anybody has been using the Cisco N7K > >> platform, especially in vertical consolidation mode (aggr and core as > >> VDCs, and dual Nexus VPC-ed together)? Any comments on this system, > >> even outsde this narrow scope of my previous question? Anybody using > >> these as server access systems, in DCs? > >> > >> Thank you, > >> > >> > >> -- > >> Sent from my mobile device > >> > >> ***Stefan Mititelu > >> http://twitter.com/netfortius > >> http://www.linkedin.com/in/netfortius > >> > >> > > > > -- > Sent from my mobile device > > ***Stefan Mititelu > http://twitter.com/netfortius > http://www.linkedin.com/in/netfortius > From charles at thewybles.com Sun Jul 19 12:49:14 2009 From: charles at thewybles.com (Charles Wyble) Date: Sun, 19 Jul 2009 10:49:14 -0700 Subject: Visio diag automations In-Reply-To: <4A61AA19.8060704@poggs.co.uk> References: <4A61AA19.8060704@poggs.co.uk> Message-ID: <4A635C9A.8000601@thewybles.com> This is built into visio. You can link a drawing to an access database. I did that a few years back. For all the desktops and servers. Right click on the icon pulled up all the data. Did layers... had the network jacks, furniture, computers, printers... everything. Peter Hicks wrote: > Bobby Mac wrote: > >> I have to create Visio diagrams for sales engagements for a webhosting >> provider. I use the same template based on our standard architecture but >> vary the number/model/detail of the servers. I am sick of the >> cut-n-paste >> approach and am wondering who has automated some of these processes. >> What I >> would like to do is provide a standard data file (excel, csv, ect..) and >> have that populate the detailed areas of the diagram. My boss won't >> pay for >> any software but I can use open source under XP or cygwin. > > I attempted to do data-driven diagrams with Visio, but quickly gave up. > I don't think Visio is the right tool for the job. > > Have you thought about writing the diagram in HTML+CSS and laying it out > that way? > > Diagramming is one of the biggest problems I've had in the 10+ years > I've been doing networking. > > > Poggs > From gsh at centrum.is Sun Jul 19 13:00:40 2009 From: gsh at centrum.is (gsh at centrum.is) Date: Sun, 19 Jul 2009 18:00:40 +0000 Subject: Visio diag automations Message-ID: <322292773-1248026449-cardhu_decombobulator_blackberry.rim.net-254281229-@bxe1035.bisx.produk.on.blackberry> Has anybody done the same where a CMDB system was the data source? Rgds, GSH ------Original Message------ From: Charles Wyble To: nanog at nanog.org Subject: Re: Visio diag automations Sent: Jul 19, 2009 17:49 This is built into visio. You can link a drawing to an access database. I did that a few years back. For all the desktops and servers. Right click on the icon pulled up all the data. Did layers... had the network jacks, furniture, computers, printers... everything. Peter Hicks wrote: > Bobby Mac wrote: > >> I have to create Visio diagrams for sales engagements for a webhosting >> provider. I use the same template based on our standard architecture but >> vary the number/model/detail of the servers. I am sick of the >> cut-n-paste >> approach and am wondering who has automated some of these processes. >> What I >> would like to do is provide a standard data file (excel, csv, ect..) and >> have that populate the detailed areas of the diagram. My boss won't >> pay for >> any software but I can use open source under XP or cygwin. > > I attempted to do data-driven diagrams with Visio, but quickly gave up. > I don't think Visio is the right tool for the job. > > Have you thought about writing the diagram in HTML+CSS and laying it out > that way? > > Diagramming is one of the biggest problems I've had in the 10+ years > I've been doing networking. > > > Poggs > Sent from my BlackBerry? wireless device, available from Siminn From charles at thewybles.com Sun Jul 19 13:46:01 2009 From: charles at thewybles.com (Charles Wyble) Date: Sun, 19 Jul 2009 11:46:01 -0700 Subject: Visio diag automations In-Reply-To: <322292773-1248026449-cardhu_decombobulator_blackberry.rim.net-254281229-@bxe1035.bisx.produk.on.blackberry> References: <322292773-1248026449-cardhu_decombobulator_blackberry.rim.net-254281229-@bxe1035.bisx.produk.on.blackberry> Message-ID: <4A6369E9.9070306@thewybles.com> A CMDB is simply a database. The data model I built in Access was essentially a CMDB. So yes, it can be done. Windows Data Access can be used with lots of things. That's all Viso uses for the integration. I rather like http://onecmdb.org/wiki/ gsh at centrum.is wrote: > Has anybody done the same where a CMDB system was the data source? > > Rgds, > GSH > > ------Original Message------ > From: Charles Wyble > To: nanog at nanog.org > Subject: Re: Visio diag automations > Sent: Jul 19, 2009 17:49 > > This is built into visio. > > You can link a drawing to an access database. > > I did that a few years back. For all the desktops and servers. Right > click on the icon pulled up all the data. > > Did layers... had the network jacks, furniture, computers, printers... > everything. > > > > Peter Hicks wrote: >> Bobby Mac wrote: >> >>> I have to create Visio diagrams for sales engagements for a webhosting >>> provider. I use the same template based on our standard architecture but >>> vary the number/model/detail of the servers. I am sick of the >>> cut-n-paste >>> approach and am wondering who has automated some of these processes. >>> What I >>> would like to do is provide a standard data file (excel, csv, ect..) and >>> have that populate the detailed areas of the diagram. My boss won't >>> pay for >>> any software but I can use open source under XP or cygwin. >> I attempted to do data-driven diagrams with Visio, but quickly gave up. >> I don't think Visio is the right tool for the job. >> >> Have you thought about writing the diagram in HTML+CSS and laying it out >> that way? >> >> Diagramming is one of the biggest problems I've had in the 10+ years >> I've been doing networking. >> >> >> Poggs >> > > > > Sent from my BlackBerry? wireless device, available from Siminn From nenolod at systeminplace.net Sun Jul 19 21:09:05 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Sun, 19 Jul 2009 21:09:05 -0500 Subject: What is good in modular routers these days? Message-ID: <1248055745.24895.29.camel@petrie> Hi, I'm looking for a Cisco 2600-like platform, except with the capability of routing with gigabit and 10gigabit linecards (and not being EOL, of course). Ideally it would be capable of doing full BGP tables in the supervision engine, although that isn't necessarily a show stopper right now. Lack of IPv6 support, however, is. Does anyone even make standalone modular routers anymore? I don't need or want switching capabilities as seen on say a Cisco 6500 series platform, as my network topology would not benefit from that, and the cost overhead would probably not justify having it anyway. Right now we are using software routing appliances for this, but they do not tend to fare well in high packets/second scenarios (e.g. inbound DDoS attacks). William -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-800-688-5018 From rdobbins at arbor.net Sun Jul 19 21:13:15 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 20 Jul 2009 09:13:15 +0700 Subject: What is good in modular routers these days? In-Reply-To: <1248055745.24895.29.camel@petrie> References: <1248055745.24895.29.camel@petrie> Message-ID: <2F8337D0-7302-4B44-8147-A6A7EFBFF1A8@arbor.net> On Jul 20, 2009, at 9:09 AM, William Pitcock wrote: > Does anyone even make standalone modular routers anymore? The Cisco ASR 1000 and the Juniper M7i/M10i routers are standalone modular routers capable of handling mpps in hardware. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From swmike at swm.pp.se Sun Jul 19 21:45:17 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 20 Jul 2009 04:45:17 +0200 (CEST) Subject: What is good in modular routers these days? In-Reply-To: <1248055745.24895.29.camel@petrie> References: <1248055745.24895.29.camel@petrie> Message-ID: On Sun, 19 Jul 2009, William Pitcock wrote: > I'm looking for a Cisco 2600-like platform, except with the capability > of routing with gigabit and 10gigabit linecards (and not being EOL, of > course). Ideally it would be capable of doing full BGP tables in the > supervision engine, although that isn't necessarily a show stopper right > now. Lack of IPv6 support, however, is. There are no CPU based routers with proper 10GE forwarding capabilities that I am aware of, closest would be network processor based (which some might argue is a lot of CPUs in some cases, but it's not a 2600 type CPU anyway). Single-thread CPU just isn't fast enough to handle the PPS involved (currently). -- Mikael Abrahamsson email: swmike at swm.pp.se From eddy+public+spam at noc.everquick.net Sun Jul 19 22:02:51 2009 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Mon, 20 Jul 2009 03:02:51 +0000 (GMT) Subject: What is good in modular routers these days? In-Reply-To: References: <1248055745.24895.29.camel@petrie> Message-ID: MA> Date: Mon, 20 Jul 2009 04:45:17 +0200 (CEST) MA> From: Mikael Abrahamsson MA> There are no CPU based routers with proper 10GE forwarding MA> capabilities that I am aware of, closest would be network processor MA> based (which some might argue is a lot of CPUs in some cases, but MA> it's not a 2600 type CPU anyway). MA> MA> Single-thread CPU just isn't fast enough to handle the PPS involved MA> (currently). With a little creativity, it can _almost_ be done for IPv4. With an efficient FIB algorithm, a single core on a Xeon 5400 will exceed 30 million lookups per second for IPv4 -- full table and lots of peers. Of course, that fails to accomodate RIB maintenance and FIB updates. It also doesn't take into account modern SMP CPUs; the RIB-handling code is still under development. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita LinkedIn: http://www.linkedin.com/in/0xebd ________________________________________________________________________ DO NOT send mail to the following addresses: davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From swmike at swm.pp.se Mon Jul 20 00:31:13 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 20 Jul 2009 07:31:13 +0200 (CEST) Subject: What is good in modular routers these days? In-Reply-To: References: <1248055745.24895.29.camel@petrie> Message-ID: On Mon, 20 Jul 2009, Edward B. DREGER wrote: > With a little creativity, it can _almost_ be done for IPv4. That's most likely a big _almost_. > With an efficient FIB algorithm, a single core on a Xeon 5400 will > exceed 30 million lookups per second for IPv4 -- full table and lots > of peers. When someone asks for "2600 class router" they probably also want WFQ/fairqueue/LLQ, L2TPv3, PPPoE and a heap of other things that impede pps quite a lot on a CPU based platform. > Of course, that fails to accomodate RIB maintenance and FIB updates. It > also doesn't take into account modern SMP CPUs; the RIB-handling code is > still under development. If you can bring all (or most) of the IOS functionality into a modern Intel Xeon/i7 platform with all that memory access speed etc and you use all the cores efficiently, then you might be able to do a lot. I've heard a lot of claims before (Lule? Algorithm from Effnet for instance) but it never came to much because functionality/stability is everything, if I want a stupid pps forwarding device I might as well get myself an L3 switch, it'll use less power and have less parts that can break. -- Mikael Abrahamsson email: swmike at swm.pp.se From neil at DOMINO.ORG Mon Jul 20 05:26:00 2009 From: neil at DOMINO.ORG (Neil J. McRae) Date: Mon, 20 Jul 2009 11:26:00 +0100 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: References: <4A60ED8A.9000906@kingrst.com> Message-ID: <002501ca0924$7a210f20$6e632d60$@ORG> Personally I'd avoid this platform given 6+ years of trying to make it work reliably. GSR is far better platform. From neil at DOMINO.ORG Mon Jul 20 05:27:44 2009 From: neil at DOMINO.ORG (Neil J. McRae) Date: Mon, 20 Jul 2009 11:27:44 +0100 Subject: Cisco 12000 series routers and IOS XR. In-Reply-To: References: Message-ID: <002801ca0924$b8451c10$28cf5430$@ORG> Jim, We converted our entire 12K backbone to IOS XR, it was painful but Its been relatively stable since. Haven't seen any issues like this. What SPA are you using? Neil. -----Original Message----- From: Jim Wininger [mailto:jwininger at indianafiber.net] Sent: 13 July 2009 21:20 To: nanog at nanog.org Subject: Cisco 12000 series routers and IOS XR. Is anyone on the list running the Cisco 12000 Series routers with XR? We have a couple of these in our network and are having a few issues with them. Specifically the line cards will reboot for some unknown reason (12000-SIP-501). We recently replaced one of the cards and the new hardware (<6mo old) is doing the same thing. Anyone have issues with these routers? -- Jim Wininger No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.20/2249 - Release Date: 07/19/09 17:59:00 From rdobbins at arbor.net Mon Jul 20 05:57:24 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 20 Jul 2009 17:57:24 +0700 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: <002501ca0924$7a210f20$6e632d60$@ORG> References: <4A60ED8A.9000906@kingrst.com> <002501ca0924$7a210f20$6e632d60$@ORG> Message-ID: On Jul 20, 2009, at 5:26 PM, Neil J. McRae wrote: > GSR is far better platform. Concur 100%. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Mon Jul 20 06:47:10 2009 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 20 Jul 2009 21:17:10 +0930 Subject: Outages in wales ? In-Reply-To: <9a8fa98b0907181347m1a55abd8j81dc3f7a76cc88e@mail.gmail.com> References: <25D3869E-FBA8-4ED3-AD58-DB5CDDC25DBC@let.de> <9a8fa98b0907181347m1a55abd8j81dc3f7a76cc88e@mail.gmail.com> Message-ID: <20090720211710.67bb1564.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> On Sat, 18 Jul 2009 21:47:37 +0100 Rob Evans wrote: > > but a buddy in wales have massive problems with internet connectivity > > > Or maybe there has been a bit of storm which has blown it 3,500 miles > to the west. If it has, please look after it, especially mid-Wales > and North Wales, they really are quite beautiful. :) > Not to be confused with New South Wales (where Sydney is), which is a state of Australia (and I'm assuming, looks like the southern part of Wales, but newer, or did a couple of hundred years ago). I'm in South Australia though, which, despite the name, doesn't actually cover all of the south of Australia. If it did, there would be no New South Wales or Victoria, or part of Western Australia (which does actually cover pretty much the western part of Australia). > Best regards, > Rob > From eddy+public+spam at noc.everquick.net Mon Jul 20 07:02:06 2009 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Mon, 20 Jul 2009 12:02:06 +0000 (GMT) Subject: What is good in modular routers these days? In-Reply-To: References: <1248055745.24895.29.camel@petrie> Message-ID: MA> Date: Mon, 20 Jul 2009 07:31:13 +0200 (CEST) MA> From: Mikael Abrahamsson MA> > With a little creativity, it can _almost_ be done for IPv4. MA> MA> That's most likely a big _almost_. Maybe. And maybe I'm using worst-case synthetic test sets in addition to real routing sets. MA> When someone asks for "2600 class router" they probably also want "2600-like platform" And I'm unaware of Cisco 2600-class routers that handle anywhere close to 10 Gbps. MA> WFQ/fairqueue/LLQ, L2TPv3, PPPoE and a heap of other things that MA> impede pps quite a lot on a CPU based platform. Perhaps the OP can clarify whether his omission of these was accidental, because such features were assumed, or because he does not need them. MA> If you can bring all (or most) of the IOS functionality into a modern Intel MA> Xeon/i7 platform with all that memory access speed etc and you use all the MA> cores efficiently, then you might be able to do a lot. I've heard a lot of And minimize both task switching and packets' in-queue time. I'm aware of the requirements. MA> claims before (Lule? Algorithm from Effnet for instance) but it never came I was unaware of Lulea. I've [obviously] not implemented it, and can't comment on performance with modern loads and CPUs. However, it's encumbered -- although I question the patent-worthiness of what I see described. Route updates appear painful, which obviously would be problematic. (I went down the painful-updates fox hole half a dozen years ago. Yes, it's a dealbreaker.) Other algorithms exist in the literature. The truly insane might even be able to "strike gold" with a little creativity. MA> to much because functionality/stability is everything, if I want a stupid We also could argue the stability of the routers that he has used, and of COTS boxes. I seem to recall having to load an interim IOS release (on 2600-series boxes even!) due to instability. MA> pps forwarding device I might as well get myself an L3 switch, it'll use MA> less power and have less parts that can break. Perhaps the OP can clarify his requirements. I understood him to want low cost and high PPS, with IPv6 being mandatory. A list of priorities and non-priorities might be useful. I interpretted the post as being keen on high processing power and low cost. On a semi-related note: Has anyone dealt with Cavium (or similar) NICs? Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita LinkedIn: http://www.linkedin.com/in/0xebd ________________________________________________________________________ DO NOT send mail to the following addresses: davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From Stephen.Bailey at uk.fujitsu.com Mon Jul 20 08:22:22 2009 From: Stephen.Bailey at uk.fujitsu.com (Bailey Stephen) Date: Mon, 20 Jul 2009 14:22:22 +0100 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: References: Message-ID: I previously ran a single 7609 with dual Sup720's as a Core Internet BGP Router, running OSPF & iBGP Never had any problems and was a very stable platform Stephen Bailey - Senior Lead Systems Engineer FUJITSU Fujitsu Services Limited, Registered in England no 96056, Registered Office 22 Baker Street, London, W1U 3BW This e-mail is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu Services does not guarantee that this e-mail has not been intercepted and amended or that it is virus-free. -----Original Message----- From: Jim Wininger [mailto:jwininger at indianafiber.net] Sent: 17 July 2009 22:23 To: nanog at nanog.org Subject: Cisco 7600 (7609) as a core BGP router. I have an opportuniy to put two 7609s into the core of my network. Currently we have 3 upstream providers, taking full BGP routes. (2 in one router and one in another). We have 17 BGP peers/customers (peering to each router), and adding about one new BGP peer every 2-3 months. It is a modest network by most standards. We are running OSPF and BGP between the existing routers. Not rocket science, nothing special (no MPLS, no VRF etc), very simple network. Does anyone have any recommendations on the 7600's as a core BGP router? Good or bad? Have they been a stable platform in a core/BGP environment? -- Jim Wininger From pstewart at nexicomgroup.net Mon Jul 20 08:37:18 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Mon, 20 Jul 2009 09:37:18 -0400 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: <002501ca0924$7a210f20$6e632d60$@ORG> References: <4A60ED8A.9000906@kingrst.com> <002501ca0924$7a210f20$6e632d60$@ORG> Message-ID: Agreed... we migrated away from GSR to 7600 and now looking at migrating back...;) GSR was 100% rock solid for us with PRP-2 processors.... sup720-3bxl has been good but no comparison... -----Original Message----- From: Neil J. McRae [mailto:neil at DOMINO.ORG] Sent: Monday, July 20, 2009 6:26 AM To: nanog at nanog.org Subject: RE: Cisco 7600 (7609) as a core BGP router. Personally I'd avoid this platform given 6+ years of trying to make it work reliably. GSR is far better platform. ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From ras at e-gerbil.net Mon Jul 20 08:46:59 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Mon, 20 Jul 2009 08:46:59 -0500 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: References: Message-ID: <20090720134659.GC51443@gerbil.cluepon.net> On Mon, Jul 20, 2009 at 02:22:22PM +0100, Bailey Stephen wrote: > I previously ran a single 7609 with dual Sup720's as a Core Internet BGP > Router, running OSPF & iBGP It's hard to classify a single router as a "core", don't you think? -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From brandon.galbraith at gmail.com Mon Jul 20 08:50:00 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Mon, 20 Jul 2009 08:50:00 -0500 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: <20090720134659.GC51443@gerbil.cluepon.net> References: <20090720134659.GC51443@gerbil.cluepon.net> Message-ID: <366100670907200650i1dcd4a15qc56311450031f960@mail.gmail.com> On Mon, Jul 20, 2009 at 8:46 AM, Richard A Steenbergen wrote: > On Mon, Jul 20, 2009 at 02:22:22PM +0100, Bailey Stephen wrote: > > I previously ran a single 7609 with dual Sup720's as a Core Internet BGP > > Router, running OSPF & iBGP > > It's hard to classify a single router as a "core", don't you think? > Is two enough? ;) > > -- > Richard A Steenbergen http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > > -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From r.hyunseog at ieee.org Mon Jul 20 09:50:45 2009 From: r.hyunseog at ieee.org (Alex H. Ryu) Date: Mon, 20 Jul 2009 09:50:45 -0500 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: References: <4A60ED8A.9000906@kingrst.com> <002501ca0924$7a210f20$6e632d60$@ORG> Message-ID: <4A648445.7030909@ieee.org> Because of nowadays network scalability demands, Cisco is preparing ASR 14000 series to replace this one, I think. ^^ Basically ASR 14000 is downgrade version of CRS-1, but I consider it is still developing or beta product. Alex Paul Stewart wrote: > Agreed... we migrated away from GSR to 7600 and now looking at migrating > back...;) GSR was 100% rock solid for us with PRP-2 processors.... > sup720-3bxl has been good but no comparison... > > -----Original Message----- > From: Neil J. McRae [mailto:neil at DOMINO.ORG] > Sent: Monday, July 20, 2009 6:26 AM > To: nanog at nanog.org > Subject: RE: Cisco 7600 (7609) as a core BGP router. > > Personally I'd avoid this platform given 6+ years of trying to make it > work > reliably. GSR is far better platform. > > > > > > > ---------------------------------------------------------------------------- > > "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." > > > > . > > From rdobbins at arbor.net Mon Jul 20 09:55:38 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 20 Jul 2009 21:55:38 +0700 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: <4A648445.7030909@ieee.org> References: <4A60ED8A.9000906@kingrst.com> <002501ca0924$7a210f20$6e632d60$@ORG> <4A648445.7030909@ieee.org> Message-ID: <3A77ABB7-7C6D-4122-8A98-1D40FB661401@arbor.net> On Jul 20, 2009, at 9:50 PM, Alex H. Ryu wrote: > Cisco is preparing ASR 14000 series to replace this one, I think. It's always a good idea to check the status/availability of a given platform prior to making any plans which depend upon it. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From tvarriale at comcast.net Mon Jul 20 09:53:49 2009 From: tvarriale at comcast.net (Tony Varriale) Date: Mon, 20 Jul 2009 09:53:49 -0500 Subject: Cisco 7600 (7609) as a core BGP router. References: <20090720134659.GC51443@gerbil.cluepon.net> Message-ID: <6C5B2CD2E48C423F8AB7E2AC397CF280@flamdt01> Core typically references functionality, not the number of network devices at that layer. tv ----- Original Message ----- From: "Richard A Steenbergen" To: "Bailey Stephen" Cc: Sent: Monday, July 20, 2009 8:46 AM Subject: Re: Cisco 7600 (7609) as a core BGP router. > On Mon, Jul 20, 2009 at 02:22:22PM +0100, Bailey Stephen wrote: >> I previously ran a single 7609 with dual Sup720's as a Core Internet BGP >> Router, running OSPF & iBGP > > It's hard to classify a single router as a "core", don't you think? > > -- > Richard A Steenbergen http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > From nenolod at systeminplace.net Mon Jul 20 09:58:46 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 20 Jul 2009 09:58:46 -0500 Subject: What is good in modular routers these days? In-Reply-To: References: <1248055745.24895.29.camel@petrie> Message-ID: <1248101926.24895.33.camel@petrie> On Mon, 2009-07-20 at 12:02 +0000, Edward B. DREGER wrote: > MA> Date: Mon, 20 Jul 2009 07:31:13 +0200 (CEST) > MA> From: Mikael Abrahamsson > > MA> > With a little creativity, it can _almost_ be done for IPv4. > MA> > MA> That's most likely a big _almost_. > > Maybe. And maybe I'm using worst-case synthetic test sets in addition > to real routing sets. > > > MA> When someone asks for "2600 class router" they probably also want > > "2600-like platform" > > And I'm unaware of Cisco 2600-class routers that handle anywhere close > to 10 Gbps. Ideally the forwarding would be done with ASICs. The Cisco asr1000 class router seems to be what I'm looking for. > > MA> WFQ/fairqueue/LLQ, L2TPv3, PPPoE and a heap of other things that > MA> impede pps quite a lot on a CPU based platform. > > Perhaps the OP can clarify whether his omission of these was accidental, > because such features were assumed, or because he does not need them. > I don't need any of that stuff, just BGP, OSPF and fast packet forwarding for IPv4. But the point is that I need only routing functionality, I don't need switching functionality like on a Cisco 6500-class system. William -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-800-688-5018 From charles at thewybles.com Mon Jul 20 10:28:35 2009 From: charles at thewybles.com (Charles Wyble) Date: Mon, 20 Jul 2009 08:28:35 -0700 Subject: Seeking facilities managers at colo facilities Message-ID: <4A648D23.6050503@thewybles.com> All, I'm working on a grant for a new type of power co generation. We need a letter of interest as part of our application. Are there any facilities managers who would be interested in working with me on this? Specifically folks who are doing work with container based systems. More details available upon request, serious responses only. Thanks. Charles Wyble charles at thewybles.com From ge at linuxbox.org Mon Jul 20 10:39:42 2009 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 20 Jul 2009 18:39:42 +0300 Subject: [Fwd: [ GLSA 200907-15 ] Nagios: Execution of arbitrary code] Message-ID: <4A648FBE.9010203@linuxbox.org> While this is the Gentoo advisory, it's generic enough. Gadi. -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ -------------- next part -------------- An embedded message was scrubbed... From: Robert Buchholz Subject: [ GLSA 200907-15 ] Nagios: Execution of arbitrary code Date: Sun, 19 Jul 2009 20:13:01 +0200 Size: 6425 URL: From mohacsi at niif.hu Mon Jul 20 11:27:10 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Mon, 20 Jul 2009 18:27:10 +0200 (CEST) Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: <4A648445.7030909@ieee.org> References: <4A60ED8A.9000906@kingrst.com> <002501ca0924$7a210f20$6e632d60$@ORG> <4A648445.7030909@ieee.org> Message-ID: On Mon, 20 Jul 2009, Alex H. Ryu wrote: > > Because of nowadays network scalability demands, Cisco is preparing ASR > 14000 series to replace this one, I think. ^^ > Basically ASR 14000 is downgrade version of CRS-1, but I consider it is > still developing or beta product. As far as I know Cisco cancelled ASR14000 platform, but the developed supervisor will be available to CRS-1 platform.... Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 > > Alex > > > Paul Stewart wrote: >> Agreed... we migrated away from GSR to 7600 and now looking at migrating >> back...;) GSR was 100% rock solid for us with PRP-2 processors.... >> sup720-3bxl has been good but no comparison... >> >> -----Original Message----- >> From: Neil J. McRae [mailto:neil at DOMINO.ORG] >> Sent: Monday, July 20, 2009 6:26 AM >> To: nanog at nanog.org >> Subject: RE: Cisco 7600 (7609) as a core BGP router. >> >> Personally I'd avoid this platform given 6+ years of trying to make it >> work >> reliably. GSR is far better platform. >> >> >> >> >> >> >> ---------------------------------------------------------------------------- >> >> "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." >> >> >> >> . >> >> > > > From r.hyunseog at ieee.org Mon Jul 20 11:35:08 2009 From: r.hyunseog at ieee.org (Alex H. Ryu) Date: Mon, 20 Jul 2009 11:35:08 -0500 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: References: <4A60ED8A.9000906@kingrst.com> <002501ca0924$7a210f20$6e632d60$@ORG> <4A648445.7030909@ieee.org> Message-ID: <4A649CBC.9030200@ieee.org> About 3 months ago, Cisco Account Team was recommending AS14000 for our company, and we rejected it. Poor product development management! Alex Mohacsi Janos wrote: > > > > On Mon, 20 Jul 2009, Alex H. Ryu wrote: > >> >> Because of nowadays network scalability demands, Cisco is preparing ASR >> 14000 series to replace this one, I think. ^^ >> Basically ASR 14000 is downgrade version of CRS-1, but I consider it is >> still developing or beta product. > > > As far as I know Cisco cancelled ASR14000 platform, but the developed > supervisor will be available to CRS-1 platform.... > > Janos Mohacsi > Network Engineer, Research Associate, Head of Network Planning and > Projects > NIIF/HUNGARNET, HUNGARY > Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 > >> >> Alex >> >> >> Paul Stewart wrote: >>> Agreed... we migrated away from GSR to 7600 and now looking at >>> migrating >>> back...;) GSR was 100% rock solid for us with PRP-2 processors.... >>> sup720-3bxl has been good but no comparison... >>> >>> -----Original Message----- >>> From: Neil J. McRae [mailto:neil at DOMINO.ORG] >>> Sent: Monday, July 20, 2009 6:26 AM >>> To: nanog at nanog.org >>> Subject: RE: Cisco 7600 (7609) as a core BGP router. >>> >>> Personally I'd avoid this platform given 6+ years of trying to make it >>> work >>> reliably. GSR is far better platform. >>> >>> >>> >>> >>> >>> >>> ---------------------------------------------------------------------------- >>> >>> >>> "The information transmitted is intended only for the person or >>> entity to which it is addressed and contains confidential and/or >>> privileged material. If you received this in error, please contact >>> the sender immediately and then destroy this transmission, including >>> all attachments, without copying, distributing or disclosing same. >>> Thank you." >>> >>> >>> >>> . >>> >>> >> >> >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From swmike at swm.pp.se Mon Jul 20 12:20:00 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 20 Jul 2009 19:20:00 +0200 (CEST) Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: References: <4A60ED8A.9000906@kingrst.com> <002501ca0924$7a210f20$6e632d60$@ORG> <4A648445.7030909@ieee.org> Message-ID: On Mon, 20 Jul 2009, Mohacsi Janos wrote: > As far as I know Cisco cancelled ASR14000 platform, but the developed > supervisor will be available to CRS-1 platform.... The FP-40 (downscaled MSC) has been in the price list for over a month now. -- Mikael Abrahamsson email: swmike at swm.pp.se From adrian at creative.net.au Mon Jul 20 21:31:00 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 21 Jul 2009 10:31:00 +0800 Subject: What is good in modular routers these days? In-Reply-To: <1248101926.24895.33.camel@petrie> References: <1248055745.24895.29.camel@petrie> <1248101926.24895.33.camel@petrie> Message-ID: <20090721023059.GA3554@skywalker.creative.net.au> On Mon, Jul 20, 2009, William Pitcock wrote: > I don't need any of that stuff, just BGP, OSPF and fast packet > forwarding for IPv4. But the point is that I need only routing > functionality, I don't need switching functionality like on a Cisco > 6500-class system. I bet if you went and spoke to the right people in the correct open source kernel/distribution project, -given the right clue-, very fast forwarding and QoS could start appearing in *NIX OSes. The problem I see is there's a lot of demand -once it is done-, but no one org or group willing to pony up to see it happen. The clue is out there. They're just looking for a way to pay the rent. Adrian (Not looking to do this, I have enough going on atm..) From kanagaraj at globaltransit.net Tue Jul 21 01:55:24 2009 From: kanagaraj at globaltransit.net (Kanagaraj) Date: Tue, 21 Jul 2009 14:55:24 +0800 Subject: What is the most standard subnet length on internet In-Reply-To: <10068989.128811229991024019.JavaMail.weblogic@epml06> References: <10068989.128811229991024019.JavaMail.weblogic@epml06> Message-ID: <4A65665C.1040207@globaltransit.net> Basically /24s are the longest prefix size accepted by providers unless you are dealing RTBH (triggered blackholing services). Another requirement to ensure acceptance of an IP block, especially smaller assignments are equivalent route objects matching it (in most cases your provider will do it on your behalf). /Kana > Hi all, > > I appreciate many people gave me advices, > Some of persons asked me about my questions, I'm sorry for that I couldn't reply to everyone. > Because of your help, I could get many opinions and standards regarding IP allocation policy. > > by the way, in APNIC's IP allocation sizes policy, there is a comments like below. > "Below are the minimum sizes for allocations and assignments, This information is provided at the request of the ISP community > to assist in filtering policy decisions " > Currently, is there any provider filtering routes under LIR's minimum allocation size such as /22 ? > > Best regards, > ============================================= > Chi-Young Joung > SAMSUNG NETWORKS Inc. > Email: lionair at samsung.com > Tel +82 70 7015 0623, Mobile +82 17 520 9193 > Fax +82 70 7016 0031 > ============================================= > > ------- Original Message ------- > Sender : Danny McPherson > Date : 2008-12-21 02:42 (GMT+09:00) > Title : Re: What is the most standard subnet length on internet > > > On Dec 18, 2008, at 9:43 PM, ??? wrote: > > >> Suresh, >> >> Yes, I guess my concern is close to the second meaning. >> >> It seems so simple. Currently annoucement of /24 seems to be okey, >> most upstream providers accept this. >> However I wonder if there is any ground rule based on any standard >> or official recommandation. >> If there is some standardized rule about prefix length to be >> annouced, I will make my bgp & IP allocation policy of >> each data center of my company, and I will be able to more fairly >> and squarely speak to my customer like this >> "You have to change your server's IP address if you want move your >> server to other place" >> > > Some useful guidance is provided here (and in > subsequent references) as well: > > An Architecture for IP Address Allocation with CIDR > > > Classless Inter-Domain Routing (CIDR): an Address Assignment and > Aggregation Strategy > > > Network Renumbering Overview > > > A Framework for Inter-Domain Route Aggregation > > > HTH, > > -danny > > From linux.yahoo at gmail.com Tue Jul 21 05:08:10 2009 From: linux.yahoo at gmail.com (Manu Chao) Date: Tue, 21 Jul 2009 12:08:10 +0200 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: <4A649CBC.9030200@ieee.org> References: <4A60ED8A.9000906@kingrst.com> <002501ca0924$7a210f20$6e632d60$@ORG> <4A648445.7030909@ieee.org> <4A649CBC.9030200@ieee.org> Message-ID: <7100ed370907210308y4cf7ce62hc369061580c22cd6@mail.gmail.com> what about ASR 9000? 2009/7/20 Alex H. Ryu > > About 3 months ago, Cisco Account Team was recommending AS14000 for our > company, and we rejected it. > Poor product development management! > > > Alex > > > Mohacsi Janos wrote: > > > > > > > > On Mon, 20 Jul 2009, Alex H. Ryu wrote: > > > >> > >> Because of nowadays network scalability demands, Cisco is preparing ASR > >> 14000 series to replace this one, I think. ^^ > >> Basically ASR 14000 is downgrade version of CRS-1, but I consider it is > >> still developing or beta product. > > > > > > As far as I know Cisco cancelled ASR14000 platform, but the developed > > supervisor will be available to CRS-1 platform.... > > > > Janos Mohacsi > > Network Engineer, Research Associate, Head of Network Planning and > > Projects > > NIIF/HUNGARNET, HUNGARY > > Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 > > > >> > >> Alex > >> > >> > >> Paul Stewart wrote: > >>> Agreed... we migrated away from GSR to 7600 and now looking at > >>> migrating > >>> back...;) GSR was 100% rock solid for us with PRP-2 processors.... > >>> sup720-3bxl has been good but no comparison... > >>> > >>> -----Original Message----- > >>> From: Neil J. McRae [mailto:neil at DOMINO.ORG] > >>> Sent: Monday, July 20, 2009 6:26 AM > >>> To: nanog at nanog.org > >>> Subject: RE: Cisco 7600 (7609) as a core BGP router. > >>> > >>> Personally I'd avoid this platform given 6+ years of trying to make it > >>> work > >>> reliably. GSR is far better platform. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > ---------------------------------------------------------------------------- > >>> > >>> > >>> "The information transmitted is intended only for the person or > >>> entity to which it is addressed and contains confidential and/or > >>> privileged material. If you received this in error, please contact > >>> the sender immediately and then destroy this transmission, including > >>> all attachments, without copying, distributing or disclosing same. > >>> Thank you." > >>> > >>> > >>> > >>> . > >>> > >>> > >> > >> > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From rdobbins at arbor.net Tue Jul 21 05:20:04 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 21 Jul 2009 17:20:04 +0700 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: <7100ed370907210308y4cf7ce62hc369061580c22cd6@mail.gmail.com> References: <4A60ED8A.9000906@kingrst.com> <002501ca0924$7a210f20$6e632d60$@ORG> <4A648445.7030909@ieee.org> <4A649CBC.9030200@ieee.org> <7100ed370907210308y4cf7ce62hc369061580c22cd6@mail.gmail.com> Message-ID: <6F6CF454-03E0-4C61-87E2-409C9E2FFF8E@arbor.net> On Jul 21, 2009, at 5:08 PM, Manu Chao wrote: > what about ASR 9000? No NetFlow, as least for now (this is important in edge applications, not so much in core); the hardware can do it, but it's yet to be implemented, AFAIK. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From jwininger at indianafiber.net Tue Jul 21 08:50:53 2009 From: jwininger at indianafiber.net (Jim Wininger) Date: Tue, 21 Jul 2009 09:50:53 -0400 Subject: Cisco 12000 series routers and IOS XR. In-Reply-To: <002801ca0924$b8451c10$28cf5430$@ORG> Message-ID: Neil, What release ox XR are you on? We had the 12000-SIP-501 in both 12ks but juet RMAed one of them and receive a 12000-SIP-601. The SPA-5X1Ge remain the same. What hardware are you running? If I may ask, what do you mean by "painful". Our experience with the 12000 (running ISO XR day one) has been quite an exercise in frustration. NAME: "0/0/CPU0", DESCR: "Cisco 12000 Series SPA Interface Processor- 501" PID: 12000-SIP-501 NAME: "0/0/0", DESCR: "5-port 1 GbE Shared Port Adapter" PID: SPA-5X1GE On 7/20/09 6:27 AM, "Neil J. McRae" wrote: > Jim, > We converted our entire 12K backbone to IOS XR, it was painful but > Its been relatively stable since. Haven't seen any issues like this. > What SPA are you using? > > Neil. > > -----Original Message----- > From: Jim Wininger [mailto:jwininger at indianafiber.net] > Sent: 13 July 2009 21:20 > To: nanog at nanog.org > Subject: Cisco 12000 series routers and IOS XR. > > Is anyone on the list running the Cisco 12000 Series routers with XR? We > have a couple of these in our network and are having a few issues with them. > > Specifically the line cards will reboot for some unknown reason > (12000-SIP-501). We recently replaced one of the cards and the new hardware > (<6mo old) is doing the same thing. > > Anyone have issues with these routers? -- Jim Wininger Indiana Fiber Network Desk - 317-777-7114 Cell - 317-432-7609 Office - 317-280-4636 CONFIDENTIALITY NOTICE: The information contained in this electronic mail transmission (including any attachment) is intended for the exclusive use of the named recipient and may contain information that is privileged or otherwise confidential. It is not intended for transmission to, or receipt by, anyone other than the named recipient (or person authorized to deliver it to the named recipient). It should not be copied or forwarded to any unauthorized person. If you have received this electronic mail transmission in error, please delete it from your system including any attachment without copying or forwarding it, and notify the sender of the error by return e-mail. From MPetersen at gs1us.org Tue Jul 21 10:46:57 2009 From: MPetersen at gs1us.org (Petersen, Mark) Date: Tue, 21 Jul 2009 11:46:57 -0400 Subject: What is good in modular routers these days? In-Reply-To: <20090721023059.GA3554@skywalker.creative.net.au> References: <1248055745.24895.29.camel@petrie><1248101926.24895.33.camel@petrie> <20090721023059.GA3554@skywalker.creative.net.au> Message-ID: <54B7F7DBCA12D94CA3FE17B68F1461A706671446@LVNJEVS205.UCCORG.org> FreeBSD has done work to optimize for 10gbps and they have a nice netperf cluster for testing http://www.freebsd.org/projects/netperf/cluster.html#resources >From http://www.freebsd.org/features.html - "10Gbps network optimization: With optimized device drivers from all major 10gbps network vendors, FreeBSD 7.0 has seen extensive optimization of the network stack for high performance workloads, including auto-scaling socket buffers, TCP Segment Offload (TSO), Large Receive Offload (LRO), direct network stack dispatch, and load balancing of TCP/IP workloads over multiple CPUs on supporting 10gbps cards or when multiple network interfaces are in use simultaneously. Full vendor support is available from Chelsio, Intel, Myricom, and Neterion." FreeBSD provides support for 802.11q, bgpd, ospfd, pf(firewall) and ALTQ(QOS) but since I haven't tested it I have no idea what kind of real world performance you can get with all these features in use. This is one group trying to pony up at least with support of many major vendors. mark -----Original Message----- From: Adrian Chadd [mailto:adrian at creative.net.au] Sent: Monday, July 20, 2009 9:31 PM To: William Pitcock Cc: nanog at nanog.org Subject: Re: What is good in modular routers these days? On Mon, Jul 20, 2009, William Pitcock wrote: > I don't need any of that stuff, just BGP, OSPF and fast packet > forwarding for IPv4. But the point is that I need only routing > functionality, I don't need switching functionality like on a Cisco > 6500-class system. I bet if you went and spoke to the right people in the correct open source kernel/distribution project, -given the right clue-, very fast forwarding and QoS could start appearing in *NIX OSes. The problem I see is there's a lot of demand -once it is done-, but no one org or group willing to pony up to see it happen. The clue is out there. They're just looking for a way to pay the rent. Adrian (Not looking to do this, I have enough going on atm..) From lmay at nframe.com Tue Jul 21 11:35:55 2009 From: lmay at nframe.com (Larry May) Date: Tue, 21 Jul 2009 12:35:55 -0400 Subject: Cisco 7600 (7609) as a core BGP router. Message-ID: <053E179161004E4C91C8613916AA37B9052051EE@nframemail01.nframe.local> We purchased one 7609 for deployment of transit BGP...it doesn't come close to the performance of a GSR w/PRP2's. Extremely high CPU useage on the 7609 with each BGP session... But on the 6509's...it does fine... Larry May Network Services n|Frame 888-223-8633 From adrian at creative.net.au Tue Jul 21 11:45:31 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Wed, 22 Jul 2009 00:45:31 +0800 Subject: What is good in modular routers these days? In-Reply-To: <54B7F7DBCA12D94CA3FE17B68F1461A706671446@LVNJEVS205.UCCORG.org> References: <20090721023059.GA3554@skywalker.creative.net.au> <54B7F7DBCA12D94CA3FE17B68F1461A706671446@LVNJEVS205.UCCORG.org> Message-ID: <20090721164531.GB8772@skywalker.creative.net.au> On Tue, Jul 21, 2009, Petersen, Mark wrote: > FreeBSD provides support for 802.11q, bgpd, ospfd, pf(firewall) and > ALTQ(QOS) but since I haven't tested it I have no idea what kind of real > world performance you can get with all these features in use. > > This is one group trying to pony up at least with support of many major > vendors. The main current funding source for work being committed back to FreeBSD's 10GE performance has a very big focus on server performance, not forwarding performance. Hence the flow cache, which benefits TCP stream performance. Adrian From mhuff at ox.com Tue Jul 21 12:06:04 2009 From: mhuff at ox.com (Matthew Huff) Date: Tue, 21 Jul 2009 13:06:04 -0400 Subject: Opensource or Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: <54B7F7DBCA12D94CA3FE17B68F1461A706671446@LVNJEVS205.UCCORG.org> References: <1248055745.24895.29.camel@petrie><1248101926.24895.33.camel@petrie> <20090721023059.GA3554@skywalker.creative.net.au> <54B7F7DBCA12D94CA3FE17B68F1461A706671446@LVNJEVS205.UCCORG.org> Message-ID: <483E6B0272B0284BA86D7596C40D29F9D12212801D@PUR-EXCH07.ox.com> I'm putting together a list of NMS systems for system (hardware, cpu util%, memory util%) and application monitoring rather than network management for our environment. We are looking for low cost / opensource solutions that have agents and/or reliable agentless monitoring for windows, linux and solaris hosts. I've put together a preliminary list, but was hoping that if someone has a solution they are happy with they would forward the info to me. Once I get the complete list, I'll re-post what I've found. The list I have so far is: Hyperic http://www.hyperic.com/ OpenNMS http://www.opennms.org/wiki/Main_Page opsview http://www.opsview.org/ osimius http://www.osmius.net/en/ PandoraFMS http://pandorafms.org/ Zabbix http://www.zabbix.com/ Groundwork http://www.groundworkopensource.com/ Nagios http://www.nagios.org Zenoss http://zenoss.com OpManager http://www.manageengine.com Orion http://www.solarwinds.com/products/orion/ BigBrother http://bb4.com/ Any others that should be added to the list to eval? ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 From trelane at trelane.net Tue Jul 21 12:12:08 2009 From: trelane at trelane.net (Andrew D Kirch) Date: Tue, 21 Jul 2009 13:12:08 -0400 Subject: Opensource or Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D12212801D@PUR-EXCH07.ox.com> References: <1248055745.24895.29.camel@petrie><1248101926.24895.33.camel@petrie> <20090721023059.GA3554@skywalker.creative.net.au> <54B7F7DBCA12D94CA3FE17B68F1461A706671446@LVNJEVS205.UCCORG.org> <483E6B0272B0284BA86D7596C40D29F9D12212801D@PUR-EXCH07.ox.com> Message-ID: <4A65F6E8.8060705@trelane.net> Argus http://argus.tcp4me.com Andrew Matthew Huff wrote: > I'm putting together a list of NMS systems for system (hardware, cpu util%, memory util%) and application monitoring rather than network management for our environment. We are looking for low cost / opensource solutions that have agents and/or reliable agentless monitoring for windows, linux and solaris hosts. I've put together a preliminary list, but was hoping that if someone has a solution they are happy with they would forward the info to me. Once I get the complete list, I'll re-post what I've found. > > The list I have so far is: > > > Hyperic http://www.hyperic.com/ > OpenNMS http://www.opennms.org/wiki/Main_Page > opsview http://www.opsview.org/ > osimius http://www.osmius.net/en/ > PandoraFMS http://pandorafms.org/ > Zabbix http://www.zabbix.com/ > Groundwork http://www.groundworkopensource.com/ > Nagios http://www.nagios.org > Zenoss http://zenoss.com > OpManager http://www.manageengine.com > Orion http://www.solarwinds.com/products/orion/ > BigBrother http://bb4.com/ > > Any others that should be added to the list to eval? > > > ---- > Matthew Huff | One Manhattanville Rd > OTA Management LLC | Purchase, NY 10577 > http://www.ox.com | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > > From jg at slash128.com Tue Jul 21 12:58:24 2009 From: jg at slash128.com (Jason Granat) Date: Tue, 21 Jul 2009 10:58:24 -0700 Subject: Opensource or Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D12212801D@PUR-EXCH07.ox.com> References: <1248055745.24895.29.camel@petrie><1248101926.24895.33.camel@petrie> <20090721023059.GA3554@skywalker.creative.net.au> <54B7F7DBCA12D94CA3FE17B68F1461A706671446@LVNJEVS205.UCCORG.org> <483E6B0272B0284BA86D7596C40D29F9D12212801D@PUR-EXCH07.ox.com> Message-ID: Spiceworks? http://www.spiceworks.com/ Sent while mobile On Jul 21, 2009, at 10:06, Matthew Huff wrote: > I'm putting together a list of NMS systems for system (hardware, cpu > util%, memory util%) and application monitoring rather than network > management for our environment. We are looking for low cost / > opensource solutions that have agents and/or reliable agentless > monitoring for windows, linux and solaris hosts. I've put together a > preliminary list, but was hoping that if someone has a solution they > are happy with they would forward the info to me. Once I get the > complete list, I'll re-post what I've found. > > The list I have so far is: > > > Hyperic http://www.hyperic.com/ > OpenNMS http://www.opennms.org/wiki/Main_Page > opsview http://www.opsview.org/ > osimius http://www.osmius.net/en/ > PandoraFMS http://pandorafms.org/ > Zabbix http://www.zabbix.com/ > Groundwork http://www.groundworkopensource.com/ > Nagios http://www.nagios.org > Zenoss http://zenoss.com > OpManager http://www.manageengine.com > Orion http://www.solarwinds.com/products/orion/ > BigBrother http://bb4.com/ > > Any others that should be added to the list to eval? > > > ---- > Matthew Huff | One Manhattanville Rd > OTA Management LLC | Purchase, NY 10577 > http://www.ox.com | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > http://slash128.com From beckman at angryox.com Tue Jul 21 13:29:55 2009 From: beckman at angryox.com (Peter Beckman) Date: Tue, 21 Jul 2009 14:29:55 -0400 Subject: Opensource or Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: References: <1248055745.24895.29.camel@petrie><1248101926.24895.33.camel@petrie> <20090721023059.GA3554@skywalker.creative.net.au> <54B7F7DBCA12D94CA3FE17B68F1461A706671446@LVNJEVS205.UCCORG.org> <483E6B0272B0284BA86D7596C40D29F9D12212801D@PUR-EXCH07.ox.com> Message-ID: Munin http://munin.projects.linpro.no/ Example: http://munin.ping.uio.no/ping.uio.no/dahl.ping.uio.no.html On Tue, 21 Jul 2009, Jason Granat wrote: > Spiceworks? > > http://www.spiceworks.com/ > > > Sent while mobile > > On Jul 21, 2009, at 10:06, Matthew Huff wrote: > >> I'm putting together a list of NMS systems for system (hardware, cpu >> util%, memory util%) and application monitoring rather than network >> management for our environment. We are looking for low cost / >> opensource solutions that have agents and/or reliable agentless >> monitoring for windows, linux and solaris hosts. I've put together a >> preliminary list, but was hoping that if someone has a solution they >> are happy with they would forward the info to me. Once I get the >> complete list, I'll re-post what I've found. >> >> The list I have so far is: >> >> >> Hyperic http://www.hyperic.com/ >> OpenNMS http://www.opennms.org/wiki/Main_Page >> opsview http://www.opsview.org/ >> osimius http://www.osmius.net/en/ >> PandoraFMS http://pandorafms.org/ >> Zabbix http://www.zabbix.com/ >> Groundwork http://www.groundworkopensource.com/ >> Nagios http://www.nagios.org >> Zenoss http://zenoss.com >> OpManager http://www.manageengine.com >> Orion http://www.solarwinds.com/products/orion/ >> BigBrother http://bb4.com/ >> >> Any others that should be added to the list to eval? >> >> >> ---- >> Matthew Huff | One Manhattanville Rd >> OTA Management LLC | Purchase, NY 10577 >> http://www.ox.com | Phone: 914-460-4039 >> aim: matthewbhuff | Fax: 914-460-4139 >> >> > > > > http://slash128.com > --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From if at xip.at Tue Jul 21 13:38:11 2009 From: if at xip.at (Ingo Flaschberger) Date: Tue, 21 Jul 2009 20:38:11 +0200 (CEST) Subject: Opensource or Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: References: <1248055745.24895.29.camel@petrie><1248101926.24895.33.camel@petrie> <20090721023059.GA3554@skywalker.creative.net.au> <54B7F7DBCA12D94CA3FE17B68F1461A706671446@LVNJEVS205.UCCORG.org> <483E6B0272B0284BA86D7596C40D29F9D12212801D@PUR-EXCH07.ox.com> Message-ID: > Munin > > http://munin.projects.linpro.no/ -> has a "api" to nagios and cacti: www.cacti.net (with add-on plugings, ie weathermap) cricket: http://cricket.sourceforge.net/ munin, cacti and cricket are more graphing than alerting (nagios) systems Kind regards, Ingo Flaschberger From drew.weaver at thenap.com Tue Jul 21 16:02:55 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Tue, 21 Jul 2009 17:02:55 -0400 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: References: <4A60ED8A.9000906@kingrst.com> <002501ca0924$7a210f20$6e632d60$@ORG> Message-ID: On Jul 20, 2009, at 5:26 PM, Neil J. McRae wrote: > GSR is far better platform. Concur 100%. --- I'm probably wrong, but aren't the 7600s 40Gbps per slot vs the GSR only being 10Gbps per slot? and doesn't that mean that there should (fairly soon) be a new version of the GSR coming that ups the slot width? -Drew From sthaug at nethelp.no Tue Jul 21 16:06:59 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 21 Jul 2009 23:06:59 +0200 (CEST) Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: References: <002501ca0924$7a210f20$6e632d60$@ORG> Message-ID: <20090721.230659.74749893.sthaug@nethelp.no> > > GSR is far better platform. > > Concur 100%. > --- > > I'm probably wrong, but aren't the 7600s 40Gbps per slot vs the GSR only being 10Gbps per slot? and doesn't that mean that there should (fairly soon) be a new version of the GSR coming that ups the slot width? It's called the CRS-1 :-) Steinar Haug, Nethelp consulting, sthaug at nethelp.no From dan at beanfield.com Tue Jul 21 16:14:25 2009 From: dan at beanfield.com (Dan Armstrong) Date: Tue, 21 Jul 2009 17:14:25 -0400 Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: <20090721.230659.74749893.sthaug@nethelp.no> References: <002501ca0924$7a210f20$6e632d60$@ORG> <20090721.230659.74749893.sthaug@nethelp.no> Message-ID: .. Or the new ASR-9000 maybe? On 21-Jul-09, at 5:06 PM, sthaug at nethelp.no wrote: >>> GSR is far better platform. >> >> Concur 100%. >> --- >> >> I'm probably wrong, but aren't the 7600s 40Gbps per slot vs the GSR >> only being 10Gbps per slot? and doesn't that mean that there should >> (fairly soon) be a new version of the GSR coming that ups the slot >> width? > > It's called the CRS-1 :-) > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > From swmike at swm.pp.se Tue Jul 21 16:21:42 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 21 Jul 2009 23:21:42 +0200 (CEST) Subject: Cisco 7600 (7609) as a core BGP router. In-Reply-To: References: <4A60ED8A.9000906@kingrst.com> <002501ca0924$7a210f20$6e632d60$@ORG> Message-ID: On Tue, 21 Jul 2009, Drew Weaver wrote: > I'm probably wrong, but aren't the 7600s 40Gbps per slot vs the GSR only > being 10Gbps per slot? and doesn't that mean that there should (fairly > soon) be a new version of the GSR coming that ups the slot width? The GSR is currently power and cooling constrained so it's not that easy to create new faster linecards, plus the fact that you need to invest in the 128xx fabric upgrade makes it not that much money efficient. Also expect any future linecards to be supported in XR only. -- Mikael Abrahamsson email: swmike at swm.pp.se From netfortius at gmail.com Tue Jul 21 23:34:12 2009 From: netfortius at gmail.com (Stefan) Date: Tue, 21 Jul 2009 23:34:12 -0500 Subject: Opensource or Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D12212801D@PUR-EXCH07.ox.com> References: <1248055745.24895.29.camel@petrie> <1248101926.24895.33.camel@petrie> <20090721023059.GA3554@skywalker.creative.net.au> <54B7F7DBCA12D94CA3FE17B68F1461A706671446@LVNJEVS205.UCCORG.org> <483E6B0272B0284BA86D7596C40D29F9D12212801D@PUR-EXCH07.ox.com> Message-ID: WebNM + Denika + Logalot - set of tools -- ***Stefan Mititelu http://twitter.com/netfortius http://www.linkedin.com/in/netfortius On Tue, Jul 21, 2009 at 12:06 PM, Matthew Huff wrote: > I'm putting together a list of NMS systems for system (hardware, cpu util%, > memory util%) and application monitoring rather than network management for > our environment. We are looking for low cost / opensource solutions that > have agents and/or reliable agentless monitoring for windows, linux and > solaris hosts. I've put together a preliminary list, but was hoping that if > someone has a solution they are happy with they would forward the info to > me. Once I get the complete list, I'll re-post what I've found. > > The list I have so far is: > > > Hyperic http://www.hyperic.com/ > OpenNMS http://www.opennms.org/wiki/Main_Page > opsview http://www.opsview.org/ > osimius http://www.osmius.net/en/ > PandoraFMS http://pandorafms.org/ > Zabbix http://www.zabbix.com/ > Groundwork http://www.groundworkopensource.com/ > Nagios http://www.nagios.org > Zenoss http://zenoss.com > OpManager http://www.manageengine.com > Orion http://www.solarwinds.com/products/orion/ > BigBrother http://bb4.com/ > > Any others that should be added to the list to eval? > > > ---- > Matthew Huff | One Manhattanville Rd > OTA Management LLC | Purchase, NY 10577 > http://www.ox.com | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > > From rdobbins at arbor.net Tue Jul 21 23:42:26 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 22 Jul 2009 11:42:26 +0700 Subject: Opensource or Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: References: <1248055745.24895.29.camel@petrie> <1248101926.24895.33.camel@petrie> <20090721023059.GA3554@skywalker.creative.net.au> <54B7F7DBCA12D94CA3FE17B68F1461A706671446@LVNJEVS205.UCCORG.org> <483E6B0272B0284BA86D7596C40D29F9D12212801D@PUR-EXCH07.ox.com> Message-ID: <0B48BA69-9044-453B-9776-BC6C5187630B@arbor.net> On Jul 22, 2009, at 11:34 AM, Stefan wrote: > WebNM + Denika + Logalot - set of > tools nfdump/nfsen, Stager, RANCID, RCS, CVS, or Subversion - these should all be included in any list of useful open-source tools for network operators, IMHO. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From chaim.rieger at gmail.com Tue Jul 21 23:44:30 2009 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Wed, 22 Jul 2009 04:44:30 +0000 Subject: Opensource or Low Cost NMS for Server Hardware / ApplicationMonitoring Message-ID: <274733387-1248237896-cardhu_decombobulator_blackberry.rim.net-368017360-@bxe1263.bisx.prod.on.blackberry> In that case might as well include Carp, vrrp, fping as well ------Original Message------ From: Roland Dobbins To: NANOG list Subject: Re: Opensource or Low Cost NMS for Server Hardware / ApplicationMonitoring Sent: Jul 21, 2009 21:42 On Jul 22, 2009, at 11:34 AM, Stefan wrote: > WebNM + Denika + Logalot - set of > tools nfdump/nfsen, Stager, RANCID, RCS, CVS, or Subversion - these should all be included in any list of useful open-source tools for network operators, IMHO. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton Sent via BlackBerry from T-Mobile From graeme at graemef.net Wed Jul 22 08:05:50 2009 From: graeme at graemef.net (Graeme Fowler) Date: Wed, 22 Jul 2009 14:05:50 +0100 Subject: Are you an "unpaid volunteer"? Message-ID: <1248267950.28824.18.camel@squonk.lboro.ac.uk> http://news.bbc.co.uk/1/hi/business/8163190.stm Some of it is right. Some of it is wrong. All of it makes for interesting reading from the point of view of a layperson. We are all, apparently, unsung heroes... Graeme PS Yes, there's plenty to tear apart in the article. Don't shoot the messenger though! From warren at kumari.net Wed Jul 22 08:06:56 2009 From: warren at kumari.net (Warren Kumari) Date: Wed, 22 Jul 2009 09:06:56 -0400 Subject: Opensource or Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: <0B48BA69-9044-453B-9776-BC6C5187630B@arbor.net> References: <1248055745.24895.29.camel@petrie> <1248101926.24895.33.camel@petrie> <20090721023059.GA3554@skywalker.creative.net.au> <54B7F7DBCA12D94CA3FE17B68F1461A706671446@LVNJEVS205.UCCORG.org> <483E6B0272B0284BA86D7596C40D29F9D12212801D@PUR-EXCH07.ox.com> <0B48BA69-9044-453B-9776-BC6C5187630B@arbor.net> Message-ID: For networking stuff, see Joe Abley and Stephen Stuart's NANOG 26 Tutorial "Managing IP Networks with Free Software" -- http://www.nanog.org/meetings/nanog26/abstracts.php?pt=Nzg1Jm5hbm9nMjY=&nm=nanog26 Direct link to PDF: http://www.nanog.org/meetings/nanog26/presentations/stephen.pdf -- it's from 2002 and so a little out of date, but still a great read. As for server / application / random other stuff (like printers and ups's and IP camera and the like), Zenoss is great -- its clean, simple, fast(ish), easy and pretty -- the last one happens to be important for some folks (esp in the enterprise world...) W On Jul 22, 2009, at 12:42 AM, Roland Dobbins wrote: > > On Jul 22, 2009, at 11:34 AM, Stefan wrote: > >> WebNM + Denika + Logalot - set of >> tools > > nfdump/nfsen, Stager, RANCID, RCS, CVS, or Subversion - these should > all be included in any list of useful open-source tools for network > operators, IMHO. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Unfortunately, inefficiency scales really well. > > -- Kevin Lawton > > From rbk at mnsginc.com Wed Jul 22 08:39:25 2009 From: rbk at mnsginc.com (R. Benjamin Kessler) Date: Wed, 22 Jul 2009 09:39:25 -0400 Subject: What Platform for a small ISP (was: Cisco 7600 (7609) as a core BGP router) In-Reply-To: <8B600A25A8CA034584549B57761B4AF408FBD3D8@mnsg-svr2.mnsg.net> References: <432127307-1247893988-cardhu_decombobulator_blackberry.rim.net-597624902-@bxe1156.bisx.prod.on.blackberry><20090718073733.GA26689@mx.ytti.net><4D771172-1100-4FAB-B13D-97778F164347@arbor.net><5a318d410907180305x4b924f1aoc883b2259c841878@mail.gmail.com> <20090718190002.GZ51443@gerbil.cluepon.net> <8B600A25A8CA034584549B57761B4AF408FBD3D8@mnsg-svr2.mnsg.net> Message-ID: <0B608FCDCF43BF4C9194C896C53202435D8BD3@mnsg-svr2.mnsg.net> There has been a lot of good feedback regarding the deficiencies of the 7600 platform... So, the new question is: what platforms should a small, start-up ISP consider when looking to provide Ethernet services to their customers? - Scalability - 100M, 1G, 10G access speeds (backplane limitations, number of ports per chassis, etc.) - MPLS Capabilities - QoS Features - Ease of configuration and support, etc. (finding NOC talent, scripting tools, etc.) - Software/Hardware "stability" and "longevity" (we don't want something that is brand-new and therefore "buggy" nor do we want something that is going EOL next year) - Bang for the buck (both acquisition and on-going maintenance and support) I'm sure I'm missing a lot of things...are there any good presentations from previous NANOG meetings that one should review? Thanks in advance, Ben From jbates at brightok.net Wed Jul 22 08:45:52 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 22 Jul 2009 08:45:52 -0500 Subject: Opensource or Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: References: <1248055745.24895.29.camel@petrie> <1248101926.24895.33.camel@petrie> <20090721023059.GA3554@skywalker.creative.net.au> <54B7F7DBCA12D94CA3FE17B68F1461A706671446@LVNJEVS205.UCCORG.org> <483E6B0272B0284BA86D7596C40D29F9D12212801D@PUR-EXCH07.ox.com> <0B48BA69-9044-453B-9776-BC6C5187630B@arbor.net> Message-ID: <4A671810.9050807@brightok.net> Warren Kumari wrote: > As for server / application / random other stuff (like printers and > ups's and IP camera and the like), Zenoss is great -- its clean, simple, > fast(ish), easy and pretty -- the last one happens to be important for > some folks (esp in the enterprise world...) > Just expect it to be run on linux; perhaps bsd. The last time I played with it, there were too many issues with getting it to run on Solaris 10 to bother. Don't get me wrong. When I installed nagios 3.1.2 yesterday, I had to make it understand that -lsocket was needed and copy snprintf.o from ./base to ./common where it was supposed to be compiled. Zenoss just wasn't an easy tweak. It's been awhile, but I suspect their install.sh was very linux centric and would have required a rewrite. Jack From jwininger at indianafiber.net Wed Jul 22 08:48:04 2009 From: jwininger at indianafiber.net (Jim Wininger) Date: Wed, 22 Jul 2009 09:48:04 -0400 Subject: What Platform for a small ISP (was: Cisco 7600 (7609) as a core BGP router) In-Reply-To: <0B608FCDCF43BF4C9194C896C53202435D8BD3@mnsg-svr2.mnsg.net> Message-ID: What do you consider a "small start-up ISP"? What kind of upstream connectivity are you considering (or at least falls under the category of small isp) bandwidht, bgp etc? On 7/22/09 9:39 AM, "R. Benjamin Kessler" wrote: > There has been a lot of good feedback regarding the deficiencies of the > 7600 platform... > > So, the new question is: what platforms should a small, start-up ISP > consider when looking to provide Ethernet services to their customers? > > - Scalability - 100M, 1G, 10G access speeds (backplane limitations, > number of ports per chassis, etc.) > - MPLS Capabilities > - QoS Features > - Ease of configuration and support, etc. (finding NOC talent, scripting > tools, etc.) > - Software/Hardware "stability" and "longevity" (we don't want something > that is brand-new and therefore "buggy" nor do we want something that is > going EOL next year) > - Bang for the buck (both acquisition and on-going maintenance and > support) > > I'm sure I'm missing a lot of things...are there any good presentations > from previous NANOG meetings that one should review? > > Thanks in advance, > > Ben > -- Jim Wininger Indiana Fiber Network Desk - 317-777-7114 Cell - 317-432-7609 Office - 317-280-4636 CONFIDENTIALITY NOTICE: The information contained in this electronic mail transmission (including any attachment) is intended for the exclusive use of the named recipient and may contain information that is privileged or otherwise confidential. It is not intended for transmission to, or receipt by, anyone other than the named recipient (or person authorized to deliver it to the named recipient). It should not be copied or forwarded to any unauthorized person. If you have received this electronic mail transmission in error, please delete it from your system including any attachment without copying or forwarding it, and notify the sender of the error by return e-mail. From linux.yahoo at gmail.com Wed Jul 22 09:29:24 2009 From: linux.yahoo at gmail.com (Manu Chao) Date: Wed, 22 Jul 2009 16:29:24 +0200 Subject: What Platform for a small ISP (was: Cisco 7600 (7609) as a core BGP router) In-Reply-To: References: <0B608FCDCF43BF4C9194C896C53202435D8BD3@mnsg-svr2.mnsg.net> Message-ID: <7100ed370907220729h50e3f524k751bcf13bd0d9f5f@mail.gmail.com> Juniper M10i versus Cisco ASR 1000 On Wed, Jul 22, 2009 at 3:48 PM, Jim Wininger wrote: > What do you consider a "small start-up ISP"? What kind of upstream > connectivity are you considering (or at least falls under the category of > small isp) bandwidht, bgp etc? > > > On 7/22/09 9:39 AM, "R. Benjamin Kessler" wrote: > > > There has been a lot of good feedback regarding the deficiencies of the > > 7600 platform... > > > > So, the new question is: what platforms should a small, start-up ISP > > consider when looking to provide Ethernet services to their customers? > > > > - Scalability - 100M, 1G, 10G access speeds (backplane limitations, > > number of ports per chassis, etc.) > > - MPLS Capabilities > > - QoS Features > > - Ease of configuration and support, etc. (finding NOC talent, scripting > > tools, etc.) > > - Software/Hardware "stability" and "longevity" (we don't want something > > that is brand-new and therefore "buggy" nor do we want something that is > > going EOL next year) > > - Bang for the buck (both acquisition and on-going maintenance and > > support) > > > > I'm sure I'm missing a lot of things...are there any good presentations > > from previous NANOG meetings that one should review? > > > > Thanks in advance, > > > > Ben > > > > -- > Jim Wininger > Indiana Fiber Network > Desk - 317-777-7114 > Cell - 317-432-7609 > Office - 317-280-4636 > > CONFIDENTIALITY NOTICE: The information contained in this electronic mail > transmission (including any attachment) is intended for the exclusive use > of > the named recipient and may contain information that is privileged or > otherwise confidential. It is not intended for transmission to, or receipt > by, anyone other than the named recipient (or person authorized to deliver > it to the named recipient). It should not be copied or forwarded to any > unauthorized person. If you have received this electronic mail transmission > in error, please delete it from your system including any attachment > without > copying or forwarding it, and notify the sender of the error by return > e-mail. > > > From ras at e-gerbil.net Wed Jul 22 09:31:36 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 22 Jul 2009 09:31:36 -0500 Subject: What Platform for a small ISP (was: Cisco 7600 (7609) as a core BGP router) In-Reply-To: <0B608FCDCF43BF4C9194C896C53202435D8BD3@mnsg-svr2.mnsg.net> References: <20090718190002.GZ51443@gerbil.cluepon.net> <8B600A25A8CA034584549B57761B4AF408FBD3D8@mnsg-svr2.mnsg.net> <0B608FCDCF43BF4C9194C896C53202435D8BD3@mnsg-svr2.mnsg.net> Message-ID: <20090722143136.GU51443@gerbil.cluepon.net> On Wed, Jul 22, 2009 at 09:39:25AM -0400, R. Benjamin Kessler wrote: > There has been a lot of good feedback regarding the deficiencies of the > 7600 platform... > > So, the new question is: what platforms should a small, start-up ISP > consider when looking to provide Ethernet services to their customers? > > - Scalability - 100M, 1G, 10G access speeds (backplane limitations, > number of ports per chassis, etc.) > - MPLS Capabilities > - QoS Features > - Ease of configuration and support, etc. (finding NOC talent, scripting > tools, etc.) > - Software/Hardware "stability" and "longevity" (we don't want something > that is brand-new and therefore "buggy" nor do we want something that is > going EOL next year) > - Bang for the buck (both acquisition and on-going maintenance and > support) People use the 6500/7600 platform because it is dirt cheap, it mostly works especially if you aren't doing anything too interesting or complex with it (and if you have to ask, you probably aren't), and there is an unlimited supply of "talent" (if you can call it that) who understands basic IOS. If you're really a small ISP looking for a safe bet, this is a fine choice. It's also available in quantity and for cheap on the used market, which is probably where you want to go as a small ISP. If on the other hand you're looking for a "good" platform and money is no object, the Juniper MX is the unquestioned leader in this space. Unfortunately it costs quite a bit more than a 6500/7600 (around 4x-10x more depending on how good a deal you get on one, and how bad a deal you get on the other), but you do get what you pay for. :) The other players in this space are the Foundry MLX/XMR and Force10. Each has their advantages and disadvantages compared to Cisco, and may be more appropriate for some people under some circumstances, but at the end of the day they are both terribly flawed products too just in different ways. Cisco still comes out with the significant price advantage though, especially on the used market, which means for "most" people who have to ask this type of question the 6500/7600 is the way to go. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From rbk at mnsginc.com Wed Jul 22 09:57:27 2009 From: rbk at mnsginc.com (R. Benjamin Kessler) Date: Wed, 22 Jul 2009 10:57:27 -0400 Subject: What Platform for a small ISP (was: Cisco 7600 (7609) as a core BGP router) In-Reply-To: References: <0B608FCDCF43BF4C9194C896C53202435D8BD3@mnsg-svr2.mnsg.net> Message-ID: <0B608FCDCF43BF4C9194C896C53202435D8BDD@mnsg-svr2.mnsg.net> On 7/22/09 9:48 AM, Jim Wininger wrote: > What do you consider a "small start-up ISP"? What kind of upstream > connectivity are you considering (or at least falls under the category of > small isp) bandwidht, bgp etc? two or three upstreams - OC-12 to 1G to each (BGP full tables) three "POPs" meshed together >> On 7/22/09 9:39 AM, "R. Benjamin Kessler" wrote: >> There has been a lot of good feedback regarding the deficiencies of the >> 7600 platform... >> >> So, the new question is: what platforms should a small, start-up ISP >> consider when looking to provide Ethernet services to their customers? >> >> - Scalability - 100M, 1G, 10G access speeds (backplane limitations, >> number of ports per chassis, etc.) >> - MPLS Capabilities >> - QoS Features >> - Ease of configuration and support, etc. (finding NOC talent, scripting >> tools, etc.) >> - Software/Hardware "stability" and "longevity" (we don't want something >> that is brand-new and therefore "buggy" nor do we want something that is >> going EOL next year) >> - Bang for the buck (both acquisition and on-going maintenance and >> support) >> >> I'm sure I'm missing a lot of things...are there any good presentations >> from previous NANOG meetings that one should review? >> >> Thanks in advance, >> >> Ben >> From ge at linuxbox.org Wed Jul 22 10:17:31 2009 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 22 Jul 2009 18:17:31 +0300 Subject: Are you an "unpaid volunteer"? In-Reply-To: <1248267950.28824.18.camel@squonk.lboro.ac.uk> References: <1248267950.28824.18.camel@squonk.lboro.ac.uk> Message-ID: <4A672D8B.8040601@linuxbox.org> Graeme Fowler wrote: > http://news.bbc.co.uk/1/hi/business/8163190.stm > > Some of it is right. Some of it is wrong. All of it makes for > interesting reading from the point of view of a layperson. > > We are all, apparently, unsung heroes... > > Graeme > > PS Yes, there's plenty to tear apart in the article. Don't shoot the > messenger though! And it wasn't really NANOG that did or does much of what he describes, but NANOG is a "good enough" representative name for the community of people who do, when we our definition to network operations. Gadi. > > -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From eric at roxanne.org Wed Jul 22 11:45:42 2009 From: eric at roxanne.org (Eric Gauthier) Date: Wed, 22 Jul 2009 12:45:42 -0400 Subject: Opensource or Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: References: <1248101926.24895.33.camel@petrie> <20090721023059.GA3554@skywalker.creative.net.au> <54B7F7DBCA12D94CA3FE17B68F1461A706671446@LVNJEVS205.UCCORG.org> <483E6B0272B0284BA86D7596C40D29F9D12212801D@PUR-EXCH07.ox.com> <0B48BA69-9044-453B-9776-BC6C5187630B@arbor.net> Message-ID: <20090722164542.GA25063@roxanne.org> Hello, > As for server / application / random other stuff (like printers and > ups's and IP camera and the like), Zenoss is great -- its clean, > simple, fast(ish), easy and pretty -- the last one happens to be > important for some folks (esp in the enterprise world...) We've looked at ZenOSS but couldn't get it to model the network. >From what we can tell, it couldn't handle the full routing table on our core routers (there are six). If someone has successfully done this, can you contact me off list? Eric :) From wclayton at corenap.com Wed Jul 22 11:58:12 2009 From: wclayton at corenap.com (Will Clayton) Date: Wed, 22 Jul 2009 11:58:12 -0500 Subject: Opensource or Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: <20090722164542.GA25063@roxanne.org> References: <1248101926.24895.33.camel@petrie> <20090721023059.GA3554@skywalker.creative.net.au> <54B7F7DBCA12D94CA3FE17B68F1461A706671446@LVNJEVS205.UCCORG.org> <483E6B0272B0284BA86D7596C40D29F9D12212801D@PUR-EXCH07.ox.com> <0B48BA69-9044-453B-9776-BC6C5187630B@arbor.net> <20090722164542.GA25063@roxanne.org> Message-ID: <4A674524.40200@corenap.com> Eric Gauthier wrote: > Hello, > > >> As for server / application / random other stuff (like printers and >> ups's and IP camera and the like), Zenoss is great -- its clean, >> simple, fast(ish), easy and pretty -- the last one happens to be >> important for some folks (esp in the enterprise world...) >> > > We've looked at ZenOSS but couldn't get it to model the network. > >From what we can tell, it couldn't handle the full routing table > on our core routers (there are six). If someone has successfully > done this, can you contact me off list? > > Eric :) I like NMIS. Fast, scalable, flexible and really hackable. It doesn't take much time to get it up and running but selling others on it can be challenging. It works off of flat tab delimited text files making populating the node base pretty easy. There are plans for NMIS5 to use database connectivity for this which will be even more fun. There are external contributions that do everything from RANCID to Flash maps of your network. The home page is here: http://sins.com.au/nmis/ But has since moved to sourceforge: http://sourceforge.net/projects/nmis/files/ With the gang being here: http://tech.groups.yahoo.com/group/nmis_users/ While not for everyone and not as popular or pretty as some of the others, it is a network monitoring system built by engineers for engineers. With a combination of SNMP data collection and ping/service tests, bandwidth utilization alerts, alert groups, thresholds etc. can be adjusted on a per-device basis and just a week of utilization can really help you identify points on the network that need to be cleaned up. I guess my favorite part is the ability to write device interface descriptions to trigger actions in the Perl script since that data is collected via SNMP. -- Will Clayton From mhuff at ox.com Wed Jul 22 12:21:54 2009 From: mhuff at ox.com (Matthew Huff) Date: Wed, 22 Jul 2009 13:21:54 -0400 Subject: Opensource or Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: <4A674524.40200@corenap.com> References: <1248101926.24895.33.camel@petrie> <20090721023059.GA3554@skywalker.creative.net.au> <54B7F7DBCA12D94CA3FE17B68F1461A706671446@LVNJEVS205.UCCORG.org> <483E6B0272B0284BA86D7596C40D29F9D12212801D@PUR-EXCH07.ox.com> <0B48BA69-9044-453B-9776-BC6C5187630B@arbor.net> <20090722164542.GA25063@roxanne.org> <4A674524.40200@corenap.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F9D12212805B@PUR-EXCH07.ox.com> I think all of these comments are useful. but we are looking for NMS for server/application monitoring, not snmp/dmi based polling. We will need a system that runs custom scripts to monitor our servers (CPU, OS syslogs, Windows Event logs, hardware, memory, etc) and our in-house applications running on these servers (100+). Native agents for windows 2003, 2008, Linux and Solaris (both Sparc and x86) with custom scripting is a minimum requirements. There are a lot of good network router/switch solutions, but we are looking for some that are more focused on server based management. We used to use BMC patrol which was a very good system. We moved away from it because it was extremely pricey per-node and BMC absolute rejection of Solaris X86 as a supported platform (We went back and forth between Sun and BMC regarding that for over a year). ---- Matthew Huff?????? | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 > -----Original Message----- > From: Will Clayton [mailto:wclayton at corenap.com] > Sent: Wednesday, July 22, 2009 12:58 PM > To: nanog at nanog.org > Subject: Re: Opensource or Low Cost NMS for Server Hardware / > Application Monitoring > > Eric Gauthier wrote: > > Hello, > > > > > >> As for server / application / random other stuff (like printers and > >> ups's and IP camera and the like), Zenoss is great -- its clean, > >> simple, fast(ish), easy and pretty -- the last one happens to be > >> important for some folks (esp in the enterprise world...) > >> > > > > We've looked at ZenOSS but couldn't get it to model the network. > > >From what we can tell, it couldn't handle the full routing table > > on our core routers (there are six). If someone has successfully > > done this, can you contact me off list? > > > > Eric :) > > I like NMIS. Fast, scalable, flexible and really hackable. It doesn't > take much time to get it up and running but selling others on it can be > challenging. It works off of flat tab delimited text files making > populating the node base pretty easy. There are plans for NMIS5 to use > database connectivity for this which will be even more fun. There are > external contributions that do everything from RANCID to Flash maps of > your network. The home page is here: > > http://sins.com.au/nmis/ > > But has since moved to sourceforge: > > http://sourceforge.net/projects/nmis/files/ > > With the gang being here: > > http://tech.groups.yahoo.com/group/nmis_users/ > > While not for everyone and not as popular or pretty as some of the > others, it is a network monitoring system built by engineers for > engineers. With a combination of SNMP data collection and ping/service > tests, bandwidth utilization alerts, alert groups, thresholds etc. can > be adjusted on a per-device basis and just a week of utilization can > really help you identify points on the network that need to be cleaned > up. > > I guess my favorite part is the ability to write device interface > descriptions to trigger actions in the Perl script since that data is > collected via SNMP. > > -- > Will Clayton > -------------- next part -------------- A non-text attachment was scrubbed... Name: Matthew Huff.vcf Type: application/octet-stream Size: 1595 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4229 bytes Desc: not available URL: From lists at quux.de Wed Jul 22 12:24:27 2009 From: lists at quux.de (Jens Link) Date: Wed, 22 Jul 2009 19:24:27 +0200 Subject: Opensource or Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D12212801D@PUR-EXCH07.ox.com> (Matthew Huff's message of "Tue\, 21 Jul 2009 13\:06\:04 -0400") References: <1248055745.24895.29.camel@petrie> <1248101926.24895.33.camel@petrie> <20090721023059.GA3554@skywalker.creative.net.au> <54B7F7DBCA12D94CA3FE17B68F1461A706671446@LVNJEVS205.UCCORG.org> <483E6B0272B0284BA86D7596C40D29F9D12212801D@PUR-EXCH07.ox.com> Message-ID: <87my6wfx6c.fsf@laphroiag.quux.de> Matthew Huff writes: > Nagios http://www.nagios.org http://www.icinga.org/ - a (very current) fork of Nagios http://software.uninett.no/stager/ - another netflow tool http://nedi.ch - For those with larger campus networks http://nipper.titania.co.uk/ - audit tool for different network devices and syslog-ng, rsyslog, ... BTW: Why do you hijack a thread to start a new mail instead of actually writing a new mail? It's not a nice think to do. Ok, those people who think their group ware clients is a mail client will never notice, but there are still some people using real mail clients. :-( I don't think that my GNUS or my MTA added all the references to your mail. cheers Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | ------------------------------------------------------------------------- From mhuff at ox.com Wed Jul 22 12:38:32 2009 From: mhuff at ox.com (Matthew Huff) Date: Wed, 22 Jul 2009 13:38:32 -0400 Subject: Opensource or Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: <87my6wfx6c.fsf@laphroiag.quux.de> References: <1248055745.24895.29.camel@petrie> <1248101926.24895.33.camel@petrie> <20090721023059.GA3554@skywalker.creative.net.au> <54B7F7DBCA12D94CA3FE17B68F1461A706671446@LVNJEVS205.UCCORG.org> <483E6B0272B0284BA86D7596C40D29F9D12212801D@PUR-EXCH07.ox.com> <87my6wfx6c.fsf@laphroiag.quux.de> Message-ID: <483E6B0272B0284BA86D7596C40D29F9D12212805F@PUR-EXCH07.ox.com> Just an FYI, I didn't hijack this thread, I'm the one that started it. If you look at the Subject line it says NMS for Server hardware / Application monitoring not for router/switch monitoring. Regardless, the suggestions and info is good for everyone, I just wanted to push a bit back towards the original topic. ---- Matthew Huff?????? | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 > -----Original Message----- > From: Jens Link [mailto:lists at quux.de] > Sent: Wednesday, July 22, 2009 1:24 PM > To: 'nanog at nanog.org' > Subject: Re: Opensource or Low Cost NMS for Server Hardware / > Application Monitoring > > Matthew Huff writes: > > > Nagios http://www.nagios.org > > http://www.icinga.org/ - a (very current) fork of Nagios > > http://software.uninett.no/stager/ - another netflow tool > > http://nedi.ch - For those with larger campus networks > > http://nipper.titania.co.uk/ - audit tool for different network devices > > and syslog-ng, rsyslog, ... > > BTW: Why do you hijack a thread to start a new mail instead of actually > writing a new mail? It's not a nice think to do. Ok, those people who > think their group ware clients is a mail client will never notice, but > there are still some people using real mail clients. :-( I don't think > that my GNUS or my MTA added all the references to your mail. > > cheers > > Jens > -- > ----------------------------------------------------------------------- > -- > | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 > | > | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de > | > ----------------------------------------------------------------------- > -- -------------- next part -------------- A non-text attachment was scrubbed... Name: Matthew Huff.vcf Type: application/octet-stream Size: 1595 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4229 bytes Desc: not available URL: From sethm at rollernet.us Wed Jul 22 12:45:27 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 22 Jul 2009 10:45:27 -0700 Subject: Opensource or Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D12212805F@PUR-EXCH07.ox.com> References: <1248055745.24895.29.camel@petrie> <1248101926.24895.33.camel@petrie> <20090721023059.GA3554@skywalker.creative.net.au> <54B7F7DBCA12D94CA3FE17B68F1461A706671446@LVNJEVS205.UCCORG.org> <483E6B0272B0284BA86D7596C40D29F9D12212801D@PUR-EXCH07.ox.com> <87my6wfx6c.fsf@laphroiag.quux.de> <483E6B0272B0284BA86D7596C40D29F9D12212805F@PUR-EXCH07.ox.com> Message-ID: <4A675037.8010203@rollernet.us> Matthew Huff wrote: > Just an FYI, I didn't hijack this thread, I'm the one that started it. If > you look at the Subject line it says NMS for Server hardware / Application > monitoring not for router/switch monitoring. Regardless, the suggestions and > info is good for everyone, I just wanted to push a bit back towards the > original topic. > Yeah, you did. You can't just hit reply and change the subject. That doesn't kill the thread references. I'm seeing this whole thing under "What is good in modular routers these days?" when a new message arrives in threaded view. It's actually kind of obnoxious when someone combines threads. ~Seth From r.hyunseog at ieee.org Wed Jul 22 13:07:15 2009 From: r.hyunseog at ieee.org (Alex H. Ryu) Date: Wed, 22 Jul 2009 13:07:15 -0500 Subject: Opensource or Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D12212805B@PUR-EXCH07.ox.com> References: <1248101926.24895.33.camel@petrie> <20090721023059.GA3554@skywalker.creative.net.au> <54B7F7DBCA12D94CA3FE17B68F1461A706671446@LVNJEVS205.UCCORG.org> <483E6B0272B0284BA86D7596C40D29F9D12212801D@PUR-EXCH07.ox.com> <0B48BA69-9044-453B-9776-BC6C5187630B@arbor.net> <20090722164542.GA25063@roxanne.org> <4A674524.40200@corenap.com> <483E6B0272B0284BA86D7596C40D29F9D12212805B@PUR-EXCH07.ox.com> Message-ID: <4A675553.4090400@ieee.org> It really depends on your application server configuration. Most people just uses SNMP for this purpose. Something like net-snmp installed in servers, then monitor the info via SNMP MIB polling. Alex Matthew Huff wrote: > I think all of these comments are useful. but we are looking for NMS for > server/application monitoring, not snmp/dmi based polling. We will need a > system that runs custom scripts to monitor our servers (CPU, OS syslogs, > Windows Event logs, hardware, memory, etc) and our in-house applications > running on these servers (100+). Native agents for windows 2003, 2008, Linux > and Solaris (both Sparc and x86) with custom scripting is a minimum > requirements. There are a lot of good network router/switch solutions, but > we are looking for some that are more focused on server based management. We > used to use BMC patrol which was a very good system. We moved away from it > because it was extremely pricey per-node and BMC absolute rejection of > Solaris X86 as a supported platform (We went back and forth between Sun and > BMC regarding that for over a year). > > ---- > Matthew Huff??? | One Manhattanville Rd > OTA Management LLC | Purchase, NY 10577 > http://www.ox.com | Phone: 914-460-4039 > aim: matthewbhuff | Fax:? 914-460-4139 > > > > >> -----Original Message----- >> From: Will Clayton [mailto:wclayton at corenap.com] >> Sent: Wednesday, July 22, 2009 12:58 PM >> To: nanog at nanog.org >> Subject: Re: Opensource or Low Cost NMS for Server Hardware / >> Application Monitoring >> >> Eric Gauthier wrote: >> >>> Hello, >>> >>> >>> >>>> As for server / application / random other stuff (like printers and >>>> ups's and IP camera and the like), Zenoss is great -- its clean, >>>> simple, fast(ish), easy and pretty -- the last one happens to be >>>> important for some folks (esp in the enterprise world...) >>>> >>>> >>> We've looked at ZenOSS but couldn't get it to model the network. >>> >From what we can tell, it couldn't handle the full routing table >>> on our core routers (there are six). If someone has successfully >>> done this, can you contact me off list? >>> >>> Eric :) >>> >> I like NMIS. Fast, scalable, flexible and really hackable. It doesn't >> take much time to get it up and running but selling others on it can be >> challenging. It works off of flat tab delimited text files making >> populating the node base pretty easy. There are plans for NMIS5 to use >> database connectivity for this which will be even more fun. There are >> external contributions that do everything from RANCID to Flash maps of >> your network. The home page is here: >> >> http://sins.com.au/nmis/ >> >> But has since moved to sourceforge: >> >> http://sourceforge.net/projects/nmis/files/ >> >> With the gang being here: >> >> http://tech.groups.yahoo.com/group/nmis_users/ >> >> While not for everyone and not as popular or pretty as some of the >> others, it is a network monitoring system built by engineers for >> engineers. With a combination of SNMP data collection and ping/service >> tests, bandwidth utilization alerts, alert groups, thresholds etc. can >> be adjusted on a per-device basis and just a week of utilization can >> really help you identify points on the network that need to be cleaned >> up. >> >> I guess my favorite part is the ability to write device interface >> descriptions to trigger actions in the Perl script since that data is >> collected via SNMP. >> >> -- >> Will Clayton >> >> > > From mhuff at ox.com Wed Jul 22 13:08:29 2009 From: mhuff at ox.com (Matthew Huff) Date: Wed, 22 Jul 2009 14:08:29 -0400 Subject: Open Source / Low Cost NMS for Server Hardware / Application Monitoring Message-ID: <483E6B0272B0284BA86D7596C40D29F9D122128063@PUR-EXCH07.ox.com> I apologize for not starting a new thread before, I didn't realize that the nanog mailing list created a thread-index rather than using the subject. Even though NANOG is primarily for network operators, I know that a number of members work in NOCs where there is also monitoring of servers/applications. I would appreciate it if anyone has suggestions about monitoring systems that would be applicable to our environment. We have a large number of custom applications on a large number of hosts including Windows 2003/2008, Linux x86/x86_64 and Solaris Sparc/x86_64. We are looking for a better way of monitoring our environment. We are looking for recommendations for opensource or low-cost. We would prefer solutions where the basic monitoring is ready out of the box. Native agents with custom scripting would be highly desired (rather than SNMP/DMI/WMI polling). Some of our requirements: . Native agents for Windows 2003/2008, Linux, Linux x86_64, Solaris Sparc and Solaris x86_64. Either binaries or source code. . Ability to send alerts via email, pager and/or snmp . Monitoring of OS properties like memory, disk, cpu, etc... . Ability to extend agents with scripting to allow monitoring of custom services . Plug-in architecture for third-party add-ons . Reliable Architecture . Reasonable user interface . Non-blocking polling . Active Project (New Releases on regular basis and have existed for a reasonable period) Based on our research and feedback from NANOG, we have put a preliminary list of product to evaluate: Hyperic http://www.hyperic.com/ OpenNMS http://www.opennms.org/wiki/Main_Page opsview http://www.opsview.org/ osimius http://www.osmius.net/en/ PandoraFMS http://pandorafms.org/ Zabbix http://www.zabbix.com/ Groundwork http://www.groundworkopensource.com/ Nagios http://www.nagios.org Zenoss http://zenoss.com OpManager http://www.manageengine.com Orion http://www.solarwinds.com/products/orion/ BigBrother http://bb4.com/ Argus http://argus.tcp4me.com/ Xymon http://www.xymon.com Spiceworks http://www.spiceworks.com/ ICINGA http://www.icinga.org ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 From darcy at druid.net Wed Jul 22 13:31:44 2009 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Wed, 22 Jul 2009 14:31:44 -0400 Subject: Open Source / Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D122128063@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F9D122128063@PUR-EXCH07.ox.com> Message-ID: <20090722143144.028a1584.darcy@druid.net> On Wed, 22 Jul 2009 14:08:29 -0400 Matthew Huff wrote: > I apologize for not starting a new thread before, I didn't realize that the nanog mailing list created a thread-index rather than using the subject. It's not the nanog mailing list, it's your own email client (and ours) that keeps the threads intact. The mailing list simply forwards the headers you send it. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From jbates at brightok.net Wed Jul 22 13:40:21 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 22 Jul 2009 13:40:21 -0500 Subject: Open Source / Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D122128063@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F9D122128063@PUR-EXCH07.ox.com> Message-ID: <4A675D15.7000102@brightok.net> Matthew Huff wrote: > Some of our requirements: > > . Native agents for Windows 2003/2008, Linux, Linux x86_64, Solaris Sparc and Solaris x86_64. Either binaries or source code. > . Ability to send alerts via email, pager and/or snmp > . Monitoring of OS properties like memory, disk, cpu, etc... > . Ability to extend agents with scripting to allow monitoring of custom services > . Plug-in architecture for third-party add-ons > . Reliable Architecture > . Reasonable user interface > . Non-blocking polling > . Active Project (New Releases on regular basis and have existed for a reasonable period) You probably have the list of the most commonly used. Each has good and bad points. A few of them I believe are limited on using agents and supporting external scripts. Several are considered Nagios on steroids, using a Nagios core wrappered in a bunch of other OSS. Several, like Zenoss are particular about the primarily monitoring system (though agents might run on any OS). Jack From dstorandt at teljet.com Wed Jul 22 13:43:08 2009 From: dstorandt at teljet.com (David Storandt) Date: Wed, 22 Jul 2009 14:43:08 -0400 Subject: What Platform for a small ISP (was: Cisco 7600 (7609) as a core BGP router) In-Reply-To: <0B608FCDCF43BF4C9194C896C53202435D8BDD@mnsg-svr2.mnsg.net> References: <0B608FCDCF43BF4C9194C896C53202435D8BD3@mnsg-svr2.mnsg.net> <0B608FCDCF43BF4C9194C896C53202435D8BDD@mnsg-svr2.mnsg.net> Message-ID: Why are you a "small start-up" and needing 600M-1G of pipe, and from 3x carriers? You can't use 150-200M via GigE ports and scale as needed (assuming you aren't bound to a SONET loop)? We started our IP backbone in 2005 with 3x 300M connections on 6509/maxed-Sup2s with 85% BGP tables and 6516-GBIC blades. All of our drops were GBE or 10/100, no SONET, no fancy stuff. 3x nodes meshed. Redundancy was our only mandatory requirement. Everything worked well, until we started getting more sophisticated. This setup now could run $5-6k/node if you shop around. Since then, prices have dropped on more powerful stuff and persistent EOL progression, so if you can pull off funds for Sup720-3BXL engines, you've got options for 10G, IP6, MPLS, and full tables from day one, although 10G ports are not cheap (for a shoestring one, at least). I would consider Sup720-3Bs as a minimum for that platform, considering EOL and features. -D On Wed, Jul 22, 2009 at 10:57 AM, R. Benjamin Kessler wrote: > On 7/22/09 9:48 AM, Jim Wininger wrote: > >> What do you consider a "small start-up ISP"? What kind of upstream >> connectivity are you considering (or at least falls under the category > of >> small isp) bandwidht, bgp etc? > > two or three upstreams - OC-12 to 1G to each (BGP full tables) > three "POPs" meshed together > >>> On 7/22/09 9:39 AM, "R. Benjamin Kessler" wrote: > >>> There has been a lot of good feedback regarding the deficiencies of > the >>> 7600 platform... >>> >>> So, the new question is: what platforms should a small, start-up ISP >>> consider when looking to provide Ethernet services to their > customers? >>> >>> - Scalability - 100M, 1G, 10G access speeds (backplane limitations, >>> number of ports per chassis, etc.) >>> - MPLS Capabilities >>> - QoS Features >>> - Ease of configuration and support, etc. (finding NOC talent, > scripting >>> tools, etc.) >>> - Software/Hardware "stability" and "longevity" (we don't want > something >>> that is brand-new and therefore "buggy" nor do we want something that > is >>> going EOL next year) >>> - Bang for the buck (both acquisition and on-going maintenance and >>> support) >>> >>> I'm sure I'm missing a lot of things...are there any good > presentations >>> from previous NANOG meetings that one should review? >>> >>> Thanks in advance, >>> >>> Ben >>> > > > From Ray.Sanders at VillageVoiceMedia.com Wed Jul 22 14:10:22 2009 From: Ray.Sanders at VillageVoiceMedia.com (Ray Sanders) Date: Wed, 22 Jul 2009 12:10:22 -0700 Subject: Open Source / Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: <4A675D15.7000102@brightok.net> References: <483E6B0272B0284BA86D7596C40D29F9D122128063@PUR-EXCH07.ox.com> <4A675D15.7000102@brightok.net> Message-ID: <1248289822.18828.75.camel@artoo.vvmedia.com> It's neither open source, nor free, but I moved from Nagios/Groundwork to Solarwinds ipMonitor 9. Solarwinds recently cut the price down to under $1000 for unlimited monitors. Up until about a year ago, the unlimited license ran about $5K. So for a large nationwide environment like ours, our ROI was pretty decent, but if you are only watching a dozen or two systems with maybe ten monitors each, Nagios would be the best bet. On Wed, 2009-07-22 at 13:40 -0500, Jack Bates wrote: > Matthew Huff wrote: > > Some of our requirements: > > > > . Native agents for Windows 2003/2008, Linux, Linux x86_64, Solaris Sparc and Solaris x86_64. Either binaries or source code. > > . Ability to send alerts via email, pager and/or snmp > > . Monitoring of OS properties like memory, disk, cpu, etc... > > . Ability to extend agents with scripting to allow monitoring of custom services > > . Plug-in architecture for third-party add-ons > > . Reliable Architecture > > . Reasonable user interface > > . Non-blocking polling > > . Active Project (New Releases on regular basis and have existed for a reasonable period) > > You probably have the list of the most commonly used. Each has good and > bad points. A few of them I believe are limited on using agents and > supporting external scripts. Several are considered Nagios on steroids, > using a Nagios core wrappered in a bunch of other OSS. Several, like > Zenoss are particular about the primarily monitoring system (though > agents might run on any OS). > > Jack > -- "Prediction is very difficult, especially about the future." Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344 From Erik.Amundson at oati.net Wed Jul 22 14:47:59 2009 From: Erik.Amundson at oati.net (Erik Amundson) Date: Wed, 22 Jul 2009 14:47:59 -0500 Subject: Open Source / Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D122128063@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F9D122128063@PUR-EXCH07.ox.com> Message-ID: <635D17EE85D35A49B8F278998E6C340404A98B96D2@EXVS.dev.oati.local> We've been using Ipswitch WhatsUp Gold for many years. Their recent improvements to the product have been mainly system monitoring stuff. The product has grown in capabilities hugely since version 4 when we started with them (they are on version 12 now), and with that improvement in capabilities, the price has gone up a bit. It's still a whole lot less than most other options, however. There isn't too much in the way of agents, but we've integrated a ton of proprietary systems with WhatsUp Gold via it's SQL database back-end. They also have fully scriptable monitoring as a standard feature now. Anyways, thought I'd put in my two cents... - Erik -----Original Message----- From: Matthew Huff [mailto:mhuff at ox.com] Sent: Wednesday, July 22, 2009 1:08 PM To: 'nanog at nanog.org' Subject: Open Source / Low Cost NMS for Server Hardware / Application Monitoring I apologize for not starting a new thread before, I didn't realize that the nanog mailing list created a thread-index rather than using the subject. Even though NANOG is primarily for network operators, I know that a number of members work in NOCs where there is also monitoring of servers/applications. I would appreciate it if anyone has suggestions about monitoring systems that would be applicable to our environment. We have a large number of custom applications on a large number of hosts including Windows 2003/2008, Linux x86/x86_64 and Solaris Sparc/x86_64. We are looking for a better way of monitoring our environment. We are looking for recommendations for opensource or low-cost. We would prefer solutions where the basic monitoring is ready out of the box. Native agents with custom scripting would be highly desired (rather than SNMP/DMI/WMI polling). Some of our requirements: . Native agents for Windows 2003/2008, Linux, Linux x86_64, Solaris Sparc and Solaris x86_64. Either binaries or source code. . Ability to send alerts via email, pager and/or snmp . Monitoring of OS properties like memory, disk, cpu, etc... . Ability to extend agents with scripting to allow monitoring of custom services . Plug-in architecture for third-party add-ons . Reliable Architecture . Reasonable user interface . Non-blocking polling . Active Project (New Releases on regular basis and have existed for a reasonable period) Based on our research and feedback from NANOG, we have put a preliminary list of product to evaluate: Hyperic http://www.hyperic.com/ OpenNMS http://www.opennms.org/wiki/Main_Page opsview http://www.opsview.org/ osimius http://www.osmius.net/en/ PandoraFMS http://pandorafms.org/ Zabbix http://www.zabbix.com/ Groundwork http://www.groundworkopensource.com/ Nagios http://www.nagios.org Zenoss http://zenoss.com OpManager http://www.manageengine.com Orion http://www.solarwinds.com/products/orion/ BigBrother http://bb4.com/ Argus http://argus.tcp4me.com/ Xymon http://www.xymon.com Spiceworks http://www.spiceworks.com/ ICINGA http://www.icinga.org ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 From andrew.wallace at rocketmail.com Wed Jul 22 15:27:39 2009 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Wed, 22 Jul 2009 21:27:39 +0100 Subject: Nanog mentioned on BBC news website Message-ID: <4b6ee9310907221327s10b75643scdf1ce618ab331f2@mail.gmail.com> Big up the Nanog community, you do the net proud... http://news.bbc.co.uk/1/hi/technology/8163190.stm From oberman at es.net Wed Jul 22 18:41:48 2009 From: oberman at es.net (Kevin Oberman) Date: Wed, 22 Jul 2009 16:41:48 -0700 Subject: Nanog mentioned on BBC news website In-Reply-To: Your message of "Wed, 22 Jul 2009 21:27:39 BST." <4b6ee9310907221327s10b75643scdf1ce618ab331f2@mail.gmail.com> Message-ID: <20090722234148.BAFA21CC0B@ptavv.es.net> > Date: Wed, 22 Jul 2009 21:27:39 +0100 > From: "andrew.wallace" > > Big up the Nanog community, you do the net proud... > > http://news.bbc.co.uk/1/hi/technology/8163190.stm First showed up on NANOG 7 hours ago, but it was a fun read. Clearly the article has little connection with reality. I am not an unpaid volunteer and neither were most or all of those involved. The idea that just because the traffic does not originate or terminate on my net means that working on solving a problem is altruism is pretty silly. And NANOG was not really involved though several of those that were are active in NANOG. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From mike at m5computersecurity.com Wed Jul 22 19:05:53 2009 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Wed, 22 Jul 2009 17:05:53 -0700 Subject: What else shall we test? Message-ID: <1248307553.6564.767.camel@mike-desktop> All, We are putting together a test plan to test a pair of Cisco 7206 VXR's, each with with NPE-G2. The purpose of the test is just to make sure we know where their realistic limits are with a real configuration, full route tables from two providers, etc. We have one JDSU T-Berd 8000 test system with interfaces and software to test a single stream through multi-mode fiber interfaces. We plan to test through the interfaces on the NPE and through PA-GE cards with a variety of packet sizes (especially 64 Byte). I'd be interested in any thoughts on additional testing or testing methodologies we might want to do, to help us set our expectations for this setup and to plan when we need to go bigger as we grow traffic, hosts, etc. We plan to get 1 to 3 additional full tables and peer with Any2 Easy on this network within the next year. We want to determine how this platform will behave under moderate DoS attacks, BGP updates, etc. Is there anything else we need to be mindful of? Can we get a realistic test of the routers with the T-Berd? What else should we test while we have the maintenance window and the test system on hand? Your thoughts and experience are appreciated! Thanks ! Mike -- ************************************************************ Michael J. McCafferty Principal, Security Engineer M5 Hosting http://www.m5hosting.com You can have your own custom Dedicated Server up and running today ! RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more ************************************************************ From patrick at ianai.net Wed Jul 22 19:44:21 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 22 Jul 2009 20:44:21 -0400 Subject: Nanog mentioned on BBC news website In-Reply-To: <20090722234148.BAFA21CC0B@ptavv.es.net> References: <20090722234148.BAFA21CC0B@ptavv.es.net> Message-ID: On Jul 22, 2009, at 7:41 PM, Kevin Oberman wrote: >> Date: Wed, 22 Jul 2009 21:27:39 +0100 >> From: "andrew.wallace" >> >> Big up the Nanog community, you do the net proud... >> >> http://news.bbc.co.uk/1/hi/technology/8163190.stm > > First showed up on NANOG 7 hours ago, but it was a fun read. > > Clearly the article has little connection with reality. I am not an > unpaid volunteer and neither were most or all of those involved. The > idea that just because the traffic does not originate or terminate > on my > net means that working on solving a problem is altruism is pretty > silly. My fav part: "That's precisely how packets move around the internet, sometimes in a many as 25 or 30 hops with the intervening entities passing the data around having no contractual or legal obligation to the original sender or to the receiver." How many of you pass packets without getting paid? Kinda makes you wonder about all those other TED talks, huh? > And NANOG was not really involved though several of those that were > are > active in NANOG. Well, one could argue that NANOG _is_ its members. Yeah, a stretch, but I'm trying. :-) -- TTFN, patrick From adrian.minta at gmail.com Thu Jul 23 00:19:44 2009 From: adrian.minta at gmail.com (Adrian Minta) Date: Thu, 23 Jul 2009 08:19:44 +0300 Subject: What else shall we test? Message-ID: <4a67f2f2.0af6660a.601a.0f78@mx.google.com> I will sugest to test the throughput when a BGP peer is flapping. -----Original Message----- From: Michael J McCafferty Sent: 23 iulie 2009 03:05 To: nanog Subject: What else shall we test? All, We are putting together a test plan to test a pair of Cisco 7206 VXR's, each with with NPE-G2. The purpose of the test is just to make sure we know where their realistic limits are with a real configuration, full route tables from two providers, etc. We have one JDSU T-Berd 8000 test system with interfaces and software to test a single stream through multi-mode fiber interfaces. We plan to test through the interfaces on the NPE and through PA-GE cards with a variety of packet sizes (especially 64 Byte). I'd be interested in any thoughts on additional testing or testing methodologies we might want to do, to help us set our expectations for this setup and to plan when we need to go bigger as we grow traffic, hosts, etc. We plan to get 1 to 3 additional full tables and peer with Any2 Easy on this network within the next year. We want to determine how this platform will behave under moderate DoS attacks, BGP updates, etc. Is there anything else we need to be mindful of? Can we get a realistic test of the routers with the T-Berd? What else should we test while we have the maintenance window and the test system on hand? Your thoughts and experience are appreciated! Thanks ! Mike -- ************************************************************ Michael J. McCafferty Principal, Security Engineer M5 Hosting http://www.m5hosting.com You can have your own custom Dedicated Server up and running today ! RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more ************************************************************ From sharef.mustafa at paltel.net Thu Jul 23 04:48:51 2009 From: sharef.mustafa at paltel.net (Sharef Mustafa) Date: Thu, 23 Jul 2009 12:48:51 +0300 Subject: Blocking IPv6 broadcast Message-ID: Hi, I have a customer connected to my Cisco 3560 switch via Gigabit Ethernet, recently I noticed that he is broadcasting IPv6 packets such as LLMNR, DHCPv6 and ICMPv6 it seems that the customer is connecting a Vista machine that has some IPv6 services enabled (some IPv6 services are enabled by default on Vista) How can I block such broadcast from entering my network? By the way there is no firewall in this setup, just a switch to switch. BR Sharef From swmike at swm.pp.se Thu Jul 23 05:15:56 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 23 Jul 2009 12:15:56 +0200 (CEST) Subject: Blocking IPv6 broadcast In-Reply-To: References: Message-ID: On Thu, 23 Jul 2009, Sharef Mustafa wrote: > How can I block such broadcast from entering my network? If you are not doing any L2 security for IPv6, you probably want to block the IPv6 ethertype packets altogether. Found a link here that might be useful: I suggest anyone with L2 possibility between customers to implement something like this to avoid rogue RAs. -- Mikael Abrahamsson email: swmike at swm.pp.se From jim at reptiles.org Thu Jul 23 06:27:26 2009 From: jim at reptiles.org (Jim Mercer) Date: Thu, 23 Jul 2009 07:27:26 -0400 Subject: Nanog mentioned on BBC news website In-Reply-To: References: <20090722234148.BAFA21CC0B@ptavv.es.net> Message-ID: <20090723112726.GB68894@reptiles.org> On Wed, Jul 22, 2009 at 08:44:21PM -0400, Patrick W. Gilmore wrote: > My fav part: > > "That's precisely how packets move around the internet, sometimes in a > many as 25 or 30 hops with the intervening entities passing the data > around having no contractual or legal obligation to the original > sender or to the receiver." > > > How many of you pass packets without getting paid? in the case of intervening entities, it is true that they have no link to the sender or receiver. my packets from office to home can traverse at 3 or more networks that are not paid by me, or my company. they likely have contracts or obligations with their immediate neighbours, which is basically why the system continues to work. -- Jim Mercer jim at reptiles.org +971 55 410-5633 "I'm Prime Minister of Canada, I live here and I'm going to take a leak." - Lester Pearson in 1967, during a meeting between himself and President Lyndon Johnson, whose Secret Service detail had taken over Pearson's cottage retreat. At one point, a Johnson guard asked Pearson, "Who are you and where are you going?" From andrey.gordon at gmail.com Thu Jul 23 08:56:33 2009 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Thu, 23 Jul 2009 09:56:33 -0400 Subject: Open Source / Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: <635D17EE85D35A49B8F278998E6C340404A98B96D2@EXVS.dev.oati.local> References: <483E6B0272B0284BA86D7596C40D29F9D122128063@PUR-EXCH07.ox.com> <635D17EE85D35A49B8F278998E6C340404A98B96D2@EXVS.dev.oati.local> Message-ID: <1E71FD04-3D6B-40CC-8016-74F1DCFAAF1A@gmail.com> May I also mention InterMapper from Dartware. Very low price solution. Doesn't do well with trending and graphing out of the box (use RRD to get data out of it), but I like the live maps, platform independence and ease of creating new probes. I try to use SNMP wherever possible, but it can take pass parameters to an external script and analyze it's output as well. > -----Original Message----- > From: Matthew Huff [mailto:mhuff at ox.com] > Sent: Wednesday, July 22, 2009 1:08 PM > To: 'nanog at nanog.org' > Subject: Open Source / Low Cost NMS for Server Hardware / > Application Monitoring > > I apologize for not starting a new thread before, I didn't realize > that the nanog mailing list created a thread-index rather than using > the subject. > > Even though NANOG is primarily for network operators, I know that a > number of members work in NOCs where there is also monitoring of > servers/applications. I would appreciate it if anyone has > suggestions about monitoring systems that would be applicable to our > environment. We have a large number of custom applications on a > large number of hosts including Windows 2003/2008, Linux x86/x86_64 > and Solaris Sparc/x86_64. We are looking for a better way of > monitoring our environment. We are looking for recommendations for > opensource or low-cost. We would prefer solutions where the basic > monitoring is ready out of the box. Native agents with custom > scripting would be highly desired (rather than SNMP/DMI/WMI polling). > > Some of our requirements: > > . Native agents for Windows 2003/2008, Linux, Linux x86_64, > Solaris Sparc and Solaris x86_64. Either binaries or source code. > . Ability to send alerts via email, pager and/or snmp > . Monitoring of OS properties like memory, disk, cpu, etc... > . Ability to extend agents with scripting to allow monitoring > of custom services > . Plug-in architecture for third-party add-ons > . Reliable Architecture > . Reasonable user interface > . Non-blocking polling > . Active Project (New Releases on regular basis and have > existed for a reasonable period) > > Based on our research and feedback from NANOG, we have put a > preliminary list of product to evaluate: > > Hyperic http://www.hyperic.com/ > OpenNMS http://www.opennms.org/wiki/Main_Page > opsview http://www.opsview.org/ > osimius http://www.osmius.net/en/ > PandoraFMS http://pandorafms.org/ > Zabbix http://www.zabbix.com/ > Groundwork http://www.groundworkopensource.com/ > Nagios http://www.nagios.org > Zenoss http://zenoss.com > OpManager http://www.manageengine.com > Orion http://www.solarwinds.com/products/orion/ > BigBrother http://bb4.com/ > Argus http://argus.tcp4me.com/ > Xymon http://www.xymon.com > Spiceworks http://www.spiceworks.com/ > ICINGA http://www.icinga.org > > ---- > Matthew Huff | One Manhattanville Rd > OTA Management LLC | Purchase, NY 10577 > http://www.ox.com | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 203 bytes Desc: This is a digitally signed message part URL: From marc at ena.com Thu Jul 23 09:38:45 2009 From: marc at ena.com (Marc Powell) Date: Thu, 23 Jul 2009 09:38:45 -0500 Subject: Open Source / Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: <1248289822.18828.75.camel@artoo.vvmedia.com> References: <483E6B0272B0284BA86D7596C40D29F9D122128063@PUR-EXCH07.ox.com> <4A675D15.7000102@brightok.net> <1248289822.18828.75.camel@artoo.vvmedia.com> Message-ID: <830649D2-8895-4871-97AF-25671E212110@ena.com> On Jul 22, 2009, at 2:10 PM, Ray Sanders wrote: > So for a large nationwide environment like ours, our ROI was pretty > decent, but if you are only watching a dozen or two systems with maybe > ten monitors each, Nagios would be the best bet. I would disagree; nagios is not limited to small systems... We're currently monitoring about 8500 services on 2834 routers with nagios quite successfully and have been doing so for nearly a decade now -- we started with Netsaint. With custom scripts receiving data from our inventory management system, Nagios config generation for 99% of the hosts is completely automated with only a handful of special cases that are hand-modified as needed. Our investment, both in initial/ ongoing man-hours, hardware, etc is minimal so our ROI is decent too ;) -- Marc From charles at thewybles.com Thu Jul 23 12:33:58 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 23 Jul 2009 10:33:58 -0700 Subject: Open Source / Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: <830649D2-8895-4871-97AF-25671E212110@ena.com> References: <483E6B0272B0284BA86D7596C40D29F9D122128063@PUR-EXCH07.ox.com> <4A675D15.7000102@brightok.net> <1248289822.18828.75.camel@artoo.vvmedia.com> <830649D2-8895-4871-97AF-25671E212110@ena.com> Message-ID: <4A689F06.9070604@thewybles.com> > I would disagree; nagios is not limited to small systems... We're > currently monitoring about 8500 services on 2834 routers with nagios > quite successfully and have been doing so for nearly a decade now -- we > started with Netsaint. With custom scripts receiving data from our > inventory management system, Nagios config generation for 99% of the > hosts is completely automated with only a handful of special cases that > are hand-modified as needed. Our investment, both in initial/ongoing > man-hours, hardware, etc is minimal so our ROI is decent too ;) > > -- > Marc > +1 / what he said I auto generate my nagios configs from an in house asset management system as well. It works great. Monitoring over 1k devices. We built a custom reporting system around nagios as well. From WJohnston at induscorp.com Thu Jul 23 12:40:39 2009 From: WJohnston at induscorp.com (Winn Johnston) Date: Thu, 23 Jul 2009 13:40:39 -0400 Subject: Open Source / Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: <4A689F06.9070604@thewybles.com> References: <483E6B0272B0284BA86D7596C40D29F9D122128063@PUR-EXCH07.ox.com> <4A675D15.7000102@brightok.net> <1248289822.18828.75.camel@artoo.vvmedia.com> <830649D2-8895-4871-97AF-25671E212110@ena.com>, <4A689F06.9070604@thewybles.com> Message-ID: +1 / what he said I used it at the DNC worked like a charm! Winn Johnston Linux Systems Administrator 703 380 8666 ________________________________________ From: Charles Wyble [charles at thewybles.com] Sent: Thursday, July 23, 2009 1:33 PM To: nanog at nanog.org Subject: Re: Open Source / Low Cost NMS for Server Hardware / Application Monitoring > I would disagree; nagios is not limited to small systems... We're > currently monitoring about 8500 services on 2834 routers with nagios > quite successfully and have been doing so for nearly a decade now -- we > started with Netsaint. With custom scripts receiving data from our > inventory management system, Nagios config generation for 99% of the > hosts is completely automated with only a handful of special cases that > are hand-modified as needed. Our investment, both in initial/ongoing > man-hours, hardware, etc is minimal so our ROI is decent too ;) > > -- > Marc > +1 / what he said I auto generate my nagios configs from an in house asset management system as well. It works great. Monitoring over 1k devices. We built a custom reporting system around nagios as well. ______________________________________________________________________ This inbound email was scanned by MessageLabs _____________________________________________________________________ ______________________________________________________________________ This email was scanned by MessageLabs _____________________________________________________________________ From truman at suspicious.org Thu Jul 23 13:19:50 2009 From: truman at suspicious.org (Truman Boyes) Date: Thu, 23 Jul 2009 14:19:50 -0400 Subject: What else shall we test? In-Reply-To: <1248307553.6564.767.camel@mike-desktop> References: <1248307553.6564.767.camel@mike-desktop> Message-ID: Hi Michael, I would suggest testing: throughput with 64 byte packets throughput with 1500 byte packets a distribution of whatever you deem an imix to be ... 64, 128, 512, 1500 with a Poisson distribution. throughput of periodic packet stream when the control plane is being affected (ie. either icmp to router, TTL expired, or some router alert option) max prefixes number of lost packets when fiber is pulled to one of the "uplinks" ... to determine the convergence time. you can send 1000 packets per second and loop the receive back to the test unit so you can track how many milliseconds of packet loss. IPv6 throughput number of filters / ACLs applied ... and throughput when these ACLs are applied. number of supported mac filters Apply a filter to the control plane and then attack port 179 .. see how the BGP sessions hold up. saturate a GE card with transit traffic and see if the network control packets suffer any loss (ie. session drop, retransmit, etc) Kind regards, Truman Boyes On 22/07/2009, at 8:05 PM, Michael J McCafferty wrote: > All, > We are putting together a test plan to test a pair of Cisco 7206 > VXR's, > each with with NPE-G2. The purpose of the test is just to make sure we > know where their realistic limits are with a real configuration, full > route tables from two providers, etc. We have one JDSU T-Berd 8000 > test > system with interfaces and software to test a single stream through > multi-mode fiber interfaces. We plan to test through the interfaces on > the NPE and through PA-GE cards with a variety of packet sizes > (especially 64 Byte). > I'd be interested in any thoughts on additional testing or testing > methodologies we might want to do, to help us set our expectations for > this setup and to plan when we need to go bigger as we grow traffic, > hosts, etc. > We plan to get 1 to 3 additional full tables and peer with Any2 > Easy on > this network within the next year. We want to determine how this > platform will behave under moderate DoS attacks, BGP updates, etc. Is > there anything else we need to be mindful of? Can we get a realistic > test of the routers with the T-Berd? What else should we test while we > have the maintenance window and the test system on hand? > > Your thoughts and experience are appreciated! > > Thanks ! > Mike > > -- > ************************************************************ > Michael J. McCafferty > Principal, Security Engineer > M5 Hosting > http://www.m5hosting.com > > You can have your own custom Dedicated Server up and running today ! > RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more > ************************************************************ > > From deepak at ai.net Thu Jul 23 13:56:36 2009 From: deepak at ai.net (Deepak Jain) Date: Thu, 23 Jul 2009 14:56:36 -0400 Subject: Nanog mentioned on BBC news website In-Reply-To: <20090723112726.GB68894@reptiles.org> References: <20090722234148.BAFA21CC0B@ptavv.es.net> <20090723112726.GB68894@reptiles.org> Message-ID: > in the case of intervening entities, it is true that they have no link > to > the sender or receiver. my packets from office to home can traverse at > 3 > or more networks that are not paid by me, or my company. > > they likely have contracts or obligations with their immediate > neighbours, > which is basically why the system continues to work. > I'm not sure if this is the benefit for the lurkers or the old guys, or will eventually get recycled in the press and give me a headache, but here goes. I think what people seem to keep skipping over is the concept that packets generated from "A" go to ISP "B" who has relationship with C... to pass packets to "Z". From the point of view of "C" all packets from "B" (including "A") are just "B"'s traffic. It's not as simple as I have an agreement with my neighbor and we pass slop around. If I am "C", whatever my neighbor is moving is essentially of equal value in my agreement with my neighbor (until one of us chooses to renegotiate it: i.e. peering dispute, whatever). No matter which "A" is sending it to "B". I don't *really* get the option to pick and choose on a per packet basis. In the case of three intervening networks, each is aggregating their customers' traffic and passing the relevant portions to the neighboring network (presumably for *their* aggregated customers' traffic). This is, in some ways, fundamentally different than the US highway system, where if I'm driving a truck between one state and another, the next state (even though they have interconnection agreements) can set different rules on me than the state I just left. I know this happens with (for example) Michigan and its neighbors. In the Internet context, my neighbor is responsible to abide by our agreement and prevent the traffic coming over to me from violating that agreement and I am allowed to police and enforce that border any way I want. What this means is that if "A" is affected by something, from my perspective as "C", "B" is absolutely authoritative for the discussion about "A"'s traffic and what to do with it. (No matter how many "B"'s A has contracted with, B and C do not have to ask A for permission for ways/means/methods to move packets). We can agree to drop it on the floor, give it priority or special treatment or generally just ignore it and let the packets pass the way they will. This how the so-called community "volunteers" have so much ability to affect and improve the system. Everyone operates in their own fiefdom owing little allegiance (other than those of commerce and equity) to its neighbors. I may charge a tariff to enter my fiefdom, but once packets enter my fiefdom, they are my packets. I protect them, and try to speed them on their way without impediment and I negotiate with others on their behalf to improve their happiness. And continuing the micro-economics analogy... this is why periodic wars break out between larger fiefdoms and there is little way to influence them to play for the "good" of the system. The only way to influence them is for their own good. DJ P.S. I've been scratching my head and wondering what this TED thing is all about, it seems like a big cheerleading thing.. From goemon at anime.net Thu Jul 23 15:22:54 2009 From: goemon at anime.net (goemon at anime.net) Date: Thu, 23 Jul 2009 13:22:54 -0700 (PDT) Subject: questionable email filtering policies? Message-ID: Seems rather unwise to filter your abuse mailbox. ----- The following addresses had permanent fatal errors ----- (reason: 554 Message not allowed - UP Email not accepted for policy reasons. Please visit http://help.yahoo.com/help/us/mail/defer/defer-04.html [120]) -Dan From bc-list at beztech.net Thu Jul 23 15:27:41 2009 From: bc-list at beztech.net (Ben Carleton) Date: Thu, 23 Jul 2009 16:27:41 -0400 Subject: questionable email filtering policies? In-Reply-To: References: Message-ID: <02E68C62-DC12-4F0E-8578-34B23B8F9E64@beztech.net> Try filling out this form to reach Y's abuse dept? http://help.yahoo.com/l/us/yahoo/mail/postmaster/defer.html --bc On Jul 23, 2009, at 4:22 PM, goemon at anime.net wrote: > Seems rather unwise to filter your abuse mailbox. > > ----- The following addresses had permanent fatal errors ----- > > (reason: 554 Message not allowed - UP Email not accepted for > policy reasons. Please visit http://help.yahoo.com/help/us/mail/defer/defer-04.html > [120]) > > -Dan > From herrin-nanog at dirtside.com Thu Jul 23 15:38:24 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Thu, 23 Jul 2009 16:38:24 -0400 Subject: Nanog mentioned on BBC news website In-Reply-To: <20090723112726.GB68894@reptiles.org> References: <20090722234148.BAFA21CC0B@ptavv.es.net> <20090723112726.GB68894@reptiles.org> Message-ID: <3c3e3fca0907231338xf5efadfo75de38314f2f5634@mail.gmail.com> On Thu, Jul 23, 2009 at 7:27 AM, Jim Mercer wrote: > On Wed, Jul 22, 2009 at 08:44:21PM -0400, Patrick W. Gilmore wrote: >> My fav part: >> >> "That's precisely how packets move around the internet, sometimes in a >> many as 25 or 30 hops with the intervening entities passing the data >> around having no contractual or legal obligation to the original >> sender or to the receiver." >> >> >> How many of you pass packets without getting paid? > > in the case of intervening entities, it is true that they have no link to > the sender or receiver. ?my packets from office to home can traverse at 3 > or more networks that are not paid by me, or my company. If I pay you to send my packets and you pay bob to send my packets then I have paid bob to send my packets. Transitive property of payment. ;-) 'Couse bob doesn't pay claire anything but denise pays claire to receive packets for denise, my packets are intended for denise and bob and claire have a peering agreement in which they agree to swap already-paid traffic directly rather than both paying ed to do it for them. So it ain't free and at each step there is a contractual obligation to at least one of the sender or receiver. Regards, Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From patrick at ianai.net Thu Jul 23 15:50:44 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 23 Jul 2009 13:50:44 -0700 Subject: Nanog mentioned on BBC news website In-Reply-To: <20090723112726.GB68894@reptiles.org> References: <20090722234148.BAFA21CC0B@ptavv.es.net> <20090723112726.GB68894@reptiles.org> Message-ID: Sent from my iPhone, please excuse any errors. On Jul 23, 2009, at 4:27, Jim Mercer wrote: > On Wed, Jul 22, 2009 at 08:44:21PM -0400, Patrick W. Gilmore wrote: >> My fav part: >> >> "That's precisely how packets move around the internet, sometimes >> in a >> many as 25 or 30 hops with the intervening entities passing the data >> around having no contractual or legal obligation to the original >> sender or to the receiver." >> >> >> How many of you pass packets without getting paid? > > in the case of intervening entities, it is true that they have no > link to > the sender or receiver. my packets from office to home can traverse > at 3 > or more networks that are not paid by me, or my company. > > they likely have contracts or obligations with their immediate > neighbours, > which is basically why the system continues to work. I honestly expected someone to mention this when I wrote the original post, but I had hopes no one would. :-) It is clear the intent of the TED speaker was the intermediaries were transiting packets out of the good of their hearts. Allow me to illustrate: The postal system is amazing! You can mail a letter from the US to England and the "intermediate" carrier will deliver the mail even though they have NO contract with you or the recipient! How awesome is that? This is not fantasy. You give it to the USPS, who will hand it to DHL, who will hand it to Royal Mail, who will hand it to the recipient. Does _anyone_ comment on the lack of your contract with DHL? Is anyone surprised it still works? Is it worthy of a TED talk? -- TTFN, patrick From WJohnston at induscorp.com Thu Jul 23 16:18:07 2009 From: WJohnston at induscorp.com (Winn Johnston) Date: Thu, 23 Jul 2009 17:18:07 -0400 Subject: Nanog mentioned on BBC news website In-Reply-To: <3c3e3fca0907231338xf5efadfo75de38314f2f5634@mail.gmail.com> References: <20090722234148.BAFA21CC0B@ptavv.es.net> <20090723112726.GB68894@reptiles.org>, <3c3e3fca0907231338xf5efadfo75de38314f2f5634@mail.gmail.com> Message-ID: Very well put Bill :) Winn Johnston Linux Systems Administrator ________________________________________ From: William Herrin [herrin-nanog at dirtside.com] Sent: Thursday, July 23, 2009 4:38 PM To: Jim Mercer Cc: NANOG list Subject: Re: Nanog mentioned on BBC news website On Thu, Jul 23, 2009 at 7:27 AM, Jim Mercer wrote: > On Wed, Jul 22, 2009 at 08:44:21PM -0400, Patrick W. Gilmore wrote: >> My fav part: >> >> "That's precisely how packets move around the internet, sometimes in a >> many as 25 or 30 hops with the intervening entities passing the data >> around having no contractual or legal obligation to the original >> sender or to the receiver." >> >> >> How many of you pass packets without getting paid? > > in the case of intervening entities, it is true that they have no link to > the sender or receiver. my packets from office to home can traverse at 3 > or more networks that are not paid by me, or my company. If I pay you to send my packets and you pay bob to send my packets then I have paid bob to send my packets. Transitive property of payment. ;-) 'Couse bob doesn't pay claire anything but denise pays claire to receive packets for denise, my packets are intended for denise and bob and claire have a peering agreement in which they agree to swap already-paid traffic directly rather than both paying ed to do it for them. So it ain't free and at each step there is a contractual obligation to at least one of the sender or receiver. Regards, Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 ______________________________________________________________________ This inbound email was scanned by MessageLabs _____________________________________________________________________ ______________________________________________________________________ This email was scanned by MessageLabs _____________________________________________________________________ From Valdis.Kletnieks at vt.edu Thu Jul 23 17:04:48 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 23 Jul 2009 18:04:48 -0400 Subject: questionable email filtering policies? In-Reply-To: Your message of "Thu, 23 Jul 2009 13:22:54 PDT." References: Message-ID: <12428.1248386688@turing-police.cc.vt.edu> On Thu, 23 Jul 2009 13:22:54 PDT, goemon at anime.net said: > Seems rather unwise to filter your abuse mailbox. > > ----- The following addresses had permanent fatal errors ----- > > (reason: 554 Message not allowed - UP Email not accepted for policy reasons. Please visit http://help.yahoo.com/help/us/mail/defer/defer-04.html [120]) I'm not sure which is worse: 1) That they filter their abuse mailbox. 2) That they outsource their abuse mailbox (and potentially others) to Yahoo. 3) That they're doing (2) and they're apparently a few orders of magnitude bigger than "Joe's Bait, Tackle, and Internet Emporium". "And they wonder why we block their e-mail.." -- the NANOG lurker in the next cubicle, standard response when a site's demonstrated configuration clue level is so low to render constructive dialog improbable. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From johnl at iecc.com Thu Jul 23 19:10:16 2009 From: johnl at iecc.com (John Levine) Date: 24 Jul 2009 00:10:16 -0000 Subject: questionable email filtering policies? In-Reply-To: <12428.1248386688@turing-police.cc.vt.edu> Message-ID: <20090724001016.9461.qmail@simone.iecc.com> >> >I'm not sure which is worse: >1) That they filter their abuse mailbox. >2) That they outsource their abuse mailbox (and potentially others) to Yahoo. BT outsources all of their mail to Yahoo. It actually works pretty well, either POP or web mail. R's, John From goemon at anime.net Thu Jul 23 22:29:47 2009 From: goemon at anime.net (goemon at anime.net) Date: Thu, 23 Jul 2009 20:29:47 -0700 (PDT) Subject: questionable email filtering policies? In-Reply-To: <02E68C62-DC12-4F0E-8578-34B23B8F9E64@beztech.net> References: <02E68C62-DC12-4F0E-8578-34B23B8F9E64@beztech.net> Message-ID: assume i have already done this, and received a completely and utterly useless response from yahoo indicating they have absolutely not the slightest clue. -Dan On Thu, 23 Jul 2009, Ben Carleton wrote: > Try filling out this form to reach Y's abuse dept? > http://help.yahoo.com/l/us/yahoo/mail/postmaster/defer.html > > > --bc > On Jul 23, 2009, at 4:22 PM, goemon at anime.net wrote: > >> Seems rather unwise to filter your abuse mailbox. >> >> ----- The following addresses had permanent fatal errors ----- >> >> (reason: 554 Message not allowed - UP Email not accepted for policy >> reasons. Please visit >> http://help.yahoo.com/help/us/mail/defer/defer-04.html [120]) >> >> -Dan >> > From rmacharia at gmail.com Thu Jul 23 23:27:30 2009 From: rmacharia at gmail.com (Raymond Macharia) Date: Fri, 24 Jul 2009 07:27:30 +0300 Subject: Nanog mentioned on BBC news website In-Reply-To: <4b6ee9310907221327s10b75643scdf1ce618ab331f2@mail.gmail.com> References: <4b6ee9310907221327s10b75643scdf1ce618ab331f2@mail.gmail.com> Message-ID: Hi To summarize the article "Nanogers you do a great job" On the rest we can safely say we are probably more clueful as to what goes on and we can try as much to correct but I doubt anyone will want to put all the gory details in any form of press Raymond On 7/22/09, andrew.wallace wrote: > Big up the Nanog community, you do the net proud... > > http://news.bbc.co.uk/1/hi/technology/8163190.stm > > -- Sent from my mobile device Raymond Macharia From chaz at chaz6.com Fri Jul 24 08:28:31 2009 From: chaz at chaz6.com (Chris Hills) Date: Fri, 24 Jul 2009 15:28:31 +0200 Subject: questionable email filtering policies? In-Reply-To: References: Message-ID: On 23/07/09 22:22, goemon at anime.net wrote: > Seems rather unwise to filter your abuse mailbox. > > ----- The following addresses had permanent fatal errors ----- > > (reason: 554 Message not allowed - UP Email not accepted for policy > reasons. Please visit > http://help.yahoo.com/help/us/mail/defer/defer-04.html [120]) > > -Dan On the topic of mail rejection I have come across a few sites that reject mail, even to postmaster@, from domains that have one or more ipv6-only MX records listed (i.e. a domain name with AAAA but no A record(s)). The common factor seems to be mimedefang. From fweimer at bfk.de Fri Jul 24 08:39:15 2009 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 24 Jul 2009 13:39:15 +0000 Subject: questionable email filtering policies? In-Reply-To: (Chris Hills's message of "Fri\, 24 Jul 2009 15\:28\:31 +0200") References: Message-ID: <823a8m2oak.fsf@mid.bfk.de> * Chris Hills: > On the topic of mail rejection I have come across a few sites that > reject mail, even to postmaster@, from domains that have one or more > ipv6-only MX records listed (i.e. a domain name with AAAA but no A > record(s)). The common factor seems to be mimedefang. Plain sendmail has got a similar issue, especially if the best MX is IPv6-only. I learnt that the hard way---and it speaks for the quality of IPv6 testing that the "IPv6 considerations for SMTP" RFC (forgot its number) doesn't even come close to mentioning this issue, preferring to talk about bizarre reachability concerns. 8-P -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From llynch at civil-tongue.net Fri Jul 24 09:10:53 2009 From: llynch at civil-tongue.net (Lucy Lynch) Date: Fri, 24 Jul 2009 07:10:53 -0700 (PDT) Subject: 5 forwarded messages... (fwd) Message-ID: All - Forwarded with permission. I think that Jonathan was actually commenting on two aspects that make the Internet model unique, one of which is the innovative nature of peering relationships and the second is the sense of a shared interest in the health and safety of global routing which is reflected in responses to network issues. NANOG is a part of both these forms of "goodness". - Lucy ---------- Forwarded message ---------- Date: Fri, 24 Jul 2009 09:54:39 -0400 From: Jonathan Zittrain To: lynch at isoc.org Subject: Re: 5 forwarded messages... Lucy, Thanks for forwarding. It's not easy to compress the details of Internet routing (including BGP) into a short talk for laypeople, and going from that to a news article is even more lossy. Here's the context in which I brought it up: the Internet is not the only way to build a global data network, and its differences from other models, literal and metaphorical, are notable. The protocols themselves were in large part developed without the standard attempts to profit from them -- a case of the "patent that never was," as some have also called the Web. The daisy chains (daisy webs?) of routing are not, to me, functionally equivalent to the transitivity of contracts that make the international postal system flow, because of the ways in which new ISPs and ASNs can come and go, and overlap one another. There is a generativity to the network that has allowed for the kinds of innovation that simply haven't happened in more closed (and, some would say, rational) means of networking. I'm sure my view here is colored by my longtime experience with CompuServe, and the near-universal view I perceived among its engineers and sysops in the mid-80's that tomorrow's global network would be the winner of the grudge match among them, the Source, Prodigy, AOL, etc., not the backwater Internet. On the "volunteer" label -- I did not mean that members of NANOG (or the broader network community) are unemployed, or even employed only in unrelated fields. Instead, I wanted to say that when an incident like the YouTube/Pakistan situation comes up, there are people working together to solve it who don't owe YouTube a thing, and that aside from (re-)advertising its own equally or more specific route to itself, YouTube was not particularly privileged to fix the blackholing. It required people to help each other sort out the competing claims, and then favor YouTube's claim over that of AS17557. So, as I understand it, current routing implementations entail certain systemic vulnerabilities for which the YouTube incident is a good example, and when risks materialize they're dealt with in a kind of ad hoc fashion that relies on a lot of cooperation, and not necessarily among contracting parties. I see similarities to the ways Wikipedia governance works, but that's probably flamebait for another time. Anyway, as the clueless country lawyer, I'm anxious to know what I'm missing or getting wrong or imprecise. Best, JZ At GMT-4 09:06 AM 7/24/2009, you wrote: > Jonathan - > > As I mentioned earlier, it looks like the BBC managed to > mangle your point about transit relationships fairly > thoroughly. I think Patrick caught your quote, but the > gist of your point has been lost. > > > Lucy Lynch > Director, Trust and Identity Initiatives > Internet Society (ISOC ) > > ---------- Forwarded message ---------- > Date: Wed, 22 Jul 2009 20:44:21 -0400 > From: Patrick W. Gilmore > To: NANOG list > Subject: Re: Nanog mentioned on BBC news website > > On Jul 22, 2009, at 7:41 PM, Kevin Oberman wrote: > >>> Date: Wed, 22 Jul 2009 21:27:39 +0100 >>> From: "andrew.wallace" >>> Big up the Nanog community, you do the net proud... >>> http://news.bbc.co.uk/1/hi/technology/8163190.stm >> First showed up on NANOG 7 hours ago, but it was a fun read. >> Clearly the article has little connection with reality. I am not an >> unpaid volunteer and neither were most or all of those involved. The >> idea that just because the traffic does not originate or terminate on my >> net means that working on solving a problem is altruism is pretty silly. > > My fav part: > > > "That's precisely how packets move around the internet, sometimes in a many > as 25 or 30 hops with the intervening entities passing the data around having > no contractual or legal obligation to the original sender or to the > receiver." > > > How many of you pass packets without getting paid? > > Kinda makes you wonder about all those other TED talks, huh? > > >> And NANOG was not really involved though several of those that were are >> active in NANOG. > > Well, one could argue that NANOG _is_ its members. > > Yeah, a stretch, but I'm trying. :-) > > -- > TTFN, > patrick > > > > > ---------- Forwarded message ---------- > Date: Thu, 23 Jul 2009 14:56:36 -0400 > From: Deepak Jain > To: Jim Mercer , Patrick W. Gilmore > Cc: NANOG list > Subject: RE: Nanog mentioned on BBC news website > >> in the case of intervening entities, it is true that they have no link >> to >> the sender or receiver. my packets from office to home can traverse at >> 3 >> or more networks that are not paid by me, or my company. >> >> they likely have contracts or obligations with their immediate >> neighbours, >> which is basically why the system continues to work. > > I'm not sure if this is the benefit for the lurkers or the old guys, or will > eventually get recycled in the press and give me a headache, but here goes. > > I think what people seem to keep skipping over is the concept that packets > generated from "A" go to ISP "B" who has relationship with C... to pass > packets to "Z". From the point of view of "C" all packets from "B" (including > "A") are just "B"'s traffic. It's not as simple as I have an agreement with > my neighbor and we pass slop around. > > If I am "C", whatever my neighbor is moving is essentially of equal value in > my agreement with my neighbor (until one of us chooses to renegotiate it: > i.e. peering dispute, whatever). No matter which "A" is sending it to "B". I > don't *really* get the option to pick and choose on a per packet basis. > > In the case of three intervening networks, each is aggregating their > customers' traffic and passing the relevant portions to the neighboring > network (presumably for *their* aggregated customers' traffic). > > This is, in some ways, fundamentally different than the US highway system, > where if I'm driving a truck between one state and another, the next state > (even though they have interconnection agreements) can set different rules on > me than the state I just left. I know this happens with (for example) > Michigan and its neighbors. > > In the Internet context, my neighbor is responsible to abide by our agreement > and prevent the traffic coming over to me from violating that agreement and I > am allowed to police and enforce that border any way I want. > > What this means is that if "A" is affected by something, from my perspective > as "C", "B" is absolutely authoritative for the discussion about "A"'s > traffic and what to do with it. (No matter how many "B"'s A has contracted > with, B and C do not have to ask A for permission for ways/means/methods to > move packets). We can agree to drop it on the floor, give it priority or > special treatment or generally just ignore it and let the packets pass the > way they will. > > This how the so-called community "volunteers" have so much ability to affect > and improve the system. Everyone operates in their own fiefdom owing little > allegiance (other than those of commerce and equity) to its neighbors. I may > charge a tariff to enter my fiefdom, but once packets enter my fiefdom, they > are my packets. I protect them, and try to speed them on their way without > impediment and I negotiate with others on their behalf to improve their > happiness. > > And continuing the micro-economics analogy... this is why periodic wars break > out between larger fiefdoms and there is little way to influence them to play > for the "good" of the system. The only way to influence them is for their own > good. > > DJ > > P.S. I've been scratching my head and wondering what this TED thing is all > about, it seems like a big cheerleading thing.. > > > > > > ---------- Forwarded message ---------- > Date: Thu, 23 Jul 2009 16:38:24 -0400 > From: William Herrin > To: Jim Mercer > Cc: NANOG list > Subject: Re: Nanog mentioned on BBC news website > > On Thu, Jul 23, 2009 at 7:27 AM, Jim Mercer wrote: >> On Wed, Jul 22, 2009 at 08:44:21PM -0400, Patrick W. Gilmore wrote: >>> My fav part: >>> >>> "That's precisely how packets move around the internet, sometimes in a >>> many as 25 or 30 hops with the intervening entities passing the data >>> around having no contractual or legal obligation to the original >>> sender or to the receiver." >>> >>> >>> How many of you pass packets without getting paid? >> >> in the case of intervening entities, it is true that they have no link to >> the sender or receiver. ? my packets from office to home can traverse at 3 >> or more networks that are not paid by me, or my company. > > If I pay you to send my packets and you pay bob to send my packets > then I have paid bob to send my packets. Transitive property of > payment. ;-) > > 'Couse bob doesn't pay claire anything but denise pays claire to > receive packets for denise, my packets are intended for denise and bob > and claire have a peering agreement in which they agree to swap > already-paid traffic directly rather than both paying ed to do it for > them. > > So it ain't free and at each step there is a contractual obligation to > at least one of the sender or receiver. > > Regards, > Bill > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > > > ---------- Forwarded message ---------- > Date: Thu, 23 Jul 2009 13:50:44 -0700 > From: Patrick W. Gilmore > To: North American Operators' Group > Subject: Re: Nanog mentioned on BBC news website > > > > Sent from my iPhone, please excuse any errors. > > > On Jul 23, 2009, at 4:27, Jim Mercer wrote: > >> On Wed, Jul 22, 2009 at 08:44:21PM -0400, Patrick W. Gilmore wrote: >>> My fav part: >>> >>> "That's precisely how packets move around the internet, sometimes in a >>> many as 25 or 30 hops with the intervening entities passing the data >>> around having no contractual or legal obligation to the original >>> sender or to the receiver." >>> >>> How many of you pass packets without getting paid? >> in the case of intervening entities, it is true that they have no link to >> the sender or receiver. my packets from office to home can traverse at 3 >> or more networks that are not paid by me, or my company. >> they likely have contracts or obligations with their immediate neighbours, >> which is basically why the system continues to work. > > I honestly expected someone to mention this when I wrote the original post, > but I had hopes no one would. :-) > > It is clear the intent of the TED speaker was the intermediaries were > transiting packets out of the good of their hearts. > > Allow me to illustrate: > > The postal system is amazing! You can mail a letter from the US to England > and the "intermediate" carrier will deliver the mail even though they have NO > contract with you or the recipient! How awesome is that? > > This is not fantasy. You give it to the USPS, who will hand it to DHL, who > will hand it to Royal Mail, who will hand it to the recipient. Does _anyone_ > comment on the lack of your contract with DHL? Is anyone surprised it still > works? Is it worthy of a TED talk? > > -- > TTFN, > patrick > > > > ---------- Forwarded message ---------- > Date: Fri, 24 Jul 2009 07:27:30 +0300 > From: Raymond Macharia > To: nanog at nanog.org > Subject: Re: Nanog mentioned on BBC news website > > Hi > To summarize the article "Nanogers you do a great job" > On the rest we can safely say we are probably more clueful as to what > goes on and we can try as much to correct but I doubt anyone will want > to put all the gory details in any form of press > > Raymond > > On 7/22/09, andrew.wallace wrote: >> Big up the Nanog community, you do the net proud... >> >> http://news.bbc.co.uk/1/hi/technology/8163190.stm > > -- > Sent from my mobile device > > Raymond Macharia From ka at pacific.net Fri Jul 24 11:18:31 2009 From: ka at pacific.net (Ken A.) Date: Fri, 24 Jul 2009 09:18:31 -0700 Subject: questionable email filtering policies? In-Reply-To: <823a8m2oak.fsf@mid.bfk.de> References: <823a8m2oak.fsf@mid.bfk.de> Message-ID: <4A69DED7.8070904@pacific.net> On 07/24/2009 06:39 AM, Florian Weimer wrote: > * Chris Hills: > >> On the topic of mail rejection I have come across a few sites that >> reject mail, even to postmaster@, from domains that have one or more >> ipv6-only MX records listed (i.e. a domain name with AAAA but no A >> record(s)). The common factor seems to be mimedefang. > > Plain sendmail has got a similar issue, especially if the best MX is > IPv6-only. I learnt that the hard way---and it speaks for the quality > of IPv6 testing that the "IPv6 considerations for SMTP" RFC (forgot > its number) doesn't even come close to mentioning this issue, > preferring to talk about bizarre reachability concerns. 8-P > Is it an antispam test that fails in sendmail, or does delivery fail after the first MX lookup is 'unexpected' (yikes)? As a small ISP that runs our own mail for the most part, I'm curious if there are any lists out there of antispam tools that have been tested in a functional ipv6 environment. By antispam tools, I mean things like mimedefang, snertsoft's milters, mailscanner, spamassassin (and dns perl modules), and other 3rd party milters or filters that might be less well known, but that do dns tests, or sanity tests of some kind (milter-dnsrbl, milter-regex, etc). Thanks, Ken -- Ken Anderson Pacific.Net From cscora at apnic.net Fri Jul 24 13:12:17 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 25 Jul 2009 04:12:17 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200907241812.n6OICHSM016607@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 25 Jul, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 292250 Prefixes after maximum aggregation: 138369 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 145253 Total ASes present in the Internet Routing Table: 31825 Prefixes per ASN: 9.18 Origin-only ASes present in the Internet Routing Table: 27671 Origin ASes announcing only one prefix: 13487 Transit ASes present in the Internet Routing Table: 4154 Transit-only ASes present in the Internet Routing Table: 101 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 39 Max AS path prepend of ASN (22394) 36 Prefixes from unregistered ASNs in the Routing Table: 434 Unregistered ASNs in the Routing Table: 127 Number of 32-bit ASNs allocated by the RIRs: 213 Prefixes from 32-bit ASNs in the Routing Table: 76 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 342 Number of addresses announced to Internet: 2061480576 Equivalent to 122 /8s, 223 /16s and 178 /24s Percentage of available address space announced: 55.6 Percentage of allocated address space announced: 64.4 Percentage of available address space allocated: 86.4 Percentage of address space in use by end-sites: 78.4 Total number of prefixes smaller than registry allocations: 144712 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 69858 Total APNIC prefixes after maximum aggregation: 24855 APNIC Deaggregation factor: 2.81 Prefixes being announced from the APNIC address blocks: 69293 Unique aggregates announced from the APNIC address blocks: 31631 APNIC Region origin ASes present in the Internet Routing Table: 3715 APNIC Prefixes per ASN: 18.65 APNIC Region origin ASes announcing only one prefix: 1012 APNIC Region transit ASes present in the Internet Routing Table: 576 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 473972672 Equivalent to 28 /8s, 64 /16s and 63 /24s Percentage of available APNIC address space announced: 88.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 180/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 124246 Total ARIN prefixes after maximum aggregation: 66104 ARIN Deaggregation factor: 1.88 Prefixes being announced from the ARIN address blocks: 124900 Unique aggregates announced from the ARIN address blocks: 52323 ARIN Region origin ASes present in the Internet Routing Table: 13128 ARIN Prefixes per ASN: 9.51 ARIN Region origin ASes announcing only one prefix: 5058 ARIN Region transit ASes present in the Internet Routing Table: 1289 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 39 Number of ARIN addresses announced to Internet: 995143360 Equivalent to 59 /8s, 80 /16s and 174 /24s Percentage of available ARIN address space announced: 191.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 66929 Total RIPE prefixes after maximum aggregation: 39578 RIPE Deaggregation factor: 1.69 Prefixes being announced from the RIPE address blocks: 66512 Unique aggregates announced from the RIPE address blocks: 44870 RIPE Region origin ASes present in the Internet Routing Table: 13327 RIPE Prefixes per ASN: 4.99 RIPE Region origin ASes announcing only one prefix: 6965 RIPE Region transit ASes present in the Internet Routing Table: 1987 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 497559744 Equivalent to 29 /8s, 168 /16s and 40 /24s Percentage of available RIPE address space announced: 98.9 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223 RIPE Address Blocks 25/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 24706 Total LACNIC prefixes after maximum aggregation: 6074 LACNIC Deaggregation factor: 4.07 Prefixes being announced from the LACNIC address blocks: 24652 Unique aggregates announced from the LACNIC address blocks: 13642 LACNIC Region origin ASes present in the Internet Routing Table: 1146 LACNIC Prefixes per ASN: 21.51 LACNIC Region origin ASes announcing only one prefix: 365 LACNIC Region transit ASes present in the Internet Routing Table: 192 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 19 Number of LACNIC addresses announced to Internet: 72665344 Equivalent to 4 /8s, 84 /16s and 201 /24s Percentage of available LACNIC address space announced: 72.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 6131 Total AfriNIC prefixes after maximum aggregation: 1475 AfriNIC Deaggregation factor: 4.16 Prefixes being announced from the AfriNIC address blocks: 6538 Unique aggregates announced from the AfriNIC address blocks: 2506 AfriNIC Region origin ASes present in the Internet Routing Table: 302 AfriNIC Prefixes per ASN: 21.65 AfriNIC Region origin ASes announcing only one prefix: 87 AfriNIC Region transit ASes present in the Internet Routing Table: 64 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 20171264 Equivalent to 1 /8s, 51 /16s and 202 /24s Percentage of available AfriNIC address space announced: 60.1 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1704 6934 409 Korea Telecom (KIX) 17488 1543 137 103 Hathway IP Over Cable Interne 4755 1221 292 145 TATA Communications formerly 9583 1111 86 548 Sify Limited 4134 972 17321 375 CHINANET-BACKBONE 7545 812 198 101 TPG Internet Pty Ltd 23577 786 34 667 Korea Telecom (ATM-MPLS) 9829 782 611 14 BSNL National Internet Backbo 18101 750 201 32 Reliance Infocom Ltd Internet 24560 731 247 170 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4241 3643 324 bellsouth.net, inc. 4323 1899 1050 386 Time Warner Telecom 1785 1713 714 139 PaeTec Communications, Inc. 7018 1511 5907 1047 AT&T WorldNet Services 20115 1423 1461 678 Charter Communications 2386 1272 670 924 AT&T Data Communications Serv 6478 1242 275 315 AT&T Worldnet Services 3356 1190 10960 441 Level 3 Communications, LLC 11492 1128 208 12 Cable One 22773 1077 2604 66 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 30890 481 91 195 Evolva Telecom 12479 475 578 6 Uni2 Autonomous System 3292 459 1903 394 TDC Tele Danmark 702 430 1861 346 UUNET - Commercial IP service 9198 360 138 12 Kazakhtelecom Data Network Ad 3320 352 7082 305 Deutsche Telekom AG 3301 349 1684 311 TeliaNet Sweden 3215 343 3065 108 France Telecom Transpac 8866 333 109 20 Bulgarian Telecommunication C 8551 306 290 38 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1489 2888 241 UniNet S.A. de C.V. 10620 938 218 114 TVCABLE BOGOTA 28573 651 581 36 NET Servicos de Comunicao S.A 7303 596 316 92 Telecom Argentina Stet-France 22047 543 302 14 VTR PUNTO NET S.A. 11830 488 309 56 Instituto Costarricense de El 11172 443 99 69 Servicios Alestra S.A de C.V 6471 434 96 31 ENTEL CHILE S.A. 7738 410 858 29 Telecomunicacoes da Bahia S.A 3816 382 188 78 Empresa Nacional de Telecomun Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1026 188 7 TEDATA 24863 903 90 48 LINKdotNET AS number 20858 323 34 5 EgyNet 3741 277 856 237 The Internet Solution 2018 244 215 143 Tertiary Education Network 6713 175 166 16 Itissalat Al-MAGHRIB 33783 152 10 8 EEPAD TISP TELECOM & INTERNET 29571 139 15 8 Ci Telecom Autonomous system 24835 129 46 9 RAYA Telecom - Egypt 5536 123 8 9 Internet Egypt Network Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4241 3643 324 bellsouth.net, inc. 4323 1899 1050 386 Time Warner Telecom 1785 1713 714 139 PaeTec Communications, Inc. 4766 1704 6934 409 Korea Telecom (KIX) 17488 1543 137 103 Hathway IP Over Cable Interne 7018 1511 5907 1047 AT&T WorldNet Services 8151 1489 2888 241 UniNet S.A. de C.V. 20115 1423 1461 678 Charter Communications 2386 1272 670 924 AT&T Data Communications Serv 6478 1242 275 315 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 1785 1713 1574 PaeTec Communications, Inc. 4323 1899 1513 Time Warner Telecom 17488 1543 1440 Hathway IP Over Cable Interne 4766 1704 1295 Korea Telecom (KIX) 8151 1489 1248 UniNet S.A. de C.V. 11492 1128 1116 Cable One 4755 1221 1076 TATA Communications formerly 18566 1062 1052 Covad Communications 8452 1026 1019 TEDATA 22773 1077 1011 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.112.0/22 5713 Telkom SA Ltd 41.223.176.0/22 36981 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.251.0/24 22555 Universal Talkware Corporatio 64.31.32.0/19 11955 ServiceCo LLC - Road Runner Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:18 /9:10 /10:24 /11:58 /12:169 /13:350 /14:613 /15:1170 /16:10543 /17:4767 /18:8242 /19:17172 /20:20526 /21:20395 /22:26268 /23:26180 /24:153024 /25:933 /26:1035 /27:570 /28:159 /29:8 /30:7 /31:1 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2752 4241 bellsouth.net, inc. 4766 1402 1704 Korea Telecom (KIX) 17488 1290 1543 Hathway IP Over Cable Interne 1785 1183 1713 PaeTec Communications, Inc. 11492 1054 1128 Cable One 18566 1043 1062 Covad Communications 2386 989 1272 AT&T Data Communications Serv 9583 964 1111 Sify Limited 4323 963 1899 Time Warner Telecom 8452 948 1026 TEDATA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:14 8:209 12:2145 13:7 15:19 16:3 17:5 20:36 24:1100 32:52 34:2 38:577 40:98 41:1749 43:1 44:2 47:22 52:6 55:2 56:2 57:24 58:596 59:649 60:461 61:1078 62:1106 63:2037 64:3711 65:2401 66:3582 67:1663 68:861 69:2640 70:552 71:154 72:1651 73:2 74:1636 75:175 76:348 77:849 78:580 79:359 80:974 81:840 82:585 83:451 84:624 85:1060 86:369 87:678 88:363 89:1468 90:50 91:2415 92:377 93:1069 94:1068 95:1122 96:155 97:225 98:250 99:27 110:176 111:348 112:113 113:144 114:254 115:330 116:1123 117:534 118:355 119:734 120:147 121:783 122:1059 123:704 124:974 125:1374 128:225 129:232 130:128 131:414 132:74 133:9 134:186 135:40 136:225 137:165 138:167 139:81 140:449 141:121 142:383 143:354 144:359 145:48 146:387 147:155 148:517 149:223 150:175 151:193 152:145 153:147 154:2 155:275 156:167 157:301 158:118 159:342 160:289 161:156 162:274 163:164 164:475 165:520 166:467 167:361 168:708 169:171 170:479 171:41 172:10 173:315 174:258 178:1 186:107 187:146 188:354 189:537 190:2914 192:5783 193:4270 194:3313 195:2692 196:1123 198:3647 199:3369 200:5140 201:1282 202:7716 203:8324 204:3903 205:2159 206:2447 207:2746 208:3895 209:3436 210:2539 211:1123 212:1666 213:1631 214:82 215:29 216:4540 217:1365 218:402 219:451 220:1107 221:475 222:327 End of report From gosand1982 at yahoo.com Fri Jul 24 15:23:35 2009 From: gosand1982 at yahoo.com (George Sanders) Date: Fri, 24 Jul 2009 13:23:35 -0700 (PDT) Subject: Recommendations for Hong Kong datacenter, and a sanity check for my geopolitical conclusions ? Message-ID: <834941.40938.qm@web111612.mail.gq1.yahoo.com> I will be expanding a small network infrastructure service (read: DNS and mail ... a few 1u and 2u servers) to Hong Kong next year. We don't have any particular customer base in Hong Kong - rather, we have customers all over southeast asia and would like to serve them better, as well as attract more SE Asia customers. I chose Hong Kong for the following reasons: - South Korea is alternately happy with / upset with Japan, and I don't want to deal with that - Japan is is alternately happy with / upset with South Korea, and I don't want to deal with that - Mainland China is out of the question, for obvious reasons - The smaller (Thailand, Vietnamese, Phillipines, etc.) countries all have their own particular issues (recent coup in Thailand, etc.) So the choice came down to Hong Kong or Singapore, and I chose Hong Kong because it seems easier to "just get things done" there. I realize that in the long term there is a greater risk of social paradigm shift in Hong Kong because of mainland China, but in the short run it seems that Hong Kong is more "functional" than Singapore. Any comments on the above thought process ? The obvious follow-up is, which datacenter ? I need a full service center that will give me rackspace and let me just plug ethernet into their switch. I am not interested in brokering my own connectivity, nor am I interested in running my own routers. I want to pay one bill to one organization and get one cable. The end. I think there are further considerations though ... I read details of one very modern, very sexy datacenter housed in a skyscraper, but my research showed me that this building has been built on land reclaimed from the sea, and there is reasonable concern that the sand underpinnings could liquify, to a degree, in a seismic event. I'd also like to be more than a few feet above sea level. Honestly, as sexy as it would be to be in a slick tower right on the bay in Central Hong Kong, I would much rather find some nondescript, one story building, miles from the coast and a few hundred feet above sea level. What recommendations might someone have ? Thank you very much for any comments or suggestions you may have. From copraphage at gmail.com Fri Jul 24 15:30:52 2009 From: copraphage at gmail.com (Chris McDonald) Date: Fri, 24 Jul 2009 16:30:52 -0400 Subject: Recommendations for Hong Kong datacenter, and a sanity check for my geopolitical conclusions ? In-Reply-To: <834941.40938.qm@web111612.mail.gq1.yahoo.com> References: <834941.40938.qm@web111612.mail.gq1.yahoo.com> Message-ID: <25dbbe250907241330j10c3ba6akb0f376967be13286@mail.gmail.com> Making every effort to not pimp my employer (pccw), I would say that the Equinix in HK is good and they have a decent equinix direct product (one bill to pay). If you're looking more for a "managed colo", pccw owns powerbase which does that sort of thing. HKCOLO is good but space is hard to come by. On 7/24/09, George Sanders wrote: > > > I will be expanding a small network infrastructure service (read: DNS and > mail ... a few 1u and 2u servers) to Hong Kong next year. > > We don't have any particular customer base in Hong Kong - rather, we have > customers all over southeast asia and would like to serve them better, as > well as attract more SE Asia customers. > > I chose Hong Kong for the following reasons: > > - South Korea is alternately happy with / upset with Japan, and I don't want > to deal with that > > - Japan is is alternately happy with / upset with South Korea, and I don't > want to deal with that > > - Mainland China is out of the question, for obvious reasons > > - The smaller (Thailand, Vietnamese, Phillipines, etc.) countries all have > their own particular issues (recent coup in Thailand, etc.) > > So the choice came down to Hong Kong or Singapore, and I chose Hong Kong > because it seems easier to "just get things done" there. I realize that in > the long term there is a greater risk of social paradigm shift in Hong Kong > because of mainland China, but in the short run it seems that Hong Kong is > more "functional" than Singapore. > > Any comments on the above thought process ? > > > The obvious follow-up is, which datacenter ? > > I need a full service center that will give me rackspace and let me just > plug ethernet into their switch. I am not interested in brokering my own > connectivity, nor am I interested in running my own routers. I want to pay > one bill to one organization and get one cable. The end. > > I think there are further considerations though ... I read details of one > very modern, very sexy datacenter housed in a skyscraper, but my research > showed me that this building has been built on land reclaimed from the sea, > and there is reasonable concern that the sand underpinnings could liquify, > to a degree, in a seismic event. I'd also like to be more than a few feet > above sea level. Honestly, as sexy as it would be to be in a slick tower > right on the bay in Central Hong Kong, I would much rather find some > nondescript, one story building, miles from the coast and a few hundred feet > above sea level. > > What recommendations might someone have ? > > Thank you very much for any comments or suggestions you may have. > > > > -- Sent from Gmail for mobile | mobile.google.com From bbillon-ml at splio.fr Fri Jul 24 15:46:24 2009 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Fri, 24 Jul 2009 22:46:24 +0200 Subject: Recommendations for Hong Kong datacenter, and a sanity check for my geopolitical conclusions ? In-Reply-To: <834941.40938.qm@web111612.mail.gq1.yahoo.com> References: <834941.40938.qm@web111612.mail.gq1.yahoo.com> Message-ID: <4A6A1DA0.7030402@splio.fr> The process is good, I did the same excepted I also potentially needed good Mainland China connectivity (what are the obvious reasons?), otherway I think would have take the Singapore option. Getting things done there is not a problem either. I choose the Mega iAdvantage datacenters in HK. Benjamin George Sanders a ?crit : > I will be expanding a small network infrastructure service (read: DNS and mail ... a few 1u and 2u servers) to Hong Kong next year. > > We don't have any particular customer base in Hong Kong - rather, we have customers all over southeast asia and would like to serve them better, as well as attract more SE Asia customers. > > I chose Hong Kong for the following reasons: > > - South Korea is alternately happy with / upset with Japan, and I don't want to deal with that > > - Japan is is alternately happy with / upset with South Korea, and I don't want to deal with that > > - Mainland China is out of the question, for obvious reasons > > - The smaller (Thailand, Vietnamese, Phillipines, etc.) countries all have their own particular issues (recent coup in Thailand, etc.) > > So the choice came down to Hong Kong or Singapore, and I chose Hong Kong because it seems easier to "just get things done" there. I realize that in the long term there is a greater risk of social paradigm shift in Hong Kong because of mainland China, but in the short run it seems that Hong Kong is more "functional" than Singapore. > > Any comments on the above thought process ? > > > The obvious follow-up is, which datacenter ? > > I need a full service center that will give me rackspace and let me just plug ethernet into their switch. I am not interested in brokering my own connectivity, nor am I interested in running my own routers. I want to pay one bill to one organization and get one cable. The end. > > I think there are further considerations though ... I read details of one very modern, very sexy datacenter housed in a skyscraper, but my research showed me that this building has been built on land reclaimed from the sea, and there is reasonable concern that the sand underpinnings could liquify, to a degree, in a seismic event. I'd also like to be more than a few feet above sea level. Honestly, as sexy as it would be to be in a slick tower right on the bay in Central Hong Kong, I would much rather find some nondescript, one story building, miles from the coast and a few hundred feet above sea level. > > What recommendations might someone have ? > > Thank you very much for any comments or suggestions you may have. > > > > From andrew at parnell.ca Fri Jul 24 15:50:08 2009 From: andrew at parnell.ca (Andrew Parnell) Date: Fri, 24 Jul 2009 16:50:08 -0400 Subject: Recommendations for Hong Kong datacenter, and a sanity check for my geopolitical conclusions ? In-Reply-To: <25dbbe250907241330j10c3ba6akb0f376967be13286@mail.gmail.com> References: <834941.40938.qm@web111612.mail.gq1.yahoo.com> <25dbbe250907241330j10c3ba6akb0f376967be13286@mail.gmail.com> Message-ID: <2d54a02d0907241350o5583b33by57da06cf7a73fd21@mail.gmail.com> We recently moved out of Hutchinson (HGC), which was a pretty poor experience overall. We moved to a fairly new NTT site, which is miles away from anywhere (Tai Po). The experience there has been pretty much the exact opposite. They tend to be quite anal about policy and procedure, which can be a tad annoying, but overall I'll take that over the previously abysmal experience :) On Fri, Jul 24, 2009 at 4:30 PM, Chris McDonald wrote: > Making every effort to not pimp my employer (pccw), I would say that > the Equinix in HK is good and they have a decent equinix direct > product (one bill to pay). If you're looking more for a "managed > colo", pccw owns powerbase which does that sort of thing. HKCOLO is > good but space is hard to come by. > > > > > > > > On 7/24/09, George Sanders wrote: > > > > > > I will be expanding a small network infrastructure service (read: DNS and > > mail ... a few 1u and 2u servers) to Hong Kong next year. > > > > We don't have any particular customer base in Hong Kong - rather, we have > > customers all over southeast asia and would like to serve them better, as > > well as attract more SE Asia customers. > > > > I chose Hong Kong for the following reasons: > > > > - South Korea is alternately happy with / upset with Japan, and I don't > want > > to deal with that > > > > - Japan is is alternately happy with / upset with South Korea, and I > don't > > want to deal with that > > > > - Mainland China is out of the question, for obvious reasons > > > > - The smaller (Thailand, Vietnamese, Phillipines, etc.) countries all > have > > their own particular issues (recent coup in Thailand, etc.) > > > > So the choice came down to Hong Kong or Singapore, and I chose Hong Kong > > because it seems easier to "just get things done" there. I realize that > in > > the long term there is a greater risk of social paradigm shift in Hong > Kong > > because of mainland China, but in the short run it seems that Hong Kong > is > > more "functional" than Singapore. > > > > Any comments on the above thought process ? > > > > > > The obvious follow-up is, which datacenter ? > > > > I need a full service center that will give me rackspace and let me just > > plug ethernet into their switch. I am not interested in brokering my own > > connectivity, nor am I interested in running my own routers. I want to > pay > > one bill to one organization and get one cable. The end. > > > > I think there are further considerations though ... I read details of one > > very modern, very sexy datacenter housed in a skyscraper, but my research > > showed me that this building has been built on land reclaimed from the > sea, > > and there is reasonable concern that the sand underpinnings could > liquify, > > to a degree, in a seismic event. I'd also like to be more than a few > feet > > above sea level. Honestly, as sexy as it would be to be in a slick tower > > right on the bay in Central Hong Kong, I would much rather find some > > nondescript, one story building, miles from the coast and a few hundred > feet > > above sea level. > > > > What recommendations might someone have ? > > > > Thank you very much for any comments or suggestions you may have. > > > > > > > > > > -- > Sent from Gmail for mobile | mobile.google.com > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > From Jay.Murphy at state.nm.us Fri Jul 24 15:56:37 2009 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Fri, 24 Jul 2009 14:56:37 -0600 Subject: Recommendations for Hong Kong datacenter, and a sanity check for my geopolitical conclusions ? In-Reply-To: <834941.40938.qm@web111612.mail.gq1.yahoo.com> References: <834941.40938.qm@web111612.mail.gq1.yahoo.com> Message-ID: George, As a previous thread had stated I would opt for Singapore as well. 1) The country is more technology driven. They speak good english, and the country is beautiful too, without the uncertain future. Jay Murphy "We move the information that moves your world." ? Please consider the environment before printing e-mail -----Original Message----- From: George Sanders [mailto:gosand1982 at yahoo.com] Sent: Friday, July 24, 2009 2:24 PM To: nanog at nanog.org Subject: Recommendations for Hong Kong datacenter,and a sanity check for my geopolitical conclusions ? I will be expanding a small network infrastructure service (read: DNS and mail ... a few 1u and 2u servers) to Hong Kong next year. We don't have any particular customer base in Hong Kong - rather, we have customers all over southeast asia and would like to serve them better, as well as attract more SE Asia customers. I chose Hong Kong for the following reasons: - South Korea is alternately happy with / upset with Japan, and I don't want to deal with that - Japan is is alternately happy with / upset with South Korea, and I don't want to deal with that - Mainland China is out of the question, for obvious reasons - The smaller (Thailand, Vietnamese, Phillipines, etc.) countries all have their own particular issues (recent coup in Thailand, etc.) So the choice came down to Hong Kong or Singapore, and I chose Hong Kong because it seems easier to "just get things done" there. I realize that in the long term there is a greater risk of social paradigm shift in Hong Kong because of mainland China, but in the short run it seems that Hong Kong is more "functional" than Singapore. Any comments on the above thought process ? The obvious follow-up is, which datacenter ? I need a full service center that will give me rackspace and let me just plug ethernet into their switch. I am not interested in brokering my own connectivity, nor am I interested in running my own routers. I want to pay one bill to one organization and get one cable. The end. I think there are further considerations though ... I read details of one very modern, very sexy datacenter housed in a skyscraper, but my research showed me that this building has been built on land reclaimed from the sea, and there is reasonable concern that the sand underpinnings could liquify, to a degree, in a seismic event. I'd also like to be more than a few feet above sea level. Honestly, as sexy as it would be to be in a slick tower right on the bay in Central Hong Kong, I would much rather find some nondescript, one story building, miles from the coast and a few hundred feet above sea level. What recommendations might someone have ? Thank you very much for any comments or suggestions you may have. ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. Confidentiality Notice: This e-mail,including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review,use,disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the MessageLabs Email Security System. From gosand1982 at yahoo.com Fri Jul 24 16:04:59 2009 From: gosand1982 at yahoo.com (George Sanders) Date: Fri, 24 Jul 2009 14:04:59 -0700 (PDT) Subject: Recommendations for Hong Kong datacenter, and a sanity check for my geopolitical conclusions ? In-Reply-To: <4A6A1DA0.7030402@splio.fr> References: <834941.40938.qm@web111612.mail.gq1.yahoo.com> <4A6A1DA0.7030402@splio.fr> Message-ID: <788775.25888.qm@web111602.mail.gq1.yahoo.com> ________________________________ From: Benjamin Billon To: nanog at nanog.org Sent: Friday, July 24, 2009 3:46:24 PM Subject: Re: Recommendations for Hong Kong datacenter, and a sanity check for my geopolitical conclusions ? The process is good, I did the same excepted I also potentially needed good Mainland China connectivity (what are the obvious reasons?), otherway I think would have take the Singapore option. Getting things done there is not a problem either. I choose the Mega iAdvantage datacenters in HK. Yes, thank you - that was the datacenter I had read about in my own research. What did you think of the height of that building and its location on reclaimed sea land ? It makes me nervous, but as I said in a different message in this thread, it looks like ALL of urban HK is reclaimed so ... who knows. I was saying that I did not want the servers _inside of_ China, for obvious reasons. Although the actual geography of shenzhen makes it much more appealing, even though we want greater freedom RE: content/filtering/freedom of speech/etc. (if only for principles sake). Thanks for your comments. From bbillon-ml at splio.fr Fri Jul 24 16:53:48 2009 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Fri, 24 Jul 2009 23:53:48 +0200 Subject: Recommendations for Hong Kong datacenter, and a sanity check for my geopolitical conclusions ? In-Reply-To: <788775.25888.qm@web111602.mail.gq1.yahoo.com> References: <834941.40938.qm@web111612.mail.gq1.yahoo.com> <4A6A1DA0.7030402@splio.fr> <788775.25888.qm@web111602.mail.gq1.yahoo.com> Message-ID: <4A6A2D6C.80505@splio.fr> I'd say it depends, as always. Mostly of what your business is about. If you're a bank, you got to take many care about your datacenter(s) locations, but you'll have the money for it anyway. Same for health services and so on. Here is a short story: when I had to choose for my first datacenter location, I checked if there was two distinct power lines, enough UPS capacity, no potential problem with water floods, etc. Then I thought: who am I to care that much? If there is a terrorist attack in my DC and everything blows up, who will care? One big part of the local and international Internet will be down and injured, I'm not ashamed to say my business won't take that much damages after all. Still, if you're hosting critical data (and any business does), go for remote backups, even cheap ones. One dedicated server in another city / country with enough encryption (VPN / disk encryption) could do the trick. Again, if the Mega iAdvantage building falls down to the sea, what will the whole island look like? Who's gonna care about the Internet at that time? About mainland China, there are very nice datacenters in Beijing and Shanghai, even if in my opinion they're still lacking of sufficient services (even if Shanghai's are usually better). Then again it depends what's your business is about. If you're trying to reach Chinese people, you'll have to deal with mainland China administration guys anyway! George Sanders a ?crit : > > > Yes, thank you - that was the datacenter I had read about in my own > research. What did you think of the height of that building and its > location on reclaimed sea land ? It makes me nervous, but as I said in > a different message in this thread, it looks like ALL of urban HK is > reclaimed so ... who knows. > > I was saying that I did not want the servers _inside of_ China, for > obvious reasons. Although the actual geography of shenzhen makes it > much more appealing, even though we want greater freedom RE: > content/filtering/freedom of speech/etc. (if only for principles sake).. > > Thanks for your comments. > From cidr-report at potaroo.net Fri Jul 24 17:00:01 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 24 Jul 2009 22:00:01 GMT Subject: BGP Update Report Message-ID: <200907242200.n6OM01va026330@wattle.apnic.net> BGP Update Report Interval: 16-Jul-09 -to- 23-Jul-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9198 95713 6.0% 265.9 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - AS17488 25218 1.6% 16.3 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 3 - AS8452 25189 1.6% 23.4 -- TEDATA TEDATA 4 - AS1659 20553 1.3% 61.2 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center 5 - AS4755 19486 1.2% 15.6 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 6 - AS47408 14496 0.9% 690.3 -- MANDARIN-AS Mandarin WIMAX Sicilia SpA 7 - AS17908 12224 0.8% 17.2 -- TCISL Tata Communications 8 - AS21491 12090 0.8% 403.0 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 9 - AS9829 11492 0.7% 14.4 -- BSNL-NIB National Internet Backbone 10 - AS33783 11449 0.7% 74.3 -- EEPAD 11 - AS29049 10615 0.7% 34.4 -- DELTA-TELECOM-AS Delta Telecom LTD. 12 - AS8151 9684 0.6% 6.5 -- Uninet S.A. de C.V. 13 - AS6389 9683 0.6% 2.3 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 14 - AS10620 8875 0.6% 9.2 -- TV Cable S.A. 15 - AS7738 8834 0.6% 21.5 -- Telecomunicacoes da Bahia S.A. 16 - AS30890 8786 0.6% 18.2 -- EVOLVA Evolva Telecom / iLink Telecom 17 - AS38548 8555 0.5% 503.2 -- INFRATEL-AS-ID-AP Network Access Point 18 - AS4249 7932 0.5% 43.6 -- LILLY-AS - Eli Lilly and Company 19 - AS35805 7838 0.5% 18.8 -- UTG-AS United Telecom AS 20 - AS20115 7250 0.5% 5.1 -- CHARTER-NET-HKY-NC - Charter Communications TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS47408 14496 0.9% 690.3 -- MANDARIN-AS Mandarin WIMAX Sicilia SpA 2 - AS38548 8555 0.5% 503.2 -- INFRATEL-AS-ID-AP Network Access Point 3 - AS28618 476 0.0% 476.0 -- Linktel Telecomunicacoes do Brasil Ltda 4 - AS25546 4408 0.3% 440.8 -- BROOKLANDCOMP-AS Brookland Computer Services 5 - AS4796 432 0.0% 432.0 -- BANDUNG-NET-AS-AP Institute of Technology Bandung 6 - AS47640 1281 0.1% 427.0 -- TRICOMPAS Tricomp Sp. z. o. o. 7 - AS30969 5968 0.4% 426.3 -- TAN-NET TransAfrica Networks 8 - AS21491 12090 0.8% 403.0 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 9 - AS5050 6030 0.4% 376.9 -- PSC-EXT - Pittsburgh Supercomputing Center 10 - AS35400 1846 0.1% 307.7 -- MFIST Interregoinal Organization Network Technologies 11 - AS9198 95713 6.0% 265.9 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 12 - AS42426 264 0.0% 264.0 -- EURIAL-AS SC EURIAL INVEST SA 13 - AS5055 788 0.1% 262.7 -- WANET - Software Design Associates 14 - AS8668 1824 0.1% 260.6 -- TELONE-AS TelOne Zimbabwe P/L 15 - AS24994 510 0.0% 255.0 -- GENESYS-AS GENESYS Informatica AS for announcing own prefixes 16 - AS40060 2262 0.1% 251.3 -- AAAWI - AAA Wireless, Inc. 17 - AS34972 249 0.0% 249.0 -- ROBINAXIS-AS SC BINAXIS SRL 18 - AS41492 247 0.0% 247.0 -- EXIMBANK-AS SC Eximbank SA 19 - AS5313 245 0.0% 245.0 -- DNIC-ASBLK-05120-05376 - DoD Network Information Center 20 - AS41904 968 0.1% 242.0 -- SGAICE-AS JSC Severgazautomatica ICE TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 92.46.244.0/23 10397 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - 89.218.220.0/23 10379 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 3 - 95.59.8.0/23 10377 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 4 - 95.59.2.0/23 10377 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 5 - 95.59.4.0/22 10377 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 6 - 95.59.3.0/24 10376 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 7 - 89.218.218.0/23 10375 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 8 - 88.204.221.0/24 9758 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 9 - 95.59.1.0/24 9741 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 10 - 41.233.92.0/23 8996 0.5% AS8452 -- TEDATA TEDATA 11 - 41.233.94.0/23 8814 0.5% AS8452 -- TEDATA TEDATA 12 - 203.190.47.0/24 8459 0.5% AS38548 -- INFRATEL-AS-ID-AP Network Access Point 13 - 72.23.246.0/24 5945 0.3% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 14 - 193.201.184.0/21 4399 0.3% AS25546 -- BROOKLANDCOMP-AS Brookland Computer Services 15 - 196.27.104.0/21 2894 0.2% AS30969 -- TAN-NET TransAfrica Networks 16 - 196.27.108.0/22 2857 0.2% AS30969 -- TAN-NET TransAfrica Networks 17 - 192.12.120.0/24 2592 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 18 - 85.60.208.0/21 2510 0.1% AS12479 -- UNI2-AS Uni2 Autonomous System 19 - 143.77.216.0/23 2429 0.1% AS747 -- TAEGU-AS - Headquarters, USAISC 20 - 143.77.87.0/24 2306 0.1% AS747 -- TAEGU-AS - Headquarters, USAISC Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 24 17:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 24 Jul 2009 22:00:00 GMT Subject: The Cidr Report Message-ID: <200907242200.n6OM00hC026322@wattle.apnic.net> This report has been generated at Fri Jul 24 21:11:13 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 17-07-09 297646 181238 18-07-09 297821 181428 19-07-09 298028 181360 20-07-09 297961 181282 21-07-09 298280 181670 22-07-09 298046 182478 23-07-09 298944 182557 24-07-09 298785 182918 AS Summary 31943 Number of ASes in routing system 13570 Number of ASes announcing only one prefix 4300 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 89732608 Largest address span announced by an AS (/32s) AS27064: DNIC-ASBLK-27032-27159 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 24Jul09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 299234 182851 116383 38.9% All ASes AS6389 4238 336 3902 92.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4300 1651 2649 61.6% TWTC - tw telecom holdings, inc. AS4766 1809 525 1284 71.0% KIXS-AS-KR Korea Telecom AS17488 1544 319 1225 79.3% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1221 194 1027 84.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1077 70 1007 93.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS1785 1713 751 962 56.2% AS-PAETEC-NET - PaeTec Communications, Inc. AS8151 1490 563 927 62.2% Uninet S.A. de C.V. AS19262 1022 236 786 76.9% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8452 1025 304 721 70.3% TEDATA TEDATA AS18101 750 43 707 94.3% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS3356 1191 509 682 57.3% LEVEL3 Level 3 Communications AS18566 1062 399 663 62.4% COVAD - Covad Communications Co. AS6478 1242 596 646 52.0% ATT-INTERNET3 - AT&T WorldNet Services AS10620 938 307 631 67.3% TV Cable S.A. AS4804 686 70 616 89.8% MPX-AS Microplex PTY LTD AS17908 706 130 576 81.6% TCISL Tata Communications AS24560 731 184 547 74.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS9498 633 103 530 83.7% BBIL-AP BHARTI Airtel Ltd. AS22047 543 14 529 97.4% VTR BANDA ANCHA S.A. AS11492 1128 611 517 45.8% CABLEONE - CABLE ONE, INC. AS4134 972 459 513 52.8% CHINANET-BACKBONE No.31,Jin-rong Street AS7303 597 92 505 84.6% Telecom Argentina S.A. AS855 614 121 493 80.3% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS17676 564 78 486 86.2% GIGAINFRA Softbank BB Corp. AS4808 671 187 484 72.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7018 1513 1048 465 30.7% ATT-INTERNET4 - AT&T WorldNet Services AS9443 531 83 448 84.4% INTERNETPRIMUS-AS-AP Primus Telecommunications AS4780 557 134 423 75.9% SEEDNET Digital United Inc. AS7011 988 570 418 42.3% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. Total 36056 10687 25369 70.4% Top 30 total Possible Bogus Routes 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.112.0/22 AS5713 SAIX-NET 41.223.176.0/22 AS36981 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.31.59.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.31.60.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 100.100.100.0/30 AS38676 AS33005-AS-KR wizsolution co.,Ltd 116.50.0.0/24 AS17754 EXCELL-AS Excellmedia 116.50.1.0/24 AS17754 EXCELL-AS Excellmedia 116.50.2.0/24 AS17754 EXCELL-AS Excellmedia 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.10.0/24 AS38236 121.50.13.0/24 AS38236 121.50.15.0/24 AS17625 BLAZENET-IN-AP BlazeNet's Network 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 158.222.5.0/24 AS21580 DIRCON - Direct Connect 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.132.58.0/24 AS20141 QUALITYTECH-SUW-300 - Quality Technology Services, LLC. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 193.33.148.0/23 AS30890 EVOLVA Evolva Telecom / iLink Telecom 193.104.229.0/26 AS34444 EUTELSAT-BACKBONE-AS EUTELSAT S.A. 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.5.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.19.0.0/24 AS3848 WORLDLINX-2 - WorldLinx Telecommunications, Inc. 199.114.0.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 ITCOMM - IT Communications 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.9.115.0/24 AS10292 CWJ-1 - Cable & Wireless Jamaica 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.84.10.0/23 AS9308 CHINA-ABITCOOL Abitcool(China) Inc. 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS2764 AAPT AAPT Limited 202.124.195.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.125.112.0/24 AS23674 MBL-AS-AP Micronet Broadband (Pvt) Ltd. 202.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.138.167.0/24 AS18990 AIRBAND-DALLAS - Airband Communications, Inc 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.151.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.158.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.177.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.178.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.88.0/21 AS36835 208.77.224.0/24 AS36835 208.77.225.0/24 AS36835 208.77.226.0/24 AS36835 208.77.227.0/24 AS36835 208.77.228.0/24 AS36835 208.77.229.0/24 AS36835 208.77.230.0/24 AS36835 208.77.231.0/24 AS36835 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.217.224.0/19 AS6130 AIS-WEST - American Internet Services, LLC. 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 213.181.70.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.80.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.81.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.82.0/23 AS17175 NSS-UK New Skies Satellites UK AS 213.181.82.0/24 AS17175 NSS-UK New Skies Satellites UK AS 213.181.83.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.84.0/22 AS17175 NSS-UK New Skies Satellites UK AS 213.181.84.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.85.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.86.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.87.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.88.0/21 AS17175 NSS-UK New Skies Satellites UK AS 213.181.88.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.89.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.90.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.91.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.92.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.93.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.94.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.95.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.72.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.73.0/24 AS12491 IPPLANET-AS Gilat Satcom Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From tme at americafree.tv Fri Jul 24 18:25:44 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 24 Jul 2009 19:25:44 -0400 Subject: Nanog mentioned on BBC news website In-Reply-To: References: <20090722234148.BAFA21CC0B@ptavv.es.net> <20090723112726.GB68894@reptiles.org> Message-ID: <1B0E852B-CCD0-4224-B929-213D63F19B1A@americafree.tv> On Jul 23, 2009, at 4:50 PM, Patrick W. Gilmore wrote: > > > Sent from my iPhone, please excuse any errors. > > > On Jul 23, 2009, at 4:27, Jim Mercer wrote: > >> On Wed, Jul 22, 2009 at 08:44:21PM -0400, Patrick W. Gilmore wrote: >>> My fav part: >>> >>> "That's precisely how packets move around the internet, sometimes >>> in a >>> many as 25 or 30 hops with the intervening entities passing the data >>> around having no contractual or legal obligation to the original >>> sender or to the receiver." >>> >>> >>> How many of you pass packets without getting paid? >> >> in the case of intervening entities, it is true that they have no >> link to >> the sender or receiver. my packets from office to home can >> traverse at 3 >> or more networks that are not paid by me, or my company. >> >> they likely have contracts or obligations with their immediate >> neighbours, >> which is basically why the system continues to work. > > I honestly expected someone to mention this when I wrote the > original post, but I had hopes no one would. :-) > > It is clear the intent of the TED speaker was the intermediaries > were transiting packets out of the good of their hearts. > > Allow me to illustrate: > > The postal system is amazing! You can mail a letter from the US to > England and the "intermediate" carrier will deliver the mail even > though they have NO contract with you or the recipient! How awesome > is that? > > This is not fantasy. You give it to the USPS, who will hand it to > DHL, who will hand it to Royal Mail, who will hand it to the > recipient. Does _anyone_ comment on the lack of your contract with > DHL? Is anyone surprised it still works? Is it worthy of a TED talk? > You obviously don't understand the executive briefings industry ! Regards Marshall > -- > TTFN, > patrick > > > From llynch at civil-tongue.net Sat Jul 25 08:09:51 2009 From: llynch at civil-tongue.net (Lucy Lynch) Date: Sat, 25 Jul 2009 06:09:51 -0700 (PDT) Subject: Fellowship reminder (fwd) Message-ID: All - Please forward to likely candidates! - Lucy ---------- Forwarded message ---------- Date: Thu, 23 Jul 2009 14:08:47 +0200 Subject: Fellowship reminder ****************************** ONE WEEK LEFT TO APPLY! Dear Colleagues, The Internet Society has announced that it is seeking applications for the next round of the ISOC Fellowship to the IETF program, part of its Future Internet Leaders program (www.isoc.org/leaders). The program offers engineers from developing countries fellowships that fund the cost of attending an Internet Engineering Task Force (IETF) meeting. As you know, the IETF is the Internet's premier standards-making body, responsible for the development of protocols used in IP-based networks. IETF participants represent an international community of network designers, operators, vendors, and researchers involved in the technical operation of the Internet and the continuing evolution of Internet architecture. Fellowships will be awarded through a competitive application process. The Internet Society is currently accepting fellowship applications for the next two IETF meetings: * IETF 76 being held in Hiroshima, Japan, 8-13 November 2009 * IETF 77 being held in Anaheim, USA, 21-26 March 2010 Up to six fellowships will be awarded for each IETF meeting. Full details on the ISOC Fellowship to the IETF, including how to apply, are located on the ISOC website at : http://www.isoc.org/educpillar/fellowship Fellowship applications for both IETF meetings are due by *31 July 2009*. The Internet Society formally launched the ISOC Fellowship to the IETF program in January 2007 after successfully piloting the program during 2006 at IETF 66 in Montreal and IETF 67 in San Diego. Forty seven individuals from 29 countries have participated in the program since its inception. I encourage you to pass information about this program to individuals involved in your regional operators' groups that have a keen interest in the Internet standardisation activities of the IETF. You also may consider being a reference for the applicant. If you have questions, please do not hesiate to contact Connie Kendig or Mirjam Kuehne . Kind Regards, Connie J Kendig ISOC From zartash at gmail.com Sat Jul 25 08:44:15 2009 From: zartash at gmail.com (Zartash Uzmi) Date: Sat, 25 Jul 2009 18:44:15 +0500 Subject: Nanog mentioned on BBC news website In-Reply-To: <3c3e3fca0907231338xf5efadfo75de38314f2f5634@mail.gmail.com> References: <20090722234148.BAFA21CC0B@ptavv.es.net> <20090723112726.GB68894@reptiles.org> <3c3e3fca0907231338xf5efadfo75de38314f2f5634@mail.gmail.com> Message-ID: <4fff97de0907250644l6695dc3bgeb35b69026ba2781@mail.gmail.com> > > >> > >> How many of you pass packets without getting paid? > > > > in the case of intervening entities, it is true that they have no link to > > the sender or receiver. my packets from office to home can traverse at 3 > > or more networks that are not paid by me, or my company. > > If I pay you to send my packets and you pay bob to send my packets > then I have paid bob to send my packets. Transitive property of > payment. ;-) Yes, the transitive property prevails but there are constraints: imagine if Bob were not there to take this "relatively small" payment! Thus if I pay you to send my packets and you pay Bob to send those packets -- then indirectly I have paid Bob an amount which is much less compared to what you would charge me if you had to "build the Bob" yourself -- I am sure you would pass on the costs to me, the end user, especially if there is no such thing as unpaid volunteerism :) The paradox is that the existence of Bob lowers the cost to an end user -- there is some such thing that can be classified as unpaid volunteerism... and yes, being the Bobs, the NANOGers are exhibiting this unpaid volunteerism! > 'Couse bob doesn't pay claire anything but denise pays claire to > receive packets for denise, my packets are intended for denise and bob > and claire have a peering agreement in which they agree to swap > already-paid traffic directly rather than both paying ed to do it for > them. > > So it ain't free and at each step there is a contractual obligation to > at least one of the sender or receiver. > > Regards, > Bill > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > From charles at thewybles.com Sat Jul 25 11:05:12 2009 From: charles at thewybles.com (Charles Wyble) Date: Sat, 25 Jul 2009 09:05:12 -0700 Subject: Recommendations for Hong Kong datacenter, and a sanity check for my geopolitical conclusions ? In-Reply-To: <788775.25888.qm@web111602.mail.gq1.yahoo.com> References: <834941.40938.qm@web111612.mail.gq1.yahoo.com> <4A6A1DA0.7030402@splio.fr> <788775.25888.qm@web111602.mail.gq1.yahoo.com> Message-ID: <4A6B2D38.3030705@thewybles.com> > > > > Yes, thank you - that was the datacenter I had read about in my own research. What did you think of the height of that building and its location on reclaimed sea land ? It makes me nervous, but as I said in a different message in this thread, it looks like ALL of urban HK is reclaimed so ... who knows. Well where does the HK govt put there servers? If they outsource them to a colo, then that might be an interesting place to start. Sinking into the sea seems a remote possibility. I don't know much about Hong Kong. I imagine others on the list might be able to speak to that better. > > I was saying that I did not want the servers _inside of_ China, for obvious reasons. Although the actual geography of shenzhen makes it much more appealing, even though we want greater freedom RE: content/filtering/freedom of speech/etc. (if only for principles sake). Something something govt event, something something shutting down/throttling all connectivity to get there message out. The point is, that placing servers directly in China presents significant operational issues, that a business can understand (hey guess what we can't hit our VPN at random times completely outside our control). It has nothing to do with free speech, and everything to do with continuity of operations. China is.... difficult. I was tangentially related to a China deployment project for a massive e-commerce company. My manager was discussing the project, and I told him I wanted nothing to do with it. Every time my team mate turned around there was another discussion with legal going on. Not to mention EVERYTHING was 100% outsourced. It was pure unbridled hell for everyone involved with the project. From tme at americafree.tv Sat Jul 25 11:18:55 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Sat, 25 Jul 2009 12:18:55 -0400 Subject: Recommendations for Hong Kong datacenter, and a sanity check for my geopolitical conclusions ? In-Reply-To: <4A6B2D38.3030705@thewybles.com> References: <834941.40938.qm@web111612.mail.gq1.yahoo.com> <4A6A1DA0.7030402@splio.fr> <788775.25888.qm@web111602.mail.gq1.yahoo.com> <4A6B2D38.3030705@thewybles.com> Message-ID: On Jul 25, 2009, at 12:05 PM, Charles Wyble wrote: > > >> Yes, thank you - that was the datacenter I had read about in my own >> research. What did you think of the height of that building and >> its location on reclaimed sea land ? It makes me nervous, but as I >> said in a different message in this thread, it looks like ALL of >> urban HK is reclaimed so ... who knows. > > Well where does the HK govt put there servers? If they outsource > them to a colo, then that might be an interesting place to start. > Sinking into the sea seems a remote possibility. Hong Kong is considered to be in a low seismic risk area and is not near a plate boundary. I don't think that there has ever been a major Earthquake recorded there. Past performance of course is no guarantee of future results. See, e.g., http://www.cedd.gov.hk/eng/publications/information_notes/doc/in_2007_05e.pdf Regards Marshall > I don't know much about Hong Kong. I imagine others on the list > might be able to speak to that better. > > >> I was saying that I did not want the servers _inside of_ China, for >> obvious reasons. Although the actual geography of shenzhen makes >> it much more appealing, even though we want greater freedom RE: >> content/filtering/freedom of speech/etc. (if only for principles >> sake). > > Something something govt event, something something shutting down/ > throttling all connectivity to get there message out. > > The point is, that placing servers directly in China presents > significant operational issues, that a business can understand (hey > guess what we can't hit our VPN at random times completely outside > our control). It has nothing to do with free speech, and everything > to do with continuity of operations. > > China is.... difficult. I was tangentially related to a China > deployment project for a massive e-commerce company. My manager was > discussing the project, and I told him I wanted nothing to do with it. > > Every time my team mate turned around there was another discussion > with legal going on. Not to mention EVERYTHING was 100% outsourced. > > It was pure unbridled hell for everyone involved with the project. > > From hank at efes.iucc.ac.il Sat Jul 25 13:46:22 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 25 Jul 2009 21:46:22 +0300 (IDT) Subject: Recommendations for Hong Kong datacenter, and a sanity check for my geopolitical conclusions ? In-Reply-To: <834941.40938.qm@web111612.mail.gq1.yahoo.com> References: <834941.40938.qm@web111612.mail.gq1.yahoo.com> Message-ID: On Fri, 24 Jul 2009, George Sanders wrote: When comparing, I would think you need to compare HKIX vs SOX and see which IX gives you better overall peering and connectivity for that area. -Hank > I will be expanding a small network infrastructure service (read: DNS and mail ... a few 1u and 2u servers) to Hong Kong next year. We don't have any particular customer base in Hong Kong - rather, we have customers all over southeast asia and would like to serve them better, as well as attract more SE Asia customers. I chose Hong Kong for the following reasons: - South Korea is alternately happy with / upset with Japan, and I don't want to deal with that - Japan is is alternately happy with / upset with South Korea, and I don't want to deal with that - Mainland China is out of the question, for obvious reasons - The smaller (Thailand, Vietnamese, Phillipines, etc.) countries all have their own particular issues (recent coup in Thailand, etc.) So the choice came down to Hong Kong or Singapore, and I chose Hong Kong because it seems easier to "just get things done" there. I realize that in the long term there is a greater risk of social paradigm shift in Hong Kong because of mainland China, but in the short run it seems that Hong Kong is more "functional" than Singapore. Any comments on the above thought process ? The obvious follow-up is, which datacenter ? I need a full service center that will give me rackspace and let me just plug ethernet into their switch. I am not interested in brokering my own connectivity, nor am I interested in running my own routers. I want to pay one bill to one organization and get one cable. The end. I think there are further considerations though ... I read details of one very modern, very sexy datacenter housed in a skyscraper, but my research showed me that this building has been built on land reclaimed from the sea, and there is reasonable concern that the sand underpinnings could liquify, to a degree, in a seismic event. I'd also like to be more than a few feet above sea level. Honestly, as sexy as it would be to be in a slick tower right on the bay in Central Hong Kong, I would much rather find some nondescript, one story building, miles from the coast and a few hundred feet above sea level. What recommendations might someone have ? Thank you very much for any comments or suggestions you may have. > From jtk at cymru.com Sun Jul 26 08:20:27 2009 From: jtk at cymru.com (John Kristoff) Date: Sun, 26 Jul 2009 08:20:27 -0500 Subject: What is the most standard subnet length on internet In-Reply-To: <4A65665C.1040207@globaltransit.net> References: <10068989.128811229991024019.JavaMail.weblogic@epml06> <4A65665C.1040207@globaltransit.net> Message-ID: <20090726082027.2c6e80e1@t61p> On Tue, 21 Jul 2009 14:55:24 +0800 Kanagaraj wrote: > Basically /24s are the longest prefix size accepted by providers > unless you are dealing RTBH (triggered blackholing services). Another > requirement to ensure acceptance of an IP block, especially smaller > assignments are equivalent route objects matching it (in most cases > your provider will do it on your behalf). Randy Bush et al. have something interesting to say that challenges this conventional wisdom or at least clarifies it. See here for some detail: In part they show that the use of default routing might be much more pervasive than people realize based on data plane measurements they take (as opposed to control plane measurements). They observe that while a /25 does does not have the same reachability as a larger prefix, it might still be reachable by a surprising number of ASes. John From j at arpa.com Sun Jul 26 20:48:06 2009 From: j at arpa.com (jamie) Date: Sun, 26 Jul 2009 20:48:06 -0500 Subject: AT&T. Layer 6-8 needed. Message-ID: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> All, It appears at AT&T (including DSL, and my own home service via u-verse) has unilaterally and without explanation started blocking websites. I have confirmed this with multiple tests. (It actually appears that these sites are being blocked at a local-global scale -- that is, each city/hub seems to have blackholes for the sites). The sites I know of I'll list below (see Reddit for a discussion), but this is clearly and absolutely unacceptable. Please, comments on the nature of the sites are OT.. Let's keep this thread that way. (Away from being OT, that is). If any T folk are around, and have gotten wind of this (all comments / direct emails will be off record), a reply would be appreciated. No ears enclosing clue will be reached via normal channels at ~950E on a Sunday, but this is clearly a problem needing addressing, resolution, action and, who knows - suit? Thanks in advance all for insight, comments, -jamie From eslerj at gmail.com Sun Jul 26 21:06:37 2009 From: eslerj at gmail.com (Joel Esler) Date: Sun, 26 Jul 2009 22:06:37 -0400 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> References: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> Message-ID: <06C30DA4-10DA-43C9-AF81-F29C4496EA33@gmail.com> I have read on another list this evening that AT&T DSL in SoCal is blocking certain sites within 4chan. J On Jul 26, 2009, at 9:48 PM, jamie wrote: > All, > > It appears at AT&T (including DSL, and my own home service via u- > verse) > has unilaterally and without explanation started blocking websites. > > I have confirmed this with multiple tests. (It actually appears that > these sites are being blocked at a local-global scale -- that is, each > city/hub seems to have blackholes for the sites). > > The sites I know of I'll list below (see Reddit for a discussion), > but > this is clearly and absolutely unacceptable. Please, comments on > the nature > of the sites are OT.. Let's keep this thread that way. (Away from > being OT, > that is). > > If any T folk are around, and have gotten wind of this (all > comments / > direct emails will be off record), a reply would be appreciated. > > No ears enclosing clue will be reached via normal channels at ~950E > on a > Sunday, but this is clearly a problem needing addressing, > resolution, action > and, who knows - suit? > > Thanks in advance all for insight, comments, > > -jamie -- Joel Esler ? http://www.joelesler.net ? http://www.twitter.com/joelesler [m] From sethm at rollernet.us Sun Jul 26 21:10:50 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 26 Jul 2009 19:10:50 -0700 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <06C30DA4-10DA-43C9-AF81-F29C4496EA33@gmail.com> References: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> <06C30DA4-10DA-43C9-AF81-F29C4496EA33@gmail.com> Message-ID: <4A6D0CAA.3040205@rollernet.us> Joel Esler wrote: > I have read on another list this evening that AT&T DSL in SoCal is > blocking certain sites within 4chan. > I just tested and can confirm the blackhole is in Reno, too. One more reason to dump ATT in addition to their trial dollar-per-gig thing they're doing here. ~Seth From j at arpa.com Sun Jul 26 21:47:47 2009 From: j at arpa.com (jamie) Date: Sun, 26 Jul 2009 21:47:47 -0500 Subject: AT&T. Layer 6-8 needed. In-Reply-To: References: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> Message-ID: <6ff30abd0907261947y10263ccam33f51b70b0396a6e@mail.gmail.com> img.4chan.org is the biggest site - I've already received six replies on top of the list-replies confirming (b/c they saw this problem mentioned on sites/blogs) filtering. technical information, traces, bgp views (esp. from singly-homed T customers), etc, encouraged -jamie >> > I don't see a below below. > From davet1 at gmail.com Sun Jul 26 22:03:57 2009 From: davet1 at gmail.com (David Temkin) Date: Sun, 26 Jul 2009 20:03:57 -0700 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <6ff30abd0907261947y10263ccam33f51b70b0396a6e@mail.gmail.com> References: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> <6ff30abd0907261947y10263ccam33f51b70b0396a6e@mail.gmail.com> Message-ID: <148641da0907262003k11da6438q4b820025a610a4e6@mail.gmail.com> Perfectly reachable from AT&T in NY: ny01-rtr#traceroute img.4chan.com Type escape sequence to abort. Tracing the route to img.4chan.com (208.73.210.27) 1 12.94.163.57 8 msec 4 msec 4 msec 2 cr1.n54ny.ip.att.net (12.122.131.238) [MPLS: Label 16370 Exp 0] 8 msec 8 msec 8 msec 3 ggr4.n54ny.ip.att.net (12.122.131.25) 8 msec 8 msec 4 msec 4 192.205.34.50 16 msec 4 msec 4 msec 5 0.xe-5-0-3.XL4.NYC4.ALTER.NET (152.63.18.10) 36 msec 4 msec 8 msec 6 0.so-6-0-0.XL2.LAX1.ALTER.NET (152.63.57.81) 76 msec 76 msec 76 msec 7 POS7-0.GW4.LAX1.ALTER.NET (152.63.53.61) 76 msec 76 msec 76 msec 8 oversee-gw.customer.alter.net (65.223.29.34) 76 msec 80 msec 80 msec 9 208.73.208.10 80 msec 80 msec 76 msec 10 img.4chan.com (208.73.210.27) 76 msec 76 msec 76 msec Are you sure this isn't just a technical/routing issue versus a blocking issue? Seems like everyone's out to make a sensationalist story out of this when it's unlikely that anyone's awake at AT&T on a Sunday afternoon who could/would make such a change. -Dave On Sun, Jul 26, 2009 at 7:47 PM, jamie wrote: > img.4chan.org is the biggest site - I've already received six replies on > top > of the list-replies confirming (b/c they saw this problem mentioned on > sites/blogs) filtering. > > technical information, traces, bgp views (esp. from singly-homed T > customers), etc, encouraged > > -jamie > > > >> > > I don't see a below below. > > > From shon at unwiredbb.com Sun Jul 26 22:05:32 2009 From: shon at unwiredbb.com (Shon Elliott) Date: Sun, 26 Jul 2009 20:05:32 -0700 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> References: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> Message-ID: <4A6D197C.6070808@unwiredbb.com> There has been alot of customers on our network who were complaining about ACK scan reports coming from 207.126.64.181. We had no choice but to block that single IP until the attacks let up. It was a decision I made with the gentleman that owns the colo facility currently hosts 4chan. There was no other way around it. I'm sure AT&T is probably blocking it for the same reason. 4chan has been under attack for over 3 weeks, the attacks filling up an entire GigE. If you want to blame anyone, blame the script kiddies who pull this kind of stunt. Regards, Shon Elliott Senior Network Engineer unWired Broadband, Inc. jamie wrote: > All, > > It appears at AT&T (including DSL, and my own home service via u-verse) > has unilaterally and without explanation started blocking websites. > > I have confirmed this with multiple tests. (It actually appears that > these sites are being blocked at a local-global scale -- that is, each > city/hub seems to have blackholes for the sites). > > The sites I know of I'll list below (see Reddit for a discussion), but > this is clearly and absolutely unacceptable. Please, comments on the nature > of the sites are OT.. Let's keep this thread that way. (Away from being OT, > that is). > > If any T folk are around, and have gotten wind of this (all comments / > direct emails will be off record), a reply would be appreciated. > > No ears enclosing clue will be reached via normal channels at ~950E on a > Sunday, but this is clearly a problem needing addressing, resolution, action > and, who knows - suit? > > Thanks in advance all for insight, comments, > > -jamie > From tomb at byrneit.net Sun Jul 26 22:06:33 2009 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Sun, 26 Jul 2009 20:06:33 -0700 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <6ff30abd0907261947y10263ccam33f51b70b0396a6e@mail.gmail.com> References: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> <6ff30abd0907261947y10263ccam33f51b70b0396a6e@mail.gmail.com> Message-ID: <70D072392E56884193E3D2DE09C097A91F43B4@pascal.zaphodb.org> That host is not on any ThreatSTOP lists. (DShield, Cyber-TA, Shadowserver, and several others). >-----Original Message----- >From: jamie [mailto:j at arpa.com] >Sent: Sunday, July 26, 2009 7:48 PM >To: nanog at nanog.org >Subject: Re: AT&T. Layer 6-8 needed. > >img.4chan.org is the biggest site - I've already received six replies on >top >of the list-replies confirming (b/c they saw this problem mentioned on >sites/blogs) filtering. > >technical information, traces, bgp views (esp. from singly-homed T >customers), etc, encouraged > >-jamie > > >>> >> I don't see a below below. >> From shon at unwiredbb.com Sun Jul 26 22:11:41 2009 From: shon at unwiredbb.com (Shon Elliott) Date: Sun, 26 Jul 2009 20:11:41 -0700 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> References: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> Message-ID: <4A6D1AED.7000506@unwiredbb.com> It seems like my blocking of 207.126.64.181 is pointless, because Level3 is also blocking the entire net 207.127.64.0. All I can say is.. oh well. Nothing we can do about it. jamie wrote: > All, > > It appears at AT&T (including DSL, and my own home service via u-verse) > has unilaterally and without explanation started blocking websites. > > I have confirmed this with multiple tests. (It actually appears that > these sites are being blocked at a local-global scale -- that is, each > city/hub seems to have blackholes for the sites). > > The sites I know of I'll list below (see Reddit for a discussion), but > this is clearly and absolutely unacceptable. Please, comments on the nature > of the sites are OT.. Let's keep this thread that way. (Away from being OT, > that is). > > If any T folk are around, and have gotten wind of this (all comments / > direct emails will be off record), a reply would be appreciated. > > No ears enclosing clue will be reached via normal channels at ~950E on a > Sunday, but this is clearly a problem needing addressing, resolution, action > and, who knows - suit? > > Thanks in advance all for insight, comments, > > -jamie > From j at arpa.com Sun Jul 26 22:11:50 2009 From: j at arpa.com (jamie) Date: Sun, 26 Jul 2009 22:11:50 -0500 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <4A6D197C.6070808@unwiredbb.com> References: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> <4A6D197C.6070808@unwiredbb.com> Message-ID: <6ff30abd0907262011x6d222993ma8f3b350dec050b2@mail.gmail.com> It should be blocked at the complaining customer port. Not nationwide, and certainly not without announcement. On Sun, Jul 26, 2009 at 10:05 PM, Shon Elliott wrote: > There has been alot of customers on our network who were complaining about > ACK > scan reports coming from 207.126.64.181. We had no choice but to block that > single IP until the attacks let up. It was a decision I made with the > gentleman > that owns the colo facility currently hosts 4chan. There was no other way > around > it. I'm sure AT&T is probably blocking it for the same reason. 4chan has > been > under attack for over 3 weeks, the attacks filling up an entire GigE. If > you > want to blame anyone, blame the script kiddies who pull this kind of stunt. > > Regards, > Shon Elliott > Senior Network Engineer > unWired Broadband, Inc. > > > jamie wrote: > > All, > > > > It appears at AT&T (including DSL, and my own home service via u-verse) > > has unilaterally and without explanation started blocking websites. > > > > I have confirmed this with multiple tests. (It actually appears that > > these sites are being blocked at a local-global scale -- that is, each > > city/hub seems to have blackholes for the sites). > > > > The sites I know of I'll list below (see Reddit for a discussion), but > > this is clearly and absolutely unacceptable. Please, comments on the > nature > > of the sites are OT.. Let's keep this thread that way. (Away from being > OT, > > that is). > > > > If any T folk are around, and have gotten wind of this (all comments / > > direct emails will be off record), a reply would be appreciated. > > > > No ears enclosing clue will be reached via normal channels at ~950E on > a > > Sunday, but this is clearly a problem needing addressing, resolution, > action > > and, who knows - suit? > > > > Thanks in advance all for insight, comments, > > > > -jamie > > > > > From shon at unwiredbb.com Sun Jul 26 22:20:31 2009 From: shon at unwiredbb.com (Shon Elliott) Date: Sun, 26 Jul 2009 20:20:31 -0700 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <6ff30abd0907262011x6d222993ma8f3b350dec050b2@mail.gmail.com> References: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> <4A6D197C.6070808@unwiredbb.com> <6ff30abd0907262011x6d222993ma8f3b350dec050b2@mail.gmail.com> Message-ID: <4A6D1CFF.5090901@unwiredbb.com> Jamie, Unfortunately, that's not easy with wireless backbones. The customers don't have their own "port". I also know for fact that 4chan is in the process of moving, so what you're seeing could just be that. Them moving. Regards, Shon Elliott Senior Network Engineer unWired Broadband, Inc. jamie wrote: > It should be blocked at the complaining customer port. > > Not nationwide, and certainly not without announcement. > > > On Sun, Jul 26, 2009 at 10:05 PM, Shon Elliott > wrote: > > There has been alot of customers on our network who were complaining > about ACK > scan reports coming from 207.126.64.181. We had no choice but to > block that > single IP until the attacks let up. It was a decision I made with > the gentleman > that owns the colo facility currently hosts 4chan. There was no > other way around > it. I'm sure AT&T is probably blocking it for the same reason. 4chan > has been > under attack for over 3 weeks, the attacks filling up an entire > GigE. If you > want to blame anyone, blame the script kiddies who pull this kind of > stunt. > > Regards, > Shon Elliott > Senior Network Engineer > unWired Broadband, Inc. > > > jamie wrote: > > All, > > > > It appears at AT&T (including DSL, and my own home service via > u-verse) > > has unilaterally and without explanation started blocking websites. > > > > I have confirmed this with multiple tests. (It actually appears > that > > these sites are being blocked at a local-global scale -- that is, each > > city/hub seems to have blackholes for the sites). > > > > The sites I know of I'll list below (see Reddit for a > discussion), but > > this is clearly and absolutely unacceptable. Please, comments on > the nature > > of the sites are OT.. Let's keep this thread that way. (Away from > being OT, > > that is). > > > > If any T folk are around, and have gotten wind of this (all > comments / > > direct emails will be off record), a reply would be appreciated. > > > > No ears enclosing clue will be reached via normal channels at > ~950E on a > > Sunday, but this is clearly a problem needing addressing, > resolution, action > > and, who knows - suit? > > > > Thanks in advance all for insight, comments, > > > > -jamie > > > > > From davet1 at gmail.com Sun Jul 26 22:45:40 2009 From: davet1 at gmail.com (David Temkin) Date: Sun, 26 Jul 2009 20:45:40 -0700 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <148641da0907262003k11da6438q4b820025a610a4e6@mail.gmail.com> References: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> <6ff30abd0907261947y10263ccam33f51b70b0396a6e@mail.gmail.com> <148641da0907262003k11da6438q4b820025a610a4e6@mail.gmail.com> Message-ID: <148641da0907262045n4540fb9fi68c3944ab009cd29@mail.gmail.com> Someone just pointed out that I dumbassedly tracerouted to img.4chan.com, which is a linkfarm. img.4chan.org is also reachable from AT&T in NY: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 207.126.64.182, timeout is 2 seconds: .!..! Success rate is 40 percent (2/5), round-trip min/avg/max = 164/196/228 ms ny01-rtr# Type escape sequence to abort. Tracing the route to img.4chan.org (207.126.64.182) 1 12.94.163.57 8 msec 4 msec 4 msec 2 cr1.n54ny.ip.att.net (12.122.131.238) [MPLS: Label 16377 Exp 0] 8 msec 8 msec 8 msec 3 ggr7.n54ny.ip.att.net (12.122.131.97) 8 msec 4 msec 8 msec 4 192.205.35.10 8 msec 4 msec 4 msec 5 cr1-tengig-0-8-3-0.NewYork.savvis.net (204.70.198.13) 4 msec 8 msec 4 msec 6 cr1-pos-0-3-2-3.dallas.savvis.net (204.70.192.82) 48 msec 44 msec 44 msec 7 * * * 8 er1-te-3-1.dallasequinix.savvis.net (204.70.204.149) 48 msec 44 msec 44 msec 9 208.175.175.22 164 msec 172 msec 120 msec 10 unknown.xeex.net (216.152.253.26) 48 msec 48 msec 48 msec However, it's equally as unhealthy from Comcast: --- img.4chan.org ping statistics --- 110 packets transmitted, 77 packets received, 30% packet loss round-trip min/avg/max/stddev = 62.635/233.576/639.919/96.254 ms So, enough with the conspiracy theories already. On Sun, Jul 26, 2009 at 8:03 PM, David Temkin wrote: > Perfectly reachable from AT&T in NY: > > ny01-rtr#traceroute img.4chan.com > > Type escape sequence to abort. > Tracing the route to img.4chan.com (208.73.210.27) > > 1 12.94.163.57 8 msec 4 msec 4 msec > 2 cr1.n54ny.ip.att.net (12.122.131.238) [MPLS: Label 16370 Exp 0] 8 msec > 8 msec 8 msec > 3 ggr4.n54ny.ip.att.net (12.122.131.25) 8 msec 8 msec 4 msec > 4 192.205.34.50 16 msec 4 msec 4 msec > 5 0.xe-5-0-3.XL4.NYC4.ALTER.NET (152.63.18.10) 36 msec 4 msec 8 msec > 6 0.so-6-0-0.XL2.LAX1.ALTER.NET (152.63.57.81) 76 msec 76 msec 76 msec > 7 POS7-0.GW4.LAX1.ALTER.NET (152.63.53.61) 76 msec 76 msec 76 msec > 8 oversee-gw.customer.alter.net (65.223.29.34) 76 msec 80 msec 80 msec > 9 208.73.208.10 80 msec 80 msec 76 msec > 10 img.4chan.com (208.73.210.27) 76 msec 76 msec 76 msec > > Are you sure this isn't just a technical/routing issue versus a blocking > issue? Seems like everyone's out to make a sensationalist story out of this > when it's unlikely that anyone's awake at AT&T on a Sunday afternoon who > could/would make such a change. > > -Dave > > > On Sun, Jul 26, 2009 at 7:47 PM, jamie wrote: > >> img.4chan.org is the biggest site - I've already received six replies on >> top >> of the list-replies confirming (b/c they saw this problem mentioned on >> sites/blogs) filtering. >> >> technical information, traces, bgp views (esp. from singly-homed T >> customers), etc, encouraged >> >> -jamie >> >> >> >> >> > I don't see a below below. >> > >> > > From sethm at rollernet.us Sun Jul 26 22:46:34 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 26 Jul 2009 20:46:34 -0700 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <4A6D1CFF.5090901@unwiredbb.com> References: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> <4A6D197C.6070808@unwiredbb.com> <6ff30abd0907262011x6d222993ma8f3b350dec050b2@mail.gmail.com> <4A6D1CFF.5090901@unwiredbb.com> Message-ID: <4A6D231A.2050502@rollernet.us> Shon Elliott wrote: > Jamie, > > Unfortunately, that's not easy with wireless backbones. The customers don't have > their own "port". I also know for fact that 4chan is in the process of moving, > so what you're seeing could just be that. Them moving. > This is definitely not "them moving": traceroute: Warning: img.4chan.org has multiple addresses; using 207.126.64.182 traceroute to img.4chan.org (207.126.64.182), 30 hops max, 40 byte packets 1 67.118.62.1 207.264 ms 258.116 ms 174.721 ms 2 63.201.16.134 141.205 ms 46.683 ms 41.622 ms 3 * * * 4 * * * 5 * * * 6 * * * Traceroute from an ATT DSL account. ~Seth From goemon at anime.net Sun Jul 26 23:13:24 2009 From: goemon at anime.net (goemon at anime.net) Date: Sun, 26 Jul 2009 21:13:24 -0700 (PDT) Subject: AT&T. Layer 6-8 needed. In-Reply-To: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> References: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> Message-ID: http://status.4chan.org/ On Sun, 26 Jul 2009, jamie wrote: > No ears enclosing clue will be reached via normal channels at ~950E on a > Sunday, but this is clearly a problem needing addressing, resolution, action > and, who knows - suit? http://www.hulu.com/watch/4163/saturday-night-live-ernestine From j at arpa.com Sun Jul 26 23:35:04 2009 From: j at arpa.com (jamie) Date: Sun, 26 Jul 2009 23:35:04 -0500 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <4A6D1CFF.5090901@unwiredbb.com> References: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> <4A6D197C.6070808@unwiredbb.com> <6ff30abd0907262011x6d222993ma8f3b350dec050b2@mail.gmail.com> <4A6D1CFF.5090901@unwiredbb.com> Message-ID: <6ff30abd0907262135l17d3c807o6366ed8810cf9b03@mail.gmail.com> 'Wireless backbone'? K. I have a dozen confirmations off list in every time zone. SANS ISC is soliciting technical reports on this; It's on the EFF's Radar. "This is not a drill" If any ISP of mine filtered my (where my = brick-and-mortar-corp) access to any destination because of another customer (there are *always* technical solutions to problems you describe, the one you implemented wouldn't even make my list), you'd have one less customer and quite likely a Tortious Interference claim.. And, as a (wired) backbone arch, if I ever filtered a host (btw: there are five IPs in that /24 being filtered by T) that cut off every customer's access to that host or group, I'd expect to not have a job anymore. If I wanted filtered Internet, I'd sign up for Prodigy. Check http://status.4chan.org - they're not moving anything at the moment, and confirm the filtering. Debate away, I'm off to bed. I think 4chan's reaction to this will be bigger than the story itself - No need for me to argue what will soon be in the News Cycle. -j On Sun, Jul 26, 2009 at 10:20 PM, Shon Elliott wrote: > > Jamie, > > Unfortunately, that's not easy with wireless backbones. The customers don't > have > their own "port". I also know for fact that 4chan is in the process of > moving, > so what you're seeing could just be that. Them moving. > > > Regards, > Shon Elliott > Senior Network Engineer > unWired Broadband, Inc. > > > jamie wrote: > > It should be blocked at the complaining customer port. > > > > Not nationwide, and certainly not without announcement. > > > > > > On Sun, Jul 26, 2009 at 10:05 PM, Shon Elliott > > wrote: > > > > There has been alot of customers on our network who were complaining > > about ACK > > scan reports coming from 207.126.64.181. We had no choice but to > > block that > > single IP until the attacks let up. It was a decision I made with > > the gentleman > > that owns the colo facility currently hosts 4chan. There was no > > other way around > > it. I'm sure AT&T is probably blocking it for the same reason. 4chan > > has been > > under attack for over 3 weeks, the attacks filling up an entire > > GigE. If you > > want to blame anyone, blame the script kiddies who pull this kind of > > stunt. > > > > Regards, > > Shon Elliott > > Senior Network Engineer > > unWired Broadband, Inc. > > > > > > jamie wrote: > > > All, > > > > > > It appears at AT&T (including DSL, and my own home service via > > u-verse) > > > has unilaterally and without explanation started blocking websites. > > > > > > I have confirmed this with multiple tests. (It actually appears > > that > > > these sites are being blocked at a local-global scale -- that is, > each > > > city/hub seems to have blackholes for the sites). > > > > > > The sites I know of I'll list below (see Reddit for a > > discussion), but > > > this is clearly and absolutely unacceptable. Please, comments on > > the nature > > > of the sites are OT.. Let's keep this thread that way. (Away from > > being OT, > > > that is). > > > > > > If any T folk are around, and have gotten wind of this (all > > comments / > > > direct emails will be off record), a reply would be appreciated. > > > > > > No ears enclosing clue will be reached via normal channels at > > ~950E on a > > > Sunday, but this is clearly a problem needing addressing, > > resolution, action > > > and, who knows - suit? > > > > > > Thanks in advance all for insight, comments, > > > > > > -jamie > > > > > > > > > > From bambenek at gmail.com Sun Jul 26 23:39:42 2009 From: bambenek at gmail.com (John Bambenek) Date: Sun, 26 Jul 2009 23:39:42 -0500 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <6ff30abd0907262135l17d3c807o6366ed8810cf9b03@mail.gmail.com> References: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> <4A6D197C.6070808@unwiredbb.com> <6ff30abd0907262011x6d222993ma8f3b350dec050b2@mail.gmail.com> <4A6D1CFF.5090901@unwiredbb.com> <6ff30abd0907262135l17d3c807o6366ed8810cf9b03@mail.gmail.com> Message-ID: <4A6D2F8E.5080501@gmail.com> SANS ISC isn't soliciting technical reports, we're interested and looking at the issue with a particular eye to 4chan's history of pulling pranks. Then there is the blocking because of the DoS angle, which I admit, doesn't seem to fit the facts in this case. There are AT&T people on this list, I presume, who can speak to the issue if need be. I'd prefer the SANS ISC not get "name dropped" as if we lend credibility to this. We're looking, sure. That's it. j jamie wrote: > 'Wireless backbone'? > > K. > > I have a dozen confirmations off list in every time zone. SANS ISC is > soliciting technical reports on this; It's on the EFF's Radar. > > "This is not a drill" > > If any ISP of mine filtered my (where my = brick-and-mortar-corp) access to > any destination because of another customer (there are *always* technical > solutions to problems you describe, the one you implemented wouldn't even > make my list), you'd have one less customer and quite likely a Tortious > Interference claim.. > > And, as a (wired) backbone arch, if I ever filtered a host (btw: there are > five IPs in that /24 being filtered by T) that cut off every customer's > access to that host or group, I'd expect to not have a job anymore. > > If I wanted filtered Internet, I'd sign up for Prodigy. > > Check http://status.4chan.org - they're not moving anything at the moment, > and confirm the filtering. > > Debate away, I'm off to bed. > > I think 4chan's reaction to this will be bigger than the story itself - No > need for me to argue what will soon be in the News Cycle. > > -j > > > > > On Sun, Jul 26, 2009 at 10:20 PM, Shon Elliott wrote: > > >> Jamie, >> >> Unfortunately, that's not easy with wireless backbones. The customers don't >> have >> their own "port". I also know for fact that 4chan is in the process of >> moving, >> so what you're seeing could just be that. Them moving. >> >> >> Regards, >> Shon Elliott >> Senior Network Engineer >> unWired Broadband, Inc. >> >> >> jamie wrote: >> >>> It should be blocked at the complaining customer port. >>> >>> Not nationwide, and certainly not without announcement. >>> >>> >>> On Sun, Jul 26, 2009 at 10:05 PM, Shon Elliott >> > wrote: >>> >>> There has been alot of customers on our network who were complaining >>> about ACK >>> scan reports coming from 207.126.64.181. We had no choice but to >>> block that >>> single IP until the attacks let up. It was a decision I made with >>> the gentleman >>> that owns the colo facility currently hosts 4chan. There was no >>> other way around >>> it. I'm sure AT&T is probably blocking it for the same reason. 4chan >>> has been >>> under attack for over 3 weeks, the attacks filling up an entire >>> GigE. If you >>> want to blame anyone, blame the script kiddies who pull this kind of >>> stunt. >>> >>> Regards, >>> Shon Elliott >>> Senior Network Engineer >>> unWired Broadband, Inc. >>> >>> >>> jamie wrote: >>> > All, >>> > >>> > It appears at AT&T (including DSL, and my own home service via >>> u-verse) >>> > has unilaterally and without explanation started blocking websites. >>> > >>> > I have confirmed this with multiple tests. (It actually appears >>> that >>> > these sites are being blocked at a local-global scale -- that is, >>> >> each >> >>> > city/hub seems to have blackholes for the sites). >>> > >>> > The sites I know of I'll list below (see Reddit for a >>> discussion), but >>> > this is clearly and absolutely unacceptable. Please, comments on >>> the nature >>> > of the sites are OT.. Let's keep this thread that way. (Away from >>> being OT, >>> > that is). >>> > >>> > If any T folk are around, and have gotten wind of this (all >>> comments / >>> > direct emails will be off record), a reply would be appreciated. >>> > >>> > No ears enclosing clue will be reached via normal channels at >>> ~950E on a >>> > Sunday, but this is clearly a problem needing addressing, >>> resolution, action >>> > and, who knows - suit? >>> > >>> > Thanks in advance all for insight, comments, >>> > >>> > -jamie >>> > >>> >>> >>> >>> From shon at unwiredbb.com Sun Jul 26 23:39:52 2009 From: shon at unwiredbb.com (Shon Elliott) Date: Sun, 26 Jul 2009 21:39:52 -0700 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <4A6D231A.2050502@rollernet.us> References: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> <4A6D197C.6070808@unwiredbb.com> <6ff30abd0907262011x6d222993ma8f3b350dec050b2@mail.gmail.com> <4A6D1CFF.5090901@unwiredbb.com> <4A6D231A.2050502@rollernet.us> Message-ID: <4A6D2F98.2080302@unwiredbb.com> Seth, I said it could be, not that it is. Thanks for pointing that out. However, I believe the reason they are being blocked at AT&T is the main reason I supplied on my first post. The DDoS attack issue is the main ticket here. It's not because of content, or to piss people off. It's to protect their network, as any of you would do when you got DDoSed on your own networks. It's damage control, essentially, until they find out who is involved and block them, then they'll likely lift the block. This ISN'T the first time this has happened. Especially to 4chan. You can check their status page and see most of the entries revolve around them being down because of DDoS attacks. Regards, Shon Elliott Senior Network Engineer unWired Broadband, Inc. Seth Mattinen wrote: > Shon Elliott wrote: >> Jamie, >> >> Unfortunately, that's not easy with wireless backbones. The customers >> don't have >> their own "port". I also know for fact that 4chan is in the process of >> moving, >> so what you're seeing could just be that. Them moving. >> > > This is definitely not "them moving": > > traceroute: Warning: img.4chan.org has multiple addresses; using > 207.126.64.182 > traceroute to img.4chan.org (207.126.64.182), 30 hops max, 40 byte packets > 1 67.118.62.1 207.264 ms 258.116 ms 174.721 ms > 2 63.201.16.134 141.205 ms 46.683 ms 41.622 ms > 3 * * * > 4 * * * > 5 * * * > 6 * * * > > Traceroute from an ATT DSL account. > > ~Seth > > From j at arpa.com Sun Jul 26 23:44:49 2009 From: j at arpa.com (jamie) Date: Sun, 26 Jul 2009 23:44:49 -0500 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <4A6D2F8E.5080501@gmail.com> References: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> <4A6D197C.6070808@unwiredbb.com> <6ff30abd0907262011x6d222993ma8f3b350dec050b2@mail.gmail.com> <4A6D1CFF.5090901@unwiredbb.com> <6ff30abd0907262135l17d3c807o6366ed8810cf9b03@mail.gmail.com> <4A6D2F8E.5080501@gmail.com> Message-ID: <6ff30abd0907262144g301bc20wec987ab4840b1a29@mail.gmail.com> I must have misinterpreted "send us something confirming the AT&T 4Chan outage / isc.sans.org" message. My bad. On Sun, Jul 26, 2009 at 11:39 PM, John Bambenek wrote: > SANS ISC isn't soliciting technical reports, we're interested and looking > at the issue with a particular eye to 4chan's history of pulling pranks. > > Then there is the blocking because of the DoS angle, which I admit, doesn't > seem to fit the facts in this case. > > There are AT&T people on this list, I presume, who can speak to the issue > if need be. > > I'd prefer the SANS ISC not get "name dropped" as if we lend credibility to > this. We're looking, sure. That's it. > > j > > > jamie wrote: > >> 'Wireless backbone'? >> >> K. >> >> I have a dozen confirmations off list in every time zone. SANS ISC is >> soliciting technical reports on this; It's on the EFF's Radar. >> >> "This is not a drill" >> >> If any ISP of mine filtered my (where my = brick-and-mortar-corp) access >> to >> any destination because of another customer (there are *always* technical >> solutions to problems you describe, the one you implemented wouldn't even >> make my list), you'd have one less customer and quite likely a Tortious >> Interference claim.. >> >> And, as a (wired) backbone arch, if I ever filtered a host (btw: there are >> five IPs in that /24 being filtered by T) that cut off every customer's >> access to that host or group, I'd expect to not have a job anymore. >> >> If I wanted filtered Internet, I'd sign up for Prodigy. >> >> Check http://status.4chan.org - they're not moving anything at the >> moment, >> and confirm the filtering. >> >> Debate away, I'm off to bed. >> >> I think 4chan's reaction to this will be bigger than the story itself - No >> need for me to argue what will soon be in the News Cycle. >> >> -j >> >> >> >> >> On Sun, Jul 26, 2009 at 10:20 PM, Shon Elliott >> wrote: >> >> >> >>> Jamie, >>> >>> Unfortunately, that's not easy with wireless backbones. The customers >>> don't >>> have >>> their own "port". I also know for fact that 4chan is in the process of >>> moving, >>> so what you're seeing could just be that. Them moving. >>> >>> >>> Regards, >>> Shon Elliott >>> Senior Network Engineer >>> unWired Broadband, Inc. >>> >>> >>> jamie wrote: >>> >>> >>>> It should be blocked at the complaining customer port. >>>> >>>> Not nationwide, and certainly not without announcement. >>>> >>>> >>>> On Sun, Jul 26, 2009 at 10:05 PM, Shon Elliott >>> > wrote: >>>> >>>> There has been alot of customers on our network who were complaining >>>> about ACK >>>> scan reports coming from 207.126.64.181. We had no choice but to >>>> block that >>>> single IP until the attacks let up. It was a decision I made with >>>> the gentleman >>>> that owns the colo facility currently hosts 4chan. There was no >>>> other way around >>>> it. I'm sure AT&T is probably blocking it for the same reason. 4chan >>>> has been >>>> under attack for over 3 weeks, the attacks filling up an entire >>>> GigE. If you >>>> want to blame anyone, blame the script kiddies who pull this kind of >>>> stunt. >>>> >>>> Regards, >>>> Shon Elliott >>>> Senior Network Engineer >>>> unWired Broadband, Inc. >>>> >>>> >>>> jamie wrote: >>>> > All, >>>> > >>>> > It appears at AT&T (including DSL, and my own home service via >>>> u-verse) >>>> > has unilaterally and without explanation started blocking websites. >>>> > >>>> > I have confirmed this with multiple tests. (It actually appears >>>> that >>>> > these sites are being blocked at a local-global scale -- that is, >>>> >>>> >>> each >>> >>> >>>> > city/hub seems to have blackholes for the sites). >>>> > >>>> > The sites I know of I'll list below (see Reddit for a >>>> discussion), but >>>> > this is clearly and absolutely unacceptable. Please, comments on >>>> the nature >>>> > of the sites are OT.. Let's keep this thread that way. (Away from >>>> being OT, >>>> > that is). >>>> > >>>> > If any T folk are around, and have gotten wind of this (all >>>> comments / >>>> > direct emails will be off record), a reply would be appreciated. >>>> > >>>> > No ears enclosing clue will be reached via normal channels at >>>> ~950E on a >>>> > Sunday, but this is clearly a problem needing addressing, >>>> resolution, action >>>> > and, who knows - suit? >>>> > >>>> > Thanks in advance all for insight, comments, >>>> > >>>> > -jamie >>>> > >>>> >>>> >>>> >>>> >>>> >>> > From 2600hz at gmail.com Mon Jul 27 00:14:03 2009 From: 2600hz at gmail.com (chris rollin) Date: Mon, 27 Jul 2009 00:14:03 -0500 Subject: AT&T. Layer 6-8 needed. Message-ID: Shon wrote: Seth, > I said it could be, not that it is. Thanks for pointing that out. However, I > believe the reason they are being blocked at AT&T is the main reason I supplied > on my first post. The DDoS attack issue is the main ticket here. The ACK storms arent coming from the 4chan servers It's just like the DNS attack (IN/NS/.). It points to the stupidity of AT&T uppers SANS: Are you or arent you soliciting data? I have some to confirm also > It's not > because of content, or to piss people off. It's to protect their network, as any > of you would do when you got DDoSed on your own networks. They are going to get some first hand experience in what Protecting their Network involves real soon, now. Blocking 4chan was an exercise in Stupidity > It's damage control, It's a damage challenge. > essentially, until they find out who is involved and block them, then they'll > likely lift the block. They don't have the right to do this. Not in their TOS/EULA/User-Agreement. Not in any sane legal forum. (I*A*AL) > This ISN'T the first time this has happened. Exactly. Now you see the problem ? From bambenek at gmail.com Mon Jul 27 00:17:10 2009 From: bambenek at gmail.com (John Bambenek) Date: Mon, 27 Jul 2009 00:17:10 -0500 Subject: AT&T. Layer 6-8 needed. In-Reply-To: References: Message-ID: <4A6D3856.7050706@gmail.com> We'll take data from **Trusted** sources. I'm just not going to take a public open mailing list post as evidence at this point. chris rollin wrote: > Shon wrote: > > Seth, > > >> I said it could be, not that it is. Thanks for pointing that out. However, >> > I > >> believe the reason they are being blocked at AT&T is the main reason I >> > supplied > >> on my first post. The DDoS attack issue is the main ticket here. >> > > The ACK storms arent coming from the 4chan servers > It's just like the DNS attack (IN/NS/.). It points to the stupidity of AT&T > uppers > SANS: Are you or arent you soliciting data? I have some to confirm also > > >> It's not >> because of content, or to piss people off. It's to protect their network, >> > as any > >> of you would do when you got DDoSed on your own networks. >> > > They are going to get some first hand experience in what Protecting their > Network > involves real soon, now. Blocking 4chan was an exercise in Stupidity > > >> It's damage control, >> > > It's a damage challenge. > > >> essentially, until they find out who is involved and block them, then >> > they'll > >> likely lift the block. >> > > They don't have the right to do this. Not in their TOS/EULA/User-Agreement. > Not in any sane legal forum. (I*A*AL) > > >> This ISN'T the first time this has happened. >> > > Exactly. > > Now you see the problem ? > From 2600hz at gmail.com Mon Jul 27 00:18:15 2009 From: 2600hz at gmail.com (chris rollin) Date: Mon, 27 Jul 2009 00:18:15 -0500 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <4A6D3856.7050706@gmail.com> References: <4A6D3856.7050706@gmail.com> Message-ID: Uh. You posted on Twitter. The most trusted name in [?] On Mon, Jul 27, 2009 at 12:17 AM, John Bambenek wrote: > We'll take data from **Trusted** sources. > > I'm just not going to take a public open mailing list post as evidence at > this point. > > > chris rollin wrote: > >> Shon wrote: >> >> Seth, >> >> >> >>> I said it could be, not that it is. Thanks for pointing that out. >>> However, >>> >>> >> I >> >> >>> believe the reason they are being blocked at AT&T is the main reason I >>> >>> >> supplied >> >> >>> on my first post. The DDoS attack issue is the main ticket here. >>> >>> >> >> The ACK storms arent coming from the 4chan servers >> It's just like the DNS attack (IN/NS/.). It points to the stupidity of >> AT&T >> uppers >> SANS: Are you or arent you soliciting data? I have some to confirm also >> >> >> >>> It's not >>> because of content, or to piss people off. It's to protect their network, >>> >>> >> as any >> >> >>> of you would do when you got DDoSed on your own networks. >>> >>> >> >> They are going to get some first hand experience in what Protecting their >> Network >> involves real soon, now. Blocking 4chan was an exercise in Stupidity >> >> >> >>> It's damage control, >>> >>> >> >> It's a damage challenge. >> >> >> >>> essentially, until they find out who is involved and block them, then >>> >>> >> they'll >> >> >>> likely lift the block. >>> >>> >> >> They don't have the right to do this. Not in their >> TOS/EULA/User-Agreement. >> Not in any sane legal forum. (I*A*AL) >> >> >> >>> This ISN'T the first time this has happened. >>> >>> >> >> Exactly. >> >> Now you see the problem ? >> >> > > From bambenek at gmail.com Mon Jul 27 00:19:08 2009 From: bambenek at gmail.com (John Bambenek) Date: Mon, 27 Jul 2009 00:19:08 -0500 Subject: AT&T. Layer 6-8 needed. In-Reply-To: References: <4A6D3856.7050706@gmail.com> Message-ID: <4A6D38CC.6000200@gmail.com> Someone else posted on twitter, I saw it recently. To make it even clearer, we'll take your data, sure. Just don't expect us to jump on it until we verify with something solid. chris rollin wrote: > Uh. > > You posted on Twitter. > > The most trusted name in [?] > > On Mon, Jul 27, 2009 at 12:17 AM, John Bambenek > wrote: > > We'll take data from **Trusted** sources. > > I'm just not going to take a public open mailing list post as > evidence at this point. > > > chris rollin wrote: > > Shon wrote: > > Seth, > > > > I said it could be, not that it is. Thanks for pointing > that out. However, > > > I > > > believe the reason they are being blocked at AT&T is the > main reason I > > > supplied > > > on my first post. The DDoS attack issue is the main ticket > here. > > > > The ACK storms arent coming from the 4chan servers > It's just like the DNS attack (IN/NS/.). It points to the > stupidity of AT&T > uppers > SANS: Are you or arent you soliciting data? I have some to > confirm also > > > > It's not > because of content, or to piss people off. It's to protect > their network, > > > as any > > > of you would do when you got DDoSed on your own networks. > > > > They are going to get some first hand experience in what > Protecting their > Network > involves real soon, now. Blocking 4chan was an exercise in > Stupidity > > > > It's damage control, > > > > It's a damage challenge. > > > > essentially, until they find out who is involved and block > them, then > > > they'll > > > likely lift the block. > > > > They don't have the right to do this. Not in their > TOS/EULA/User-Agreement. > Not in any sane legal forum. (I*A*AL) > > > > This ISN'T the first time this has happened. > > > > Exactly. > > Now you see the problem ? > > > > From shon at unwiredbb.com Mon Jul 27 00:37:47 2009 From: shon at unwiredbb.com (Shon Elliott) Date: Sun, 26 Jul 2009 22:37:47 -0700 Subject: AT&T. Layer 6-8 needed. In-Reply-To: References: Message-ID: <4A6D3D2B.7050001@unwiredbb.com> chris rollin wrote: > Shon wrote: > > Seth, > >> I said it could be, not that it is. Thanks for pointing that out. However, > I >> believe the reason they are being blocked at AT&T is the main reason I > supplied >> on my first post. The DDoS attack issue is the main ticket here. > > The ACK storms arent coming from the 4chan servers > It's just like the DNS attack (IN/NS/.). It points to the stupidity of AT&T > uppers > SANS: Are you or arent you soliciting data? I have some to confirm also > Actually, they are. They are returning responses to hundreds of thousands of SPOOFED SYN requests. Where do you think those are gonna go? The ACKs are gonna come back to the network in which IPs were SPOOFed from, essentially, causing a DDoS on a network not even really involved. >> It's not >> because of content, or to piss people off. It's to protect their network, > as any >> of you would do when you got DDoSed on your own networks. > > They are going to get some first hand experience in what Protecting their > Network > involves real soon, now. Blocking 4chan was an exercise in Stupidity > Is that some kind of threat or what? Why would you even make a statement like that? >> It's damage control, > > It's a damage challenge. > >> essentially, until they find out who is involved and block them, then > they'll >> likely lift the block. > > They don't have the right to do this. Not in their TOS/EULA/User-Agreement. > Not in any sane legal forum. (I*A*AL) > They don't have the right to protect their network? So you're saying, if someone is DDoSing your network either direct or indirect, the network operator is just supposed to sit there and do nothing while all of it's customers get crappy internet service because of something they probably don't even know about or care about. >> This ISN'T the first time this has happened. > Don't cut it off there. This ISN'T the first time it's happened, as 4chan goes through DDoSes from script kiddies on a regular basis, and it harms lots of networks along the way in the process. > Exactly. > > Now you see the problem ? > The problem is the DDoS attacks. Not AT&T. 4chan's users constantly instigate this. Chris Poole needs to do more than just sit back and watch. He needs to start collecting this information and turning it in to the authorities, because all of this is convered under domestic terrorism as a cyber-crime. I'm betting there's reasons why he hasn't. He's afraid to get into trouble himself on some of the content that's posted to /b/... whether it's there 5 seconds or 5 minutes. From nenolod at systeminplace.net Mon Jul 27 00:38:20 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 27 Jul 2009 00:38:20 -0500 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <4A6D197C.6070808@unwiredbb.com> References: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> <4A6D197C.6070808@unwiredbb.com> Message-ID: <1248673100.5698.7.camel@petrie> On Sun, 2009-07-26 at 20:05 -0700, Shon Elliott wrote: > There has been alot of customers on our network who were complaining about ACK > scan reports coming from 207.126.64.181. We had no choice but to block that > single IP until the attacks let up. It was a decision I made with the gentleman > that owns the colo facility currently hosts 4chan. There was no other way around > it. I'm sure AT&T is probably blocking it for the same reason. 4chan has been > under attack for over 3 weeks, the attacks filling up an entire GigE. If you > want to blame anyone, blame the script kiddies who pull this kind of stunt. ...have you ever heard of forged packet headers? Just saying. William -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-800-688-5018 From nenolod at systeminplace.net Mon Jul 27 00:58:33 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 27 Jul 2009 00:58:33 -0500 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <4A6D3D2B.7050001@unwiredbb.com> References: <4A6D3D2B.7050001@unwiredbb.com> Message-ID: <1248674313.13748.10.camel@petrie> On Sun, 2009-07-26 at 22:37 -0700, Shon Elliott wrote: > > chris rollin wrote: > > Shon wrote: > > > > Seth, > > > >> I said it could be, not that it is. Thanks for pointing that out. However, > > I > >> believe the reason they are being blocked at AT&T is the main reason I > > supplied > >> on my first post. The DDoS attack issue is the main ticket here. > > > > The ACK storms arent coming from the 4chan servers > > It's just like the DNS attack (IN/NS/.). It points to the stupidity of AT&T > > uppers > > SANS: Are you or arent you soliciting data? I have some to confirm also > > > > > Actually, they are. They are returning responses to hundreds of thousands of > SPOOFED SYN requests. Where do you think those are gonna go? The ACKs are gonna > come back to the network in which IPs were SPOOFed from, essentially, causing a > DDoS on a network not even really involved. {citation needed}. It is possible to send spoofed ACK responses without the SYN ever happening in the first place. At any rate, you would think that if this was really going on that status.4chan.org would have an update on the topic. It is widely known that AT&T loves censorship. They love censorship because it is profitable for them to love censorship, and this isn't the first time they have enmasse blocked access to a website they didn't like. This has nothing at all to do with forged ACK responses, and everything to do with content. AT&T does not have the right to filter what their users can access, period. You can put all the spin on it that you want, but in the end it's about content. If this was about protecting their network, then they could do that in a different way, period end of story. > >> It's not > >> because of content, or to piss people off. It's to protect their network, > > as any > >> of you would do when you got DDoSed on your own networks. > > > > They are going to get some first hand experience in what Protecting their > > Network > > involves real soon, now. Blocking 4chan was an exercise in Stupidity > > > > > Is that some kind of threat or what? Why would you even make a statement like that? Do not underestimate the power of teenagers living in their parents' basement. There's a lot of them, and they can't access their favourite website anymore. This is going to result in a lot of these families switching to Cable or an alternative DSL provider. > > > >> It's damage control, > > > > It's a damage challenge. > > > >> essentially, until they find out who is involved and block them, then > > they'll > >> likely lift the block. > > > > They don't have the right to do this. Not in their TOS/EULA/User-Agreement. > > Not in any sane legal forum. (I*A*AL) > > > > They don't have the right to protect their network? So you're saying, if someone > is DDoSing your network either direct or indirect, the network operator is just > supposed to sit there and do nothing while all of it's customers get crappy > internet service because of something they probably don't even know about or > care about. They have the right to protect their network, but not at the cost of reducing neutrality. But luckily we live in a free market, and AT&T is about to lose a lot of business because of that block. If I were them, I would fix it now, and be extremely apologetic about this happening. > > >> This ISN'T the first time this has happened. > > > > Don't cut it off there. This ISN'T the first time it's happened, as 4chan goes > through DDoSes from script kiddies on a regular basis, and it harms lots of > networks along the way in the process. No, he means, this isn't the first time AT&T has degraded service as a matter of policy. > > > Exactly. > > > > Now you see the problem ? > > > > The problem is the DDoS attacks. Not AT&T. 4chan's users constantly instigate > this. Chris Poole needs to do more than just sit back and watch. He needs to > start collecting this information and turning it in to the authorities, because > all of this is convered under domestic terrorism as a cyber-crime. I'm betting > there's reasons why he hasn't. He's afraid to get into trouble himself on some > of the content that's posted to /b/... whether it's there 5 seconds or 5 minutes. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ There you go right there. It's about the content. End of story. William -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-800-688-5018 From goemon at anime.net Mon Jul 27 00:58:28 2009 From: goemon at anime.net (goemon at anime.net) Date: Sun, 26 Jul 2009 22:58:28 -0700 (PDT) Subject: AT&T. Layer 6-8 needed. In-Reply-To: <1248673100.5698.7.camel@petrie> References: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> <4A6D197C.6070808@unwiredbb.com> <1248673100.5698.7.camel@petrie> Message-ID: On Mon, 27 Jul 2009, William Pitcock wrote: > On Sun, 2009-07-26 at 20:05 -0700, Shon Elliott wrote: >> There has been alot of customers on our network who were complaining about ACK >> scan reports coming from 207.126.64.181. We had no choice but to block that >> single IP until the attacks let up. It was a decision I made with the gentleman >> that owns the colo facility currently hosts 4chan. There was no other way around >> it. I'm sure AT&T is probably blocking it for the same reason. 4chan has been >> under attack for over 3 weeks, the attacks filling up an entire GigE. If you >> want to blame anyone, blame the script kiddies who pull this kind of stunt. > ...have you ever heard of forged packet headers? Just saying. everyone who *still* refuses to block spoofing should think hard about it. you know who you are. -Dan From goemon at anime.net Mon Jul 27 01:02:18 2009 From: goemon at anime.net (goemon at anime.net) Date: Sun, 26 Jul 2009 23:02:18 -0700 (PDT) Subject: questionable email filtering policies? In-Reply-To: <20090724001016.9461.qmail@simone.iecc.com> References: <20090724001016.9461.qmail@simone.iecc.com> Message-ID: On Thu, 24 Jul 2009, John Levine wrote: >>> >> I'm not sure which is worse: >> 1) That they filter their abuse mailbox. >> 2) That they outsource their abuse mailbox (and potentially others) to Yahoo. > BT outsources all of their mail to Yahoo. It actually works pretty well, > either POP or web mail. so far btopenworld.com looks like bullet proof phishing drop boxes, based on yahoo's cluefree response. anyone from yahoo with clue around? or is this a lost cause... -Dan From shon at unwiredbb.com Mon Jul 27 01:15:26 2009 From: shon at unwiredbb.com (Shon Elliott) Date: Sun, 26 Jul 2009 23:15:26 -0700 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <1248674313.13748.10.camel@petrie> References: <4A6D3D2B.7050001@unwiredbb.com> <1248674313.13748.10.camel@petrie> Message-ID: <4A6D45FE.6010008@unwiredbb.com> William Pitcock wrote: > On Sun, 2009-07-26 at 22:37 -0700, Shon Elliott wrote: >> chris rollin wrote: >>> Shon wrote: >>> >>> Seth, >>> >>>> I said it could be, not that it is. Thanks for pointing that out. However, >>> I >>>> believe the reason they are being blocked at AT&T is the main reason I >>> supplied >>>> on my first post. The DDoS attack issue is the main ticket here. >>> The ACK storms arent coming from the 4chan servers >>> It's just like the DNS attack (IN/NS/.). It points to the stupidity of AT&T >>> uppers >>> SANS: Are you or arent you soliciting data? I have some to confirm also >>> >> >> Actually, they are. They are returning responses to hundreds of thousands of >> SPOOFED SYN requests. Where do you think those are gonna go? The ACKs are gonna >> come back to the network in which IPs were SPOOFed from, essentially, causing a >> DDoS on a network not even really involved. > > {citation needed}. > > It is possible to send spoofed ACK responses without the SYN ever > happening in the first place. At any rate, you would think that if this > was really going on that status.4chan.org would have an update on the > topic. > Regardless of that, I have logs from firewalls to show that it's happening. So what, do I have to post them here to prove that it's happening? > It is widely known that AT&T loves censorship. They love censorship > because it is profitable for them to love censorship, and this isn't the > first time they have enmasse blocked access to a website they didn't > like. This has nothing at all to do with forged ACK responses, and > everything to do with content. > Yes, they do love censorship. I agree. You got me there.. But for ME it was about the forged ACK responses. I already lifted my block on it some time ago. It was temporary while I figured out some other ways to lessen the attack. > AT&T does not have the right to filter what their users can access, > period. You can put all the spin on it that you want, but in the end > it's about content. > I'm not putting any spin on why they did what they did. I'm just stating I know some of the facts and saying what I did and WHY I did it. > If this was about protecting their network, then they could do that in a > different way, period end of story. Maybe they can. I don't know the situation. For a small ISP such as us, we don't have a lot of alternatives. It's not like we're made of AT&T's billions of dollars. > >>>> It's not >>>> because of content, or to piss people off. It's to protect their network, >>> as any >>>> of you would do when you got DDoSed on your own networks. >>> They are going to get some first hand experience in what Protecting their >>> Network >>> involves real soon, now. Blocking 4chan was an exercise in Stupidity >>> >> >> Is that some kind of threat or what? Why would you even make a statement like that? > > Do not underestimate the power of teenagers living in their parents' > basement. There's a lot of them, and they can't access their favourite > website anymore. > > This is going to result in a lot of these families switching to Cable or > an alternative DSL provider. > I bet if half of the parents knew what their kids were doing on the internet... this wouldn't be a problem. >> >>>> It's damage control, >>> It's a damage challenge. >>> >>>> essentially, until they find out who is involved and block them, then >>> they'll >>>> likely lift the block. >>> They don't have the right to do this. Not in their TOS/EULA/User-Agreement. >>> Not in any sane legal forum. (I*A*AL) >>> >> They don't have the right to protect their network? So you're saying, if someone >> is DDoSing your network either direct or indirect, the network operator is just >> supposed to sit there and do nothing while all of it's customers get crappy >> internet service because of something they probably don't even know about or >> care about. > > They have the right to protect their network, but not at the cost of > reducing neutrality. But luckily we live in a free market, and AT&T is > about to lose a lot of business because of that block. If I were them, > I would fix it now, and be extremely apologetic about this happening. Okay, so how do YOU block the attacks from eating up your bandwidth and filling up your logs without blocking the entire IP? > >>>> This ISN'T the first time this has happened. >> Don't cut it off there. This ISN'T the first time it's happened, as 4chan goes >> through DDoSes from script kiddies on a regular basis, and it harms lots of >> networks along the way in the process. > > No, he means, this isn't the first time AT&T has degraded service as a > matter of policy. > I suppose that's possible. I've been on AT&T's network as a home user and have not really experienced that before. >>> Exactly. >>> >>> Now you see the problem ? >>> >> The problem is the DDoS attacks. Not AT&T. 4chan's users constantly instigate >> this. Chris Poole needs to do more than just sit back and watch. He needs to >> start collecting this information and turning it in to the authorities, because >> all of this is convered under domestic terrorism as a cyber-crime. I'm betting >> there's reasons why he hasn't. He's afraid to get into trouble himself on some >> of the content that's posted to /b/... whether it's there 5 seconds or 5 minutes. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > There you go right there. It's about the content. End of story. > No, the problem is that he won't do anything about it. I doubt AT&T is doing it for censorship reasons, but that's speculation on my part. But don't sit there and take the second half of my sentence to make a point like that. Chris CAN do something about it, he just won't. Why do you think that is? > William From nenolod at systeminplace.net Mon Jul 27 01:22:46 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 27 Jul 2009 01:22:46 -0500 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <4A6D45FE.6010008@unwiredbb.com> References: <4A6D3D2B.7050001@unwiredbb.com> <1248674313.13748.10.camel@petrie> <4A6D45FE.6010008@unwiredbb.com> Message-ID: <1248675766.13748.12.camel@petrie> On Sun, 2009-07-26 at 23:15 -0700, Shon Elliott wrote: > Okay, so how do YOU block the attacks from eating up your bandwidth > and filling > up your logs without blocking the entire IP? If I was AT&T, I would purchase DDoS filtering equipment and run it at edge where all of my traffic is peering anyway. This discussion is about AT&T, not you. William -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-800-688-5018 From 2600hz at gmail.com Mon Jul 27 01:25:30 2009 From: 2600hz at gmail.com (chris rollin) Date: Mon, 27 Jul 2009 01:25:30 -0500 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <1248673100.5698.7.camel@petrie> References: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> <4A6D197C.6070808@unwiredbb.com> <1248673100.5698.7.camel@petrie> Message-ID: Apparently not Back to the kids' table ! On Mon, Jul 27, 2009 at 12:38 AM, William Pitcock wrote: > On Sun, 2009-07-26 at 20:05 -0700, Shon Elliott wrote: > > There has been alot of customers on our network who were complaining > about ACK > > scan reports coming from 207.126.64.181. We had no choice but to block > that > > single IP until the attacks let up. > > ...have you ever heard of forged packet headers? Just saying. > > William > -- > William Pitcock > SystemInPlace - Simple Hosting Solutions > 1-800-688-5018 > > > From trelane at trelane.net Mon Jul 27 01:25:29 2009 From: trelane at trelane.net (Andrew D Kirch) Date: Mon, 27 Jul 2009 02:25:29 -0400 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <1248675766.13748.12.camel@petrie> References: <4A6D3D2B.7050001@unwiredbb.com> <1248674313.13748.10.camel@petrie> <4A6D45FE.6010008@unwiredbb.com> <1248675766.13748.12.camel@petrie> Message-ID: <4A6D4859.4040106@trelane.net> William Pitcock wrote: > On Sun, 2009-07-26 at 23:15 -0700, Shon Elliott wrote: > >> Okay, so how do YOU block the attacks from eating up your bandwidth >> and filling >> up your logs without blocking the entire IP? >> > > If I was AT&T, I would purchase DDoS filtering equipment and run it at > edge where all of my traffic is peering anyway. > > This discussion is about AT&T, not you. > > William > While I agree, I certainly believe that due to the nature of some of the content on 4chan, AT&T can make a strong "Good Samaritan" claim under 47USC230. There's always TOR. Andrew D Kirch From kody at vaserv.com Mon Jul 27 01:31:18 2009 From: kody at vaserv.com (Kody Riker) Date: Mon, 27 Jul 2009 02:31:18 -0400 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <4A6D4859.4040106@trelane.net> References: <4A6D3D2B.7050001@unwiredbb.com> <1248674313.13748.10.camel@petrie> <4A6D45FE.6010008@unwiredbb.com> <1248675766.13748.12.camel@petrie> <4A6D4859.4040106@trelane.net> Message-ID: <004001ca0e83$dc12e190$9438a4b0$@com> Seems that ATT has restored access to 4chan as confirmed on http://www.centralgadget.com/att-blocking-access-to-portions-of-4chan-2336/ and on an IRC I happened to be idleing in. -- Kody Riker Level II VAServ Ltd -----Original Message----- From: Andrew D Kirch [mailto:trelane at trelane.net] Sent: Monday, July 27, 2009 2:25 AM To: William Pitcock Cc: nanog - n. am. network ops group list Subject: Re: AT&T. Layer 6-8 needed. William Pitcock wrote: > On Sun, 2009-07-26 at 23:15 -0700, Shon Elliott wrote: > >> Okay, so how do YOU block the attacks from eating up your bandwidth >> and filling >> up your logs without blocking the entire IP? >> > > If I was AT&T, I would purchase DDoS filtering equipment and run it at > edge where all of my traffic is peering anyway. > > This discussion is about AT&T, not you. > > William > While I agree, I certainly believe that due to the nature of some of the content on 4chan, AT&T can make a strong "Good Samaritan" claim under 47USC230. There's always TOR. Andrew D Kirch From shon at unwiredbb.com Mon Jul 27 01:37:33 2009 From: shon at unwiredbb.com (Shon Elliott) Date: Sun, 26 Jul 2009 23:37:33 -0700 Subject: AT&T. Layer 6-8 needed. In-Reply-To: References: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> <4A6D197C.6070808@unwiredbb.com> <1248673100.5698.7.camel@petrie> Message-ID: <4A6D4B2D.40901@unwiredbb.com> Chris, Have you even read any of the other posts on here. I have been talking about spoofed packets in this thread multiple times. I do know what it is. I would appreciate you not making stupid comments like that. chris rollin wrote: > Apparently not > > Back to the kids' table ! > > > On Mon, Jul 27, 2009 at 12:38 AM, William Pitcock > > wrote: > > On Sun, 2009-07-26 at 20:05 -0700, Shon Elliott wrote: > > There has been alot of customers on our network who were > complaining about ACK > > scan reports coming from 207.126.64.181. We had no choice but to > block that > > single IP until the attacks let up. > > ...have you ever heard of forged packet headers? Just saying. > > William > -- > William Pitcock > SystemInPlace - Simple Hosting Solutions > 1-800-688-5018 > > > From 2600hz at gmail.com Mon Jul 27 01:41:07 2009 From: 2600hz at gmail.com (chris rollin) Date: Mon, 27 Jul 2009 01:41:07 -0500 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <4A6D4859.4040106@trelane.net> References: <4A6D3D2B.7050001@unwiredbb.com> <1248674313.13748.10.camel@petrie> <4A6D45FE.6010008@unwiredbb.com> <1248675766.13748.12.camel@petrie> <4A6D4859.4040106@trelane.net> Message-ID: This only protects ISPs from, upon being served notice, being liable for content A majority of the CDA was overturned, as it violates both first and fifth amendments. What is left of it only applies to ISPs PUBLISHING (*not* filtering) content This is Net Neutrality realm On Mon, Jul 27, 2009 at 1:25 AM, Andrew D Kirch wrote: > William Pitcock wrote: > > On Sun, 2009-07-26 at 23:15 -0700, Shon Elliott wrote: > > > >> Okay, so how do YOU block the attacks from eating up your bandwidth > >> and filling > >> up your logs without blocking the entire IP? > >> > > > > If I was AT&T, I would purchase DDoS filtering equipment and run it at > > edge where all of my traffic is peering anyway. > > > > This discussion is about AT&T, not you. > > > > William > > > While I agree, I certainly believe that due to the nature of some of the > content > on 4chan, AT&T can make a strong "Good Samaritan" claim under 47USC230. > There's > always TOR. > > > Andrew D Kirch > > From 2600hz at gmail.com Mon Jul 27 02:09:00 2009 From: 2600hz at gmail.com (chris rollin) Date: Mon, 27 Jul 2009 02:09:00 -0500 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <4A6D4B2D.40901@unwiredbb.com> References: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> <4A6D197C.6070808@unwiredbb.com> <1248673100.5698.7.camel@petrie> <4A6D4B2D.40901@unwiredbb.com> Message-ID: On Mon, Jul 27, 2009 at 1:37 AM, Shon Elliott wrote: > > Chris, > > Have you even read any of the other posts on here. I fade in and out > > I have been talking about > spoofed packets in this thread multiple times. man engrish > > I do know what it is. I would?appreciate you not making stupid comments like that. As was stated before, this?isnt?about?you In other news, it looks like ATT is quietly removing filters from cities. ?Chicago still showing down From alexb at ripe.net Mon Jul 27 02:10:59 2009 From: alexb at ripe.net (Alex Band) Date: Mon, 27 Jul 2009 09:10:59 +0200 Subject: New IPv6 interview: Google on ipv6.google.com Message-ID: <1925094F-5FAF-439D-98CA-570487BF401E@ripe.net> Lorenzo Colitti, network engineer at Google, discusses the implementation of IPv6, which resulted in the launch of ipv6.google.com. He talks about the feedback they have received, future plans for making Google services available over IPv6 and what advice he would give to other companies. http://www.youtube.com/watch?v=vFwStbTpr6E Cheers, Alex Band RIPE NCC From tb at tburke.us Mon Jul 27 02:15:27 2009 From: tb at tburke.us (Tim Burke) Date: Mon, 27 Jul 2009 02:15:27 -0500 Subject: AT&T. Layer 6-8 needed. In-Reply-To: References: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> <4A6D197C.6070808@unwiredbb.com> <1248673100.5698.7.camel@petrie> <4A6D4B2D.40901@unwiredbb.com> Message-ID: <009f01ca0e8a$048bb1a0$0da314e0$@us> Appears to be up from here - I'm in suburban Chicago. traceroute to img.4chan.org (207.126.64.181), 30 hops max, 40 byte packets 1 172.31.129.1 (172.31.129.1) 0.602 ms 1.383 ms 1.638 ms 2 172.31.128.1 (172.31.128.1) 7.337 ms 10.254 ms 10.638 ms 3 192.168.0.1 (192.168.0.1) 17.694 ms 18.092 ms 18.473 ms 4 adsl-99-135-157-254.dsl.emhril.sbcglobal.net (99.135.157.254) 19.318 ms 20.903 ms 22.319 ms 5 68.250.251.2 (68.250.251.2) 24.326 ms 25.967 ms 27.654 ms 6 bb2-g9-0.emhril.sbcglobal.net (151.164.94.164) 29.195 ms 11.296 ms 16.196 ms 7 * * * 8 te7-2.ccr02.ord03.atlas.cogentco.com (154.54.11.237) 17.772 ms 19.221 ms 21.926 ms 9 * * * 10 * * * 11 te9-4.mpd01.dfw01.atlas.cogentco.com (154.54.5.217) 56.902 ms 59.571 ms 60.826 ms 12 te8-3.mpd01.dfw03.atlas.cogentco.com (66.28.4.174) 46.897 ms te7-3.mpd01.dfw03.atlas.cogentco.com (154.54.6.66) 46.735 ms te4-3.mpd01.dfw03.atlas.cogentco.com (154.54.6.58) 46.319 ms 13 38.104.35.234 (38.104.35.234) 46.997 ms 34.910 ms 35.444 ms 14 * * * 15 * * * -----Original Message----- From: chris rollin [mailto:2600hz at gmail.com] Sent: Monday, July 27, 2009 2:09 AM To: Shon Elliott Cc: nanog at nanog.org >> nanog Subject: Re: AT&T. Layer 6-8 needed. On Mon, Jul 27, 2009 at 1:37 AM, Shon Elliott wrote: > > Chris, > > Have you even read any of the other posts on here. I fade in and out > > I have been talking about > spoofed packets in this thread multiple times. man engrish > > I do know what it is. I would?appreciate you not making stupid comments like that. As was stated before, this?isnt?about?you In other news, it looks like ATT is quietly removing filters from cities. ?Chicago still showing down From sthaug at nethelp.no Mon Jul 27 01:39:30 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Mon, 27 Jul 2009 08:39:30 +0200 (CEST) Subject: questionable email filtering policies? In-Reply-To: References: <20090724001016.9461.qmail@simone.iecc.com> Message-ID: <20090727.083930.74736205.sthaug@nethelp.no> > > BT outsources all of their mail to Yahoo. It actually works pretty well, > > either POP or web mail. > > so far btopenworld.com looks like bullet proof phishing drop boxes, based > on yahoo's cluefree response. How about writing to Bruce Schneier and explaining the problem? He's Chief Security Technology Officer at BT. http://www.schneier.com/ Steinar Haug, Nethelp consulting, sthaug at nethelp.no From eslerj at gmail.com Mon Jul 27 08:05:42 2009 From: eslerj at gmail.com (Joel Esler) Date: Mon, 27 Jul 2009 09:05:42 -0400 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <4A6D38CC.6000200@gmail.com> References: <4A6D3856.7050706@gmail.com> <4A6D38CC.6000200@gmail.com> Message-ID: <39774CB6-A190-4E3B-A5E6-FD5D85EAB891@gmail.com> I posted it on Twitter. And I was talking with John at the time. We're observing the information that is coming in, but it's hard to verify something like that when: A) We haven't heard from our contacts at AT&T. B) The only information we are seeing "confirming" it is on open mailing lists, and no offense, but given 4chan's proclivity in spreading disinformation extremely well.... C) I don't know if we want to take the word of moot directly from the 4chan website either. I've read in a couple places that the connectivity is coming back up, I have a hard time believing that AT&T would do this, and even if they did, they did it for a legit reason (maybe a DDOS?) J On Jul 27, 2009, at 1:19 AM, John Bambenek wrote: > Someone else posted on twitter, I saw it recently. > > To make it even clearer, we'll take your data, sure. Just don't > expect us to jump on it until we verify with something solid. > > chris rollin wrote: >> Uh. >> >> You posted on Twitter. >> >> The most trusted name in [?] >> >> On Mon, Jul 27, 2009 at 12:17 AM, John Bambenek > > wrote: >> >> We'll take data from **Trusted** sources. >> >> I'm just not going to take a public open mailing list post as >> evidence at this point. >> >> >> chris rollin wrote: >> >> Shon wrote: >> >> Seth, >> >> >> I said it could be, not that it is. Thanks for pointing >> that out. However, >> >> I >> >> believe the reason they are being blocked at AT&T is the >> main reason I >> >> supplied >> >> on my first post. The DDoS attack issue is the main ticket >> here. >> >> >> The ACK storms arent coming from the 4chan servers >> It's just like the DNS attack (IN/NS/.). It points to the >> stupidity of AT&T >> uppers >> SANS: Are you or arent you soliciting data? I have some to >> confirm also >> >> >> It's not >> because of content, or to piss people off. It's to protect >> their network, >> >> as any >> >> of you would do when you got DDoSed on your own networks. >> >> >> They are going to get some first hand experience in what >> Protecting their >> Network >> involves real soon, now. Blocking 4chan was an exercise in >> Stupidity >> >> >> It's damage control, >> >> >> It's a damage challenge. >> >> >> essentially, until they find out who is involved and block >> them, then >> >> they'll >> >> likely lift the block. >> >> >> They don't have the right to do this. Not in their >> TOS/EULA/User-Agreement. >> Not in any sane legal forum. (I*A*AL) >> >> >> This ISN'T the first time this has happened. >> >> >> Exactly. >> >> Now you see the problem ? >> >> >> > > -- Joel Esler ? http://www.joelesler.net ? http://www.twitter.com/joelesler [m] From jlewis at lewis.org Mon Jul 27 08:24:55 2009 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 27 Jul 2009 09:24:55 -0400 (EDT) Subject: AT&T. Layer 6-8 needed. In-Reply-To: <6ff30abd0907262135l17d3c807o6366ed8810cf9b03@mail.gmail.com> References: <6ff30abd0907261848w37a92157w12fb8170c8cfdb54@mail.gmail.com> <4A6D197C.6070808@unwiredbb.com> <6ff30abd0907262011x6d222993ma8f3b350dec050b2@mail.gmail.com> <4A6D1CFF.5090901@unwiredbb.com> <6ff30abd0907262135l17d3c807o6366ed8810cf9b03@mail.gmail.com> Message-ID: On Sun, 26 Jul 2009, jamie wrote: > If any ISP of mine filtered my (where my = brick-and-mortar-corp) access to > any destination because of another customer (there are *always* technical > solutions to problems you describe, the one you implemented wouldn't even > make my list), you'd have one less customer and quite likely a Tortious > Interference claim.. I don't know if they still do it, or if their old "Abuse/Security guy, Travis Haymore" is still around, but above.net had a history of null routing "destinations they didn't like", which meant if you were a customer (even a multihomed one) and sent them traffic for those destinations, you wouldn't get there. Getting the list of null routed space from above.net was not trivial. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jzp-sc at rsuc.gweep.net Mon Jul 27 08:29:32 2009 From: jzp-sc at rsuc.gweep.net (Joe Provo) Date: Mon, 27 Jul 2009 09:29:32 -0400 Subject: [NANOG-announce] NANOG Election Time line 2009 Message-ID: <20090727132931.GA87768@gweep.net> Hello NANOGers! Per the charter (http://nanog.org/governance/charter/), we are approaching the annual NANOG election and appointment time. In addition to the series of "call for nominations" messages at the opening of each period, we thought to send an overview and time line ahead of the actual nominations opening. Hopefully this will get more of the eligible members of the community to consider standing for a role in one of the Committees that helps makes NANOG what it is. = NANOG Steering Committee The NANOG Steering Committee works closely with Merit to promote, support and improve NANOG. The Steering Committee is responsible for the selection of the Program Committee and the Mailing List Committee, and is the community's instrument for ensuring that the NANOG organization remains open, relevant and useful. Elections for three of the seven positions on the Steering Committee will be held in October 2009. The currently-serving Steering Committee members whose terms are expiring are Steve Feldman, Jared Mauch and Chris Morrow. Chris has served two consecutive terms so per the charter, he cannot be considered for re-election until October 2010. There are no restrictions on eligible candidates, but Steering Committee members must commit to attending two out of every three annual NANOG meetings per the charter (6.2.6). A good candidate will have experience with Internet engineering, operations, and governance organizations as well as the principles and practices which guide them. Consensus organizing, leadership, outreach and communication skills are prized. = NANOG Program Committee The Program Committee is a group of sixteen individuals from the NANOG community who together are responsible for the solicitation and selection of material for NANOG meeting Programs. A new Program Committee will be selected by the Steering Committee after the election in October. Eight positions are to be filled. The currently-serving Program Committee members whose terms are expiring are Joel Jaeggli, Rodney Joffe, Sylvie LaPerriere, Kevin Oberman, Lane Patterson, Ren Provo, Josh Snowhorn and Todd Underwood. Furthermore, Joel, Ren, Josh and Todd have all served two consecutive terms so per the charter, they cannot be considered for another Program Committee appointment until October 2010. Per the NANOG charter (6.2.1), eligible candidates are individuals who have attended at least one NANOG meeting in the past 12 months (one or more of NANOG 45, NANOG 46 or NANOG 47). Broad technical knowledge of Internet operations and familiarity with NANOG meetings are useful attributes. Having constructive opinions and ideas about how NANOG meetings might be improved is of high value. = NANOG Mailing List Committee The Mailing List Committee is a group of five individuals from the NANOG community who together are responsible for the administration and moderation of the NANOG mailing lists. A new Mailing List Committee will be selected by the Steering Committee after the election in October. Two positions are to be filled. The currently-serving Mailing List Committee members whose terms are expiring are Kris Foster and Simon Lyall. The main NANOG mailing list serves an important role in the community by providing a day-to-day forum for network operators. Participating in the MLC gives you the opportunity to make a noticeable contribution. The MLC is covered under section 7.1.2 of the NANOG charter. = Why? If you care about NANOG as a set of fora and think you would like to take a turn at volunteering your time to help make it better, please consider either volunteering yourself or nominating someone else. For more information about the role of any Committee, or to find out more about what's involved in being a Committee member, please do consult the current NANOG charter or contact someone who is already serving and ask them directly: http://nanog.org/governance/steering/steeringcommittee.php http://nanog.org/governance/program/programcommittee.php http://nanog.org/mailinglist/listadmins/ = Time Line Mon 2009-08-17 Call for Steering Committee nominations Tue 2009-09-08 Call for Program Committee nominations Mon 2009-09-14 SC nominations close Mon 2009-09-28 Call for Mailing List Committee nominations Sun 2009-10-18 Voting for the 2009/2010 NANOG SC opens at 12:00 EDT Mon 2009-10-19 PC nominations close Wed 2009-10-21 Voting for the 2009/2010 NANOG SC closes at 13:00 EDT Thu 2009-10-22 New PC appointed Thu 2009-10-29 MLC nominations close Tue 2009-11-03 New MLC appointed Cheers! Joe Provo on behalf of the NANOG Steering Committee -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From jlewis at lewis.org Mon Jul 27 08:58:10 2009 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 27 Jul 2009 09:58:10 -0400 (EDT) Subject: AT&T. Layer 6-8 needed. In-Reply-To: <1248674313.13748.10.camel@petrie> References: <4A6D3D2B.7050001@unwiredbb.com> <1248674313.13748.10.camel@petrie> Message-ID: On Mon, 27 Jul 2009, William Pitcock wrote: > It is widely known that AT&T loves censorship. They love censorship > because it is profitable for them to love censorship, and this isn't the > first time they have enmasse blocked access to a website they didn't > like. This has nothing at all to do with forged ACK responses, and > everything to do with content. How does breaking things (censorship) make them more money? http://njabl.org/faq.html#Q12 > AT&T does not have the right to filter what their users can access, > period. You can put all the spin on it that you want, but in the end > it's about content. Whatever happened to "My network, my rules?" If AT&T blocks something, and as an AT&T customer, you don't like it, get your connectivity from someone else. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bambenek at gmail.com Mon Jul 27 09:04:19 2009 From: bambenek at gmail.com (John C. A. Bambenek) Date: Mon, 27 Jul 2009 09:04:19 -0500 Subject: AT&T. Layer 6-8 needed. In-Reply-To: References: <4A6D3D2B.7050001@unwiredbb.com> <1248674313.13748.10.camel@petrie> Message-ID: Because most of the net libertarians insist that they should do whatever they want and everyone else should help cater to them. Liberty for me but not for thee. On 7/27/09, Jon Lewis wrote: > On Mon, 27 Jul 2009, William Pitcock wrote: > >> It is widely known that AT&T loves censorship. They love censorship >> because it is profitable for them to love censorship, and this isn't the >> first time they have enmasse blocked access to a website they didn't >> like. This has nothing at all to do with forged ACK responses, and >> everything to do with content. > > How does breaking things (censorship) make them more money? > > http://njabl.org/faq.html#Q12 > >> AT&T does not have the right to filter what their users can access, >> period. You can put all the spin on it that you want, but in the end >> it's about content. > > Whatever happened to "My network, my rules?" If AT&T blocks something, > and as an AT&T customer, you don't like it, get your connectivity from > someone else. > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > -- Sent from my mobile device From patrick at ianai.net Mon Jul 27 09:10:57 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 27 Jul 2009 10:10:57 -0400 Subject: AT&T. Layer 6-8 needed. In-Reply-To: References: <4A6D3D2B.7050001@unwiredbb.com> <1248674313.13748.10.camel@petrie> Message-ID: On Jul 27, 2009, at 10:04 AM, John C. A. Bambenek wrote: > Because most of the net libertarians insist that they should do > whatever they want and everyone else should help cater to them. > > Liberty for me but not for thee. I am very much of the "my network, my rules" camp. As soon as att pays back all the gov't subsidies, tax credits, etc., - we- paid them, they can call it -their- network. Until then, things are a lot murkier. -- TTFN, patrick > On 7/27/09, Jon Lewis wrote: >> On Mon, 27 Jul 2009, William Pitcock wrote: >> >>> It is widely known that AT&T loves censorship. They love censorship >>> because it is profitable for them to love censorship, and this >>> isn't the >>> first time they have enmasse blocked access to a website they didn't >>> like. This has nothing at all to do with forged ACK responses, and >>> everything to do with content. >> >> How does breaking things (censorship) make them more money? >> >> http://njabl.org/faq.html#Q12 >> >>> AT&T does not have the right to filter what their users can access, >>> period. You can put all the spin on it that you want, but in the >>> end >>> it's about content. >> >> Whatever happened to "My network, my rules?" If AT&T blocks >> something, >> and as an AT&T customer, you don't like it, get your connectivity >> from >> someone else. >> >> ---------------------------------------------------------------------- >> Jon Lewis | I route >> Senior Network Engineer | therefore you are >> Atlantic Net | >> _________ http://www.lewis.org/~jlewis/pgp for PGP public >> key_________ >> >> > > -- > Sent from my mobile device > From David_Hiers at adp.com Mon Jul 27 10:22:06 2009 From: David_Hiers at adp.com (Hiers, David) Date: Mon, 27 Jul 2009 10:22:06 -0500 Subject: AT&T. Layer 6-8 needed. In-Reply-To: References: <4A6D3D2B.7050001@unwiredbb.com> <1248674313.13748.10.camel@petrie> Message-ID: <81CDFC77FB2DC54DB875D4F8FFC36CE00A92089C42@DSMAIL2HE.ds.ad.adp.com> I"m not a lawyer, but I think that the argument goes something like this... The common carriers want to be indemnified from the content they carry. In other words, the phone company doesn't want to be held liable for the Evil Plot planned over their phone lines. The price they pay for indemnification is that they must not care about ANY content (including content that competes with content offered by a non-carrier division of the common carrier). If they edit SOME content, then they are acting in the role of a newspaper editor, and have assumed the mantle of responsibility for ALL content. Carriers can, however, do what they need to do to keep their networks running, so they are permitted disrupt traffic that is damaging to the network. The seedy side of all of this is that if a common carrier wants to block a particular set of content from a site/network, all they need to do is point out some technical badness that comes from the same general direction. Since the background radiation of technical badness is fairly high from every direction, it's not too hard to find a good excuse when you want one. David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 -----Original Message----- From: Jon Lewis [mailto:jlewis at lewis.org] Sent: Monday, July 27, 2009 6:58 AM To: William Pitcock Cc: nanog - n. am. network ops group list Subject: Re: AT&T. Layer 6-8 needed. On Mon, 27 Jul 2009, William Pitcock wrote: > It is widely known that AT&T loves censorship. They love censorship > because it is profitable for them to love censorship, and this isn't > the first time they have enmasse blocked access to a website they > didn't like. This has nothing at all to do with forged ACK responses, > and everything to do with content. How does breaking things (censorship) make them more money? http://njabl.org/faq.html#Q12 > AT&T does not have the right to filter what their users can access, > period. You can put all the spin on it that you want, but in the end > it's about content. Whatever happened to "My network, my rules?" If AT&T blocks something, and as an AT&T customer, you don't like it, get your connectivity from someone else. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. From patrick at ianai.net Mon Jul 27 10:34:52 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 27 Jul 2009 11:34:52 -0400 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <81CDFC77FB2DC54DB875D4F8FFC36CE00A92089C42@DSMAIL2HE.ds.ad.adp.com> References: <4A6D3D2B.7050001@unwiredbb.com> <1248674313.13748.10.camel@petrie> <81CDFC77FB2DC54DB875D4F8FFC36CE00A92089C42@DSMAIL2HE.ds.ad.adp.com> Message-ID: <276D7E82-2C3F-44FF-A9EA-E9799A5D150B@ianai.net> On Jul 27, 2009, at 11:22 AM, Hiers, David wrote: > I"m not a lawyer, but I think that the argument goes something like > this... > > The common carriers want to be indemnified from the content they > carry. In other words, the phone company doesn't want to be held > liable for the Evil Plot planned over their phone lines. The price > they pay for indemnification is that they must not care about ANY > content (including content that competes with content offered by a > non-carrier division of the common carrier). If they edit SOME > content, then they are acting in the role of a newspaper editor, and > have assumed the mantle of responsibility for ALL content. Famous two cases, Prodigy & Compuserve. Overturned many years ago. If you edit "some" content you are not automatically liable for all content. No ISP is a common carrier. That implies things like "you must provide service to everyone". Some common carriers get orders like "you must provide service in $MIDDLE_OF_NOWHERE". ISPs can, under certain circumstances, get a "mere conduit" style immunity. > Carriers can, however, do what they need to do to keep their > networks running, so they are permitted disrupt traffic that is > damaging to the network. > > The seedy side of all of this is that if a common carrier wants to > block a particular set of content from a site/network, all they need > to do is point out some technical badness that comes from the same > general direction. Since the background radiation of technical > badness is fairly high from every direction, it's not too hard to > find a good excuse when you want one. That, I believe, is much harder. But IANAL. Hell, I Am Not An ISP even. :) -- TTFN, patrick From jtk at cymru.com Mon Jul 27 10:47:43 2009 From: jtk at cymru.com (John Kristoff) Date: Mon, 27 Jul 2009 10:47:43 -0500 Subject: finding open resolvers Message-ID: <20090727104743.4046aeb1@t61p> Hi folks, We're interested in finding open resolvers and reporting on them. There is already a list specific to dns-ops, so I'll just point you there if this topic is of interest. I recommend follow ups go there or privately. Thank you, John From scg at gibbard.org Mon Jul 27 13:28:31 2009 From: scg at gibbard.org (Steve Gibbard) Date: Mon, 27 Jul 2009 11:28:31 -0700 (PDT) Subject: Recommendations for Hong Kong datacenter, and a sanity check for my geopolitical conclusions ? In-Reply-To: <834941.40938.qm@web111612.mail.gq1.yahoo.com> References: <834941.40938.qm@web111612.mail.gq1.yahoo.com> Message-ID: My take on this would be that DNS especially, and the volume of mail that can be handled via a few 1 and 2u servers, are pretty easy to duplicate. As such, I suspect you're overthinking some of the risk management pieces. In any of the places you mentioned, you're more likely to have random accidental power or network connectivity outages than to be dislodged by a tsunami, hurricane, or military coup. No matter where you go, if you design your service such that it can fail over to your network sites elsewhere in the world, you should be fine. I ran a 30-location DNS network that included servers in some fairly unstable places for about four years. Power outages in one location or another happened a couple times a week sometimes. The ones we worried about were the ones where the equipment didn't successfully reboot itself afterward. Hardware failures happened periodically -- again often enough that I don't have a clear count. We had one location that we lost connectivity to due to a coup for maybe a week, once. The real questions to be asking are where you'll get the best network connectivity and support. For network connectivity, Hong Kong, Singapore, and Tokyo will all be decent choices. Tokyo can be difficult if you don't have a Japanese speaker on staff. Hong Kong and Singapore are both full of people who speak good English. Last time I looked at it, transit connectivity was cheaper in Hong Kong. Peering was easier in Hong Kong as well, since everybody was on the HKIX rather than being split between two exchanges (SOX and Equinix) as they were in Singapore. But it's been a few years since I've dealt with stuff in either place, so the situation may have changed. As for facilities, my usual shopping technique is to figure out who I want to connect to, figure out where they are, and then figure out which building has the best combination of price and remote hands support. If there are any discernable differences in the level of back-up power they provide, you may want to take that into consideration too. And then remember, your equipment will be far away. Things will happen to it that you don't expect. Some of those will be hard to fix from a distance. Make sure you're able to fail over to equipment in other places if you need to, because if you do this enough, you will lose a site somewhere eventually. -Steve On Fri, 24 Jul 2009, George Sanders wrote: > > > I will be expanding a small network infrastructure service (read: DNS > and mail ... a few 1u and 2u servers) to Hong Kong next year. > > We don't have any particular customer base in Hong Kong - rather, we > have customers all over southeast asia and would like to serve them > better, as well as attract more SE Asia customers. > > I chose Hong Kong for the following reasons: > > - South Korea is alternately happy with / upset with Japan, and I don't > want to deal with that > > - Japan is is alternately happy with / upset with South Korea, and I > don't want to deal with that > > - Mainland China is out of the question, for obvious reasons > > - The smaller (Thailand, Vietnamese, Phillipines, etc.) countries all > have their own particular issues (recent coup in Thailand, etc.) > > So the choice came down to Hong Kong or Singapore, and I chose Hong Kong > because it seems easier to "just get things done" there. I realize that > in the long term there is a greater risk of social paradigm shift in > Hong Kong because of mainland China, but in the short run it seems that > Hong Kong is more "functional" than Singapore. > > Any comments on the above thought process ? > > > The obvious follow-up is, which datacenter ? > > I need a full service center that will give me rackspace and let me just > plug ethernet into their switch. I am not interested in brokering my > own connectivity, nor am I interested in running my own routers. I want > to pay one bill to one organization and get one cable. The end. > > I think there are further considerations though ... I read details of > one very modern, very sexy datacenter housed in a skyscraper, but my > research showed me that this building has been built on land reclaimed > from the sea, and there is reasonable concern that the sand > underpinnings could liquify, to a degree, in a seismic event. I'd also > like to be more than a few feet above sea level. Honestly, as sexy as > it would be to be in a slick tower right on the bay in Central Hong > Kong, I would much rather find some nondescript, one story building, > miles from the coast and a few hundred feet above sea level. > > What recommendations might someone have ? > > Thank you very much for any comments or suggestions you may have. > From richard at bennett.com Mon Jul 27 16:25:43 2009 From: richard at bennett.com (Richard Bennett) Date: Mon, 27 Jul 2009 14:25:43 -0700 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <276D7E82-2C3F-44FF-A9EA-E9799A5D150B@ianai.net> References: <4A6D3D2B.7050001@unwiredbb.com> <1248674313.13748.10.camel@petrie><81CDFC77FB2DC54DB875D4F8FFC36CE00A92089C42@DSMAIL2HE.ds.ad.adp.com> <276D7E82-2C3F-44FF-A9EA-E9799A5D150B@ianai.net> Message-ID: <4D8EE8D5295A4E6C837103F209DBD799@Honkin> I'm not a lawyer either, but I know how ISPs are regulated in the US. The actual framework is the FCC's "Internet Policy Statement," to wit: http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-05-151A1.pdf . To encourage broadband deployment and preserve and promote the open and interconnected nature of the public Internet, consumers are entitled to access the lawful Internet content of their choice. . To encourage broadband deployment and preserve and promote the open and interconnected nature of the public Internet, consumers are entitled to run applications and use services of their choice, subject to the needs of law enforcement. . To encourage broadband deployment and preserve and promote the open and interconnected nature of the public Internet, consumers are entitled to connect their choice of legal devices that do not harm the network.13 . To encourage broadband deployment and preserve and promote the open and interconnected nature of the public Internet, consumers are entitled to competition among network providers, application and service providers, and content providers.14 All of this is subject to a "reasonable network management" exception. There is some disagreement about what consitututes "reasonable network management" at the fringes, but the FCC is on record that spam killing and DDOS attack mitigation are "reasonable." Some people want to add a fifth "non-discrimination" rule. In the case of the ISPs and carriers who blocked access to 4chan for a while Sunday, since that was done in accordance with DDOS mitigation, there's not any issue as far as the FCC is concerned, but that hasn't prevented the usual parties from complaining about censorship, etc. Richard Bennett -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: Monday, July 27, 2009 8:35 AM To: nanog - n. am. network ops group list Subject: Re: AT&T. Layer 6-8 needed. On Jul 27, 2009, at 11:22 AM, Hiers, David wrote: > I"m not a lawyer, but I think that the argument goes something like > this... > > The common carriers want to be indemnified from the content they > carry. In other words, the phone company doesn't want to be held > liable for the Evil Plot planned over their phone lines. The price > they pay for indemnification is that they must not care about ANY > content (including content that competes with content offered by a > non-carrier division of the common carrier). If they edit SOME > content, then they are acting in the role of a newspaper editor, and > have assumed the mantle of responsibility for ALL content. Famous two cases, Prodigy & Compuserve. Overturned many years ago. If you edit "some" content you are not automatically liable for all content. No ISP is a common carrier. That implies things like "you must provide service to everyone". Some common carriers get orders like "you must provide service in $MIDDLE_OF_NOWHERE". ISPs can, under certain circumstances, get a "mere conduit" style immunity. > Carriers can, however, do what they need to do to keep their networks > running, so they are permitted disrupt traffic that is damaging to the > network. > > The seedy side of all of this is that if a common carrier wants to > block a particular set of content from a site/network, all they need > to do is point out some technical badness that comes from the same > general direction. Since the background radiation of technical > badness is fairly high from every direction, it's not too hard to find > a good excuse when you want one. That, I believe, is much harder. But IANAL. Hell, I Am Not An ISP even. :) -- TTFN, patrick From sethm at rollernet.us Mon Jul 27 17:00:05 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 27 Jul 2009 15:00:05 -0700 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <4D8EE8D5295A4E6C837103F209DBD799@Honkin> References: <4A6D3D2B.7050001@unwiredbb.com> <1248674313.13748.10.camel@petrie><81CDFC77FB2DC54DB875D4F8FFC36CE00A92089C42@DSMAIL2HE.ds.ad.adp.com> <276D7E82-2C3F-44FF-A9EA-E9799A5D150B@ianai.net> <4D8EE8D5295A4E6C837103F209DBD799@Honkin> Message-ID: <4A6E2365.3050901@rollernet.us> Richard Bennett wrote: > > In the case of the ISPs and carriers who blocked access to 4chan for a while > Sunday, since that was done in accordance with DDOS mitigation, there's not > any issue as far as the FCC is concerned, but that hasn't prevented the > usual parties from complaining about censorship, etc. > If someone came out and said "Hey, DDOS mitigation, please hold!" that would be cool, too. Based on the content of 4chan, it's either DDOS or someone cried about the content. It looked like the latter. ~Seth From richard at bennett.com Mon Jul 27 17:23:04 2009 From: richard at bennett.com (Richard Bennett) Date: Mon, 27 Jul 2009 15:23:04 -0700 Subject: AT&T. Layer 6-8 needed. In-Reply-To: <4A6E2365.3050901@rollernet.us> References: <4A6D3D2B.7050001@unwiredbb.com> <1248674313.13748.10.camel@petrie><81CDFC77FB2DC54DB875D4F8FFC36CE00A92089C42@DSMAIL2HE.ds.ad.adp.com> <276D7E82-2C3F-44FF-A9EA-E9799A5D150B@ianai.net><4D8EE8D5295A4E6C837103F209DBD799@Honkin> <4A6E2365.3050901@rollernet.us> Message-ID: Corporate PR staffs don't generally work on Sunday, but when AT&T came into the office today they drafted this statement: http://www.att.com/gen/press-room?pid=4800&cdvn=news&newsarticleid=26970 "Beginning Friday, an AT&T customer was impacted by a denial-of-service attack stemming from IP addresses connected to img.4chan.org. To prevent this attack from disrupting service for the impacted AT&T customer, and to prevent the attack from spreading to impact our other customers, AT&T temporarily blocked access to the IP addresses in question for our customers. This action was in no way related to the content at img.4chan.org; our focus was on protecting our customers from malicious traffic. "Overnight Sunday, after we determined the denial-of-service threat no longer existed, AT&T removed the block on the IP addresses in question. We will continue to monitor for denial-of-service activity and any malicious traffic to protect our customers. "Here's more (http://budurl.com/DDoSVideo) on AT&T's efforts to prevent denial-of-service attacks." There's obviously a history of DOS attacks to and from 4chan and the membership over the years, some of it quite righteous. The "Anonymous" attacks against the Cult of Scientology, for example, were very sweet. But all you have to do is read the status page that moot posts on 4chan to realize that they've been the target of a counter-attack for past three weeks or so. Richard Bennett -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Monday, July 27, 2009 3:00 PM To: 'nanog - n. am. network ops group list' Subject: Re: AT&T. Layer 6-8 needed. Richard Bennett wrote: > > In the case of the ISPs and carriers who blocked access to 4chan for a > while Sunday, since that was done in accordance with DDOS mitigation, > there's not any issue as far as the FCC is concerned, but that hasn't > prevented the usual parties from complaining about censorship, etc. > If someone came out and said "Hey, DDOS mitigation, please hold!" that would be cool, too. Based on the content of 4chan, it's either DDOS or someone cried about the content. It looked like the latter. ~Seth From chewtoy at s8n.net Tue Jul 28 05:50:02 2009 From: chewtoy at s8n.net (Russell Heilling) Date: Tue, 28 Jul 2009 11:50:02 +0100 Subject: Anomalies with AS13214 ? In-Reply-To: <4426C119-52FA-4D3D-9BD5-00CEC831D964@cs.ucla.edu> References: <4A08448A.7020403@west.net> <4426C119-52FA-4D3D-9BD5-00CEC831D964@cs.ucla.edu> Message-ID: <647fc4230907280350m47603268y392b460240d0d473@mail.gmail.com> 2009/5/11 Ricardo Oliveira : > Hi all, > > First, thanks for using Cyclops, and thanks for all the Cyclops users that > drop me a message about this. > > It seems some router in AS13214 decided to originate all the prefixes and > send them to AS48285 in the Caymans, all the ASPATHs are 48285 13214. > The first announcement was on 2009-05-11 11:03:11 UTC and last on 2009-05-11 > 12:16:32 UTC, there were 266,289 prefixes leaked (they were withdrawn > afterwards) It looks like AS13214 are misbehaving again... We have just started receiving cyclops alerts indicating that AS13214 is announcing our prefixes again: Alert ID: 4927389 Alert type: origin change Monitored ASN,prefix: 78.154.96.0/19 Offending attribute: 78.154.96.0/19-13214 Date: 2009-07-28 08:30:56 UTC Duration: 00:00:01 (hh:mm:ss) No. monitors: 1 (http://cyclops.cs.ucla.edu/view_monitors.html?aid=4927389) Announced prefix: 78.154.96.0/19 Announced ASPATH: 48285 13214 BGP message: http://cyclops.cs.ucla.edu/show_myalert.html?aid=4927389 I guess ROBTEX didn't implement ingress filters after the last episode... > As indicated in the Cyclops alerts, only a single monitor(AS48285) in > route-views4 detected this leak. I checked on other neighbors of AS13214 and > they seem fine, so it seems it was only a single router issue. > > This incident shows the advantage of having a wide set of peers for > detection, it seems Cyclops was the only tool to detect this incident. Given > the amount of banks and financial institutions in the Caymans, i would > otherwise have raised a red flag, but it seems this case was an > unintentional misconfig by AS13214. > > Would appreciate any further comment on the tool, and happy cyclopying! > > --Ricardo > the Cyclops guy > http://cyclops.cs.ucla.edu > > > On May 11, 2009, at 8:30 AM, Jay Hennigan wrote: > >> We're getting cyclops[1] alerts that AS13214 is advertising itself as >> origin for all of our prefixes. ?Their anomaly report shows thousands of >> prefixes originating there. >> >> Anyone else seeing evidence of this or being affected? >> >> >> [1] http://cyclops.cs.ucla.edu/ >> >> >> -- >> Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net >> Impulse Internet Service ?- ?http://www.impulse.net/ >> Your local telephone and internet company - 805 884-6323 - WB6RDV > > > -- Russell Heilling http://perlmonkey.blogspot.com "The amazing ability of the bee to adapt herself often helps the beekeeper to overcome the results of his ignorance." - Brother Adam From swmike at swm.pp.se Tue Jul 28 06:42:17 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 28 Jul 2009 13:42:17 +0200 (CEST) Subject: Anomalies with AS13214 ? In-Reply-To: <647fc4230907280350m47603268y392b460240d0d473@mail.gmail.com> References: <4A08448A.7020403@west.net> <4426C119-52FA-4D3D-9BD5-00CEC831D964@cs.ucla.edu> <647fc4230907280350m47603268y392b460240d0d473@mail.gmail.com> Message-ID: On Tue, 28 Jul 2009, Russell Heilling wrote: > It looks like AS13214 are misbehaving again... We have just started > receiving cyclops alerts indicating that AS13214 is announcing our > prefixes again: There is talk about this being a new Quagga bug redist:ing kernel routes into BGP. I'm yelling at them for not having outgoing route filters to handle the possibility after what happened last time. -- Mikael Abrahamsson email: swmike at swm.pp.se From bortzmeyer at nic.fr Tue Jul 28 07:17:17 2009 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 28 Jul 2009 14:17:17 +0200 Subject: Anomalies with AS13214 ? In-Reply-To: <647fc4230907280350m47603268y392b460240d0d473@mail.gmail.com> References: <4A08448A.7020403@west.net> <4426C119-52FA-4D3D-9BD5-00CEC831D964@cs.ucla.edu> <647fc4230907280350m47603268y392b460240d0d473@mail.gmail.com> Message-ID: <20090728121717.GA10890@nic.fr> On Tue, Jul 28, 2009 at 11:50:02AM +0100, Russell Heilling wrote a message of 75 lines which said: > No. monitors: 1 That's why it's good to use BGP alarm systems with a peer threshold. I recommend BGPmon (today, I run it with a peer thershold of 1 because the problem is rare enough but I can raise it if necessary). AFAIK, Cyclops does not have this functionality. From nanog at daork.net Tue Jul 28 07:27:56 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 29 Jul 2009 00:27:56 +1200 Subject: Anomalies with AS13214 ? In-Reply-To: References: <4A08448A.7020403@west.net> <75cb24520905110944x74fc6f9av3de81c4c6569315b@mail.gmail.com> Message-ID: On 12/05/2009, at 4:47 AM, David Freedman wrote: > Yeah, interesting contact name on this: > > person: Fredrik Neij > address: DCPNetworks > address: Box 161 > address: SE-11479 Stockholm > address: Sweden > mnt-by: MNT-DCP > phone: +46 707 323819 > nic-hdl: FN2233-RIPE > source: RIPE # Filtered Dispatch someone from IETF, that is on in Stockholm right now. Actually, Paul Jakma might be there, dispatch him if it really is a Quagga bug. -- Nathan Ward From tsands at rackspace.com Tue Jul 28 07:30:45 2009 From: tsands at rackspace.com (Tom Sands) Date: Tue, 28 Jul 2009 07:30:45 -0500 Subject: Recommendations for Hong Kong datacenter, and a sanity check for my geopolitical conclusions ? In-Reply-To: <25dbbe250907241330j10c3ba6akb0f376967be13286@mail.gmail.com> References: <834941.40938.qm@web111612.mail.gq1.yahoo.com> <25dbbe250907241330j10c3ba6akb0f376967be13286@mail.gmail.com> Message-ID: <3631_1248784249_n6SCUi3E007701_4A6EEF75.3080003@rackspace.com> Equinix and Mega-iAdvantage are both good choices. Equinix is just standing up their peering exchange in HK, so this is something they have over Mega-I, and both can offer connectivity to HKIX. Outside of the locations above, our HK presence is also a floor in a PCCW facility, which has been good so far. I'm also not a sales person, but we could offer the capability you are looking for, though we aren't colo if you ever needed physical access to your equipment. -------------------------------------------------------------------------------- Tom Sands Chief Network Engineer Rackspace Managed Hosting -------------------------------------------------------------------------------- Chris McDonald wrote: > Making every effort to not pimp my employer (pccw), I would say that > the Equinix in HK is good and they have a decent equinix direct > product (one bill to pay). If you're looking more for a "managed > colo", pccw owns powerbase which does that sort of thing. HKCOLO is > good but space is hard to come by. > > > > > > > > On 7/24/09, George Sanders wrote: >> >> I will be expanding a small network infrastructure service (read: DNS and >> mail ... a few 1u and 2u servers) to Hong Kong next year. >> >> We don't have any particular customer base in Hong Kong - rather, we have >> customers all over southeast asia and would like to serve them better, as >> well as attract more SE Asia customers. >> >> I chose Hong Kong for the following reasons: >> >> - South Korea is alternately happy with / upset with Japan, and I don't want >> to deal with that >> >> - Japan is is alternately happy with / upset with South Korea, and I don't >> want to deal with that >> >> - Mainland China is out of the question, for obvious reasons >> >> - The smaller (Thailand, Vietnamese, Phillipines, etc.) countries all have >> their own particular issues (recent coup in Thailand, etc.) >> >> So the choice came down to Hong Kong or Singapore, and I chose Hong Kong >> because it seems easier to "just get things done" there. I realize that in >> the long term there is a greater risk of social paradigm shift in Hong Kong >> because of mainland China, but in the short run it seems that Hong Kong is >> more "functional" than Singapore. >> >> Any comments on the above thought process ? >> >> >> The obvious follow-up is, which datacenter ? >> >> I need a full service center that will give me rackspace and let me just >> plug ethernet into their switch. I am not interested in brokering my own >> connectivity, nor am I interested in running my own routers. I want to pay >> one bill to one organization and get one cable. The end. >> >> I think there are further considerations though ... I read details of one >> very modern, very sexy datacenter housed in a skyscraper, but my research >> showed me that this building has been built on land reclaimed from the sea, >> and there is reasonable concern that the sand underpinnings could liquify, >> to a degree, in a seismic event. I'd also like to be more than a few feet >> above sea level. Honestly, as sexy as it would be to be in a slick tower >> right on the bay in Central Hong Kong, I would much rather find some >> nondescript, one story building, miles from the coast and a few hundred feet >> above sea level. >> >> What recommendations might someone have ? >> >> Thank you very much for any comments or suggestions you may have. >> >> >> >> > > -- > Sent from Gmail for mobile | mobile.google.com > > . > Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. From bortzmeyer at nic.fr Tue Jul 28 07:33:45 2009 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 28 Jul 2009 14:33:45 +0200 Subject: Anomalies with AS13214 ? In-Reply-To: <647fc4230907280350m47603268y392b460240d0d473@mail.gmail.com> References: <4A08448A.7020403@west.net> <4426C119-52FA-4D3D-9BD5-00CEC831D964@cs.ucla.edu> <647fc4230907280350m47603268y392b460240d0d473@mail.gmail.com> Message-ID: <20090728123345.GA12937@nic.fr> On Tue, Jul 28, 2009 at 11:50:02AM +0100, Russell Heilling wrote a message of 75 lines which said: > I guess ROBTEX didn't implement ingress filters after the last > episode... It *seems* (I do not know them in detail) that Robtex , AS 48285, is dedicated to measurements, not to IP transit. If so, it makes sense for them to accept everything. If I'm right, it means Cyclops was wrong to have a monitor in an AS which is not a "real" operator. From mansaxel at besserwisser.org Tue Jul 28 08:18:08 2009 From: mansaxel at besserwisser.org (Mans Nilsson) Date: Tue, 28 Jul 2009 15:18:08 +0200 Subject: Anomalies with AS13214 ? In-Reply-To: References: <4A08448A.7020403@west.net> <75cb24520905110944x74fc6f9av3de81c4c6569315b@mail.gmail.com> Message-ID: <20090728131808.GC10901@besserwisser.org> Subject: Re: Anomalies with AS13214 ? Date: Wed, Jul 29, 2009 at 12:27:56AM +1200 Quoting Nathan Ward (nanog at daork.net): > On 12/05/2009, at 4:47 AM, David Freedman wrote: > >> Yeah, interesting contact name on this: >> >> person: Fredrik Neij >> address: DCPNetworks >> address: Box 161 >> address: SE-11479 Stockholm >> address: Sweden >> mnt-by: MNT-DCP >> phone: +46 707 323819 >> nic-hdl: FN2233-RIPE >> source: RIPE # Filtered (yes, it is him.) > Dispatch someone from IETF, that is on in Stockholm right now. Won't help. Neij is 12 time zones away. But he is aware of the problem. -- M?ns Nilsson From bortzmeyer at nic.fr Tue Jul 28 08:38:24 2009 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 28 Jul 2009 15:38:24 +0200 Subject: Anomalies with AS13214 ? In-Reply-To: <647fc4230907280350m47603268y392b460240d0d473@mail.gmail.com> References: <4A08448A.7020403@west.net> <4426C119-52FA-4D3D-9BD5-00CEC831D964@cs.ucla.edu> <647fc4230907280350m47603268y392b460240d0d473@mail.gmail.com> Message-ID: <20090728133824.GA24915@nic.fr> On Tue, Jul 28, 2009 at 11:50:02AM +0100, Russell Heilling wrote a message of 75 lines which said: > I guess ROBTEX didn't implement ingress filters after the last > episode... I simply asked them and they told me that DCP (AS 13214) is simply their transit provider so they cannot put a max-prefixes or list the prefixes announced in an ACL. From me at sharloncarty.net Tue Jul 28 08:45:28 2009 From: me at sharloncarty.net (Sharlon R. Carty) Date: Tue, 28 Jul 2009 09:45:28 -0400 Subject: Anomalies with AS13214 ? In-Reply-To: <4426C119-52FA-4D3D-9BD5-00CEC831D964@cs.ucla.edu> References: <4A08448A.7020403@west.net> <4426C119-52FA-4D3D-9BD5-00CEC831D964@cs.ucla.edu> Message-ID: Isn't this the second time that AS13214 seemed to have made a "unintentional misconfig"? On Mon, May 11, 2009 at 3:05 PM, Ricardo Oliveira wrote: > Hi all, > > First, thanks for using Cyclops, and thanks for all the Cyclops users that > drop me a message about this. > > It seems some router in AS13214 decided to originate all the prefixes and > send them to AS48285 in the Caymans, all the ASPATHs are 48285 13214. > The first announcement was on 2009-05-11 11:03:11 UTC and last on > 2009-05-11 12:16:32 UTC, there were 266,289 prefixes leaked (they were > withdrawn afterwards) > > As indicated in the Cyclops alerts, only a single monitor(AS48285) in > route-views4 detected this leak. I checked on other neighbors of AS13214 and > they seem fine, so it seems it was only a single router issue. > > This incident shows the advantage of having a wide set of peers for > detection, it seems Cyclops was the only tool to detect this incident. Given > the amount of banks and financial institutions in the Caymans, i would > otherwise have raised a red flag, but it seems this case was an > unintentional misconfig by AS13214. > > Would appreciate any further comment on the tool, and happy cyclopying! > > --Ricardo > the Cyclops guy > http://cyclops.cs.ucla.edu > > > On May 11, 2009, at 8:30 AM, Jay Hennigan wrote: > > We're getting cyclops[1] alerts that AS13214 is advertising itself as >> origin for all of our prefixes. Their anomaly report shows thousands of >> prefixes originating there. >> >> Anyone else seeing evidence of this or being affected? >> >> >> [1] http://cyclops.cs.ucla.edu/ >> >> >> -- >> Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net >> Impulse Internet Service - http://www.impulse.net/ >> Your local telephone and internet company - 805 884-6323 - WB6RDV >> > > > -- --sharlon From bortzmeyer at nic.fr Tue Jul 28 08:49:44 2009 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 28 Jul 2009 15:49:44 +0200 Subject: Anomalies with AS13214 ? In-Reply-To: References: <4A08448A.7020403@west.net> <4426C119-52FA-4D3D-9BD5-00CEC831D964@cs.ucla.edu> Message-ID: <20090728134944.GA27072@nic.fr> On Tue, Jul 28, 2009 at 09:45:28AM -0400, Sharlon R. Carty wrote a message of 57 lines which said: > Isn't this the second time that AS13214 seemed to have made a > "unintentional misconfig"? Yes From sjk at sleepycatz.com Tue Jul 28 09:53:23 2009 From: sjk at sleepycatz.com (sjk) Date: Tue, 28 Jul 2009 09:53:23 -0500 Subject: Anomalies with AS13214 ? In-Reply-To: <647fc4230907280350m47603268y392b460240d0d473@mail.gmail.com> References: <4A08448A.7020403@west.net> <4426C119-52FA-4D3D-9BD5-00CEC831D964@cs.ucla.edu> <647fc4230907280350m47603268y392b460240d0d473@mail.gmail.com> Message-ID: <4A6F10E3.2090900@sleepycatz.com> Russell Heilling wrote: > 2009/5/11 Ricardo Oliveira : >> Hi all, >> >> First, thanks for using Cyclops, and thanks for all the Cyclops users that >> drop me a message about this. >> >> It seems some router in AS13214 decided to originate all the prefixes and >> send them to AS48285 in the Caymans, all the ASPATHs are 48285 13214. >> The first announcement was on 2009-05-11 11:03:11 UTC and last on 2009-05-11 >> 12:16:32 UTC, there were 266,289 prefixes leaked (they were withdrawn >> afterwards) > > It looks like AS13214 are misbehaving again... We have just started > receiving cyclops alerts indicating that AS13214 is announcing our > prefixes again: We are seeing the same thing for two of our prefixes: Offending attribute: 66.251.224.0/19-13214 Offending attribute: 66.146.192.0/19-48285 Pretty annoying --steve From David_Hiers at adp.com Tue Jul 28 09:58:00 2009 From: David_Hiers at adp.com (Hiers, David) Date: Tue, 28 Jul 2009 09:58:00 -0500 Subject: OT: Voice Operators' Group forming In-Reply-To: References: <4A6D3D2B.7050001@unwiredbb.com> <1248674313.13748.10.camel@petrie><81CDFC77FB2DC54DB875D4F8FFC36CE00A92089C42@DSMAIL2HE.ds.ad.adp.com> <276D7E82-2C3F-44FF-A9EA-E9799A5D150B@ianai.net><4D8EE8D5295A4E6C837103F209DBD799@Honkin> <4A6E2365.3050901@rollernet.us> Message-ID: <81CDFC77FB2DC54DB875D4F8FFC36CE00A921D4A3C@DSMAIL2HE.ds.ad.adp.com> Hi NANOG, I'd like to announce the formation of a NANOG-knockoff group for voice operators, the Voice Operators' Group. Voice network operators share many of the same challenges as IP network operators; we register with registrars (CILLI, OCN, and ACNA as well as ASN and DNS), route traffic (point codes as well as IP addresses), resolve names (CNAM as well as DNS), manage reachability (to countries, LATAs and NPA/NXXs as well as to IP networks), and deal with equipment issues. NANOG has been so useful at the IP layer that it seems like a good idea to try to duplicate it a little further up the stack. For now, the group is on Yahoo: http://tech.groups.yahoo.com/group/voip_operators_group/ Of course, we're looking for a better place, name, and charter. Regards, David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. From w3yni1 at gmail.com Tue Jul 28 10:11:18 2009 From: w3yni1 at gmail.com (Charles Mills) Date: Tue, 28 Jul 2009 11:11:18 -0400 Subject: XO - a Tier 1 or not? Message-ID: <607f1e0a0907280811j6257ed1w21fcb331e271daf5@mail.gmail.com> Trying to sort through the marketecture and salesman speak and get a definitive answer. I figure the NANOGers would be able to give me some input. Is XO Communications a Tier 1 ISP? I'd say no based on all research and googling that I've done but they seem to meet some of the criteria (some != all and therefore not Tier 1). Any help here? Thanks as always. Chuck From pekkas at netcore.fi Tue Jul 28 10:18:02 2009 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 28 Jul 2009 18:18:02 +0300 (EEST) Subject: XO - a Tier 1 or not? In-Reply-To: <607f1e0a0907280811j6257ed1w21fcb331e271daf5@mail.gmail.com> References: <607f1e0a0907280811j6257ed1w21fcb331e271daf5@mail.gmail.com> Message-ID: On Tue, 28 Jul 2009, Charles Mills wrote: > Is XO Communications a Tier 1 ISP? ... > Any help here? Thanks as always. http://en.wikipedia.org/wiki/Tier_1_network -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From patrick at ianai.net Tue Jul 28 10:26:01 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 28 Jul 2009 11:26:01 -0400 Subject: XO - a Tier 1 or not? In-Reply-To: References: <607f1e0a0907280811j6257ed1w21fcb331e271daf5@mail.gmail.com> Message-ID: <4DBD8CAE-C92A-4D0C-AF82-88F1AC0C0327@ianai.net> On Jul 28, 2009, at 11:18 AM, Pekka Savola wrote: > On Tue, 28 Jul 2009, Charles Mills wrote: >> Is XO Communications a Tier 1 ISP? > ... >> Any help here? Thanks as always. > > http://en.wikipedia.org/wiki/Tier_1_network Having written a good portion of that page, in the interest of full disclosure, I would like to point out some of the comments made while I was editing (and re-editing) the page. I do not _know_ XO has settlement agreements with Sprint & L3. Such contracts are covered by NDA, so (supposedly) only certain people inside Sprint, L3, and XO know whether XO is paying settlements. That said, does it matter? Settlement-Based may actually have a slight benefit over Settlement Free, as links which generate revenue may get upgraded faster than links which do not. Perhaps more importantly, does Transit Free matter? A network which has two diverse transit providers is orders of magnitude less likely to be affected by bifurcation events than transit free networks. Not to mention many non-transit free networks have better quality and service, IMHO, than some transit free networks. But hey, your money, your bits, so your decision. You want to buy from XO because they are Transit Free, or not buy from them because they are not Tier One, so be it. What's that line about competitors and encouragement... ? =) -- TTFN, patrick From streiner at cluebyfour.org Tue Jul 28 10:30:47 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 28 Jul 2009 11:30:47 -0400 (EDT) Subject: XO - a Tier 1 or not? In-Reply-To: <607f1e0a0907280811j6257ed1w21fcb331e271daf5@mail.gmail.com> References: <607f1e0a0907280811j6257ed1w21fcb331e271daf5@mail.gmail.com> Message-ID: On Tue, 28 Jul 2009, Charles Mills wrote: > Trying to sort through the marketecture and salesman speak and get a > definitive answer. > > I figure the NANOGers would be able to give me some input. > > Is XO Communications a Tier 1 ISP? Do the best of my knowledge, no. The definition of 'Tier 1' is something of a moving target based on who you ask, but the most commonly stated criteria I've seen over the years are: 1. The provider does not buy IP transit from anyone - all traffic is moved on settlement-free public or private interconnects. That's not to say that the provider doesn't buy non-IP services (IRUs, lambdas, easements, etc) from other providers on occasion. 2. The provider lives in the default-free zone, which is pretty much a re-statement of point 1. I'll leave discussions about geographical coverage out of it for now. That said, I don't think XO meets the criteria above. I'm not 100% certain, but I don't think they're totally settlement-free. Other providers like Cogent would fall into this bucket as well. However, I also wouldn't get too hung up on tiers. Many very reliable, competent, and responsive providers providers but transit to handle at least some portion of their traffic. It also depends on what sort of service you need. For example, if you need a big MPLS pipe to another country, there are a limited number of providers who can do that, so they would tend to be the big guys. However, if you just need general IP transit, your options open up quite a bit. jms From nanog-post at rsuc.gweep.net Tue Jul 28 11:01:37 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Tue, 28 Jul 2009 12:01:37 -0400 Subject: XO - a Tier 1 or not? In-Reply-To: References: <607f1e0a0907280811j6257ed1w21fcb331e271daf5@mail.gmail.com> Message-ID: <20090728160137.GA14391@gweep.net> On Tue, Jul 28, 2009 at 11:30:47AM -0400, Justin M. Streiner wrote: > On Tue, 28 Jul 2009, Charles Mills wrote: [snip] > Do the best of my knowledge, no. The definition of 'Tier 1' is something > of a moving target based on who you ask, but the most commonly stated > criteria I've seen over the years are: > 1. The provider does not buy IP transit from anyone - all traffic is moved > on settlement-free public or private interconnects. That's not to say > that the provider doesn't buy non-IP services (IRUs, lambdas, easements, > etc) from other providers on occasion. Purchasing other services is sometimes seen as a settlement, generally based upon which end of the transaction one is sitting. > 2. The provider lives in the default-free zone, which is pretty much a > re-statement of point 1. Running without default (using full table, "default-free zone") Has nothing to do with who you pay for what. Discussion of "tiers" will inevitably reach topics of marketing & market dominance [eg "tier one in my home region" for many PTTs] and generally are not any kind of useful technical metric. In fact, it can easily be argued that the networks which run without any form of contractually binding vector for their customer's traffic are more fragile than those who have one or more paths with dollars (and various levels of penalties) attached. Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From streiner at cluebyfour.org Tue Jul 28 11:30:38 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 28 Jul 2009 12:30:38 -0400 (EDT) Subject: XO - a Tier 1 or not? In-Reply-To: <20090728160137.GA14391@gweep.net> References: <607f1e0a0907280811j6257ed1w21fcb331e271daf5@mail.gmail.com> <20090728160137.GA14391@gweep.net> Message-ID: On Tue, 28 Jul 2009, Joe Provo wrote: > On Tue, Jul 28, 2009 at 11:30:47AM -0400, Justin M. Streiner wrote: >> 1. The provider does not buy IP transit from anyone - all traffic is moved >> on settlement-free public or private interconnects. That's not to say >> that the provider doesn't buy non-IP services (IRUs, lambdas, easements, >> etc) from other providers on occasion. > > Purchasing other services is sometimes seen as a settlement, generally > based upon which end of the transaction one is sitting. Sure, that's possible. The agreements can be structured in many different ways. Since they're often covered by nondisclosure agreements, only a handful of people on either end know the full details. Many of the peering agreements I've seen either worked the cost structure on a rotating (provider A buys the first link, provider B buys the second, etc) or a split (the two providers split the costs of the links) basis. Discussions about more advanced topics like traffic levels and settlement fall-back clauses are somewhat out of scope for this thread. >> 2. The provider lives in the default-free zone, which is pretty much a >> re-statement of point 1. > > Running without default (using full table, "default-free zone") Has > nothing to do with who you pay for what. Agreed. I brought it up because it's a common (but not entirely accurate) assumption that providers who live in the DFZ are Tier 1 providers. > Discussion of "tiers" will inevitably reach topics of marketing & > market dominance [eg "tier one in my home region" for many PTTs] > and generally are not any kind of useful technical metric. In fact, > it can easily be argued that the networks which run without any form > of contractually binding vector for their customer's traffic are more > fragile than those who have one or more paths with dollars (and various > levels of penalties) attached. Agreed again, but it's something that operators will continue to deal with as long as some providers continue to play up their tier status and customers continue to attach some relevance or assumptions of performance or reliability to it. jms From David_Hiers at adp.com Tue Jul 28 12:56:52 2009 From: David_Hiers at adp.com (Hiers, David) Date: Tue, 28 Jul 2009 12:56:52 -0500 Subject: XO - a Tier 1 or not? In-Reply-To: <4DBD8CAE-C92A-4D0C-AF82-88F1AC0C0327@ianai.net> References: <607f1e0a0907280811j6257ed1w21fcb331e271daf5@mail.gmail.com> <4DBD8CAE-C92A-4D0C-AF82-88F1AC0C0327@ianai.net> Message-ID: <81CDFC77FB2DC54DB875D4F8FFC36CE00A921D5194@DSMAIL2HE.ds.ad.adp.com> If you limit your consideration to how things look at IP and AP/AR, then the Tier-N discussion is solvable. If you care about actual physical facilities, all bets are off. Taking a tangent from the diversity concept: http://www.atis.org/ndai/ATIS_NDAI_Final_Report_2006.pdf I worked at a CLEC that purchased two SS7 links, one each from two Very Big Carriers. Both wound up going through the same fiber bundle in one particular market, on which both big guys leased bandwidth from A Minor Carrier. I've never seen a VP run as fast as when that backhoe hit us in Illinois; turns out they only *look* slow. You never really know... David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: Tuesday, July 28, 2009 8:26 AM To: NANOG list Subject: Re: XO - a Tier 1 or not? On Jul 28, 2009, at 11:18 AM, Pekka Savola wrote: > On Tue, 28 Jul 2009, Charles Mills wrote: >> Is XO Communications a Tier 1 ISP? > ... >> Any help here? Thanks as always. > > http://en.wikipedia.org/wiki/Tier_1_network Having written a good portion of that page, in the interest of full disclosure, I would like to point out some of the comments made while I was editing (and re-editing) the page. I do not _know_ XO has settlement agreements with Sprint & L3. Such contracts are covered by NDA, so (supposedly) only certain people inside Sprint, L3, and XO know whether XO is paying settlements. That said, does it matter? Settlement-Based may actually have a slight benefit over Settlement Free, as links which generate revenue may get upgraded faster than links which do not. Perhaps more importantly, does Transit Free matter? A network which has two diverse transit providers is orders of magnitude less likely to be affected by bifurcation events than transit free networks. Not to mention many non-transit free networks have better quality and service, IMHO, than some transit free networks. But hey, your money, your bits, so your decision. You want to buy from XO because they are Transit Free, or not buy from them because they are not Tier One, so be it. What's that line about competitors and encouragement... ? =) -- TTFN, patrick This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. From kyle.mclerren at gmail.com Tue Jul 28 13:28:36 2009 From: kyle.mclerren at gmail.com (Kyle McLerren) Date: Tue, 28 Jul 2009 11:28:36 -0700 Subject: Anomalies with AS13214 ? In-Reply-To: <4A6F10E3.2090900@sleepycatz.com> References: <4A08448A.7020403@west.net> <4426C119-52FA-4D3D-9BD5-00CEC831D964@cs.ucla.edu> <647fc4230907280350m47603268y392b460240d0d473@mail.gmail.com> <4A6F10E3.2090900@sleepycatz.com> Message-ID: <48860ad00907281128m207db1acre2c89748679d445b@mail.gmail.com> Seeing the same thing here. Had alerts from Cyclops roll in for all 7 of our prefixes at: 2009-07-28 08:30:26, lasted 35 mins or so: Alert ID: 4910940 Alert type: origin change Monitored ASN,prefix: 174.137.112.0/20 Offending attribute: 174.137.112.0/20-13214 Date: 2009-07-28 08:30:26 UTC Duration: 00:00:01 (hh:mm:ss) --kyle On Tue, Jul 28, 2009 at 7:53 AM, sjk wrote: > > > Russell Heilling wrote: >> 2009/5/11 Ricardo Oliveira : >>> Hi all, >>> >>> First, thanks for using Cyclops, and thanks for all the Cyclops users that >>> drop me a message about this. >>> >>> It seems some router in AS13214 decided to originate all the prefixes and >>> send them to AS48285 in the Caymans, all the ASPATHs are 48285 13214. >>> The first announcement was on 2009-05-11 11:03:11 UTC and last on 2009-05-11 >>> 12:16:32 UTC, there were 266,289 prefixes leaked (they were withdrawn >>> afterwards) >> >> It looks like AS13214 are misbehaving again... ?We have just started >> receiving cyclops alerts indicating that AS13214 is announcing our >> prefixes again: > > We are seeing the same thing for two of our prefixes: > > Offending attribute: ? ? ? ? ?66.251.224.0/19-13214 > > Offending attribute: ? ? ? ? ?66.146.192.0/19-48285 > > Pretty annoying > > --steve > > > From nanog at shreddedmail.com Tue Jul 28 10:25:28 2009 From: nanog at shreddedmail.com (Rick Ernst) Date: Tue, 28 Jul 2009 08:25:28 -0700 Subject: Need help with performance troubleshooting Message-ID: Starting about a week ago, I've had sporadic reports of "slow uploads" (hundreds of kbs, has been 10s of mbs) born out by multiple speed test sites and application results and also duplicated internally. Downloads are > 50Mbs as expected (OC-3 and GigE uplinks to ATT/UUNET/Level3/Sprint/Qwest, etc). It "feels" like the commonality is Seattle, but I haven't been able to find anything conclusive. I'm also not seeing anything interesting in my network as far as CPU, utiliation, interface errors, etc. Hopefully not DoSing myself; I'd like to get some external visibility from "the other direction"; can I get results against our speedtest server ( http://speedtest.easystreet.com) along with traceroute results and geographic origin of the test? Note that traceroute won't make it all the way through due to some RFC addressing and firewall rules. Thanks, Rick From nanog at shreddedmail.com Tue Jul 28 15:19:07 2009 From: nanog at shreddedmail.com (Rick Ernst) Date: Tue, 28 Jul 2009 13:19:07 -0700 Subject: Need help with performance troubleshooting In-Reply-To: References: Message-ID: Thanks for all the results, folks. Other than an ADSL user, all of the traces and speed test results look "normal" (and well above the hundreds of kbs being reported). The ADSL user had a slow download, but with a similar traceroute to others with good performance. I'm going to have my support staff start pushing back harder with the problem almost certainly being outside our network and more specifically isolated to a geographic location and/or set of network destinations. Rick On Tue, Jul 28, 2009 at 8:25 AM, Rick Ernst wrote: > > Starting about a week ago, I've had sporadic reports of "slow uploads" > (hundreds of kbs, has been 10s of mbs) born out by multiple speed test sites > and application results and also duplicated internally. Downloads are > > 50Mbs as expected (OC-3 and GigE uplinks to ATT/UUNET/Level3/Sprint/Qwest, > etc). > > It "feels" like the commonality is Seattle, but I haven't been able to find > anything conclusive. I'm also not seeing anything interesting in my network > as far as CPU, utiliation, interface errors, etc. > > Hopefully not DoSing myself; I'd like to get some external visibility from > "the other direction"; can I get results against our speedtest server ( > http://speedtest.easystreet.com) along with traceroute results and > geographic origin of the test? Note that traceroute won't make it all the > way through due to some RFC addressing and firewall rules. > > Thanks, > Rick > > From charles at thewybles.com Tue Jul 28 16:37:53 2009 From: charles at thewybles.com (Charles Wyble) Date: Tue, 28 Jul 2009 14:37:53 -0700 Subject: OT: Voice Operators' Group forming In-Reply-To: <81CDFC77FB2DC54DB875D4F8FFC36CE00A921D4A3C@DSMAIL2HE.ds.ad.adp.com> References: <4A6D3D2B.7050001@unwiredbb.com> <1248674313.13748.10.camel@petrie><81CDFC77FB2DC54DB875D4F8FFC36CE00A92089C42@DSMAIL2HE.ds.ad.adp.com> <276D7E82-2C3F-44FF-A9EA-E9799A5D150B@ianai.net><4D8EE8D5295A4E6C837103F209DBD799@Honkin> <4A6E2365.3050901@rollernet.us> <81CDFC77FB2DC54DB875D4F8FFC36CE00A921D4A3C@DSMAIL2HE.ds.ad.adp.com> Message-ID: <4A6F6FB1.3000607@thewybles.com> Hiers, David wrote: > Hi NANOG, > I'd like to announce the formation of a NANOG-knockoff group for voice operators, the Voice Operators' Group. Very cool! :) > > Voice network operators share many of the same challenges as IP network operators; we register with registrars (CILLI, OCN, and ACNA as well as ASN and DNS), route traffic (point codes as well as IP addresses), resolve names (CNAM as well as DNS), manage reachability (to countries, LATAs and NPA/NXXs as well as to IP networks), and deal with equipment issues. Indeed we do! > > NANOG has been so useful at the IP layer that it seems like a good idea to try to duplicate it a little further up the stack. Yep. > > For now, the group is on Yahoo: > > http://tech.groups.yahoo.com/group/voip_operators_group/ > > Of course, we're looking for a better place, name, and charter. > Might I recommend google groups, or puck.nether.org. An IPTV list was recently formed. NAVOG works for me. From nanog-amuse at foofus.com Tue Jul 28 16:42:38 2009 From: nanog-amuse at foofus.com (AMuse) Date: Tue, 28 Jul 2009 14:42:38 -0700 Subject: OT: Voice Operators' Group forming In-Reply-To: <4A6F6FB1.3000607@thewybles.com> References: <4A6D3D2B.7050001@unwiredbb.com> <1248674313.13748.10.camel@petrie><81CDFC77FB2DC54DB875D4F8FFC36CE00A92089C42@DSMAIL2HE.ds.ad.adp.com> <276D7E82-2C3F-44FF-A9EA-E9799A5D150B@ianai.net><4D8EE8D5295A4E6C837103F209DBD799@Honkin> <4A6E2365.3050901@rollernet.us> <81CDFC77FB2DC54DB875D4F8FFC36CE00A921D4A3C@DSMAIL2HE.ds.ad.adp.com> <4A6F6FB1.3000607@thewybles.com> Message-ID: <4A6F70CE.5050606@foofus.com> I second the idea of google groups or some other group provider; Yahoo groups are known within many circles for having long email delays. Charles Wyble wrote: > > > Hiers, David wrote: >> Hi NANOG, >> I'd like to announce the formation of a NANOG-knockoff group for >> voice operators, the Voice Operators' Group. > > Very cool! :) > >> >> Voice network operators share many of the same challenges as IP >> network operators; we register with registrars (CILLI, OCN, and ACNA >> as well as ASN and DNS), route traffic (point codes as well as IP >> addresses), resolve names (CNAM as well as DNS), manage reachability >> (to countries, LATAs and NPA/NXXs as well as to IP networks), and >> deal with equipment issues. > > Indeed we do! >> >> NANOG has been so useful at the IP layer that it seems like a good >> idea to try to duplicate it a little further up the stack. > > > Yep. > >> >> For now, the group is on Yahoo: >> >> http://tech.groups.yahoo.com/group/voip_operators_group/ >> >> Of course, we're looking for a better place, name, and charter. >> > > Might I recommend google groups, or puck.nether.org. An IPTV list was > recently formed. > > NAVOG works for me. > > From brandon at rd.bbc.co.uk Tue Jul 28 16:49:44 2009 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Tue, 28 Jul 2009 22:49:44 +0100 (BST) Subject: OT: Voice Operators' Group forming Message-ID: <200907282149.WAA18355@sunf10.rd.bbc.co.uk> > NAVOG works for me. I'd prefer Voice Operators' Group Online Network brandon From j at arpa.com Tue Jul 28 16:49:52 2009 From: j at arpa.com (jamie) Date: Tue, 28 Jul 2009 16:49:52 -0500 Subject: OT: Voice Operators' Group forming In-Reply-To: <4A6F6FB1.3000607@thewybles.com> References: <1248674313.13748.10.camel@petrie> <81CDFC77FB2DC54DB875D4F8FFC36CE00A92089C42@DSMAIL2HE.ds.ad.adp.com> <276D7E82-2C3F-44FF-A9EA-E9799A5D150B@ianai.net> <4D8EE8D5295A4E6C837103F209DBD799@Honkin> <4A6E2365.3050901@rollernet.us> <81CDFC77FB2DC54DB875D4F8FFC36CE00A921D4A3C@DSMAIL2HE.ds.ad.adp.com> <4A6F6FB1.3000607@thewybles.com> Message-ID: <6ff30abd0907281449k122dea6dt97e4816d1ddd0c08@mail.gmail.com> puck.nether.net. way to volunteer someone else's box :-) -j On Tue, Jul 28, 2009 at 4:37 PM, Charles Wyble wrote: > > > Hiers, David wrote: > >> Hi NANOG, >> I'd like to announce the formation of a NANOG-knockoff group for voice >> operators, the Voice Operators' Group. >> > > Very cool! :) > > >> Voice network operators share many of the same challenges as IP network >> operators; we register with registrars (CILLI, OCN, and ACNA as well as ASN >> and DNS), route traffic (point codes as well as IP addresses), resolve names >> (CNAM as well as DNS), manage reachability (to countries, LATAs and NPA/NXXs >> as well as to IP networks), and deal with equipment issues. >> > > Indeed we do! > >> >> NANOG has been so useful at the IP layer that it seems like a good idea to >> try to duplicate it a little further up the stack. >> > > > Yep. > > >> For now, the group is on Yahoo: >> >> http://tech.groups.yahoo.com/group/voip_operators_group/ >> >> Of course, we're looking for a better place, name, and charter. >> >> > Might I recommend google groups, or puck.nether.org. An IPTV list was > recently formed. > > NAVOG works for me. > > > > From charles at thewybles.com Tue Jul 28 17:17:07 2009 From: charles at thewybles.com (Charles Wyble) Date: Tue, 28 Jul 2009 15:17:07 -0700 Subject: OT: Voice Operators' Group forming In-Reply-To: <6ff30abd0907281449k122dea6dt97e4816d1ddd0c08@mail.gmail.com> References: <1248674313.13748.10.camel@petrie> <81CDFC77FB2DC54DB875D4F8FFC36CE00A92089C42@DSMAIL2HE.ds.ad.adp.com> <276D7E82-2C3F-44FF-A9EA-E9799A5D150B@ianai.net> <4D8EE8D5295A4E6C837103F209DBD799@Honkin> <4A6E2365.3050901@rollernet.us> <81CDFC77FB2DC54DB875D4F8FFC36CE00A921D4A3C@DSMAIL2HE.ds.ad.adp.com> <4A6F6FB1.3000607@thewybles.com> <6ff30abd0907281449k122dea6dt97e4816d1ddd0c08@mail.gmail.com> Message-ID: <4A6F78E3.9090503@thewybles.com> jamie wrote: > puck.nether.net . Right. That's what I meant. > > way to volunteer someone else's box :-) Good point. My apologies. Google groups then. :) From tme at americafree.tv Tue Jul 28 17:22:44 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 28 Jul 2009 18:22:44 -0400 Subject: OT: Voice Operators' Group forming In-Reply-To: <200907282149.WAA18355@sunf10.rd.bbc.co.uk> References: <200907282149.WAA18355@sunf10.rd.bbc.co.uk> Message-ID: <5A9C4B75-4BE2-4731-8FA3-39704F64766A@americafree.tv> Dear Brandon; Are you planning to favor this new group with any poetry readings ? Regards Marshall On Jul 28, 2009, at 5:49 PM, Brandon Butterworth wrote: >> NAVOG works for me. > > I'd prefer Voice Operators' Group Online Network > > brandon > > From carlos at race.com Tue Jul 28 18:36:17 2009 From: carlos at race.com (Carlos Alcantar) Date: Tue, 28 Jul 2009 16:36:17 -0700 Subject: OT: Voice Operators' Group forming Message-ID: <859604546CD1FF488BDB6EA94C896AFB8AB80E@racexchange.race.local> So has someone created the google group yet? -----Original Message----- From: Marshall Eubanks [mailto:tme at americafree.tv] Sent: Tuesday, July 28, 2009 3:23 PM To: Brandon Butterworth Cc: nanog at nanog.org Subject: Re: OT: Voice Operators' Group forming Dear Brandon; Are you planning to favor this new group with any poetry readings ? Regards Marshall On Jul 28, 2009, at 5:49 PM, Brandon Butterworth wrote: >> NAVOG works for me. > > I'd prefer Voice Operators' Group Online Network > > brandon > > From jack at crepinc.com Tue Jul 28 19:16:46 2009 From: jack at crepinc.com (Jack Carrozzo) Date: Tue, 28 Jul 2009 20:16:46 -0400 Subject: OT: Voice Operators' Group forming In-Reply-To: <5A9C4B75-4BE2-4731-8FA3-39704F64766A@americafree.tv> References: <200907282149.WAA18355@sunf10.rd.bbc.co.uk> <5A9C4B75-4BE2-4731-8FA3-39704F64766A@americafree.tv> Message-ID: <2ad0f9f60907281716t3b9aec6bvfe30e2595d3daaef@mail.gmail.com> > Are you planning to favor this new group with any poetry readings ? I for one am looking forward to the haikus. -Jack Carrozzo > > Regards > Marshall > > On Jul 28, 2009, at 5:49 PM, Brandon Butterworth wrote: > >>> NAVOG ?works for me. >> >> I'd prefer Voice Operators' Group Online Network >> >> brandon >> >> > > > From jmartinez at zero11.com Tue Jul 28 19:49:54 2009 From: jmartinez at zero11.com (John Martinez) Date: Tue, 28 Jul 2009 17:49:54 -0700 Subject: Bind 9 vulnerability Message-ID: <4A6F9CB2.501@zero11.com> https://www.isc.org/node/474 From owen at delong.com Tue Jul 28 20:02:32 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 28 Jul 2009 18:02:32 -0700 Subject: OT: Voice Operators' Group forming In-Reply-To: <2ad0f9f60907281716t3b9aec6bvfe30e2595d3daaef@mail.gmail.com> References: <200907282149.WAA18355@sunf10.rd.bbc.co.uk> <5A9C4B75-4BE2-4731-8FA3-39704F64766A@americafree.tv> <2ad0f9f60907281716t3b9aec6bvfe30e2595d3daaef@mail.gmail.com> Message-ID: On Jul 28, 2009, at 5:16 PM, Jack Carrozzo wrote: >> Are you planning to favor this new group with any poetry readings ? > > I for one am looking forward to the haikus. > a voice group forming can we cancel the echoes of bellcore e-mail Owen From woody at pch.net Tue Jul 28 23:34:04 2009 From: woody at pch.net (Bill Woodcock) Date: Tue, 28 Jul 2009 21:34:04 -0700 Subject: Ahoy, SLA boffins! Message-ID: <8070E7E5-07BF-424E-9A2F-FC736BA26E66@pch.net> So I've embarked on the no-doubt-futile task of trying to interpret SLAs as empirically-verifiable technical specifications, rather than as marketing blather. And there's something that I'm finding particularly puzzling: In most SLAs, there seem to be two separate guarantees proffered: one concerning "network availability" and one concerning "packet loss." Now, if I were to put my engineer hat on, and try to _imagine_ what the difference might be, I might imagine "network availability" to have something to do with layer-2 link status being presented as "up," while packet loss would be the percentage of packets dropped. But when I actually read SLAs, "network availability" is generally defined as the portion of the month that the path from the customer's local loop to the transit or peering routers was "available" to transmit packets. Packet loss, on the other hand, is generally defined as the portion of packets which are lost while crossing that exact same piece of network. Now, what am I missing here? Is this one of those Heisenberg things, where "network availability" is the time the network _could have_ delivered a packet _when you weren't actually doing so_, while "packet loss" is the time the network _couldn't_ deliver a packet when you _were_ actually doing so? Is "network availability" inherently unmeasurable on a network that's less than 100% utilized? Am I over-thinking this? Seriously, though, I know there are people who don't consider SLAs to be fantasy-fiction, and some of them must not be innumerate, and some subset of those must be on NANOG, and the intersection set might be equal to or greater than one, right? Can anybody explain this to me in a way I can translate into code, while still taking myself seriously? -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From patrick at ianai.net Tue Jul 28 23:42:42 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 29 Jul 2009 00:42:42 -0400 Subject: Ahoy, SLA boffins! In-Reply-To: <8070E7E5-07BF-424E-9A2F-FC736BA26E66@pch.net> References: <8070E7E5-07BF-424E-9A2F-FC736BA26E66@pch.net> Message-ID: <106982B4-26E4-454C-82FD-CA60AE85BB1E@ianai.net> On Jul 29, 2009, at 12:34 AM, Bill Woodcock wrote: > So I've embarked on the no-doubt-futile task of trying to interpret > SLAs as empirically-verifiable technical specifications, rather than > as marketing blather. And there's something that I'm finding > particularly puzzling: > > In most SLAs, there seem to be two separate guarantees proffered: > one concerning "network availability" and one concerning "packet > loss." Now, if I were to put my engineer hat on, and try to > _imagine_ what the difference might be, I might imagine "network > availability" to have something to do with layer-2 link status being > presented as "up," while packet loss would be the percentage of > packets dropped. But when I actually read SLAs, "network > availability" is generally defined as the portion of the month that > the path from the customer's local loop to the transit or peering > routers was "available" to transmit packets. Packet loss, on the > other hand, is generally defined as the portion of packets which are > lost while crossing that exact same piece of network. > > Now, what am I missing here? Is this one of those Heisenberg > things, where "network availability" is the time the network _could > have_ delivered a packet _when you weren't actually doing so_, while > "packet loss" is the time the network _couldn't_ deliver a packet > when you _were_ actually doing so? > > Is "network availability" inherently unmeasurable on a network > that's less than 100% utilized? > > Am I over-thinking this? Yes. But not because you are coming to strange conclusions, but because (as you say in your first sentence), you are trying to put empirical / objective meaning to marketing blather. I had a simple way to fix this. I defined a network as "down" with more than X% packet loss (usually with X in the 2-5 range, depending on other deal parameters). IMHO, a network with 5% packet loss -is- down. I don't know about you, but none of my customers will use my service if they have 5% loss. TCP is finicky! This receives the strongest credit because you cannot use the service. Below X, you are not "down", just degraded, and therefore the link has some utility, but not 100% utility. This receives a credit, but not as strong a credit as being unable to use a link. Oh, and, of course, if the there is no light on the fiber, then we are (obviously) "down" as well. Make sense? Or I am over-thinking it? :) -- TTFN, patrick P.S. Now you get to think about things like "packet loss to / from where?" and whether the last mile should count. > Seriously, though, I know there are people who don't consider SLAs > to be fantasy-fiction, and some of them must not be innumerate, and > some subset of those must be on NANOG, and the intersection set > might be equal to or greater than one, right? Can anybody explain > this to me in a way I can translate into code, while still taking > myself seriously? > > -Bill > > > > From wavetossed at googlemail.com Wed Jul 29 06:04:04 2009 From: wavetossed at googlemail.com (Michael Dillon) Date: Wed, 29 Jul 2009 12:04:04 +0100 Subject: Ahoy, SLA boffins! In-Reply-To: <8070E7E5-07BF-424E-9A2F-FC736BA26E66@pch.net> References: <8070E7E5-07BF-424E-9A2F-FC736BA26E66@pch.net> Message-ID: <877585b00907290404x5a430ffaqee789b97a3b42905@mail.gmail.com> > Am I over-thinking this? Yes, I think so. Often a large component of an SLA is related to the cost of compliance versus the cost of the penalty imposed. If it is cheaper to pay the occasional penalty, rather than construct the network to meet the SLA, then the network operator will often make a purely sales/marketing decision to use the SLA without including engineering/OPS in the discussion. Also, the wording often refers to unplanned downtime so that any planned downtime doesn't get counted in the non-availability measure. And sometimes you find some allowance for packet drop during a limited time period so that if you drop a thousand packets, it doesn't count if it happens during the peak hour of the day or if all packets are dropped in a few minutes timeframe. Another limitation that I have seen refers to "core" network or "core" PoPs meaning the part of the network in the major market area (generally the USA and Western Europe) but not covering network or PoPs in "fringe" areas. I don't believe that there is any hard science behind SLAs and that most engineering/OPS teams don't even know what are the actual SLAs being given to customers. There are engineering targets that are sometimes referred to as SLAs but they are not the Service Level Agreement that is in signed customer contracts. All that aside, it would be interesting to see some standards for measuring and reporting things like "network availability" from an engineering point of view. --Michael Dillon From colin at 7compass.com Wed Jul 29 06:54:54 2009 From: colin at 7compass.com (Colin Hines) Date: Wed, 29 Jul 2009 07:54:54 -0400 Subject: Anyone subscribe who is an AT&T/Cingular SMS <-> email mail administrator? Message-ID: <41a77bc90907290454g71638af1yfcab43e3359c4e22@mail.gmail.com> I'm not sure if this is the right list, but this is my best guess at this point; If there is anyone here who administers (any/some/all/involved with) the sms to email gateways for AT&T/Cingular, could you please contact me offlist? Thanks mucho! -- Colin Hines From Rich_Andreas at Cable.Comcast.com Wed Jul 29 07:54:49 2009 From: Rich_Andreas at Cable.Comcast.com (Andreas, Rich) Date: Wed, 29 Jul 2009 08:54:49 -0400 Subject: Ahoy, SLA boffins! In-Reply-To: <8070E7E5-07BF-424E-9A2F-FC736BA26E66@pch.net> References: <8070E7E5-07BF-424E-9A2F-FC736BA26E66@pch.net> Message-ID: <997BC128AE961E4A8B880CD7442D94800D492CFD@NJCHLEXCMB01.cable.comcast.com> Bill, To be brief, but hopefully not too fleeting, the majority of the standards orgs - ITU, MEF - use packet loss to derive availability. Loss% = the % of packets which were transmitted but not received by the destination host. As for availability, loss is measured across some time period. If during that period X% of the transmitted packets were NOT lost, then the network is said to be available. Typically a 20% figure is used, e.g. if 20% of the packets transmitted during a 5-minute period were received then the network is said to be 100% Available for that 5-minute time period. Some Carriers have taken this to the extreme to say that if at least 1 packet was successfully transmitted then the network was 100% Available for the time period. Loss is a measure of the networks usability, Availability is .......?? (Meaningless??) What utility does a network have that is "Available" yet sustaining a loss rate which renders it inoperable? Rich -----Original Message----- From: Bill Woodcock [mailto:woody at pch.net] Sent: Wednesday, July 29, 2009 12:34 AM To: nanog Subject: Ahoy, SLA boffins! So I've embarked on the no-doubt-futile task of trying to interpret SLAs as empirically-verifiable technical specifications, rather than as marketing blather. And there's something that I'm finding particularly puzzling: In most SLAs, there seem to be two separate guarantees proffered: one concerning "network availability" and one concerning "packet loss." Now, if I were to put my engineer hat on, and try to _imagine_ what the difference might be, I might imagine "network availability" to have something to do with layer-2 link status being presented as "up," while packet loss would be the percentage of packets dropped. But when I actually read SLAs, "network availability" is generally defined as the portion of the month that the path from the customer's local loop to the transit or peering routers was "available" to transmit packets. Packet loss, on the other hand, is generally defined as the portion of packets which are lost while crossing that exact same piece of network. Now, what am I missing here? Is this one of those Heisenberg things, where "network availability" is the time the network _could have_ delivered a packet _when you weren't actually doing so_, while "packet loss" is the time the network _couldn't_ deliver a packet when you _were_ actually doing so? Is "network availability" inherently unmeasurable on a network that's less than 100% utilized? Am I over-thinking this? Seriously, though, I know there are people who don't consider SLAs to be fantasy-fiction, and some of them must not be innumerate, and some subset of those must be on NANOG, and the intersection set might be equal to or greater than one, right? Can anybody explain this to me in a way I can translate into code, while still taking myself seriously? -Bill From bicknell at ufp.org Wed Jul 29 09:33:14 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 29 Jul 2009 10:33:14 -0400 Subject: Ahoy, SLA boffins! In-Reply-To: <8070E7E5-07BF-424E-9A2F-FC736BA26E66@pch.net> References: <8070E7E5-07BF-424E-9A2F-FC736BA26E66@pch.net> Message-ID: <20090729143313.GA53887@ussenterprise.ufp.org> I think the desired goal here is to separate the access SLA from the backbone SLA. That is, consider a simple picture: Network Cloud------Provider Edge Router-----Local Loop-----Customer Router Network availability is the % of the time the customer router and provider edge router can communicate, and is designed to measure if the local loop is up. For instance, let's say the provider edge router looses all its uplinks to the Network Cloud, your local loop is up and functioing but you have 100% packet loss to all destinations. The "packet loss" SLA kicks in on a per-destination basis. Everything is up and working, but the provider has a full circuit and is dropping 20% of the packets on that link. You catch it, you get a credit. I think the technical reason why these are separate has to do with the expectations. If my local loop is dropping 0.5% of the packets due to errors, it is broken and must be fixed. If some random destination on the Internet is dropping 0.5% of the packets well, that's a normal day in the life of the network. Plus, if your local loop takes errors then you get a credit. However, if there's a full link in the backbone but none of your packets take it, and thus you are unaffected, you don't. Now, having said all that, and having been one of the people who've attempted to communicate sane, rational, technical ideas to marketing and legal the chance that anything sane made it in the actual contract is, well, nil. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 825 bytes Desc: not available URL: From psirt at cisco.com Wed Jul 29 10:00:00 2009 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 29 Jul 2009 15:00:00 -0000 Subject: Cisco Security Advisory: Cisco IOS Software Border Gateway Protocol 4-Byte Autonomous System Number Vulnerabilities Message-ID: <20090729.bgp@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS Software Border Gateway Protocol 4-Byte Autonomous System Number Vulnerabilities Advisory ID: cisco-sa-20090729-bgp http://www.cisco.com/warp/public/707/cisco-sa-20090729-bgp.shtml Revision: 1.0 ========= For Public Release 2009 July 29 1600 UTC (GMT) Summary ======= Recent versions of Cisco IOS Software support RFC4893 ("BGP Support for Four-octet AS Number Space") and contain two remote denial of service (DoS) vulnerabilities when handling specific Border Gateway Protocol (BGP) updates. These vulnerabilities affect only devices running Cisco IOS Software with support for four-octet AS number space (here after referred to as 4-byte AS number) and BGP routing configured. The first vulnerability could cause an affected device to reload when processing a BGP update that contains autonomous system (AS) path segments made up of more than one thousand autonomous systems. The second vulnerability could cause an affected device to reload when the affected device processes a malformed BGP update that has been crafted to trigger the issue. Cisco has released free software updates to address these vulnerabilities. No workarounds are available for the first vulnerability. A workaround is available for the second vulnerability. This advisory is posted at the following link: http://www.cisco.com/warp/public/707/cisco-sa-20090729-bgp.shtml Affected Products ================= Vulnerable Products +------------------ These vulnerabilities affect only devices running Cisco IOS and Cisco IOS XE Software (here after both referred to as simply Cisco IOS) with support for RFC4893 and that have been configured for BGP routing. The software table in the section "Software Versions and Fixes" of this advisory indicates all affected Cisco IOS Software versions that have support for RFC4893 and are affected by this vulnerability. A Cisco IOS software version that has support for RFC4893 will allow configuration of AS numbers using 4 Bytes. The following example identifies a Cisco device that has 4 byte AS number support: Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#router bgp ? <1-65535> Autonomous system number <1.0-XX.YY> 4 Octets Autonomous system number Or: Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#router bgp ? <1-4294967295> Autonomous system number <1.0-XX.YY> Autonomous system number The following example identifies a Cisco device that has 2 byte AS number support: Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#router bgp ? <1-65535> Autonomous system number A router that is running the BGP process will contain a line in the configuration that defines the autonomous system number (AS number), which can be seen by issuing the command line interface (CLI) command "show running-config". The canonical textual representation of four byte AS Numbers is standardized by the IETF through RFC5396 (Textual Representation of Autonomous System (AS) Numbers). Two major ways for textual representation have been defined as ASDOT and ASPLAIN. Cisco IOS routers support both textual representations of AS numbers. For further information about textual representation of four byte AS numbers in Cisco IOS Software consult the document "Explaining 4-Byte Autonomous System (AS) ASPLAIN and ASDOT Notation for Cisco IOS" at the following link: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/white_paper_c11_516829.html Cisco IOS Software with support for RFC4893 is affected by both vulnerabilities if BGP routing is configured using either ASPLAIN or ASDOT notation. The following example identifies a Cisco device that is configured for BGP using ASPLAIN notation: router bgp 65536 The following example identifies a Cisco device that is configured for BGP using ASDOT notation: router bgp 1.0 To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the show version command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software release name. Other Cisco devices do not have the show version command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 12.3(26) with an installed image name of C2500-IS-L: Router#show version Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by cisco Systems, Inc. Compiled Mon 17-Mar-08 14:39 by dchih !--- output truncated The following example identifies a Cisco product that is running Cisco IOS Software Release 12.4(20)T with an installed image name of C1841-ADVENTERPRISEK9-M: Router#show version Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Thu 10-Jul-08 20:25 by prod_rel_team !--- output truncated Additional information about Cisco IOS Software release naming conventions is available in "White Paper: Cisco IOS Reference Guide" at the following link: http://www.cisco.com/warp/public/620/1.html Products Confirmed Not Vulnerable +-------------------------------- The following Cisco products are confirmed not vulnerable: * Cisco IOS Software not explicitly mentioned in this Advisory * Cisco IOS XR Software * Cisco IOS NX-OS No other Cisco products are currently known to be affected by this vulnerability. Details ======= RFC4271 has defined an AS number as a two-octet entity in BGP. RFC4893 has defined an AS number as a four-octet entity in BGP. The first vulnerability could cause an affected device to reload when processing a BGP update that contains AS path segments made up of more than one thousand autonomous systems. If an affected 4-byte AS number BGP speaker receives a BGP update from a 2-byte AS number BGP speaker that contains AS path segments made up of more than one thousand autonomous systems, the device may crash with memory corruption, and the error "%%Software-forced reload" will be displayed. The following three conditions are required for successful exploitation of this vulnerability: * Affected Cisco IOS Software device is a 4-byte AS number BGP speaker * BGP peering neighbor is a 2-byte AS number BGP speaker * BGP peering neighbor is capable of sending a BGP update with a series of greater than one thousand AS numbers Note: Note: Cisco IOS, Cisco IOS XE, Cisco NX-OS and Cisco IOS XR Software, as a 2 byte AS number BGP speaker send BGP updates with a maximum of 255 AS numbers. This vulnerability is documented in Cisco Bug ID CSCsy86021 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2009-1168. The second vulnerability could cause an affected device to reload when the affected device processes a malformed BGP update that has been crafted to trigger the issue. The following three conditions are required for successful exploitation of this vulnerability: * Affected Cisco IOS Software device is a 4-byte AS number BGP speaker * BGP peering neighbor is a 2-byte AS number BGP speaker * BGP peering neighbor is capable of sending a non-RFC compliant crafted BGP update message This vulnerability is documented in Cisco Bug ID CSCta33973 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2009-2049. Further information regarding Cisco support for 4-byte AS number is available in "Cisco IOS BGP 4-Byte ASN Support" at the following link: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/data_sheet_C78-521821.html Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at http://intellishield.cisco.com/security/alertmanager/cvss CSCsy86021: Cisco IOS Software BGP Long AS-path Vulnerability CVSS Base Score - 7.1 Access Vector Network Access Complexity Medium Authentication None Confidentiality Impact None Availability Impact Complete CVSS Temporal Score - 6.7 Exploitability Functional Remediation Level Official-Fix Report Confidence Confirmed CSCta33973: Cisco IOS Software Crafted BGP Update Message Vulnerability CVSS Base Score - 5.4 Access Vector Network Access Complexity High Authentication None Confidentiality Impact None Availability Impact Complete CVSS Temporal Score - 4.5 Exploitability Functional Remediation Level Official-Fix Report Confidence Confirmed Impact ====== Successful exploitation of the vulnerabilities described in this document may result in a reload of the device. The issue could result in repeated exploitation to cause an extended DoS condition. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |----------+--------------------------------------------------------| | Affected | |Recommended | |12.0-Based| First Fixed Release | Release | | Releases | | | |----------+-------------------------------------------+------------| |12.0 |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0DA |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0DB |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0DC |Not Vulnerable | | |----------+-------------------------------------------+------------| | |Releases up to and including 12.0(32)S11 | | | |are not vulnerable; first fixed in | | |12.0S |12.0(32)S14; | | | | | | | |Releases up to and including 12.0(33)S2 are| | | |not vulnerable; first fixed in 12.0(33)S5 | | |----------+-------------------------------------------+------------| |12.0SC |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0SL |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0SP |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0ST |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0SX |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0SY |Releases up to and including 12.0(32)SY7 |12.0(32)SY10| | |are not vulnerable; first fixed in | | | |12.0(32)SY9a. | | |----------+-------------------------------------------+------------| |12.0SZ |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0T |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0W |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0WC |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0WT |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0WX |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0XA |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0XB |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0XC |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0XD |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0XE |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0XF |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0XG |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0XH |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0XI |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0XJ |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0XK |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0XL |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0XM |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0XN |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0XQ |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0XR |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0XS |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0XT |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0XV |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.0XW |Not Vulnerable | | |----------+-------------------------------------------+------------| | Affected | |Recommended | |12.1-Based| First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | |Recommended | |12.2-Based| First Fixed Release | Release | | Releases | | | |----------+-------------------------------------------+------------| |12.2 |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2B |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2BC |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2BW |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2BX |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2BY |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2BZ |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2CX |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2CY |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2CZ |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2DA |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2DD |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2DX |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2EW |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2EWA |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2EX |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2EY |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2EZ |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2FX |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2FY |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2FZ |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2IRA |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2IRB |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2IRC |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2IXA |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2IXB |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2IXC |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2IXD |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2IXE |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2IXF |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2IXG |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2IXH |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2JA |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2JK |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2MB |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2MC |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2S |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SB |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SBC |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SCA |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SCB |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SE |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SEA |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SEB |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SEC |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SED |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SEE |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SEF |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SEG |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SG |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SGA |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SL |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SM |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SO |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SQ |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SRA |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SRB |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SRC |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SRD |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2STE |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SU |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SV |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SVA |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SVC |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SVD |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SVE |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SW |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SX |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SXA |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SXB |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SXD |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SXE |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SXF |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SXH |Not Vulnerable | | |----------+-------------------------------------------+------------| | |Releases up to and including 12.2(33)SXI | | |12.2SXI |are not vulnerable; CSCsy86021 first fixed | | | |in 12.2(33)SXI2; CSCta33973 first fixed in | | | |12.2(33)SXI3 | | |----------+-------------------------------------------+------------| |12.2SY |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2SZ |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2T |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2TPC |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2XA |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2XB |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2XC |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2XD |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2XE |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2XF |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2XG |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2XH |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2XI |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2XJ |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2XK |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2XL |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2XM |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2XN |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2XNA |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2XNB |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2XNC |12.2(33)XNC2 | | |----------+-------------------------------------------+------------| |12.2XND |12.2(33)XND1; available 25th August 2009 | | |----------+-------------------------------------------+------------| |12.2XO |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2XQ |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2XR |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2XS |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2XT |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2XU |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2XV |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2XW |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YA |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YB |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YC |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YD |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YE |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YF |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YG |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YH |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YJ |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YK |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YL |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YM |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YN |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YO |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YP |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YQ |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YR |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YS |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YT |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YU |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YV |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YW |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YX |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YY |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2YZ |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2ZA |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2ZB |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2ZC |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2ZD |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2ZE |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2ZF |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2ZG |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2ZH |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2ZJ |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2ZL |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2ZM |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2ZP |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2ZU |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2ZX |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2ZY |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.2ZYA |Not Vulnerable | | |----------+-------------------------------------------+------------| | Affected | |Recommended | |12.3-Based| First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.3 based releases | |-------------------------------------------------------------------| | Affected | |Recommended | |12.4-Based| First Fixed Release | Release | | Releases | | | |----------+-------------------------------------------+------------| |12.4 |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4JA |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4JDA |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4JDC |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4JDD |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4JK |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4JL |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4JMA |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4JMB |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4JX |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4MD |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4MDA |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4MR |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4SW |Not Vulnerable | | |----------+-------------------------------------------+------------| | |Releases up to 12.4(24)T are not | | |12.4T |vulnerable; first fixed in 12.4(24)T2 | | | |available on 23-Oct-2009 | | |----------+-------------------------------------------+------------| |12.4XA |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4XB |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4XC |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4XD |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4XE |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4XF |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4XG |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4XJ |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4XK |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4XL |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4XM |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4XN |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4XP |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4XQ |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4XR |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4XT |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4XV |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4XW |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4XY |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4XZ |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4YA |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4YB |Not Vulnerable | | |----------+-------------------------------------------+------------| |12.4YD |Not Vulnerable | | +-------------------------------------------------------------------+ Cisco IOS XE Release Table +------------------------- +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |----------+--------------------------------------------------------| | Affected | | | 2.1 | There are no affected 2.1 based releases | | Releases | | |----------+--------------------------------------------------------| | Affected | | | 2.2 | There are no affected 2.2 based releases | | Releases | | |----------+--------------------------------------------------------| | Affected | Releases up to and including 2.3.1t are vulnerable; | | 2.3 | First fixed in 2.3.2 | | Releases | | |----------+--------------------------------------------------------+ | Affected | Releases up to and including 2.4.0 are vulnerable; | | 2.4 | First fixed in 2.4.1, available 25th August 2009 | | Releases | | +----------+--------------------------------------------------------+ Workarounds =========== For the first vulnerability, there are no workarounds on the affected device. Neighbors could be configured to discard routes that have more than one thousand AS numbers in the AS-path segments. This configuration will help prevent the further propagation of BGP updates with the AS path segments made up of greater than one thousand AS numbers. Note: Configuring "bgp maxas-limit [value]" on the affected device does not mitigate this vulnerability. For the second vulnerability, configuring "bgp maxas-limit [value]" on the affected device does mitigate this vulnerability. Cisco is recommends using a conservative value of 100 to mitigate this vulnerability. Consult the document "Protecting Border Gateway Protocol for the Enterprise" at the following link for additional best practices on protecting BGP infrastructures: http://www.cisco.com/web/about/security/intelligence/protecting_bgp.html Obtaining Fixed Software ======================== Cisco has released free software updates that address these vulnerabilities. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com. Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of malicious exploitation of either of these vulnerabilities, although we are aware of some customers who have seen the first vulnerability triggered within their infrastructures. Further investigation of those incidents seems to indicate that the vulnerability has been accidentally triggered. These vulnerabilities were discovered via internal product testing. Status of this Notice: FINAL ============================ This information is Cisco Highly Confidential - Do not redistribute. THIS IS A DRAFT VERSION OF A SECURITY NOTICE THAT CONTAINS UNRELEASED INFORMATION ABOUT CISCO PRODUCTS. DISTRIBUTION WITHIN CISCO IS LIMITED TO PERSONNEL WITH A NEED TO KNOW. THIS DRAFT MAY CONTAIN ERRORS OR OMIT IMPORTANT INFORMATION. THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. Distribution ============ This advisory is posted on Cisco's worldwide website at: http://www.cisco.com/warp/public/707/cisco-sa-20090729-bgp.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +-------------------------------------------------------------------+ | Revision 1.0 | 2009-July-29 1600 | Initial public release | +-------------------------------------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFKcGNc86n/Gc8U/uARAks6AKCCWLTakna/WbNzMuIbeGPJGJHnbQCfbYEi I6XwyRZTnktw7RSnT6Y/N1E= =KmUm -----END PGP SIGNATURE----- From wavetossed at googlemail.com Wed Jul 29 11:59:41 2009 From: wavetossed at googlemail.com (Michael Dillon) Date: Wed, 29 Jul 2009 17:59:41 +0100 Subject: Ahoy, SLA boffins! In-Reply-To: <20090729143313.GA53887@ussenterprise.ufp.org> References: <8070E7E5-07BF-424E-9A2F-FC736BA26E66@pch.net> <20090729143313.GA53887@ussenterprise.ufp.org> Message-ID: <877585b00907290959h7324a3b5ua160308a6c8d4148@mail.gmail.com> > Now, having said all that, and having been one of the people who've > attempted to communicate sane, rational, technical ideas to marketing > and legal the chance that anything sane made it in the actual contract > is, well, nil. I disagree. If someone takes the trouble to publish a technical document describing a sane technical way to measure a network SLA, and they also provide code for measuring/calculating the SLA, then there is a good chance that the industry will pick it up. Look at 95th percentile billing. Dave Rand at Abovenet thought it up, probably to simplify the billing process and keep billing overhead costs down. Then UUNet picked it up and suddenly just about everyone was offering a 95th percentile billing model. -- Michael Dillon From David_Hiers at adp.com Wed Jul 29 12:05:20 2009 From: David_Hiers at adp.com (Hiers, David) Date: Wed, 29 Jul 2009 12:05:20 -0500 Subject: OT: Voice Operators' Group forming In-Reply-To: <4A6F78E3.9090503@thewybles.com> References: <1248674313.13748.10.camel@petrie> <81CDFC77FB2DC54DB875D4F8FFC36CE00A92089C42@DSMAIL2HE.ds.ad.adp.com> <276D7E82-2C3F-44FF-A9EA-E9799A5D150B@ianai.net> <4D8EE8D5295A4E6C837103F209DBD799@Honkin> <4A6E2365.3050901@rollernet.us> <81CDFC77FB2DC54DB875D4F8FFC36CE00A921D4A3C@DSMAIL2HE.ds.ad.adp.com> <4A6F6FB1.3000607@thewybles.com> <6ff30abd0907281449k122dea6dt97e4816d1ddd0c08@mail.gmail.com> <4A6F78E3.9090503@thewybles.com> Message-ID: <81CDFC77FB2DC54DB875D4F8FFC36CE00A9229B252@DSMAIL2HE.ds.ad.adp.com> Hi All, We're making progress... I registered the domains voiceops.org and voiceops.net. No matter what the final name becomes, at least we've got some domains that aren't too hard on the eyes. Some noble souls have already volunteered to host it on a proper mailman server. Nothing is set up yet, but it's coming together. Thanks, David Hiers -----Original Message----- From: Charles Wyble [mailto:charles at thewybles.com] Sent: Tuesday, July 28, 2009 3:17 PM To: nanog at nanog.org Subject: Re: OT: Voice Operators' Group forming jamie wrote: > puck.nether.net . Right. That's what I meant. > > way to volunteer someone else's box :-) Good point. My apologies. Google groups then. :) This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. From funkyfun at gmail.com Wed Jul 29 12:49:42 2009 From: funkyfun at gmail.com (Net) Date: Wed, 29 Jul 2009 13:49:42 -0400 Subject: Ahoy, SLA boffins! In-Reply-To: <8070E7E5-07BF-424E-9A2F-FC736BA26E66@pch.net> References: <8070E7E5-07BF-424E-9A2F-FC736BA26E66@pch.net> Message-ID: Aawaw On 7/29/09, Bill Woodcock wrote: > > So I've embarked on the no-doubt-futile task of trying to interpret > SLAs as empirically-verifiable technical specifications, rather than > as marketing blather. And there's something that I'm finding > particularly puzzling: > > In most SLAs, there seem to be two separate guarantees proffered: one > concerning "network availability" and one concerning "packet loss." > Now, if I were to put my engineer hat on, and try to _imagine_ what > the difference might be, I might imagine "network availability" to > have something to do with layer-2 link status being presented as "up," > while packet loss would be the percentage of packets dropped. But > when I actually read SLAs, "network availability" is generally defined > as the portion of the month that the path from the customer's local > loop to the transit or peering routers was "available" to transmit > packets. Packet loss, on the other hand, is generally defined as the > portion of packets which are lost while crossing that exact same piece > of network. > > Now, what am I missing here? Is this one of those Heisenberg things, > where "network availability" is the time the network _could have_ > delivered a packet _when you weren't actually doing so_, while "packet > loss" is the time the network _couldn't_ deliver a packet when you > _were_ actually doing so? > > Is "network availability" inherently unmeasurable on a network that's > less than 100% utilized? > > Am I over-thinking this? > > Seriously, though, I know there are people who don't consider SLAs to > be fantasy-fiction, and some of them must not be innumerate, and some > subset of those must be on NANOG, and the intersection set might be > equal to or greater than one, right? Can anybody explain this to me > in a way I can translate into code, while still taking myself seriously? > > -Bill > > > > > From dholmes at mwdh2o.com Wed Jul 29 13:05:05 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Wed, 29 Jul 2009 11:05:05 -0700 Subject: Ahoy, SLA boffins! In-Reply-To: <8070E7E5-07BF-424E-9A2F-FC736BA26E66@pch.net> References: <8070E7E5-07BF-424E-9A2F-FC736BA26E66@pch.net> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E0961CFF4@usmsxt104.mwd.h2o> We use the BRIX active measurement system (BRIX now owned by EXFO) which gathers round trip time, packet loss, and jitter randomly every minute 24x7x365 for our major backbone links to calculate SLAs. "Network Availability" can be measured empirically using BRIX calculated values of packet loss, and expressed in terms of #9's, which BRIX will also calculate over any time period for which BRIX historical data is being kept. BRIX historical data is kept on an embedded Oracle data base. BRIX usually runs on a Solaris SMP server. -----Original Message----- From: Bill Woodcock [mailto:woody at pch.net] Sent: Tuesday, July 28, 2009 9:34 PM To: nanog Subject: Ahoy, SLA boffins! So I've embarked on the no-doubt-futile task of trying to interpret SLAs as empirically-verifiable technical specifications, rather than as marketing blather. And there's something that I'm finding particularly puzzling: In most SLAs, there seem to be two separate guarantees proffered: one concerning "network availability" and one concerning "packet loss." Now, if I were to put my engineer hat on, and try to _imagine_ what the difference might be, I might imagine "network availability" to have something to do with layer-2 link status being presented as "up," while packet loss would be the percentage of packets dropped. But when I actually read SLAs, "network availability" is generally defined as the portion of the month that the path from the customer's local loop to the transit or peering routers was "available" to transmit packets. Packet loss, on the other hand, is generally defined as the portion of packets which are lost while crossing that exact same piece of network. Now, what am I missing here? Is this one of those Heisenberg things, where "network availability" is the time the network _could have_ delivered a packet _when you weren't actually doing so_, while "packet loss" is the time the network _couldn't_ deliver a packet when you _were_ actually doing so? Is "network availability" inherently unmeasurable on a network that's less than 100% utilized? Am I over-thinking this? Seriously, though, I know there are people who don't consider SLAs to be fantasy-fiction, and some of them must not be innumerate, and some subset of those must be on NANOG, and the intersection set might be equal to or greater than one, right? Can anybody explain this to me in a way I can translate into code, while still taking myself seriously? -Bill From herrin-nanog at dirtside.com Wed Jul 29 14:25:02 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Wed, 29 Jul 2009 15:25:02 -0400 Subject: Ahoy, SLA boffins! In-Reply-To: <8070E7E5-07BF-424E-9A2F-FC736BA26E66@pch.net> References: <8070E7E5-07BF-424E-9A2F-FC736BA26E66@pch.net> Message-ID: <3c3e3fca0907291225y6bf98884o9679824eadf73e4@mail.gmail.com> On Wed, Jul 29, 2009 at 12:34 AM, Bill Woodcock wrote: > Am I over-thinking this? The SLA's I've looked at promise me that if their service is hard down for a week (with no ambiguity whatsoever) they'll credit my bill for upwards of 2% of the $50k/year or so I spend on the Internet connection for my mutli-million dollar online service. So yeah, you're overthinking it. When they start coupling those SLAs with some sort of serious business loss insurance, then paying attention to the SLA and carefully examining what constitutes failure may make some kind sense at a technical level. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jbotctc at gmail.com Wed Jul 29 14:59:44 2009 From: jbotctc at gmail.com (Jim Wininger) Date: Wed, 29 Jul 2009 15:59:44 -0400 Subject: Subnet Size for BGP peers. Message-ID: <15a18b860907291259n304fe598x763b650a6f0dc44a@mail.gmail.com> I have a question about the subnet size for BGP peers. Typically when we turn up a new BGP customer we turn them up on a /29 or a /30. That seems to be the "norm". We connect to many of our BGP peers with ethernet. It would be a simple matter to allocate a /24 for connectivity to the customer on a shared link. This would help save on some address space. My question is, is this in general good or bad idea? Have others been down this path and found that it was a bad idea? I can see some of the pothols on this path (BGP session hijacking, incorrectly configured customer routers etc). These issues could be at least partially mitigated. Are there larger issues when doing something like this or is it a practical idea? -- Jim Wininger -- Jim Wininger jbotctc at gmail.com From jcdill.lists at gmail.com Wed Jul 29 15:19:41 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Wed, 29 Jul 2009 13:19:41 -0700 Subject: Ahoy, SLA boffins! In-Reply-To: <3c3e3fca0907291225y6bf98884o9679824eadf73e4@mail.gmail.com> References: <8070E7E5-07BF-424E-9A2F-FC736BA26E66@pch.net> <3c3e3fca0907291225y6bf98884o9679824eadf73e4@mail.gmail.com> Message-ID: <4A70AEDD.5030206@gmail.com> William Herrin wrote: > On Wed, Jul 29, 2009 at 12:34 AM, Bill Woodcock wrote: > >> Am I over-thinking this? >> > > The SLA's I've looked at promise me that if their service is hard down > for a week (with no ambiguity whatsoever) they'll credit my bill for > upwards of 2% of the $50k/year or so I spend on the Internet > connection for my mutli-million dollar online service. > I'm really surprised anyone considers this an SLA, or anything special in a business contract. I automatically expect to get a credit of 1.923% if the service were not provided for a period of 168 hours, no questions asked and no SLA required. When service is simply not provided, there's nothing special about not having to pay for it. I don't know of any business where you can have a contract that requires you to pay your monthly/annual fee for services when said services are not provided. If you have a housekeeping or lawn service that is supposed to come once a week, and you have an annual contract with them for this service at $50/week, and they miss a week (provide no service) you don't pay them anyway for that missed week. You don't need an SLA in your contract with them to have this right to withhold payment for the period of time when the services are not provided *at all*. An SLA comes into play when a service is degraded below the quality you contracted for. What credit do they give you when you have 168 hours of degraded service, e.g. 50% of the service level you specified in your RFQ? That's where your SLA comes in. The SLA specifies at what point your service is considered "degraded" (how much below the contracted service level, and how long of a time period is required before it is considered below grade) and what $credit you may receive when you are provided some service, but not to the level specified in your contract. jc From herrin-nanog at dirtside.com Wed Jul 29 15:38:18 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Wed, 29 Jul 2009 16:38:18 -0400 Subject: Ahoy, SLA boffins! In-Reply-To: <4A70AEDD.5030206@gmail.com> References: <8070E7E5-07BF-424E-9A2F-FC736BA26E66@pch.net> <3c3e3fca0907291225y6bf98884o9679824eadf73e4@mail.gmail.com> <4A70AEDD.5030206@gmail.com> Message-ID: <3c3e3fca0907291338j497ccd8cod45687b2b141d692@mail.gmail.com> On Wed, Jul 29, 2009 at 4:19 PM, JC Dill wrote: > William Herrin wrote: >> The SLA's I've looked at promise me that if their service is hard down >> for a week (with no ambiguity whatsoever) they'll credit my bill for >> upwards of 2% of the $50k/year or so I spend on the Internet >> connection for my mutli-million dollar online service. > An SLA comes into play when a service is degraded below the quality you > contracted for. ?What credit do they give you when you have 168 hours of > degraded service, e.g. 50% of the service level you specified in your RFQ? > ?That's where your SLA comes in. ?The SLA specifies at what point your > service is considered "degraded" (how much below the contracted service > level, and how long of a time period is required before it is considered > below grade) and what $credit you may receive when you are provided some > service, but not to the level specified in your contract. Hi JC, Perhaps you miss my point: what the ISP is offering to pay me as a result of a failure to deliver adequate service is so much less than my loss for the same as to render the payment meaningless. I'm gonna terminate the contract for nonperformance and hire someone who can get the job done long before its worth my time to chase you for an SLA-based service credit. And we both know it. The only way I ever chase you for an SLA credit is I'm playing the blame game instead of doing my job for my customers. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jml at packetpimp.org Wed Jul 29 15:52:38 2009 From: jml at packetpimp.org (Jason LeBlanc) Date: Wed, 29 Jul 2009 16:52:38 -0400 Subject: OT: Voice Operators' Group forming In-Reply-To: <200907282149.WAA18355@sunf10.rd.bbc.co.uk> References: <200907282149.WAA18355@sunf10.rd.bbc.co.uk> Message-ID: <4A70B696.4030303@packetpimp.org> Brandon Butterworth wrote: >> NAVOG works for me. >> > > I'd prefer Voice Operators' Group Online Network > > brandon > > *claps* From cmeidinger at sendmail.com Wed Jul 29 16:42:13 2009 From: cmeidinger at sendmail.com (Chris Meidinger) Date: Wed, 29 Jul 2009 23:42:13 +0200 Subject: OT: Voice Operators' Group forming In-Reply-To: <4A70B696.4030303@packetpimp.org> References: <200907282149.WAA18355@sunf10.rd.bbc.co.uk> <4A70B696.4030303@packetpimp.org> Message-ID: <5B645D36-9898-41E7-8888-BC5193F659B8@sendmail.com> On 29.07.2009, at 22:52, Jason LeBlanc wrote: > Brandon Butterworth wrote: >>> NAVOG works for me. >>> >> >> I'd prefer Voice Operators' Group Online Network >> >> brandon >> >> > *claps* Imagine the poetry you have to listen to when _those_ guys put you on hold... From nanog at daork.net Wed Jul 29 16:51:03 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 30 Jul 2009 09:51:03 +1200 Subject: Subnet Size for BGP peers. In-Reply-To: <15a18b860907291259n304fe598x763b650a6f0dc44a@mail.gmail.com> References: <15a18b860907291259n304fe598x763b650a6f0dc44a@mail.gmail.com> Message-ID: <5B1316A3-9E38-4598-B8EE-7D2DD6508E91@daork.net> On 30/07/2009, at 7:59 AM, Jim Wininger wrote: > I have a question about the subnet size for BGP peers. Typically > when we > > turn up a new BGP customer we turn them up on a /29 or a /30. That > seems to > > be the "norm". > > > We connect to many of our BGP peers with ethernet. It would be a > simple > > matter to allocate a /24 for connectivity to the customer on a > shared link. > > This would help save on some address space. > > > My question is, is this in general good or bad idea? Have others > been down > > this path and found that it was a bad idea? I can see some of the > pothols on > > this path (BGP session hijacking, incorrectly configured customer > routers > > etc). These issues could be at least partially mitigated. Are there > larger > > issues when doing something like this or is it a practical idea? What is your access network? Do you have a switch port per customer? If so, look in to private VLANs on Cisco, or whatever similar feature exists for your vendor. -- Nathan Ward From stephen at sprunk.org Wed Jul 29 16:52:13 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 29 Jul 2009 16:52:13 -0500 Subject: Ahoy, SLA boffins! In-Reply-To: <4A70AEDD.5030206@gmail.com> References: <8070E7E5-07BF-424E-9A2F-FC736BA26E66@pch.net> <3c3e3fca0907291225y6bf98884o9679824eadf73e4@mail.gmail.com> <4A70AEDD.5030206@gmail.com> Message-ID: <4A70C48D.6070206@sprunk.org> JC Dill wrote: > William Herrin wrote: >> The SLA's I've looked at promise me that if their service is hard >> down for a week (with no ambiguity whatsoever) they'll credit my bill >> for upwards of 2% of the $50k/year or so I spend on the Internet >> connection for my mutli-million dollar online service. > > I'm really surprised anyone considers this an SLA, or anything special > in a business contract. I automatically expect to get a credit of > 1.923% if the service were not provided for a period of 168 hours, no > questions asked and no SLA required. > > When service is simply not provided, there's nothing special about not > having to pay for it. Read your contract closely and you'll find that, except for an explicit SLA clause (which will cost you extra), they make no guarantee that the circuit will work at all and you'll still owe them money. On top of that, the SLA payouts are usually capped at an amount _less_ than the price increase due to demanding an SLA. If your circuit costs $2k/mo, and it's down for an entire month, you'll probably still owe them at least $1500 for that non-service -- and you could buy a non-SLA service for the same $1500/mo. (Savvy customers who are spending big bucks know how to negotiate these terms to be more favorable, but most customers aren't savvy unless they've already been burned by this.) S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From andrew.wallace at rocketmail.com Wed Jul 29 16:53:39 2009 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Wed, 29 Jul 2009 22:53:39 +0100 Subject: Fwd: Dan Kaminsky Message-ID: <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> ---------- Forwarded message ---------- From: andrew.wallace Date: Wed, Jul 29, 2009 at 6:22 PM Subject: Real Black Hats Hack Security Experts on Eve of Conference To: Information Security Mailing List LAS VEGAS ? Two noted security professionals were targeted this week by hackers who broke into their web pages, stole personal data and posted it online on the eve of the Black Hat security conference. Security researcher Dan Kaminsky and former hacker Kevin Mitnick were targeted because of their high profiles, and because the intruders consider the two notables to be posers who hype themselves and do little to increase security, according to a note the hackers posted in a file left on Kaminsky?s site. The files taken from Kaminsky?s server included private e-mails between Kaminisky and other security researchers, highly personal chat logs, and a list of files he has purportedly downloaded that pertain to dating and other topics. The hacks also targeted other security professionals, and were apparently timed to coincide with the Black Hat and DefCon security conference in Las Vegas this week, where Kaminsky is unveiling new research on digital certificates and hash collisions. The hackers criticized Mitnick and Kaminsky for using insecure blogging and hosting services to publish their sites, that allowed the hackers to gain easy access to their data. http://www.wired.com/threatlevel/2009/07/kaminsky-hacked/ http://www.leetupload.com/zf05.txt From pstewart at nexicomgroup.net Wed Jul 29 17:02:07 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Wed, 29 Jul 2009 18:02:07 -0400 Subject: Subnet Size for BGP peers. In-Reply-To: <15a18b860907291259n304fe598x763b650a6f0dc44a@mail.gmail.com> References: <15a18b860907291259n304fe598x763b650a6f0dc44a@mail.gmail.com> Message-ID: /29's here for everyone.... great for troubleshooting and any future additions typically required...;) -----Original Message----- From: Jim Wininger [mailto:jbotctc at gmail.com] Sent: July 29, 2009 4:00 PM To: nanog at nanog.org Subject: Subnet Size for BGP peers. I have a question about the subnet size for BGP peers. Typically when we turn up a new BGP customer we turn them up on a /29 or a /30. That seems to be the "norm". We connect to many of our BGP peers with ethernet. It would be a simple matter to allocate a /24 for connectivity to the customer on a shared link. This would help save on some address space. My question is, is this in general good or bad idea? Have others been down this path and found that it was a bad idea? I can see some of the pothols on this path (BGP session hijacking, incorrectly configured customer routers etc). These issues could be at least partially mitigated. Are there larger issues when doing something like this or is it a practical idea? -- Jim Wininger -- Jim Wininger jbotctc at gmail.com ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From bbillon-ml at splio.fr Wed Jul 29 17:09:27 2009 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Thu, 30 Jul 2009 00:09:27 +0200 Subject: Subnet Size for BGP peers. In-Reply-To: <15a18b860907291259n304fe598x763b650a6f0dc44a@mail.gmail.com> References: <15a18b860907291259n304fe598x763b650a6f0dc44a@mail.gmail.com> Message-ID: <4A70C897.2060108@splio.fr> Imagine two of your clients are competitors, they probably don't want to be on the same IP range. And yes, when you sell your service to several customers, you don't want one of them blowing up all the other's SLA. IXs use /24, as far as I know, and peers connected there can usually use md5 password if they want to. But in that case, some troubles like arp broadcast storm could happen, coming from any of the connected network. I guess it's not the same level of service, but I agree, many /30 or /29 are a big loss of addresses. It reminds me GLBP with two gateways: on 10.0.0.0/29, you got 10.0.0.0 : network 10.0.0.7 : broadcast 10.0.0.1 : gw1 10.0.0.2 : gw2 10.0.0.6 : virtual gw only 3, 4 and 5 for other equipments. Who knows any other good way to lose IP addresses? Jim Wininger a ?crit : > I have a question about the subnet size for BGP peers. Typically when we > > turn up a new BGP customer we turn them up on a /29 or a /30. That seems to > > be the "norm". > > > We connect to many of our BGP peers with ethernet. It would be a simple > > matter to allocate a /24 for connectivity to the customer on a shared link. > > This would help save on some address space. > > > My question is, is this in general good or bad idea? Have others been down > > this path and found that it was a bad idea? I can see some of the pothols on > > this path (BGP session hijacking, incorrectly configured customer routers > > etc). These issues could be at least partially mitigated. Are there larger > > issues when doing something like this or is it a practical idea? > > From andrew.wallace at rocketmail.com Wed Jul 29 18:27:45 2009 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Thu, 30 Jul 2009 00:27:45 +0100 Subject: Dan Kaminsky In-Reply-To: <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> References: <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> Message-ID: <4b6ee9310907291627h1f61d48boadcf19416e27eaf6@mail.gmail.com> --- On Wed, 7/29/09, Scott Weeks wrote: > From: Scott Weeks > Subject: Re: Fwd: Dan Kaminsky > To: "andrew.wallace" > Date: Wednesday, July 29, 2009, 10:10 PM > > > --- andrew.wallace at rocketmail.com > wrote: > > http://www.leetupload.com/zf05.txt > ------------------------------------------ > > > This one is off line: > > > Site Temporarily Unavailable > We apologize for the inconvenience. Please contact the > webmaster/ tech support immediately to have them rectify > this. > > error id: "bad_httpd_conf" > > > scott > > Dan Kaminsky mirrors: http://r00tsecurity.org/files/zf05.txt http://antilimit.net/zf05.txt Much thanks, Andrew > From randy at psg.com Wed Jul 29 22:22:55 2009 From: randy at psg.com (Randy Bush) Date: Thu, 30 Jul 2009 05:22:55 +0200 Subject: Fwd: Dan Kaminsky In-Reply-To: <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> References: <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> Message-ID: > LAS VEGAS ? Two noted security professionals were targeted this week > by hackers who broke into their web pages, stole personal data and > posted it online on the eve of the Black Hat security conference. boooooring. randy From trelane at trelane.net Wed Jul 29 23:13:52 2009 From: trelane at trelane.net (Andrew D Kirch) Date: Thu, 30 Jul 2009 00:13:52 -0400 Subject: Fwd: Dan Kaminsky In-Reply-To: References: <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> Message-ID: <4A711E00.7030602@trelane.net> Randy Bush wrote: >> LAS VEGAS ? Two noted security professionals were targeted this week >> by hackers who broke into their web pages, stole personal data and >> posted it online on the eve of the Black Hat security conference. >> > > boooooring. > > randy > > Two noted security professionals, and Kevin Mitnick, whom no one gives a damn about, were targeted... FTFY Andrew D Kirch From randy at psg.com Wed Jul 29 23:23:58 2009 From: randy at psg.com (Randy Bush) Date: Thu, 30 Jul 2009 06:23:58 +0200 Subject: Fwd: Dan Kaminsky In-Reply-To: <4A711E00.7030602@trelane.net> References: <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> <4A711E00.7030602@trelane.net> Message-ID: >>> LAS VEGAS ? Two noted security professionals were targeted this week >>> by hackers who broke into their web pages, stole personal data and >>> posted it online on the eve of the Black Hat security conference. >> boooooring. > Two noted security professionals, and Kevin Mitnick, whom no one gives a > damn about, were targeted... Ettore Bugatti, maker of the finest cars of his day, was once asked why his cars had less than perfect brakes. He replied something like, "Any fool can make a car stop. It takes a genius to make a car go." so i am not particularly impressed by news of children making a car stop. randy From barton at gnaps.com Wed Jul 29 23:22:27 2009 From: barton at gnaps.com (Barton F Bruce) Date: Thu, 30 Jul 2009 00:22:27 -0400 Subject: Subnet Size for BGP peers. References: <15a18b860907291259n304fe598x763b650a6f0dc44a@mail.gmail.com> Message-ID: ----- Original Message ----- From: "Jim Wininger" To: Sent: Wednesday, July 29, 2009 3:59 PM Subject: Subnet Size for BGP peers. > I have a question about the subnet size for BGP peers. Typically when we > > turn up a new BGP customer we turn them up on a /29 or a /30. That seems > to > > be the "norm". > We connect to many of our BGP peers with ethernet. It would be a simple So what is wrong with a /31? We use /30s but if you are short on IP space, look at using /31 rather than /30 links. Cuts your space usage in half. If I remember correctly, the BIG problem with using /31s when they first became "legal" was to decide if the customer still gets the higher numbered IP address (or you the lower one), or if you still get the ODD number. No kidding, it is a problem for some! Where you are on ethernet, use a seperate 802.1q vlan per customer and have your switch give the customer untagged packets. If you have downstreams in your COLO, and either free or as a paid service, offer to setup private vlans in your switch for any pair or group of customers that need to also connect to each other privately for whatever they are doing. In that latter case, they will be getting tagged packets but their routers or switches should have no problem dealing with them. We don't charge for physical crossconnects, so this has saved us having to do physical crossconnects between customers, and has saved customers router ports. From swmike at swm.pp.se Wed Jul 29 23:28:26 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 30 Jul 2009 06:28:26 +0200 (CEST) Subject: Subnet Size for BGP peers. In-Reply-To: <4A70C897.2060108@splio.fr> References: <15a18b860907291259n304fe598x763b650a6f0dc44a@mail.gmail.com> <4A70C897.2060108@splio.fr> Message-ID: On Thu, 30 Jul 2009, Benjamin Billon wrote: > Who knows any other good way to lose IP addresses? I know how to not lose them: int lo30 ip address 192.168.0.1 255.255.255.0 int gi2.10 encap dot1q 10 desc cust 1 ip address unnumbered lo30 int gi2.11 encap dot1q 11 desc cust 2 ip address unnumbered lo30 ip route 192.168.0.2 255.255.255.255 gi2.10 ip route 192.168.0.3 255.255.255.255 gi2.11 etc. Now you can have one customer per vlan but still have them share the same IP subnet. This works with vlan interfaces as well. I don't remember if you have to do local-proxy-arp or not, but if you're running bgp you could always do next-hop-self to be sure it hops via the gateway. -- Mikael Abrahamsson email: swmike at swm.pp.se From jcdill.lists at gmail.com Thu Jul 30 01:59:39 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Wed, 29 Jul 2009 23:59:39 -0700 Subject: Ahoy, SLA boffins! In-Reply-To: <4A70C48D.6070206@sprunk.org> References: <8070E7E5-07BF-424E-9A2F-FC736BA26E66@pch.net> <3c3e3fca0907291225y6bf98884o9679824eadf73e4@mail.gmail.com> <4A70AEDD.5030206@gmail.com> <4A70C48D.6070206@sprunk.org> Message-ID: <4A7144DB.1040101@gmail.com> Stephen Sprunk wrote: > Read your contract closely and you'll find that, except for an explicit > SLA clause (which will cost you extra), they make no guarantee that the > circuit will work at all and you'll still owe them money. I am not a lawyer. However, over the years many lawyers have told me you can't have a legally enforcible contract that says (in essence) you owe me money even if I give you absolutely nothing in exchange (or visa versa). A legally enforcible contract must *always* have an exchange of consideration - I give you something (money, labor, tangible property, intangible property) in exchange for something you give me. Many businesses try this type of crap all the time, but (according to the above mentioned lawyers) it's not worth the paper it is written on. They make these clauses hoping the other party doesn't know their rights. However, contract law (e.g. the UCC) trumps unenforcible and illegal clauses in your contracts (this is why we *have* civil laws regarding civil contracts, otherwise there would be no point in civil laws at all). But please don't take my word for it, ask your own lawyer to review your contract and give you an opinion about the legality and enforceability of clauses of this type, in your particular contract. jc From brent at servuhome.net Thu Jul 30 02:46:50 2009 From: brent at servuhome.net (Brent Jones) Date: Thu, 30 Jul 2009 00:46:50 -0700 Subject: Open Source / Low Cost NMS for Server Hardware / Application Monitoring In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D122128063@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F9D122128063@PUR-EXCH07.ox.com> Message-ID: On Wed, Jul 22, 2009 at 11:08 AM, Matthew Huff wrote: > I apologize for not starting a new thread before, I didn't realize that the nanog mailing list created a thread-index rather than using the subject. > > Even though NANOG is primarily for network operators, I know that a number of members work in NOCs where there is also monitoring of servers/applications. I would appreciate it if anyone has suggestions about monitoring systems that would be applicable to our environment. We have a large number of custom applications on a large number of hosts including Windows 2003/2008, Linux x86/x86_64 and Solaris Sparc/x86_64. We are looking for a better way of monitoring our environment. We are looking for recommendations for opensource or low-cost. We would prefer solutions where the basic monitoring is ready out of the box. Native agents with custom scripting would be highly desired (rather than SNMP/DMI/WMI polling). > > Some of our requirements: > > . ? ? ? Native agents for Windows 2003/2008, Linux, Linux x86_64, Solaris Sparc and Solaris x86_64. Either binaries or source code. > . ? ? ? Ability to send alerts via email, pager and/or snmp > . ? ? ? Monitoring of OS properties like memory, disk, cpu, etc... > . ? ? ? Ability to extend agents with scripting to allow monitoring of custom services > . ? ? ? Plug-in architecture for third-party add-ons > . ? ? ? Reliable Architecture > . ? ? ? Reasonable user interface > . ? ? ? Non-blocking polling > . ? ? ? Active Project (New Releases on regular basis and have existed for a reasonable period) > > Based on our research and feedback from NANOG, we have put a preliminary list of product to evaluate: > > Hyperic ? ? ? ? http://www.hyperic.com/ > OpenNMS ? ? ? ? http://www.opennms.org/wiki/Main_Page > opsview ? ? ? ? http://www.opsview.org/ > osimius ? ? ? ? http://www.osmius.net/en/ > PandoraFMS ? ? ? ? ? ? ?http://pandorafms.org/ > Zabbix ? ? ? ? ?http://www.zabbix.com/ > Groundwork ? ? ? ? ? ? ?http://www.groundworkopensource.com/ > Nagios ? ? ? ? ?http://www.nagios.org > Zenoss ? ? ? ? ?http://zenoss.com > OpManager ? ? ? ? ? ? ? http://www.manageengine.com > Orion ? ? ? ? ? ? ? ? ? http://www.solarwinds.com/products/orion/ > BigBrother ? ? ? ? ? ? ?http://bb4.com/ > Argus ? ? ? ? ? ? ? ? ? http://argus.tcp4me.com/ > Xymon ? ? ? ? ? ? ? ? ? http://www.xymon.com > Spiceworks ? ? ? ? ? ? ?http://www.spiceworks.com/ > ICINGA ? ? ? ? ?http://www.icinga.org > > ---- > Matthew Huff ? ? ? | One Manhattanville Rd > OTA Management LLC | Purchase, NY 10577 > http://www.ox.com ?| Phone: 914-460-4039 > aim: matthewbhuff ?| Fax: ? 914-460-4139 > > > > > I use Zabbix and Cacti primarily, but in the same situation - there has to be better stuff out there. You listed some that I wasn't familiar with, so I'll try those out. I did use Hyperic, while it has a lot of features, its bulky UI really detracts from its abilities. Wish Zabbix had some more community and developers, has many promising features, but needs SNMP and IPMI more tightly integrated. -- Brent Jones brent at servuhome.net From swmike at swm.pp.se Thu Jul 30 04:04:09 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 30 Jul 2009 11:04:09 +0200 (CEST) Subject: Subnet Size for BGP peers. In-Reply-To: References: <15a18b860907291259n304fe598x763b650a6f0dc44a@mail.gmail.com> <4A70C897.2060108@splio.fr> Message-ID: On Thu, 30 Jul 2009, Mikael Abrahamsson wrote: > I don't remember if you have to do local-proxy-arp or not, but if you're > running bgp you could always do next-hop-self to be sure it hops via the > gateway. I did remember that this is identical to the behaviour described in RFC3069. -- Mikael Abrahamsson email: swmike at swm.pp.se From adrian.minta at gmail.com Thu Jul 30 04:06:04 2009 From: adrian.minta at gmail.com (Adrian Minta) Date: Thu, 30 Jul 2009 12:06:04 +0300 Subject: Subnet Size for BGP peers. In-Reply-To: <15a18b860907291259n304fe598x763b650a6f0dc44a@mail.gmail.com> References: <15a18b860907291259n304fe598x763b650a6f0dc44a@mail.gmail.com> Message-ID: <4A71627C.2030108@gmail.com> Shared link for BGP connectivity is a bad idea. Imagine that one of your customer leave proxy-arp on his interface, or imagine that he makes a Layer2 loop. Then all other customers will be affected. Usually a customer with BGP is on another level, so a gain of some IP's doesn't worth the trouble IMHO. -- Best regards, Adrian Minta From leothelion.murtaza at gmail.com Thu Jul 30 04:16:29 2009 From: leothelion.murtaza at gmail.com (Murtaza) Date: Thu, 30 Jul 2009 15:16:29 +0600 Subject: caches for peer-to-peer trafic Message-ID: <949b74980907300216j5300dd26rd13ffba1bb48bb48@mail.gmail.com> Hey guys, I wanted to ask that if ISPs use any kind of caching system for peer-to-peer traffic? It seems to be difficult thing to do, though there is some research going on (including me). However, I wanted to ask about the practices being used by ISPs and I suppose this is the best audience to ask such a question. Thanks and regards, Ghulam Murtaza PhD Student, Lahore University of Management Sciences From leigh.porter at ukbroadband.com Thu Jul 30 04:23:21 2009 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Thu, 30 Jul 2009 10:23:21 +0100 Subject: Ahoy, SLA boffins! References: <8070E7E5-07BF-424E-9A2F-FC736BA26E66@pch.net> <3c3e3fca0907291225y6bf98884o9679824eadf73e4@mail.gmail.com> <4A70AEDD.5030206@gmail.com> <4A70C48D.6070206@sprunk.org> Message-ID: Indeed, that's why some companies have contracts managers with experience of thieving gits who try to rip you off on SLAs. We indeed have been burned and so our contracts worth any money now have real good incentives for the vendors to come up with the goods and make what they sell us work. Even though, sometimes important stuff gets dropped because the vendor refuses to be bound by it, and then, we get screwed over it. -- Leigh -----Original Message----- From: Stephen Sprunk [mailto:stephen at sprunk.org] Sent: Wed 7/29/2009 10:52 PM To: JC Dill Cc: North American Noise and Off-topic Gripes Subject: Re: Ahoy, SLA boffins! JC Dill wrote: > William Herrin wrote: >> The SLA's I've looked at promise me that if their service is hard >> down for a week (with no ambiguity whatsoever) they'll credit my bill >> for upwards of 2% of the $50k/year or so I spend on the Internet >> connection for my mutli-million dollar online service. > > I'm really surprised anyone considers this an SLA, or anything special > in a business contract. I automatically expect to get a credit of > 1.923% if the service were not provided for a period of 168 hours, no > questions asked and no SLA required. > > When service is simply not provided, there's nothing special about not > having to pay for it. Read your contract closely and you'll find that, except for an explicit SLA clause (which will cost you extra), they make no guarantee that the circuit will work at all and you'll still owe them money. On top of that, the SLA payouts are usually capped at an amount _less_ than the price increase due to demanding an SLA. If your circuit costs $2k/mo, and it's down for an entire month, you'll probably still owe them at least $1500 for that non-service -- and you could buy a non-SLA service for the same $1500/mo. (Savvy customers who are spending big bucks know how to negotiate these terms to be more favorable, but most customers aren't savvy unless they've already been burned by this.) S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From rdobbins at arbor.net Thu Jul 30 04:34:33 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 30 Jul 2009 16:34:33 +0700 Subject: caches for peer-to-peer trafic In-Reply-To: <949b74980907300216j5300dd26rd13ffba1bb48bb48@mail.gmail.com> References: <949b74980907300216j5300dd26rd13ffba1bb48bb48@mail.gmail.com> Message-ID: On Jul 30, 2009, at 4:16 PM, Murtaza wrote: > I wanted to ask that if ISPs use any kind of caching system for peer- > to-peer traffic? Oversi and ApplianSys are two companies which I know some SPs use. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From randy at psg.com Thu Jul 30 07:10:09 2009 From: randy at psg.com (Randy Bush) Date: Thu, 30 Jul 2009 14:10:09 +0200 Subject: sat-3 cut? Message-ID: http://news.bbc.co.uk/2/hi/technology/8176014.stm From randy at psg.com Thu Jul 30 07:12:32 2009 From: randy at psg.com (Randy Bush) Date: Thu, 30 Jul 2009 14:12:32 +0200 Subject: sat-3 cut? In-Reply-To: References: Message-ID: better lay coverage in al jazeera http://english.aljazeera.net/news/africa/2009/07/2009730775992910.html randy From wbailey at gci.com Thu Jul 30 07:14:12 2009 From: wbailey at gci.com (Warren Bailey) Date: Thu, 30 Jul 2009 04:14:12 -0800 Subject: sat-3 cut? References: Message-ID: <5B3743FC2D0D8B41B27EE4F5EACA79D107CCDBCB@DTN1EX01.gci.com> In other news, Nigerian Scams at an all time low this morning/afternoon. ;) ________________________________ From: Randy Bush [mailto:randy at psg.com] Sent: Thu 7/30/2009 4:10 AM To: North American Network Operators Group; AfNOG Subject: sat-3 cut? http://news.bbc.co.uk/2/hi/technology/8176014.stm From Rod.Beck at hiberniaatlantic.com Thu Jul 30 07:14:15 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Thu, 30 Jul 2009 13:14:15 +0100 Subject: sat-3 cut? References: Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB01628480@bert.HiberniaAtlantic.local> I wonder how long it will take to get a ship there ... Regards, Roderick S. Beck Director of European Sales Hibernia Atlantic -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Thu 7/30/2009 1:10 PM To: North American Network Operators Group; AfNOG Subject: sat-3 cut? http://news.bbc.co.uk/2/hi/technology/8176014.stm From wbailey at gci.com Thu Jul 30 07:20:16 2009 From: wbailey at gci.com (Warren Bailey) Date: Thu, 30 Jul 2009 04:20:16 -0800 Subject: sat-3 cut? Message-ID: <5B3743FC2D0D8B41B27EE4F5EACA79D108970FFB@DTN1EX01.gci.com> Article said 2 weeks. ----- Original Message ----- From: Rod Beck To: Randy Bush ; North American Network Operators Group ; AfNOG Sent: Thu Jul 30 04:14:15 2009 Subject: RE: sat-3 cut? I wonder how long it will take to get a ship there ... Regards, Roderick S. Beck Director of European Sales Hibernia Atlantic -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Thu 7/30/2009 1:10 PM To: North American Network Operators Group; AfNOG Subject: sat-3 cut? http://news.bbc.co.uk/2/hi/technology/8176014.stm From sthaug at nethelp.no Thu Jul 30 08:47:44 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 30 Jul 2009 15:47:44 +0200 (CEST) Subject: sat-3 cut? In-Reply-To: <5B3743FC2D0D8B41B27EE4F5EACA79D107CCDBCB@DTN1EX01.gci.com> References: <5B3743FC2D0D8B41B27EE4F5EACA79D107CCDBCB@DTN1EX01.gci.com> Message-ID: <20090730.154744.74737128.sthaug@nethelp.no> > In other news, Nigerian Scams at an all time low this morning/afternoon. Unfortunately a lot of the Nigerian scams run out of Dutch coffee shops/internet cafes and thus won't be affected. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From jmamodio at gmail.com Thu Jul 30 08:48:16 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 30 Jul 2009 08:48:16 -0500 Subject: sat-3 cut? In-Reply-To: <5B3743FC2D0D8B41B27EE4F5EACA79D107CCDBCB@DTN1EX01.gci.com> References: <5B3743FC2D0D8B41B27EE4F5EACA79D107CCDBCB@DTN1EX01.gci.com> Message-ID: <202705b0907300648g2a887ea4m36e13d35206a797b@mail.gmail.com> On Thu, Jul 30, 2009 at 7:14 AM, Warren Bailey wrote: > In other news, Nigerian Scams at an all time low this morning/afternoon. Since some time ago I've been getting them through .cn sites and new variants like "I won the $500K Toyota Bingo" ?? ... can't believe that still some people fall for the scam. Cheers Jorge From dwhite at olp.net Thu Jul 30 09:33:34 2009 From: dwhite at olp.net (Dan White) Date: Thu, 30 Jul 2009 09:33:34 -0500 Subject: sat-3 cut? In-Reply-To: <202705b0907300648g2a887ea4m36e13d35206a797b@mail.gmail.com> References: <5B3743FC2D0D8B41B27EE4F5EACA79D107CCDBCB@DTN1EX01.gci.com> <202705b0907300648g2a887ea4m36e13d35206a797b@mail.gmail.com> Message-ID: <4A71AF3E.6070508@olp.net> Jorge Amodio wrote: > On Thu, Jul 30, 2009 at 7:14 AM, Warren Bailey wrote: > >> In other news, Nigerian Scams at an all time low this morning/afternoon. >> > > Since some time ago I've been getting them through .cn sites and new variants > like "I won the $500K Toyota Bingo" ?? ... can't believe that still some people > fall for the scam. > > Cheers > Jorge > > According to some quick fuzzy math(*), there will be 410,121 new suckers joining the net today. [*] http://www.internetworldstats.com/stats.htm From Valdis.Kletnieks at vt.edu Thu Jul 30 12:09:37 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 30 Jul 2009 13:09:37 -0400 Subject: Fwd: Dan Kaminsky In-Reply-To: Your message of "Wed, 29 Jul 2009 22:53:39 BST." <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> References: <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> Message-ID: <21537.1248973777@turing-police.cc.vt.edu> On Wed, 29 Jul 2009 22:53:39 BST, "andrew.wallace" said: > The hackers criticized Mitnick and Kaminsky for using insecure > blogging and hosting services to publish their sites, that allowed the > hackers to gain easy access to their data. *yawn*. kiddies whack low-value sites, death of Internet predicted. Film at 11. What Mitnick and Kaminsky realize, and most NANOGers hopefully do too, is that security comes with costs, and a cost-benefit analysis is in order. Mitnick came out and *said* that he knew the site was insecure, but since no sensitive data was on there, it didn't matter. Presumably the site's monthly cost, convenience, user-interface, and so on, outweigh the effort of occasionally having to recover after some idiot whizzes all over the site. Now, if they had managed to whack a site that Mitnick and Kaminsky *cared* about, it would be a different story... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From merlyn at geeks.org Thu Jul 30 15:22:24 2009 From: merlyn at geeks.org (Doug McIntyre) Date: Thu, 30 Jul 2009 15:22:24 -0500 Subject: Subnet Size for BGP peers. In-Reply-To: References: <15a18b860907291259n304fe598x763b650a6f0dc44a@mail.gmail.com> Message-ID: <20090730202224.GA54330@geeks.org> On Thu, Jul 30, 2009 at 12:22:27AM -0400, Barton F Bruce wrote: > So what is wrong with a /31? We use /30s but if you are short on IP space, > look at using /31 rather than /30 links. Cuts your space usage in half. /31's are only defined for point-to-point links. Ethernet isn't considered PtP in general.. Many devices won't accept a /31 on anything but a PtP WAN media type link. (or not at all). From r.engehausen at gmail.com Thu Jul 30 16:01:36 2009 From: r.engehausen at gmail.com (Roy) Date: Thu, 30 Jul 2009 14:01:36 -0700 Subject: Subnet Size for BGP peers. In-Reply-To: <20090730202224.GA54330@geeks.org> References: <15a18b860907291259n304fe598x763b650a6f0dc44a@mail.gmail.com> <20090730202224.GA54330@geeks.org> Message-ID: <4A720A30.4080700@gmail.com> Doug McIntyre wrote: > On Thu, Jul 30, 2009 at 12:22:27AM -0400, Barton F Bruce wrote: > >> So what is wrong with a /31? We use /30s but if you are short on IP space, >> look at using /31 rather than /30 links. Cuts your space usage in half. >> > > /31's are only defined for point-to-point links. > > Ethernet isn't considered PtP in general.. > > Many devices won't accept a /31 on anything but a PtP WAN media type link. > (or not at all). > > Since it isn't PtP, one also has to allow the customer to connect multiple devices. From mpetach at netflight.com Thu Jul 30 16:50:01 2009 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 30 Jul 2009 14:50:01 -0700 Subject: Ahoy, SLA boffins! In-Reply-To: <3c3e3fca0907291338j497ccd8cod45687b2b141d692@mail.gmail.com> References: <8070E7E5-07BF-424E-9A2F-FC736BA26E66@pch.net> <3c3e3fca0907291225y6bf98884o9679824eadf73e4@mail.gmail.com> <4A70AEDD.5030206@gmail.com> <3c3e3fca0907291338j497ccd8cod45687b2b141d692@mail.gmail.com> Message-ID: <63ac96a50907301450p1a67ee12r9daa1c2d81613041@mail.gmail.com> On 7/29/09, William Herrin wrote: > Perhaps you miss my point: what the ISP is offering to pay me as a > result of a failure to deliver adequate service is so much less than > my loss for the same as to render the payment meaningless. I'm gonna > terminate the contract for nonperformance and hire someone who can get > the job done long before its worth my time to chase you for an > SLA-based service credit. And we both know it. The only way I ever > chase you for an SLA credit is I'm playing the blame game instead of > doing my job for my customers. Actually, SLA credits are useful in cases where it's not the only path between two sites; if, for example, you have 12 OC192 links running across the US, but your peak traffic on them doesn't exceed 80Gb combined, having an OC192 down for a day or two won't really hurt you; there's no reason to cancel the circuit, the rest of your links are carrying the traffic just fine, but since one of the links failed to meet its SLA, you might as well push the vendor to give you the SLA credit back; it saves you some money, you have no lost customers, you have no other impact to your business. It's not about playing the "blame game", it's about giving the vendor an incentive to try to run their system a bit more reliably. Now, for single-homed customers depending on that one link, I agree, an SLA is largely meaningless compared to the impact of being down. But there's many cases where the SLA is meaningful, and collecting SLA credits is worth it, without there being a corresponding massive loss in revenue associated with the outage. Matt From william.allen.simpson at gmail.com Thu Jul 30 17:25:59 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Thu, 30 Jul 2009 18:25:59 -0400 Subject: sat-3 cut? In-Reply-To: References: Message-ID: <4A721DF7.1070101@gmail.com> Randy Bush wrote: > better lay coverage in al jazeera > > http://english.aljazeera.net/news/africa/2009/07/2009730775992910.html > Thanks, Randy. Making this more on-topic, the map show many hops down. How can a single cut affect more than 1 hop, those on either side of the cut? Surely, for a major investment like this, both ends have peers with others? From dr at kyx.net Thu Jul 30 17:48:18 2009 From: dr at kyx.net (Dragos Ruiu) Date: Thu, 30 Jul 2009 15:48:18 -0700 Subject: Dan Kaminsky In-Reply-To: References: <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> <4A711E00.7030602@trelane.net> Message-ID: <7C332C86-7E7C-4C4E-8ADD-61310CA0758C@kyx.net> On 29-Jul-09, at 9:23 PM, Randy Bush wrote: >>>> LAS VEGAS ? Two noted security professionals were targeted this >>>> week >>>> by hackers who broke into their web pages, stole personal data and >>>> posted it online on the eve of the Black Hat security conference. >>> boooooring. >> Two noted security professionals, and Kevin Mitnick, whom no one >> gives a >> damn about, were targeted... > > Ettore Bugatti, maker of the finest cars of his day, was once asked > why > his cars had less than perfect brakes. He replied something like, > "Any > fool can make a car stop. It takes a genius to make a car go." > > so i am not particularly impressed by news of children making a car > stop. at the risk of adding to the metadiscussion. what does any of this have to do with nanog? (sorry I'm kinda irritable about character slander being spammed out unnecessarily to unrelated public lists lately ;-P ) From ras at e-gerbil.net Thu Jul 30 18:16:40 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Thu, 30 Jul 2009 18:16:40 -0500 Subject: Dan Kaminsky In-Reply-To: <7C332C86-7E7C-4C4E-8ADD-61310CA0758C@kyx.net> References: <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> <4A711E00.7030602@trelane.net> <7C332C86-7E7C-4C4E-8ADD-61310CA0758C@kyx.net> Message-ID: <20090730231640.GC51443@gerbil.cluepon.net> On Thu, Jul 30, 2009 at 03:48:18PM -0700, Dragos Ruiu wrote: > > On 29-Jul-09, at 9:23 PM, Randy Bush wrote: > > >Ettore Bugatti, maker of the finest cars of his day, was once asked > >why > >his cars had less than perfect brakes. He replied something like, > >"Any > >fool can make a car stop. It takes a genius to make a car go." > > > >so i am not particularly impressed by news of children making a car > >stop. > > at the risk of adding to the metadiscussion. what does any of this > have to do with nanog? > (sorry I'm kinda irritable about character slander being spammed out > unnecessarily to unrelated public lists lately ;-P ) At the risk of adding to the metadiscussion, I've never seen anyone die from having a car that accelerated too slowly. Unfortunately I think encouraging Randy to drive cars with bad brakes would be against the NANOG charter. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From william.allen.simpson at gmail.com Thu Jul 30 18:42:50 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Thu, 30 Jul 2009 19:42:50 -0400 Subject: Fwd: Dan Kaminsky In-Reply-To: <21537.1248973777@turing-police.cc.vt.edu> References: <4b6ee9310907291453y6da24d19l21cc5345bd8f08a2@mail.gmail.com> <21537.1248973777@turing-police.cc.vt.edu> Message-ID: <4A722FFA.9080905@gmail.com> Valdis.Kletnieks at vt.edu wrote: > ... Mitnick came out and *said* that he knew the site was insecure, but > since no sensitive data was on there, it didn't matter. Presumably the > site's monthly cost, convenience, user-interface, and so on, outweigh the > effort of occasionally having to recover after some idiot whizzes all over > the site. > > Now, if they had managed to whack a site that Mitnick and Kaminsky *cared* > about, it would be a different story... > Remembering those ancient days, it always seemed to me that was Mitnick's usual series of excuses (as in: he was a scapegoat, nobody was physically hurt, their cleanup cost estimates were inflated, et cetera ad nauseum). This just seems like more of the same. I'm not a big fan of throw them in prison and throw away the key, but the fact that his prison sentences (plural) and restitution were so lenient is certainly a factor in the difficulty of convincing LE to take investigation and prosecution seriously. Security consultants that don't practice secure computing on their own sites aren't much more than flacks for hire. http://antilimit.net/zf05.txt Anyway, most of the reading was pretty boring and badly formatted, but it still put a bit of a knot in my intestines.... Are we paying enough attention to securing our systems? From carlos at race.com Thu Jul 30 21:57:11 2009 From: carlos at race.com (Carlos Alcantar) Date: Thu, 30 Jul 2009 19:57:11 -0700 Subject: OT: Voice Operators' Group forming Message-ID: <859604546CD1FF488BDB6EA94C896AFB8AB8B1@racexchange.race.local> How's the startup of the list looking? -----Original Message----- From: Chris Meidinger [mailto:cmeidinger at sendmail.com] Sent: Wednesday, July 29, 2009 2:42 PM To: Jason LeBlanc Cc: nanog at nanog.org Subject: Re: OT: Voice Operators' Group forming On 29.07.2009, at 22:52, Jason LeBlanc wrote: > Brandon Butterworth wrote: >>> NAVOG works for me. >>> >> >> I'd prefer Voice Operators' Group Online Network >> >> brandon >> >> > *claps* Imagine the poetry you have to listen to when _those_ guys put you on hold... From scott at sberkman.net Fri Jul 31 09:28:25 2009 From: scott at sberkman.net (Scott Berkman) Date: Fri, 31 Jul 2009 10:28:25 -0400 Subject: OT: Voice Operators' Group forming In-Reply-To: <859604546CD1FF488BDB6EA94C896AFB8AB8B1@racexchange.race.local> References: <859604546CD1FF488BDB6EA94C896AFB8AB8B1@racexchange.race.local> Message-ID: <007401ca11eb$334be8c0$99e3ba40$@net> We're almost there, expect a list posting here in the next couple of days with the details. -Scott -----Original Message----- From: Carlos Alcantar [mailto:carlos at race.com] Sent: Thursday, July 30, 2009 10:57 PM To: nanog at nanog.org Subject: RE: OT: Voice Operators' Group forming How's the startup of the list looking? -----Original Message----- From: Chris Meidinger [mailto:cmeidinger at sendmail.com] Sent: Wednesday, July 29, 2009 2:42 PM To: Jason LeBlanc Cc: nanog at nanog.org Subject: Re: OT: Voice Operators' Group forming On 29.07.2009, at 22:52, Jason LeBlanc wrote: > Brandon Butterworth wrote: >>> NAVOG works for me. >>> >> >> I'd prefer Voice Operators' Group Online Network >> >> brandon >> >> > *claps* Imagine the poetry you have to listen to when _those_ guys put you on hold... From andyzweb at gmail.com Fri Jul 31 10:32:34 2009 From: andyzweb at gmail.com (Andrew Euell) Date: Fri, 31 Jul 2009 11:32:34 -0400 Subject: Happy Sysadmin Day Message-ID: Happy Sysadmin Day nanog'ers. Thank you for keeping the internet running! http://www.sysadminday.com/ -- Andrew Euell andyzweb [at] gmail [dot] com From sil at infiltrated.net Fri Jul 31 10:35:42 2009 From: sil at infiltrated.net (J. Oquendo) Date: Fri, 31 Jul 2009 11:35:42 -0400 Subject: Happy Sysadmin Day In-Reply-To: References: Message-ID: <4A730F4E.3010701@infiltrated.net> Andrew Euell wrote: > Happy Sysadmin Day nanog'ers. Thank you for keeping the internet running! > http://www.sysadminday.com/ > > Keeping the Internet running? You mean as in the flakiness of what is happening with portions of Level3 right at this moment? -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From andyzweb at gmail.com Fri Jul 31 10:40:05 2009 From: andyzweb at gmail.com (Andrew Euell) Date: Fri, 31 Jul 2009 11:40:05 -0400 Subject: Happy Sysadmin Day In-Reply-To: <4A730F4E.3010701@infiltrated.net> References: <4A730F4E.3010701@infiltrated.net> Message-ID: at least their performance is reflected in their stock price http://www.google.com/finance?client=ob&q=NASDAQ:LVLT On Fri, Jul 31, 2009 at 11:35 AM, J. Oquendo wrote: > Andrew Euell wrote: > > Happy Sysadmin Day nanog'ers. Thank you for keeping the internet running! > > http://www.sysadminday.com/ > > > > > Keeping the Internet running? You mean as in the flakiness of what is > happening with portions of Level3 right at this moment? > > > -- > > =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > J. Oquendo > SGFA, SGFE, C|EH, CNDA, CHFI, OSCP > > "It takes 20 years to build a reputation and five minutes to > ruin it. If you think about that, you'll do things > differently." - Warren Buffett > > 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E > > -- Andrew Euell andyzweb [at] gmail [dot] com From andyring at inebraska.com Fri Jul 31 10:53:01 2009 From: andyring at inebraska.com (Andy Ringsmuth) Date: Fri, 31 Jul 2009 10:53:01 -0500 Subject: Happy Sysadmin Day In-Reply-To: <4A730F4E.3010701@infiltrated.net> References: <4A730F4E.3010701@infiltrated.net> Message-ID: <3CAF442A-3184-4DD1-AAB7-5BC0A268F2D4@inebraska.com> On Jul 31, 2009, at 10:35 AM, J. Oquendo wrote: > Andrew Euell wrote: >> Happy Sysadmin Day nanog'ers. Thank you for keeping the internet >> running! >> http://www.sysadminday.com/ >> >> > Keeping the Internet running? You mean as in the flakiness of what is > happening with portions of Level3 right at this moment? Yeah, anyone know what's going on with Level3? Whatever the heck it is, it's causing lots of weirdness for me. -Andy From patrick at ianai.net Fri Jul 31 10:58:40 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 31 Jul 2009 11:58:40 -0400 Subject: Happy Sysadmin Day In-Reply-To: <3CAF442A-3184-4DD1-AAB7-5BC0A268F2D4@inebraska.com> References: <4A730F4E.3010701@infiltrated.net> <3CAF442A-3184-4DD1-AAB7-5BC0A268F2D4@inebraska.com> Message-ID: On Jul 31, 2009, at 11:53 AM, Andy Ringsmuth wrote: > On Jul 31, 2009, at 10:35 AM, J. Oquendo wrote: > Andrew Euell wrote: >>> Happy Sysadmin Day nanog'ers. Thank you for keeping the internet >>> running! >>> http://www.sysadminday.com/ >>> >>> >> Keeping the Internet running? You mean as in the flakiness of what is >> happening with portions of Level3 right at this moment? > > Yeah, anyone know what's going on with Level3? Whatever the heck it > is, it's causing lots of weirdness for me. I'm not on the MLC, but this strikes me as silly. First, isn't outages@ that -> a -> way -> ?? Also, do people honestly think asking "why is L3 having issues" in an e-mail "Subject: Re: Happy Sysadmin Day" a good idea? Perhaps you all need to realize that Ettore was an idiot - making good brakes is _hard_... er, sorry. :) -- TTFN, patrick From nanog-amuse at foofus.com Fri Jul 31 11:02:30 2009 From: nanog-amuse at foofus.com (AMuse) Date: Fri, 31 Jul 2009 09:02:30 -0700 Subject: Happy Sysadmin Day In-Reply-To: References: <4A730F4E.3010701@infiltrated.net> <3CAF442A-3184-4DD1-AAB7-5BC0A268F2D4@inebraska.com> Message-ID: <4A731596.5020906@foofus.com> Patrick: If you're surprised that someone is conflating 'Happy sysadmin day!" with "Hey by the way can you help me figure this out?" then you haven't been a sysadmin long enough! ;) (yes, I know, you weren't surprised, just taking a lighthearted shot at the guy) Patrick W. Gilmore wrote: > > I'm not on the MLC, but this strikes me as silly. > > First, isn't outages@ that -> a -> way -> ?? > > Also, do people honestly think asking "why is L3 having issues" in an > e-mail "Subject: Re: Happy Sysadmin Day" a good idea? > > Perhaps you all need to realize that Ettore was an idiot - making good > brakes is _hard_... er, sorry. :) > From cscora at apnic.net Fri Jul 31 13:12:55 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 1 Aug 2009 04:12:55 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200907311812.n6VICtpS019420@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 01 Aug, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 292961 Prefixes after maximum aggregation: 138493 Deaggregation factor: 2.12 Unique aggregates announced to Internet: 145391 Total ASes present in the Internet Routing Table: 31852 Prefixes per ASN: 9.20 Origin-only ASes present in the Internet Routing Table: 27681 Origin ASes announcing only one prefix: 13518 Transit ASes present in the Internet Routing Table: 4171 Transit-only ASes present in the Internet Routing Table: 105 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 456 Unregistered ASNs in the Routing Table: 130 Number of 32-bit ASNs allocated by the RIRs: 220 Prefixes from 32-bit ASNs in the Routing Table: 81 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 340 Number of addresses announced to Internet: 2082757696 Equivalent to 124 /8s, 36 /16s and 92 /24s Percentage of available address space announced: 56.2 Percentage of allocated address space announced: 65.0 Percentage of available address space allocated: 86.4 Percentage of address space in use by end-sites: 78.5 Total number of prefixes smaller than registry allocations: 140414 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 70058 Total APNIC prefixes after maximum aggregation: 24829 APNIC Deaggregation factor: 2.82 Prefixes being announced from the APNIC address blocks: 69476 Unique aggregates announced from the APNIC address blocks: 31605 APNIC Region origin ASes present in the Internet Routing Table: 3717 APNIC Prefixes per ASN: 18.69 APNIC Region origin ASes announcing only one prefix: 1012 APNIC Region transit ASes present in the Internet Routing Table: 579 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 475903680 Equivalent to 28 /8s, 93 /16s and 182 /24s Percentage of available APNIC address space announced: 88.6 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 180/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 124431 Total ARIN prefixes after maximum aggregation: 66173 ARIN Deaggregation factor: 1.88 Prefixes being announced from the ARIN address blocks: 125090 Unique aggregates announced from the ARIN address blocks: 52293 ARIN Region origin ASes present in the Internet Routing Table: 13139 ARIN Prefixes per ASN: 9.52 ARIN Region origin ASes announcing only one prefix: 5077 ARIN Region transit ASes present in the Internet Routing Table: 1287 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 1012769216 Equivalent to 60 /8s, 93 /16s and 161 /24s Percentage of available ARIN address space announced: 88.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 67087 Total RIPE prefixes after maximum aggregation: 39643 RIPE Deaggregation factor: 1.69 Prefixes being announced from the RIPE address blocks: 66684 Unique aggregates announced from the RIPE address blocks: 44964 RIPE Region origin ASes present in the Internet Routing Table: 13340 RIPE Prefixes per ASN: 5.00 RIPE Region origin ASes announcing only one prefix: 6980 RIPE Region transit ASes present in the Internet Routing Table: 1995 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 498967744 Equivalent to 29 /8s, 189 /16s and 164 /24s Percentage of available RIPE address space announced: 99.1 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223 RIPE Address Blocks 25/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 24832 Total LACNIC prefixes after maximum aggregation: 6078 LACNIC Deaggregation factor: 4.09 Prefixes being announced from the LACNIC address blocks: 24789 Unique aggregates announced from the LACNIC address blocks: 13736 LACNIC Region origin ASes present in the Internet Routing Table: 1147 LACNIC Prefixes per ASN: 21.61 LACNIC Region origin ASes announcing only one prefix: 367 LACNIC Region transit ASes present in the Internet Routing Table: 192 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 23 Number of LACNIC addresses announced to Internet: 72874176 Equivalent to 4 /8s, 87 /16s and 248 /24s Percentage of available LACNIC address space announced: 72.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 6163 Total AfriNIC prefixes after maximum aggregation: 1482 AfriNIC Deaggregation factor: 4.16 Prefixes being announced from the AfriNIC address blocks: 6569 Unique aggregates announced from the AfriNIC address blocks: 2514 AfriNIC Region origin ASes present in the Internet Routing Table: 299 AfriNIC Prefixes per ASN: 21.97 AfriNIC Region origin ASes announcing only one prefix: 82 AfriNIC Region transit ASes present in the Internet Routing Table: 61 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 16 Number of AfriNIC addresses announced to Internet: 20273152 Equivalent to 1 /8s, 53 /16s and 88 /24s Percentage of available AfriNIC address space announced: 60.4 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1714 6976 419 Korea Telecom (KIX) 17488 1543 137 103 Hathway IP Over Cable Interne 4755 1227 292 145 TATA Communications formerly 9583 1114 87 548 Sify Limited 4134 980 17389 381 CHINANET-BACKBONE 7545 807 198 101 TPG Internet Pty Ltd 9829 807 619 15 BSNL National Internet Backbo 23577 785 34 666 Korea Telecom (ATM-MPLS) 4808 754 1515 172 CNCGROUP IP network: China169 18101 750 201 32 Reliance Infocom Ltd Internet Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4224 3643 323 bellsouth.net, inc. 4323 1912 1048 386 Time Warner Telecom 1785 1719 714 138 PaeTec Communications, Inc. 7018 1511 5907 1047 AT&T WorldNet Services 20115 1428 1464 679 Charter Communications 2386 1265 669 921 AT&T Data Communications Serv 6478 1249 274 302 AT&T Worldnet Services 3356 1201 10963 443 Level 3 Communications, LLC 11492 1129 208 12 Cable One 22773 1079 2604 66 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 30890 483 92 195 Evolva Telecom 12479 470 578 6 Uni2 Autonomous System 3292 460 1905 395 TDC Tele Danmark 702 430 1861 346 UUNET - Commercial IP service 9198 367 138 12 Kazakhtelecom Data Network Ad 3320 353 7083 306 Deutsche Telekom AG 3301 347 1684 310 TeliaNet Sweden 3215 344 3081 109 France Telecom Transpac 8866 335 109 20 Bulgarian Telecommunication C 8551 310 290 38 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1504 2898 245 UniNet S.A. de C.V. 10620 964 220 107 TVCABLE BOGOTA 28573 637 579 41 NET Servicos de Comunicao S.A 7303 601 320 94 Telecom Argentina Stet-France 22047 539 302 14 VTR PUNTO NET S.A. 11830 489 310 54 Instituto Costarricense de El 11172 443 99 69 Servicios Alestra S.A de C.V 6471 421 96 31 ENTEL CHILE S.A. 7738 410 858 29 Telecomunicacoes da Bahia S.A 3816 386 189 80 Empresa Nacional de Telecomun Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1025 188 7 TEDATA 24863 908 90 48 LINKdotNET AS number 20858 324 34 5 EgyNet 3741 277 856 237 The Internet Solution 2018 245 215 143 Tertiary Education Network 6713 176 166 16 Itissalat Al-MAGHRIB 33783 152 10 8 EEPAD TISP TELECOM & INTERNET 24835 138 46 9 RAYA Telecom - Egypt 29571 138 14 6 Ci Telecom Autonomous system 5536 123 8 9 Internet Egypt Network Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4224 3643 323 bellsouth.net, inc. 4323 1912 1048 386 Time Warner Telecom 1785 1719 714 138 PaeTec Communications, Inc. 4766 1714 6976 419 Korea Telecom (KIX) 17488 1543 137 103 Hathway IP Over Cable Interne 7018 1511 5907 1047 AT&T WorldNet Services 8151 1504 2898 245 UniNet S.A. de C.V. 20115 1428 1464 679 Charter Communications 2386 1265 669 921 AT&T Data Communications Serv 6478 1249 274 302 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 1785 1719 1581 PaeTec Communications, Inc. 4323 1912 1526 Time Warner Telecom 17488 1543 1440 Hathway IP Over Cable Interne 4766 1714 1295 Korea Telecom (KIX) 8151 1504 1259 UniNet S.A. de C.V. 11492 1129 1117 Cable One 4755 1227 1082 TATA Communications formerly 18566 1062 1052 Covad Communications 8452 1025 1018 TEDATA 22773 1079 1013 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.112.0/22 5713 Telkom SA Ltd 41.223.176.0/22 36981 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.251.0/24 22555 Universal Talkware Corporatio 64.31.32.0/19 11955 ServiceCo LLC - Road Runner Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:24 /11:58 /12:169 /13:350 /14:619 /15:1171 /16:10574 /17:4763 /18:8324 /19:17206 /20:20600 /21:20446 /22:26358 /23:26224 /24:153360 /25:904 /26:1027 /27:574 /28:157 /29:8 /30:7 /31:1 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2740 4224 bellsouth.net, inc. 4766 1400 1714 Korea Telecom (KIX) 17488 1290 1543 Hathway IP Over Cable Interne 1785 1189 1719 PaeTec Communications, Inc. 11492 1055 1129 Cable One 18566 1043 1062 Covad Communications 4323 967 1912 Time Warner Telecom 9583 967 1114 Sify Limited 8452 947 1025 TEDATA 10620 872 964 TVCABLE BOGOTA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:14 8:210 12:2134 13:7 15:19 16:3 17:5 20:35 24:1111 32:52 34:2 38:583 40:98 41:1721 43:1 44:2 47:22 52:6 53:2 55:2 56:2 57:24 58:597 59:649 60:462 61:1081 62:1111 63:2004 64:3704 65:2407 66:3583 67:1680 68:860 69:2731 70:550 71:152 72:1652 73:2 74:1644 75:175 76:340 77:849 78:586 79:355 80:955 81:852 82:591 83:453 84:634 85:1063 86:372 87:670 88:373 89:1479 90:50 91:2425 92:384 93:1090 94:1107 95:1194 96:157 97:240 98:256 99:28 110:168 111:365 112:117 113:147 114:241 115:350 116:1119 117:555 118:338 119:757 120:147 121:782 122:1056 123:685 124:980 125:1377 128:225 129:222 130:128 131:414 132:74 133:10 134:186 135:43 136:224 137:165 138:167 139:82 140:446 141:123 142:384 143:377 144:361 145:48 146:390 147:152 148:529 149:221 150:206 151:193 152:145 153:148 154:2 155:275 156:167 157:301 158:118 159:343 160:289 161:156 162:272 163:165 164:474 165:515 166:466 167:361 168:709 169:176 170:481 171:41 172:10 173:324 174:269 178:1 180:4 186:109 187:145 188:350 189:573 190:2941 192:5790 193:4259 194:3298 195:2692 196:1127 198:3641 199:3363 200:5133 201:1285 202:7740 203:8287 204:3892 205:2135 206:2443 207:2737 208:3893 209:3449 210:2534 211:1106 212:1662 213:1618 214:80 215:29 216:4550 217:1365 218:405 219:450 220:1104 221:479 222:328 End of report From David_Hiers at adp.com Fri Jul 31 14:42:54 2009 From: David_Hiers at adp.com (Hiers, David) Date: Fri, 31 Jul 2009 14:42:54 -0500 Subject: Voice Operators' Group: voiceops.org Message-ID: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> Hi Everyone, I'm pleased to announce that the Voice Operators' Group has found an excellent home. Our web site, www.voiceops.org has a good home (thanks Scott!), while Jared, Daniel, and all the great folks over at nether.net are hosting our list server. If VoiceOps can do for voice anything close to what NANOG has done for IP, we'll all owe much to the people that are making this happen. email: voiceops-subscribe at voiceops.org web: https://puck.nether.net/mailman/listinfo/voiceops Thanks, David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. From up at 3.am Fri Jul 31 16:25:23 2009 From: up at 3.am (up at 3.am) Date: Fri, 31 Jul 2009 17:25:23 -0400 (EDT) Subject: Data Center QoS equipment breaking http 1.1? Message-ID: Sorry if this is a little OT, but we're seeing a serious problem and was wondering if it is what I think it is. In short: I have been moving services off of our servers in a data center onto a server at eSecuredata, who rents dedicated servers. The idea is to lower costs and eliminate having to deal with hardware. The advertise "unmetered bandwidth", but mention QoS measure to control "bandwidth hogs". One of my customers, whose site I just moved from a unique IP virtual host on my old server onto an Apache NameVirtualHost on the new one, worked fine at first. Then today, they started complaining about getting one of our home pages. I figured DNS or web caching issues, until I started seeing it for myself. It was no caching issue, it was NameVirtualHost breaking. I poured over my configs (I've done this config countless times), and saw this in the apache docs: http://httpd.apache.org/docs/2.2/vhosts/name-based.html " Some operating systems and network equipment implement bandwidth management techniques that cannot differentiate between hosts unless they are on separate IP addresses." So, I installed lynx on the server, and sure enough, it worked perfectly fine there, just not from anywhere outside eSecuredata's network that I could see. Can anyone shed any light on this particular practice, of this company in particular? thanks James Smallacombe PlantageNet, Inc. CEO and Janitor up at 3.am http://3.am ========================================================================= From cidr-report at potaroo.net Fri Jul 31 17:00:02 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 31 Jul 2009 22:00:02 GMT Subject: BGP Update Report Message-ID: <200907312200.n6VM02ed043609@wattle.apnic.net> BGP Update Report Interval: 23-Jul-09 -to- 30-Jul-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9198 96435 8.3% 291.3 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - AS8452 24062 2.1% 31.4 -- TEDATA TEDATA 3 - AS22783 18285 1.6% 3047.5 -- WEBPOWER - WebPower, Inc. 4 - AS47408 14767 1.3% 703.2 -- MANDARIN-AS Mandarin WIMAX Sicilia SpA 5 - AS1659 12463 1.1% 132.6 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center 6 - AS35805 10796 0.9% 32.8 -- UTG-AS United Telecom AS 7 - AS21491 9693 0.8% 807.8 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 8 - AS15491 7947 0.7% 111.9 -- WANEX-AS Wanex ltd. 9 - AS7011 7718 0.7% 35.1 -- FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. 10 - AS14571 7714 0.7% 68.9 -- Internet Group do Brasil 11 - AS44083 6712 0.6% 30.8 -- STROIBAT-AS SC Stroibat Prod SRL 12 - AS8151 6657 0.6% 6.1 -- Uninet S.A. de C.V. 13 - AS5668 6631 0.6% 8.1 -- AS-5668 - CenturyTel Internet Holdings, Inc. 14 - AS17488 6586 0.6% 5.3 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 15 - AS33783 6570 0.6% 41.1 -- EEPAD 16 - AS8485 6530 0.6% 1088.3 -- SAMSC-AS SamSC RAS 17 - AS11 6453 0.6% 430.2 -- HARVARD - Harvard University 18 - AS7738 5922 0.5% 15.8 -- Telecomunicacoes da Bahia S.A. 19 - AS5050 5918 0.5% 1183.6 -- PSC-EXT - Pittsburgh Supercomputing Center 20 - AS12479 5845 0.5% 27.2 -- UNI2-AS Uni2 Autonomous System TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS22783 18285 1.6% 3047.5 -- WEBPOWER - WebPower, Inc. 2 - AS47640 1401 0.1% 1401.0 -- TRICOMPAS Tricomp Sp. z. o. o. 3 - AS38548 3938 0.3% 1312.7 -- INFRATEL-AS-ID-AP Network Access Point 4 - AS5050 5918 0.5% 1183.6 -- PSC-EXT - Pittsburgh Supercomputing Center 5 - AS25546 3443 0.3% 1147.7 -- BROOKLANDCOMP-AS Brookland Computer Services 6 - AS40060 2274 0.2% 1137.0 -- AAAWI - AAA Wireless, Inc. 7 - AS8485 6530 0.6% 1088.3 -- SAMSC-AS SamSC RAS 8 - AS46847 4210 0.4% 842.0 -- ENGINEYARD-1 - Engine Yard, Inc. 9 - AS21491 9693 0.8% 807.8 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 10 - AS6671 798 0.1% 798.0 -- SAMARA-IP NETWORK FOR RESEARCH, 11 - AS35400 1476 0.1% 738.0 -- MFIST Interregoinal Organization Network Technologies 12 - AS4628 1445 0.1% 722.5 -- ASN-PACIFIC-INTERNET-IX Pacific Internet Ltd 13 - AS47408 14767 1.3% 703.2 -- MANDARIN-AS Mandarin WIMAX Sicilia SpA 14 - AS18829 657 0.1% 657.0 -- GALAXY-CONTROL-SYSTEMS - Galaxy Control Systems 15 - AS7270 468 0.0% 468.0 -- NET2PHONE - Net2Phone Corp. 16 - AS11032 460 0.0% 460.0 -- UQ - Universite du Quebec a Quebec 17 - AS11 6453 0.6% 430.2 -- HARVARD - Harvard University 18 - AS35103 364 0.0% 364.0 -- ILLUSTRA-AS AS Illustra 19 - AS29850 361 0.0% 361.0 -- MHN-AS - Memorial Healthcare 20 - AS43026 359 0.0% 359.0 -- IMPOL-AS Impol Sp. z o.o. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 92.46.244.0/23 10507 0.8% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - 89.218.218.0/23 10486 0.8% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 3 - 89.218.220.0/23 10484 0.8% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 4 - 95.59.8.0/23 10473 0.8% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 5 - 95.59.4.0/22 10472 0.8% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 6 - 95.59.3.0/24 10471 0.8% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 7 - 95.59.2.0/23 10469 0.8% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 8 - 88.204.221.0/24 10336 0.8% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 9 - 95.59.1.0/24 10304 0.8% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 10 - 41.233.94.0/23 8496 0.7% AS8452 -- TEDATA TEDATA 11 - 41.233.92.0/23 8387 0.7% AS8452 -- TEDATA TEDATA 12 - 63.163.66.0/24 6803 0.5% AS22783 -- WEBPOWER - WebPower, Inc. 13 - 205.246.203.0/24 6801 0.5% AS22783 -- WEBPOWER - WebPower, Inc. 14 - 72.23.246.0/24 5874 0.5% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 15 - 65.212.89.0/24 4641 0.4% AS22783 -- WEBPOWER - WebPower, Inc. 16 - 203.190.47.0/24 3943 0.3% AS17670 -- INFOKOM-AS PT. Infokom Elektrindo AS38548 -- INFRATEL-AS-ID-AP Network Access Point 17 - 193.201.184.0/21 3434 0.3% AS25546 -- BROOKLANDCOMP-AS Brookland Computer Services 18 - 192.12.120.0/24 2670 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 19 - 200.78.218.32/27 2325 0.2% AS6503 -- Avantel, S.A. 20 - 85.60.208.0/21 2324 0.2% AS12479 -- UNI2-AS Uni2 Autonomous System Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 31 17:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 31 Jul 2009 22:00:00 GMT Subject: The Cidr Report Message-ID: <200907312200.n6VM00px043598@wattle.apnic.net> This report has been generated at Fri Jul 31 21:11:38 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 24-07-09 298785 182835 25-07-09 299168 182751 26-07-09 298909 182973 27-07-09 299265 183099 28-07-09 299345 183207 29-07-09 299380 182987 30-07-09 299354 183395 31-07-09 299904 183680 AS Summary 31970 Number of ASes in routing system 13604 Number of ASes announcing only one prefix 4306 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 89732608 Largest address span announced by an AS (/32s) AS27064: DNIC-ASBLK-27032-27159 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 31Jul09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 300085 183736 116349 38.8% All ASes AS6389 4224 337 3887 92.0% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4306 1661 2645 61.4% TWTC - tw telecom holdings, inc. AS4766 1820 536 1284 70.5% KIXS-AS-KR Korea Telecom AS17488 1544 311 1233 79.9% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1227 194 1033 84.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1081 70 1011 93.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1505 595 910 60.5% Uninet S.A. de C.V. AS18566 1062 261 801 75.4% COVAD - Covad Communications Co. AS19262 1021 236 785 76.9% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18101 750 43 707 94.3% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS8452 1025 325 700 68.3% TEDATA TEDATA AS6478 1249 595 654 52.4% ATT-INTERNET3 - AT&T WorldNet Services AS4804 686 70 616 89.8% MPX-AS Microplex PTY LTD AS1785 1719 1119 600 34.9% AS-PAETEC-NET - PaeTec Communications, Inc. AS17908 730 154 576 78.9% TCISL Tata Communications AS10620 964 401 563 58.4% TV Cable S.A. AS4808 754 200 554 73.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS22047 539 14 525 97.4% VTR BANDA ANCHA S.A. AS9498 637 119 518 81.3% BBIL-AP BHARTI Airtel Ltd. AS7303 601 95 506 84.2% Telecom Argentina S.A. AS855 614 124 490 79.8% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS17676 564 78 486 86.2% GIGAINFRA Softbank BB Corp. AS11492 1129 658 471 41.7% CABLEONE - CABLE ONE, INC. AS7018 1515 1049 466 30.8% ATT-INTERNET4 - AT&T WorldNet Services AS24560 729 273 456 62.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS9443 531 84 447 84.2% INTERNETPRIMUS-AS-AP Primus Telecommunications AS4134 980 535 445 45.4% CHINANET-BACKBONE No.31,Jin-rong Street AS7545 831 398 433 52.1% TPG-INTERNET-AP TPG Internet Pty Ltd AS4780 560 136 424 75.7% SEEDNET Digital United Inc. AS7011 987 569 418 42.4% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. Total 35884 11240 24644 68.7% Top 30 total Possible Bogus Routes 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.112.0/22 AS5713 SAIX-NET 41.223.176.0/22 AS36981 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.31.59.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.31.60.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 91.213.112.0/24 AS42755 ICTALPHEN-AS IT Business Centre ICT-Alphen 100.100.100.0/30 AS38676 AS33005-AS-KR wizsolution co.,Ltd 116.50.0.0/24 AS17754 EXCELL-AS Excellmedia 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.10.0/24 AS38236 121.50.13.0/24 AS38236 121.50.15.0/24 AS17625 BLAZENET-IN-AP BlazeNet's Network 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 158.222.5.0/24 AS21580 SIERRA-ADVANTAGE - Sierra Advantage, Inc. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.244.48.0/20 AS25424 INEXT-CZ INTERNEXT 2000 s.r.o. 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.132.58.0/24 AS20141 QUALITYTECH-SUW-300 - Quality Technology Services, LLC. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 193.33.148.0/23 AS30890 EVOLVA Evolva Telecom / iLink Telecom 193.104.229.0/26 AS34444 EUTELSAT-BACKBONE-AS EUTELSAT S.A. 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.5.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.19.0.0/24 AS3848 WORLDLINX-2 - WorldLinx Telecommunications, Inc. 199.114.0.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 ITCOMM - IT Communications 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.9.115.0/24 AS10292 CWJ-1 - Cable & Wireless Jamaica 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.84.10.0/23 AS9308 CHINA-ABITCOOL Abitcool(China) Inc. 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS2764 AAPT AAPT Limited 202.124.195.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.86.96.0/19 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.138.167.0/24 AS18990 AIRBAND-DALLAS - Airband Communications, Inc 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.151.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.177.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.178.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.88.0/21 AS36835 208.77.224.0/24 AS36835 208.77.225.0/24 AS36835 208.77.226.0/24 AS36835 208.77.227.0/24 AS36835 208.77.228.0/24 AS36835 208.77.229.0/24 AS36835 208.77.230.0/24 AS36835 208.77.231.0/24 AS36835 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.217.224.0/19 AS6130 AIS-WEST - American Internet Services, LLC. 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 213.181.70.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.80.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.81.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.82.0/23 AS17175 NSS-UK New Skies Satellites UK AS 213.181.82.0/24 AS17175 NSS-UK New Skies Satellites UK AS 213.181.83.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.84.0/22 AS17175 NSS-UK New Skies Satellites UK AS 213.181.84.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.85.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.86.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.87.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.88.0/21 AS17175 NSS-UK New Skies Satellites UK AS 213.181.88.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.89.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.90.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.91.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.92.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.93.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.94.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.95.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.72.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.73.0/24 AS12491 IPPLANET-AS Gilat Satcom Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From up at 3.am Fri Jul 31 17:05:06 2009 From: up at 3.am (up at 3.am) Date: Fri, 31 Jul 2009 18:05:06 -0400 (EDT) Subject: Data Center QoS equipment breaking http 1.1? In-Reply-To: References: Message-ID: Please disregard this idiocy of mine...it appears that the Apache UseCanonicalName directive selectively breaks some NameVirtualHosts, while leaving others unscathed, but turning it off fixed it anyway. On Fri, 31 Jul 2009, up at 3.am wrote: > > Sorry if this is a little OT, but we're seeing a serious problem and was > wondering if it is what I think it is. > > In short: I have been moving services off of our servers in a data center > onto a server at eSecuredata, who rents dedicated servers. The idea is to > lower costs and eliminate having to deal with hardware. > > The advertise "unmetered bandwidth", but mention QoS measure to control > "bandwidth hogs". > > One of my customers, whose site I just moved from a unique IP virtual host on > my old server onto an Apache NameVirtualHost on the new one, worked fine at > first. Then today, they started complaining about getting one of our home > pages. I figured DNS or web caching issues, until I started seeing it for > myself. It was no caching issue, it was NameVirtualHost breaking. > > I poured over my configs (I've done this config countless times), and saw > this in the apache docs: > > http://httpd.apache.org/docs/2.2/vhosts/name-based.html > > " Some operating systems and network equipment implement bandwidth management > techniques that cannot differentiate between hosts unless they are on > separate IP addresses." > > So, I installed lynx on the server, and sure enough, it worked perfectly fine > there, just not from anywhere outside eSecuredata's network that I could see. > > Can anyone shed any light on this particular practice, of this company in > particular? > > thanks > > James Smallacombe PlantageNet, Inc. CEO and Janitor > up at 3.am http://3.am > ========================================================================= > James Smallacombe PlantageNet, Inc. CEO and Janitor up at 3.am http://3.am ========================================================================= From patrick at ianai.net Fri Jul 31 17:22:37 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 31 Jul 2009 18:22:37 -0400 Subject: The Cidr Report In-Reply-To: <200907312200.n6VM00px043598@wattle.apnic.net> References: <200907312200.n6VM00px043598@wattle.apnic.net> Message-ID: <73CBA376-77FB-4E13-A062-3C6FE31EF8DE@ianai.net> On Jul 31, 2009, at 6:00 PM, cidr-report at potaroo.net wrote: > Recent Table History > Date Prefixes CIDR Agg > 24-07-09 298785 182835 > 25-07-09 299168 182751 > 26-07-09 298909 182973 > 27-07-09 299265 183099 > 28-07-09 299345 183207 > 29-07-09 299380 182987 > 30-07-09 299354 183395 > 31-07-09 299904 183680 Only 94 prefixes short! Any bets on whether next tomorrow is THREE HUNDRED (thousand) day? Careful what you say, we actually dropped prefixes Wed -> Thurs this week. How many router will have blood spattered over them? :-) -- TTFN, patrick From up at 3.am Fri Jul 31 19:02:07 2009 From: up at 3.am (up at 3.am) Date: Fri, 31 Jul 2009 20:02:07 -0400 (EDT) Subject: Verizon transparent web caching issue? WASRe: Data Center QoS equipment breaking http 1.1? In-Reply-To: References: Message-ID: Disregard my disregard. The problem resurfaced with no changes on my part. I purged browser caches and tried them from 3 browsers and each time: http://www.countytheater.org redirected to: http://webmail.ns3.pil.net/ which is another NameVhost on that server sharing that IP. This is incorrect. However, I then switch from a Verizon connection to an ATT 3g connection on the IPhone and the problem goes away. Has anyone heard of upstream transparent caching issues causing this kind of problem? Does anyone else here get the redirect instead of the correct page? TIA On Fri, 31 Jul 2009, up at 3.am wrote: > > Please disregard this idiocy of mine...it appears that the Apache > UseCanonicalName directive selectively breaks some NameVirtualHosts, while > leaving others unscathed, but turning it off fixed it anyway. > > On Fri, 31 Jul 2009, up at 3.am wrote: > >> >> Sorry if this is a little OT, but we're seeing a serious problem and was >> wondering if it is what I think it is. >> >> In short: I have been moving services off of our servers in a data center >> onto a server at eSecuredata, who rents dedicated servers. The idea is to >> lower costs and eliminate having to deal with hardware. >> >> The advertise "unmetered bandwidth", but mention QoS measure to control >> "bandwidth hogs". >> >> One of my customers, whose site I just moved from a unique IP virtual host >> on my old server onto an Apache NameVirtualHost on the new one, worked fine >> at first. Then today, they started complaining about getting one of our >> home pages. I figured DNS or web caching issues, until I started seeing it >> for myself. It was no caching issue, it was NameVirtualHost breaking. >> >> I poured over my configs (I've done this config countless times), and saw >> this in the apache docs: >> >> http://httpd.apache.org/docs/2.2/vhosts/name-based.html >> >> " Some operating systems and network equipment implement bandwidth >> management techniques that cannot differentiate between hosts unless they >> are on separate IP addresses." >> >> So, I installed lynx on the server, and sure enough, it worked perfectly >> fine there, just not from anywhere outside eSecuredata's network that I >> could see. >> >> Can anyone shed any light on this particular practice, of this company in >> particular? >> >> thanks >> >> James Smallacombe PlantageNet, Inc. CEO and Janitor >> up at 3.am >> http://3.am >> ========================================================================= >> > > James Smallacombe PlantageNet, Inc. CEO and Janitor > up at 3.am http://3.am > ========================================================================= > > James Smallacombe PlantageNet, Inc. CEO and Janitor up at 3.am http://3.am ========================================================================= From jay at miscreant.org Fri Jul 31 19:34:12 2009 From: jay at miscreant.org (jay at miscreant.org) Date: Sat, 01 Aug 2009 10:34:12 +1000 Subject: Verizon transparent web caching issue? WASRe: Data Center QoS equipment breaking http 1.1? In-Reply-To: References: Message-ID: <20090801103412.gzbwjds4oo04g04w@web1.nswh.com.au> Quoting up at 3.am: > > Disregard my disregard. The problem resurfaced with no changes on my > part. I purged browser caches and tried them from 3 browsers and each > time: > > http://www.countytheater.org > > redirected to: http://webmail.ns3.pil.net/ which is another NameVhost > on that server sharing that IP. This is incorrect. However, I then > switch from a Verizon connection to an ATT 3g connection on the IPhone > and the problem goes away. > > Has anyone heard of upstream transparent caching issues causing this > kind of problem? Does anyone else here get the redirect instead of the > correct page? > > TIA From .au the first 3 times I got pil.net. After that I got lots of 302's and finally www.countytheater.org loaded, however the url showing in the browser is http://ns3.pil.net/~jsanders/. Looking at the packet cap it looks like your apache is doing strange things. --jay From up at 3.am Fri Jul 31 20:06:03 2009 From: up at 3.am (up at 3.am) Date: Fri, 31 Jul 2009 21:06:03 -0400 (EDT) Subject: Verizon transparent web caching issue? WASRe: Data Center QoS equipment breaking http 1.1? In-Reply-To: References: Message-ID: Again, turned out to be my own stupidity. It was just DNS on a secondary DNS server, which was pointing to the old IP, which was redirecting to the new IP, but at that point, the headers are lost. I would have thought that on MacOSX (my client; the server is FreeBSD 7.2-STABLE), if I tell the /etc/resolv.conf to look at the primary name server only, which has the correct info, plus doing a dnscacheutil -flushcache, that this wouldn't be an issue. Apparently, I was wrong, or perhaps it doesn't override what Verizon does with my browser's queries, despite what nslookup shows in a terminal window. On Fri, 31 Jul 2009, up at 3.am wrote: > > Disregard my disregard. The problem resurfaced with no changes on my part. > I purged browser caches and tried them from 3 browsers and each time: > > http://www.countytheater.org > > redirected to: http://webmail.ns3.pil.net/ which is another NameVhost on > that server sharing that IP. This is incorrect. However, I then switch from > a Verizon connection to an ATT 3g connection on the IPhone and the problem > goes away. > > Has anyone heard of upstream transparent caching issues causing this kind of > problem? Does anyone else here get the redirect instead of the correct page? > > TIA > > On Fri, 31 Jul 2009, up at 3.am wrote: > >> >> Please disregard this idiocy of mine...it appears that the Apache >> UseCanonicalName directive selectively breaks some NameVirtualHosts, while >> leaving others unscathed, but turning it off fixed it anyway. >> >> On Fri, 31 Jul 2009, up at 3.am wrote: >> >>> >>> Sorry if this is a little OT, but we're seeing a serious problem and was >>> wondering if it is what I think it is. >>> >>> In short: I have been moving services off of our servers in a data center >>> onto a server at eSecuredata, who rents dedicated servers. The idea is to >>> lower costs and eliminate having to deal with hardware. >>> >>> The advertise "unmetered bandwidth", but mention QoS measure to control >>> "bandwidth hogs". >>> >>> One of my customers, whose site I just moved from a unique IP virtual host >>> on my old server onto an Apache NameVirtualHost on the new one, worked >>> fine at first. Then today, they started complaining about getting one of >>> our home pages. I figured DNS or web caching issues, until I started >>> seeing it for myself. It was no caching issue, it was NameVirtualHost >>> breaking. >>> >>> I poured over my configs (I've done this config countless times), and saw >>> this in the apache docs: >>> >>> http://httpd.apache.org/docs/2.2/vhosts/name-based.html >>> >>> " Some operating systems and network equipment implement bandwidth >>> management techniques that cannot differentiate between hosts unless they >>> are on separate IP addresses." >>> >>> So, I installed lynx on the server, and sure enough, it worked perfectly >>> fine there, just not from anywhere outside eSecuredata's network that I >>> could see. >>> >>> Can anyone shed any light on this particular practice, of this company in >>> particular? >>> >>> thanks >>> >>> James Smallacombe PlantageNet, Inc. CEO and Janitor >>> up at 3.am http://3.am >>> ========================================================================= >>> >> >> James Smallacombe PlantageNet, Inc. CEO and Janitor >> up at 3.am >> http://3.am >> ========================================================================= >> >> > > James Smallacombe PlantageNet, Inc. CEO and Janitor > up at 3.am http://3.am > ========================================================================= > James Smallacombe PlantageNet, Inc. CEO and Janitor up at 3.am http://3.am ========================================================================= From nanog at daork.net Fri Jul 31 20:13:19 2009 From: nanog at daork.net (Nathan Ward) Date: Sat, 1 Aug 2009 13:13:19 +1200 Subject: Verizon transparent web caching issue? WASRe: Data Center QoS equipment breaking http 1.1? In-Reply-To: References: Message-ID: <5190A622-D3ED-4065-B206-EB8D3CC949AE@daork.net> On 1/08/2009, at 1:06 PM, up at 3.am wrote: > > Again, turned out to be my own stupidity. It was just DNS on a > secondary DNS server, which was pointing to the old IP, which was > redirecting to the new IP, but at that point, the headers are lost. > > I would have thought that on MacOSX (my client; the server is > FreeBSD 7.2-STABLE), if I tell the /etc/resolv.conf to look at the > primary name server only, which has the correct info, plus doing a > dnscacheutil -flushcache, that this wouldn't be an issue. > > Apparently, I was wrong, or perhaps it doesn't override what Verizon > does with my browser's queries, despite what nslookup shows in a > terminal window. As you are on OS X, have a read of http://developer.apple.com/documentation/Darwin/Reference/Manpages/man5/resolver.5.html It lets you do per-domain resolvers, and so on. -- Nathan Ward From john at vanoppen.com Tue Jul 28 10:36:30 2009 From: john at vanoppen.com (John van Oppen) Date: Tue, 28 Jul 2009 08:36:30 -0700 Subject: XO - a Tier 1 or not? References: <607f1e0a0907280811j6257ed1w21fcb331e271daf5@mail.gmail.com> Message-ID: XO has been offering a product lately that is all routes except level3 and sprint which leads me to believe that they pay both of those peers... John van Oppen Spectrum Networks LLC Direct: 206.973.8302 Main: 206.973.8300 Website: http://spectrumnetworks.us -----Original Message----- From: Justin M. Streiner [mailto:streiner at cluebyfour.org] Sent: Tuesday, July 28, 2009 8:31 AM To: nanog at nanog.org Subject: Re: XO - a Tier 1 or not? On Tue, 28 Jul 2009, Charles Mills wrote: > Trying to sort through the marketecture and salesman speak and get a > definitive answer. > > I figure the NANOGers would be able to give me some input. > > Is XO Communications a Tier 1 ISP? Do the best of my knowledge, no. The definition of 'Tier 1' is something of a moving target based on who you ask, but the most commonly stated criteria I've seen over the years are: 1. The provider does not buy IP transit from anyone - all traffic is moved on settlement-free public or private interconnects. That's not to say that the provider doesn't buy non-IP services (IRUs, lambdas, easements, etc) from other providers on occasion. 2. The provider lives in the default-free zone, which is pretty much a re-statement of point 1. I'll leave discussions about geographical coverage out of it for now. That said, I don't think XO meets the criteria above. I'm not 100% certain, but I don't think they're totally settlement-free. Other providers like Cogent would fall into this bucket as well. However, I also wouldn't get too hung up on tiers. Many very reliable, competent, and responsive providers providers but transit to handle at least some portion of their traffic. It also depends on what sort of service you need. For example, if you need a big MPLS pipe to another country, there are a limited number of providers who can do that, so they would tend to be the big guys. However, if you just need general IP transit, your options open up quite a bit. jms