From vixie at isc.org Mon Jun 1 00:08:43 2009 From: vixie at isc.org (Paul Vixie) Date: Mon, 01 Jun 2009 05:08:43 +0000 Subject: White House net security paper In-Reply-To: (Randy Bush's message of "Mon\, 01 Jun 2009 13\:08\:05 +0900") References: <200905312247190.32BF5B92.5704@clifden.donelan.com> <20090601032343.GF21477@skywalker.creative.net.au> Message-ID: Randy Bush writes: > As hire As. Bs hire Cs. Lots of Cs. > > this problem needs neurons, not battalions. this problem needs round-tuits, which Good Guys are consistently short of, but which Bad Guys always have as many of as they can find use for. a few battalions of B's and C's, if wisely deployed, could bridge that gap. the key to all this is therefore not really "neurons" but rather "wiselyness". i promise to, um, mention this, or maybe more, in my nanog-philly keynote. -- Paul Vixie KI6YSY From vixie at isc.org Mon Jun 1 00:12:25 2009 From: vixie at isc.org (Paul Vixie) Date: Mon, 01 Jun 2009 05:12:25 +0000 Subject: White House net security paper In-Reply-To: <200905312247190.32BF5B92.5704@clifden.donelan.com> (Sean Donelan's message of "Sun\, 31 May 2009 22\:54\:40 -0400 \(EDT\)") References: <200905312247190.32BF5B92.5704@clifden.donelan.com> Message-ID: Sean Donelan writes: > How many ISPs have too many network security people? network security is a "loss center". not just a cost center, a *loss* center. non-bankrupt ISP's whose investors will make good multiples only staff their *profit* centers. the Good Guys and Bad Guys all know this -- the difference is that the Good Guys try not to think about this whereas the Bad Guys think about it all the time. -- Paul Vixie KI6YSY From randy at psg.com Mon Jun 1 02:41:50 2009 From: randy at psg.com (Randy Bush) Date: Mon, 01 Jun 2009 16:41:50 +0900 Subject: White House net security paper In-Reply-To: References: <200905312247190.32BF5B92.5704@clifden.donelan.com> <20090601032343.GF21477@skywalker.creative.net.au> Message-ID: >> As hire As. Bs hire Cs. Lots of Cs. >> this problem needs neurons, not battalions. > this problem needs round-tuits, which Good Guys are consistently short > of, but which Bad Guys always have as many of as they can find use > for. a few battalions of B's and C's, if wisely deployed, could > bridge that gap. there is a reason Bs and Cs have spare round-tuits. fred brooks was no fool. os/360 taught some of us some lessons. batallions work in the infantry, or so i am told. this is rocket science. randy From randy at psg.com Mon Jun 1 02:43:46 2009 From: randy at psg.com (Randy Bush) Date: Mon, 01 Jun 2009 16:43:46 +0900 Subject: White House net security paper In-Reply-To: References: <200905312247190.32BF5B92.5704@clifden.donelan.com> Message-ID: > network security is a "loss center". not just a cost center, a *loss* center. > non-bankrupt ISP's whose investors will make good multiples only staff their > *profit* centers. this glib statement may have been true at the isps where you worked. it is not true for the ones where i work(ed). randy From tim at pelican.org Mon Jun 1 03:00:38 2009 From: tim at pelican.org (Tim Franklin) Date: Mon, 1 Jun 2009 09:00:38 +0100 (BST) Subject: DNS ed.gov translations In-Reply-To: <6864111.01243843140914.JavaMail.root@new-jennyfur.pelican.org> Message-ID: <6551274.21243843238896.JavaMail.root@new-jennyfur.pelican.org> > ROTFL what an honour ;-), as we are in to weekend mood anyway I share > the reason for this. When I joined Colt my signature did look like this: > > --- > ___ ___ ___ ___ Ralf Weber t: +49 (0)69 56606 2780 > \C/ \O/ \L/ \T/ System Administrator > V V V V COLT Telecom GmbH f: +49 (0)69 56606 6280 > IP Services e: rw at colt.net As did everyone's, I think - it's great that we had such an ASCII-art-friendly logo :) > That was used until our lawyers decided that as with real letters it > was their duty to design the fine print on email also. This lead to > what you see now below. I don't like it but am bound to use it. In the > signatur select box of my email program the signatur below is named "rw at colt.net > violating RFC1855". I moved all my work-related mailing-list subscriptions to personal email when the legal departments started getting hold of .sigs. It seems pretty much impossible these days to post from a work address to any external email at all without looking like an idiot. (Of course, just removing the legal boilerplate doesn't, in itself, *prevent* me from looking an idiot, before anyone goes for the obvious...) Regards, Tim. From hank at efes.iucc.ac.il Mon Jun 1 03:02:31 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 01 Jun 2009 11:02:31 +0300 Subject: White House net security paper In-Reply-To: References: <200905312247190.32BF5B92.5704@clifden.donelan.com> Message-ID: <5.1.0.14.2.20090601110138.00aee650@efes.iucc.ac.il> At 04:43 PM 01-06-09 +0900, Randy Bush wrote: > > network security is a "loss center". not just a cost center, a *loss* > center. > > non-bankrupt ISP's whose investors will make good multiples only staff > their > > *profit* centers. > >this glib statement may have been true at the isps where you worked. it >is not true for the ones where i work(ed). It is true at every ISP I have ever encountered. I do not consider the statement glib. -Hank From randy at psg.com Mon Jun 1 03:06:38 2009 From: randy at psg.com (Randy Bush) Date: Mon, 01 Jun 2009 17:06:38 +0900 Subject: White House net security paper In-Reply-To: <5.1.0.14.2.20090601110138.00aee650@efes.iucc.ac.il> References: <200905312247190.32BF5B92.5704@clifden.donelan.com> <5.1.0.14.2.20090601110138.00aee650@efes.iucc.ac.il> Message-ID: >>> network security is a "loss center". not just a cost center, a >>> *loss* center. non-bankrupt ISP's whose investors will make good >>> multiples only staff their *profit* centers. >> this glib statement may have been true at the isps where you worked. it >> is not true for the ones where i work(ed). > It is true at every ISP I have ever encountered. I do not consider the > statement glib. well, i guess some of us are pickier than others, and have the luck of having choices. randy From Ben.Matthew at timlradio.co.uk Mon Jun 1 05:59:30 2009 From: Ben.Matthew at timlradio.co.uk (Ben Matthew) Date: Mon, 1 Jun 2009 11:59:30 +0100 Subject: In a bit of bind... Message-ID: Firstly... I apologise for the atrocious pun in the subject; just can't seem to help myself. Anyway my company currently uses BIND for our DNS requirements (9.6.0). I'm always pretty keen on updating, when advised to, in order to patch vulnerabilities and so forth as we have a fairly popular website and I'm sure there's lots of nasty little tykes out there ready to try and take us down. I have six servers in total, two multi-homed servers for ordinary DNS and four servers running an Anycast network (2 x master and slave). Anyway I've recently been investigating other options for DNS as, like many companies currently, we've laid off a bunch of staff and the overhead for maintaining BIND is quite high if done, like us, unassisted and you are editing zone files in a text editor. Ultimately for our simple zones (non-Anycast, basic web forwarders) I want to create a web-app to do this for me, probably in PHP. I could create something that: 1) Creates a zone file for "mydomain.com" and fills in defaults; overrides with options from the web-app if needed. 2) Updates the existing named.conf file 3) Opens a secure connection to the master, and uploads new config files 4) Runs a remote process to restart BIND 5) Opens a secure connection to slave, updates named.conf 6) Runs a remote process to restart BIND But I've had a play with "myDNS" (http://mydns.bboy.net) which is capable of serving DNS requests directly from a mySQL database. And it seems pretty good. All my web-app now needs to do is adjust some database records and everything else updates automatically. All very cool. However, my question is this... Has anyone yet experienced any major problems with myDNS - either security or reliability? Frankly, I'm a little scared of daring to shift away from a well-established system. Perhaps you've had the chance to poke about in the code... Is it based on the BIND codebase? Does it get security updates when exploits are revealed? Finally I've managed to successfully configure BIND 9 as a slave to a myDNS server and the AXFR transfers seem to be working fine. This strikes me as being quite a nice balance of ease of use and reliability in case myDNS fails on me. Ok I appreciate it doesn't get around security concerns but hey ho. Opinions much appreciated. Cheers, Ben -- Ben Matthew, Senior Network Engineer Absolute Radio, One Golden Square, London W1F 9DJ Tel: 020 7432 3457 Mobile: 07817464623 http://www.absoluteradio.co.uk Absolute Radio, winner of four Sony Radio Awards in 2009 ________________________________________________ DISCLAIMER This e-mail message, including any attachments, is intended solely for the use of the addressee and may contain confidential information. If it is not intended for you, please inform the sender and delete the e-mail and any attachments immediately. Any review, retransmission, disclosure, copying or modification of it is strictly forbidden. Please be advised that the views and opinions expressed in this e-mail may not reflect the views and opinions of TIML Radio Limited or any of its parent and subsidiary companies. Whilst we take reasonable precautions to ensure that our emails are free from viruses, we cannot be responsible for any viruses transmitted with this e-mail and recommend that you subject any incoming e-mail to your own virus checking procedures. Use of this or any other e-mail facility signifies consent to any interception we might lawfully carry out to prevent abuse of these facilities. ________________________________________________ TIML Radio Limited (trading as Absolute Radio) Registered office: One Golden Square, London. W1F 9DJ Registered in England No 02674136 VAT No 927 2572 11 From swm at emanon.com Mon Jun 1 06:17:27 2009 From: swm at emanon.com (Scott Morris) Date: Mon, 01 Jun 2009 07:17:27 -0400 Subject: In a bit of bind... In-Reply-To: References: Message-ID: <4A23B8C7.6030008@emanon.com> May seem a little simplistic, but how about Webmin. :) Runs on most linux-type systems over SSL/https and allows you to administer your DNS (and other services) without issues and provide the things you listed below. Oh, and it's free. And it's already done. Scott Ben Matthew wrote: > Firstly... I apologise for the atrocious pun in the subject; just can't seem to help myself. > > Anyway my company currently uses BIND for our DNS requirements (9.6.0). I'm always pretty keen on updating, when advised to, in order to patch vulnerabilities and so forth as we have a fairly popular website and I'm sure there's lots of nasty little tykes out there ready to try and take us down. I have six servers in total, two multi-homed servers for ordinary DNS and four servers running an Anycast network (2 x master and slave). > > Anyway I've recently been investigating other options for DNS as, like many companies currently, we've laid off a bunch of staff and the overhead for maintaining BIND is quite high if done, like us, unassisted and you are editing zone files in a text editor. > > Ultimately for our simple zones (non-Anycast, basic web forwarders) I want to create a web-app to do this for me, probably in PHP. I could create something that: > > > 1) Creates a zone file for "mydomain.com" and fills in defaults; overrides with options from the web-app if needed. > > 2) Updates the existing named.conf file > > 3) Opens a secure connection to the master, and uploads new config files > > 4) Runs a remote process to restart BIND > > 5) Opens a secure connection to slave, updates named.conf > > 6) Runs a remote process to restart BIND > > But I've had a play with "myDNS" (http://mydns.bboy.net) which is capable of serving DNS requests directly from a mySQL database. And it seems pretty good. All my web-app now needs to do is adjust some database records and everything else updates automatically. All very cool. > > However, my question is this... Has anyone yet experienced any major problems with myDNS - either security or reliability? Frankly, I'm a little scared of daring to shift away from a well-established system. > > Perhaps you've had the chance to poke about in the code... Is it based on the BIND codebase? Does it get security updates when exploits are revealed? > > Finally I've managed to successfully configure BIND 9 as a slave to a myDNS server and the AXFR transfers seem to be working fine. This strikes me as being quite a nice balance of ease of use and reliability in case myDNS fails on me. Ok I appreciate it doesn't get around security concerns but hey ho. > > Opinions much appreciated. > > Cheers, > > Ben > > -- > Ben Matthew, Senior Network Engineer > Absolute Radio, One Golden Square, London W1F 9DJ > Tel: 020 7432 3457 Mobile: 07817464623 > http://www.absoluteradio.co.uk > > Absolute Radio, winner of four Sony Radio Awards in 2009 > > > ________________________________________________ > DISCLAIMER > This e-mail message, including any attachments, is intended solely for the use of the addressee and may contain confidential information. If it is not intended for you, please inform the sender and delete the e-mail and any attachments immediately. Any review, retransmission, disclosure, copying or modification of it is strictly forbidden. Please be advised that the views and opinions expressed in this e-mail may not reflect the views and opinions of TIML Radio Limited or any of its parent and subsidiary companies. > Whilst we take reasonable precautions to ensure that our emails are free from viruses, we cannot be responsible for any viruses transmitted with this e-mail and recommend that you subject any incoming e-mail to your own virus checking procedures. Use of this or any other e-mail facility signifies consent to any interception we might lawfully carry out to prevent abuse of these facilities. > ________________________________________________ > TIML Radio Limited (trading as Absolute Radio) > Registered office: One Golden Square, London. W1F 9DJ > Registered in England No 02674136 VAT No 927 2572 11 > > > > > From cmeidinger at sendmail.com Mon Jun 1 06:27:45 2009 From: cmeidinger at sendmail.com (Chris Meidinger) Date: Mon, 1 Jun 2009 13:27:45 +0200 Subject: In a bit of bind... In-Reply-To: References: Message-ID: On 01.06.2009, at 12:59, Ben Matthew wrote: > Finally I've managed to successfully configure BIND 9 as a slave to > a myDNS server and the AXFR transfers seem to be working fine. This > strikes me as being quite a nice balance of ease of use and > reliability in case myDNS fails on me. Ok I appreciate it doesn't > get around security concerns but hey ho. As far as as security, why have myDNS world-reachable at all? You can have bind feed off of myDNS without having anyone on the outside ever talk to the myDNS backend. Chris From karnaugh at karnaugh.za.net Mon Jun 1 06:31:44 2009 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Mon, 1 Jun 2009 13:31:44 +0200 Subject: In a bit of bind... In-Reply-To: References: Message-ID: <78bfcf050906010431t773af886x52a3b3f82be434d9@mail.gmail.com> On Mon, Jun 1, 2009 at 12:59 PM, Ben Matthew wrote: > Anyway my company currently uses BIND for our DNS requirements (9.6.0). > I'm always pretty keen on updating, when advised to, in order to patch > vulnerabilities and so forth as we have a fairly popular website and I'm > sure there's lots of nasty little tykes out there ready to try and take us > down. I have six servers in total, two multi-homed servers for ordinary DNS > and four servers running an Anycast network (2 x master and slave). > > Anyway I've recently been investigating other options for DNS as, like many > companies currently, we've laid off a bunch of staff and the overhead for > maintaining BIND is quite high if done, like us, unassisted and you are > editing zone files in a text editor. > > You don't necessarily need to move away from Bind but what you do need is a better backend. Certainly you should avoid Webmin and trying to automate changes to BIND zone files as this gets really messy and unmaintainable very quickly. You can use Bind9 DLZ and MySQL or LDAP. I didn't find this all that easy to package or manage though. Personally, for scalable authoritative DNS I think PowerDNS is far better especially with an LDAP backend as LDAP is trivial to replicate over large numbers of slaves. An interface to LDAP for DNS was also a trivial project for us. If you don't need so much scalability there are existing web interfaces for PowerDNS using the MySQL backend. https://webdns.bountysource.com/ https://www.poweradmin.org/trac/ From sean at donelan.com Mon Jun 1 07:32:23 2009 From: sean at donelan.com (Sean Donelan) Date: Mon, 1 Jun 2009 08:32:23 -0400 (EDT) Subject: White House net security paper In-Reply-To: References: <200905312247190.32BF5B92.5704@clifden.donelan.com> <20090601032343.GF21477@skywalker.creative.net.au> Message-ID: <200906010826250.32BF5B92.6796@clifden.donelan.com> If people think that support for R&E programs should be cut instead, I guess that is also a useful data point. It would be noteworthy that any group advocated a cut in their own funding. "The Federal government, with the participation of all departments and agencies, should expand support for key education programs and research and development to ensure the Nation~Rs continued ability to compete in the information age economy. Existing programs should be evaluated and possibly expanded, and other activities could serve as models for additional programs." Jared's message earlier had the information about how you could participate if you have suggestions. From jared at puck.nether.net Mon Jun 1 08:18:04 2009 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 1 Jun 2009 09:18:04 -0400 Subject: White House net security paper In-Reply-To: <200906010826250.32BF5B92.6796@clifden.donelan.com> References: <200905312247190.32BF5B92.5704@clifden.donelan.com> <20090601032343.GF21477@skywalker.creative.net.au> <200906010826250.32BF5B92.6796@clifden.donelan.com> Message-ID: <1BA27C33-6603-4983-8AC1-3AB2D4C82BAF@puck.nether.net> On Jun 1, 2009, at 8:32 AM, Sean Donelan wrote: > If people think that support for R&E programs should be cut instead, > I guess that is also a useful data point. It would be noteworthy > that any group advocated a cut in their own funding. > > "The Federal government, with the participation of all departments > and > agencies, should expand support for key education programs and > research > and development to ensure the Nation~Rs continued ability to > compete in > the information age economy. Existing programs should be evaluated > and > possibly expanded, and other activities could serve as models for > additional programs." > > Jared's message earlier had the information about how you could > participate > if you have suggestions. There have been numerous recommendations over the years to improve education and training of IT/Security professionals directed at either DHS, EOP and other agencies. I see a critical gap in this space myself. There are not enough people that are truly skilled in this space. Perhaps this need will never be met, but with the consistent threat of compromise facing any network connected organization, there need to be people who are trained to respond. There just are not enough skilled network & security engineers out there. US-CERT (as an example) is always hiring, and I have heard stories of people going from fast-food to trying to decipher intrusion data because they could get their TS/SCI. I'm certain that anyone who can combine two skills (computers, computer networks or data forensics) with some criminal justice could help fight the bad guys. There is a severe lack of talent here. - Jared From skeeve at skeeve.org Mon Jun 1 08:42:13 2009 From: skeeve at skeeve.org (Skeeve Stevens) Date: Mon, 1 Jun 2009 23:42:13 +1000 Subject: US Based Server host on v6 Message-ID: Hey guys, I mostly use Ezzi.net and a couple of others for server hosting. I am looking for the same, but with dual-stack traffic and ipv6 addresses. in theory it should be the same cost. Anyone know any companies doing this yet? .Skeeve -- Skeeve Stevens - skeeve at skeeve.org www.skeeve.org / Cell +61 (0)414 753 383 msn://skeeve at skeeve.org ; skype://skeeve twitter://skeevestevens ; Also facebook (skeeve at skeeve.org) and LinkedIn (skeeve at eintellego.net) eintellego - skeeve at eintellego.net - www.eintellego.net -- I'm a groove licked love child king of the verse Si vis pacem, para bellum From Ben.Matthew at timlradio.co.uk Mon Jun 1 08:58:01 2009 From: Ben.Matthew at timlradio.co.uk (Ben Matthew) Date: Mon, 1 Jun 2009 14:58:01 +0100 Subject: In a bit of bind... In-Reply-To: <4A23BE84.5030404@poggs.co.uk> References: <4A23BE84.5030404@poggs.co.uk> Message-ID: Thanks very much for the various responses to my question; both on and off-list. I'm very much liking the idea of only letting the outside world see bind and then AXFR'ing the data from an easier-to-manage internal database backed solution. Whether that be myDNS, Microsoft or whatever. Bit of initial config work and then, in theory, an easy job to administer. Actually feel a bit dumb for not considering that in the first place. Cheers again, Ben -----Original Message----- From: Peter Hicks [mailto:peter.hicks at poggs.co.uk] Sent: 01 June 2009 12:42 To: Ben Matthew Cc: nanog at nanog.org Subject: Re: In a bit of bind... Ben, Ben Matthew wrote: > I have six servers in total, two multi-homed servers for ordinary DNS and four servers running an Anycast network (2 x master and slave). > For DNS, you may find it easier to outsource hosting to another provider who has geographically diverse DNS services. This doesn't necessarily mean loss of control. It also separates your nameserver hosting from your servers - suppose your network were to be under attack, or a configuration error dropped you offline. If DNS were somewhere else, you could log in, change A records, point somewhere else. > Anyway I've recently been investigating other options for DNS as, like many companies currently, we've laid off a bunch of staff and the overhead for maintaining BIND is quite high if done, like us, unassisted and you are editing zone files in a text editor. > Revision control systems - CVS, Subversion - are your friend here. What about wrapping up your DNS change procedure through perl or shell scripts which automatically roll back if bind doesn't reload, or some critical hosts suddenly disappear from the file. Also, ask yourself what the cost of operating the service without changes is, and what the cost of each change is. How often are you making changes? How often do you need to make a change in an absolute emergency? If changes are being done frequently, a technical or semi-technical member of staff will get to know the procedure. If changes are being made rarely, can the changes wait for you to apply them if you don't feel comfortable with others doing it? > Ultimately for our simple zones (non-Anycast, basic web forwarders) I want to create a web-app to do this for me, probably in PHP. I could create something that... Herein lies a problem - you want to create a web front-end to a DNS server. You're going to have to do a lot of testing to make this play nicely, and you could introduce your own security holes or gotchas. What is the cost of creating something yourself? How about one of the following? * Outsource DNS hosting, use another provider's interface to manage * BIND9 slaves, Windows-based master (hidden) which already has a GUI and it isn't difficult to change zones * Stick to what you have and document it, wrapping the 'apply' process in some simple shell or perl Peter ________________________________________________ DISCLAIMER This e-mail message, including any attachments, is intended solely for the use of the addressee and may contain confidential information. If it is not intended for you, please inform the sender and delete the e-mail and any attachments immediately. Any review, retransmission, disclosure, copying or modification of it is strictly forbidden. Please be advised that the views and opinions expressed in this e-mail may not reflect the views and opinions of TIML Radio Limited or any of its parent and subsidiary companies. Whilst we take reasonable precautions to ensure that our emails are free from viruses, we cannot be responsible for any viruses transmitted with this e-mail and recommend that you subject any incoming e-mail to your own virus checking procedures. Use of this or any other e-mail facility signifies consent to any interception we might lawfully carry out to prevent abuse of these facilities. ________________________________________________ TIML Radio Limited (trading as Absolute Radio) Registered office: One Golden Square, London. W1F 9DJ Registered in England No 02674136 VAT No 927 2572 11 From morrowc.lists at gmail.com Mon Jun 1 09:55:27 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 1 Jun 2009 10:55:27 -0400 Subject: US Based Server host on v6 In-Reply-To: References: Message-ID: <75cb24520906010755r105744b3u5f2fcf1ffc869cd3@mail.gmail.com> On Mon, Jun 1, 2009 at 9:42 AM, Skeeve Stevens wrote: > Hey guys, > I mostly use Ezzi.net and a couple of others for server hosting. > > I am looking for the same, but with dual-stack traffic and ipv6 addresses. > in theory it should be the same cost. > > Anyone know any companies doing this yet? > http://he.net/ From aaron at wholesaleinternet.com Mon Jun 1 11:47:52 2009 From: aaron at wholesaleinternet.com (Aaron Wendel) Date: Mon, 1 Jun 2009 11:47:52 -0500 Subject: AOL Postmaster Message-ID: <0e3201c9e2d8$b466f770$1d34e650$@com> Is anyone from AOL lurking on the list that could contact me of-list? I'm having some issues with mail being rejected because AOL believes our IPs are dynamic. Aaron From mwalter at 3z.net Mon Jun 1 12:23:07 2009 From: mwalter at 3z.net (Mike Walter) Date: Mon, 1 Jun 2009 13:23:07 -0400 Subject: AOL Postmaster In-Reply-To: <0e3201c9e2d8$b466f770$1d34e650$@com> References: <0e3201c9e2d8$b466f770$1d34e650$@com> Message-ID: Have you been through http://postmaster.aol.com/? Mike -----Original Message----- From: Aaron Wendel [mailto:aaron at wholesaleinternet.com] Sent: Monday, June 01, 2009 12:48 PM To: nanog at nanog.org Subject: AOL Postmaster Is anyone from AOL lurking on the list that could contact me of-list? I'm having some issues with mail being rejected because AOL believes our IPs are dynamic. Aaron From rmoseley at softlayer.com Mon Jun 1 13:18:38 2009 From: rmoseley at softlayer.com (Ric Moseley) Date: Mon, 1 Jun 2009 13:18:38 -0500 Subject: US Based Server host on v6 In-Reply-To: References: Message-ID: (not that I am self promoting but...) Softlayer (www.softlayer.com) has been offering ipv6 on dedicated servers for 6 months now on a dual stack network. Thanks. Ric. -----Original Message----- From: Skeeve Stevens [mailto:skeeve at skeeve.org] Sent: Monday, June 01, 2009 8:42 AM To: nanog at nanog.org Subject: US Based Server host on v6 Hey guys, I mostly use Ezzi.net and a couple of others for server hosting. I am looking for the same, but with dual-stack traffic and ipv6 addresses. in theory it should be the same cost. Anyone know any companies doing this yet? .Skeeve -- Skeeve Stevens - skeeve at skeeve.org www.skeeve.org / Cell +61 (0)414 753 383 msn://skeeve at skeeve.org ; skype://skeeve twitter://skeevestevens ; Also facebook (skeeve at skeeve.org) and LinkedIn (skeeve at eintellego.net) eintellego - skeeve at eintellego.net - www.eintellego.net -- I'm a groove licked love child king of the verse Si vis pacem, para bellum 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 cmaurand at xyonet.com Mon Jun 1 13:37:57 2009 From: cmaurand at xyonet.com (Curtis Maurand) Date: Mon, 01 Jun 2009 14:37:57 -0400 Subject: In a bit of bind... In-Reply-To: References: <4A23BE84.5030404@poggs.co.uk> Message-ID: <4A242005.4050608@xyonet.com> I've been using powerdns for quite a while and I've found it to be solid and stable. It'll use quite a few different backends includeing BIND zone files, but its claim to fame is that it uses mysql. a list of different backends can be found at: http://en.wikipedia.org/wiki/PowerDNS#Backends I saw bind and bind2, db2, geo, gmysql, gpgsql, goracle, gsqlite, ldap, odbc, opendbx, pipe and xdb. Pipe is interesting because you can write a backend in anything that talks to anything. There is documentation and examples on the website. The "g" stands for generic. I've been using poweradmin for management. register.com and tucows both use it. Cheers, Curtis Ben Matthew wrote: > Thanks very much for the various responses to my question; both on and off-list. > > I'm very much liking the idea of only letting the outside world see bind and then AXFR'ing the data from an easier-to-manage internal database backed solution. Whether that be myDNS, Microsoft or whatever. Bit of initial config work and then, in theory, an easy job to administer. > > Actually feel a bit dumb for not considering that in the first place. > > Cheers again, > > Ben > > > -----Original Message----- > From: Peter Hicks [mailto:peter.hicks at poggs.co.uk] > Sent: 01 June 2009 12:42 > To: Ben Matthew > Cc: nanog at nanog.org > Subject: Re: In a bit of bind... > > Ben, > > Ben Matthew wrote: > >> I have six servers in total, two multi-homed servers for ordinary DNS and four servers running an Anycast network (2 x master and slave). >> >> > For DNS, you may find it easier to outsource hosting to another provider > who has geographically diverse DNS services. This doesn't necessarily > mean loss of control. It also separates your nameserver hosting from > your servers - suppose your network were to be under attack, or a > configuration error dropped you offline. If DNS were somewhere else, > you could log in, change A records, point somewhere else. > >> Anyway I've recently been investigating other options for DNS as, like many companies currently, we've laid off a bunch of staff and the overhead for maintaining BIND is quite high if done, like us, unassisted and you are editing zone files in a text editor. >> >> > Revision control systems - CVS, Subversion - are your friend here. What > about wrapping up your DNS change procedure through perl or shell > scripts which automatically roll back if bind doesn't reload, or some > critical hosts suddenly disappear from the file. > > Also, ask yourself what the cost of operating the service without > changes is, and what the cost of each change is. How often are you > making changes? How often do you need to make a change in an absolute > emergency? If changes are being done frequently, a technical or > semi-technical member of staff will get to know the procedure. If > changes are being made rarely, can the changes wait for you to apply > them if you don't feel comfortable with others doing it? > >> Ultimately for our simple zones (non-Anycast, basic web forwarders) I want to create a web-app to do this for me, probably in PHP. I could create something that... >> > Herein lies a problem - you want to create a web front-end to a DNS > server. You're going to have to do a lot of testing to make this play > nicely, and you could introduce your own security holes or gotchas. > What is the cost of creating something yourself? > > How about one of the following? > > * Outsource DNS hosting, use another provider's interface to manage > * BIND9 slaves, Windows-based master (hidden) which already has a GUI > and it isn't difficult to change zones > * Stick to what you have and document it, wrapping the 'apply' process > in some simple shell or perl > > > > Peter > > > ________________________________________________ > DISCLAIMER > This e-mail message, including any attachments, is intended solely for the use of the addressee and may contain confidential information. If it is not intended for you, please inform the sender and delete the e-mail and any attachments immediately. Any review, retransmission, disclosure, copying or modification of it is strictly forbidden. Please be advised that the views and opinions expressed in this e-mail may not reflect the views and opinions of TIML Radio Limited or any of its parent and subsidiary companies. > Whilst we take reasonable precautions to ensure that our emails are free from viruses, we cannot be responsible for any viruses transmitted with this e-mail and recommend that you subject any incoming e-mail to your own virus checking procedures. Use of this or any other e-mail facility signifies consent to any interception we might lawfully carry out to prevent abuse of these facilities. > ________________________________________________ > TIML Radio Limited (trading as Absolute Radio) > Registered office: One Golden Square, London. W1F 9DJ > Registered in England No 02674136 VAT No 927 2572 11 > > > > > From aaron at wholesaleinternet.net Mon Jun 1 15:04:25 2009 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Mon, 1 Jun 2009 15:04:25 -0500 Subject: AOL Postmaster In-Reply-To: References: <0e3201c9e2d8$b466f770$1d34e650$@com> Message-ID: <0e5b01c9e2f4$29874bc0$7c95e340$@net> Yes. For the last 2 months I've been getting the nice auto reply/ticket number but no other contact. Aaron -----Original Message----- From: Mike Walter [mailto:mwalter at 3z.net] Sent: Monday, June 01, 2009 12:23 PM To: nanog at nanog.org Subject: RE: AOL Postmaster Have you been through http://postmaster.aol.com/? Mike -----Original Message----- From: Aaron Wendel [mailto:aaron at wholesaleinternet.com] Sent: Monday, June 01, 2009 12:48 PM To: nanog at nanog.org Subject: AOL Postmaster Is anyone from AOL lurking on the list that could contact me of-list? I'm having some issues with mail being rejected because AOL believes our IPs are dynamic. Aaron From daryl at introspect.net Mon Jun 1 16:43:22 2009 From: daryl at introspect.net (Daryl G. Jurbala) Date: Mon, 1 Jun 2009 17:43:22 -0400 Subject: In a bit of bind... In-Reply-To: <4A242005.4050608@xyonet.com> References: <4A23BE84.5030404@poggs.co.uk> <4A242005.4050608@xyonet.com> Message-ID: On Jun 1, 2009, at 2:37 PM, Curtis Maurand wrote: > > I've been using powerdns for quite a while and I've found it to be > solid and stable. It'll use quite a few different backends > includeing BIND zone files, but its claim to fame is that it uses > mysql. > > a list of different backends can be found at: http://en.wikipedia.org/wiki/PowerDNS#Backends > > I saw bind and bind2, db2, geo, gmysql, gpgsql, goracle, gsqlite, > ldap, odbc, opendbx, pipe and xdb. Pipe is interesting because you > can write a backend in anything that talks to anything. There is > documentation and examples on the website. The "g" stands for > generic. > > I've been using poweradmin for management. > We've been using it as well in what I would consider a very small setup: 150 domains, most with almost no traffic to speak of, but 3 or 4 with decent traffic (the high traffic ones serving over 50k end-user CPE for VoIP traffic with very short TTLs ). The MySQL back-end really is a claim to fame - it makes administration really easy to integrate into whatever you want. We have also been using poweradmin for basic management for things not under programmatic MySQL management. It's basic and a bit kludgy, but definitely adequate, and easy enough to hack into your own idea of what it should be. Daryl From charles at thewybles.com Mon Jun 1 17:40:31 2009 From: charles at thewybles.com (Charles Wyble) Date: Mon, 01 Jun 2009 15:40:31 -0700 Subject: Fiber cut - response in seconds? Message-ID: <4A2458DF.1090101@thewybles.com> http://www.washingtonpost.com/wp-dyn/content/article/2009/05/30/AR2009053002114_pf.html Not sure if I fully believe the article. Responding to a fiber cut in seconds? I suppose it's possible if $TLA had people monitoring the construction from across the street, and they were in communication with the NOC. From wbailey at gci.com Mon Jun 1 17:42:26 2009 From: wbailey at gci.com (Warren Bailey) Date: Mon, 1 Jun 2009 14:42:26 -0800 Subject: Fiber cut - response in seconds? In-Reply-To: <4A2458DF.1090101@thewybles.com> References: <4A2458DF.1090101@thewybles.com> Message-ID: <5B3743FC2D0D8B41B27EE4F5EACA79D10A3BC8DE@DTN1EX01.gci.com> I sent this to all of our transport people to.. Was quite curious as to what they'd use for this. However, they are the federal government - so anything is possible. -----Original Message----- From: Charles Wyble [mailto:charles at thewybles.com] Sent: Monday, June 01, 2009 2:41 PM To: nanog at nanog.org Subject: Fiber cut - response in seconds? http://www.washingtonpost.com/wp-dyn/content/article/2009/05/30/AR200905 3002114_pf.html Not sure if I fully believe the article. Responding to a fiber cut in seconds? I suppose it's possible if $TLA had people monitoring the construction from across the street, and they were in communication with the NOC. From joelja at bogus.com Mon Jun 1 17:46:30 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 01 Jun 2009 15:46:30 -0700 Subject: Fiber cut - response in seconds? In-Reply-To: <4A2458DF.1090101@thewybles.com> References: <4A2458DF.1090101@thewybles.com> Message-ID: <4A245A46.5060109@bogus.com> It's pretty trivial if know where all the construction projects on your path are... I've seen this happen on a university campus several times. no black helicopters were involved. joel Charles Wyble wrote: > http://www.washingtonpost.com/wp-dyn/content/article/2009/05/30/AR2009053002114_pf.html > > > Not sure if I fully believe the article. Responding to a fiber cut in > seconds? > > I suppose it's possible if $TLA had people monitoring the construction > from across the street, and they were in communication with the NOC. > From charles at thewybles.com Mon Jun 1 18:10:05 2009 From: charles at thewybles.com (Charles Wyble) Date: Mon, 01 Jun 2009 16:10:05 -0700 Subject: Fiber cut - response in seconds? In-Reply-To: <4A245A46.5060109@bogus.com> References: <4A2458DF.1090101@thewybles.com> <4A245A46.5060109@bogus.com> Message-ID: <4A245FCD.9050208@thewybles.com> Joel Jaeggli wrote: > It's pretty trivial if know where all the construction projects on your > path are... How so? Setup OTDR traces and watch them? > > I've seen this happen on a university campus several times. no black > helicopters were involved. Care to expand on the methodology used? A campus network is a lot different then a major metro area. From deepak at ai.net Mon Jun 1 18:43:10 2009 From: deepak at ai.net (Deepak Jain) Date: Mon, 01 Jun 2009 19:43:10 -0400 Subject: Fiber cut - response in seconds? In-Reply-To: <4A245FCD.9050208@thewybles.com> References: <4A2458DF.1090101@thewybles.com> <4A245A46.5060109@bogus.com> <4A245FCD.9050208@thewybles.com> Message-ID: <4A24678E.3070003@ai.net> I'm not sure why this sounds so surprising or impressive... given g$vt budgets. Monitoring software using a pair of fibers in your bundle. OTDR or similar digital diagnostics. You detect a loss, you figure out how many feet away it is. You look at your map. A simpler way to do it (if you don't mind burning lots of fiber pairs) would be to loop up a pair of fibers (or add a reflectance source every 1000 ft or so -- spliced into the cable). You can figure out to within a thousand feet once you know WHICH set of loops has died. Given it almost always involved construction crews, you drive until you see backhoes for your final approximation. If I were the gov't I'd have originally opted for #2, and then moved to #1. "Seconds" is just a function of how far away the responding agency's personnel ( monitoring the loop ) were from the cut. Obviously we are talking about a few miles tops. Plenty of people used to have a single pair in each bundle for "testing". Its relatively trivial to make that a test pair live. This is all predicated on you actually keeping your toplogy up-to-date. Deepak Jain AiNET Charles Wyble wrote: > > > Joel Jaeggli wrote: >> It's pretty trivial if know where all the construction projects on your >> path are... > > How so? Setup OTDR traces and watch them? > >> >> I've seen this happen on a university campus several times. no black >> helicopters were involved. > > Care to expand on the methodology used? A campus network is a lot > different then a major metro area. > > > From bonomi at mail.r-bonomi.com Mon Jun 1 19:37:19 2009 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Mon, 1 Jun 2009 19:37:19 -0500 (CDT) Subject: Fiber cut - response in seconds? Message-ID: <200906020037.n520bJvF003068@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Mon Jun 1 18:30:48 2009 > Date: Mon, 01 Jun 2009 15:40:31 -0700 > From: Charles Wyble > To: "nanog at nanog.org" > Subject: Fiber cut - response in seconds? > > http://www.washingtonpost.com/wp-dyn/content/article/2009/05/30/AR2009053002114_pf.html > > Not sure if I fully believe the article. Responding to a fiber cut in > seconds? I *don't* believe it, _as_written_. If one takes 'in seconds' to mean single-digit quantities, they had to be: in the vehicle, with the engine running transmission in gear, starting from within a few hundred feet, with no interfering traffic AND no opposing traffic light. Now, change the 'facts' of the scenario "slightly", and it becomes a bunch more believable. Allow 'double-digit' numbers of seconds, from the time the crew _noticed_ the cut, and it gets a bit less fantastic. Postulate some form of 'damage' to the cable -- maybe a kink, that stretched, but did not sever the cable, or more likely, a pressure rupture in an enclosing safety guard, -- such as a 'near miss' by a back-hoe might cause a few scoops before the cable was completely severed, plus allow for a little time between actual cable severance, and the cut cable becomes _visible_; now you're looking at 5-10 minutes from 'first warning' of a problem at the NOC (with TDR type gear giving approximate location) and the 'rapid response' team on site. They'd have to be on an alert status comparable to the old SAC first alert bomber crews, and probably based within 3-5 miles, but things are now within the realm of beleivability. Not saying I _do_ believe it, but we're into the range of "might, maybe, possibly, happen that way", without having to postulate a TARDUS. I would have expected such a crew to be eqipped with, and need to _use_, 'lights and sirens', and *big* air horns, in dealing with traffic on the roadway -- *AND* I would have expected that 'minor detal' to have been noted by the work crew. As for the last part -- about the billing issue -- assuming that the construction contractor had called JULIE (The undergournd utilities marking service) and gotten the sign-off from all the carriers, they _were_ 'home free'. The carrier who 'failed to mark' their cable gets to pay the cost of replacement. From joelja at bogus.com Mon Jun 1 18:49:22 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 01 Jun 2009 16:49:22 -0700 Subject: Fiber cut - response in seconds? In-Reply-To: <4A245FCD.9050208@thewybles.com> References: <4A2458DF.1090101@thewybles.com> <4A245A46.5060109@bogus.com> <4A245FCD.9050208@thewybles.com> Message-ID: <4A246902.4010705@bogus.com> Charles Wyble wrote: > > > Joel Jaeggli wrote: >> It's pretty trivial if know where all the construction projects on your >> path are... > > How so? Setup OTDR traces and watch them? When you lose link on every pair in a bundle, but don't lose any of the buildings you're serving via diverse paths, you have a pretty good idea what happened. Knowing which of the three construction projects on that path is likely to be digging a trench is a facilities issue. >> >> I've seen this happen on a university campus several times. no black >> helicopters were involved. > > Care to expand on the methodology used? A campus network is a lot > different then a major metro area. Given the location the guys in the blacks suvs likely have at least situational awareness of all of the contruction projects in their immediate vicinity. they don't have to monitor everyone's cable, just their own and near instantaneous response implies proximity so it may well be more akin to a campus network. > From bicknell at ufp.org Mon Jun 1 18:51:11 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 1 Jun 2009 19:51:11 -0400 Subject: Fiber cut - response in seconds? In-Reply-To: <4A2458DF.1090101@thewybles.com> References: <4A2458DF.1090101@thewybles.com> Message-ID: <20090601235111.GA77020@ussenterprise.ufp.org> In a message written on Mon, Jun 01, 2009 at 03:40:31PM -0700, Charles Wyble wrote: > http://www.washingtonpost.com/wp-dyn/content/article/2009/05/30/AR2009053002114_pf.html > > Not sure if I fully believe the article. Responding to a fiber cut in > seconds? Folks who dig call "Miss Utility" (in Virginia, anyway) befor they dig to have folks come out and spray paint where everything is lcoated. On the back end, folks with cables in the ground subscribe to a feed of address information to know if they should go out and mark cables. I have no doubt the men in black SUV's have a feed of this data, and thus know when someone is going to be digging near their cable. Indeed, I can think of at least two instances where I was out surveying fiber digs where black SUV's seemed to be across the street the entire time. With the location having features like a metro tunnel under a US Army "classified" microwave tower it would not surprise me that they have someone in the area watching. I suspect they were waiting nearby, and when it went down went in not to tell folks they cut something, but rather to tell them that they cut nothing. Wink wink. Nudge nudge. -- 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 charles at thewybles.com Mon Jun 1 18:58:21 2009 From: charles at thewybles.com (Charles Wyble) Date: Mon, 01 Jun 2009 16:58:21 -0700 Subject: Fiber cut - response in seconds? In-Reply-To: <4A246902.4010705@bogus.com> References: <4A2458DF.1090101@thewybles.com> <4A245A46.5060109@bogus.com> <4A245FCD.9050208@thewybles.com> <4A246902.4010705@bogus.com> Message-ID: <4A246B1D.6080004@thewybles.com> Joel Jaeggli wrote: > > Charles Wyble wrote: >> >> Joel Jaeggli wrote: >>> It's pretty trivial if know where all the construction projects on your >>> path are... >> How so? Setup OTDR traces and watch them? > > When you lose link on every pair in a bundle, but don't lose any of the > buildings you're serving via diverse paths, you have a pretty good idea > what happened. Knowing which of the three construction projects on that > path is likely to be digging a trench is a facilities issue. Right. So why the "near instant" response time. If it's a diverse path, one would imagine that they could respond in a few hours or a day and not have any impact. The fact that they are so closely monitoring the construction and wanting to fix it that fast seems a bit over the top for redundant systems. > >>> I've seen this happen on a university campus several times. no black >>> helicopters were involved. >> Care to expand on the methodology used? A campus network is a lot >> different then a major metro area. > > Given the location the guys in the blacks suvs likely have at least > situational awareness of all of the contruction projects in their > immediate vicinity. One would hope. Though given the archaic nature of many govt systems, that could involve a lot of manual paper pulling... or are the bid/reward/permit systems all automated on the east coast? :) they don't have to monitor everyone's cable, just > their own and near instantaneous response implies proximity so it may > well be more akin to a campus network. True. From jfesler at gigo.com Mon Jun 1 19:04:10 2009 From: jfesler at gigo.com (Jason Fesler) Date: Mon, 1 Jun 2009 17:04:10 -0700 (PDT) Subject: Fiber cut - response in seconds? In-Reply-To: <4A246B1D.6080004@thewybles.com> References: <4A2458DF.1090101@thewybles.com> <4A245A46.5060109@bogus.com> <4A245FCD.9050208@thewybles.com> <4A246902.4010705@bogus.com> <4A246B1D.6080004@thewybles.com> Message-ID: > The fact that they are so closely monitoring the construction and wanting to > fix it that fast seems a bit over the top for redundant systems. Even despite what we saw recently in the SF bay area? If black helicopters are involved, I suspect this is about par on the paranoia scale. From dave.nanog at alfordmedia.com Mon Jun 1 19:06:30 2009 From: dave.nanog at alfordmedia.com (Dave Pooser) Date: Mon, 01 Jun 2009 19:06:30 -0500 Subject: Fiber cut - response in seconds? In-Reply-To: <4A246B1D.6080004@thewybles.com> Message-ID: > Right. So why the "near instant" response time. If it's a diverse path, > one would imagine that they could respond in a few hours or a day and > not have any impact. Just a guess, but: A cut cable is one thing. A cut cable in which people wearing different suits and driving a different brand of SUV might splice in a fiber tap is something altogether different. -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com From charles at thewybles.com Mon Jun 1 19:17:08 2009 From: charles at thewybles.com (Charles Wyble) Date: Mon, 01 Jun 2009 17:17:08 -0700 Subject: Fiber cut - response in seconds? In-Reply-To: References: Message-ID: <4A246F84.5020504@thewybles.com> I do feel this might be the last post from Mr Pooser. :) Your on to them it seems. ;) A very interesting idea. I imagine it wouldn't be hard for foreign actors to get access to the data feed of construction, observe for signs of a cut and then splice in a tap. Though wouldn't that tap be found via the real response team? Dave Pooser wrote: >> Right. So why the "near instant" response time. If it's a diverse path, >> one would imagine that they could respond in a few hours or a day and >> not have any impact. > > Just a guess, but: A cut cable is one thing. A cut cable in which people > wearing different suits and driving a different brand of SUV might splice in > a fiber tap is something altogether different. From wbailey at gci.com Mon Jun 1 19:28:43 2009 From: wbailey at gci.com (Warren Bailey) Date: Mon, 1 Jun 2009 16:28:43 -0800 Subject: Fiber cut - response in seconds? Message-ID: <5B3743FC2D0D8B41B27EE4F5EACA79D108970F6E@DTN1EX01.gci.com> Its all a sham. The construction was done by the cubans.. They're good at fiber taps ----- Original Message ----- From: Charles Wyble To: nanog at nanog.org Sent: Mon Jun 01 16:17:08 2009 Subject: Re: Fiber cut - response in seconds? I do feel this might be the last post from Mr Pooser. :) Your on to them it seems. ;) A very interesting idea. I imagine it wouldn't be hard for foreign actors to get access to the data feed of construction, observe for signs of a cut and then splice in a tap. Though wouldn't that tap be found via the real response team? Dave Pooser wrote: >> Right. So why the "near instant" response time. If it's a diverse path, >> one would imagine that they could respond in a few hours or a day and >> not have any impact. > > Just a guess, but: A cut cable is one thing. A cut cable in which people > wearing different suits and driving a different brand of SUV might splice in > a fiber tap is something altogether different. From beckman at angryox.com Mon Jun 1 20:22:50 2009 From: beckman at angryox.com (Peter Beckman) Date: Mon, 1 Jun 2009 21:22:50 -0400 Subject: Fiber cut - response in seconds? In-Reply-To: <4A246B1D.6080004@thewybles.com> References: <4A2458DF.1090101@thewybles.com> <4A245A46.5060109@bogus.com> <4A245FCD.9050208@thewybles.com> <4A246902.4010705@bogus.com> <4A246B1D.6080004@thewybles.com> Message-ID: On Mon, 1 Jun 2009, Charles Wyble wrote: > Right. So why the "near instant" response time. Extra budgets, job creation. Knowing ahead of time where and when work is going to be done (easily found out), have someone around the corner at a Starbucks so they can jump into action if/when something goes down. Just because you have a redundant path doesn't mean you shouldn't get the broken path repaired ASAP. Maybe there are only two paths. If the other goes down, and something happens and the Gov't can't mobilize in time, something bad happens. It's a perfect storm to be sure, but when you have the lives of 300 million people at stake, I appreciate the diligence. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From kin-wei.lee at hp.com Mon Jun 1 22:29:16 2009 From: kin-wei.lee at hp.com (Lee, Steven (NSG Malaysia)) Date: Tue, 2 Jun 2009 03:29:16 +0000 Subject: How to measure network equipment usage effectiveness? Message-ID: <084962C061414240A0CDB4BE328A9B2D11A24CC6D6@GVW1100EXC.americas.hpqcorp.net> Hi all, may I know how you guys measure the network equipment usage effectiveness? In what situation you will buy new network equipment instead of using the existing equipment? Any clue to share? Should we only upgrade/replace the equipment once the max PPS is reached? Is there any tools other there can measure this? Regards, Steven Lee From Valdis.Kletnieks at vt.edu Mon Jun 1 23:07:55 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 02 Jun 2009 00:07:55 -0400 Subject: How to measure network equipment usage effectiveness? In-Reply-To: Your message of "Tue, 02 Jun 2009 03:29:16 -0000." <084962C061414240A0CDB4BE328A9B2D11A24CC6D6@GVW1100EXC.americas.hpqcorp.net> References: <084962C061414240A0CDB4BE328A9B2D11A24CC6D6@GVW1100EXC.americas.hpqcorp.net> Message-ID: <97156.1243915675@turing-police.cc.vt.edu> On Tue, 02 Jun 2009 03:29:16 -0000, "Lee, Steven (NSG Malaysia)" said: > Hi all, may I know how you guys measure the network equipment usage > effectiveness? (...) Is there any tools other there can measure this? Step 0: Define "effectiveness". The problem is that quite often, decisions on whether to buy now or later are driven by non-network issues like budget and cash flow, which can't be measured by any network monitoring tools. For instance, I have a high-visibility project that demonstrated the ability to fully saturate a 1GigE port (if you can't design a file server that can flood a 1Gig port, you're in the wrong business :). The design called for multiple 10GigE. But when I'll actually *get* the ports depends on a different internal group, and they have to trade off things like "Do we spend Fiscal 2008 money we're low on to get this project going *now*, or wait a few weeks and spend Fiscal 2009 money?" and "Do we buy a very limited amount of 10GigE gear for piloting this project but possibly find it doesn't fit in our long-term 10Gig plans, or delay the port provisioning until we know what we're doing long term?". If anybody has a tool that handles *those* questions, feel free to let me know. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From jcdill.lists at gmail.com Mon Jun 1 23:25:12 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Mon, 01 Jun 2009 21:25:12 -0700 Subject: Fiber cut - response in seconds? In-Reply-To: <4A246902.4010705@bogus.com> References: <4A2458DF.1090101@thewybles.com> <4A245A46.5060109@bogus.com> <4A245FCD.9050208@thewybles.com> <4A246902.4010705@bogus.com> Message-ID: <4A24A9A8.5090708@gmail.com> Joel Jaeggli wrote: > Given the location the guys in the blacks suvs likely have at least > situational awareness of all of the contruction projects in their > immediate vicinity. This has to be the most backwards way of dealing with this problem. They know exactly where the construction is taking place - the plans are filed with the local municipality and all the relevant agencies have access. Why do they "watch" and "monitor" rather than proactively go out and say "watch out, there's an unmarked cable here" and keep them from cutting the cable in the first place? If these cables are THAT important, I'd think it would be critical to keep them from getting cut in the first place, rather than rushing out to fix them "within 24 hours". They could send guys out in white jumpsuits and hard hats and the backhoe operators would just assume it was normal bureaucracy at work (oops, we forgot to mark those cables on your map) rather than sooper sekrit black fiber that no one is supposed to know about - until they cut into it and the black SUVs show up and then they DO know about it - more than they need to know. jc From dennis at thenose.net Tue Jun 2 01:16:45 2009 From: dennis at thenose.net (Dennis Dayman) Date: Tue, 2 Jun 2009 07:16:45 +0100 Subject: AOL Postmaster In-Reply-To: <0e5b01c9e2f4$29874bc0$7c95e340$@net> References: <0e3201c9e2d8$b466f770$1d34e650$@com> <0e5b01c9e2f4$29874bc0$7c95e340$@net> Message-ID: <617BD1CC-E1B5-4DA1-9C21-D6EAE8591AC1@thenose.net> I sent your email to their team. -Dennis On Jun 1, 2009, at June 1,9:04 PM, Aaron Wendel wrote: > Yes. For the last 2 months I've been getting the nice auto reply/ > ticket > number but no other contact. > > Aaron > > > -----Original Message----- > From: Mike Walter [mailto:mwalter at 3z.net] > Sent: Monday, June 01, 2009 12:23 PM > To: nanog at nanog.org > Subject: RE: AOL Postmaster > > Have you been through http://postmaster.aol.com/? > > Mike > > -----Original Message----- > From: Aaron Wendel [mailto:aaron at wholesaleinternet.com] > Sent: Monday, June 01, 2009 12:48 PM > To: nanog at nanog.org > Subject: AOL Postmaster > > Is anyone from AOL lurking on the list that could contact me of-list? > I'm > having some issues with mail being rejected because AOL believes our > IPs > are > dynamic. > > Aaron > > > > > > > From elmi at 4ever.de Tue Jun 2 01:59:55 2009 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 2 Jun 2009 08:59:55 +0200 Subject: Fiber cut - response in seconds? In-Reply-To: <4A24A9A8.5090708@gmail.com> References: <4A2458DF.1090101@thewybles.com> <4A245A46.5060109@bogus.com> <4A245FCD.9050208@thewybles.com> <4A246902.4010705@bogus.com> <4A24A9A8.5090708@gmail.com> Message-ID: <20090602065955.GB6911@ronin.4ever.de> jcdill.lists at gmail.com (JC Dill) wrote: > Why do they "watch" and "monitor" rather than proactively go > out and say "watch out, there's an unmarked cable here" and keep them > from cutting the cable in the first place? *snicker* You ever been to a construction site? From gb10hkzo-nanog at yahoo.co.uk Tue Jun 2 04:14:43 2009 From: gb10hkzo-nanog at yahoo.co.uk (gb10hkzo-nanog at yahoo.co.uk) Date: Tue, 2 Jun 2009 02:14:43 -0700 (PDT) Subject: In a bit of bind... In-Reply-To: References: Message-ID: <76750.97661.qm@web24707.mail.ird.yahoo.com> Hi, I have not been following this thread too closely, but I spotted the last poster talking about a database backend to DNS. There are some interesting thoughts on the matter in a Nominet Blog Post here : http://blog.nominet.org.uk/tech/2008/06/02/nameservers-and-very-large-zones/ From graeme at graemef.net Tue Jun 2 04:37:23 2009 From: graeme at graemef.net (Graeme Fowler) Date: Tue, 02 Jun 2009 10:37:23 +0100 Subject: In a bit of bind... In-Reply-To: References: <4A23BE84.5030404@poggs.co.uk> Message-ID: <1243935443.16885.9.camel@squonk.lboro.ac.uk> Once upon a time, whilst working for a fairly well-known UK domain registration company, I put together a system built on an early version of the BIND-DLZ patchset against BIND 9.2.5 (If I recall correctly). It used MySQL as the backend database (because that's what the registration system used for CRM purposes) and worked very nicely, thankyou, for well in excess of a million zones and a query rate which I forget but was of the order of several thousand per second, maybe higher at times. We had a custom-written web management toolbox, part of which was exposed to customers through their control panel so they could manage their zones by themselves. The "frontend" nameservers - those actually answering queries - had a "read only" one-way replicated copy of the tables being managed by the CRM system, so all changes were near instantaneous. Copious caching options and indexing in MySQL gave the DB pretty good performance. The frontend servers themselves were load balanced and fault-tolerant and in theory at least a single machine could handle the overall system load. Unfortunately, after I moved on from that job the system broke in some spectacular way (I don't know why) and has since been significantly changed from the original spec, but I couldn't say how... DLZ worked for us - but the DB and management tools were built "in house"; I don't think there's an ideal off-the-shelf solution built around it (yet). Graeme From vixie at isc.org Tue Jun 2 04:42:12 2009 From: vixie at isc.org (Paul Vixie) Date: Tue, 02 Jun 2009 09:42:12 +0000 Subject: White House net security paper In-Reply-To: (Randy Bush's message of "Mon\, 01 Jun 2009 16\:41\:50 +0900") References: <200905312247190.32BF5B92.5704@clifden.donelan.com> <20090601032343.GF21477@skywalker.creative.net.au> Message-ID: Randy Bush writes: >> ... a few battalions of B's and C's, if wisely deployed, could bridge >> that gap. > > there is a reason Bs and Cs have spare round-tuits. > > fred brooks was no fool. os/360 taught some of us some lessons. > batallions work in the infantry, or so i am told. this is rocket > science. to me "wisely" means backfilling 80% of what the Good Guys do that isn't rocket science. (most A's are not doing only what only A's can do.) -- Paul Vixie KI6YSY From pshem.k at gmail.com Tue Jun 2 05:04:56 2009 From: pshem.k at gmail.com (Pshem Kowalczyk) Date: Tue, 2 Jun 2009 22:04:56 +1200 Subject: Huawei cx300 In-Reply-To: References: Message-ID: <20fe625b0906020304t522a3303n8d7bff0b529cf48a@mail.gmail.com> HI, As far as I understand CX300 does not support vpls (only point-to-point PWE3). I don't think that's even on the road map. kind regards Pshem 2009/5/29 Jack Kohn : > Guys, > > Anybody any experience with VPLS on Huawei cx300? > > Jack > From richard.wilson at senokian.com Tue Jun 2 07:50:15 2009 From: richard.wilson at senokian.com (Dave Wilson) Date: Tue, 02 Jun 2009 13:50:15 +0100 Subject: Fiber cut - response in seconds? In-Reply-To: <4A246F84.5020504@thewybles.com> References: <4A246F84.5020504@thewybles.com> Message-ID: <4A252007.4070809@senokian.com> Charles Wyble wrote: > I do feel this might be the last post from Mr Pooser. :) > > Your on to them it seems. ;) > > A very interesting idea. I imagine it wouldn't be hard for foreign > actors to get access to the data feed of construction, observe for signs > of a cut and then splice in a tap. > > Though wouldn't that tap be found via the real response team? > No. And here's why: If you're a naughty foreign intelligence team, and you know your stuff, you already know where some of the cables you'd really like a tap on are buried. When you hear of a construction project that might damage one, you set up your innocuous white panel truck somewhere else, near a suitable manhole. When the construction guy with a backhoe chops the cable (and you may well slip him some money to do so), *then* you put your tap in, elsewhere, with your actions covered by the downtime at the construction site. That's why the guys in the SUVs are in such a hurry, because they want to close the window of time in which someone can be tapping the cable elsewhere. At least that's what I heard. I read it somewhere on the internet. Definitely. Not at all a sneaky person. No sir. Dave W At least I'm in Britain. *Slightly* harder for the NSA to make me disappear ;-) From martin at theicelandguy.com Tue Jun 2 08:19:01 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Tue, 2 Jun 2009 09:19:01 -0400 Subject: Fiber cut - response in seconds? In-Reply-To: <4A2458DF.1090101@thewybles.com> References: <4A2458DF.1090101@thewybles.com> Message-ID: On Mon, Jun 1, 2009 at 6:40 PM, Charles Wyble wrote: > > http://www.washingtonpost.com/wp-dyn/content/article/2009/05/30/AR2009053002114_pf.html > > Not sure if I fully believe the article. Responding to a fiber cut in > seconds? > > I suppose it's possible if $TLA had people monitoring the construction from > across the street, and they were in communication with the NOC. > > Dig Safe, Miss Utility, etc. notify potential dig impacted entities when activity is occurring around their assets and coordinate the marking of the utilities and start of construction in proximity to the targeted dig zone. This is why calling the state utility locator services is the law (everywhere that I'm aware of). The government isn't exempt from these notifications FWIW. The programs may have a slight tweak in the national capitol area. http://www.ncs.gov/ Best, -M< -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From jared at puck.nether.net Tue Jun 2 08:26:14 2009 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 2 Jun 2009 09:26:14 -0400 Subject: Fiber cut - response in seconds? In-Reply-To: References: <4A2458DF.1090101@thewybles.com> Message-ID: On Jun 2, 2009, at 9:19 AM, Martin Hannigan wrote: > On Mon, Jun 1, 2009 at 6:40 PM, Charles Wyble > wrote: > >> >> http://www.washingtonpost.com/wp-dyn/content/article/2009/05/30/AR2009053002114_pf.html >> >> Not sure if I fully believe the article. Responding to a fiber cut in >> seconds? >> >> I suppose it's possible if $TLA had people monitoring the >> construction from >> across the street, and they were in communication with the NOC. >> >> > Dig Safe, Miss Utility, etc. notify potential dig impacted entities > when > activity is occurring around their assets and coordinate the marking > of the > utilities and start of construction in proximity to the targeted dig > zone. > This is why calling the state utility locator services is the law > (everywhere that I'm aware of). The government isn't exempt from these > notifications FWIW. The programs may have a slight tweak in the > national > capitol area. > > http://www.ncs.gov/ What you're likely interested in is TSP: http://tsp.ncs.gov/ This is something that is placed on your service when it's ordered and alters the design and engineering of the services. - Jared From jcdill.lists at gmail.com Tue Jun 2 09:44:40 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Tue, 02 Jun 2009 07:44:40 -0700 Subject: Fiber cut - response in seconds? In-Reply-To: <20090602065955.GB6911@ronin.4ever.de> References: <4A2458DF.1090101@thewybles.com> <4A245A46.5060109@bogus.com> <4A245FCD.9050208@thewybles.com> <4A246902.4010705@bogus.com> <4A24A9A8.5090708@gmail.com> <20090602065955.GB6911@ronin.4ever.de> Message-ID: <4A253AD8.8020209@gmail.com> Elmar K. Bins wrote: > jcdill.lists at gmail.com (JC Dill) wrote: > > >> Why do they "watch" and "monitor" rather than proactively go >> out and say "watch out, there's an unmarked cable here" and keep them >> from cutting the cable in the first place? >> > > *snicker* > > You ever been to a construction site? > Yes. We have a number here to call "Before You Dig" and they send people out to mark where underground utilities are. It would be trivially easy for one more set of jump-suited and hard-hat-wearing people to show up during this phase of the project and mark one more line. For the most part the construction teams don't know and don't care who is marking the lines or who is responsible for each, they just want the lines marked (location and type of line - gas, electric, telco) so they can avoid cutting them. In this way the marking team would be "undercover" and the previously unmarked/unmapped line would be No Big Deal. When an unmarked line is cut and black SUVs show up (the opposite of "undercover"), the line becomes A Big Deal which is the opposite of what is intended. jc From sronan at fattoc.com Tue Jun 2 09:50:48 2009 From: sronan at fattoc.com (Shane Ronan) Date: Tue, 2 Jun 2009 10:50:48 -0400 Subject: Fiber cut - response in seconds? In-Reply-To: <4A253AD8.8020209@gmail.com> References: <4A2458DF.1090101@thewybles.com> <4A245A46.5060109@bogus.com> <4A245FCD.9050208@thewybles.com> <4A246902.4010705@bogus.com> <4A24A9A8.5090708@gmail.com> <20090602065955.GB6911@ronin.4ever.de> <4A253AD8.8020209@gmail.com> Message-ID: <1372C662-A521-417A-BB2B-42ABBB43217F@fattoc.com> In my experience they are required not only to mark the line, but to identify it with the initials of the owner. On Jun 2, 2009, at 10:44 AM, JC Dill wrote: > Elmar K. Bins wrote: >> jcdill.lists at gmail.com (JC Dill) wrote: >> >> >>> Why do they "watch" and "monitor" rather than proactively go out >>> and say "watch out, there's an unmarked cable here" and keep them >>> from cutting the cable in the first place? >>> >> >> *snicker* >> >> You ever been to a construction site? >> > Yes. We have a number here to call "Before You Dig" and they send > people out to mark where underground utilities are. It would be > trivially easy for one more set of jump-suited and hard-hat-wearing > people to show up during this phase of the project and mark one more > line. For the most part the construction teams don't know and don't > care who is marking the lines or who is responsible for each, they > just want the lines marked (location and type of line - gas, > electric, telco) so they can avoid cutting them. In this way the > marking team would be "undercover" and the previously unmarked/ > unmapped line would be No Big Deal. When an unmarked line is cut > and black SUVs show up (the opposite of "undercover"), the line > becomes A Big Deal which is the opposite of what is intended. > > jc > > > From martin at theicelandguy.com Tue Jun 2 10:12:31 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Tue, 2 Jun 2009 11:12:31 -0400 Subject: Fiber cut - response in seconds? In-Reply-To: <4A253AD8.8020209@gmail.com> References: <4A2458DF.1090101@thewybles.com> <4A245A46.5060109@bogus.com> <4A245FCD.9050208@thewybles.com> <4A246902.4010705@bogus.com> <4A24A9A8.5090708@gmail.com> <20090602065955.GB6911@ronin.4ever.de> <4A253AD8.8020209@gmail.com> Message-ID: They usually hand out tin foil hats to the dig crew. A clear give away and easy to spot too. Next? On 6/2/09, JC Dill wrote: > Elmar K. Bins wrote: >> jcdill.lists at gmail.com (JC Dill) wrote: >> >> >>> Why do they "watch" and "monitor" rather than proactively go >>> out and say "watch out, there's an unmarked cable here" and keep them >>> from cutting the cable in the first place? >>> >> >> *snicker* >> >> You ever been to a construction site? >> > Yes. We have a number here to call "Before You Dig" and they send > people out to mark where underground utilities are. It would be > trivially easy for one more set of jump-suited and hard-hat-wearing > people to show up during this phase of the project and mark one more > line. For the most part the construction teams don't know and don't > care who is marking the lines or who is responsible for each, they just > want the lines marked (location and type of line - gas, electric, telco) > so they can avoid cutting them. In this way the marking team would be > "undercover" and the previously unmarked/unmapped line would be No Big > Deal. When an unmarked line is cut and black SUVs show up (the opposite > of "undercover"), the line becomes A Big Deal which is the opposite of > what is intended. > > jc > > > > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From martin at theicelandguy.com Tue Jun 2 10:15:59 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Tue, 2 Jun 2009 11:15:59 -0400 Subject: Fiber cut - response in seconds? In-Reply-To: <4A253AD8.8020209@gmail.com> References: <4A2458DF.1090101@thewybles.com> <4A245A46.5060109@bogus.com> <4A245FCD.9050208@thewybles.com> <4A246902.4010705@bogus.com> <4A24A9A8.5090708@gmail.com> <20090602065955.GB6911@ronin.4ever.de> <4A253AD8.8020209@gmail.com> Message-ID: They usually hand out tin foil hats to the dig crew. A clear give away and easy to spot too. Next? On 6/2/09, JC Dill wrote: > Elmar K. Bins wrote: >> jcdill.lists at gmail.com (JC Dill) wrote: >> >> >>> Why do they "watch" and "monitor" rather than proactively go >>> out and say "watch out, there's an unmarked cable here" and keep them >>> from cutting the cable in the first place? >>> >> >> *snicker* >> >> You ever been to a construction site? >> > Yes. We have a number here to call "Before You Dig" and they send > people out to mark where underground utilities are. It would be > trivially easy for one more set of jump-suited and hard-hat-wearing > people to show up during this phase of the project and mark one more > line. For the most part the construction teams don't know and don't > care who is marking the lines or who is responsible for each, they just > want the lines marked (location and type of line - gas, electric, telco) > so they can avoid cutting them. In this way the marking team would be > "undercover" and the previously unmarked/unmapped line would be No Big > Deal. When an unmarked line is cut and black SUVs show up (the opposite > of "undercover"), the line becomes A Big Deal which is the opposite of > what is intended. > > jc > > > > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From beckman at angryox.com Tue Jun 2 10:19:17 2009 From: beckman at angryox.com (Peter Beckman) Date: Tue, 2 Jun 2009 11:19:17 -0400 Subject: Fiber cut - response in seconds? In-Reply-To: <4A253AD8.8020209@gmail.com> References: <4A2458DF.1090101@thewybles.com> <4A245A46.5060109@bogus.com> <4A245FCD.9050208@thewybles.com> <4A246902.4010705@bogus.com> <4A24A9A8.5090708@gmail.com> <20090602065955.GB6911@ronin.4ever.de> <4A253AD8.8020209@gmail.com> Message-ID: On Tue, 2 Jun 2009, JC Dill wrote: >>> Why do they "watch" and "monitor" rather than proactively go out and say >>> "watch out, there's an unmarked cable here" and keep them from cutting the >>> cable in the first place? Because if they DON'T hit the line, it is still a secret. Then again, if they DO hit the line, it's pretty obvious what the line is for and at least one place it runs. I wonder if the Gov't schedules a move of the line once it's operational security is comprimised by an accidental cut. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From morrowc.lists at gmail.com Tue Jun 2 10:30:19 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 2 Jun 2009 11:30:19 -0400 Subject: Fiber cut - response in seconds? In-Reply-To: References: <4A2458DF.1090101@thewybles.com> <4A245A46.5060109@bogus.com> <4A245FCD.9050208@thewybles.com> <4A246902.4010705@bogus.com> <4A24A9A8.5090708@gmail.com> <20090602065955.GB6911@ronin.4ever.de> <4A253AD8.8020209@gmail.com> Message-ID: <75cb24520906020830x3d34fdbfnf1abeff94e38d03d@mail.gmail.com> On Tue, Jun 2, 2009 at 11:19 AM, Peter Beckman wrote: > On Tue, 2 Jun 2009, JC Dill wrote: > >>>> Why do they "watch" and "monitor" rather than proactively go out and say >>>> "watch out, there's an unmarked cable here" and keep them from cutting the >>>> cable in the first place? > > ?Because if they DON'T hit the line, it is still a secret. > > ?Then again, if they DO hit the line, it's pretty obvious what the line is > ?for and at least one place it runs. ?I wonder if the Gov't schedules a > ?move of the line once it's operational security is comprimised by an > ?accidental cut. putting fiber in the ground isn't a quiet task... From elmi at 4ever.de Tue Jun 2 10:44:17 2009 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 2 Jun 2009 17:44:17 +0200 Subject: Fiber cut - response in seconds? In-Reply-To: <1372C662-A521-417A-BB2B-42ABBB43217F@fattoc.com> References: <4A2458DF.1090101@thewybles.com> <4A245A46.5060109@bogus.com> <4A245FCD.9050208@thewybles.com> <4A246902.4010705@bogus.com> <4A24A9A8.5090708@gmail.com> <20090602065955.GB6911@ronin.4ever.de> <4A253AD8.8020209@gmail.com> <1372C662-A521-417A-BB2B-42ABBB43217F@fattoc.com> Message-ID: <20090602154417.GI6911@ronin.4ever.de> sronan at fattoc.com (Shane Ronan) wrote: > In my experience they are required not only to mark the line, but to > identify it with the initials of the owner. Hell yeah - but that's not the point I wanted to make. For any given construction project, the main goal is to build something without destroying something else (unless it's planned to be destroyed). Unfortunately, this goal has to be broken into easy tasks for the people executing the work. And what leaks to them is "dig a hole". They definitely don't care whether they _will_ hit something. They do care after they hit something... (sometimes they'll try to cover up like someone did here; after cutting a whole bunch of fibre trunks, they decided to fill the just-dug hole with a ton of concrete...) From eric at atlantech.net Tue Jun 2 11:05:11 2009 From: eric at atlantech.net (Eric Van Tol) Date: Tue, 2 Jun 2009 12:05:11 -0400 Subject: Fiber cut - response in seconds? In-Reply-To: <4A245FCD.9050208@thewybles.com> References: <4A2458DF.1090101@thewybles.com> <4A245A46.5060109@bogus.com> <4A245FCD.9050208@thewybles.com> Message-ID: <2C05E949E19A9146AF7BDF9D44085B863528D753D7@exchange.aoihq.local> > -----Original Message----- > From: Charles Wyble [mailto:charles at thewybles.com] > Sent: Monday, June 01, 2009 7:10 PM > To: nanog at nanog.org > Subject: Re: Fiber cut - response in seconds? > > > > Joel Jaeggli wrote: > > It's pretty trivial if know where all the construction projects on your > > path are... > > How so? Setup OTDR traces and watch them? > > > > > I've seen this happen on a university campus several times. no black > > helicopters were involved. > > Care to expand on the methodology used? A campus network is a lot > different then a major metro area. Something like Fiber SenSys (http://www.fibersensys.com/) is probably used. Measures miniscule changes in light levels to tell whether or not fiber has been tampered with. As for the response in "seconds", I would have to say that the suits were parked right there watching, assuming the story is true. Not sure if anyone has ever tried to get anywhere in Tysons Corner during roadside construction (or during an afternoon drizzle for that matter), but I can guarantee you that it would be impossible without someone already being stationed onsite. From deepak at ai.net Tue Jun 2 12:21:19 2009 From: deepak at ai.net (Deepak Jain) Date: Tue, 2 Jun 2009 13:21:19 -0400 Subject: Fiber cut - response in seconds? In-Reply-To: <4A252007.4070809@senokian.com> References: <4A246F84.5020504@thewybles.com> <4A252007.4070809@senokian.com> Message-ID: > No. And here's why: If you're a naughty foreign intelligence team, and > you know your stuff, you already know where some of the cables you'd > really like a tap on are buried. When you hear of a construction > project > that might damage one, you set up your innocuous white panel truck > somewhere else, near a suitable manhole. When the construction guy with > a backhoe chops the cable (and you may well slip him some money to do > so), *then* you put your tap in, elsewhere, with your actions covered > by > the downtime at the construction site. That's why the guys in the SUVs > are in such a hurry, because they want to close the window of time in > which someone can be tapping the cable elsewhere. > > At least that's what I heard. I read it somewhere on the internet. > Definitely. Not at all a sneaky person. No sir. And if you were a naughty foreign intelligence team installing a tap, or a bend, or whatever in the fiber contemporaneously with a known cut, you could also reamplify and dispersion compensate for the slight amount of affect your work is having so that when its tested later, the OTDR is blind to your work. Ah, the fun of Paranoia, Inc. Deepak Jain AiNET From martin at theicelandguy.com Tue Jun 2 12:54:44 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Tue, 2 Jun 2009 13:54:44 -0400 Subject: Fiber cut - response in seconds? In-Reply-To: References: <4A246F84.5020504@thewybles.com> <4A252007.4070809@senokian.com> Message-ID: It would also be cheaper to add an additional layer of security with encryption vs. roving teams of gun toting manhole watchers. YMMV, Best! Marty On 6/2/09, Deepak Jain wrote: >> No. And here's why: If you're a naughty foreign intelligence team, and >> you know your stuff, you already know where some of the cables you'd >> really like a tap on are buried. When you hear of a construction >> project >> that might damage one, you set up your innocuous white panel truck >> somewhere else, near a suitable manhole. When the construction guy with >> a backhoe chops the cable (and you may well slip him some money to do >> so), *then* you put your tap in, elsewhere, with your actions covered >> by >> the downtime at the construction site. That's why the guys in the SUVs >> are in such a hurry, because they want to close the window of time in >> which someone can be tapping the cable elsewhere. >> >> At least that's what I heard. I read it somewhere on the internet. >> Definitely. Not at all a sneaky person. No sir. > > And if you were a naughty foreign intelligence team installing a tap, or a > bend, or whatever in the fiber contemporaneously with a known cut, you could > also reamplify and dispersion compensate for the slight amount of affect > your work is having so that when its tested later, the OTDR is blind to your > work. > > Ah, the fun of Paranoia, Inc. > > Deepak Jain > AiNET > > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From charles at thewybles.com Tue Jun 2 12:57:05 2009 From: charles at thewybles.com (Charles Wyble) Date: Tue, 02 Jun 2009 10:57:05 -0700 Subject: Fiber cut - response in seconds? In-Reply-To: References: <4A246F84.5020504@thewybles.com> <4A252007.4070809@senokian.com> Message-ID: <4A2567F1.2000003@thewybles.com> Cheaper? To quote sneakers.... were the united states govt. we don't do that sort of thing. Martin Hannigan wrote: > It would also be cheaper to add an additional layer of security with > encryption vs. roving teams of gun toting manhole watchers. > > YMMV, > > Best! > > Marty > > > > On 6/2/09, Deepak Jain wrote: >>> No. And here's why: If you're a naughty foreign intelligence team, and >>> you know your stuff, you already know where some of the cables you'd >>> really like a tap on are buried. When you hear of a construction >>> project >>> that might damage one, you set up your innocuous white panel truck >>> somewhere else, near a suitable manhole. When the construction guy with >>> a backhoe chops the cable (and you may well slip him some money to do >>> so), *then* you put your tap in, elsewhere, with your actions covered >>> by >>> the downtime at the construction site. That's why the guys in the SUVs >>> are in such a hurry, because they want to close the window of time in >>> which someone can be tapping the cable elsewhere. >>> >>> At least that's what I heard. I read it somewhere on the internet. >>> Definitely. Not at all a sneaky person. No sir. >> And if you were a naughty foreign intelligence team installing a tap, or a >> bend, or whatever in the fiber contemporaneously with a known cut, you could >> also reamplify and dispersion compensate for the slight amount of affect >> your work is having so that when its tested later, the OTDR is blind to your >> work. >> >> Ah, the fun of Paranoia, Inc. >> >> Deepak Jain >> AiNET >> >> > > From Valdis.Kletnieks at vt.edu Tue Jun 2 13:07:41 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 02 Jun 2009 14:07:41 -0400 Subject: Fiber cut - response in seconds? In-Reply-To: Your message of "Tue, 02 Jun 2009 13:54:44 EDT." References: <4A246F84.5020504@thewybles.com> <4A252007.4070809@senokian.com> Message-ID: <223710.1243966061@turing-police.cc.vt.edu> On Tue, 02 Jun 2009 13:54:44 EDT, Martin Hannigan said: > It would also be cheaper to add an additional layer of security with > encryption vs. roving teams of gun toting manhole watchers. Even if encrypted, you can probably do an amazing amount of traffic analysis to tell when something is afoot. Ask any pizzeria near State Dept or Pentagon. ;) (That, plus it's easier to break an encryption if you have gigabytes of data to work with, than if you don't have any data to work with...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From thegameiam at yahoo.com Tue Jun 2 13:16:54 2009 From: thegameiam at yahoo.com (David Barak) Date: Tue, 2 Jun 2009 11:16:54 -0700 (PDT) Subject: Fiber cut - response in seconds? Message-ID: <716626.38228.qm@web31806.mail.mud.yahoo.com> Encryption is insufficient - if you let someone have physical access for a long enough period, they'll eventually crack anything. Encryption makes the period of time longer, but let them try? As regards "roving," we are talking about Tyson's Corner here: that's pretty close (< 5km) to major offices of lots of folks who would care deeply about such matters. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com --- On Tue, 6/2/09, Charles Wyble wrote: > From: Charles Wyble > Subject: Re: Fiber cut - response in seconds? > To: "nanog at nanog.org" > Date: Tuesday, June 2, 2009, 1:57 PM > Cheaper? > > To quote sneakers.... were the united states govt. we don't > do that sort > of thing. > > Martin Hannigan wrote: > > It would also be cheaper to add an additional layer of > security with > > encryption vs. roving teams of gun toting manhole > watchers. > > > > YMMV, > > > > Best! > > > > Marty > > > > > > > > On 6/2/09, Deepak Jain > wrote: > >>> No. And here's why: If you're a naughty > foreign intelligence team, and > >>> you know your stuff, you already know where > some of the cables you'd > >>> really like a tap on are buried. When you hear > of a construction > >>> project > >>> that might damage one, you set up your > innocuous white panel truck > >>> somewhere else, near a suitable manhole. When > the construction guy with > >>> a backhoe chops the cable (and you may well > slip him some money to do > >>> so), *then* you put your tap in, elsewhere, > with your actions covered > >>> by > >>> the downtime at the construction site. That's > why the guys in the SUVs > >>> are in such a hurry, because they want to > close the window of time in > >>> which someone can be tapping the cable > elsewhere. > >>> > >>> At least that's what I heard. I read it > somewhere on the internet. > >>> Definitely. Not at all a sneaky person. No > sir. > >> And if you were a naughty foreign intelligence > team installing a tap, or a > >> bend, or whatever in the fiber contemporaneously > with a known cut, you could > >> also reamplify and dispersion compensate for the > slight amount of affect > >> your work is having so that when its tested later, > the OTDR is blind to your > >> work. > >> > >> Ah, the fun of Paranoia, Inc. > >> > >> Deepak Jain > >> AiNET > >> > >> > > > > > > From joelja at bogus.com Tue Jun 2 13:21:53 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 02 Jun 2009 11:21:53 -0700 Subject: Fiber cut - response in seconds? In-Reply-To: <223710.1243966061@turing-police.cc.vt.edu> References: <4A246F84.5020504@thewybles.com> <4A252007.4070809@senokian.com> <223710.1243966061@turing-police.cc.vt.edu> Message-ID: <4A256DC1.70909@bogus.com> link-layer encryption for sonet/atm quite resistant to traffic analysis... The pipe is full of pdus whether you're using them or not. Valdis.Kletnieks at vt.edu wrote: > On Tue, 02 Jun 2009 13:54:44 EDT, Martin Hannigan said: >> It would also be cheaper to add an additional layer of security with >> encryption vs. roving teams of gun toting manhole watchers. > > Even if encrypted, you can probably do an amazing amount of traffic > analysis to tell when something is afoot. Ask any pizzeria near State Dept > or Pentagon. ;) > > (That, plus it's easier to break an encryption if you have gigabytes of > data to work with, than if you don't have any data to work with...) From charles at thewybles.com Tue Jun 2 13:34:35 2009 From: charles at thewybles.com (Charles Wyble) Date: Tue, 02 Jun 2009 11:34:35 -0700 Subject: Fiber cut - response in seconds? In-Reply-To: <716626.38228.qm@web31806.mail.mud.yahoo.com> References: <716626.38228.qm@web31806.mail.mud.yahoo.com> Message-ID: <4A2570BB.9050203@thewybles.com> David Barak wrote: > Encryption is insufficient - if you let someone have physical access for a long enough period, they'll eventually crack anything. Really? I don't think so. I imagine it would be much more dependent on the amount of computing power the attacker has access to. More encrypted blobs won't help. If that was the case then the various encryption schemes in wide use today would be cracked already. Bad guys can setup networks and blast data through it and have complete access. I don't see them cracking encryption. From thegameiam at yahoo.com Tue Jun 2 13:56:32 2009 From: thegameiam at yahoo.com (David Barak) Date: Tue, 2 Jun 2009 11:56:32 -0700 (PDT) Subject: Fiber cut - response in seconds? Message-ID: <821992.46661.qm@web31804.mail.mud.yahoo.com> --- On Tue, 6/2/09, Charles Wyble wrote: > David Barak wrote: > > Encryption is insufficient - if you let someone have > physical access for a long enough period, they'll eventually > crack anything. > > Really? I don't think so. I imagine it would be much more > dependent on the amount of computing power the attacker has > access to. More encrypted blobs won't help. If that was the > case then the various encryption schemes in wide use today > would be cracked already. Bad guys can setup networks and > blast data through it and have complete access. I don't see > them cracking encryption. Paranoia 101 teaches us that any given encryption approach will eventually fall before a brute-force onslaught of sufficient power and duration[1]. I'm not trying to argue that the attacker in this case could necessarily detect a flaw in the algorithm; rather, they'll get an effectively infinite number of chances to bang against it with no consequences. Once it's cracked, the attacker will *still* have the physical access which is thus compromised, and then has free access to all of the transmissions. Physical security is a prerequisite to all of the other approaches to communication security. Those cases where physical security is presumed to be non-existant have to rely on a lot of out-of-band knowledge for any given method to be resistant to attack, and it's very hard to make use of a connection of that type for regular operations. Pretty much all security eventually boils down to people with firearms saying "don't do that." David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From deepak at ai.net Tue Jun 2 14:20:38 2009 From: deepak at ai.net (Deepak Jain) Date: Tue, 2 Jun 2009 15:20:38 -0400 Subject: Fiber cut - response in seconds? In-Reply-To: <4A2570BB.9050203@thewybles.com> References: <716626.38228.qm@web31806.mail.mud.yahoo.com> <4A2570BB.9050203@thewybles.com> Message-ID: > > Really? I don't think so. I imagine it would be much more dependent on > the amount of computing power the attacker has access to. More > encrypted > blobs won't help. If that was the case then the various encryption > schemes in wide use today would be cracked already. Bad guys can setup > networks and blast data through it and have complete access. I don't > see > them cracking encryption. Without getting into the math involved, Vlad (and others) are correct. This is why there is key migration (regeneration/renegotiation/repudiation) along these multi-gigabit/multi-terabit streams. Your obfuscation strength (I don't care how many digits you have in your key, your cipher, what have you) is computed against the amount of data you are obfuscating. If I am obfuscating 1 byte of data, my math functions do not need to be as large as obfuscating 2^128 bits. There are plenty of non-classified books regarding COMSEC, INFOSEC and all their related interworking bits (even COMINT, SIGINT and HUMINT). Plenty of NANOG folks have been in these communities and that is why they say things that make sense regarding physical and network security. Even if you haven't been in these groups, the non-classified books are sufficiently sophisticated as to give even a layperson a respect for the layers of security (and the discipline behind it) needed to provide even the most minimal level of protection. The h4x0r kids who think magnets on their doorways, tin foil hats, or willy-nilly encryption using their email-exchanged PGP keys are protected are welcome to their sandbox too -- let's just keep it away from those of us who like things that provably work [most of the time ;)]. DJ From charles at thewybles.com Tue Jun 2 14:41:10 2009 From: charles at thewybles.com (Charles Wyble) Date: Tue, 02 Jun 2009 12:41:10 -0700 Subject: Fiber cut - response in seconds? In-Reply-To: <821992.46661.qm@web31804.mail.mud.yahoo.com> References: <821992.46661.qm@web31804.mail.mud.yahoo.com> Message-ID: <4A258056.4060804@thewybles.com> David Barak wrote: > > Paranoia 101 teaches us that any given encryption approach will eventually fall before a brute-force onslaught of sufficient power and duration[1]. Of course. Hence my comment bout the likely hood of success depending on how much computing power they have access to. How much easier does my job get if I have access to thousands of encrypted e-mails vs 1 encrypted e-mail? Once I factor your PKI root private key, your toast. It was my impression that the various algorithms were designed to prevent traffic analysis attacks, or at least vastly reduce there effectiveness, and if some magical corner case is discovered it should be further mitigated by key rotation right? I'm an operations guy, not a math wizard. :) I'm not trying to argue that the attacker in this case could necessarily detect a flaw in the algorithm; rather, they'll get an effectively infinite number of chances to bang against it with no consequences. Once it's cracked, the attacker will *still* have the physical access which is thus compromised, and then has free access to all of the transmissions. Sure. However couldn't they do this in a lab environment? Various botnets give them access to massive amounts of computing power on an ongoing basis. I presume that the folks with sufficient expertise and knowledge to do these attacks use exploits / back doors that ensure continued access to this computing power, which won't be detected/patched by the little tykes doing spamming/phising/data correlation. Then there is the ability to buy a whole lot of specialized number crunching compute gear as well. Granted the US govt has there own (classified) encryption algorithms and as such that can't be replicated in a lab environment and requires access to the physical medium carrying traffic encrypted by said algorithms. > > Physical security is a prerequisite to all of the other approaches to communication security. Those cases where physical security is presumed to be non-existant have to rely on a lot of out-of-band knowledge for any given method to be resistant to attack, and it's very hard to make use of a connection of that type for regular operations. Really? The US Military uses a whole lot of wireless (satellite, ground baed, surface to air) links. Those links can be sniffed (by people with sufficient motivation/funding/gear to do so). They rely on encryption to protect them. From tme at americafree.tv Tue Jun 2 14:52:33 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 2 Jun 2009 15:52:33 -0400 Subject: Fiber cut - response in seconds? In-Reply-To: <4A258056.4060804@thewybles.com> References: <821992.46661.qm@web31804.mail.mud.yahoo.com> <4A258056.4060804@thewybles.com> Message-ID: <35E2E43B-15A3-4716-BC58-9A67F2EEECD4@americafree.tv> On Jun 2, 2009, at 3:41 PM, Charles Wyble wrote: > > > David Barak wrote: >> Paranoia 101 teaches us that any given encryption approach will >> eventually fall before a brute-force onslaught of sufficient power >> and duration[1]. > > Of course. Hence my comment bout the likely hood of success > depending on how much computing power they have access to. How much > easier does my job get if I have access to thousands of encrypted e- > mails vs 1 encrypted e-mail? Once I factor your PKI root private > key, your toast. Note that most PKI (such as RSA) may be breakable when and if Quantum computers become practical. http://en.wikipedia.org/wiki/Shor's_algorithm Storing large amounts of PKI encrypted data for that day I am sure would interest some organizations. Regards Marshall > It was my impression that the various algorithms were designed to > prevent traffic analysis attacks, or at least vastly reduce there > effectiveness, and if some magical corner case is discovered it > should be further mitigated by key rotation right? I'm an operations > guy, not a math wizard. :) > > I'm not trying to argue that the attacker in this case could > necessarily detect a flaw in the algorithm; rather, they'll get an > effectively infinite number of chances to bang against it with no > consequences. Once it's cracked, the attacker will *still* have the > physical access which is thus compromised, and then has free access > to all of the transmissions. > > Sure. However couldn't they do this in a lab environment? Various > botnets give them access to massive amounts of computing power on an > ongoing basis. I presume that the folks with sufficient expertise > and knowledge to do these attacks use exploits / back doors that > ensure continued access to this computing power, which won't be > detected/patched by the little tykes doing spamming/phising/data > correlation. > > Then there is the ability to buy a whole lot of specialized number > crunching compute gear as well. > > Granted the US govt has there own (classified) encryption algorithms > and as such that can't be replicated in a lab environment and > requires access to the physical medium carrying traffic encrypted by > said algorithms. > > > > > >> Physical security is a prerequisite to all of the other approaches >> to communication security. Those cases where physical security is >> presumed to be non-existant have to rely on a lot of out-of-band >> knowledge for any given method to be resistant to attack, and it's >> very hard to make use of a connection of that type for regular >> operations. > > Really? The US Military uses a whole lot of wireless (satellite, > ground baed, surface to air) links. Those links can be sniffed (by > people with sufficient motivation/funding/gear to do so). They rely > on encryption to protect them. > > > > From michael.holstein at csuohio.edu Tue Jun 2 14:53:07 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Tue, 02 Jun 2009 15:53:07 -0400 Subject: Fiber cut - response in seconds? In-Reply-To: <4A258056.4060804@thewybles.com> References: <821992.46661.qm@web31804.mail.mud.yahoo.com> <4A258056.4060804@thewybles.com> Message-ID: <4A258323.2050305@csuohio.edu> > Granted the US govt has there own (classified) encryption algorithms > and as such that can't be replicated in a lab environment and requires > access to the physical medium carrying traffic encrypted by said > algorithms. Which is why they do things like this : http://en.wikipedia.org/wiki/Operation_Ivy_Bells Of course these days, it doesn't require nearly as much effort .. just a friendly phone call to AT&T (who, ironically, also built the devices used in the above). Cheers, Michael Holstein Cleveland State University From deepak at ai.net Tue Jun 2 15:27:06 2009 From: deepak at ai.net (Deepak Jain) Date: Tue, 2 Jun 2009 16:27:06 -0400 Subject: Fiber cut - response in seconds? In-Reply-To: <4A258056.4060804@thewybles.com> References: <821992.46661.qm@web31804.mail.mud.yahoo.com> <4A258056.4060804@thewybles.com> Message-ID: > Really? The US Military uses a whole lot of wireless (satellite, ground > baed, surface to air) links. Those links can be sniffed (by people with > sufficient motivation/funding/gear to do so). They rely on encryption > to > protect them. Which is why, if you have a satellite, you often position DIRECTLY over the antenna you are sending to, and using lasers (rather than other RF) to communicate with it. Likewise, if you want to maintain this kind of security (and reduce the ability to sniff) you do this in space as well. Highly columnated photons are your friend. Encryption helps, but if it was sufficient in all cases, you wouldn't go to such extremes. This (in a much more NANOG related way) has ramifications for those selling/operating Wi-Fi, WiMax, P2P and FSO wireless links and trying to do *commercially important things* -- like finance. The idea here is that fiber is FAR more secure than copper because almost everything you want to do to fiber, you can do to copper, but from a further, less physically-in-contact distance. Another idea is that commercially operated networks have lower standards for data security (but not necessarily data *integrity*) that intelligence *oriented* applications/networks. The idea of installing a tap on an encrypted line to do traffic analysis is all very interesting, but no one mentioned the idea that at a critical time (such as an attack) you could easily DISRUPT vital communications links and prevent their function [and their protected paths]. Security cannot exist without a level of integrity. Most commercial networks only need to concern themselves with integrity and let their customers deal with the security of their own applications. Commercial networks are a great study of "highly" (in the commercial sense) secure data traversing over LSAs (lower sensitivity areas) with lower control thresholds [think poles, manholes, etc]. The data is highly secure to any particular customer, but in the commercial sense, it's almost always lost in the noise. When a business entity crosses that threshold (e.g. the Federal Reserve banks or a transaction clearinghouse) where their data is *worth* getting at no matter how much sifting has to go on... you see extraordinary measures (e.g. properly implemented obfuscation, or what have you) implemented. Deepak Jain AiNET From dknight at ca.afilias.info Tue Jun 2 15:44:47 2009 From: dknight at ca.afilias.info (Dave Knight) Date: Tue, 2 Jun 2009 16:44:47 -0400 Subject: .ORG is signed Message-ID: <221739EC-8ACC-4E86-9BF1-58A61E16F1AF@ca.afilias.info> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Colleagues, On behalf of PIR Technical Support I would like to announce that as of today, 2009-06-02, at 16:00 UTC .ORG is DNSSEC signed. The following KSK is now valid for .ORG org. IN DNSKEY 257 3 7 ( AwEAAYpYfj3aaRzzkxWQqMdl7YExY81NdYSv+qayuZDo dnZ9IMh0bwMcYaVUdzNAbVeJ8gd6jq1sR3VvP/SR36mm GssbV4Udl5ORDtqiZP2TDNDHxEnKKTX+jWfytZeT7d3A bSzBKC0v7uZrM6M2eoJnl6id66rEUmQC2p9DrrDg9F6t XC9CD/zC7/y+BNNpiOdnM5DXk7HhZm7ra9E7ltL13h2m x7kEgU8e6npJlCoXjraIBgUDthYs48W/sdTDLu7N59rj CG+bpil+c8oZ9f7NR3qmSTpTP1m86RqUQnVErifrH8Kj DqL+3wzUdF5ACkYwt1XhPVPU+wSIlzbaAQN49PU= ) ; key id = 21366 Please note that due to the use of NSEC3 this key should not be used with BIND versions less than 9.6.0. Please refer to http://www.pir.org/dnssec for more information. As always, please report operational concerns with any Afilias-hosted zone to dave - -- Dave Knight Director, Resolution Services Afilias PIR Technical Support URL: http://www.pir.org E-mail: techsupport at pir.org Phone: +1.416.646.3308 Fax: +1.416.646.3305 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkoljz8ACgkQVFeEx/p946ad1ACfRgX0xjsA19jEgv8FC5ol7CME 8qUAoOx39+ZB/GIQj0/qHPnAA843iVqa =stCt -----END PGP SIGNATURE----- From jmamodio at gmail.com Tue Jun 2 15:51:42 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 2 Jun 2009 15:51:42 -0500 Subject: .ORG is signed In-Reply-To: <221739EC-8ACC-4E86-9BF1-58A61E16F1AF@ca.afilias.info> References: <221739EC-8ACC-4E86-9BF1-58A61E16F1AF@ca.afilias.info> Message-ID: <202705b0906021351o62d72278p85a25c3931ce65ec@mail.gmail.com> about time. congrats -j On Tue, Jun 2, 2009 at 3:44 PM, Dave Knight wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Colleagues, > > On behalf of PIR Technical Support I would like to announce that as of > today, 2009-06-02, at 16:00 UTC .ORG is DNSSEC signed. From cmadams at hiwaay.net Tue Jun 2 16:20:42 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 2 Jun 2009 16:20:42 -0500 Subject: Fiber cut - response in seconds? In-Reply-To: References: <821992.46661.qm@web31804.mail.mud.yahoo.com> <4A258056.4060804@thewybles.com> Message-ID: <20090602212042.GF581435@hiwaay.net> Once upon a time, Deepak Jain said: > Which is why, if you have a satellite, you often position DIRECTLY > over the antenna you are sending to Unless your target is on the equator, you don't position a satellite directly over anything. -- 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 Tue Jun 2 17:12:51 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Tue, 2 Jun 2009 17:12:51 -0500 Subject: Fiber cut - response in seconds? In-Reply-To: <4A252007.4070809@senokian.com> References: <4A246F84.5020504@thewybles.com> <4A252007.4070809@senokian.com> Message-ID: <620fd17c0906021512v55d36a0eg975872593ed44510@mail.gmail.com> On Tue, Jun 2, 2009 at 7:50 AM, Dave Wilson wrote: > No. And here's why: If you're a naughty foreign intelligence team, and > you know your stuff, you already know where some of the cables you'd > really like a tap on are buried. When you hear of a construction project > that might damage one, you set up your innocuous white panel truck > somewhere else, near a suitable manhole. When the construction guy with > a backhoe chops the cable (and you may well slip him some money to do > so), *then* you put your tap in, elsewhere, with your actions covered by > the downtime at the construction site. That's why the guys in the SUVs > are in such a hurry, because they want to close the window of time in > which someone can be tapping the cable elsewhere. Sounds like a lot of work to me. Wouldn't it be easier to just find the carrier neutral colo facilities where all the peering/transit between major networks happens, and pay them money to put up a fake wall that you can colo your optical taps behind? Drive Slow, and remember, don't open any doors that say "This Is Not An Exit", Paul Wall From charles at thewybles.com Tue Jun 2 17:28:07 2009 From: charles at thewybles.com (Charles Wyble) Date: Tue, 02 Jun 2009 15:28:07 -0700 Subject: Fiber cut - response in seconds? In-Reply-To: <620fd17c0906021512v55d36a0eg975872593ed44510@mail.gmail.com> References: <4A246F84.5020504@thewybles.com> <4A252007.4070809@senokian.com> <620fd17c0906021512v55d36a0eg975872593ed44510@mail.gmail.com> Message-ID: <4A25A777.9010803@thewybles.com> > Sounds like a lot of work to me. Wouldn't it be easier to just find the carrier > neutral colo facilities where all the peering/transit between major networks > happens, and pay them money to put up a fake wall that you can colo your > optical taps behind? Yeah.... it's not like that's ever gonna happen! :) > > Drive Slow, and remember, don't open any doors that say "This Is Not An Exit", ROFL From deepak at ai.net Tue Jun 2 17:32:01 2009 From: deepak at ai.net (Deepak Jain) Date: Tue, 2 Jun 2009 18:32:01 -0400 Subject: Fiber cut - response in seconds? In-Reply-To: <20090602212042.GF581435@hiwaay.net> References: <821992.46661.qm@web31804.mail.mud.yahoo.com> <4A258056.4060804@thewybles.com> <20090602212042.GF581435@hiwaay.net> Message-ID: > Once upon a time, Deepak Jain said: > > Which is why, if you have a satellite, you often position DIRECTLY > > over the antenna you are sending to > > Unless your target is on the equator, you don't position a satellite > directly over anything. > I promise you that that is not the case for all applications. Geosynchronous satellites can be anywhere. For the applications you are considering (communications mostly), equatorial orbit is the most advantageous. There are books documenting other locations and reasons for other locations... and we are off topic. Best, Deepak Jain AiNET From cmadams at hiwaay.net Tue Jun 2 17:35:57 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 2 Jun 2009 17:35:57 -0500 Subject: Fiber cut - response in seconds? In-Reply-To: References: <821992.46661.qm@web31804.mail.mud.yahoo.com> <4A258056.4060804@thewybles.com> <20090602212042.GF581435@hiwaay.net> Message-ID: <20090602223556.GH581435@hiwaay.net> Once upon a time, Deepak Jain said: > I promise you that that is not the case for all applications. > Geosynchronous satellites can be anywhere. For the applications you > are considering (communications mostly), equatorial orbit is the most > advantageous. Geosynchronous are only over a particular longitude. They move up and down in latitude, so it isn't over a given point except twice per day (or only once at the extremes). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From john at vanoppen.com Tue Jun 2 17:51:59 2009 From: john at vanoppen.com (John van Oppen) Date: Tue, 2 Jun 2009 15:51:59 -0700 Subject: Fiber cut - response in seconds? References: <821992.46661.qm@web31804.mail.mud.yahoo.com><4A258056.4060804@thewybles.com><20090602212042.GF581435@hiwaay.net> <20090602223556.GH581435@hiwaay.net> Message-ID: Ok, while this is off-topic, let's just point people to Wikipedia: Other satellites (which are NOT in the same position at all times from the prospective of a spot on earth): http://en.wikipedia.org/wiki/Geosynchronous_orbit TV, and other fixed positioned (relative to the earth are geostationary): http://en.wikipedia.org/wiki/Geostationary_orbit perhaps further comments can go to the discussion pages on Wikipedia since I would wager a very small number of us push any serious number of bits via satellite. John van Oppen Spectrum Networks LLC Direct: 206.973.8302 Main: 206.973.8300 Website: http://spectrumnetworks.us -----Original Message----- From: Chris Adams [mailto:cmadams at hiwaay.net] Sent: Tuesday, June 02, 2009 3:36 PM To: Deepak Jain Cc: nanog at nanog.org Subject: Re: Fiber cut - response in seconds? Once upon a time, Deepak Jain said: > I promise you that that is not the case for all applications. > Geosynchronous satellites can be anywhere. For the applications you > are considering (communications mostly), equatorial orbit is the most > advantageous. Geosynchronous are only over a particular longitude. They move up and down in latitude, so it isn't over a given point except twice per day (or only once at the extremes). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From wbailey at gci.com Tue Jun 2 17:54:28 2009 From: wbailey at gci.com (Warren Bailey) Date: Tue, 2 Jun 2009 14:54:28 -0800 Subject: Fiber cut - response in seconds? Message-ID: <5B3743FC2D0D8B41B27EE4F5EACA79D108970F72@DTN1EX01.gci.com> I do 250 mbits on 21 transponders :) ----- Original Message ----- From: John van Oppen To: Chris Adams ; Deepak Jain Cc: nanog at nanog.org Sent: Tue Jun 02 14:51:59 2009 Subject: RE: Fiber cut - response in seconds? Ok, while this is off-topic, let's just point people to Wikipedia: Other satellites (which are NOT in the same position at all times from the prospective of a spot on earth): http://en.wikipedia.org/wiki/Geosynchronous_orbit TV, and other fixed positioned (relative to the earth are geostationary): http://en.wikipedia.org/wiki/Geostationary_orbit perhaps further comments can go to the discussion pages on Wikipedia since I would wager a very small number of us push any serious number of bits via satellite. John van Oppen Spectrum Networks LLC Direct: 206.973.8302 Main: 206.973.8300 Website: http://spectrumnetworks.us -----Original Message----- From: Chris Adams [mailto:cmadams at hiwaay.net] Sent: Tuesday, June 02, 2009 3:36 PM To: Deepak Jain Cc: nanog at nanog.org Subject: Re: Fiber cut - response in seconds? Once upon a time, Deepak Jain said: > I promise you that that is not the case for all applications. > Geosynchronous satellites can be anywhere. For the applications you > are considering (communications mostly), equatorial orbit is the most > advantageous. Geosynchronous are only over a particular longitude. They move up and down in latitude, so it isn't over a given point except twice per day (or only once at the extremes). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From ryan at deadfrog.net Tue Jun 2 19:27:46 2009 From: ryan at deadfrog.net (Ryan Wilkins) Date: Tue, 2 Jun 2009 19:27:46 -0500 Subject: Fiber cut - response in seconds? In-Reply-To: <5B3743FC2D0D8B41B27EE4F5EACA79D108970F72@DTN1EX01.gci.com> References: <5B3743FC2D0D8B41B27EE4F5EACA79D108970F72@DTN1EX01.gci.com> Message-ID: Got me beat.. I'm only doing 13 Mbps across 2 transponders. But that's also customer specific and not general Internet access. But one of the antennas that I'm using is inflatable. Seriously. Most people think I'm kidding about the inflatable part. On Jun 2, 2009, at 5:54 PM, Warren Bailey wrote: > I do 250 mbits on 21 transponders :) From jrhett at netconsonance.com Tue Jun 2 21:58:42 2009 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 2 Jun 2009 19:58:42 -0700 Subject: Savvis quality? In-Reply-To: References: Message-ID: <616572B2-5646-4DE0-8C24-1389CDD4799D@netconsonance.com> On May 27, 2009, at 10:35 AM, David Hubbard wrote: > Just wondering if anyone can tell me their > opinion on Savvis bandwidth/company preferably > from a web host perspective. Considering a > connection. I wouldn't touch them with a 10g pole. They were the first and only provider we have dropped for inability to provide reasonable service. 1. They have problems in the bay area (and I've heard other places but I can't confirm) coming up with ports to connect to people on. We had long since outgrown 100mb (was 1g or higher with everyone else) but they couldn't come up with a 1g port to sell us. Then when one became free, they demanded a 700mb commit to get it. After I argued that we never run ports at that level of congestion they backed down to a 500mb commit but that was as low as they'd go. They had no budget to deploy more ports in any of the bay area peering facilities. 2. Their national NOC staff was gut-stripped down to 3 people. 24 hours a day I'd find the same person answering issues we reported. Often outages weren't resolved until they could wake the engineer up. (this isn't surprising in a small company, it's very surprising in a network the size of Savvis) 3. We had repeated issues that needed escalation to our salesperson for credit. We never got calls back on any of these, even when we had escalated through phone, email and paper letters to him. 4. One day they changed the implementation of their community strings to start putting other providers and international customers in their US-Customer-Only community strings. We escalated this issue through management, and the final conclusion was that their community strings advertised to us had to be inconsistent to meet their billing needs. (ie get peers to send them traffic they shouldn't have gotten) We were forced to drop using their community strings and instead build a large complex route-map to determine which traffic should be routed to them. That's nonsense, and was the final straw. In one of the marathon phone calls with the NOC staff about this, a NOC manager frankly told me that Savvis had been stripped and reamed, and they were just trying to stay alive long enough to sell the low- cost carcass to another provider. Yeah, I think that pretty much sums it up. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From sethm at rollernet.us Tue Jun 2 22:37:43 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 02 Jun 2009 20:37:43 -0700 Subject: Savvis quality? In-Reply-To: <616572B2-5646-4DE0-8C24-1389CDD4799D@netconsonance.com> References: <616572B2-5646-4DE0-8C24-1389CDD4799D@netconsonance.com> Message-ID: <4A25F007.5090005@rollernet.us> Jo Rhett wrote: > On May 27, 2009, at 10:35 AM, David Hubbard wrote: >> Just wondering if anyone can tell me their >> opinion on Savvis bandwidth/company preferably >> from a web host perspective. Considering a >> connection. > > > I wouldn't touch them with a 10g pole. They were the first and only > provider we have dropped for inability to provide reasonable service. > > 1. They have problems in the bay area (and I've heard other places but I > can't confirm) coming up with ports to connect to people on. We had > long since outgrown 100mb (was 1g or higher with everyone else) but they > couldn't come up with a 1g port to sell us. Then when one became free, > they demanded a 700mb commit to get it. After I argued that we never > run ports at that level of congestion they backed down to a 500mb commit > but that was as low as they'd go. They had no budget to deploy more > ports in any of the bay area peering facilities. > > 2. Their national NOC staff was gut-stripped down to 3 people. 24 hours > a day I'd find the same person answering issues we reported. Often > outages weren't resolved until they could wake the engineer up. (this > isn't surprising in a small company, it's very surprising in a network > the size of Savvis) > > 3. We had repeated issues that needed escalation to our salesperson for > credit. We never got calls back on any of these, even when we had > escalated through phone, email and paper letters to him. > > 4. One day they changed the implementation of their community strings to > start putting other providers and international customers in their > US-Customer-Only community strings. We escalated this issue through > management, and the final conclusion was that their community strings > advertised to us had to be inconsistent to meet their billing needs. > (ie get peers to send them traffic they shouldn't have gotten) We were > forced to drop using their community strings and instead build a large > complex route-map to determine which traffic should be routed to them. > That's nonsense, and was the final straw. > > In one of the marathon phone calls with the NOC staff about this, a NOC > manager frankly told me that Savvis had been stripped and reamed, and > they were just trying to stay alive long enough to sell the low-cost > carcass to another provider. > > Yeah, I think that pretty much sums it up. > Out of curiosity, how recent was all this? It doesn't really match my experience, however mine isn't very recent. I'm going to be disconnecting my last SAVVIS circuit in a few months so I haven't really tried to do anything new with them. ~Seth From blake at NXS.NET Wed Jun 3 00:04:07 2009 From: blake at NXS.NET (Blake Dunlap) Date: Wed, 3 Jun 2009 00:04:07 -0500 Subject: Savvis quality? In-Reply-To: <616572B2-5646-4DE0-8C24-1389CDD4799D@netconsonance.com> References: <616572B2-5646-4DE0-8C24-1389CDD4799D@netconsonance.com> Message-ID: <6BA3FD54BFAAEE43A4CDED542015999715FF9AF065@bnawsvmsx04.BNA01.ISDN.NET> This is quite similar to experiences we have had with them. Again the only carrier we have dropped for technical reasons. Blake Dunlap > -----Original Message----- > From: Jo Rhett [mailto:jrhett at netconsonance.com] > Sent: Tuesday, June 02, 2009 9:59 PM > To: David Hubbard > Cc: nanog at nanog.org > Subject: Re: Savvis quality? > > On May 27, 2009, at 10:35 AM, David Hubbard wrote: > > Just wondering if anyone can tell me their > > opinion on Savvis bandwidth/company preferably > > from a web host perspective. Considering a > > connection. > > > I wouldn't touch them with a 10g pole. They were the first and only > provider we have dropped for inability to provide reasonable service. > > 1. They have problems in the bay area (and I've heard other places but > I can't confirm) coming up with ports to connect to people on. We had > long since outgrown 100mb (was 1g or higher with everyone else) but > they couldn't come up with a 1g port to sell us. Then when one became > free, they demanded a 700mb commit to get it. After I argued that we > never run ports at that level of congestion they backed down to a > 500mb commit but that was as low as they'd go. They had no budget to > deploy more ports in any of the bay area peering facilities. > > 2. Their national NOC staff was gut-stripped down to 3 people. 24 > hours a day I'd find the same person answering issues we reported. > Often outages weren't resolved until they could wake the engineer up. > (this isn't surprising in a small company, it's very surprising in a > network the size of Savvis) > > 3. We had repeated issues that needed escalation to our salesperson > for credit. We never got calls back on any of these, even when we had > escalated through phone, email and paper letters to him. > > 4. One day they changed the implementation of their community strings > to start putting other providers and international customers in their > US-Customer-Only community strings. We escalated this issue through > management, and the final conclusion was that their community strings > advertised to us had to be inconsistent to meet their billing needs. > (ie get peers to send them traffic they shouldn't have gotten) We > were forced to drop using their community strings and instead build a > large complex route-map to determine which traffic should be routed to > them. That's nonsense, and was the final straw. > > In one of the marathon phone calls with the NOC staff about this, a > NOC manager frankly told me that Savvis had been stripped and reamed, > and they were just trying to stay alive long enough to sell the low- > cost carcass to another provider. > > Yeah, I think that pretty much sums it up. > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source > and other randomness > > > > From drew.weaver at thenap.com Wed Jun 3 07:09:33 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Wed, 3 Jun 2009 05:09:33 -0700 Subject: Facility wide DR/Continuity Message-ID: Hi All, I'm attempting to devise a method which will provide continuous operation of certain resources in the event of a disaster at a single facility. The types of resources that need to be available in the event of a disaster are ecommerce applications and other business critical resources. Some of the questions I keep running into are: Should the additional sites be connected to the primary site (and/or the Internet directly)? What is the best way to handle the routing? Obviously two devices cannot occupy the same IP address at the same time, so how do you provide that instant 'cut-over'? I could see using application balancers to do this but then what if the application balancers fail, etc? Any advice from folks on list or off who have done similar work is greatly appreciated. Thanks, -Drew From rdobbins at arbor.net Wed Jun 3 07:21:26 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 3 Jun 2009 19:21:26 +0700 Subject: Facility wide DR/Continuity In-Reply-To: References: Message-ID: <73D1F342-A33A-45D5-9E9A-B932A8BF2376@arbor.net> On Jun 3, 2009, at 7:09 PM, Drew Weaver wrote: > What is the best way to handle the routing? Obviously two devices > cannot occupy the same IP address at the same time, so how do you > provide that instant 'cut-over'? Avoid 'cut-over' entirely - go active/active/etc., and use DNS-based GSLB for the various system elements. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From rduman at internap.com Wed Jun 3 08:25:43 2009 From: rduman at internap.com (Ricky Duman) Date: Wed, 3 Jun 2009 09:25:43 -0400 Subject: Facility wide DR/Continuity In-Reply-To: References: Message-ID: <1CDD1922EAD45A4FBE5908CE3DA84E58014F3F2D@cx50a.800onemail.com> Drew, IMO as your %Availability goes up, (99, 99.9, 99.99.....100%)... your price to implement will go up exponentially. That being said, a majority of this will depend on what your budget is to achieve your desired availability. You can either - Failover to backup servers using DNS (but may not be instant) Also should consider replication solution if your resources need fresh data On the high-end you can: - run secondary mirror location...replicating data - Setup BGP announcing your IP block out of both locations - You should have a private link interconnecting your sites for your IBGP session. -----Original Message----- From: Drew Weaver [mailto:drew.weaver at thenap.com] Sent: Wednesday, June 03, 2009 8:10 AM To: 'nanog at nanog.org' Subject: Facility wide DR/Continuity Hi All, I'm attempting to devise a method which will provide continuous operation of certain resources in the event of a disaster at a single facility. The types of resources that need to be available in the event of a disaster are ecommerce applications and other business critical resources. Some of the questions I keep running into are: Should the additional sites be connected to the primary site (and/or the Internet directly)? What is the best way to handle the routing? Obviously two devices cannot occupy the same IP address at the same time, so how do you provide that instant 'cut-over'? I could see using application balancers to do this but then what if the application balancers fail, etc? Any advice from folks on list or off who have done similar work is greatly appreciated. Thanks, -Drew From gb10hkzo-nanog at yahoo.co.uk Wed Jun 3 09:27:56 2009 From: gb10hkzo-nanog at yahoo.co.uk (gb10hkzo-nanog at yahoo.co.uk) Date: Wed, 3 Jun 2009 07:27:56 -0700 (PDT) Subject: Facility wide DR/Continuity In-Reply-To: References: Message-ID: <927404.39366.qm@web24706.mail.ird.yahoo.com> On the subject of DNS GSLB, there's a fairly well known article on the subject that anyone considering implementing it should read at least once.... :) http://www.tenereillo.com/GSLBPageOfShame.htm and part 2 http://www.tenereillo.com/GSLBPageOfShameII.htm Yes it was written in 2004. But all the "food for thought" that it provides is still very much applicable today. From herrin-nanog at dirtside.com Wed Jun 3 09:37:40 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Wed, 3 Jun 2009 10:37:40 -0400 Subject: Facility wide DR/Continuity In-Reply-To: References: Message-ID: <3c3e3fca0906030737o523ba301k32f83a9c86c50d6b@mail.gmail.com> On Wed, Jun 3, 2009 at 8:09 AM, Drew Weaver wrote: > I'm attempting to devise a method which will provide continuous >operation of certain resources in the event of a disaster at a single facility. Drew, If you can afford it, stretch the LAN across the facilities via fiber and rebuild the critical services as a load balanced active-active cluster. Then a facility failure and a routine server failure are identical and are handled by the load balancer. F5's if you like commercial solutions, Linux LVS if you're partial to open source as I am. Then make sure you have a Internet entry into each location with BGP. BTW, this tends to make maintenance easier too. Just remove servers from the cluster when you need to work on them and add them back in when you're done. Really reduces the off-hours maintenance windows. This is how I did it when I worked at the DNC and it worked flawlessly. If you can't afford the fiber or need to put the DR site too far away for fiber to be practical, you can still build a network which virtualizes your LAN. However, you then have to worry about issues with the broadcast domain and traffic demand between the clustered servers over the slower WAN. It's doable. I've done it with VPNs over Internet T1's. But you better have your developers on board early and and provide them with a simulated environment so that they can get used to the idea of having little bandwidth between the clustered servers. On Wed, Jun 3, 2009 at 9:25 AM, Ricky Duman wrote: > - Failover to backup servers using DNS (but may not be instant) If your budget is more than a shoestring, save yourself some grief and don't go down this road. Even with the TTLs set to 5 minutes, it takes hours to get to two-nines recovery from a DNS change and months to get to five-nines. The DNS protocol is designed to be able to recover quickly but the applications which use it aren't. Like web browsers. Google "DNS Pinning." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jwise at draga.com Wed Jun 3 09:42:24 2009 From: jwise at draga.com (Jim Wise) Date: Wed, 03 Jun 2009 10:42:24 -0400 Subject: Facility wide DR/Continuity In-Reply-To: <927404.39366.qm@web24706.mail.ird.yahoo.com> (gb10hkzo-nanog@yahoo.co.uk's message of "Wed\, 3 Jun 2009 07\:27\:56 -0700 \(PDT\)") References: <927404.39366.qm@web24706.mail.ird.yahoo.com> Message-ID: <87r5y1750v.fsf@gondolin.draga.com> gb10hkzo-nanog at yahoo.co.uk writes: > On the subject of DNS GSLB, there's a fairly well known article on the > subject that anyone considering implementing it should read at least > once.... :) > > http://www.tenereillo.com/GSLBPageOfShame.htm > and part 2 > http://www.tenereillo.com/GSLBPageOfShameII.htm > > Yes it was written in 2004. But all the "food for thought" that it > provides is still very much applicable today. One thing I've noticed about this paper in the past that kind of bugs me is that in arguing that multiple A records are a better solution than a single GSLB-managed A record, the paper assumes that browsers and other common internet clients will actually cache multiple A records, and fail between them if the earlier A records fail. The (first) of the two pages explicitly touts this as a high availability solution. However, I haven't observed this behavior from browsers, media players, and similar programs `in the wild' -- as far as I've been able to tell, most client software picks an A record from those returned (possibly, but not usually skipping those found to be unreachable), and then holds onto that choice of IP address until the record times out of cache, and a new request is made. Have I been unlucky in my observations? Are there client programs which do failover between multiple A records returned for a single name -- presumably sticking with one IP for session-affinity purposes until a failure is detected? If clients do not behave this way, then the paper's observations about GSLB for HA purposes don't seem to hold -- though in my limited experience the paper's other point (that geographic dispatch is Hard) seems much more accurate (making GSLB a better HA solution than it is a load-sharing solution, again, at least in my experience). Or am I missing something? -- Jim Wise jwise at draga.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 184 bytes Desc: not available URL: From brandon.galbraith at gmail.com Wed Jun 3 09:53:12 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Wed, 3 Jun 2009 09:53:12 -0500 Subject: Facility wide DR/Continuity In-Reply-To: <3c3e3fca0906030737o523ba301k32f83a9c86c50d6b@mail.gmail.com> References: <3c3e3fca0906030737o523ba301k32f83a9c86c50d6b@mail.gmail.com> Message-ID: <366100670906030753v5b7e787we42bda2ffccadea3@mail.gmail.com> On Wed, Jun 3, 2009 at 9:37 AM, William Herrin wrote: > On Wed, Jun 3, 2009 at 8:09 AM, Drew Weaver wrote: > > > > If you can't afford the fiber or need to put the DR site too far away > for fiber to be practical, you can still build a network which > virtualizes your LAN. However, you then have to worry about issues > with the broadcast domain and traffic demand between the clustered > servers over the slower WAN. > > It's doable. I've done it with VPNs over Internet T1's. But you better > have your developers on board early and and provide them with a > simulated environment so that they can get used to the idea of having > little bandwidth between the clustered servers. > > In most cases, the fiber is affordable (a certain bandwidth provider out there offers Layer 2 point to point anywhere on their network for very low four digit prices). We recently put into place an active/active environment with one end point in the US and the other end point in Amsterdam, and both sides see the other as if they were on the same physical lan segment. I've found that, like you said, you *must* have the application developers onboard early, as you can only do so much at the network level without the app being aware. -brandon > > -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From gb10hkzo-nanog at yahoo.co.uk Wed Jun 3 09:53:30 2009 From: gb10hkzo-nanog at yahoo.co.uk (gb10hkzo-nanog at yahoo.co.uk) Date: Wed, 3 Jun 2009 07:53:30 -0700 (PDT) Subject: Facility wide DR/Continuity In-Reply-To: <87r5y1750v.fsf@gondolin.draga.com> References: <927404.39366.qm@web24706.mail.ird.yahoo.com> <87r5y1750v.fsf@gondolin.draga.com> Message-ID: <116413.94510.qm@web24701.mail.ird.yahoo.com> As with all things, there's no "right answer" ..... a lot of it depends on three things : - what you are hoping to achieve - what your budget is - what you have at your disposal in terms of numbers of qualified staff available to both implement and support the chosen solution That's the main business level factors. From a technical level, two key factors (although, of course, there are many others to consider) are : - whether you are after an active/active or active/passive solution - what the underlying application(s) are (e.g. you might have other options such as anycast with DNS) Anyway, there's a lot to consider. And despite all the expertise on Nanog, I would still suggest the original poster does their fair share of their own homework. :) ----- Original Message ---- From: Jim Wise To: gb10hkzo-nanog at yahoo.co.uk Cc: nanog at nanog.org Sent: Wednesday, 3 June, 2009 15:42:24 Subject: Re: Facility wide DR/Continuity gb10hkzo-nanog at yahoo.co.uk writes: > On the subject of DNS GSLB, there's a fairly well known article on the > subject that anyone considering implementing it should read at least > once.... :) > > http://www.tenereillo.com/GSLBPageOfShame.htm > and part 2 > http://www.tenereillo.com/GSLBPageOfShameII.htm > > Yes it was written in 2004. But all the "food for thought" that it > provides is still very much applicable today. One thing I've noticed about this paper in the past that kind of bugs me is that in arguing that multiple A records are a better solution than a single GSLB-managed A record, the paper assumes that browsers and other common internet clients will actually cache multiple A records, and fail between them if the earlier A records fail. The (first) of the two pages explicitly touts this as a high availability solution. However, I haven't observed this behavior from browsers, media players, and similar programs `in the wild' -- as far as I've been able to tell, most client software picks an A record from those returned (possibly, but not usually skipping those found to be unreachable), and then holds onto that choice of IP address until the record times out of cache, and a new request is made. Have I been unlucky in my observations? Are there client programs which do failover between multiple A records returned for a single name -- presumably sticking with one IP for session-affinity purposes until a failure is detected? If clients do not behave this way, then the paper's observations about GSLB for HA purposes don't seem to hold -- though in my limited experience the paper's other point (that geographic dispatch is Hard) seems much more accurate (making GSLB a better HA solution than it is a load-sharing solution, again, at least in my experience). Or am I missing something? -- Jim Wise jwise at draga.com From netfortius at gmail.com Wed Jun 3 10:01:38 2009 From: netfortius at gmail.com (Stefan) Date: Wed, 3 Jun 2009 10:01:38 -0500 Subject: Facility wide DR/Continuity In-Reply-To: References: Message-ID: On Wed, Jun 3, 2009 at 7:09 AM, Drew Weaver wrote: > Hi All, > > I'm attempting to devise a method which will provide continuous operation > of certain resources in the event of a disaster at a single facility. > > The types of resources that need to be available in the event of a disaster > are ecommerce applications and other business critical resources. > > Some of the questions I keep running into are: > > Should the additional sites be connected to the primary site > (and/or the Internet directly)? > What is the best way to handle the routing? Obviously two > devices cannot occupy the same IP address at the same time, so how do you > provide that instant 'cut-over'? I could see using application balancers to > do this but then what if the application balancers fail, etc? > > Any advice from folks on list or off who have done similar work is greatly > appreciated. > > Thanks, > -Drew > > > In an environment where a DR site is deemed critical, it is my experience that critical business applications also have a test or development environment associated with the production one. If you look at the problem this way, then a DR equipped with the test/devel systems, with one "instance" of production always available, would only be challenging in terms of data sync. Various SAN solutions would resolve that (SAN sync-ing over WAN/MAN/etc.). Virtualization of critical systems may also add some benefits here: clone the critical VMs in the DR, and in conjunction with the storage being available, you'll be able to bring up this type of machines in no time - just make sure you have some sort of L2 available - maybe EoS, or tunneling over an L3 connectivity - tons of info when querying for virtual machine mobility and inter-site connectivity. Voice has to be considered, also - f/PSTN - make arrangements with provider to re-route (8xx) in case of disaster. VoIP may add some extra capabilities in terms of reachability over the Internet, in case your DR site cannot accommodate - C/S people, for example, who are critical to interface with customers in case of disaster (if no information - bigger loss - perception issues) have to be able to connect even from home. As far as "immediate" switch from one to another - DNS is the primary concern (unless some wise people have hardcoded IPs all over), but there are other issues people tend to forget, at the core of some clilents - take Oracle "fat" client and its TNS names - I've seen those associated with IPs, instead of host names ... etc. Disclaimer: the above = one of many aspects. Have seen DNS comments already, so I won't repeat those aspects. HTH, -- ***Stefan http://twitter.com/netfortius From rdobbins at arbor.net Wed Jun 3 10:05:34 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 3 Jun 2009 22:05:34 +0700 Subject: Facility wide DR/Continuity In-Reply-To: <3c3e3fca0906030737o523ba301k32f83a9c86c50d6b@mail.gmail.com> References: <3c3e3fca0906030737o523ba301k32f83a9c86c50d6b@mail.gmail.com> Message-ID: <1EAE0E35-A451-496E-9045-50D7629D84BF@arbor.net> On Jun 3, 2009, at 9:37 PM, William Herrin wrote: > If you can afford it, stretch the LAN across the facilities via fiber > and rebuild the critical services as a load balanced active-active > cluster. I would advise strongly against stretching a layer-2 topology across sites, if at all possible - far better to go for layer-3 separation, work with the app/database/sysadmin folks to avoid dependence on direct adjacencies, and gain the topological freedom of routing. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From herrin-nanog at dirtside.com Wed Jun 3 10:05:15 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Wed, 3 Jun 2009 11:05:15 -0400 Subject: Facility wide DR/Continuity In-Reply-To: <116413.94510.qm@web24701.mail.ird.yahoo.com> References: <927404.39366.qm@web24706.mail.ird.yahoo.com> <87r5y1750v.fsf@gondolin.draga.com> <116413.94510.qm@web24701.mail.ird.yahoo.com> Message-ID: <3c3e3fca0906030805h1a7e5c94w205aa7a3f19cac20@mail.gmail.com> On Wed, Jun 3, 2009 at 10:53 AM, wrote: > - whether you are after an active/active or active/passive solution In practice, active/passive DR solutions often fail. You rarely need to fail over to the passive system. When you finally do need to fail over, there are a dozen configuration changes that didn't make it from the active system, so the passive system isn't in a runable state. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From gb10hkzo-nanog at yahoo.co.uk Wed Jun 3 10:13:12 2009 From: gb10hkzo-nanog at yahoo.co.uk (gb10hkzo-nanog at yahoo.co.uk) Date: Wed, 3 Jun 2009 08:13:12 -0700 (PDT) Subject: Facility wide DR/Continuity In-Reply-To: <3c3e3fca0906030805h1a7e5c94w205aa7a3f19cac20@mail.gmail.com> References: <927404.39366.qm@web24706.mail.ird.yahoo.com> <87r5y1750v.fsf@gondolin.draga.com> <116413.94510.qm@web24701.mail.ird.yahoo.com> <3c3e3fca0906030805h1a7e5c94w205aa7a3f19cac20@mail.gmail.com> Message-ID: <82712.41948.qm@web24710.mail.ird.yahoo.com> Tell me about it ...... "failover test.... what failover test" ;-) ----- Original Message ---- From: William Herrin To: gb10hkzo-nanog at yahoo.co.uk Cc: nanog at nanog.org Sent: Wednesday, 3 June, 2009 16:05:15 Subject: Re: Facility wide DR/Continuity On Wed, Jun 3, 2009 at 10:53 AM, wrote: > - whether you are after an active/active or active/passive solution In practice, active/passive DR solutions often fail. You rarely need to fail over to the passive system. When you finally do need to fail over, there are a dozen configuration changes that didn't make it from the active system, so the passive system isn't in a runable state. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rdobbins at arbor.net Wed Jun 3 10:15:49 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 3 Jun 2009 22:15:49 +0700 Subject: Facility wide DR/Continuity In-Reply-To: <3c3e3fca0906030805h1a7e5c94w205aa7a3f19cac20@mail.gmail.com> References: <927404.39366.qm@web24706.mail.ird.yahoo.com> <87r5y1750v.fsf@gondolin.draga.com> <116413.94510.qm@web24701.mail.ird.yahoo.com> <3c3e3fca0906030805h1a7e5c94w205aa7a3f19cac20@mail.gmail.com> Message-ID: On Jun 3, 2009, at 10:05 PM, William Herrin wrote: > You rarely need to fail over to the passive system. And management will never, ever let you do a full-up test, nor will they allow you to spend the money to build a scaled-up system which can handle the full load, because they can't stand the thought of hardware sitting there gathering dust. Concur 100%. Active/passive is an obsolete 35-year-old mainframe paradigm, and it deserves to die the death. With modern technology, there's just really no excuse not to go active/active, IMHO. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From veerunanog at gmail.com Wed Jun 3 10:18:25 2009 From: veerunanog at gmail.com (Veerender Attri) Date: Wed, 3 Jun 2009 11:18:25 -0400 Subject: Issues through ATT core/backbone In-Reply-To: <4A21B056.30600@pdyer.net> References: <1e8e00eb0905282005j7d16fa25j24e4370cd90488a8@mail.gmail.com> <4A21B056.30600@pdyer.net> Message-ID: <1e8e00eb0906030818j15081986lc17f6d95414e95ee@mail.gmail.com> And the Saga continues. We had issues reaching Taiwan through ATT today and no issues if i flip the outbound traffic through Verizon. I called and opened ticket with ATT and it seems like they dont want to help or even look into the issue, its really getting frustrating. These intermittent issues with ATT backbone routing has been going on for more than a week now. It seems their Backbone wont converge for routing issues when they have issues with their peering partners. V On Sat, May 30, 2009 at 6:16 PM, Phil Dyer wrote: > Veerender Attri wrote: > > We have a few circuits with ATT and a few VZ. Since friday we have seen > > serveral intermittent issues throught ATT to reach various customers and > our > > various remote offices. > > [snip] > > > Please chime in if any one else saw similar issues transiting through > AT&T > > or global crossing. > > We have seen some strange routing issues while going through ATT as > well. Couldn't reach our MX office (VPN) for several hours on 2 > occasions last week. The problem was indeed AT&T routing. As we're not a > customer of AT&T, I don't have much more info. > > phil > From gb10hkzo-nanog at yahoo.co.uk Wed Jun 3 10:19:37 2009 From: gb10hkzo-nanog at yahoo.co.uk (gb10hkzo-nanog at yahoo.co.uk) Date: Wed, 3 Jun 2009 08:19:37 -0700 (PDT) Subject: Facility wide DR/Continuity Message-ID: <387598.6103.qm@web24711.mail.ird.yahoo.com> to whoever said ... >F5's if you like commercial solutions F5s if you like expensive commercial solutions ..... Those with a less bulging wallet may wish to speak to the guys at Zeus Technology (http://www.zeus.com/) who have a lot of experience in the area and a more reasonable price tag. Contact me off-list and I can give you some names of senior techies there to speak to. (usual disclaimer that you should research your products .... it may be that for your particular application/environment/business model/whatever F5 may be your tool of choice) From gb10hkzo-nanog at yahoo.co.uk Wed Jun 3 10:20:55 2009 From: gb10hkzo-nanog at yahoo.co.uk (gb10hkzo-nanog at yahoo.co.uk) Date: Wed, 3 Jun 2009 08:20:55 -0700 (PDT) Subject: Facility wide DR/Continuity Message-ID: <40797.86770.qm@web24708.mail.ird.yahoo.com> (by the way ....before the accusations start flying of spamming , no I don't work for Zeus or have any incentive to mention their name... just happen to know their product) From herrin-nanog at dirtside.com Wed Jun 3 10:36:06 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Wed, 3 Jun 2009 11:36:06 -0400 Subject: Facility wide DR/Continuity In-Reply-To: References: <927404.39366.qm@web24706.mail.ird.yahoo.com> <87r5y1750v.fsf@gondolin.draga.com> <116413.94510.qm@web24701.mail.ird.yahoo.com> <3c3e3fca0906030805h1a7e5c94w205aa7a3f19cac20@mail.gmail.com> Message-ID: <3c3e3fca0906030836k5009ce10w77f7183fff76a779@mail.gmail.com> On Wed, Jun 3, 2009 at 11:15 AM, Roland Dobbins wrote: > Active/passive is an obsolete 35-year-old mainframe paradigm, and it > deserves to die the death. ?With modern technology, there's just really no > excuse not to go active/active, IMHO. Roland, Sometimes you're limited by the need to use applications which aren't capable of running on more than one server at a time. In other cases, its obscenely expensive to run an application on more than one server at a time. Nor is the split-brain problem in active/active systems a trivial one. There are still reasons for using active/passive configurations, but be advised that active/active solutions have a noticeably better success rate than active/passive ones. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From sethm at rollernet.us Wed Jun 3 10:38:08 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 03 Jun 2009 08:38:08 -0700 Subject: Facility wide DR/Continuity In-Reply-To: References: <927404.39366.qm@web24706.mail.ird.yahoo.com> <87r5y1750v.fsf@gondolin.draga.com> <116413.94510.qm@web24701.mail.ird.yahoo.com> <3c3e3fca0906030805h1a7e5c94w205aa7a3f19cac20@mail.gmail.com> Message-ID: <4A2698E0.3090207@rollernet.us> Roland Dobbins wrote: > > On Jun 3, 2009, at 10:05 PM, William Herrin wrote: > >> You rarely need to fail over to the passive system. > > > And management will never, ever let you do a full-up test, nor will they > allow you to spend the money to build a scaled-up system which can > handle the full load, because they can't stand the thought of hardware > sitting there gathering dust. > > Concur 100%. > > Active/passive is an obsolete 35-year-old mainframe paradigm, and it > deserves to die the death. With modern technology, there's just really > no excuse not to go active/active, IMHO. > There's always one good reason: money. Some things just don't active/active nicely on a budget. Then you're trying to explain why you want to spend money on a SAN when they really want to spend the money on new "green" refrigerators. (That's not a joke, it really happened.) ~Seth From rdobbins at arbor.net Wed Jun 3 10:40:34 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 3 Jun 2009 22:40:34 +0700 Subject: Facility wide DR/Continuity In-Reply-To: <3c3e3fca0906030836k5009ce10w77f7183fff76a779@mail.gmail.com> References: <927404.39366.qm@web24706.mail.ird.yahoo.com> <87r5y1750v.fsf@gondolin.draga.com> <116413.94510.qm@web24701.mail.ird.yahoo.com> <3c3e3fca0906030805h1a7e5c94w205aa7a3f19cac20@mail.gmail.com> <3c3e3fca0906030836k5009ce10w77f7183fff76a779@mail.gmail.com> Message-ID: On Jun 3, 2009, at 10:36 PM, William Herrin wrote: > Sometimes you're limited by the need to use applications which aren't > capable of running on more than one server at a time. All understood - which is why it's important that app devs/database folks/sysadmins are all part of the virtual team working to uplift legacy siloed OS/app stacks into more modern and flexible architectures. ;> ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From rdobbins at arbor.net Wed Jun 3 10:42:11 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 3 Jun 2009 22:42:11 +0700 Subject: Facility wide DR/Continuity In-Reply-To: <4A2698E0.3090207@rollernet.us> References: <927404.39366.qm@web24706.mail.ird.yahoo.com> <87r5y1750v.fsf@gondolin.draga.com> <116413.94510.qm@web24701.mail.ird.yahoo.com> <3c3e3fca0906030805h1a7e5c94w205aa7a3f19cac20@mail.gmail.com> <4A2698E0.3090207@rollernet.us> Message-ID: On Jun 3, 2009, at 10:38 PM, Seth Mattinen wrote: > Some things just don't active/active nicely on a budget. Sure, because of inefficient legacy design choices. Distribution and scale is ultimately an application architecture issue, with networking and ancillary technologies playing an important supporting role. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From gb10hkzo-nanog at yahoo.co.uk Wed Jun 3 11:15:06 2009 From: gb10hkzo-nanog at yahoo.co.uk (gb10hkzo-nanog at yahoo.co.uk) Date: Wed, 3 Jun 2009 09:15:06 -0700 (PDT) Subject: Facility wide DR/Continuity Message-ID: <688419.31810.qm@web24714.mail.ird.yahoo.com> Some things just don't active/active nicely on a budget. > Sure, because of inefficient legacy design choices. Roland, I'm not sure I understand your argument here. Budget is very much an issue when choosing between active/active and active/passive. Nothing to do with "inefficient legacy design". For example, consider the licensing and hardware costs involved in running something like Oracle Database in active/active mode (in a topology that is supported by Oracle Tech Support). From rdobbins at arbor.net Wed Jun 3 11:59:12 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 3 Jun 2009 23:59:12 +0700 Subject: Facility wide DR/Continuity In-Reply-To: <688419.31810.qm@web24714.mail.ird.yahoo.com> References: <688419.31810.qm@web24714.mail.ird.yahoo.com> Message-ID: On Jun 3, 2009, at 11:15 PM, gb10hkzo-nanog at yahoo.co.uk wrote: > For example, consider the licensing and hardware costs involved in > running something like Oracle Database in active/active mode (in a > topology that is supported by Oracle Tech Support). In my experience, it's no more expensive in terms of hardware/software licensing costs to run active/active, and actually less in terms of opex costs due to issues raised previously in this thread, as well as a host of others. Note that running active/active doesn't necessarily mean doing something like running a clustered database back-end, utilizing vendor- specific HA solutions. It can be done via a combination of caching, sharding, distributed indexing, et. al. - i.e., via application structuring and logic. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From woody at pch.net Wed Jun 3 12:47:13 2009 From: woody at pch.net (Bill Woodcock) Date: Wed, 3 Jun 2009 10:47:13 -0700 (PDT) Subject: Facility wide DR/Continuity In-Reply-To: References: Message-ID: On Wed, 3 Jun 2009, Drew Weaver wrote: > Should the additional sites be connected to the primary site > (and/or the Internet directly)? Yes, because any out-of-band synchronization method between the servers at the production site and the servers at the DR site is likely to be more difficult to manage. You could do UUCP over a serial line, but... > What is the best way to handle the routing? Obviously two devices > cannot occupy the same IP address at the same time, so how do you > provide that instant 'cut-over'? This is one of the only instances in which I like NATs. Set up a NAT between the two sites to do static 1-to-1 mapping of each site into a different range for the other, so that the DR servers have the same IP addresses as their production masters, but have a different IP address to synchronize with. -Bill From brandon.galbraith at gmail.com Wed Jun 3 12:53:17 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Wed, 3 Jun 2009 12:53:17 -0500 Subject: Facility wide DR/Continuity In-Reply-To: References: Message-ID: <366100670906031053l5a65f87dk32441eb38f7233b6@mail.gmail.com> On Wed, Jun 3, 2009 at 12:47 PM, Bill Woodcock wrote: > On Wed, 3 Jun 2009, Drew Weaver wrote: > > Should the additional sites be connected to the primary site > > (and/or the Internet directly)? > > Yes, because any out-of-band synchronization method between the servers at > the production site and the servers at the DR site is likely to be more > difficult to manage. You could do UUCP over a serial line, but... > > > What is the best way to handle the routing? Obviously two devices > > cannot occupy the same IP address at the same time, so how do you > > provide that instant 'cut-over'? > > This is one of the only instances in which I like NATs. Set up a NAT > between the two sites to do static 1-to-1 mapping of each site into a > different range for the other, so that the DR servers have the same IP > addresses as their production masters, but have a different IP address to > synchronize with. > Or you use RFC1918 address space at each location, and NAT each side between public anycasted space and your private IP space. Prevents internal IP conflicts, having to deal with site to site NAT, etc. -brandon -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From rdobbins at arbor.net Wed Jun 3 13:08:51 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 4 Jun 2009 01:08:51 +0700 Subject: Facility wide DR/Continuity In-Reply-To: <366100670906031053l5a65f87dk32441eb38f7233b6@mail.gmail.com> References: <366100670906031053l5a65f87dk32441eb38f7233b6@mail.gmail.com> Message-ID: <447C3E29-9922-4F2D-BA53-B8428933F44A@arbor.net> On Jun 4, 2009, at 12:53 AM, Brandon Galbraith wrote: > Or you use RFC1918 address space at each location, and NAT each side > between > public anycasted space and your private IP space. Prevents internal IP > conflicts, having to deal with site to site NAT, etc. With all due respect, both of these posited choices are quite ugly and tend to lead to huge operational difficulties, susceptibility to DDoS, etc. Definitely not recommended except as a last resort in a difficult situation, IMHO. ----------------------------------------------------------------------- Roland Dobbins // Unfortunately, inefficiency scales really well. -- Kevin Lawton From woody at pch.net Wed Jun 3 13:25:30 2009 From: woody at pch.net (Bill Woodcock) Date: Wed, 3 Jun 2009 11:25:30 -0700 (PDT) Subject: Facility wide DR/Continuity In-Reply-To: <447C3E29-9922-4F2D-BA53-B8428933F44A@arbor.net> References: <366100670906031053l5a65f87dk32441eb38f7233b6@mail.gmail.com> <447C3E29-9922-4F2D-BA53-B8428933F44A@arbor.net> Message-ID: On Thu, 4 Jun 2009, Roland Dobbins wrote: > With all due respect, both of these posited choices are quite ugly and > tend to lead to huge operational difficulties, susceptibility to DDoS, > etc. Definitely not recommended except as a last resort in a difficult > situation, IMHO. I wouldn't go quite so far as to say that they have security implications, but I definitely agree that these are solutions of last resort, and that any live load-balanced solution is infinitely preferable to a stand-by solution. Which, IMHO, is unlikely to ever work as hoped for. I was just answering the question at hand, rather than the meta-question of whether the question being asked was the right question. :-) -Bill From mprice at tqhosting.com Wed Jun 3 15:15:52 2009 From: mprice at tqhosting.com (Mark Price) Date: Wed, 3 Jun 2009 16:15:52 -0400 Subject: VerizonWireless.com contact Message-ID: <61b6fbec0906031315s6e510669x8a69f135057b6597@mail.gmail.com> Does anyone know how to get in touch with someone at Verizon Wireless regarding SMTP? Part of our network seems to be blocked by their MX servers for verizonwireless.com and I can't find any contact info. Thanks, Mark From Bourbon.Odenthal at sce.com Wed Jun 3 15:51:27 2009 From: Bourbon.Odenthal at sce.com (Bourbon.Odenthal at sce.com) Date: Wed, 3 Jun 2009 13:51:27 -0700 Subject: VerizonWireless.com contact Message-ID: Interesting. I've been dealing with this exact problem for a couple of weeks now. Several of our DNS servers, but not all, can not resolve an MX for vtext.com or vtext.biz. Still don't have a resolution and I'm still wading through their support staff trying to find someone with a clue. -BB Odenthal Network Engineer Southern California Edison ----- Original Message ----- From: Mark Price [mprice at tqhosting.com] Sent: 06/03/2009 04:15 PM AST To: nanog at nanog.org Subject: VerizonWireless.com contact Does anyone know how to get in touch with someone at Verizon Wireless regarding SMTP? Part of our network seems to be blocked by their MX servers for verizonwireless.com and I can't find any contact info. Thanks, Mark From mprice at tqhosting.com Wed Jun 3 17:14:42 2009 From: mprice at tqhosting.com (Mark Price) Date: Wed, 3 Jun 2009 18:14:42 -0400 Subject: VerizonWireless.com contact In-Reply-To: References: Message-ID: <61b6fbec0906031514r62c07fa7s3587e431784b589b@mail.gmail.com> Please let me know if you find any clue. The problem I'm having is we can connect to their incoming mail server but it just throws a reject error code with no other info: # telnet mars.verizonwireless.com 25 Trying 162.115.163.69... Connected to mars.verizonwireless.com (162.115.163.69). Escape character is '^]'. 554 venus.verizonwireless.com Connection closed by foreign host. On Wed, Jun 3, 2009 at 4:51 PM, wrote: > Interesting. ?I've been dealing with this exact problem for a couple of weeks now. Several of our DNS servers, but not all, ?can not resolve an MX for vtext.com or vtext.biz. Still don't have a resolution and I'm still wading through their support staff trying to find someone with a clue. > > -BB Odenthal > Network Engineer > Southern California Edison > > > ----- Original Message ----- > From: Mark Price [mprice at tqhosting.com] > Sent: 06/03/2009 04:15 PM AST > To: nanog at nanog.org > Subject: VerizonWireless.com contact > > > > Does anyone know how to get in touch with someone at Verizon Wireless > regarding SMTP? ?Part of our network seems to be blocked by their MX > servers for verizonwireless.com and I can't find any contact info. > > > Thanks, > > Mark > > > -- Mark Price Tranquil Hosting www.tqhosting.com office: 919-459-0134 From lists at memetic.org Wed Jun 3 18:51:13 2009 From: lists at memetic.org (Adam Armstrong) Date: Thu, 04 Jun 2009 00:51:13 +0100 Subject: Cisco 6524 and MTU In-Reply-To: <6bb5f5b10905291740p7dbf3b7eibbaca9b6db07f9cd@mail.gmail.com> References: <5B3743FC2D0D8B41B27EE4F5EACA79D10A3BC54A@DTN1EX01.gci.com> <6bb5f5b10905291740p7dbf3b7eibbaca9b6db07f9cd@mail.gmail.com> Message-ID: <4A270C71.5030409@memetic.org> We have good results carrying >1492 packets across 6524s running both ZU2 and SXI1. I do consider ZU2 to be broken though (ghost route issue). SXI1 behaves well for us. adam. > We use Cisco 6524s with packets up to 1546 bytes with no issues. IOS > ZU2, but we are testing SXI1 with no MTU issues so far. > > > Rubens > > > On Fri, May 29, 2009 at 8:35 PM, Warren Bailey wrote: > >> Has anyone encountered a 6524 dropping packets larger than 1492? IOS >> 12.2(33)SXH2a >> >> Warren Bailey >> GCI Communication Corp. >> RF Network Engineering >> 907.868.5911 office >> 907.903.5410 mobile >> >> >> >> > > From charles at thewybles.com Thu Jun 4 14:42:06 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 04 Jun 2009 12:42:06 -0700 Subject: 3fn shutdown Message-ID: <4A28238E.7040507@thewybles.com> What do folks think? How were they shutdown? AS stopped from announcing? Physical power? http://voices.washingtonpost.com/securityfix/2009/06/ftc_sues_shuts_down_n_calif_we.html From gerry at tape.net Thu Jun 4 14:45:49 2009 From: gerry at tape.net (Gerry Boudreaux) Date: Thu, 4 Jun 2009 14:45:49 -0500 Subject: 3fn shutdown In-Reply-To: <4A28238E.7040507@thewybles.com> References: <4A28238E.7040507@thewybles.com> Message-ID: <7AE59D19-E142-4240-9733-4374F0600DC3@tape.net> On Jun 4, 2009, at 2:42 PM, Charles Wyble wrote: > What do folks think? > > How were they shutdown? AS stopped from announcing? Physical power? > > http://voices.washingtonpost.com/securityfix/2009/06/ftc_sues_shuts_down_n_calif_we.html http://yro.slashdot.org/article.pl?sid=09/06/04/1814201 From michael.holstein at csuohio.edu Thu Jun 4 14:51:55 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Thu, 04 Jun 2009 15:51:55 -0400 Subject: 3fn shutdown In-Reply-To: <4A28238E.7040507@thewybles.com> References: <4A28238E.7040507@thewybles.com> Message-ID: <4A2825DB.5070400@csuohio.edu> > How were they shutdown? AS stopped from announcing? Physical power? From TFA : "3FN's sites were disconnected after a Northern California district court judge approved an FTC request to have the company's upstream Internet providers stop routing Internet traffic for the provider." Cheers, Michael Holstein Cleveland State University From eriks at nationalfastfreight.com Thu Jun 4 15:47:37 2009 From: eriks at nationalfastfreight.com (Erik Soosalu) Date: Thu, 4 Jun 2009 16:47:37 -0400 Subject: OT: ARIN contact Message-ID: <0B224A2FE01CC54C860290D42474BF6003C16E6A@exchange.nff.local> I know this is off-topic, but I know some people from ARIN read this and would appreciate it if someone from ARIN would contact me off-list. Thanks, Erik From randy at psg.com Thu Jun 4 17:48:22 2009 From: randy at psg.com (Randy Bush) Date: Fri, 05 Jun 2009 07:48:22 +0900 Subject: OT: ARIN contact In-Reply-To: <0B224A2FE01CC54C860290D42474BF6003C16E6A@exchange.nff.local> References: <0B224A2FE01CC54C860290D42474BF6003C16E6A@exchange.nff.local> Message-ID: > I know this is off-topic, but I know some people from ARIN read this and > would appreciate it if someone from ARIN would contact me off-list. hostmaster at arin.net did not respond to email? this would be *extremely* unusual. randy From deepak at ai.net Thu Jun 4 17:53:39 2009 From: deepak at ai.net (Deepak Jain) Date: Thu, 4 Jun 2009 18:53:39 -0400 Subject: OT: ARIN contact In-Reply-To: References: <0B224A2FE01CC54C860290D42474BF6003C16E6A@exchange.nff.local> Message-ID: > > I know this is off-topic, but I know some people from ARIN read this > and > > would appreciate it if someone from ARIN would contact me off-list. > > hostmaster at arin.net did not respond to email? this would be > *extremely* > unusual. > 2nd'ed. ARIN is very responsive by email and telephone now. Deepak From randy at psg.com Thu Jun 4 23:38:04 2009 From: randy at psg.com (Randy Bush) Date: Fri, 05 Jun 2009 13:38:04 +0900 Subject: ftc shuts down a colo and ip provider Message-ID: http://voices.washingtonpost.com/securityfix/2009/06/ftc_sues_shuts_down_n_calif_we.html while allegedly a black hat, this is the first case i know of in which the usg has shut down an isp. nose of camel? first they came for ... randy From trelane at trelane.net Thu Jun 4 23:45:13 2009 From: trelane at trelane.net (Andrew D Kirch) Date: Fri, 05 Jun 2009 00:45:13 -0400 Subject: ftc shuts down a colo and ip provider In-Reply-To: References: Message-ID: <4A28A2D9.10408@trelane.net> Randy Bush wrote: > http://voices.washingtonpost.com/securityfix/2009/06/ftc_sues_shuts_down_n_calif_we.html > > while allegedly a black hat, this is the first case i know of in which > the usg has shut down an isp. nose of camel? first they came for ... > > randy > > Foonet. From morrowc.lists at gmail.com Thu Jun 4 23:50:00 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 5 Jun 2009 00:50:00 -0400 Subject: ftc shuts down a colo and ip provider In-Reply-To: <4A28A2D9.10408@trelane.net> References: <4A28A2D9.10408@trelane.net> Message-ID: <75cb24520906042150x1176ab23od7df7dfef627ab28@mail.gmail.com> On Fri, Jun 5, 2009 at 12:45 AM, Andrew D Kirch wrote: > Randy Bush wrote: >> http://voices.washingtonpost.com/securityfix/2009/06/ftc_sues_shuts_down_n_calif_we.html >> >> while allegedly a black hat, this is the first case i know of in which >> the usg has shut down an isp. ?nose of camel? ?first they came for ... >> >> randy >> >> > Foonet. there have been a few other smaller ones, it'd be nice of L3 and Peer1 would also stop routing these folks assets: * 68.233.192.0/24 200.160.127.238 0 27664 16735 12956 3356 i * 68.233.193.0/24 200.160.127.238 0 27664 16735 12956 3356 i * 68.233.194.0/24 200.160.127.238 0 27664 16735 12956 3356 i * 68.233.195.0/24 200.160.127.238 0 27664 16735 12956 3356 i *> 68.233.196.0/24 74.40.7.35 0 0 5650 3561 13768 13768 13768 ? *> 68.233.197.0/24 74.40.7.35 0 0 5650 3561 13768 13768 13768 ? *> 68.233.198.0/24 74.40.7.35 0 0 5650 3561 13768 13768 13768 ? *> 68.233.199.0/24 74.40.7.35 0 0 5650 3561 13768 13768 13768 ? thanks! -Chris From tvhawaii at shaka.com Fri Jun 5 00:02:55 2009 From: tvhawaii at shaka.com (Michael Painter) Date: Thu, 4 Jun 2009 19:02:55 -1000 Subject: ftc shuts down a colo and ip provider References: Message-ID: ----- Original Message ----- From: "Randy Bush" To: "North American Network Operators Group" Sent: Thursday, June 04, 2009 6:38 PM Subject: ftc shuts down a colo and ip provider > http://voices.washingtonpost.com/securityfix/2009/06/ftc_sues_shuts_down_n_calif_we.html > > while allegedly a black hat, this is the first case i know of in which > the usg has shut down an isp. nose of camel? first they came for ... > > randy > I'm curious...what do you think should be done about webhosting providers who do harm to others? http://voices.washingtonpost.com/securityfix/pushdo.htm --Michael From deepak at ai.net Fri Jun 5 00:44:53 2009 From: deepak at ai.net (Deepak Jain) Date: Fri, 5 Jun 2009 01:44:53 -0400 Subject: ftc shuts down a colo and ip provider Message-ID: What does it say about these providers AUP that the FTC needed to go to court to turn them off? The AUP standard is usually written much, much lower. Deepak Deepak ----- Original Message ----- From: Randy Bush To: North American Network Operators Group Sent: Fri Jun 05 00:38:04 2009 Subject: ftc shuts down a colo and ip provider http://voices.washingtonpost.com/securityfix/2009/06/ftc_sues_shuts_down_n_calif_we.html while allegedly a black hat, this is the first case i know of in which the usg has shut down an isp. nose of camel? first they came for ... randy From morrowc.lists at gmail.com Fri Jun 5 00:58:46 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 5 Jun 2009 01:58:46 -0400 Subject: ftc shuts down a colo and ip provider In-Reply-To: References: Message-ID: <75cb24520906042258j3aea47cfl45b3dbe3b89b8dcf@mail.gmail.com> On Fri, Jun 5, 2009 at 1:44 AM, Deepak Jain wrote: > What does it say about these providers AUP that the FTC needed to go to court to turn them off? I hate to re-start the atrivo/intercage/mccolo thread(s) but, often what happens is there just arent any real/usable complaints sent along to the upstream providers. The webhost (aps/3fn in this case) may have avoided most/many of the complaints, over the years, being sent to their upstream(s) or they may have successfully shuffled their links faster than outages could be arranged. If address blocks or customers are shuffled fast enough, or timely enough, it looks like the problem is resolved to an upstream. One trick I've seen used is to re-announce address blocks out differing interfaces such that providers catalog the complaints not against the direct customer but against peers or other customers 'innocents' (possibly). If the upstream providers don't get quality complaints in a format they can use and catalog... nothing is going to change. If the upstreams see no abuse record there is no reason to term a paying customer. With the more criminally minded 'customers', the problem is a lot harder to bring to resolution if you are stuck inside the contracts/laws of your jurisdiction. It behooves the community at large to properly catalog and properly complain about these sorts of things. Saying: "dirty-webhost-X is never going to deal with my complaints so, I stopped sending them there X months|years ago." is not going to resolve the issue(s). Email to abuse@ is 'free' for the sender, almost all complaint generation systems can be automated, almost all complaint acceptance systems can be as well if the complaints come in well formed and with the right information included. -Chris > The AUP standard is usually written much, much lower. > > Deepak > > Deepak > > ----- Original Message ----- > From: Randy Bush > To: North American Network Operators Group > Sent: Fri Jun 05 00:38:04 2009 > Subject: ftc shuts down a colo and ip provider > > http://voices.washingtonpost.com/securityfix/2009/06/ftc_sues_shuts_down_n_calif_we.html > > while allegedly a black hat, this is the first case i know of in which > the usg has shut down an isp. ?nose of camel? ?first they came for ... > > randy > > From web at typo.org Fri Jun 5 02:02:12 2009 From: web at typo.org (Wayne E. Bouchard) Date: Fri, 5 Jun 2009 00:02:12 -0700 Subject: ftc shuts down a colo and ip provider In-Reply-To: References: Message-ID: <20090605070212.GA13772@typo.org> On Fri, Jun 05, 2009 at 01:44:53AM -0400, Deepak Jain wrote: > What does it say about these providers AUP that the FTC needed to go to court to turn them off? > > The AUP standard is usually written much, much lower. > > Deepak It says revenue trumps ethics in far too many instances. Virtually every company out there, regardless of size, has their share of those that some would rather do without but who stick around often because someone with authority is willing to look the other way. Why does this happen? Money. Simple as that. If they're willing to buy, someone is willing to sell. To put any real teeth behind the concept of an AUP and those that are supposedly charged with enforcing these, in a lot of firms, will take some sort of landmark criminal or civil case that effectively says, "You knew about these complaints and chose to ignore them, therefore you are complicit in what they did. Now fork over." It is unfortunate that this is probably going to be necessary, but thats the way I see things. Until companies are scared of the repercussions of weak or unenforced AUPs, this situation will not change. -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From smb at cs.columbia.edu Fri Jun 5 04:13:54 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Fri, 5 Jun 2009 05:13:54 -0400 Subject: .ORG is signed In-Reply-To: <221739EC-8ACC-4E86-9BF1-58A61E16F1AF@ca.afilias.info> References: <221739EC-8ACC-4E86-9BF1-58A61E16F1AF@ca.afilias.info> Message-ID: <20090605051354.4bc99085@cs.columbia.edu> On Tue, 2 Jun 2009 16:44:47 -0400 Dave Knight wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Colleagues, > > On behalf of PIR Technical Support I would like to announce that as > of today, 2009-06-02, at 16:00 UTC .ORG is DNSSEC signed. > Wonderful! --Steve Bellovin, http://www.cs.columbia.edu/~smb From randy at iij.ad.jp Fri Jun 5 04:48:29 2009 From: randy at iij.ad.jp (Randy Bush) Date: Fri, 05 Jun 2009 18:48:29 +0900 Subject: savvis Message-ID: we have a routing issue within savvis says to contact ssc at savvis.net and ipnoc at savvis.net the latter does not answer email. the former is invalid ... while talking to cluster9.us.messagelabs.com.: >>> DATA <<< 550 Invalid recipient (#5.1.1) 550 5.1.1 ... User unknown <<< 503 RCPT first (#5.5.1) could someone with routing filter fu at savvis please contact us out of band? thanks. randy From cidr-report at potaroo.net Fri Jun 5 07:00:09 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 5 Jun 2009 22:00:09 +1000 (EST) Subject: BGP Update Report Message-ID: <200906051200.n55C09rV086998@wattle.apnic.net> BGP Update Report Interval: 28-Apr-09 -to- 29-May-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9198 58785 1.0% 233.3 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - AS6389 57303 1.0% 13.1 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 3 - AS21491 54595 0.9% 1819.8 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 4 - AS8452 53246 0.9% 41.6 -- TEDATA TEDATA 5 - AS8151 48723 0.8% 12.6 -- Uninet S.A. de C.V. 6 - AS3130 46229 0.8% 179.9 -- RGNET-3130 RGnet/PSGnet 7 - AS35805 45913 0.8% 127.2 -- UTG-AS United Telecom AS 8 - AS17974 36111 0.6% 33.2 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 9 - AS10834 35811 0.6% 14.1 -- Telefonica Data Argentina S.A. 10 - AS20115 35268 0.6% 20.9 -- CHARTER-NET-HKY-NC - Charter Communications 11 - AS5056 34984 0.6% 296.5 -- INS-NET-2 - Iowa Network Services 12 - AS4249 32651 0.6% 180.4 -- LILLY-AS - Eli Lilly and Company 13 - AS17488 32059 0.5% 19.0 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 14 - AS33776 31203 0.5% 269.0 -- STARCOMMS-ASN 15 - AS4323 30360 0.5% 7.0 -- TWTC - tw telecom holdings, inc. 16 - AS30890 26554 0.5% 48.8 -- EVOLVA Evolva Telecom 17 - AS2920 25925 0.4% 316.2 -- LACOE - Los Angeles County Office of Education 18 - AS29372 25107 0.4% 317.8 -- SFR-NETWORK SFR 19 - AS5050 25065 0.4% 1790.4 -- PSC-EXT - Pittsburgh Supercomputing Center 20 - AS10620 24077 0.4% 24.3 -- TV Cable S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS16931 18144 0.3% 9072.0 -- GLOBAL-PAYMENTS-1 - Global Payments, Inc. 2 - AS15045 16317 0.3% 4079.2 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 3 - AS2 3535 0.1% 4.0 -- NAVITAIRE-AS-AU-AP Accenture - Navitaire, 4 - AS32398 20661 0.3% 3443.5 -- REALNET-ASN-1 5 - AS13153 2542 0.0% 2542.0 -- ONEWORLD OneWorld S.A. 6 - AS29229 2444 0.0% 2444.0 -- ASDA-AS Assotiation for the Development of West Athens 7 - AS8499 2252 0.0% 2252.0 -- Space Hellas Network Operation Center (NOC) 8 - AS13325 16858 0.3% 2107.2 -- STOMI - State of Michigan, DMB-CNOC 9 - AS39803 4171 0.1% 2085.5 -- UTI-AS SC UTI COMMUNICATIONS SYSTEMS SRL 10 - AS39699 5751 0.1% 1917.0 -- SSPOY-AS Salon Seudun Puhelin Oy 11 - AS47640 5581 0.1% 1860.3 -- TRICOMPAS Tricomp Sp. z. o. o. 12 - AS21491 54595 0.9% 1819.8 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 13 - AS5050 25065 0.4% 1790.4 -- PSC-EXT - Pittsburgh Supercomputing Center 14 - AS17236 1271 0.0% 1271.0 -- TULSAL-74103 - Tulsa City-County Library 15 - AS35400 7612 0.1% 1268.7 -- MFIST Interregoinal Organization Network Technologies 16 - AS28256 1241 0.0% 1241.0 -- 17 - AS28953 2317 0.0% 1158.5 -- PIRAEUSBANK Greek banking institution 18 - AS47299 1086 0.0% 1086.0 -- DRSA-AS Dlugie Rozmowy S.A. 19 - AS41492 1082 0.0% 1082.0 -- EXIMBANK-AS SC Eximbank SA 20 - AS24994 2136 0.0% 1068.0 -- GENESYS-AS GENESYS Informatica AS for announcing own prefixes TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 72.23.246.0/24 24597 0.4% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 2 - 41.204.2.0/24 20567 0.3% AS32398 -- REALNET-ASN-1 3 - 64.69.192.0/20 18134 0.3% AS16931 -- GLOBAL-PAYMENTS-1 - Global Payments, Inc. 4 - 192.12.120.0/24 10437 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 5 - 89.218.218.0/23 7837 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 6 - 89.218.220.0/23 7833 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 7 - 92.46.244.0/23 7830 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 8 - 95.59.4.0/22 7823 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 9 - 95.59.2.0/23 7818 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 10 - 95.59.8.0/23 7817 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 11 - 123.49.152.0/24 7538 0.1% AS18118 -- CITICNET-AP CITIC Networks Management Co.,Ltd. 12 - 90.150.0.0/24 7284 0.1% AS35400 -- MFIST Interregoinal Organization Network Technologies 13 - 63.144.223.0/24 7006 0.1% AS30221 -- T3COM - T3 Communications, Inc. 14 - 72.42.204.0/23 6972 0.1% AS40060 -- AAAWI - AAA Wireless, Inc. 15 - 123.49.144.0/21 6876 0.1% AS18118 -- CITICNET-AP CITIC Networks Management Co.,Ltd. 16 - 195.96.69.0/24 6089 0.1% AS8225 -- ASTELIT-MSK-AS Astelit Autonomous System 17 - 193.201.184.0/21 5865 0.1% AS25546 -- BROOKLANDCOMP-AS Brookland Computer Services 18 - 63.103.104.0/22 5668 0.1% AS15045 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 19 - 63.103.108.0/23 5668 0.1% AS15045 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 20 - 81.199.18.0/24 5657 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 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 Jun 5 07:00:03 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 5 Jun 2009 22:00:03 +1000 (EST) Subject: The Cidr Report Message-ID: <200906051200.n55C03a9086968@wattle.apnic.net> This report has been generated at Fri Jun 5 21:13:44 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 29-05-09 295132 184547 30-05-09 295389 184322 31-05-09 295380 183255 01-06-09 295277 183168 02-06-09 295685 183097 03-06-09 293672 183636 04-06-09 293913 183558 05-06-09 293617 183556 AS Summary 31505 Number of ASes in routing system 13383 Number of ASes announcing only one prefix 4292 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89749760 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'). --- 05Jun09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 294557 183702 110855 37.6% All ASes AS6389 4292 338 3954 92.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4274 1775 2499 58.5% TWTC - tw telecom holdings, inc. AS8151 2003 633 1370 68.4% Uninet S.A. de C.V. AS4766 1815 521 1294 71.3% KIXS-AS-KR Korea Telecom AS17488 1593 299 1294 81.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1242 143 1099 88.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1061 68 993 93.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS1785 1685 780 905 53.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS8452 1207 316 891 73.8% TEDATA TEDATA AS19262 1011 234 777 76.9% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18566 1062 423 639 60.2% COVAD - Covad Communications Co. AS6478 1399 788 611 43.7% ATT-INTERNET3 - AT&T WorldNet Services AS18101 752 160 592 78.7% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS4804 679 107 572 84.2% MPX-AS Microplex PTY LTD AS11492 1113 582 531 47.7% CABLEONE - CABLE ONE, INC. AS22047 588 92 496 84.4% VTR BANDA ANCHA S.A. AS2706 536 44 492 91.8% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS17676 564 80 484 85.8% GIGAINFRA Softbank BB Corp. AS4134 892 421 471 52.8% CHINANET-BACKBONE No.31,Jin-rong Street AS4808 631 166 465 73.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7018 1496 1033 463 30.9% ATT-INTERNET4 - AT&T WorldNet Services AS24560 695 245 450 64.7% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7545 805 378 427 53.0% TPG-INTERNET-AP TPG Internet Pty Ltd AS12479 449 24 425 94.7% UNI2-AS Uni2 Autonomous System AS9443 513 90 423 82.5% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7011 976 563 413 42.3% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4668 691 283 408 59.0% LGNET-AS-KR LG CNS AS6517 651 243 408 62.7% RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc AS17908 645 244 401 62.2% TCISL Tata Communications AS4780 521 135 386 74.1% SEEDNET Digital United Inc. Total 35841 11208 24633 68.7% Top 30 total Possible Bogus Routes 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 91.212.237.0/24 AS24875 NL-ISPSERVICES ISP Services BV 91.212.245.0/24 AS13237 LAMBDANET-AS European Backbone of LambdaNet 95.81.64.0/18 AS47262 HAMARA-AS Hamara System Tabriz Engineering Company 100.100.100.0/30 AS38676 AS33005-AS-KR wizsolution co.,Ltd 109.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 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 171.18.0.0/20 AS12696 AXA-TECH Axa technology Services 171.18.17.0/24 AS12696 AXA-TECH Axa technology Services 171.18.19.0/24 AS12696 AXA-TECH Axa technology Services 171.18.20.0/24 AS12696 AXA-TECH Axa technology Services 171.18.22.0/24 AS12696 AXA-TECH Axa technology Services 171.18.24.0/23 AS43722 ATNEDC-AS AXA Technology Services Germany GmbH 171.18.26.0/23 AS43722 ATNEDC-AS AXA Technology Services Germany GmbH 171.18.28.0/23 AS43722 ATNEDC-AS AXA Technology Services Germany GmbH 171.18.32.0/24 AS12696 AXA-TECH Axa technology Services 171.18.33.0/24 AS12696 AXA-TECH Axa technology Services 171.18.34.0/24 AS12696 AXA-TECH Axa technology Services 171.18.35.0/24 AS12696 AXA-TECH Axa technology Services 171.18.36.0/24 AS12696 AXA-TECH Axa technology Services 171.18.37.0/24 AS12696 AXA-TECH Axa technology Services 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 G-WiN 192.124.252.0/22 AS680 DFN-IP service G-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 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.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 HKSUPER-HK-AP Pacific 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.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. 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.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 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.108.24.0/22 AS34305 EUROACCESS Euroaccess Global Autonomous System 213.108.29.0/24 AS34305 EUROACCESS Euroaccess Global Autonomous System 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.98.48.0/20 AS22634 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 IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet 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 ge at linuxbox.org Fri Jun 5 07:04:04 2009 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 05 Jun 2009 15:04:04 +0300 Subject: ftc shuts down a colo and ip provider In-Reply-To: <75cb24520906042258j3aea47cfl45b3dbe3b89b8dcf@mail.gmail.com> References: <75cb24520906042258j3aea47cfl45b3dbe3b89b8dcf@mail.gmail.com> Message-ID: <4A2909B4.4040508@linuxbox.org> Christopher Morrow wrote: > On Fri, Jun 5, 2009 at 1:44 AM, Deepak Jain wrote: >> What does it say about these providers AUP that the FTC needed to go to court to turn them off? > > I hate to re-start the atrivo/intercage/mccolo thread(s) but, often > what happens is there just arent any real/usable complaints sent along > to the upstream providers. Chris, I think enough time has past that it should be safe now to release the full story into public consumption, and open a public debate on the subjects at hand. What do you think? Gadi. From morrowc.lists at gmail.com Fri Jun 5 08:46:43 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 5 Jun 2009 09:46:43 -0400 Subject: ftc shuts down a colo and ip provider In-Reply-To: <4A2909B4.4040508@linuxbox.org> References: <75cb24520906042258j3aea47cfl45b3dbe3b89b8dcf@mail.gmail.com> <4A2909B4.4040508@linuxbox.org> Message-ID: <75cb24520906050646w51b801bck95d1080e3d5783d2@mail.gmail.com> On Fri, Jun 5, 2009 at 8:04 AM, Gadi Evron wrote: > Christopher Morrow wrote: >> >> On Fri, Jun 5, 2009 at 1:44 AM, Deepak Jain wrote: >>> >>> What does it say about these providers AUP that the FTC needed to go to >>> court to turn them off? >> >> I hate to re-start the atrivo/intercage/mccolo thread(s) but, often >> what happens is there just arent any real/usable complaints sent along >> to the upstream providers. > > Chris, I think enough time has past that it should be safe now to release > the full story into public consumption, and open a public debate on the > subjects at hand. > > What do you think? not my call, but feel free. -Chris From ren.provo at gmail.com Fri Jun 5 13:04:25 2009 From: ren.provo at gmail.com (Ren Provo) Date: Fri, 5 Jun 2009 14:04:25 -0400 Subject: [NANOG-announce] Reminder - NANOG46 registration fees - $525 => $600 on Monday Message-ID: <787581440906051104p96ad4a2y219cdb1b6a4adc6e@mail.gmail.com> Hi folks, Just a few reminders - The registration fee for NANOG46 is set to go up from US$525 to US$600 on Monday. https://nanog.merit.edu/registration/ The general program is full at this time. Lightning talks are being accepted at http://pc.nanog.org. Three lightning talks will be selected next Tuesday for presentation on Monday the 15th of June. http://nanog46.comcast.net offers suggestions for site-seeing, food and transport. Some have asked what is the best way to get to the Loews Hotel from the Philadelphia Airport. Without a doubt the train is the best bang for your $7. Follow the signs when baggage claim, ground transportation and exit are mentioned. You can purchase the ticket on the train. Market East is the exit and the hotel is across the street from the Hard Rock at the corner of 12th & Market. See you in about a week! -ren _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From cscora at apnic.net Fri Jun 5 13:12:14 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 6 Jun 2009 04:12:14 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200906051812.n55ICE5J019229@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 06 Jun, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 288419 Prefixes after maximum aggregation: 136920 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 142415 Total ASes present in the Internet Routing Table: 31418 Prefixes per ASN: 9.18 Origin-only ASes present in the Internet Routing Table: 27318 Origin ASes announcing only one prefix: 13309 Transit ASes present in the Internet Routing Table: 4100 Transit-only ASes present in the Internet Routing Table: 98 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 28 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 491 Unregistered ASNs in the Routing Table: 142 Number of 32-bit ASNs allocated by the RIRs: 166 Prefixes from 32-bit ASNs in the Routing Table: 42 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 823 Number of addresses announced to Internet: 2058656960 Equivalent to 122 /8s, 180 /16s and 156 /24s Percentage of available address space announced: 55.5 Percentage of allocated address space announced: 64.3 Percentage of available address space allocated: 86.4 Percentage of address space in use by end-sites: 77.2 Total number of prefixes smaller than registry allocations: 143030 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 68315 Total APNIC prefixes after maximum aggregation: 24421 APNIC Deaggregation factor: 2.80 Prefixes being announced from the APNIC address blocks: 67723 Unique aggregates announced from the APNIC address blocks: 30707 APNIC Region origin ASes present in the Internet Routing Table: 3652 APNIC Prefixes per ASN: 18.54 APNIC Region origin ASes announcing only one prefix: 999 APNIC Region transit ASes present in the Internet Routing Table: 560 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 453358944 Equivalent to 27 /8s, 5 /16s and 181 /24s Percentage of available APNIC address space announced: 84.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: 123325 Total ARIN prefixes after maximum aggregation: 65857 ARIN Deaggregation factor: 1.87 Prefixes being announced from the ARIN address blocks: 124064 Unique aggregates announced from the ARIN address blocks: 51778 ARIN Region origin ASes present in the Internet Routing Table: 13026 ARIN Prefixes per ASN: 9.52 ARIN Region origin ASes announcing only one prefix: 4996 ARIN Region transit ASes present in the Internet Routing Table: 1275 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 1017544256 Equivalent to 60 /8s, 166 /16s and 126 /24s Percentage of available ARIN address space announced: 195.6 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: 65773 Total RIPE prefixes after maximum aggregation: 38881 RIPE Deaggregation factor: 1.69 Prefixes being announced from the RIPE address blocks: 64972 Unique aggregates announced from the RIPE address blocks: 43672 RIPE Region origin ASes present in the Internet Routing Table: 13101 RIPE Prefixes per ASN: 4.96 RIPE Region origin ASes announcing only one prefix: 6860 RIPE Region transit ASes present in the Internet Routing Table: 1972 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 28 Number of RIPE addresses announced to Internet: 481592224 Equivalent to 28 /8s, 180 /16s and 131 /24s Percentage of available RIPE address space announced: 102.5 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: 24378 Total LACNIC prefixes after maximum aggregation: 5971 LACNIC Deaggregation factor: 4.08 Prefixes being announced from the LACNIC address blocks: 24258 Unique aggregates announced from the LACNIC address blocks: 13143 LACNIC Region origin ASes present in the Internet Routing Table: 1118 LACNIC Prefixes per ASN: 21.70 LACNIC Region origin ASes announcing only one prefix: 363 LACNIC Region transit ASes present in the Internet Routing Table: 184 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 20 Number of LACNIC addresses announced to Internet: 71353856 Equivalent to 4 /8s, 64 /16s and 198 /24s Percentage of available LACNIC address space announced: 70.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: 6192 Total AfriNIC prefixes after maximum aggregation: 1450 AfriNIC Deaggregation factor: 4.27 Prefixes being announced from the AfriNIC address blocks: 6566 Unique aggregates announced from the AfriNIC address blocks: 2466 AfriNIC Region origin ASes present in the Internet Routing Table: 298 AfriNIC Prefixes per ASN: 22.03 AfriNIC Region origin ASes announcing only one prefix: 91 AfriNIC Region transit ASes present in the Internet Routing Table: 62 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 20432896 Equivalent to 1 /8s, 55 /16s and 200 /24s Percentage of available AfriNIC address space announced: 60.9 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 1707 6930 401 Korea Telecom (KIX) 17488 1593 130 101 Hathway IP Over Cable Interne 4755 1241 402 122 TATA Communications formerly 9583 1086 87 542 Sify Limited 4134 892 16925 377 CHINANET-BACKBONE 7545 786 198 102 TPG Internet Pty Ltd 23577 782 34 664 Korea Telecom (ATM-MPLS) 18101 752 216 29 Reliance Infocom Ltd Internet 24560 695 230 174 Bharti Airtel Ltd. 9829 678 569 16 BSNL National Internet Backbo 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 4292 3647 324 bellsouth.net, inc. 4323 1859 1034 375 Time Warner Telecom 1785 1686 717 138 PaeTec Communications, Inc. 20115 1638 1441 718 Charter Communications 7018 1498 5899 1030 AT&T WorldNet Services 6478 1399 310 436 AT&T Worldnet Services 2386 1273 683 922 AT&T Data Communications Serv 3356 1206 10980 451 Level 3 Communications, LLC 11492 1112 208 12 Cable One 18566 1062 296 10 Covad Communications 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 529 88 197 Evolva Telecom 3292 455 1893 393 TDC Tele Danmark 12479 450 578 6 Uni2 Autonomous System 702 431 1862 347 UUNET - Commercial IP service 35805 353 24 4 United Telecom of Georgia 8866 351 109 21 Bulgarian Telecommunication C 3215 343 3041 108 France Telecom Transpac 3301 339 1667 303 TeliaNet Sweden 3320 337 7066 295 Deutsche Telekom AG 29049 318 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 2001 2863 235 UniNet S.A. de C.V. 10620 905 205 118 TVCABLE BOGOTA 22047 588 302 14 VTR PUNTO NET S.A. 7303 564 297 86 Telecom Argentina Stet-France 28573 538 563 35 NET Servicos de Comunicao S.A 11830 486 292 54 Instituto Costarricense de El 6471 443 96 32 ENTEL CHILE S.A. 11172 441 102 70 Servicios Alestra S.A de C.V 7738 404 794 28 Telecomunicacoes da Bahia S.A 3816 359 171 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 1206 188 7 TEDATA 24863 851 82 40 LINKdotNET AS number 20858 298 34 5 EgyNet 3741 277 856 237 The Internet Solution 2018 245 215 143 Tertiary Education Network 6713 160 151 12 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 33776 116 6 7 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 4292 3647 324 bellsouth.net, inc. 8151 2001 2863 235 UniNet S.A. de C.V. 4323 1859 1034 375 Time Warner Telecom 4766 1707 6930 401 Korea Telecom (KIX) 1785 1686 717 138 PaeTec Communications, Inc. 20115 1638 1441 718 Charter Communications 17488 1593 130 101 Hathway IP Over Cable Interne 7018 1498 5899 1030 AT&T WorldNet Services 6478 1399 310 436 AT&T Worldnet Services 2386 1273 683 922 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 8151 2001 1766 UniNet S.A. de C.V. 1785 1686 1548 PaeTec Communications, Inc. 17488 1593 1492 Hathway IP Over Cable Interne 4323 1859 1484 Time Warner Telecom 4766 1707 1306 Korea Telecom (KIX) 8452 1206 1199 TEDATA 4755 1241 1119 TATA Communications formerly 11492 1112 1100 Cable One 18566 1062 1052 Covad Communications 22773 1062 996 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.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 64.31.59.0/24 7017 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:167 /13:348 /14:602 /15:1153 /16:10487 /17:4720 /18:8074 /19:16917 /20:20130 /21:19933 /22:25839 /23:25690 /24:151691 /25:851 /26:1008 /27:538 /28:141 /29:8 /30:5 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2799 4292 bellsouth.net, inc. 4766 1400 1707 Korea Telecom (KIX) 17488 1307 1593 Hathway IP Over Cable Interne 1785 1163 1686 PaeTec Communications, Inc. 8452 1163 1206 TEDATA 11492 1043 1112 Cable One 18566 1043 1062 Covad Communications 2386 980 1273 AT&T Data Communications Serv 4323 951 1859 Time Warner Telecom 9583 937 1086 Sify Limited Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:206 12:2250 13:10 15:19 16:3 17:4 20:35 24:1079 32:52 34:2 38:568 40:97 41:1981 43:1 44:2 47:22 52:4 55:2 56:3 57:24 58:592 59:639 60:459 61:1084 62:1095 63:2007 64:3717 65:2381 66:3626 67:1625 68:823 69:2643 70:565 71:150 72:1669 73:2 74:1560 75:170 76:306 77:854 78:556 79:350 80:974 81:836 82:559 83:430 84:614 85:1052 86:397 87:658 88:353 89:1442 90:64 91:2271 92:342 93:1047 94:1229 95:1116 96:139 97:215 98:240 99:21 109:1 110:132 112:132 113:124 114:256 115:312 116:1165 117:533 118:285 119:703 120:145 121:747 122:1027 123:682 124:989 125:1324 128:222 129:238 130:126 131:410 132:74 133:9 134:186 135:39 136:224 137:159 138:161 139:78 140:442 141:114 142:384 143:333 144:361 145:48 146:377 147:164 148:520 149:229 150:177 151:195 152:145 153:140 154:2 155:275 156:170 157:301 158:115 159:312 160:282 161:143 162:270 163:146 164:482 165:501 166:276 167:359 168:672 169:163 170:469 171:46 172:10 173:290 174:223 178:1 180:1 183:1 186:18 187:401 188:23 189:641 190:2706 192:5783 193:4232 194:3303 195:2706 196:1090 198:3628 199:3369 200:5151 201:1301 202:7908 203:8187 204:3829 205:2152 206:2436 207:2736 208:3890 209:3420 210:2682 211:1122 212:1556 213:1674 214:78 215:31 216:4645 217:1293 218:383 219:442 220:1218 221:483 222:303 End of report From jkrejci at usinternet.com Fri Jun 5 17:50:28 2009 From: jkrejci at usinternet.com (Justin Krejci) Date: Fri, 5 Jun 2009 17:50:28 -0500 Subject: Multi site BGP Routing design Message-ID: <3351AB2E05C84597AD375B6762D2A08B@usicorp.usinternet.com> We have two geographically distinct locations that currently both fall under the same ASN. At site 1 we have a particular set of ip networks (/20 and bigger) in use only locally to this site At site 2 we have a separate set of ip networks (/20 and bigger) in use only locally to this site Each site has at least one upstream internet connection advertising with BGP. There is also a (reliable) private link between to the two sites where our routers at each site are all talking iBGP (as well as ospf). There is a router subnet (/27) that spans the two sites. We currently advertise all subnets out all upstream connections as if both sites were only one and traffic routes between sites without issue via the private link. If the private link between the two sites fails, will BGP allow for us to access the IP subnets at site 2 from site 1 via the internet given that both sites are advertising under the same ASN? Is this a case where having multiple ASNs makes sense to treat each site as remote peers to each other? Thanks, Justin From eriks at nationalfastfreight.com Fri Jun 5 17:47:32 2009 From: eriks at nationalfastfreight.com (Erik Soosalu) Date: Fri, 5 Jun 2009 18:47:32 -0400 Subject: OT: ARIN contact References: <0B224A2FE01CC54C860290D42474BF6003C16E6A@exchange.nff.local> Message-ID: <0B224A2FE01CC54C860290D42474BF600272A417@exchange.nff.local> You are correct in that ARIN was extremely responsive and quick (even to this email). and I hadn't had enough contact with ARIN to know that hostmaster at arin.net would be the fastest way to get a hold of them. Thanks, Erik ________________________________ From: Deepak Jain [mailto:deepak at ai.net] Sent: Thu 6/4/2009 6:53 PM To: Randy Bush; Erik Soosalu Cc: nanog at nanog.org Subject: RE: OT: ARIN contact > > I know this is off-topic, but I know some people from ARIN read this > and > > would appreciate it if someone from ARIN would contact me off-list. > > hostmaster at arin.net did not respond to email? this would be > *extremely* > unusual. > 2nd'ed. ARIN is very responsive by email and telephone now. Deepak From randy at iij.ad.jp Fri Jun 5 18:23:56 2009 From: randy at iij.ad.jp (Randy Bush) Date: Sat, 06 Jun 2009 08:23:56 +0900 Subject: savvis In-Reply-To: References: Message-ID: > we have a routing issue within savvis > says to contact > ssc at savvis.net and ipnoc at savvis.net > the latter does not answer email. the former is invalid > ... while talking to cluster9.us.messagelabs.com.: > >>> DATA > <<< 550 Invalid recipient (#5.1.1) > 550 5.1.1 ... User unknown > <<< 503 RCPT first (#5.5.1) > could someone with routing filter fu at savvis please contact us out of > band? thanks. for the archives o someone gave us a different front door address at savvis. the tech there replied that, as it was the site of their customer, they could not help [0]. o i also received a response to the nanog post from an engineer. it was to - say they will have the broken email listings fixed - say they will chase down internally with customer you can guess who i would hire. randy -- [0] - at the companies where i have worked (which vix says is a skewed sample), "not my job" is a CLM. the customer pays me for it to be my job. i may not be able to disclose, but i sure as hell will chase. From devangnp at gmail.com Fri Jun 5 18:28:03 2009 From: devangnp at gmail.com (devang patel) Date: Fri, 5 Jun 2009 17:28:03 -0600 Subject: Template for PE router configuration Message-ID: Hello, Is there any good document about PE router configuration template or any sample configuration some one can share, if possible? I am looking for the PE configuration template which has multiple MPLS VPN customer as well as PPPoE aggregation on it. regards Devang Patel From devangnp at gmail.com Fri Jun 5 18:28:03 2009 From: devangnp at gmail.com (devang patel) Date: Fri, 5 Jun 2009 17:28:03 -0600 Subject: Template for PE router configuration Message-ID: Hello, Is there any good document about PE router configuration template or any sample configuration some one can share, if possible? I am looking for the PE configuration template which has multiple MPLS VPN customer as well as PPPoE aggregation on it. regards Devang Patel From steve at ibctech.ca Fri Jun 5 18:42:43 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 05 Jun 2009 19:42:43 -0400 Subject: Multi site BGP Routing design In-Reply-To: <3351AB2E05C84597AD375B6762D2A08B@usicorp.usinternet.com> References: <3351AB2E05C84597AD375B6762D2A08B@usicorp.usinternet.com> Message-ID: <4A29AD73.1040503@ibctech.ca> Justin Krejci wrote: > If the private link between the two sites fails, will BGP allow for us to > access the IP subnets at site 2 from site 1 via the internet given that both > sites are advertising under the same ASN? No, because your router at site 2 will not accept any prefix with its own AS in the AS_PATH (which site 1 would be advertising from). > Is this a case where having multiple ASNs makes sense to treat each site as > remote peers to each other? Unless someone else has any better advice (I'm sure they do), you will need two separate public ASNs. Site 1 advertises it's space out of AS1, and site 2 advertises it's space from AS2. If you do that, it may be best if you have an eBGP session between the two PoPs using med/pref to ensure the direct link is preferred if it is up. (I've never had to do iBGP between two sites like this before, but I do know that eBGP is preferred over iBGP). Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From cmadams at hiwaay.net Fri Jun 5 19:16:55 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 5 Jun 2009 19:16:55 -0500 Subject: Multi site BGP Routing design In-Reply-To: <4A29AD73.1040503@ibctech.ca> References: <3351AB2E05C84597AD375B6762D2A08B@usicorp.usinternet.com> <4A29AD73.1040503@ibctech.ca> Message-ID: <20090606001655.GA1486707@hiwaay.net> Once upon a time, Steve Bertrand said: > Unless someone else has any better advice (I'm sure they do), you will > need two separate public ASNs. Site 1 advertises it's space out of AS1, > and site 2 advertises it's space from AS2. I don't know that it's better advice, but another way to link the two sites is via a tunnel (GRE or IPIP). Use the upstream IP on each router as the local endpoint, and then run some routing protocol over the tunnel. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From cra at WPI.EDU Fri Jun 5 19:33:24 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 5 Jun 2009 20:33:24 -0400 Subject: Multi site BGP Routing design In-Reply-To: <3351AB2E05C84597AD375B6762D2A08B@usicorp.usinternet.com> References: <3351AB2E05C84597AD375B6762D2A08B@usicorp.usinternet.com> Message-ID: <20090606003324.GD11559@angus.ind.WPI.EDU> On Fri, Jun 05, 2009 at 05:50:28PM -0500, Justin Krejci wrote: > If the private link between the two sites fails, will BGP allow for us to > access the IP subnets at site 2 from site 1 via the internet given that both > sites are advertising under the same ASN? Maybe. Especially if both sites are connected to the same ISP, you can tweak some BGP knobs to allow your own ASN to appear in the AS PATH N times where N > 1, and accept the routes anyway. From John.Herbert at ins.com Fri Jun 5 19:35:00 2009 From: John.Herbert at ins.com (John.Herbert at ins.com) Date: Fri, 5 Jun 2009 19:35:00 -0500 Subject: Multi site BGP Routing design In-Reply-To: <20090606001655.GA1486707@hiwaay.net> References: <3351AB2E05C84597AD375B6762D2A08B@usicorp.usinternet.com> <4A29AD73.1040503@ibctech.ca>,<20090606001655.GA1486707@hiwaay.net> Message-ID: <16984E60-4059-457B-B468-7ED5BECA0307@mimectl> Depending on your security policies you may want to encrypt said tunnel also. Other than that, it all depends on it all depends. For example - if you receive / or have a default route pointing to the ISP, then the fact you have the same AS and won't receive the other site's routes in BGP doesn't matter at all - you'll follow a default from site 1 to the ISP, and the ISP will have a route to site 2 and can pass the traffic in the right direction. If you don't mind your traffic being passed unencrypted over the Internet, that is. You'll obviously need to adapt your firewall policies to allow for that flow as well. j. ________________________________ From: Chris Adams [cmadams at hiwaay.net] Sent: Friday, June 05, 2009 20:16 To: nanog at nanog.org Subject: Re: Multi site BGP Routing design Once upon a time, Steve Bertrand said: > Unless someone else has any better advice (I'm sure they do), you will > need two separate public ASNs. Site 1 advertises it's space out of AS1, > and site 2 advertises it's space from AS2. I don't know that it's better advice, but another way to link the two sites is via a tunnel (GRE or IPIP). Use the upstream IP on each router as the local endpoint, and then run some routing protocol over the tunnel. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From steve at ibctech.ca Fri Jun 5 19:36:01 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 05 Jun 2009 20:36:01 -0400 Subject: Multi site BGP Routing design In-Reply-To: <20090606003324.GD11559@angus.ind.WPI.EDU> References: <3351AB2E05C84597AD375B6762D2A08B@usicorp.usinternet.com> <20090606003324.GD11559@angus.ind.WPI.EDU> Message-ID: <4A29B9F1.4020502@ibctech.ca> Chuck Anderson wrote: > On Fri, Jun 05, 2009 at 05:50:28PM -0500, Justin Krejci wrote: >> If the private link between the two sites fails, will BGP allow for us to >> access the IP subnets at site 2 from site 1 via the internet given that both >> sites are advertising under the same ASN? > > Maybe. Especially if both sites are connected to the same ISP, you > can tweak some BGP knobs to allow your own ASN to appear in the AS > PATH N times where N > 1, and accept the routes anyway. For some reason, I see that as being a configuration method that would quickly be forgotten about, and later cause major headaches trying to troubleshoot. Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From steve at ibctech.ca Fri Jun 5 19:40:03 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 05 Jun 2009 20:40:03 -0400 Subject: Multi site BGP Routing design In-Reply-To: <16984E60-4059-457B-B468-7ED5BECA0307@mimectl> References: <3351AB2E05C84597AD375B6762D2A08B@usicorp.usinternet.com> <4A29AD73.1040503@ibctech.ca>, <20090606001655.GA1486707@hiwaay.net> <16984E60-4059-457B-B468-7ED5BECA0307@mimectl> Message-ID: <4A29BAE3.2050006@ibctech.ca> John.Herbert at ins.com wrote: > Depending on your security policies you may want to encrypt said tunnel also. > > Other than that, it all depends on it all depends. For example - if you receive / or have a default route pointing to the ISP, then the fact you have the same AS and won't receive the other site's routes in BGP doesn't matter at all - you'll follow a default from site 1 to the ISP, and the ISP will have a route to site 2 and can pass the traffic in the right direction. If you don't mind your traffic being passed unencrypted over the Internet, that is. You'll obviously need to adapt your firewall policies to allow for that flow as well. Personally, I don't really like the tunnel idea... I've had to deal with them for v6 connectivity, and they seem so 'ugly'. My first thoughts were about de-aggregation, but since he's already advertising different space out of each site, that became irrelevant. I was just thinking that two AS numbers would be the cleanest, easiest to maintain method for him to take. Certainly tunnelling did go through my mind though to ensure site-to-site peering over the Internet. Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From John.Herbert at ins.com Fri Jun 5 19:40:15 2009 From: John.Herbert at ins.com (John.Herbert at ins.com) Date: Fri, 5 Jun 2009 19:40:15 -0500 Subject: Multi site BGP Routing design In-Reply-To: <20090606003324.GD11559@angus.ind.WPI.EDU> References: <3351AB2E05C84597AD375B6762D2A08B@usicorp.usinternet.com>, <20090606003324.GD11559@angus.ind.WPI.EDU> Message-ID: <94B504A0-AE64-4065-961D-B4253C3C32BA@mimectl> This is a good concept but if the ISP route is a Juniper then as I recall by default it looks ahead, sees the as-path routing loop if it were to send it to the other router, and doesn't send it. So while you might be able to configure it on the receiving router, if the sending router won't send it, you're SOL. j. ________________________________ From: Chuck Anderson [cra at WPI.EDU] Sent: Friday, June 05, 2009 20:33 To: nanog at nanog.org Subject: Re: Multi site BGP Routing design On Fri, Jun 05, 2009 at 05:50:28PM -0500, Justin Krejci wrote: > If the private link between the two sites fails, will BGP allow for us to > access the IP subnets at site 2 from site 1 via the internet given that both > sites are advertising under the same ASN? Maybe. Especially if both sites are connected to the same ISP, you can tweak some BGP knobs to allow your own ASN to appear in the AS PATH N times where N > 1, and accept the routes anyway. From John.Herbert at ins.com Fri Jun 5 19:43:59 2009 From: John.Herbert at ins.com (John.Herbert at ins.com) Date: Fri, 5 Jun 2009 19:43:59 -0500 Subject: Multi site BGP Routing design In-Reply-To: <4A29BAE3.2050006@ibctech.ca> References: <3351AB2E05C84597AD375B6762D2A08B@usicorp.usinternet.com> <4A29AD73.1040503@ibctech.ca>,<20090606001655.GA1486707@hiwaay.net> <16984E60-4059-457B-B468-7ED5BECA0307@mimectl>, <4A29BAE3.2050006@ibctech.ca> Message-ID: Steve, Agreed. I'm not suggesting that a tunnel is the ultimate best solution, but rather just pointing out that if you go with a tunnel, it's worth remembering that it's going unencrypted over a public network rather than site to site over a private link. j. ________________________________ From: Steve Bertrand [steve at ibctech.ca] Sent: Friday, June 05, 2009 20:40 To: Herbert, John Cc: cmadams at hiwaay.net; nanog at nanog.org Subject: Re: Multi site BGP Routing design John.Herbert at ins.com wrote: > Depending on your security policies you may want to encrypt said tunnel also. > > Other than that, it all depends on it all depends. For example - if you receive / or have a default route pointing to the ISP, then the fact you have the same AS and won't receive the other site's routes in BGP doesn't matter at all - you'll follow a default from site 1 to the ISP, and the ISP will have a route to site 2 and can pass the traffic in the right direction. If you don't mind your traffic being passed unencrypted over the Internet, that is. You'll obviously need to adapt your firewall policies to allow for that flow as well. Personally, I don't really like the tunnel idea... I've had to deal with them for v6 connectivity, and they seem so 'ugly'. My first thoughts were about de-aggregation, but since he's already advertising different space out of each site, that became irrelevant. I was just thinking that two AS numbers would be the cleanest, easiest to maintain method for him to take. Certainly tunnelling did go through my mind though to ensure site-to-site peering over the Internet. Steve From cra at WPI.EDU Fri Jun 5 19:48:39 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 5 Jun 2009 20:48:39 -0400 Subject: Multi site BGP Routing design In-Reply-To: <94B504A0-AE64-4065-961D-B4253C3C32BA@mimectl> References: <20090606003324.GD11559@angus.ind.WPI.EDU> <94B504A0-AE64-4065-961D-B4253C3C32BA@mimectl> Message-ID: <20090606004839.GE11559@angus.ind.WPI.EDU> On Fri, Jun 05, 2009 at 07:40:15PM -0500, John.Herbert at ins.com wrote: > This is a good concept but if the ISP route is a Juniper then as I > recall by default it looks ahead, sees the as-path routing loop if > it were to send it to the other router, and doesn't send it. So > while you might be able to configure it on the receiving router, if > the sending router won't send it, you're SOL. True, the ISP in this case would have to cooperate :-) From steve at ibctech.ca Fri Jun 5 20:00:02 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 05 Jun 2009 21:00:02 -0400 Subject: Multi site BGP Routing design In-Reply-To: <20090606004839.GE11559@angus.ind.WPI.EDU> References: <20090606003324.GD11559@angus.ind.WPI.EDU> <94B504A0-AE64-4065-961D-B4253C3C32BA@mimectl> <20090606004839.GE11559@angus.ind.WPI.EDU> Message-ID: <4A29BF92.4010003@ibctech.ca> Chuck Anderson wrote: > On Fri, Jun 05, 2009 at 07:40:15PM -0500, John.Herbert at ins.com wrote: >> This is a good concept but if the ISP route is a Juniper then as I >> recall by default it looks ahead, sees the as-path routing loop if >> it were to send it to the other router, and doesn't send it. So >> while you might be able to configure it on the receiving router, if >> the sending router won't send it, you're SOL. > > True, the ISP in this case would have to cooperate :-) Have you ever known an ISP to not co-operate when it comes to requesting a BGP session? Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From mksmith at adhost.com Fri Jun 5 20:37:02 2009 From: mksmith at adhost.com (Michael K. Smith) Date: Fri, 05 Jun 2009 18:37:02 -0700 Subject: Multi site BGP Routing design In-Reply-To: <4A29AD73.1040503@ibctech.ca> Message-ID: On 6/5/09 4:42 PM, "Steve Bertrand" wrote: > Justin Krejci wrote: > >> If the private link between the two sites fails, will BGP allow for us to >> access the IP subnets at site 2 from site 1 via the internet given that both >> sites are advertising under the same ASN? > > No, because your router at site 2 will not accept any prefix with its > own AS in the AS_PATH (which site 1 would be advertising from). > > If you're running Cisco with the right IOS it looks like you could use the 'neighbor x.x.x.x allowas-in' command to accept your own AS. Then you would just have to set your local route origination so that the appropriate routes were withdrawn when the backnet link goes down. Mike From steve at ibctech.ca Fri Jun 5 20:59:54 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 05 Jun 2009 21:59:54 -0400 Subject: Multi site BGP Routing design In-Reply-To: References: Message-ID: <4A29CD9A.3080902@ibctech.ca> Michael K. Smith wrote: > On 6/5/09 4:42 PM, "Steve Bertrand" wrote: > >> Justin Krejci wrote: >> >>> If the private link between the two sites fails, will BGP allow for us to >>> access the IP subnets at site 2 from site 1 via the internet given that both >>> sites are advertising under the same ASN? >> No, because your router at site 2 will not accept any prefix with its >> own AS in the AS_PATH (which site 1 would be advertising from). >> >> > If you're running Cisco with the right IOS it looks like you could use the > 'neighbor x.x.x.x allowas-in' command to accept your own AS. Then you would > just have to set your local route origination so that the appropriate routes > were withdrawn when the backnet link goes down. I stand corrected. I've read about this, but does anyone have operational experience with it that they can share? Even though we are a very small SP, I always feel that going against the traditional grain when doing things like this may leave a trail of undocumented, hard-to-troubleshoot issues in the future. To rephrase the OP's question, would it be BCP to acquire a second ASN, and without further de-aggregating, continue advertising each site's IP space to the DFZ, but from dissimilar ASs as opposed to the same one? Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From randy at psg.com Fri Jun 5 21:04:25 2009 From: randy at psg.com (Randy Bush) Date: Sat, 06 Jun 2009 11:04:25 +0900 Subject: Multi site BGP Routing design In-Reply-To: <4A29BF92.4010003@ibctech.ca> References: <20090606003324.GD11559@angus.ind.WPI.EDU> <94B504A0-AE64-4065-961D-B4253C3C32BA@mimectl> <20090606004839.GE11559@angus.ind.WPI.EDU> <4A29BF92.4010003@ibctech.ca> Message-ID: > Have you ever known an ISP to not co-operate when it comes to > requesting a BGP session? yes. this problem is rampant with colonialist telcos in the poorer countries. randy From steve at ibctech.ca Fri Jun 5 21:46:27 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 05 Jun 2009 22:46:27 -0400 Subject: Multi site BGP Routing design In-Reply-To: References: <20090606003324.GD11559@angus.ind.WPI.EDU> <94B504A0-AE64-4065-961D-B4253C3C32BA@mimectl> <20090606004839.GE11559@angus.ind.WPI.EDU> <4A29BF92.4010003@ibctech.ca> Message-ID: <4A29D883.9030500@ibctech.ca> Randy Bush wrote: >> Have you ever known an ISP to not co-operate when it comes to >> requesting a BGP session? > > yes. this problem is rampant with colonialist telcos in the poorer > countries. Yeah, well, I don't live in a poorer country, and I deal with it here. *cough* Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From randy at psg.com Fri Jun 5 22:00:44 2009 From: randy at psg.com (Randy Bush) Date: Sat, 06 Jun 2009 12:00:44 +0900 Subject: Multi site BGP Routing design In-Reply-To: <4A29D883.9030500@ibctech.ca> References: <20090606003324.GD11559@angus.ind.WPI.EDU> <94B504A0-AE64-4065-961D-B4253C3C32BA@mimectl> <20090606004839.GE11559@angus.ind.WPI.EDU> <4A29BF92.4010003@ibctech.ca> <4A29D883.9030500@ibctech.ca> Message-ID: >>> Have you ever known an ISP to not co-operate when it comes to >>> requesting a BGP session? >> yes. this problem is rampant with colonialist telcos in the poorer >> countries. > Yeah, well, I don't live in a poorer country, and I deal with it here. > *cough* you asked a question. you are not required to like the answer. randy From randy at psg.com Fri Jun 5 22:32:15 2009 From: randy at psg.com (Randy Bush) Date: Sat, 06 Jun 2009 12:32:15 +0900 Subject: Multi site BGP Routing design In-Reply-To: References: <20090606003324.GD11559@angus.ind.WPI.EDU> <94B504A0-AE64-4065-961D-B4253C3C32BA@mimectl> <20090606004839.GE11559@angus.ind.WPI.EDU> <4A29BF92.4010003@ibctech.ca> <4A29D883.9030500@ibctech.ca> Message-ID: >>>> Have you ever known an ISP to not co-operate when it comes to >>>> requesting a BGP session? >>> yes. this problem is rampant with colonialist telcos in the poorer >>> countries. >> Yeah, well, I don't live in a poorer country, and I deal with it here. >> *cough* > you asked a question. you are not required to like the answer. oh, and i belive there was a north american incident of this discussed on this list in the last year. i am just too soaked to have the energy to search. i think it was due to living in a sparsely served area, so the isp could get away with . randy From ip at ioshints.info Sat Jun 6 02:40:20 2009 From: ip at ioshints.info (Ivan Pepelnjak) Date: Sat, 6 Jun 2009 09:40:20 +0200 Subject: Multi site BGP Routing design In-Reply-To: <4A29CD9A.3080902@ibctech.ca> References: <4A29CD9A.3080902@ibctech.ca> Message-ID: <005e01c9e67a$0c906cc0$0a00000a@nil.si> > To rephrase the OP's question, would it be BCP to acquire a > second ASN, and without further de-aggregating, continue > advertising each site's IP space to the DFZ, but from > dissimilar ASs as opposed to the same one? This would definitely be the best approach. You're not introducing new IP prefixes and you're not extending AS paths, so the net effect on the global BGP routing is zero (OK, you might have to use the 4 byte AS number :). Just make sure that both ISPs you connect to allow you to advertise "transit" prefixes. If site A public link goes down, but the private link is up, site B will advertise its own address space plus site A's address space with an extra AS number in the AS path (and the upstream ISP might filter that). Ivan http://www.ioshints.info/about http://blog.ioshints.info/ From msaqib at gmail.com Sat Jun 6 07:21:29 2009 From: msaqib at gmail.com (Saqib Ilyas) Date: Sat, 6 Jun 2009 17:21:29 +0500 Subject: Multi site BGP Routing design In-Reply-To: <005e01c9e67a$0c906cc0$0a00000a@nil.si> References: <4A29CD9A.3080902@ibctech.ca> <005e01c9e67a$0c906cc0$0a00000a@nil.si> Message-ID: <262b67200906060521v78c97463ta39229c397535862@mail.gmail.com> For a given interconnection between the upstream ISPs for the two site, once the direct link goes down, the time required for site A to learn the new route to site B and vice versa would be different with the different proposed solutions, right? Thanks and best regards On Sat, Jun 6, 2009 at 12:40 PM, Ivan Pepelnjak wrote: > > To rephrase the OP's question, would it be BCP to acquire a > > second ASN, and without further de-aggregating, continue > > advertising each site's IP space to the DFZ, but from > > dissimilar ASs as opposed to the same one? > > This would definitely be the best approach. You're not introducing new IP > prefixes and you're not extending AS paths, so the net effect on the global > BGP routing is zero (OK, you might have to use the 4 byte AS number :). > > Just make sure that both ISPs you connect to allow you to advertise > "transit" prefixes. If site A public link goes down, but the private link > is > up, site B will advertise its own address space plus site A's address space > with an extra AS number in the AS path (and the upstream ISP might filter > that). > > Ivan > > http://www.ioshints.info/about > http://blog.ioshints.info/ > > > -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences From maillist at webjogger.net Sat Jun 6 08:37:48 2009 From: maillist at webjogger.net (Adam Greene) Date: Sat, 6 Jun 2009 09:37:48 -0400 Subject: Multi site BGP Routing design References: <4A29CD9A.3080902@ibctech.ca><005e01c9e67a$0c906cc0$0a00000a@nil.si> <262b67200906060521v78c97463ta39229c397535862@mail.gmail.com> Message-ID: Hi all, We actually have a very similar setup to what Justin asked about, with the exception that we advertise only some of our netblocks to one provider and the rest to the other. If one of the providers fails, we then advertise all netblocks through the provider which is still up. If the private link between our two locations fails, the two halves of our network communicate via the Internet. >From what Justin described, I would think he would be able to keep a single ASN and configure his network so that if the private link goes down, the two newly disconnected halves of his network advertise only the netblocks they can still "see" (i.e. the ones on their half). As long as his internal network is set up with dynamic routing (iBGP / OSPF) the two halves should realize they have to get to the other half via the Internet. In our case, we don't get full routing tables from our providers, just default routes. Perhaps in Justin's case something as simple as a floating static route via the Internet to the other half of the network would take care of any ASN weirdness. It doesn't sound like he really needs his border routers to speak BGP with each other while the private link is down. If he wanted to remove the BGP session entirely under these circumstances, he could do the iBGP peering between RFC 1918 addresses and thus force the iBGP session to go down if the private link fails. Thanks, Adam ----- Original Message ----- From: "Saqib Ilyas" To: Sent: Saturday, June 06, 2009 8:21 AM Subject: Re: Multi site BGP Routing design > For a given interconnection between the upstream ISPs for the two site, > once > the direct link goes down, the time required for site A to learn the new > route to site B and vice versa would be different with the different > proposed solutions, right? > Thanks and best regards > > On Sat, Jun 6, 2009 at 12:40 PM, Ivan Pepelnjak wrote: > >> > To rephrase the OP's question, would it be BCP to acquire a >> > second ASN, and without further de-aggregating, continue >> > advertising each site's IP space to the DFZ, but from >> > dissimilar ASs as opposed to the same one? >> >> This would definitely be the best approach. You're not introducing new IP >> prefixes and you're not extending AS paths, so the net effect on the >> global >> BGP routing is zero (OK, you might have to use the 4 byte AS number :). >> >> Just make sure that both ISPs you connect to allow you to advertise >> "transit" prefixes. If site A public link goes down, but the private link >> is >> up, site B will advertise its own address space plus site A's address >> space >> with an extra AS number in the AS path (and the upstream ISP might filter >> that). >> >> Ivan >> >> http://www.ioshints.info/about >> http://blog.ioshints.info/ >> >> >> > > > -- > Muhammad Saqib Ilyas > PhD Student, Computer Science and Engineering > Lahore University of Management Sciences > > From jeffrey.lyon at blacklotus.net Sat Jun 6 09:37:09 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 6 Jun 2009 10:37:09 -0400 Subject: Rwhoisd solution? Message-ID: <16720fe00906060737ue1d1371j735c681983038fe3@mail.gmail.com> NANOGers, Can someone please point me in the direction of an rwhoisd solution to be run on a CentOS Linux platform? ARIN is now punting rwhois queries to us and frankly i've been unable to find an easy to install/use solution to answer these queries. I've seen the rwhoisd at projects.arin.net but the documentation on it is ghastly to say the least. Hopefully someone knows of an easier solution or at least a tutorial somewhere? -- 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 gmclean at xilogix.net Sat Jun 6 10:03:33 2009 From: gmclean at xilogix.net (Gregory McLean) Date: Sat, 06 Jun 2009 11:03:33 -0400 Subject: Rwhoisd solution? In-Reply-To: <16720fe00906060737ue1d1371j735c681983038fe3@mail.gmail.com> References: <16720fe00906060737ue1d1371j735c681983038fe3@mail.gmail.com> Message-ID: <1244300613.17902.3.camel@developer.gxsnmp.org> On Sat, 2009-06-06 at 10:37 -0400, Jeffrey Lyon wrote: > NANOGers, > > Can someone please point me in the direction of an rwhoisd solution to > be run on a CentOS Linux platform? ARIN is now punting rwhois queries > to us and frankly i've been unable to find an easy to install/use > solution to answer these queries. I've seen the rwhoisd at > projects.arin.net but the documentation on it is ghastly to say the > least. > > Hopefully someone knows of an easier solution or at least a tutorial somewhere? > If you happen to find one I'd like to know about it as well... From jeffrey.lyon at blacklotus.net Sat Jun 6 10:05:33 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 6 Jun 2009 11:05:33 -0400 Subject: Rwhoisd solution? In-Reply-To: <1244300613.17902.3.camel@developer.gxsnmp.org> References: <16720fe00906060737ue1d1371j735c681983038fe3@mail.gmail.com> <1244300613.17902.3.camel@developer.gxsnmp.org> Message-ID: <16720fe00906060805v48a8d448ke514f1336fe39736@mail.gmail.com> Gregory, So far i've received a few replies, one of them containing something of a tutorial. If it works i'll post my adaptation of it on the web for all to reference. Thanks, Jeff On Sat, Jun 6, 2009 at 11:03 AM, Gregory McLean wrote: > On Sat, 2009-06-06 at 10:37 -0400, Jeffrey Lyon wrote: >> NANOGers, >> >> Can someone please point me in the direction of an rwhoisd solution to >> be run on a CentOS Linux platform? ARIN is now punting rwhois queries >> to us and frankly i've been unable to find an easy to install/use >> solution to answer these queries. I've seen the rwhoisd at >> projects.arin.net but the documentation on it is ghastly to say the >> least. >> >> Hopefully someone knows of an easier solution or at least a tutorial somewhere? >> > If you happen to find one I'd like to know about it as well... > > > -- 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 peter at peter-dambier.de Sun Jun 7 17:16:12 2009 From: peter at peter-dambier.de (Peter Dambier) Date: Mon, 08 Jun 2009 00:16:12 +0200 Subject: EU elections - piratenpartei.net censored Message-ID: <4A2C3C2C.7020305@peter-dambier.de> Hello, right during the election the website piratenpartei.net of the german pirates party gets censored by the hoster. alfahosting.info Good advertising, isn't it? Interestingly enough their website is down too. Afraid of emails I guess. Kind regards Peter -- 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 a.harrowell at gmail.com Sun Jun 7 17:24:15 2009 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Sun, 7 Jun 2009 23:24:15 +0100 Subject: EU elections - piratenpartei.net censored In-Reply-To: <4A2C3C2C.7020305@peter-dambier.de> References: <4A2C3C2C.7020305@peter-dambier.de> Message-ID: <200906072324.31270.a.harrowell@gmail.com> On Sunday 07 June 2009 23:16:12 Peter Dambier wrote: > Hello, > > right during the election the website > > piratenpartei.net > > of the german pirates party gets censored by the hoster. > > alfahosting.info > > Good advertising, isn't it? > > Interestingly enough their website is down too. > Afraid of emails I guess. Perhaps the election night on which they finally won a seat might - MIGHT - have posed a few load issues? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part. URL: From arnold at nipper.de Sun Jun 7 17:27:29 2009 From: arnold at nipper.de (Arnold Nipper) Date: Mon, 08 Jun 2009 00:27:29 +0200 Subject: EU elections - piratenpartei.net censored In-Reply-To: <4A2C3C2C.7020305@peter-dambier.de> References: <4A2C3C2C.7020305@peter-dambier.de> Message-ID: <4A2C3ED1.2020302@nipper.de> On 08.06.2009 00:16 Peter Dambier wrote > right during the election the website > > piratenpartei.net > > of the german pirates party gets censored by the hoster. > really censored. Do you know why alfahosting.info turned down the site? > alfahosting.info > > Good advertising, isn't it? > > Interestingly enough their website is down too. > Afraid of emails I guess. > try http://www.piratenpartei.de/ instead. Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature URL: From peter at peter-dambier.de Sun Jun 7 17:36:46 2009 From: peter at peter-dambier.de (Peter Dambier) Date: Mon, 08 Jun 2009 00:36:46 +0200 Subject: EU elections - piratenpartei.net censored In-Reply-To: <4A2C3ED1.2020302@nipper.de> References: <4A2C3C2C.7020305@peter-dambier.de> <4A2C3ED1.2020302@nipper.de> Message-ID: <4A2C40FE.1010305@peter-dambier.de> Thank you Arnold. Yes, we have not put all our eggs in the same nest :) As far as we could find out somebody has put us into an adult filter. That is what triggered the reaction of the hoster. There is a movement of the governing parties in germany to install a mandatory adult filter controled only by a single policeman. That is excactly what the pirates party is opposing. Kind regards Peter Arnold Nipper wrote: > On 08.06.2009 00:16 Peter Dambier wrote > >> right during the election the website >> >> piratenpartei.net >> >> of the german pirates party gets censored by the hoster. >> > > really censored. Do you know why alfahosting.info turned down the site? > >> alfahosting.info >> >> Good advertising, isn't it? >> >> Interestingly enough their website is down too. >> Afraid of emails I guess. >> > > try http://www.piratenpartei.de/ instead. > > > > Arnold -- 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 nanog2 at adns.net Sun Jun 7 20:18:53 2009 From: nanog2 at adns.net (John Palmer (NANOG Acct)) Date: Sun, 7 Jun 2009 20:18:53 -0500 Subject: EU elections - piratenpartei.net censored References: <4A2C3C2C.7020305@peter-dambier.de> <4A2C3ED1.2020302@nipper.de> <4A2C40FE.1010305@peter-dambier.de> Message-ID: <421EC03E4C634673A1CCBDC310273F32@TAKA> Thats fine - but one thing that I can't tolerate about the Pirates party is this apparent non-sense that there should be no such thing as copyright. AFAIC, making an illegal download of software or music is stealing and is no different from going into a shop and shoplifting some merchandise. Someone is making a living from writing that code or making that music. John ----- Original Message ----- From: "Peter Dambier" To: Sent: Sunday, June 07, 2009 5:36 PM Subject: Re: EU elections - piratenpartei.net censored > Thank you Arnold. > > Yes, we have not put all our eggs in the same nest :) > > As far as we could find out somebody has put us into an adult filter. > That is what triggered the reaction of the hoster. > > There is a movement of the governing parties in germany to install > a mandatory adult filter controled only by a single policeman. > > That is excactly what the pirates party is opposing. > > Kind regards > Peter > > > Arnold Nipper wrote: >> On 08.06.2009 00:16 Peter Dambier wrote >> >>> right during the election the website >>> >>> piratenpartei.net >>> >>> of the german pirates party gets censored by the hoster. >>> >> >> really censored. Do you know why alfahosting.info turned down the site? >> >>> alfahosting.info >>> >>> Good advertising, isn't it? >>> >>> Interestingly enough their website is down too. >>> Afraid of emails I guess. >>> >> >> try http://www.piratenpartei.de/ instead. >> >> >> >> Arnold > > -- > 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 mikelieman at gmail.com Sun Jun 7 20:37:42 2009 From: mikelieman at gmail.com (Mike Lieman) Date: Sun, 7 Jun 2009 21:37:42 -0400 Subject: EU elections - piratenpartei.net censored In-Reply-To: <421EC03E4C634673A1CCBDC310273F32@TAKA> References: <4A2C3C2C.7020305@peter-dambier.de> <4A2C3ED1.2020302@nipper.de> <4A2C40FE.1010305@peter-dambier.de> <421EC03E4C634673A1CCBDC310273F32@TAKA> Message-ID: <43661d390906071837n749a023ajab0e75235e2b0ad6@mail.gmail.com> Copyright Laws, are just that. Laws. And the can be changed if The People desire it. The issue I see with copyright TODAY is that there is effectively no entry of anything into the Public Domain in any reasonable sort of time. Traditionally that's been the benefit derived by The People for giving special Copyright privileges. So what do The People get out of all this? There's that and the abuse, where content which clearly fails to advance neither Science nor Useful Arts -- the Constitutionally Mandated extent of Copyright authority granted to the Legislature -- is Copyrighted. What Science or Useful Art is Hannah Montana's latest CD advancing, making it worthy of special privilege? On Sun, Jun 7, 2009 at 9:18 PM, John Palmer (NANOG Acct) wrote: > Thats fine - but one thing that I can't tolerate about the Pirates party is > this > apparent non-sense that there should be no such thing as copyright. > AFAIC, making an illegal download of software or music is stealing and is > no different from going into a shop and shoplifting some merchandise. > > Someone is making a living from writing that code or making that music. > > John > ----- Original Message ----- From: "Peter Dambier" > > To: > Sent: Sunday, June 07, 2009 5:36 PM > Subject: Re: EU elections - piratenpartei.net censored > > > Thank you Arnold. >> >> Yes, we have not put all our eggs in the same nest :) >> >> As far as we could find out somebody has put us into an adult filter. >> That is what triggered the reaction of the hoster. >> >> There is a movement of the governing parties in germany to install >> a mandatory adult filter controled only by a single policeman. >> >> That is excactly what the pirates party is opposing. >> >> Kind regards >> Peter >> >> >> Arnold Nipper wrote: >> >>> On 08.06.2009 00:16 Peter Dambier wrote >>> >>> right during the election the website >>>> >>>> piratenpartei.net >>>> >>>> of the german pirates party gets censored by the hoster. >>>> >>>> >>> really censored. Do you know why alfahosting.info turned down the site? >>> >>> alfahosting.info >>>> >>>> Good advertising, isn't it? >>>> >>>> Interestingly enough their website is down too. >>>> Afraid of emails I guess. >>>> >>>> >>> try http://www.piratenpartei.de/ instead. >>> >>> >>> >>> Arnold >>> >> >> -- >> 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 awacs at ziskind.us Sun Jun 7 21:24:19 2009 From: awacs at ziskind.us (N. Yaakov Ziskind) Date: Sun, 7 Jun 2009 22:24:19 -0400 Subject: EU elections - piratenpartei.net censored In-Reply-To: <43661d390906071837n749a023ajab0e75235e2b0ad6@mail.gmail.com> References: <4A2C3C2C.7020305@peter-dambier.de> <4A2C3ED1.2020302@nipper.de> <4A2C40FE.1010305@peter-dambier.de> <421EC03E4C634673A1CCBDC310273F32@TAKA> <43661d390906071837n749a023ajab0e75235e2b0ad6@mail.gmail.com> Message-ID: <20090607222419.A26408@egps.egps.com> Why is there *never* a moderator around when you need one? :-) Mike Lieman wrote (on Sun, Jun 07, 2009 at 09:37:42PM -0400): > Copyright Laws, are just that. Laws. And the can be changed if The People > desire it. > > The issue I see with copyright TODAY is that there is effectively no entry > of anything into the Public Domain in any reasonable sort of time. > Traditionally that's been the benefit derived by The People for giving > special Copyright privileges. > > So what do The People get out of all this? > > There's that and the abuse, where content which clearly fails to advance > neither Science nor Useful Arts -- the Constitutionally Mandated extent of > Copyright authority granted to the Legislature -- is Copyrighted. > > What Science or Useful Art is Hannah Montana's latest CD advancing, making > it worthy of special privilege? > > On Sun, Jun 7, 2009 at 9:18 PM, John Palmer (NANOG Acct) wrote: > > > Thats fine - but one thing that I can't tolerate about the Pirates party is > > this > > apparent non-sense that there should be no such thing as copyright. > > AFAIC, making an illegal download of software or music is stealing and is > > no different from going into a shop and shoplifting some merchandise. > > > > Someone is making a living from writing that code or making that music. > > > > John > > ----- Original Message ----- From: "Peter Dambier" > > > > To: > > Sent: Sunday, June 07, 2009 5:36 PM > > Subject: Re: EU elections - piratenpartei.net censored > > > > > > Thank you Arnold. > >> > >> Yes, we have not put all our eggs in the same nest :) > >> > >> As far as we could find out somebody has put us into an adult filter. > >> That is what triggered the reaction of the hoster. > >> > >> There is a movement of the governing parties in germany to install > >> a mandatory adult filter controled only by a single policeman. > >> > >> That is excactly what the pirates party is opposing. > >> > >> Kind regards > >> Peter -- _________________________________________ Nachman Yaakov Ziskind, FSPA, LLM awacs at ziskind.us Attorney and Counselor-at-Law http://ziskind.us Economic Group Pension Services http://egps.com Actuaries and Employee Benefit Consultants From randy at psg.com Sun Jun 7 22:38:28 2009 From: randy at psg.com (Randy Bush) Date: Mon, 08 Jun 2009 12:38:28 +0900 Subject: EU elections - piratenpartei.net censored In-Reply-To: <20090607222419.A26408@egps.egps.com> References: <4A2C3C2C.7020305@peter-dambier.de> <4A2C3ED1.2020302@nipper.de> <4A2C40FE.1010305@peter-dambier.de> <421EC03E4C634673A1CCBDC310273F32@TAKA> <43661d390906071837n749a023ajab0e75235e2b0ad6@mail.gmail.com> <20090607222419.A26408@egps.egps.com> Message-ID: > Why is there *never* a moderator around when you need one? :-) people will reply to trolls. your delete key is probably kind of left of center of your keyboard. randy From joelja at bogus.com Mon Jun 8 08:53:04 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 08 Jun 2009 06:53:04 -0700 Subject: We need your lightning talks! Message-ID: <4A2D17C0.6080608@bogus.com> Folks, Lightning talk submissions are being accepted for the monday tuesday wednesday slots. Lightning talks are short (10 minutes), topical and timely. and done at the last minute. Submissions are made through the NANOG PC's talk submission tool: https://pc.nanog.org/login.php Unlike general session materials, they do not require the advanced submission of slides. Lightning talks submitted by jun 8 will be voted on by the PC on our call just prior to the start of nanog 46. Lightning talks will continue to be accepted through tuesday of the conference. The sooner you get your abstract in, the higher the probablity that we will be able to accept your talk. Thanks Joel From kysks at kornet.net Mon Jun 8 11:49:48 2009 From: kysks at kornet.net (kysks) Date: Tue, 9 Jun 2009 01:49:48 +0900 Subject: iBGP advertisement interval Message-ID: <00bf01c9e859$225d6810$ad037ea8@KTICARUS> Hello. Nanog I thought BGP advertisement interval is the following. ibgp : 5 second, ebgp : 30 second. But, now I realize that the default ibgp interval of Cisco is 0 second. (ios 12.0 & IOX) (it displays "Default minimum time between advertisement runs is 0 seconds") When did it change? ^^; I wonder if No interval time for bgp advertisement would bring insecure network by flapping network. Do you think I have to change the default value of interval time to longer? And I 'm curious about what the default value of Juniper router is. Because I have to implement with the Juniper and Cisco mixed. From jlewis at lewis.org Mon Jun 8 11:57:27 2009 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 8 Jun 2009 12:57:27 -0400 (EDT) Subject: iBGP advertisement interval In-Reply-To: <00bf01c9e859$225d6810$ad037ea8@KTICARUS> References: <00bf01c9e859$225d6810$ad037ea8@KTICARUS> Message-ID: On Tue, 9 Jun 2009, kysks wrote: > I thought BGP advertisement interval is the following. > > ibgp : 5 second, ebgp : 30 second. > > But, now I realize that the default ibgp interval of Cisco is 0 second. > (ios 12.0 & IOX) On the 6500, this seems to have been changed somewhere in the 12.2SX line. > When did it change? ^^; The answer to that probably depends on which platform/train you're interested in. > I wonder if No interval time for bgp advertisement would bring insecure > network by flapping network. More annoying, AFAIK, JunOS has a default update time of 0 for eBGP, and I'd imagine it's the same for iBGP. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jkrejci at usinternet.com Mon Jun 8 13:42:41 2009 From: jkrejci at usinternet.com (Justin Krejci) Date: Mon, 8 Jun 2009 13:42:41 -0500 Subject: Multi site BGP Routing design In-Reply-To: References: <4A29CD9A.3080902@ibctech.ca><005e01c9e67a$0c906cc0$0a00000a@nil.si><262b67200906060521v78c97463ta39229c397535862@mail.gmail.com> Message-ID: Thanks to all for the on and off list replies, they've been helpful. We get full BGP routes from all upstream connections (currently they are all different providers). The upstream bandwidth is cheaper at site 2 than at site 1 and the private backnet connection is a fixed cost so when previously considering the multi-ASN approach we would plan for each site using the other as a transit/gateway using eBGP but put preference on sending out via site 2 and maybe prepend site 1 AS on the local upstream SP so incoming favors site 2 as well (we're already doing this preferential routing anyways). I don't particularly care for the allow routes for our own ASN arrive from an upstream BGP session especially when it seems like all carriers would need to be cooperative on this, which may not be a big deal overall but adds another layer of complexity and difficulty if we change/add/remove carriers later on. What if they don't all support it, change their policies, or upgrade to a new version of router code that makes the default/expected behavior interfere. I am thinking the multiple ASN route is the cleanest but the idea of letting a default gateway (via static route maybe) out the local upstream connection to reach the other site when the backnet link is down sounds like it would work with minimal to no headaches but it just some how seems like a duct tape job. Does this sort of technique have any significant flaws or concerns associated with it? -----Original Message----- From: Adam Greene [mailto:maillist at webjogger.net] Sent: Saturday, June 06, 2009 8:38 AM To: nanog at nanog.org Subject: Re: Multi site BGP Routing design Hi all, We actually have a very similar setup to what Justin asked about, with the exception that we advertise only some of our netblocks to one provider and the rest to the other. If one of the providers fails, we then advertise all netblocks through the provider which is still up. If the private link between our two locations fails, the two halves of our network communicate via the Internet. >From what Justin described, I would think he would be able to keep a single ASN and configure his network so that if the private link goes down, the two newly disconnected halves of his network advertise only the netblocks they can still "see" (i.e. the ones on their half). As long as his internal network is set up with dynamic routing (iBGP / OSPF) the two halves should realize they have to get to the other half via the Internet. In our case, we don't get full routing tables from our providers, just default routes. Perhaps in Justin's case something as simple as a floating static route via the Internet to the other half of the network would take care of any ASN weirdness. It doesn't sound like he really needs his border routers to speak BGP with each other while the private link is down. If he wanted to remove the BGP session entirely under these circumstances, he could do the iBGP peering between RFC 1918 addresses and thus force the iBGP session to go down if the private link fails. Thanks, Adam ----- Original Message ----- From: "Saqib Ilyas" To: Sent: Saturday, June 06, 2009 8:21 AM Subject: Re: Multi site BGP Routing design > For a given interconnection between the upstream ISPs for the two site, > once > the direct link goes down, the time required for site A to learn the new > route to site B and vice versa would be different with the different > proposed solutions, right? > Thanks and best regards > > On Sat, Jun 6, 2009 at 12:40 PM, Ivan Pepelnjak wrote: > >> > To rephrase the OP's question, would it be BCP to acquire a >> > second ASN, and without further de-aggregating, continue >> > advertising each site's IP space to the DFZ, but from >> > dissimilar ASs as opposed to the same one? >> >> This would definitely be the best approach. You're not introducing new IP >> prefixes and you're not extending AS paths, so the net effect on the >> global >> BGP routing is zero (OK, you might have to use the 4 byte AS number :). >> >> Just make sure that both ISPs you connect to allow you to advertise >> "transit" prefixes. If site A public link goes down, but the private link >> is >> up, site B will advertise its own address space plus site A's address >> space >> with an extra AS number in the AS path (and the upstream ISP might filter >> that). >> >> Ivan >> >> http://www.ioshints.info/about >> http://blog.ioshints.info/ >> >> >> > > > -- > Muhammad Saqib Ilyas > PhD Student, Computer Science and Engineering > Lahore University of Management Sciences > > From deepak at ai.net Mon Jun 8 23:42:41 2009 From: deepak at ai.net (Deepak Jain) Date: Tue, 9 Jun 2009 00:42:41 -0400 Subject: Eye protection in DWDM systems -- what threshold? Message-ID: At what power level do DWDM systems become dangerous to work near (i.e. not staring into any optics, using light meters, etc)? I never see technicians on inside DWDM systems using eye protection, but I see power levels of amps going higher and higher. On a recent meter I saw almost .6mW... Any pointers to a document saying 1550nm becomes dangerous at xxxx dbM? Thanks in advance, DJ From joelja at bogus.com Tue Jun 9 00:25:24 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 08 Jun 2009 22:25:24 -0700 Subject: Eye protection in DWDM systems -- what threshold? In-Reply-To: References: Message-ID: <4A2DF244.7070201@bogus.com> There are erbium doped raman lasers with output of up to 10 watts continuous wave, they are (obviously) class 4 devices and are considered hazardous. 3r and 3b emitters shouldn't be directly exposed to the eye, and carry an appropriate warnings. the 10-80km stuff should all be 1 or 1m and does't merit the yellow triangle. Deepak Jain wrote: > At what power level do DWDM systems become dangerous to work near (i.e. not staring into any optics, using light meters, etc)? I never see technicians on inside DWDM systems using eye protection, but I see power levels of amps going higher and higher. On a recent meter I saw almost .6mW... > > Any pointers to a document saying 1550nm becomes dangerous at xxxx dbM? > > Thanks in advance, > > DJ From kevin.hodle at gmail.com Tue Jun 9 01:16:53 2009 From: kevin.hodle at gmail.com (Kevin Hodle) Date: Tue, 9 Jun 2009 01:16:53 -0500 Subject: Eye protection in DWDM systems -- what threshold? In-Reply-To: References: Message-ID: <9639597a0906082316m3068d20bk421c5887b4347ac1@mail.gmail.com> Hi Deepak, Most modern DWDM transponders with 160km network side optics will be launching anywhere from -2dBm to +2dBm depending on how warm the laser is, assuming a +2 dBm launch you are looking at around 1.6mW - not something you want to be exposing your eyes too. If you've also deployed EDFA's in your optical topology potentially adding another +20 dBm or so, its a good idea to start documenting expected optical power levels at each point in your topology for times when splice work or other maintenance work needs to be performed. To be on the safe side, the best policy is to simply shut down any light contributing lasers on a given strand when performing any kind of maintenance on that strand (design your optical topology with redundancy in mind, so you can seamlessly take light off a given path if need be). Modern gear usually comes equipped with a feature called ALS (Auto Laser Shutdown), where if an LOS condition is detected the laser is automatically shutdown. If your gear supports this, enable it. It could potentially save an ignorant tech's eyesight :). Cheers, Kevin Hodle On Mon, Jun 8, 2009 at 11:42 PM, Deepak Jain wrote: > > At what power level do DWDM systems become dangerous to work near (i.e. not staring into any optics, using light meters, etc)? I never see technicians on inside DWDM systems using eye protection, but I see power levels of amps going higher and higher. On a recent meter I saw almost .6mW... > > Any pointers to a document saying 1550nm becomes dangerous at xxxx dbM? > > Thanks in advance, > > DJ > From swmike at swm.pp.se Tue Jun 9 01:27:38 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 9 Jun 2009 08:27:38 +0200 (CEST) Subject: Eye protection in DWDM systems -- what threshold? In-Reply-To: <9639597a0906082316m3068d20bk421c5887b4347ac1@mail.gmail.com> References: <9639597a0906082316m3068d20bk421c5887b4347ac1@mail.gmail.com> Message-ID: On Tue, 9 Jun 2009, Kevin Hodle wrote: > Hi Deepak, > > Most modern DWDM transponders with 160km network side optics will > be launching anywhere from -2dBm to +2dBm depending on how warm the > laser is, assuming a +2 dBm launch you are looking at around 1.6mW - It might be good to note that there are ZX GBICs (120km variants) that are launching at +2 to +5, so you don't really need a DWDM system to achieve these levels. Care not to expose eyes to this light should be taken whenever handling optics of any kind. -- Mikael Abrahamsson email: swmike at swm.pp.se From david.freedman at uk.clara.net Tue Jun 9 05:43:02 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Tue, 09 Jun 2009 11:43:02 +0100 Subject: Eye protection in DWDM systems -- what threshold? In-Reply-To: References: Message-ID: I forget who the vendor is now, but their shelves are sealed with a door which, when opened, turns off all the lasers on the shelf so you can work on it, yes, a simple provisioning operation causes an outage / protection switchover!! Dave. Deepak Jain wrote: > At what power level do DWDM systems become dangerous to work near (i.e. not staring into any optics, using light meters, etc)? I never see technicians on inside DWDM systems using eye protection, but I see power levels of amps going higher and higher. On a recent meter I saw almost .6mW... > > Any pointers to a document saying 1550nm becomes dangerous at xxxx dbM? > > Thanks in advance, > > DJ > From rs at seastrom.com Tue Jun 9 11:37:09 2009 From: rs at seastrom.com (Robert E. Seastrom) Date: Tue, 09 Jun 2009 12:37:09 -0400 Subject: Eye protection in DWDM systems -- what threshold? In-Reply-To: (Deepak Jain's message of "Tue, 9 Jun 2009 00:42:41 -0400") References: Message-ID: <86ws7lcqiy.fsf@seastrom.com> Deepak Jain writes: > Any pointers to a document saying 1550nm becomes dangerous at xxxx dbM? Even -30 dBM would be pretty dangerous. You sure you don't mean dBm? ;-) -r From jeff-kell at utc.edu Tue Jun 9 11:43:09 2009 From: jeff-kell at utc.edu (Jeff Kell) Date: Tue, 09 Jun 2009 12:43:09 -0400 Subject: Eye protection in DWDM systems -- what threshold? In-Reply-To: <86ws7lcqiy.fsf@seastrom.com> References: <86ws7lcqiy.fsf@seastrom.com> Message-ID: <4A2E911D.4030506@utc.edu> Reminds me of the old warning/attention sign over a termination rack... WARNING: Do not look into laser with remaining eye. Jeff From patrick at ianai.net Tue Jun 9 11:44:19 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 9 Jun 2009 12:44:19 -0400 Subject: Eye protection in DWDM systems -- what threshold? In-Reply-To: <4A2E911D.4030506@utc.edu> References: <86ws7lcqiy.fsf@seastrom.com> <4A2E911D.4030506@utc.edu> Message-ID: <862DA379-1E50-40F6-BDA2-6504622792F5@ianai.net> On Jun 9, 2009, at 12:43 PM, Jeff Kell wrote: > Reminds me of the old warning/attention sign over a termination > rack... > > WARNING: Do not look into laser with remaining eye. It will be the last thing you never saw. -- TTFN, patrick From ras at e-gerbil.net Tue Jun 9 13:06:42 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Tue, 9 Jun 2009 13:06:42 -0500 Subject: Eye protection in DWDM systems -- what threshold? In-Reply-To: <4A2E911D.4030506@utc.edu> References: <86ws7lcqiy.fsf@seastrom.com> <4A2E911D.4030506@utc.edu> Message-ID: <20090609180642.GJ51443@gerbil.cluepon.net> On Tue, Jun 09, 2009 at 12:43:09PM -0400, Jeff Kell wrote: > Reminds me of the old warning/attention sign over a termination rack... > > WARNING: Do not look into laser with remaining eye. The only problem with those funny signs is they scare remote hands techs into never looking at a fiber because they don't want to try and understand the difference between a SX GBIC and a class 3 ultra longhaul amp. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From joesox at gmail.com Tue Jun 9 13:13:53 2009 From: joesox at gmail.com (JoeSox) Date: Tue, 9 Jun 2009 11:13:53 -0700 Subject: End User Internet Monitoring for Supervisor recommendations Message-ID: <785694cd0906091113n42a4fbe0o6681cece1f757d57@mail.gmail.com> I have a friend in a shop that is not running any robust Websense like applications. They are looking for a freeware solution or possibly inexpensive solution just for a few requests not for the entire company. I used one a while back but I since have lost the information and that PC that I dropped the application on has since been rebuilt. Does anyone have any recommendations that meet the following requirements: 1) A Supervisor can navigate to a url to see end user's internet activity. 2) Freeware or close to it -- Thank You, Joe From braaen at zcorum.com Tue Jun 9 13:19:51 2009 From: braaen at zcorum.com (Brian Raaen) Date: Tue, 09 Jun 2009 14:19:51 -0400 Subject: End User Internet Monitoring for Supervisor recommendations In-Reply-To: <785694cd0906091113n42a4fbe0o6681cece1f757d57@mail.gmail.com> References: <785694cd0906091113n42a4fbe0o6681cece1f757d57@mail.gmail.com> Message-ID: <4A2EA7C7.5060409@zcorum.com> Our Company has been doing some testing with Linux Untangled servers. http://www.untangle.com/ JoeSox wrote: > I have a friend in a shop that is not running any robust Websense like > applications. They are looking for a freeware solution or possibly > inexpensive solution just for a few requests not for the entire > company. I used one a while back but I since have lost the > information and that PC that I dropped the application on has since > been rebuilt. > > Does anyone have any recommendations that meet the following requirements: > 1) A Supervisor can navigate to a url to see end user's internet activity. > 2) Freeware or close to it > > -- ----------------- Brian Raaen Network Engineer email: /braaen at zcorum.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: braaen.vcf Type: text/x-vcard Size: 206 bytes Desc: not available URL: From patrick at ianai.net Tue Jun 9 13:21:46 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 9 Jun 2009 14:21:46 -0400 Subject: Eye protection in DWDM systems -- what threshold? In-Reply-To: <20090609180642.GJ51443@gerbil.cluepon.net> References: <86ws7lcqiy.fsf@seastrom.com> <4A2E911D.4030506@utc.edu> <20090609180642.GJ51443@gerbil.cluepon.net> Message-ID: <79592AD4-2B60-4E73-8B2D-AD38601EF38D@ianai.net> On Jun 9, 2009, at 2:06 PM, Richard A Steenbergen wrote: > On Tue, Jun 09, 2009 at 12:43:09PM -0400, Jeff Kell wrote: >> Reminds me of the old warning/attention sign over a termination >> rack... >> >> WARNING: Do not look into laser with remaining eye. > > The only problem with those funny signs is they scare remote hands > techs > into never looking at a fiber because they don't want to try and > understand the difference between a SX GBIC and a class 3 ultra > longhaul > amp. Honestly, that is probably better. Kinda like never pointing a gun at anyone, whether you think it is loaded or not. Put another way: I don't trust many H&E techs to know the difference between an SX GBIC and a Buck Rogers Laser Cannon. Besides, lots of lasers these days are infrared, so you can't see them anyway. (Hence the "last thing you never saw" comment.) -- TTFN, patrick From jjn at nuge.com Tue Jun 9 13:28:47 2009 From: jjn at nuge.com (Jay Nugent) Date: Tue, 9 Jun 2009 14:28:47 -0400 (EDT) Subject: End User Internet Monitoring for Supervisor recommendations In-Reply-To: <4A2EA7C7.5060409@zcorum.com> Message-ID: Greetings, On Tue, 9 Jun 2009, Brian Raaen wrote: > Our Company has been doing some testing with Linux Untangled servers. > http://www.untangle.com/ > > JoeSox wrote: > > I have a friend in a shop that is not running any robust Websense like > > applications. They are looking for a freeware solution or possibly > > inexpensive solution just for a few requests not for the entire > > company. I used one a while back but I since have lost the > > information and that PC that I dropped the application on has since > > been rebuilt. > > > > Does anyone have any recommendations that meet the following requirements: > > 1) A Supervisor can navigate to a url to see end user's internet activity. > > 2) Freeware or close to it Also take a look at NTOP. Let's ya see all workstation and router traffic on your LAN and can be viewed with a browser pointed to port :3000 --- Jay Nugent Train how you will Operate, and you will Operate how you were Trained. +------------------------------------------------------------------------+ | Jay Nugent jjn at nuge.com (734)484-5105 (734)649-0850/Cell | | Nugent Telecommunications [www.nuge.com] | | Internet Consulting/Linux SysAdmin/Engineering & Design/ISP Reseller | | ISP Monitoring [www.ispmonitor.org] ISP & Modem Performance Monitoring | | Web-Pegasus [www.webpegasus.com] Web Hosting/DNS Hosting/Shell Accts| +------------------------------------------------------------------------+ 2:01pm up 2 days, 7:15, 2 users, load average: 0.00, 0.03, 0.00 -------------- next part -------------- A non-text attachment was scrubbed... Name: braaen.vcf Type: text/x-vcard Size: 206 bytes Desc: URL: From bicknell at ufp.org Tue Jun 9 13:26:54 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 9 Jun 2009 14:26:54 -0400 Subject: Eye protection in DWDM systems -- what threshold? In-Reply-To: <20090609180642.GJ51443@gerbil.cluepon.net> References: <86ws7lcqiy.fsf@seastrom.com> <4A2E911D.4030506@utc.edu> <20090609180642.GJ51443@gerbil.cluepon.net> Message-ID: <20090609182654.GA2311@ussenterprise.ufp.org> In a message written on Tue, Jun 09, 2009 at 01:06:42PM -0500, Richard A Steenbergen wrote: > The only problem with those funny signs is they scare remote hands techs > into never looking at a fiber because they don't want to try and > understand the difference between a SX GBIC and a class 3 ultra longhaul > amp. Save your poor techs eyes, and make them more reliable all at the same time: http://search.newport.com/?sku=F-IRC2-F -- 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 dylan.ebner at crlmed.com Tue Jun 9 14:28:22 2009 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Tue, 9 Jun 2009 13:28:22 -0600 Subject: Traceroute management Message-ID: <6286FF05EBE33C4596F6C6C2376268670216017B@VS11.EXCHPROD.USA.NET> My company uses it's internet connection primarily for VPN tunneling. I have always wanted a tool that I can enter the peer ip addresses and it will every 8 or 12 hours run a traceroute and log it so I can build historical maps of the path our traffic is taking. Has anyone ever seen any apps like this, preferably something that is free. Thanks From scott at sberkman.net Tue Jun 9 14:45:27 2009 From: scott at sberkman.net (Scott Berkman) Date: Tue, 9 Jun 2009 15:45:27 -0400 Subject: Traceroute management In-Reply-To: <6286FF05EBE33C4596F6C6C2376268670216017B@VS11.EXCHPROD.USA.NET> References: <6286FF05EBE33C4596F6C6C2376268670216017B@VS11.EXCHPROD.USA.NET> Message-ID: <001401c9e93a$d7215270$8563f750$@net> Try SmokePing (which includes SmokeTrace now): http://oss.oetiker.ch/smokeping/ You could also just use a cronjob and output the results to a flat file or database if you prefer something home grown. -Scott -----Original Message----- From: Dylan Ebner [mailto:dylan.ebner at crlmed.com] Sent: Tuesday, June 09, 2009 3:28 PM To: nanog at nanog.org Subject: Traceroute management My company uses it's internet connection primarily for VPN tunneling. I have always wanted a tool that I can enter the peer ip addresses and it will every 8 or 12 hours run a traceroute and log it so I can build historical maps of the path our traffic is taking. Has anyone ever seen any apps like this, preferably something that is free. Thanks From Jason.Mishka at UToledo.Edu Tue Jun 9 15:06:24 2009 From: Jason.Mishka at UToledo.Edu (Mishka, Jason) Date: Tue, 9 Jun 2009 16:06:24 -0400 Subject: Traceroute management In-Reply-To: <001401c9e93a$d7215270$8563f750$@net> References: <6286FF05EBE33C4596F6C6C2376268670216017B@VS11.EXCHPROD.USA.NET> <001401c9e93a$d7215270$8563f750$@net> Message-ID: BGPlay might be what you are looking for. I believe you can replay certain time periods. http://bgplay.routeviews.org/bgplay/ Jason > -----Original Message----- > From: Scott Berkman [mailto:scott at sberkman.net] > Sent: Tuesday, June 09, 2009 3:45 PM > To: 'Dylan Ebner'; nanog at nanog.org > Subject: RE: Traceroute management > > Try SmokePing (which includes SmokeTrace now): > http://oss.oetiker.ch/smokeping/ > > You could also just use a cronjob and output the results to a flat file or > database if you prefer something home grown. > > -Scott > > -----Original Message----- > From: Dylan Ebner [mailto:dylan.ebner at crlmed.com] > Sent: Tuesday, June 09, 2009 3:28 PM > To: nanog at nanog.org > Subject: Traceroute management > > My company uses it's internet connection primarily for VPN tunneling. I > have always wanted a tool that I can enter the peer ip addresses and it > will every 8 or 12 hours run a traceroute and log it so I can build > historical maps of the path our traffic is taking. Has anyone ever seen > any apps like this, preferably something that is free. > > Thanks > > > From deepak at ai.net Tue Jun 9 15:06:58 2009 From: deepak at ai.net (Deepak Jain) Date: Tue, 09 Jun 2009 16:06:58 -0400 Subject: Eye protection in DWDM systems -- what threshold? In-Reply-To: <20090609182654.GA2311@ussenterprise.ufp.org> References: <86ws7lcqiy.fsf@seastrom.com> <4A2E911D.4030506@utc.edu> <20090609180642.GJ51443@gerbil.cluepon.net> <20090609182654.GA2311@ussenterprise.ufp.org> Message-ID: <4A2EC0E2.5050302@ai.net> Leo Bicknell wrote: > In a message written on Tue, Jun 09, 2009 at 01:06:42PM -0500, Richard A Steenbergen wrote: >> The only problem with those funny signs is they scare remote hands techs >> into never looking at a fiber because they don't want to try and >> understand the difference between a SX GBIC and a class 3 ultra longhaul >> amp. > > Save your poor techs eyes, and make them more reliable all at the same > time: > > http://search.newport.com/?sku=F-IRC2-F > This conversation has gone places I didn't expect. Leo, that card is pretty cool, but for a few hundred $$ more, you can get a light meter (if someone is smart enough to use the card...) Does anyone *use* any eye protection (other that not looking at the light, turning off the light etc) -- I mean like protective goggles, etc, when doing simple things like adding/removing patch cables from an SMF patch panel. I get that if you *know* the gear you are using has a Class 3 laser on it, you should be careful... but when you are patching it into a building's cable plant and some schmuck is patching the last leg in for you (or has pulled it accidentally, etc).. um, "don't look at it" is our community's BCP? DJ From arievayner at gmail.com Tue Jun 9 15:37:23 2009 From: arievayner at gmail.com (Arie Vayner) Date: Tue, 9 Jun 2009 23:37:23 +0300 Subject: Traceroute management In-Reply-To: <6286FF05EBE33C4596F6C6C2376268670216017B@VS11.EXCHPROD.USA.NET> References: <6286FF05EBE33C4596F6C6C2376268670216017B@VS11.EXCHPROD.USA.NET> Message-ID: <20b13c6b0906091337t5d5441c1v105841a66fa608a4@mail.gmail.com> Hmm, take a look at pingplotter Arie On Tue, Jun 9, 2009 at 10:28 PM, Dylan Ebner wrote: > My company uses it's internet connection primarily for VPN tunneling. I > have always wanted a tool that I can enter the peer ip addresses and it > will every 8 or 12 hours run a traceroute and log it so I can build > historical maps of the path our traffic is taking. Has anyone ever seen > any apps like this, preferably something that is free. > > Thanks > > From ip at ioshints.info Tue Jun 9 15:45:59 2009 From: ip at ioshints.info (Ivan Pepelnjak) Date: Tue, 9 Jun 2009 22:45:59 +0200 Subject: Multi site BGP Routing design In-Reply-To: References: <4A29CD9A.3080902@ibctech.ca><005e01c9e67a$0c906cc0$0a00000a@nil.si><262b67200906060521v78c97463ta39229c397535862@mail.gmail.com> Message-ID: <001e01c9e943$4c49dec0$0a00000a@nil.si> > I am thinking the multiple ASN route is the cleanest but the > idea of letting a default gateway (via static route maybe) > out the local upstream connection to reach the other site > when the backnet link is down sounds like it would work with > minimal to no headaches but it just some how seems like a > duct tape job. Does this sort of technique have any > significant flaws or concerns associated with it? It's a static route, so you're never sure the remote end (upstream router) is truly alive. In this respect, it would be much better to receive default route over BGP (if the upstream carrier is willing to implement it). On the other hand, it's a last-resort mechanism, so you'd only use it if everything else fails (and you don't care how reliable it is). Just make sure it's well documented and understood ... and think about what will happen when you add a third carrier to one of the sites. Last but not least, you could use reliable static routing (static route tied to ping tests). http://blog.ioshints.info/2007/02/reliable-static-routing.html http://blog.ioshints.info/search?q=static+routing Just my $0.002 :) Ivan http://www.ioshints.info/about http://blog.ioshints.info/ From ras at e-gerbil.net Tue Jun 9 16:26:42 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Tue, 9 Jun 2009 16:26:42 -0500 Subject: Eye protection in DWDM systems -- what threshold? In-Reply-To: <4A2EC0E2.5050302@ai.net> References: <86ws7lcqiy.fsf@seastrom.com> <4A2E911D.4030506@utc.edu> <20090609180642.GJ51443@gerbil.cluepon.net> <20090609182654.GA2311@ussenterprise.ufp.org> <4A2EC0E2.5050302@ai.net> Message-ID: <20090609212642.GO51443@gerbil.cluepon.net> On Tue, Jun 09, 2009 at 04:06:58PM -0400, Deepak Jain wrote: > > This conversation has gone places I didn't expect. Leo, that card is > pretty cool, but for a few hundred $$ more, you can get a light meter > (if someone is smart enough to use the card...) Now if only you could train people to use them... If I had a nickel for every time an Equinix tech has told me I'm sending them a +67dBm signal I'd be able to actually buy the laser to do that. > Does anyone *use* any eye protection (other that not looking at the > light, turning off the light etc) -- I mean like protective goggles, > etc, when doing simple things like adding/removing patch cables from an > SMF patch panel. > > I get that if you *know* the gear you are using has a Class 3 laser on > it, you should be careful... but when you are patching it into a > building's cable plant and some schmuck is patching the last leg in for > you (or has pulled it accidentally, etc).. um, "don't look at it" is our > community's BCP? Come on, the closest thing to a dangerous laser you're going to find in most colos is the laser pointer built in to the vendor pen schwag you picked up at the last beer and gear. The class 3 lasers are few and far between, and copiously labeled when you do come across them. Spend 5 minutes teaching people what the laser classes and how how to read the label. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From elmi at 4ever.de Tue Jun 9 16:28:20 2009 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 9 Jun 2009 23:28:20 +0200 Subject: Traceroute management In-Reply-To: <20b13c6b0906091337t5d5441c1v105841a66fa608a4@mail.gmail.com> References: <6286FF05EBE33C4596F6C6C2376268670216017B@VS11.EXCHPROD.USA.NET> <20b13c6b0906091337t5d5441c1v105841a66fa608a4@mail.gmail.com> Message-ID: <20090609212820.GS54150@ronin.4ever.de> arievayner at gmail.com (Arie Vayner) wrote: > Hmm, take a look at pingplotter From what I understand, Dylan is interested in something that archives traceroutes and compares them to former versions. The only tool I know that does this is something Gert D?ring (gert at space.net) hacked a couple of years ago. Maybe he'd share it with you. It's a Perl script capable of intelligently filtering hops and basically showing you when your packets take a new path to their destination. Cheers, Elmar. From joelja at bogus.com Tue Jun 9 16:44:53 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 09 Jun 2009 14:44:53 -0700 Subject: Eye protection in DWDM systems -- what threshold? In-Reply-To: <4A2EC0E2.5050302@ai.net> References: <86ws7lcqiy.fsf@seastrom.com> <4A2E911D.4030506@utc.edu> <20090609180642.GJ51443@gerbil.cluepon.net> <20090609182654.GA2311@ussenterprise.ufp.org> <4A2EC0E2.5050302@ai.net> Message-ID: <4A2ED7D5.8040704@bogus.com> Deepak Jain wrote: > Does anyone *use* any eye protection (other that not looking at the > light, turning off the light etc) -- I mean like protective goggles, > etc, when doing simple things like adding/removing patch cables from an > SMF patch panel. There are osha requirements and ansi standards. ANSI Z136.1 - Safe Use of Lasers ANSI Z136.2 - Safe Use of Lasers in Optical Fiber Communication Systems Utilizing Laser Diode and LED Sources > I get that if you *know* the gear you are using has a Class 3 laser on > it, you should be careful... but when you are patching it into a > building's cable plant and some schmuck is patching the last leg in for > you (or has pulled it accidentally, etc).. um, "don't look at it" is our > community's BCP? Actually that's pretty much the requirement for 3r, for 3b and 4 the requirements for eye protection and manual safety systems are much higher. All this high power stuff is rather rare (your cisco ons for example is a class 1 laser product), unless you terminate one end of a submarine system you'll likely never see a class 4 laser in this context. I tend to carry around extra dust protection boots in the tool bag to recover the exposed sc/st plugs that seem to accumulate in panels that people touch a lot, mostly, it protects the ends of the ferrules. > DJ > From kloch at kl.net Tue Jun 9 17:17:05 2009 From: kloch at kl.net (Kevin Loch) Date: Tue, 09 Jun 2009 18:17:05 -0400 Subject: Eye protection in DWDM systems -- what threshold? In-Reply-To: <20090609212642.GO51443@gerbil.cluepon.net> References: <86ws7lcqiy.fsf@seastrom.com> <4A2E911D.4030506@utc.edu> <20090609180642.GJ51443@gerbil.cluepon.net> <20090609182654.GA2311@ussenterprise.ufp.org> <4A2EC0E2.5050302@ai.net> <20090609212642.GO51443@gerbil.cluepon.net> Message-ID: <4A2EDF61.6010909@kl.net> > On Tue, Jun 09, 2009 at 04:06:58PM -0400, Deepak Jain wrote: >> This conversation has gone places I didn't expect. Leo, that card is >> pretty cool, but for a few hundred $$ more, you can get a light meter >> (if someone is smart enough to use the card...) In a pinch the camera on a MacBook pro can be used to detect presence of IR light. Here's light from a 10Gbase-LR xenpak: http://www.majhost.com/gallery/kl/Macbook/macbook-laser-camera.jpg It's easier to see when previewing in real time than in the static picture but it does require careful aim. - Kevin From vern at ee.lbl.gov Tue Jun 9 17:51:26 2009 From: vern at ee.lbl.gov (vern at ee.lbl.gov) Date: Tue, 09 Jun 2009 15:51:26 -0700 Subject: ICSI Netalyzr launch Message-ID: <200906092251.n59MpVP3025300@pork.ICSI.Berkeley.EDU> Folks, you might be interested in checking out a network monitoring tool we launched today, Netalyzr. It's a Java applet you can run by surfing to netalyzr.com. It aims to measure a bunch of the properties of and end user's network access, particularly looking for transparent modifications (e.g., hidden proxies), connectivity restrictions, and some security issues (e.g., whether the DNS resolver is vulnerable to the Kaminsky attack). We've had several thousand users run it today so far, so you may be hearing about reports your customers have gotten from it. You can see a sample report at: http://netalyzr.icsi.berkeley.edu/restore/id=example-session - Vern From meekjt at gmail.com Tue Jun 9 17:51:44 2009 From: meekjt at gmail.com (Jon Meek) Date: Tue, 9 Jun 2009 18:51:44 -0400 Subject: Traceroute management In-Reply-To: <20090609212820.GS54150@ronin.4ever.de> References: <6286FF05EBE33C4596F6C6C2376268670216017B@VS11.EXCHPROD.USA.NET> <20b13c6b0906091337t5d5441c1v105841a66fa608a4@mail.gmail.com> <20090609212820.GS54150@ronin.4ever.de> Message-ID: mon ( http://mon.wiki.kernel.org/index.php/Main_Page ) comes with traceroute.monitor It keeps a state file of current routes and logs only changes. You can specify equivalent hops, hops to ignore, StopAt addresses, and UnexpectedHops. Since it is part of mon, it is easy to alert on a route change. The IgnoreHop feature was probably added after the mon release. I can provide a newer version if IgnoreHop would be useful. Jon From tvhawaii at shaka.com Tue Jun 9 18:46:33 2009 From: tvhawaii at shaka.com (Michael Painter) Date: Tue, 9 Jun 2009 13:46:33 -1000 Subject: Eye protection in DWDM systems -- what threshold? References: <86ws7lcqiy.fsf@seastrom.com><4A2E911D.4030506@utc.edu> <20090609180642.GJ51443@gerbil.cluepon.net> <20090609182654.GA2311@ussenterprise.ufp.org> <4A2EC0E2.5050302@ai.net><20090609212642.GO51443@gerbil.cluepon.net> <4A2EDF61.6010909@kl.net> Message-ID: <9F3A8B912A97412688575D53C12C3934@DELL16> ----- Original Message ----- From: "Kevin Loch" Cc: Sent: Tuesday, June 09, 2009 12:17 PM Subject: Re: Eye protection in DWDM systems -- what threshold? > In a pinch the camera on a MacBook pro can be used to detect > presence of IR light. Here's light from a 10Gbase-LR xenpak: > > http://www.majhost.com/gallery/kl/Macbook/macbook-laser-camera.jpg > > It's easier to see when previewing in real time than > in the static picture but it does require careful aim. > > - Kevin Most 'cell phone' cameras also detect IR. Handy to verify that A/V equipment "Remotes" are working. --Michael From pace at jolokianetworks.com Wed Jun 10 03:19:30 2009 From: pace at jolokianetworks.com (Mark Pace) Date: Wed, 10 Jun 2009 01:19:30 -0700 Subject: Blackberry.net Email Administration Contact? Message-ID: <4A2F6C92.3080907@jolokianetworks.com> If anyone has a contact within Blackberry.net's email department, I'd greatly appreciate it if you could get me in touch with them. We're getting hundreds of connections a second from their mail servers and have had to block them. Thanks in advance, Mark Pace From lists at iamchriswallace.com Wed Jun 10 08:40:04 2009 From: lists at iamchriswallace.com (Chris Wallace) Date: Wed, 10 Jun 2009 09:40:04 -0400 Subject: Rwhoisd solution? In-Reply-To: <16720fe00906060737ue1d1371j735c681983038fe3@mail.gmail.com> References: <16720fe00906060737ue1d1371j735c681983038fe3@mail.gmail.com> Message-ID: I used this guide and it worked quite well. The writer was using FreeBSD but I installed onto Ubuntu and ran into little to no issues. http://www.unixadmin.cc/rwhois/ ---Chris On Jun 6, 2009, at 10:37 AM, Jeffrey Lyon wrote: > NANOGers, > > Can someone please point me in the direction of an rwhoisd solution to > be run on a CentOS Linux platform? ARIN is now punting rwhois queries > to us and frankly i've been unable to find an easy to install/use > solution to answer these queries. I've seen the rwhoisd at > projects.arin.net but the documentation on it is ghastly to say the > least. > > Hopefully someone knows of an easier solution or at least a tutorial > somewhere? > > -- > 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 nathan at robotics.net Wed Jun 10 10:31:32 2009 From: nathan at robotics.net (Nathan Stratton) Date: Wed, 10 Jun 2009 10:31:32 -0500 (CDT) Subject: Traceroute management In-Reply-To: <6286FF05EBE33C4596F6C6C2376268670216017B@VS11.EXCHPROD.USA.NET> References: <6286FF05EBE33C4596F6C6C2376268670216017B@VS11.EXCHPROD.USA.NET> Message-ID: On Tue, 9 Jun 2009, Dylan Ebner wrote: > My company uses it's internet connection primarily for VPN tunneling. I > have always wanted a tool that I can enter the peer ip addresses and it > will every 8 or 12 hours run a traceroute and log it so I can build > historical maps of the path our traffic is taking. Has anyone ever seen > any apps like this, preferably something that is free. We ended up writing our own, take a look at perl Net::Traceroute throw it in a DB with DBI and then graph it with graphviz. ><> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com From axisml at gmail.com Wed Jun 10 12:05:49 2009 From: axisml at gmail.com (Chris Stone) Date: Wed, 10 Jun 2009 11:05:49 -0600 Subject: Rwhoisd solution? In-Reply-To: References: <16720fe00906060737ue1d1371j735c681983038fe3@mail.gmail.com> Message-ID: <3047fef10906101005of0caf90hd911db2b27bc2ff2@mail.gmail.com> >> Can someone please point me in the direction of an rwhoisd solution to >> be run on a CentOS Linux platform? ARIN is now punting rwhois queries >> to us and frankly i've been unable to find an easy to install/use >> solution to answer these queries. I've seen the rwhoisd at >> projects.arin.net but the documentation on it is ghastly to say the >> least. If you use IPPlan to manage your IP allocations, it comes with a whois daemon that'll automagically use the information from your IPPlan sql database. Chris From dongsu.han at gmail.com Wed Jun 10 14:28:08 2009 From: dongsu.han at gmail.com (Dongsu Han) Date: Wed, 10 Jun 2009 15:28:08 -0400 Subject: Coax wiring. MoCA between neighbors. Message-ID: <4A300948.2040800@gmail.com> Hi All, I'm trying to find out how coax cables are wired in a residential area to each house. I found out that "drop amp" amplifies the signal just out side the building, and a few neighbors share the drop amp (basically a powered splitter). What other devices are there? I'm also trying to find out whether my neighbors would be able to overhear the MoCA signal from my apartment. Anyone knows the answer? For example, my apartment building has a cabinet that concentrates all coax cables from all units, and the 2~4 coax cables are attached to a device in the cabinet. I'm assuming it is a drop amp and I think MoCa signals can travel across the drop amp. Is my guess correct? Any comments on coax cable wiring between houses or apartments and MoCA technology would be very useful. Thank you, Dongsu From nazgul at somewhere.com Wed Jun 10 14:41:24 2009 From: nazgul at somewhere.com (Kee Hinckley) Date: Wed, 10 Jun 2009 15:41:24 -0400 Subject: Coax wiring. MoCA between neighbors. In-Reply-To: <4A300948.2040800@gmail.com> References: <4A300948.2040800@gmail.com> Message-ID: <51A0C81B-194B-471E-A0F6-9CF2C5B8AF02@somewhere.com> On Jun 10, 2009, at 3:28 PM, Dongsu Han wrote: > I'm also trying to find out whether my neighbors would be able to > overhear the MoCA signal from my apartment. Anyone knows the answer? I can't speak to what they are *supposed* to do, but my experience is that things can be overheard. Last summer I discovered that my Comcast cable had two premium digital channels I hadn't ordered. One was showing soft porn, and while I was sitting there pondering this, it began to fast forward. Not surprisingly, it was fast forwarding over the boring parts and then watching the naughty bits at normal speed. I can only assume that one of the neighboring houses has video-on-demand. From jhorstman at adknowledge.com Wed Jun 10 15:16:36 2009 From: jhorstman at adknowledge.com (Justin Horstman) Date: Wed, 10 Jun 2009 15:16:36 -0500 Subject: Coax wiring. MoCA between neighbors. In-Reply-To: <51A0C81B-194B-471E-A0F6-9CF2C5B8AF02@somewhere.com> References: <4A300948.2040800@gmail.com> <51A0C81B-194B-471E-A0F6-9CF2C5B8AF02@somewhere.com> Message-ID: I recall an Article that talked about this and found it quickly... http://www.slate.com/id/2167389 has some links and info you might find useful ~J -----Original Message----- From: Kee Hinckley [mailto:nazgul at somewhere.com] Sent: Wednesday, June 10, 2009 2:41 PM To: Dongsu Han Cc: nanog at nanog.org Subject: Re: Coax wiring. MoCA between neighbors. On Jun 10, 2009, at 3:28 PM, Dongsu Han wrote: > I'm also trying to find out whether my neighbors would be able to > overhear the MoCA signal from my apartment. Anyone knows the answer? I can't speak to what they are *supposed* to do, but my experience is that things can be overheard. Last summer I discovered that my Comcast cable had two premium digital channels I hadn't ordered. One was showing soft porn, and while I was sitting there pondering this, it began to fast forward. Not surprisingly, it was fast forwarding over the boring parts and then watching the naughty bits at normal speed. I can only assume that one of the neighboring houses has video-on-demand. From fjordan at hcs.net Wed Jun 10 15:28:21 2009 From: fjordan at hcs.net (Fred Jordan) Date: Wed, 10 Jun 2009 16:28:21 -0400 Subject: Traceroute management In-Reply-To: <6286FF05EBE33C4596F6C6C2376268670216017B@VS11.EXCHPROD.USA.NET> References: <6286FF05EBE33C4596F6C6C2376268670216017B@VS11.EXCHPROD.USA.NET> Message-ID: <4A301765.90007@hcs.net> Best thing I've seen is from the network guys at NCAR/UCAR. And it has the right price too! http://www.cisl.ucar.edu/nets/tools/trcheck/ Dylan Ebner wrote: > My company uses it's internet connection primarily for VPN tunneling. I > have always wanted a tool that I can enter the peer ip addresses and it > will every 8 or 12 hours run a traceroute and log it so I can build > historical maps of the path our traffic is taking. Has anyone ever seen > any apps like this, preferably something that is free. > > Thanks > > From dongsu.han at gmail.com Wed Jun 10 15:35:36 2009 From: dongsu.han at gmail.com (Dongsu Han) Date: Wed, 10 Jun 2009 16:35:36 -0400 Subject: Coax wiring. MoCA between neighbors. In-Reply-To: References: <4A300948.2040800@gmail.com> <51A0C81B-194B-471E-A0F6-9CF2C5B8AF02@somewhere.com> Message-ID: <4A301918.3070107@gmail.com> Thank you. Very interesting story and useful info. I'm also curious about the signal generated from customers from MoCA (multimedia over coax) devices. How many neighbors would be sharing the same coax medium? Does anybody have a guess? I'm guessing neighbors that are connected by the same drop amp would essentially be on the same wire. I would really appreciate any info. Thank you. -Dongsu Justin Horstman wrote: > I recall an Article that talked about this and found it quickly... > > http://www.slate.com/id/2167389 > > has some links and info you might find useful > > ~J > > > -----Original Message----- > From: Kee Hinckley [mailto:nazgul at somewhere.com] > Sent: Wednesday, June 10, 2009 2:41 PM > To: Dongsu Han > Cc: nanog at nanog.org > Subject: Re: Coax wiring. MoCA between neighbors. > > On Jun 10, 2009, at 3:28 PM, Dongsu Han wrote: > >> I'm also trying to find out whether my neighbors would be able to >> overhear the MoCA signal from my apartment. Anyone knows the answer? >> > > I can't speak to what they are *supposed* to do, but my experience is > that things can be overheard. Last summer I discovered that my Comcast > cable had two premium digital channels I hadn't ordered. One was > showing soft porn, and while I was sitting there pondering this, it > began to fast forward. Not surprisingly, it was fast forwarding over > the boring parts and then watching the naughty bits at normal speed. I > can only assume that one of the neighboring houses has video-on-demand. > > > From frnkblk at iname.com Wed Jun 10 15:44:12 2009 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 10 Jun 2009 15:44:12 -0500 Subject: Coax wiring. MoCA between neighbors. In-Reply-To: <4A300948.2040800@gmail.com> References: <4A300948.2040800@gmail.com> Message-ID: AFAIR, you can configure the MoCA adapters to a certain unique ID, not unlike garage door openers. In single-home settings there's usually enough cable loss that sharing is not a problem, but in an apartment complex, you may want to consider making sure there is a return trap on your cable so that only a select range of frequencies (the ones that your STB and cable modem use) can pass thru, and the higher range the MoCA uses does not. Frank -----Original Message----- From: Dongsu Han [mailto:dongsu.han at gmail.com] Sent: Wednesday, June 10, 2009 2:28 PM To: nanog at nanog.org Subject: Coax wiring. MoCA between neighbors. Hi All, I'm trying to find out how coax cables are wired in a residential area to each house. I found out that "drop amp" amplifies the signal just out side the building, and a few neighbors share the drop amp (basically a powered splitter). What other devices are there? I'm also trying to find out whether my neighbors would be able to overhear the MoCA signal from my apartment. Anyone knows the answer? For example, my apartment building has a cabinet that concentrates all coax cables from all units, and the 2~4 coax cables are attached to a device in the cabinet. I'm assuming it is a drop amp and I think MoCa signals can travel across the drop amp. Is my guess correct? Any comments on coax cable wiring between houses or apartments and MoCA technology would be very useful. Thank you, Dongsu From rmayer at vinotech.org Wed Jun 10 15:52:21 2009 From: rmayer at vinotech.org (Ralph Mayer) Date: Wed, 10 Jun 2009 22:52:21 +0200 Subject: Traceroute management In-Reply-To: <6286FF05EBE33C4596F6C6C2376268670216017B@VS11.EXCHPROD.USA.NET> References: <6286FF05EBE33C4596F6C6C2376268670216017B@VS11.EXCHPROD.USA.NET> Message-ID: <9dea07e00906101352r6b183a68xa34798bd02de7f7@mail.gmail.com> I use mtr with the "--report" and the "--report-cycles" switches + cron rm From pace at jolokianetworks.com Wed Jun 10 21:08:55 2009 From: pace at jolokianetworks.com (Mark Pace) Date: Wed, 10 Jun 2009 19:08:55 -0700 Subject: Blackberry.net Email Administration Contact? In-Reply-To: <4A2F6C92.3080907@jolokianetworks.com> References: <4A2F6C92.3080907@jolokianetworks.com> Message-ID: <4A306737.20401@jolokianetworks.com> At the moment it appears as tho the blackberry email storm has subsided. I thought I'd share a most excellent letter I got from Blackberry after one of the Nanog users was kind enough to forward my email along to them: > Hello Mark, > > Thank you for contacting BlackBerry Customer Support. > > We have determined that you purchased your BlackBerry product through one of our carrier partners. Your service provider fields general queries and provides technical support for all BlackBerry smartphone-related issues and can act as your first point of contact in these matters. > > You may also have the option to receive fee-based support directly from Research In Motion, the manufacturer and wireless experts for the BlackBerry solution. If you would like to learn more about this option, please dial the appropriate telephone number below and enter option 3 in the phone menu to be routed to BlackBerry Customer Care. > > If your organization has subscribed to BlackBerry Technical Support Services, please contact your IT department and have one of your named callers contact BlackBerry Technical Support. > > Note: BlackBerry Technical Support Services is an annual subscription program providing software maintenance and technical support services for your BlackBerry solution. Named callers are personnel within your organization who are authorized to contact our support staff. For more information on BlackBerry Technical Support Services, please visit: > > http://www.blackberry.com/support/tsupport/ > > All BlackBerry smartphone users have free access to the BlackBerry Technical Solution Center. The BlackBerry Technical Solution Center provides a repository of support information, documentation and frequently asked questions, with enhanced search capabilities so you can easily search for and find the BlackBerry support information you need. Please visit: > > http://na.blackberry.com/eng/support/ > > Thank you again for contacting us Mark and have a nice day. > > Sincerely, Lucky me! I can contact my non-existent carrier or I can pay for support on a product I don't own that is flooding my network! I feel privileged... pace Mark Pace wrote: > If anyone has a contact within Blackberry.net's email department, I'd > greatly appreciate it if you could get me in touch with them. We're > getting hundreds of connections a second from their mail servers and > have had to block them. > > > Thanks in advance, > Mark Pace > From morrowc.lists at gmail.com Wed Jun 10 21:14:47 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 10 Jun 2009 22:14:47 -0400 Subject: ICSI Netalyzr launch In-Reply-To: <200906092251.n59MpVP3025300@pork.ICSI.Berkeley.EDU> References: <200906092251.n59MpVP3025300@pork.ICSI.Berkeley.EDU> Message-ID: <75cb24520906101914i35d4c4abwe08eb69ddbf7e26a@mail.gmail.com> didn't want to spring for a cert for that eh? www.startssl.com ... hey lookie! free certs! On Tue, Jun 9, 2009 at 6:51 PM, wrote: > Folks, you might be interested in checking out a network monitoring > tool we launched today, Netalyzr. ?It's a Java applet you can run by > surfing to netalyzr.com. ?It aims to measure a bunch of the properties of > and end user's network access, particularly looking for transparent > modifications (e.g., hidden proxies), connectivity restrictions, and some > security issues (e.g., whether the DNS resolver is vulnerable to the > Kaminsky attack). > > We've had several thousand users run it today so far, so you may be hearing > about reports your customers have gotten from it. ?You can see a sample > report at: > > ? ? ? ?http://netalyzr.icsi.berkeley.edu/restore/id=example-session > > - Vern > > From vern at ee.lbl.gov Wed Jun 10 21:16:33 2009 From: vern at ee.lbl.gov (vern at ee.lbl.gov) Date: Wed, 10 Jun 2009 19:16:33 -0700 Subject: ICSI Netalyzr launch In-Reply-To: <75cb24520906101914i35d4c4abwe08eb69ddbf7e26a@mail.gmail.com> (Wed, 10 Jun 2009 22:14:47 EDT). Message-ID: <200906110216.n5B2GbaG018676@pork.ICSI.Berkeley.EDU> > didn't want to spring for a cert for that eh? www.startssl.com ... hey > lookie! free certs! ? We bought a cert from Thawte specifically so people wouldn't find that it's suspect. Does it look funny when your browser presents it to you? Vern From patrick at ianai.net Wed Jun 10 21:23:00 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 10 Jun 2009 22:23:00 -0400 Subject: ICSI Netalyzr launch In-Reply-To: <200906110216.n5B2GbaG018676@pork.ICSI.Berkeley.EDU> References: <200906110216.n5B2GbaG018676@pork.ICSI.Berkeley.EDU> Message-ID: On Jun 10, 2009, at 10:16 PM, vern at ee.lbl.gov wrote: >> didn't want to spring for a cert for that eh? www.startssl.com ... >> hey >> lookie! free certs! > > ? We bought a cert from Thawte specifically so people wouldn't find > that > it's suspect. Does it look funny when your browser presents it to > you? Yes. -- TTFN, patrick From nanog at daork.net Wed Jun 10 21:26:06 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 11 Jun 2009 14:26:06 +1200 Subject: ICSI Netalyzr launch In-Reply-To: <200906110216.n5B2GbaG018676@pork.ICSI.Berkeley.EDU> References: <200906110216.n5B2GbaG018676@pork.ICSI.Berkeley.EDU> Message-ID: <88553257-6137-4EA6-8B52-741EBDA04E83@daork.net> On 11/06/2009, at 2:16 PM, vern at ee.lbl.gov wrote: >> didn't want to spring for a cert for that eh? www.startssl.com ... >> hey >> lookie! free certs! > > ? We bought a cert from Thawte specifically so people wouldn't find > that > it's suspect. Does it look funny when your browser presents it to > you? I had the same problem, I'm not sure Christopher correctly diagnosed it. It looks like in Safari, when a Java applet asks for unrestricted access (as opposed to standard) it presents you with the security cert to confirm that you really want it. It says "This certificate is valid", as opposed to "invalid" or "untrusted" or whatever normally comes up. Screenshot of the GUI: http://don.braintrust.co.nz/~nward/netalyzr.png -- Nathan Ward From morrowc.lists at gmail.com Wed Jun 10 21:52:13 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 10 Jun 2009 22:52:13 -0400 Subject: ICSI Netalyzr launch In-Reply-To: <88553257-6137-4EA6-8B52-741EBDA04E83@daork.net> References: <200906110216.n5B2GbaG018676@pork.ICSI.Berkeley.EDU> <88553257-6137-4EA6-8B52-741EBDA04E83@daork.net> Message-ID: <75cb24520906101952i8122a99mcce9b2f128a80e01@mail.gmail.com> On Wed, Jun 10, 2009 at 10:26 PM, Nathan Ward wrote: > On 11/06/2009, at 2:16 PM, vern at ee.lbl.gov wrote: > >>> didn't want to spring for a cert for that eh? www.startssl.com ... hey >>> lookie! free certs! >> >> ? ?We bought a cert from Thawte specifically so people wouldn't find that >> it's suspect. ?Does it look funny when your browser presents it to you? > > > I had the same problem, I'm not sure Christopher correctly diagnosed it. > > It looks like in Safari, when a Java applet asks for unrestricted access (as > opposed to standard) it presents you with the security cert to confirm that > you really want it. It says "This certificate is valid", as opposed to > "invalid" or "untrusted" or whatever normally comes up. actually: 1) it's firefox 2) the error is from 'java' (looks like the same error as you get nathan) 3) it says: "This applet was signed by the 'International Computer Science Institute' , but Java canNOT verify the authenticity of the signature's certificate. Do you trust this certificate?" So... java fail, my-reading-skills-fail... -chris > > Screenshot of the GUI: > http://don.braintrust.co.nz/~nward/netalyzr.png From cgrundemann at gmail.com Wed Jun 10 22:11:10 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 10 Jun 2009 21:11:10 -0600 Subject: ICSI Netalyzr launch In-Reply-To: <200906092251.n59MpVP3025300@pork.ICSI.Berkeley.EDU> References: <200906092251.n59MpVP3025300@pork.ICSI.Berkeley.EDU> Message-ID: <443de7ad0906102011g2a95b71fx2da0297a5c0f4c9a@mail.gmail.com> On Tue, Jun 9, 2009 at 16:51, wrote: > Folks, you might be interested in checking out a network monitoring > tool we launched today, Netalyzr. ?It's a Java applet you can run by > surfing to netalyzr.com. ?It aims to measure a bunch of the properties of > and end user's network access, particularly looking for transparent > modifications (e.g., hidden proxies), connectivity restrictions, and some > security issues (e.g., whether the DNS resolver is vulnerable to the > Kaminsky attack). > > We've had several thousand users run it today so far, so you may be hearing > about reports your customers have gotten from it. ?You can see a sample > report at: > > ? ? ? ?http://netalyzr.icsi.berkeley.edu/restore/id=example-session > > - Vern > > Why no privacy policy? Or am I just partially blind? Is an answer in a FAQ legally binding? ~Chris -- Chris Grundemann weblog.chrisgrundemann.com www.twitter.com/chrisgrundemann www.coisoc.org From flintbarber at flintrock.com Wed Jun 10 23:01:59 2009 From: flintbarber at flintrock.com (Flint E. Barber) Date: Wed, 10 Jun 2009 22:01:59 -0600 Subject: Data Centers in LA - CRG West Message-ID: We are in the process of evaluating Equinix and CRG West in LA. Before we ink a deal, can anyone give some feedback on CRG West? I have had some minor direct operational experience with them in the past with a former employer. If anyone has some history with them; good, bad or informational on things to watch for throughout a lifecycle of a couple years with them would be appreciated. They seem pretty sound, but some things have cropped up as we have started looking at a possible contract. So if you have an opinion on the following please let me know on/off list as appropriate: Difficulties during contract phase other than terms. i.e. rights assignments, reps and warrants, etc.. Implementation issues during setup and install. Operational issues with HVAC/power/xcons/remote hands.. Any2 pitfalls. Integrity if issues arise. Comments would be welcome.. thanks! Regards, -Flint From mike at m5computersecurity.com Thu Jun 11 02:56:16 2009 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Thu, 11 Jun 2009 00:56:16 -0700 Subject: Any2 Exchange experiences to share? Message-ID: <20090611005616.6rzn9v13qgkcc8og@webmail.m5computersecurity.com> All, I am interested to hear any experiences with the Any2 Exchange at One Wilshire Blvd, especially regarding performance and reliability to the other exchange participants in comparison to routing to the same networks via Tier 1 transit providers. We are in San Diego and have easy access to the exchange via transport offered by our data center facility who does have physical presence at OWB, but *we* are not physically in OWB, ~4.5ms away and some $ for transport to OWB. All things considered, the cost will be about the same to route via Tier 1 transit providers from San Diego as it will be to transport to OWB to the exchange. The basic question is, "Does it improve my network enough to connect to the exchange?" Thank you for your help! Mike -- ************************************************************ Michael J. McCafferty M5 Hosting http://www.m5hosting.com ************************************************************ From justin at justinshore.com Thu Jun 11 08:46:45 2009 From: justin at justinshore.com (Justin Shore) Date: Thu, 11 Jun 2009 08:46:45 -0500 Subject: Cogent input Message-ID: <4A310AC5.5050701@justinshore.com> I'm in search of some information about Cogent, it's past, present and future. I've heard bits and pieces about Cogent's past over the years but by no means have I actively been keeping up. I'm aware of some (regular?) depeering issues. The NANOG archives have given me some additional insight into that (recurring?) problem. The reasoning behind the depeering events is a bit fuzzy though. I would be interested in people's opinion on whether or not they should be consider for upstream service based on this particular issue. Are there any reasonable mitigation measures available to Cogent downstreams if (when?) Cogent were to be depeered again? My understanding is that at least on previous depeering occasion, the depeering partner simply null-routed all prefixes being received via Cogent, creating a blackhole essentially. I also recall reading that this meant that prefixes being advertised and received by the depeering partner from other peers would still end up in the blackhole. The only solution I would see to this problem would be to shut down the BGP session with Cogent and rely on a 2nd upstream. Are there any other possible steps for mitigation in a depeering event? I also know that their bandwidth is extremely cheap. This of course creates an issue for technical folks when trying to justify other upstream options that cost significantly more but also don't have a damaging history of getting depeered. Does Cogent still have an issue with depeering? Are there any reasonable mitigation measures or should a downstream customer do any thing in particular to ready themselves for a depeering event? Does their low cost outweigh the risks? What are the specific risks? Thanks Justin From pstewart at nexicomgroup.net Thu Jun 11 08:55:06 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Thu, 11 Jun 2009 09:55:06 -0400 Subject: Cogent input In-Reply-To: <4A310AC5.5050701@justinshore.com> References: <4A310AC5.5050701@justinshore.com> Message-ID: Our experience with them was at least one major (longer than an hour) outages PER MONTH and many of those times they were black holing our routes in their network which was the most damaging aspect. The outages were one thing but when our routes still somehow managed to get advertised in their network (even though our BGP session was down) that really created issues. I have heard from some nearby folks who still have service that it's gotten better, but we are also in the "regional offering" when it comes to IP Transit and have sold connections to many former Cogent customers who were fed up and left. I have found with Cogent that you will get a LOT of varying opinions on them - there are several other players (at least in our market) that are priced very similar now and have a better history behind them..... The specific de-peering issues never effected us much due to enough diversity in our upstreams and a fair amount of direct/public peering... Thanks, Paul -----Original Message----- From: Justin Shore [mailto:justin at justinshore.com] Sent: Thursday, June 11, 2009 9:47 AM To: NANOG Subject: Cogent input I'm in search of some information about Cogent, it's past, present and future. I've heard bits and pieces about Cogent's past over the years but by no means have I actively been keeping up. I'm aware of some (regular?) depeering issues. The NANOG archives have given me some additional insight into that (recurring?) problem. The reasoning behind the depeering events is a bit fuzzy though. I would be interested in people's opinion on whether or not they should be consider for upstream service based on this particular issue. Are there any reasonable mitigation measures available to Cogent downstreams if (when?) Cogent were to be depeered again? My understanding is that at least on previous depeering occasion, the depeering partner simply null-routed all prefixes being received via Cogent, creating a blackhole essentially. I also recall reading that this meant that prefixes being advertised and received by the depeering partner from other peers would still end up in the blackhole. The only solution I would see to this problem would be to shut down the BGP session with Cogent and rely on a 2nd upstream. Are there any other possible steps for mitigation in a depeering event? I also know that their bandwidth is extremely cheap. This of course creates an issue for technical folks when trying to justify other upstream options that cost significantly more but also don't have a damaging history of getting depeered. Does Cogent still have an issue with depeering? Are there any reasonable mitigation measures or should a downstream customer do any thing in particular to ready themselves for a depeering event? Does their low cost outweigh the risks? What are the specific risks? Thanks 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 andy-nanog at bash.sh Thu Jun 11 09:01:59 2009 From: andy-nanog at bash.sh (Andrew Mulholland) Date: Thu, 11 Jun 2009 15:01:59 +0100 Subject: Cogent input In-Reply-To: References: <4A310AC5.5050701@justinshore.com> Message-ID: At $JOB-1 we used Cogent. Lots of horror stories had been heard about them. We didn't have such problems. Had nx1Gig from them. On the few occasions where we had some slight issues, I was happy to be able to get through to some one useful on the phone quickly, and not play pass the parcel with call centre operatives. and at least in the quantities we were buying they were significantly better value than others, which was the primary reason we went with them. andrew On Thu, Jun 11, 2009 at 2:55 PM, Paul Stewart wrote: > Our experience with them was at least one major (longer than an hour) > outages PER MONTH and many of those times they were black holing our > routes in their network which was the most damaging aspect. ?The outages > were one thing but when our routes still somehow managed to get > advertised in their network (even though our BGP session was down) that > really created issues. ?I have heard from some nearby folks who still > have service that it's gotten better, but we are also in the "regional > offering" when it comes to IP Transit and have sold connections to many > former Cogent customers who were fed up and left. > > I have found with Cogent that you will get a LOT of varying opinions on > them - there are several other players (at least in our market) that are > priced very similar now and have a better history behind them..... > > The specific de-peering issues never effected us much due to enough > diversity in our upstreams and a fair amount of direct/public peering... > > Thanks, > > Paul > > > > -----Original Message----- > From: Justin Shore [mailto:justin at justinshore.com] > Sent: Thursday, June 11, 2009 9:47 AM > To: NANOG > Subject: Cogent input > > I'm in search of some information about Cogent, it's past, present and > future. ?I've heard bits and pieces about Cogent's past over the years > but by no means have I actively been keeping up. > > I'm aware of some (regular?) depeering issues. ?The NANOG archives have > given me some additional insight into that (recurring?) problem. ?The > reasoning behind the depeering events is a bit fuzzy though. ?I would be > > interested in people's opinion on whether or not they should be consider > > for upstream service based on this particular issue. ?Are there any > reasonable mitigation measures available to Cogent downstreams if > (when?) Cogent were to be depeered again? ?My understanding is that at > least on previous depeering occasion, the depeering partner simply > null-routed all prefixes being received via Cogent, creating a blackhole > > essentially. ?I also recall reading that this meant that prefixes being > advertised and received by the depeering partner from other peers would > still end up in the blackhole. ?The only solution I would see to this > problem would be to shut down the BGP session with Cogent and rely on a > 2nd upstream. ?Are there any other possible steps for mitigation in a > depeering event? > > I also know that their bandwidth is extremely cheap. ?This of course > creates an issue for technical folks when trying to justify other > upstream options that cost significantly more but also don't have a > damaging history of getting depeered. > > Does Cogent still have an issue with depeering? ?Are there any > reasonable mitigation measures or should a downstream customer do any > thing in particular to ready themselves for a depeering event? ?Does > their low cost outweigh the risks? ?What are the specific risks? > > Thanks > ?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 mike at sentex.net Thu Jun 11 09:13:29 2009 From: mike at sentex.net (Mike Tancsa) Date: Thu, 11 Jun 2009 10:13:29 -0400 Subject: Cogent input In-Reply-To: References: <4A310AC5.5050701@justinshore.com> Message-ID: <200906111411.n5BEBXLY039931@lava.sentex.ca> At 10:01 AM 6/11/2009, Andrew Mulholland wrote: >We didn't have such problems. >Had nx1Gig from them. > >On the few occasions where we had some slight issues, I was happy to >be able to get through to some one useful on the phone quickly, and >not play pass the parcel with call centre operatives. This matches our experience as well. When there are issues, they are EASY to get a hold of and the people who answer the phone clueful and dedicated to dealing with IP issues, not "can I help you with your long distance bill".... Also, they are pretty good about keeping us informed about maintenance issues. I would not use them as a sole provider (why run your own AS if you only have one transit provider?) but certainly I am happy keeping them in the mix to date. We havent seen the same level of issues as some people in YYZ have seen, but I think that seems to be more on their 100Mb connections for some reason. On the gig service we are on, they are fairly reliable. Not quite as good as TATA/Teleglobe has been for us however. ---Mike From bclark at spectraaccess.com Thu Jun 11 09:17:10 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Thu, 11 Jun 2009 10:17:10 -0400 Subject: Cogent input In-Reply-To: References: <4A310AC5.5050701@justinshore.com> Message-ID: <1244729830.26816.29.camel@acer-laptop> I hate when these questions get asked, because as the saying goes..."a person happy with a service will only tell one other person, but a person unhappy with a service with tell ten other people". So I think a lot of times you'll get skewed responses...but with that said, we've been using Cogent now for a year and no complaints at all. Had some minor downtime back in April due to a hardware failure, but Cogent responded extremely quickly, scheduled an emergency maintainance and had us running rather quickly. Face it, hardware problems happen so I can't blame Cogent on the failure. The few times I've dealt with their tech support group I found 99% of them very knowledgeable and I know that when we initially turned on the link they went the extra mile to resolve some initial problems during the weekend time frame. My 2 cents and with any provider mileage will vary, Bret On Thu, 2009-06-11 at 15:01 +0100, Andrew Mulholland wrote: > At $JOB-1 we used Cogent. > > Lots of horror stories had been heard about them. > > We didn't have such problems. > > Had nx1Gig from them. > > On the few occasions where we had some slight issues, I was happy to > be able to get through to some one useful on the phone quickly, and > not play pass the parcel with call centre operatives. > > > and at least in the quantities we were buying they were significantly > better value than others, which was the primary reason we went with > them. > > > > andrew > > > > On Thu, Jun 11, 2009 at 2:55 PM, Paul Stewart wrote: > > Our experience with them was at least one major (longer than an hour) > > outages PER MONTH and many of those times they were black holing our > > routes in their network which was the most damaging aspect. The outages > > were one thing but when our routes still somehow managed to get > > advertised in their network (even though our BGP session was down) that > > really created issues. I have heard from some nearby folks who still > > have service that it's gotten better, but we are also in the "regional > > offering" when it comes to IP Transit and have sold connections to many > > former Cogent customers who were fed up and left. > > > > I have found with Cogent that you will get a LOT of varying opinions on > > them - there are several other players (at least in our market) that are > > priced very similar now and have a better history behind them..... > > > > The specific de-peering issues never effected us much due to enough > > diversity in our upstreams and a fair amount of direct/public peering... > > > > Thanks, > > > > Paul > > > > > > > > -----Original Message----- > > From: Justin Shore [mailto:justin at justinshore.com] > > Sent: Thursday, June 11, 2009 9:47 AM > > To: NANOG > > Subject: Cogent input > > > > I'm in search of some information about Cogent, it's past, present and > > future. I've heard bits and pieces about Cogent's past over the years > > but by no means have I actively been keeping up. > > > > I'm aware of some (regular?) depeering issues. The NANOG archives have > > given me some additional insight into that (recurring?) problem. The > > reasoning behind the depeering events is a bit fuzzy though. I would be > > > > interested in people's opinion on whether or not they should be consider > > > > for upstream service based on this particular issue. Are there any > > reasonable mitigation measures available to Cogent downstreams if > > (when?) Cogent were to be depeered again? My understanding is that at > > least on previous depeering occasion, the depeering partner simply > > null-routed all prefixes being received via Cogent, creating a blackhole > > > > essentially. I also recall reading that this meant that prefixes being > > advertised and received by the depeering partner from other peers would > > still end up in the blackhole. The only solution I would see to this > > problem would be to shut down the BGP session with Cogent and rely on a > > 2nd upstream. Are there any other possible steps for mitigation in a > > depeering event? > > > > I also know that their bandwidth is extremely cheap. This of course > > creates an issue for technical folks when trying to justify other > > upstream options that cost significantly more but also don't have a > > damaging history of getting depeered. > > > > Does Cogent still have an issue with depeering? Are there any > > reasonable mitigation measures or should a downstream customer do any > > thing in particular to ready themselves for a depeering event? Does > > their low cost outweigh the risks? What are the specific risks? > > > > Thanks > > 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 awacs at ziskind.us Thu Jun 11 09:22:53 2009 From: awacs at ziskind.us (N. Yaakov Ziskind) Date: Thu, 11 Jun 2009 10:22:53 -0400 Subject: Cogent input In-Reply-To: <4A310AC5.5050701@justinshore.com> References: <4A310AC5.5050701@justinshore.com> Message-ID: <20090611102253.C13038@egps.egps.com> Justin Shore wrote (on Thu, Jun 11, 2009 at 08:46:45AM -0500): > I'm in search of some information about Cogent, it's past, present and > future. I've heard bits and pieces about Cogent's past over the years > but by no means have I actively been keeping up. We've had Cogent for several years in NYC with no real problems. Their tech support is clueless (more than a month so far to get new IP's, for instance) but you can work around that. -- _________________________________________ Nachman Yaakov Ziskind, FSPA, LLM awacs at ziskind.us Attorney and Counselor-at-Law http://ziskind.us Economic Group Pension Services http://egps.com Actuaries and Employee Benefit Consultants From tme at americafree.tv Thu Jun 11 09:23:47 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 11 Jun 2009 10:23:47 -0400 Subject: Cogent input In-Reply-To: <200906111411.n5BEBXLY039931@lava.sentex.ca> References: <4A310AC5.5050701@justinshore.com> <200906111411.n5BEBXLY039931@lava.sentex.ca> Message-ID: On Jun 11, 2009, at 10:13 AM, Mike Tancsa wrote: > At 10:01 AM 6/11/2009, Andrew Mulholland wrote: > >> We didn't have such problems. > >> Had nx1Gig from them. >> >> On the few occasions where we had some slight issues, I was happy to >> be able to get through to some one useful on the phone quickly, and >> not play pass the parcel with call centre operatives. > > > This matches our experience as well. When there are issues, they are > EASY to get a hold of and the people who answer the phone clueful > and dedicated to dealing with IP issues, not "can I help you with > your long distance bill".... Also, they are pretty good about > keeping us informed about maintenance issues. I would not use them > as a sole provider (why run your own AS if you only have one transit > provider?) but certainly I am happy keeping them in the mix to date. > +1 from here. Marshall > We havent seen the same level of issues as some people in YYZ have > seen, but I think that seems to be more on their 100Mb connections > for some reason. On the gig service we are on, they are fairly > reliable. Not quite as good as TATA/Teleglobe has been for us > however. > > ---Mike > > From zak at yellowfiber.net Thu Jun 11 09:08:19 2009 From: zak at yellowfiber.net (Zak Thompson) Date: Thu, 11 Jun 2009 10:08:19 -0400 Subject: Cogent input In-Reply-To: <1244729830.26816.29.camel@acer-laptop> References: <4A310AC5.5050701@justinshore.com> <1244729830.26816.29.camel@acer-laptop> Message-ID: <872A476DA517EE428312FB7D5FF284BA1B6A9E@rstexchange02.yellowfiber.net> Overall I can't say cogent has been bad. They have been great with support and getting things completed. As far as outages go, maintenance here and there but they always give ample time via email on planned outages. Their network has improved a lot over the years and most customers can't tell if they are on cogent or Level3 for the most part. But as with every network no one single carrier will get the job done "the best". I can't think of the last.. unexpected outage we had in our POP with cogent. Overall recommended carrier now a days. Cost in terms of performance, you can get competitive rates from Level3 and a chunk of the tier2's out there that will go lower than cogents standard pricing model. Most seem to be in the same ball park +-1/Mbps. Zachary A. Thompson -----Original Message----- From: Bret Clark [mailto:bclark at spectraaccess.com] Sent: Thursday, June 11, 2009 10:17 AM To: NANOG Subject: Re: Cogent input I hate when these questions get asked, because as the saying goes..."a person happy with a service will only tell one other person, but a person unhappy with a service with tell ten other people". So I think a lot of times you'll get skewed responses...but with that said, we've been using Cogent now for a year and no complaints at all. Had some minor downtime back in April due to a hardware failure, but Cogent responded extremely quickly, scheduled an emergency maintainance and had us running rather quickly. Face it, hardware problems happen so I can't blame Cogent on the failure. The few times I've dealt with their tech support group I found 99% of them very knowledgeable and I know that when we initially turned on the link they went the extra mile to resolve some initial problems during the weekend time frame. My 2 cents and with any provider mileage will vary, Bret On Thu, 2009-06-11 at 15:01 +0100, Andrew Mulholland wrote: > At $JOB-1 we used Cogent. > > Lots of horror stories had been heard about them. > > We didn't have such problems. > > Had nx1Gig from them. > > On the few occasions where we had some slight issues, I was happy to > be able to get through to some one useful on the phone quickly, and > not play pass the parcel with call centre operatives. > > > and at least in the quantities we were buying they were significantly > better value than others, which was the primary reason we went with > them. > > > > andrew > > > > On Thu, Jun 11, 2009 at 2:55 PM, Paul Stewart wrote: > > Our experience with them was at least one major (longer than an hour) > > outages PER MONTH and many of those times they were black holing our > > routes in their network which was the most damaging aspect. The outages > > were one thing but when our routes still somehow managed to get > > advertised in their network (even though our BGP session was down) that > > really created issues. I have heard from some nearby folks who still > > have service that it's gotten better, but we are also in the "regional > > offering" when it comes to IP Transit and have sold connections to many > > former Cogent customers who were fed up and left. > > > > I have found with Cogent that you will get a LOT of varying opinions on > > them - there are several other players (at least in our market) that are > > priced very similar now and have a better history behind them..... > > > > The specific de-peering issues never effected us much due to enough > > diversity in our upstreams and a fair amount of direct/public peering... > > > > Thanks, > > > > Paul > > > > > > > > -----Original Message----- > > From: Justin Shore [mailto:justin at justinshore.com] > > Sent: Thursday, June 11, 2009 9:47 AM > > To: NANOG > > Subject: Cogent input > > > > I'm in search of some information about Cogent, it's past, present and > > future. I've heard bits and pieces about Cogent's past over the years > > but by no means have I actively been keeping up. > > > > I'm aware of some (regular?) depeering issues. The NANOG archives have > > given me some additional insight into that (recurring?) problem. The > > reasoning behind the depeering events is a bit fuzzy though. I would be > > > > interested in people's opinion on whether or not they should be consider > > > > for upstream service based on this particular issue. Are there any > > reasonable mitigation measures available to Cogent downstreams if > > (when?) Cogent were to be depeered again? My understanding is that at > > least on previous depeering occasion, the depeering partner simply > > null-routed all prefixes being received via Cogent, creating a blackhole > > > > essentially. I also recall reading that this meant that prefixes being > > advertised and received by the depeering partner from other peers would > > still end up in the blackhole. The only solution I would see to this > > problem would be to shut down the BGP session with Cogent and rely on a > > 2nd upstream. Are there any other possible steps for mitigation in a > > depeering event? > > > > I also know that their bandwidth is extremely cheap. This of course > > creates an issue for technical folks when trying to justify other > > upstream options that cost significantly more but also don't have a > > damaging history of getting depeered. > > > > Does Cogent still have an issue with depeering? Are there any > > reasonable mitigation measures or should a downstream customer do any > > thing in particular to ready themselves for a depeering event? Does > > their low cost outweigh the risks? What are the specific risks? > > > > Thanks > > 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 kratzers at pa.net Thu Jun 11 09:33:25 2009 From: kratzers at pa.net (Stephen Kratzer) Date: Thu, 11 Jun 2009 10:33:25 -0400 Subject: Cogent input In-Reply-To: <4A310AC5.5050701@justinshore.com> References: <4A310AC5.5050701@justinshore.com> Message-ID: <200906111033.26208.kratzers@pa.net> We've only recently started using Cogent transit, but it's been stable since its introduction 6 months ago. Turn-up was a bit rocky since we never received engineering details, and engineering was atypical in that two eBGP sessions were established, one just to advertise loopbacks, and another for the actual feed. The biggest issue we have with them is that they don't allow deaggregation. If you've been allocated a prefix of length yy, they'll accept only x.x.x.x/yy, not x.x.x.x/yy le 24. Yes, sometimes deaggregation is necessary or desirable even if only temporarily. And, they have no plans to support IPv6. "Cogent's official stance on IPv6 is that we will deploy IPv6 when it becomes a commercial necessity. We have tested IPv6 and we have our plan for rolling it out, but there are no commercial drivers to spend money to upgrade a network to IPv6 for no real return on investment." Stephen Kratzer Network Engineer CTI Networks, Inc. On Thursday 11 June 2009 09:46:45 Justin Shore wrote: > I'm in search of some information about Cogent, it's past, present and > future. I've heard bits and pieces about Cogent's past over the years > but by no means have I actively been keeping up. > > I'm aware of some (regular?) depeering issues. The NANOG archives have > given me some additional insight into that (recurring?) problem. The > reasoning behind the depeering events is a bit fuzzy though. I would be > interested in people's opinion on whether or not they should be consider > for upstream service based on this particular issue. Are there any > reasonable mitigation measures available to Cogent downstreams if > (when?) Cogent were to be depeered again? My understanding is that at > least on previous depeering occasion, the depeering partner simply > null-routed all prefixes being received via Cogent, creating a blackhole > essentially. I also recall reading that this meant that prefixes being > advertised and received by the depeering partner from other peers would > still end up in the blackhole. The only solution I would see to this > problem would be to shut down the BGP session with Cogent and rely on a > 2nd upstream. Are there any other possible steps for mitigation in a > depeering event? > > I also know that their bandwidth is extremely cheap. This of course > creates an issue for technical folks when trying to justify other > upstream options that cost significantly more but also don't have a > damaging history of getting depeered. > > Does Cogent still have an issue with depeering? Are there any > reasonable mitigation measures or should a downstream customer do any > thing in particular to ready themselves for a depeering event? Does > their low cost outweigh the risks? What are the specific risks? > > Thanks > Justin From kratzers at pa.net Thu Jun 11 09:33:25 2009 From: kratzers at pa.net (Stephen Kratzer) Date: Thu, 11 Jun 2009 10:33:25 -0400 Subject: Cogent input In-Reply-To: <4A310AC5.5050701@justinshore.com> References: <4A310AC5.5050701@justinshore.com> Message-ID: <200906111033.26208.kratzers@pa.net> We've only recently started using Cogent transit, but it's been stable since its introduction 6 months ago. Turn-up was a bit rocky since we never received engineering details, and engineering was atypical in that two eBGP sessions were established, one just to advertise loopbacks, and another for the actual feed. The biggest issue we have with them is that they don't allow deaggregation. If you've been allocated a prefix of length yy, they'll accept only x.x.x.x/yy, not x.x.x.x/yy le 24. Yes, sometimes deaggregation is necessary or desirable even if only temporarily. And, they have no plans to support IPv6. "Cogent's official stance on IPv6 is that we will deploy IPv6 when it becomes a commercial necessity. We have tested IPv6 and we have our plan for rolling it out, but there are no commercial drivers to spend money to upgrade a network to IPv6 for no real return on investment." Stephen Kratzer Network Engineer CTI Networks, Inc. On Thursday 11 June 2009 09:46:45 Justin Shore wrote: > I'm in search of some information about Cogent, it's past, present and > future. I've heard bits and pieces about Cogent's past over the years > but by no means have I actively been keeping up. > > I'm aware of some (regular?) depeering issues. The NANOG archives have > given me some additional insight into that (recurring?) problem. The > reasoning behind the depeering events is a bit fuzzy though. I would be > interested in people's opinion on whether or not they should be consider > for upstream service based on this particular issue. Are there any > reasonable mitigation measures available to Cogent downstreams if > (when?) Cogent were to be depeered again? My understanding is that at > least on previous depeering occasion, the depeering partner simply > null-routed all prefixes being received via Cogent, creating a blackhole > essentially. I also recall reading that this meant that prefixes being > advertised and received by the depeering partner from other peers would > still end up in the blackhole. The only solution I would see to this > problem would be to shut down the BGP session with Cogent and rely on a > 2nd upstream. Are there any other possible steps for mitigation in a > depeering event? > > I also know that their bandwidth is extremely cheap. This of course > creates an issue for technical folks when trying to justify other > upstream options that cost significantly more but also don't have a > damaging history of getting depeered. > > Does Cogent still have an issue with depeering? Are there any > reasonable mitigation measures or should a downstream customer do any > thing in particular to ready themselves for a depeering event? Does > their low cost outweigh the risks? What are the specific risks? > > Thanks > Justin From kratzers at pa.net Thu Jun 11 09:35:13 2009 From: kratzers at pa.net (Stephen Kratzer) Date: Thu, 11 Jun 2009 10:35:13 -0400 Subject: Cogent input In-Reply-To: <200906111033.26208.kratzers@pa.net> References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> Message-ID: <200906111035.13326.kratzers@pa.net> Should have said "And, they have no plans to deploy IPv6 in the immediate future." On Thursday 11 June 2009 10:33:25 Stephen Kratzer wrote: > We've only recently started using Cogent transit, but it's been stable > since its introduction 6 months ago. Turn-up was a bit rocky since we never > received engineering details, and engineering was atypical in that two eBGP > sessions were established, one just to advertise loopbacks, and another for > the actual feed. The biggest issue we have with them is that they don't > allow deaggregation. If you've been allocated a prefix of length yy, > they'll accept only x.x.x.x/yy, not x.x.x.x/yy le 24. Yes, sometimes > deaggregation is necessary or desirable even if only temporarily. > > And, they have no plans to support IPv6. > > "Cogent's official stance on IPv6 is that we will deploy IPv6 when it > becomes a commercial necessity. We have tested IPv6 and we have our plan > for rolling it out, but there are no commercial drivers to spend money > to upgrade a network to IPv6 for no real return on investment." > > Stephen Kratzer > Network Engineer > CTI Networks, Inc. > > On Thursday 11 June 2009 09:46:45 Justin Shore wrote: > > I'm in search of some information about Cogent, it's past, present and > > future. I've heard bits and pieces about Cogent's past over the years > > but by no means have I actively been keeping up. > > > > I'm aware of some (regular?) depeering issues. The NANOG archives have > > given me some additional insight into that (recurring?) problem. The > > reasoning behind the depeering events is a bit fuzzy though. I would be > > interested in people's opinion on whether or not they should be consider > > for upstream service based on this particular issue. Are there any > > reasonable mitigation measures available to Cogent downstreams if > > (when?) Cogent were to be depeered again? My understanding is that at > > least on previous depeering occasion, the depeering partner simply > > null-routed all prefixes being received via Cogent, creating a blackhole > > essentially. I also recall reading that this meant that prefixes being > > advertised and received by the depeering partner from other peers would > > still end up in the blackhole. The only solution I would see to this > > problem would be to shut down the BGP session with Cogent and rely on a > > 2nd upstream. Are there any other possible steps for mitigation in a > > depeering event? > > > > I also know that their bandwidth is extremely cheap. This of course > > creates an issue for technical folks when trying to justify other > > upstream options that cost significantly more but also don't have a > > damaging history of getting depeered. > > > > Does Cogent still have an issue with depeering? Are there any > > reasonable mitigation measures or should a downstream customer do any > > thing in particular to ready themselves for a depeering event? Does > > their low cost outweigh the risks? What are the specific risks? > > > > Thanks > > Justin From kratzers at pa.net Thu Jun 11 09:35:13 2009 From: kratzers at pa.net (Stephen Kratzer) Date: Thu, 11 Jun 2009 10:35:13 -0400 Subject: Cogent input In-Reply-To: <200906111033.26208.kratzers@pa.net> References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> Message-ID: <200906111035.13326.kratzers@pa.net> Should have said "And, they have no plans to deploy IPv6 in the immediate future." On Thursday 11 June 2009 10:33:25 Stephen Kratzer wrote: > We've only recently started using Cogent transit, but it's been stable > since its introduction 6 months ago. Turn-up was a bit rocky since we never > received engineering details, and engineering was atypical in that two eBGP > sessions were established, one just to advertise loopbacks, and another for > the actual feed. The biggest issue we have with them is that they don't > allow deaggregation. If you've been allocated a prefix of length yy, > they'll accept only x.x.x.x/yy, not x.x.x.x/yy le 24. Yes, sometimes > deaggregation is necessary or desirable even if only temporarily. > > And, they have no plans to support IPv6. > > "Cogent's official stance on IPv6 is that we will deploy IPv6 when it > becomes a commercial necessity. We have tested IPv6 and we have our plan > for rolling it out, but there are no commercial drivers to spend money > to upgrade a network to IPv6 for no real return on investment." > > Stephen Kratzer > Network Engineer > CTI Networks, Inc. > > On Thursday 11 June 2009 09:46:45 Justin Shore wrote: > > I'm in search of some information about Cogent, it's past, present and > > future. I've heard bits and pieces about Cogent's past over the years > > but by no means have I actively been keeping up. > > > > I'm aware of some (regular?) depeering issues. The NANOG archives have > > given me some additional insight into that (recurring?) problem. The > > reasoning behind the depeering events is a bit fuzzy though. I would be > > interested in people's opinion on whether or not they should be consider > > for upstream service based on this particular issue. Are there any > > reasonable mitigation measures available to Cogent downstreams if > > (when?) Cogent were to be depeered again? My understanding is that at > > least on previous depeering occasion, the depeering partner simply > > null-routed all prefixes being received via Cogent, creating a blackhole > > essentially. I also recall reading that this meant that prefixes being > > advertised and received by the depeering partner from other peers would > > still end up in the blackhole. The only solution I would see to this > > problem would be to shut down the BGP session with Cogent and rely on a > > 2nd upstream. Are there any other possible steps for mitigation in a > > depeering event? > > > > I also know that their bandwidth is extremely cheap. This of course > > creates an issue for technical folks when trying to justify other > > upstream options that cost significantly more but also don't have a > > damaging history of getting depeered. > > > > Does Cogent still have an issue with depeering? Are there any > > reasonable mitigation measures or should a downstream customer do any > > thing in particular to ready themselves for a depeering event? Does > > their low cost outweigh the risks? What are the specific risks? > > > > Thanks > > Justin From steve at ibctech.ca Thu Jun 11 09:37:40 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 11 Jun 2009 10:37:40 -0400 Subject: Cogent input In-Reply-To: <200906111033.26208.kratzers@pa.net> References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> Message-ID: <4A3116B4.1090208@ibctech.ca> Stephen Kratzer wrote: > And, they have no plans to support IPv6. Ouch! I hope this is a non-starter for a lot of folks. Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From tore at linpro.no Thu Jun 11 09:44:43 2009 From: tore at linpro.no (Tore Anderson) Date: Thu, 11 Jun 2009 16:44:43 +0200 Subject: Cogent input In-Reply-To: <4A310AC5.5050701@justinshore.com> References: <4A310AC5.5050701@justinshore.com> Message-ID: <4A31185B.4020808@linpro.no> Hi Justin, > I'm in search of some information about Cogent, it's past, present and > future. I've heard bits and pieces about Cogent's past over the years > but by no means have I actively been keeping up. We recently got a 10-gig port in Oslo from them. Price-wise they were competitive but absolutely not in a leauge of their own - a couple of other large providers matched their offers. In the end the main differencing factor for us was that their PoP happened to be in the same building as our data centre, so no local access was required (unlike the others). The link hasn't been up for very long so I can't comment on long-term reliability issues, but so far I've been _very_ happy with them, everything was up and running just a couple of days after we ordered, and the staff we've had contact with have been knowledgeable and helpful. The service has performed as expected: latency has been low and I haven't noticed any sub-optimal routing (trampolines) or packet loss. We multihome, so we're not too concerned about potential de-peerings. I would not single-home to any of the transit-free networks anyway, as any of them could end up on the receiving end of a de-peering. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From bclark at spectraaccess.com Thu Jun 11 09:49:13 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Thu, 11 Jun 2009 10:49:13 -0400 Subject: Cogent input In-Reply-To: <4A3116B4.1090208@ibctech.ca> References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> <4A3116B4.1090208@ibctech.ca> Message-ID: <1244731753.26816.34.camel@acer-laptop> I'm skeptical as to where this info came from since this seems nothing more then nay-say? if people are going to make grandiose statements then they should justify them with reputable evidence. I would be extremely surprised if Cogent engineering isn't working on a IPv6 plan or doesn't have one already in place. Bret On Thu, 2009-06-11 at 10:37 -0400, Steve Bertrand wrote: > Stephen Kratzer wrote: > > > And, they have no plans to support IPv6. > > Ouch! > > I hope this is a non-starter for a lot of folks. > > Steve From bclark at spectraaccess.com Thu Jun 11 09:49:13 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Thu, 11 Jun 2009 10:49:13 -0400 Subject: Cogent input In-Reply-To: <4A3116B4.1090208@ibctech.ca> References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> <4A3116B4.1090208@ibctech.ca> Message-ID: <1244731753.26816.34.camel@acer-laptop> I'm skeptical as to where this info came from since this seems nothing more then nay-say? if people are going to make grandiose statements then they should justify them with reputable evidence. I would be extremely surprised if Cogent engineering isn't working on a IPv6 plan or doesn't have one already in place. Bret On Thu, 2009-06-11 at 10:37 -0400, Steve Bertrand wrote: > Stephen Kratzer wrote: > > > And, they have no plans to support IPv6. > > Ouch! > > I hope this is a non-starter for a lot of folks. > > Steve From mhernand1 at comcast.net Thu Jun 11 09:49:23 2009 From: mhernand1 at comcast.net (manolo) Date: Thu, 11 Jun 2009 10:49:23 -0400 Subject: Cogent input In-Reply-To: <200906111035.13326.kratzers@pa.net> References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> <200906111035.13326.kratzers@pa.net> Message-ID: <4A311973.5000308@comcast.net> Stephen Kratzer wrote: > Should have said "And, they have no plans to deploy IPv6 in the immediate > future." > > On Thursday 11 June 2009 10:33:25 Stephen Kratzer wrote: > >> We've only recently started using Cogent transit, but it's been stable >> since its introduction 6 months ago. Turn-up was a bit rocky since we never >> received engineering details, and engineering was atypical in that two eBGP >> sessions were established, one just to advertise loopbacks, and another for >> the actual feed. The biggest issue we have with them is that they don't >> allow deaggregation. If you've been allocated a prefix of length yy, >> they'll accept only x.x.x.x/yy, not x.x.x.x/yy le 24. Yes, sometimes >> deaggregation is necessary or desirable even if only temporarily. >> >> And, they have no plans to support IPv6. >> >> "Cogent's official stance on IPv6 is that we will deploy IPv6 when it >> becomes a commercial necessity. We have tested IPv6 and we have our plan >> for rolling it out, but there are no commercial drivers to spend money >> to upgrade a network to IPv6 for no real return on investment." >> >> Stephen Kratzer >> Network Engineer >> CTI Networks, Inc. >> >> On Thursday 11 June 2009 09:46:45 Justin Shore wrote: >> >>> I'm in search of some information about Cogent, it's past, present and >>> future. I've heard bits and pieces about Cogent's past over the years >>> but by no means have I actively been keeping up. >>> >>> I'm aware of some (regular?) depeering issues. The NANOG archives have >>> given me some additional insight into that (recurring?) problem. The >>> reasoning behind the depeering events is a bit fuzzy though. I would be >>> interested in people's opinion on whether or not they should be consider >>> for upstream service based on this particular issue. Are there any >>> reasonable mitigation measures available to Cogent downstreams if >>> (when?) Cogent were to be depeered again? My understanding is that at >>> least on previous depeering occasion, the depeering partner simply >>> null-routed all prefixes being received via Cogent, creating a blackhole >>> essentially. I also recall reading that this meant that prefixes being >>> advertised and received by the depeering partner from other peers would >>> still end up in the blackhole. The only solution I would see to this >>> problem would be to shut down the BGP session with Cogent and rely on a >>> 2nd upstream. Are there any other possible steps for mitigation in a >>> depeering event? >>> >>> I also know that their bandwidth is extremely cheap. This of course >>> creates an issue for technical folks when trying to justify other >>> upstream options that cost significantly more but also don't have a >>> damaging history of getting depeered. >>> >>> Does Cogent still have an issue with depeering? Are there any >>> reasonable mitigation measures or should a downstream customer do any >>> thing in particular to ready themselves for a depeering event? Does >>> their low cost outweigh the risks? What are the specific risks? >>> >>> Thanks >>> Justin >>> > > > > > In Europe they have been good and stable most of the time. In the US well, they are cogent and I have so many bad experiences with them here I cannot in all honestly recommend them. But if your looking for cheap bandwidth to complement another provider its not an unreasonable thing to do as they price point is competitive. Manolo From cra at WPI.EDU Thu Jun 11 09:50:05 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 11 Jun 2009 10:50:05 -0400 Subject: Cogent input In-Reply-To: <872A476DA517EE428312FB7D5FF284BA1B6A9E@rstexchange02.yellowfiber.net> References: <1244729830.26816.29.camel@acer-laptop> <872A476DA517EE428312FB7D5FF284BA1B6A9E@rstexchange02.yellowfiber.net> Message-ID: <20090611145005.GD21110@angus.ind.WPI.EDU> We've been using Cogent for 4 months now and I have no major complaints. From tore at linpro.no Thu Jun 11 09:56:06 2009 From: tore at linpro.no (Tore Anderson) Date: Thu, 11 Jun 2009 16:56:06 +0200 Subject: Cogent input In-Reply-To: <200906111033.26208.kratzers@pa.net> References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> Message-ID: <4A311B06.9010606@linpro.no> Hello, * Stephen Kratzer > We've only recently started using Cogent transit, but it's been > stable since its introduction 6 months ago. Turn-up was a bit rocky > since we never received engineering details, and engineering was > atypical in that two eBGP sessions were established, one just to > advertise loopbacks, and another for the actual feed. The biggest > issue we have with them is that they don't allow deaggregation. If > you've been allocated a prefix of length yy, they'll accept only > x.x.x.x/yy, not x.x.x.x/yy le 24. Yes, sometimes deaggregation is > necessary or desirable even if only temporarily. Interesting. I requested exactly that when filling in their BGP questionnaire, and they set it up - no questions asked. Also, we have a perfectly normal single BGP session. The loopback address of the router we're connected to is found within the 38.0.0.0/8 prefix, which they announce to us over that session like any other route. > And, they have no plans to support IPv6. I have been promised, in writing, that they will provide us with native IPv6 transit before the end of the year. I'm based in Europe, though. Perhaps they're more flexible and customer-friendly here than in the US? Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From bdfleming at kanren.net Thu Jun 11 09:59:09 2009 From: bdfleming at kanren.net (Brad Fleming) Date: Thu, 11 Jun 2009 09:59:09 -0500 Subject: Cogent input In-Reply-To: <200906111033.26208.kratzers@pa.net> References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> Message-ID: On Jun 11, 2009, at 9:33 AM, Stephen Kratzer wrote: > The biggest issue we have with them is that they don't allow > deaggregation. If you've been allocated a prefix of length yy, > they'll accept > only x.x.x.x/yy, not x.x.x.x/yy le 24. Yes, sometimes deaggregation is > necessary or desirable even if only temporarily. In our peering session with Cogent, we requested several /16 le /24 prefixes configured and received no pushback or problems. We are using their 1Gbps service so I'm not sure if that buys us additional leeway with requests like this or not. We've been customers for nearly two full years and intend to continue for at least a third. -brad fleming From kratzers at pa.net Thu Jun 11 10:03:21 2009 From: kratzers at pa.net (Stephen Kratzer) Date: Thu, 11 Jun 2009 11:03:21 -0400 Subject: Cogent input In-Reply-To: <1244731753.26816.34.camel@acer-laptop> References: <4A310AC5.5050701@justinshore.com> <4A3116B4.1090208@ibctech.ca> <1244731753.26816.34.camel@acer-laptop> Message-ID: <200906111103.22079.kratzers@pa.net> Perhaps you missed my quote: "Cogent's official stance on IPv6 is that we will deploy IPv6 when it becomes a commercial necessity. We have tested IPv6 and we have our plan for rolling it out, but there are no commercial drivers to spend money to upgrade a network to IPv6 for no real return on investment." This came rom a contact at Cogent (not sure of the role, probably sales rep). On Thursday 11 June 2009 10:49:13 Bret Clark wrote: > I'm skeptical as to where this info came from since this seems nothing > more then nay-say? if people are going to make grandiose statements then > they should justify them with reputable evidence. I would be extremely > surprised if Cogent engineering isn't working on a IPv6 plan or doesn't > have one already in place. > > Bret > > On Thu, 2009-06-11 at 10:37 -0400, Steve Bertrand wrote: > > Stephen Kratzer wrote: > > > And, they have no plans to support IPv6. > > > > Ouch! > > > > I hope this is a non-starter for a lot of folks. > > > > Steve From kratzers at pa.net Thu Jun 11 10:03:21 2009 From: kratzers at pa.net (Stephen Kratzer) Date: Thu, 11 Jun 2009 11:03:21 -0400 Subject: Cogent input In-Reply-To: <1244731753.26816.34.camel@acer-laptop> References: <4A310AC5.5050701@justinshore.com> <4A3116B4.1090208@ibctech.ca> <1244731753.26816.34.camel@acer-laptop> Message-ID: <200906111103.22079.kratzers@pa.net> Perhaps you missed my quote: "Cogent's official stance on IPv6 is that we will deploy IPv6 when it becomes a commercial necessity. We have tested IPv6 and we have our plan for rolling it out, but there are no commercial drivers to spend money to upgrade a network to IPv6 for no real return on investment." This came rom a contact at Cogent (not sure of the role, probably sales rep). On Thursday 11 June 2009 10:49:13 Bret Clark wrote: > I'm skeptical as to where this info came from since this seems nothing > more then nay-say? if people are going to make grandiose statements then > they should justify them with reputable evidence. I would be extremely > surprised if Cogent engineering isn't working on a IPv6 plan or doesn't > have one already in place. > > Bret > > On Thu, 2009-06-11 at 10:37 -0400, Steve Bertrand wrote: > > Stephen Kratzer wrote: > > > And, they have no plans to support IPv6. > > > > Ouch! > > > > I hope this is a non-starter for a lot of folks. > > > > Steve From bclark at spectraaccess.com Thu Jun 11 10:06:38 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Thu, 11 Jun 2009 11:06:38 -0400 Subject: Cogent input In-Reply-To: <200906111103.22079.kratzers@pa.net> References: <4A310AC5.5050701@justinshore.com> <4A3116B4.1090208@ibctech.ca> <1244731753.26816.34.camel@acer-laptop> <200906111103.22079.kratzers@pa.net> Message-ID: <1244732798.4099.1.camel@acer-laptop> Far different response then whoever quoted..."And, they have no plans to support IPv6." On Thu, 2009-06-11 at 11:03 -0400, Stephen Kratzer wrote: > Perhaps you missed my quote: > > "Cogent's official stance on IPv6 is that we will deploy IPv6 when it > becomes a commercial necessity. We have tested IPv6 and we have our plan > for rolling it out, but there are no commercial drivers to spend money > to upgrade a network to IPv6 for no real return on investment." > > This came rom a contact at Cogent (not sure of the role, probably sales rep). > > On Thursday 11 June 2009 10:49:13 Bret Clark wrote: > > I'm skeptical as to where this info came from since this seems nothing > > more then nay-say? if people are going to make grandiose statements then > > they should justify them with reputable evidence. I would be extremely > > surprised if Cogent engineering isn't working on a IPv6 plan or doesn't > > have one already in place. > > > > Bret > > > > On Thu, 2009-06-11 at 10:37 -0400, Steve Bertrand wrote: > > > Stephen Kratzer wrote: > > > > And, they have no plans to support IPv6. > > > > > > Ouch! > > > > > > I hope this is a non-starter for a lot of folks. > > > > > > Steve > > From kratzers at pa.net Thu Jun 11 10:09:18 2009 From: kratzers at pa.net (Stephen Kratzer) Date: Thu, 11 Jun 2009 11:09:18 -0400 Subject: Cogent input In-Reply-To: <1244732798.4099.1.camel@acer-laptop> References: <4A310AC5.5050701@justinshore.com> <200906111103.22079.kratzers@pa.net> <1244732798.4099.1.camel@acer-laptop> Message-ID: <200906111109.19035.kratzers@pa.net> Perhaps you missed my amendment: Should have said "And, they have no plans to deploy IPv6 in the immediate future." :) On Thursday 11 June 2009 11:06:38 Bret Clark wrote: > Far different response then whoever quoted..."And, they have no plans to > support IPv6." > > On Thu, 2009-06-11 at 11:03 -0400, Stephen Kratzer wrote: > > Perhaps you missed my quote: > > > > "Cogent's official stance on IPv6 is that we will deploy IPv6 when it > > becomes a commercial necessity. We have tested IPv6 and we have our plan > > for rolling it out, but there are no commercial drivers to spend money > > to upgrade a network to IPv6 for no real return on investment." > > > > This came rom a contact at Cogent (not sure of the role, probably sales > > rep). > > > > On Thursday 11 June 2009 10:49:13 Bret Clark wrote: > > > I'm skeptical as to where this info came from since this seems nothing > > > more then nay-say? if people are going to make grandiose statements > > > then they should justify them with reputable evidence. I would be > > > extremely surprised if Cogent engineering isn't working on a IPv6 plan > > > or doesn't have one already in place. > > > > > > Bret > > > > > > On Thu, 2009-06-11 at 10:37 -0400, Steve Bertrand wrote: > > > > Stephen Kratzer wrote: > > > > > And, they have no plans to support IPv6. > > > > > > > > Ouch! > > > > > > > > I hope this is a non-starter for a lot of folks. > > > > > > > > Steve From kratzers at pa.net Thu Jun 11 10:09:18 2009 From: kratzers at pa.net (Stephen Kratzer) Date: Thu, 11 Jun 2009 11:09:18 -0400 Subject: Cogent input In-Reply-To: <1244732798.4099.1.camel@acer-laptop> References: <4A310AC5.5050701@justinshore.com> <200906111103.22079.kratzers@pa.net> <1244732798.4099.1.camel@acer-laptop> Message-ID: <200906111109.19035.kratzers@pa.net> Perhaps you missed my amendment: Should have said "And, they have no plans to deploy IPv6 in the immediate future." :) On Thursday 11 June 2009 11:06:38 Bret Clark wrote: > Far different response then whoever quoted..."And, they have no plans to > support IPv6." > > On Thu, 2009-06-11 at 11:03 -0400, Stephen Kratzer wrote: > > Perhaps you missed my quote: > > > > "Cogent's official stance on IPv6 is that we will deploy IPv6 when it > > becomes a commercial necessity. We have tested IPv6 and we have our plan > > for rolling it out, but there are no commercial drivers to spend money > > to upgrade a network to IPv6 for no real return on investment." > > > > This came rom a contact at Cogent (not sure of the role, probably sales > > rep). > > > > On Thursday 11 June 2009 10:49:13 Bret Clark wrote: > > > I'm skeptical as to where this info came from since this seems nothing > > > more then nay-say? if people are going to make grandiose statements > > > then they should justify them with reputable evidence. I would be > > > extremely surprised if Cogent engineering isn't working on a IPv6 plan > > > or doesn't have one already in place. > > > > > > Bret > > > > > > On Thu, 2009-06-11 at 10:37 -0400, Steve Bertrand wrote: > > > > Stephen Kratzer wrote: > > > > > And, they have no plans to support IPv6. > > > > > > > > Ouch! > > > > > > > > I hope this is a non-starter for a lot of folks. > > > > > > > > Steve From bclark at spectraaccess.com Thu Jun 11 10:12:16 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Thu, 11 Jun 2009 11:12:16 -0400 Subject: Cogent input In-Reply-To: <200906111109.19035.kratzers@pa.net> References: <4A310AC5.5050701@justinshore.com> <200906111103.22079.kratzers@pa.net> <1244732798.4099.1.camel@acer-laptop> <200906111109.19035.kratzers@pa.net> Message-ID: <1244733136.4099.2.camel@acer-laptop> You email is faster them mine ;) On Thu, 2009-06-11 at 11:09 -0400, Stephen Kratzer wrote: > Perhaps you missed my amendment: > > Should have said "And, they have no plans to deploy IPv6 in the immediate > future." > > :) > > On Thursday 11 June 2009 11:06:38 Bret Clark wrote: > > Far different response then whoever quoted..."And, they have no plans to > > support IPv6." > > > > On Thu, 2009-06-11 at 11:03 -0400, Stephen Kratzer wrote: > > > Perhaps you missed my quote: > > > > > > "Cogent's official stance on IPv6 is that we will deploy IPv6 when it > > > becomes a commercial necessity. We have tested IPv6 and we have our plan > > > for rolling it out, but there are no commercial drivers to spend money > > > to upgrade a network to IPv6 for no real return on investment." > > > > > > This came rom a contact at Cogent (not sure of the role, probably sales > > > rep). > > > > > > On Thursday 11 June 2009 10:49:13 Bret Clark wrote: > > > > I'm skeptical as to where this info came from since this seems nothing > > > > more then nay-say? if people are going to make grandiose statements > > > > then they should justify them with reputable evidence. I would be > > > > extremely surprised if Cogent engineering isn't working on a IPv6 plan > > > > or doesn't have one already in place. > > > > > > > > Bret > > > > > > > > On Thu, 2009-06-11 at 10:37 -0400, Steve Bertrand wrote: > > > > > Stephen Kratzer wrote: > > > > > > And, they have no plans to support IPv6. > > > > > > > > > > Ouch! > > > > > > > > > > I hope this is a non-starter for a lot of folks. > > > > > > > > > > Steve > > From bclark at spectraaccess.com Thu Jun 11 10:12:16 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Thu, 11 Jun 2009 11:12:16 -0400 Subject: Cogent input In-Reply-To: <200906111109.19035.kratzers@pa.net> References: <4A310AC5.5050701@justinshore.com> <200906111103.22079.kratzers@pa.net> <1244732798.4099.1.camel@acer-laptop> <200906111109.19035.kratzers@pa.net> Message-ID: <1244733136.4099.2.camel@acer-laptop> You email is faster them mine ;) On Thu, 2009-06-11 at 11:09 -0400, Stephen Kratzer wrote: > Perhaps you missed my amendment: > > Should have said "And, they have no plans to deploy IPv6 in the immediate > future." > > :) > > On Thursday 11 June 2009 11:06:38 Bret Clark wrote: > > Far different response then whoever quoted..."And, they have no plans to > > support IPv6." > > > > On Thu, 2009-06-11 at 11:03 -0400, Stephen Kratzer wrote: > > > Perhaps you missed my quote: > > > > > > "Cogent's official stance on IPv6 is that we will deploy IPv6 when it > > > becomes a commercial necessity. We have tested IPv6 and we have our plan > > > for rolling it out, but there are no commercial drivers to spend money > > > to upgrade a network to IPv6 for no real return on investment." > > > > > > This came rom a contact at Cogent (not sure of the role, probably sales > > > rep). > > > > > > On Thursday 11 June 2009 10:49:13 Bret Clark wrote: > > > > I'm skeptical as to where this info came from since this seems nothing > > > > more then nay-say? if people are going to make grandiose statements > > > > then they should justify them with reputable evidence. I would be > > > > extremely surprised if Cogent engineering isn't working on a IPv6 plan > > > > or doesn't have one already in place. > > > > > > > > Bret > > > > > > > > On Thu, 2009-06-11 at 10:37 -0400, Steve Bertrand wrote: > > > > > Stephen Kratzer wrote: > > > > > > And, they have no plans to support IPv6. > > > > > > > > > > Ouch! > > > > > > > > > > I hope this is a non-starter for a lot of folks. > > > > > > > > > > Steve > > From raymond at prolocation.net Thu Jun 11 10:18:50 2009 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Thu, 11 Jun 2009 17:18:50 +0200 (CEST) Subject: Cogent input In-Reply-To: <200906111109.19035.kratzers@pa.net> References: <4A310AC5.5050701@justinshore.com> <200906111103.22079.kratzers@pa.net> <1244732798.4099.1.camel@acer-laptop> <200906111109.19035.kratzers@pa.net> Message-ID: Hi! > Should have said "And, they have no plans to deploy IPv6 in the immediate > future." > > :) >>> "Cogent's official stance on IPv6 is that we will deploy IPv6 when it >>> becomes a commercial necessity. We have tested IPv6 and we have our plan >>> for rolling it out, but there are no commercial drivers to spend money >>> to upgrade a network to IPv6 for no real return on investment." Thats strange they are running pilots with customers on v6 in Amsterdam. Bye, Raymond. From raymond at prolocation.net Thu Jun 11 10:18:50 2009 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Thu, 11 Jun 2009 17:18:50 +0200 (CEST) Subject: Cogent input In-Reply-To: <200906111109.19035.kratzers@pa.net> References: <4A310AC5.5050701@justinshore.com> <200906111103.22079.kratzers@pa.net> <1244732798.4099.1.camel@acer-laptop> <200906111109.19035.kratzers@pa.net> Message-ID: Hi! > Should have said "And, they have no plans to deploy IPv6 in the immediate > future." > > :) >>> "Cogent's official stance on IPv6 is that we will deploy IPv6 when it >>> becomes a commercial necessity. We have tested IPv6 and we have our plan >>> for rolling it out, but there are no commercial drivers to spend money >>> to upgrade a network to IPv6 for no real return on investment." Thats strange they are running pilots with customers on v6 in Amsterdam. Bye, Raymond. From davei at otd.com Thu Jun 11 10:25:12 2009 From: davei at otd.com (Dave Israel) Date: Thu, 11 Jun 2009 11:25:12 -0400 Subject: Cogent input In-Reply-To: References: <4A310AC5.5050701@justinshore.com> <200906111103.22079.kratzers@pa.net> <1244732798.4099.1.camel@acer-laptop> <200906111109.19035.kratzers@pa.net> Message-ID: <4A3121D8.7090202@otd.com> Raymond Dijkxhoorn wrote: >>>> "Cogent's official stance on IPv6 is that we will deploy IPv6 when it >>>> becomes a commercial necessity. We have tested IPv6 and we have our >>>> plan >>>> for rolling it out, but there are no commercial drivers to spend money >>>> to upgrade a network to IPv6 for no real return on investment." > > Thats strange they are running pilots with customers on v6 in Amsterdam. Not really so strange. ISPs often pilot features (v6, multicast, etc) that they have no immediate intention of deploying, so that they have experience if and when it becomes profitable/sensible to deploy them. From raymond at prolocation.net Thu Jun 11 10:28:38 2009 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Thu, 11 Jun 2009 17:28:38 +0200 (CEST) Subject: Cogent input In-Reply-To: <4A3121D8.7090202@otd.com> References: <4A310AC5.5050701@justinshore.com> <200906111103.22079.kratzers@pa.net> <1244732798.4099.1.camel@acer-laptop> <200906111109.19035.kratzers@pa.net> <4A3121D8.7090202@otd.com> Message-ID: Hi! >>>>> "Cogent's official stance on IPv6 is that we will deploy IPv6 when it >>>>> becomes a commercial necessity. We have tested IPv6 and we have our >>>>> plan >>>>> for rolling it out, but there are no commercial drivers to spend money >>>>> to upgrade a network to IPv6 for no real return on investment." >> Thats strange they are running pilots with customers on v6 in Amsterdam. > Not really so strange. ISPs often pilot features (v6, multicast, etc) > that they have no immediate intention of deploying, so that they have > experience if and when it becomes profitable/sensible to deploy them. Not from what i have been told, but hey i am not working there. We got a v6 transit offer as pilot from them so perhaps they are moving towards live service .... Would not be strange in this current stage... Bye, Raymond. From tme at americafree.tv Thu Jun 11 10:31:01 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 11 Jun 2009 11:31:01 -0400 Subject: Cogent input In-Reply-To: <200906111103.22079.kratzers@pa.net> References: <4A310AC5.5050701@justinshore.com> <4A3116B4.1090208@ibctech.ca> <1244731753.26816.34.camel@acer-laptop> <200906111103.22079.kratzers@pa.net> Message-ID: <3E91452E-4B26-4EBD-BC7A-9F05119184BD@americafree.tv> On Jun 11, 2009, at 11:03 AM, Stephen Kratzer wrote: > Perhaps you missed my quote: > > "Cogent's official stance on IPv6 is that we will deploy IPv6 when it > becomes a commercial necessity. We have tested IPv6 and we have our > plan > for rolling it out, but there are no commercial drivers to spend money > to upgrade a network to IPv6 for no real return on investment." FWIW, they have said basically the same thing about multicast. Regards Marshall > > > This came rom a contact at Cogent (not sure of the role, probably > sales rep). > > On Thursday 11 June 2009 10:49:13 Bret Clark wrote: >> I'm skeptical as to where this info came from since this seems >> nothing >> more then nay-say? if people are going to make grandiose statements >> then >> they should justify them with reputable evidence. I would be >> extremely >> surprised if Cogent engineering isn't working on a IPv6 plan or >> doesn't >> have one already in place. >> >> Bret >> >> On Thu, 2009-06-11 at 10:37 -0400, Steve Bertrand wrote: >>> Stephen Kratzer wrote: >>>> And, they have no plans to support IPv6. >>> >>> Ouch! >>> >>> I hope this is a non-starter for a lot of folks. >>> >>> Steve > > > > From tme at americafree.tv Thu Jun 11 10:31:01 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 11 Jun 2009 11:31:01 -0400 Subject: Cogent input In-Reply-To: <200906111103.22079.kratzers@pa.net> References: <4A310AC5.5050701@justinshore.com> <4A3116B4.1090208@ibctech.ca> <1244731753.26816.34.camel@acer-laptop> <200906111103.22079.kratzers@pa.net> Message-ID: <3E91452E-4B26-4EBD-BC7A-9F05119184BD@americafree.tv> On Jun 11, 2009, at 11:03 AM, Stephen Kratzer wrote: > Perhaps you missed my quote: > > "Cogent's official stance on IPv6 is that we will deploy IPv6 when it > becomes a commercial necessity. We have tested IPv6 and we have our > plan > for rolling it out, but there are no commercial drivers to spend money > to upgrade a network to IPv6 for no real return on investment." FWIW, they have said basically the same thing about multicast. Regards Marshall > > > This came rom a contact at Cogent (not sure of the role, probably > sales rep). > > On Thursday 11 June 2009 10:49:13 Bret Clark wrote: >> I'm skeptical as to where this info came from since this seems >> nothing >> more then nay-say? if people are going to make grandiose statements >> then >> they should justify them with reputable evidence. I would be >> extremely >> surprised if Cogent engineering isn't working on a IPv6 plan or >> doesn't >> have one already in place. >> >> Bret >> >> On Thu, 2009-06-11 at 10:37 -0400, Steve Bertrand wrote: >>> Stephen Kratzer wrote: >>>> And, they have no plans to support IPv6. >>> >>> Ouch! >>> >>> I hope this is a non-starter for a lot of folks. >>> >>> Steve > > > > From seph at directionless.org Thu Jun 11 10:48:36 2009 From: seph at directionless.org (seph) Date: Thu, 11 Jun 2009 11:48:36 -0400 Subject: Cogent input In-Reply-To: <1244729830.26816.29.camel@acer-laptop> (Bret Clark's message of "Thu, 11 Jun 2009 10:17:10 -0400") References: <4A310AC5.5050701@justinshore.com> <1244729830.26816.29.camel@acer-laptop> Message-ID: Here as well. We're a small content provider, and we have cogent as one of our ISPs. Though I wouldn't feel comfortable using only them, my experience has been pretty good. Their NOC is competent, and service has been reliable. seph Bret Clark writes: > I hate when these questions get asked, because as the saying goes..."a > person happy with a service will only tell one other person, but a > person unhappy with a service with tell ten other people". So I think a > lot of times you'll get skewed responses...but with that said, we've > been using Cogent now for a year and no complaints at all. Had some > minor downtime back in April due to a hardware failure, but Cogent > responded extremely quickly, scheduled an emergency maintainance and had > us running rather quickly. Face it, hardware problems happen so I can't > blame Cogent on the failure. The few times I've dealt with their tech > support group I found 99% of them very knowledgeable and I know that > when we initially turned on the link they went the extra mile to resolve > some initial problems during the weekend time frame. > > My 2 cents and with any provider mileage will vary, > Bret > > > > On Thu, 2009-06-11 at 15:01 +0100, Andrew Mulholland wrote: > >> At $JOB-1 we used Cogent. >> >> Lots of horror stories had been heard about them. >> >> We didn't have such problems. >> >> Had nx1Gig from them. >> >> On the few occasions where we had some slight issues, I was happy to >> be able to get through to some one useful on the phone quickly, and >> not play pass the parcel with call centre operatives. >> >> >> and at least in the quantities we were buying they were significantly >> better value than others, which was the primary reason we went with >> them. >> >> >> >> andrew >> >> >> >> On Thu, Jun 11, 2009 at 2:55 PM, Paul Stewart wrote: >> > Our experience with them was at least one major (longer than an hour) >> > outages PER MONTH and many of those times they were black holing our >> > routes in their network which was the most damaging aspect. The outages >> > were one thing but when our routes still somehow managed to get >> > advertised in their network (even though our BGP session was down) that >> > really created issues. I have heard from some nearby folks who still >> > have service that it's gotten better, but we are also in the "regional >> > offering" when it comes to IP Transit and have sold connections to many >> > former Cogent customers who were fed up and left. >> > >> > I have found with Cogent that you will get a LOT of varying opinions on >> > them - there are several other players (at least in our market) that are >> > priced very similar now and have a better history behind them..... >> > >> > The specific de-peering issues never effected us much due to enough >> > diversity in our upstreams and a fair amount of direct/public peering... >> > >> > Thanks, >> > >> > Paul >> > >> > >> > >> > -----Original Message----- >> > From: Justin Shore [mailto:justin at justinshore.com] >> > Sent: Thursday, June 11, 2009 9:47 AM >> > To: NANOG >> > Subject: Cogent input >> > >> > I'm in search of some information about Cogent, it's past, present and >> > future. I've heard bits and pieces about Cogent's past over the years >> > but by no means have I actively been keeping up. >> > >> > I'm aware of some (regular?) depeering issues. The NANOG archives have >> > given me some additional insight into that (recurring?) problem. The >> > reasoning behind the depeering events is a bit fuzzy though. I would be >> > >> > interested in people's opinion on whether or not they should be consider >> > >> > for upstream service based on this particular issue. Are there any >> > reasonable mitigation measures available to Cogent downstreams if >> > (when?) Cogent were to be depeered again? My understanding is that at >> > least on previous depeering occasion, the depeering partner simply >> > null-routed all prefixes being received via Cogent, creating a blackhole >> > >> > essentially. I also recall reading that this meant that prefixes being >> > advertised and received by the depeering partner from other peers would >> > still end up in the blackhole. The only solution I would see to this >> > problem would be to shut down the BGP session with Cogent and rely on a >> > 2nd upstream. Are there any other possible steps for mitigation in a >> > depeering event? >> > >> > I also know that their bandwidth is extremely cheap. This of course >> > creates an issue for technical folks when trying to justify other >> > upstream options that cost significantly more but also don't have a >> > damaging history of getting depeered. >> > >> > Does Cogent still have an issue with depeering? Are there any >> > reasonable mitigation measures or should a downstream customer do any >> > thing in particular to ready themselves for a depeering event? Does >> > their low cost outweigh the risks? What are the specific risks? >> > >> > Thanks >> > 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 alex at corp.nac.net Thu Jun 11 12:18:40 2009 From: alex at corp.nac.net (Alex Rubenstein) Date: Thu, 11 Jun 2009 13:18:40 -0400 Subject: Cogent input In-Reply-To: <4A310AC5.5050701@justinshore.com> References: <4A310AC5.5050701@justinshore.com> Message-ID: > I'm aware of some (regular?) depeering issues. The NANOG archives have AFAIR, there has never been a black-holing, just disappearance of routes. If you are properly multihomed, this is irrelevant and you continue to eat your ice cream and chuckle while they fight it out. It's amusing, really. > I also know that their bandwidth is extremely cheap. This of course > creates an issue for technical folks when trying to justify other > upstream options that cost significantly more but also don't have a > damaging history of getting depeered. It's not as relatively cheap as it used to be. A variety of others can be had in the same ballpark (Telia, Tiscali, Seabone, etc.) From patrick at ianai.net Thu Jun 11 13:32:19 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 11 Jun 2009 14:32:19 -0400 Subject: Any2 Exchange experiences to share? In-Reply-To: <20090611005616.6rzn9v13qgkcc8og@webmail.m5computersecurity.com> References: <20090611005616.6rzn9v13qgkcc8og@webmail.m5computersecurity.com> Message-ID: <5963DC66-E2B7-423C-B18D-D8E4FEB7EB12@ianai.net> On Jun 11, 2009, at 3:56 AM, Michael J McCafferty wrote: > I am interested to hear any experiences with the Any2 Exchange at > One Wilshire Blvd, especially regarding performance and reliability > to the other exchange participants in comparison to routing to the > same networks via Tier 1 transit providers. > We are in San Diego and have easy access to the exchange via > transport offered by our data center facility who does have physical > presence at OWB, but *we* are not physically in OWB, ~4.5ms away and > some $ for transport to OWB. All things considered, the cost will be > about the same to route via Tier 1 transit providers from San Diego > as it will be to transport to OWB to the exchange. The basic > question is, "Does it improve my network enough to connect to the > exchange?" If it's cost neutral, I'd go with peering. Additional vectors / choices are always useful. Plus as your network grows, you will get a cost benefit from the peering as that is fixed- cost. (Actually a step function as you upgrade, but you get the point.) Any2 runs a fine IX. Very few problems. OWB has had some issues with power in the past, but I think (hope) they are all resolved. -- TTFN, patrick From daniel at bit.nl Thu Jun 11 14:40:33 2009 From: daniel at bit.nl (Daniel Verlouw) Date: Thu, 11 Jun 2009 21:40:33 +0200 Subject: Cogent input In-Reply-To: References: <4A310AC5.5050701@justinshore.com> <200906111103.22079.kratzers@pa.net> <1244732798.4099.1.camel@acer-laptop> <200906111109.19035.kratzers@pa.net> <4A3121D8.7090202@otd.com> Message-ID: On Jun 11, 2009, at 5:28 PM, Raymond Dijkxhoorn wrote: > Not from what i have been told, but hey i am not working there. We > got a v6 transit offer as pilot from them so perhaps they are moving > towards live service .... Would not be strange in this current > stage... same thing here. routing table still looks pretty empty though: daniel at jun1.bit-2a> show route aspath-regex ".* 174 .*" table inet6.0 | match BGP | count Count: 0 lines --Daniel. From justin at justinshore.com Thu Jun 11 17:37:45 2009 From: justin at justinshore.com (Justin Shore) Date: Thu, 11 Jun 2009 17:37:45 -0500 Subject: Cogent input In-Reply-To: <4A311B06.9010606@linpro.no> References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> <4A311B06.9010606@linpro.no> Message-ID: <4A318739.4090209@justinshore.com> Tore Anderson wrote: >> advertise loopbacks, and another for the actual feed. The biggest >> issue we have with them is that they don't allow deaggregation. If >> you've been allocated a prefix of length yy, they'll accept only >> x.x.x.x/yy, not x.x.x.x/yy le 24. Yes, sometimes deaggregation is >> necessary or desirable even if only temporarily. > > Interesting. I requested exactly that when filling in their BGP > questionnaire, and they set it up - no questions asked. It would be a show-stopper for us if they didn't let us deaggregate. We're not really wanting their service for our existing service area. We're wanting to use it to expand to a new service area that is only connected by a much lower-speed service back to the bulk of our current network for specific services like voice. Our PI space is currently broken up to 1) let us effect some measure of load-balancing with Cox (any prefixes we advertised out Cox instead of our much larger tier-1 resulted in a wildly disproportionate amount of preference given to Cox; not sure why) and 2) let this new venture get started with a reasonably-sized allotment of IP. It will be advertised out local providers in that area and also at our main peering point with significant prepending. Visa versa for our other prefixes. We have to deaggregate a little bit to make this work (but not excessively of course). > I have been promised, in writing, that they will provide us with native > IPv6 transit before the end of the year. I hope at least some SPs make this commitment back in the states. I can't find any tier-1s that can provide us with native v6. Our tier-1 upstream has a best effort test program in place that uses ipv6ip tunnels. The other upstream says that they aren't making any public IPv6 plans yet. It's hard to push the migration to v6 along when native v6 providers aren't readily available. Justin From paul at telcodata.us Thu Jun 11 18:00:16 2009 From: paul at telcodata.us (Paul Timmins) Date: Thu, 11 Jun 2009 19:00:16 -0400 Subject: Cogent input In-Reply-To: <4A318739.4090209@justinshore.com> References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> <4A311B06.9010606@linpro.no> <4A318739.4090209@justinshore.com> Message-ID: <4A318C80.6010000@telcodata.us> > > I hope at least some SPs make this commitment back in the states. I > can't find any tier-1s that can provide us with native v6. Our tier-1 > upstream has a best effort test program in place that uses ipv6ip > tunnels. The other upstream says that they aren't making any public > IPv6 plans yet. It's hard to push the migration to v6 along when > native v6 providers aren't readily available. GlobalCrossing told me today I can order native IPv6 anywhere on their network. Don't know if they count as Tier 1 on your list, though. VZB has given me tunnels for a while, hopefully they'll get their pMTU issue fixed so we can do more interesting things with it. -Paul From john at vanoppen.com Thu Jun 11 18:31:24 2009 From: john at vanoppen.com (John van Oppen) Date: Thu, 11 Jun 2009 16:31:24 -0700 Subject: Cogent input References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> <4A311B06.9010606@linpro.no><4A318739.4090209@justinshore.com> <4A318C80.6010000@telcodata.us> Message-ID: NTT (2914) and GBLX (3549) both do native v6... most everyone else on the tier1 list does tunnels. :( There are some nice tier2 networks who do native v6, tiscali and he.net come to mind. -John -----Original Message----- From: Paul Timmins [mailto:paul at telcodata.us] Sent: Thursday, June 11, 2009 4:00 PM To: Justin Shore Cc: NANOG Subject: Re: Cogent input > > I hope at least some SPs make this commitment back in the states. I > can't find any tier-1s that can provide us with native v6. Our tier-1 > upstream has a best effort test program in place that uses ipv6ip > tunnels. The other upstream says that they aren't making any public > IPv6 plans yet. It's hard to push the migration to v6 along when > native v6 providers aren't readily available. GlobalCrossing told me today I can order native IPv6 anywhere on their network. Don't know if they count as Tier 1 on your list, though. VZB has given me tunnels for a while, hopefully they'll get their pMTU issue fixed so we can do more interesting things with it. -Paul From wbailey at gci.com Thu Jun 11 18:33:59 2009 From: wbailey at gci.com (Warren Bailey) Date: Thu, 11 Jun 2009 15:33:59 -0800 Subject: Cogent input Message-ID: <5B3743FC2D0D8B41B27EE4F5EACA79D108970FA0@DTN1EX01.gci.com> Does GBLX still have their data center in Chinatown(NYC)??? I remember about 10 years ago how amazed I was with that place... ----- Original Message ----- From: John van Oppen To: Paul Timmins ; Justin Shore Cc: NANOG Sent: Thu Jun 11 15:31:24 2009 Subject: RE: Cogent input NTT (2914) and GBLX (3549) both do native v6... most everyone else on the tier1 list does tunnels. :( There are some nice tier2 networks who do native v6, tiscali and he.net come to mind. -John -----Original Message----- From: Paul Timmins [mailto:paul at telcodata.us] Sent: Thursday, June 11, 2009 4:00 PM To: Justin Shore Cc: NANOG Subject: Re: Cogent input > > I hope at least some SPs make this commitment back in the states. I > can't find any tier-1s that can provide us with native v6. Our tier-1 > upstream has a best effort test program in place that uses ipv6ip > tunnels. The other upstream says that they aren't making any public > IPv6 plans yet. It's hard to push the migration to v6 along when > native v6 providers aren't readily available. GlobalCrossing told me today I can order native IPv6 anywhere on their network. Don't know if they count as Tier 1 on your list, though. VZB has given me tunnels for a while, hopefully they'll get their pMTU issue fixed so we can do more interesting things with it. -Paul From bruce.horth at gmail.com Thu Jun 11 18:57:07 2009 From: bruce.horth at gmail.com (Bruce Horth) Date: Thu, 11 Jun 2009 19:57:07 -0400 Subject: Blackberry.net Email Administration Contact? In-Reply-To: <4A306737.20401@jolokianetworks.com> References: <4A2F6C92.3080907@jolokianetworks.com> <4A306737.20401@jolokianetworks.com> Message-ID: https://ws.arin.net/whois/?queryinput=!%20RIM abuse at rim.com ipadmin at rim.com On Wed, Jun 10, 2009 at 22:08, Mark Pace wrote: > At the moment it appears as tho the blackberry email storm has > subsided. ?I thought I'd share a most excellent letter I got from > Blackberry after one of the Nanog users was kind enough to forward my > email along to them: > >> Hello Mark, >> >> Thank you for contacting BlackBerry Customer Support. >> >> We have determined that you purchased your BlackBerry product through one of our carrier partners. ?Your service provider fields general queries and provides technical support for all BlackBerry smartphone-related issues and can act as your first point of contact in these matters. >> >> You may also have the option to receive fee-based support directly from Research In Motion, the manufacturer and wireless experts for the BlackBerry solution. If you would like to learn more about this option, please dial the appropriate telephone number below and enter option 3 in the phone menu to be routed to BlackBerry Customer Care. >> >> If your organization has subscribed to BlackBerry Technical Support Services, please contact your IT department and have one of your named callers contact BlackBerry Technical Support. >> >> Note: BlackBerry Technical Support Services is an annual subscription program providing software maintenance and technical support services for your BlackBerry solution. Named callers are personnel within your organization who are authorized to contact our support staff. For more information on BlackBerry Technical Support Services, please visit: >> >> http://www.blackberry.com/support/tsupport/ >> >> All BlackBerry smartphone users have free access to the BlackBerry Technical Solution Center. The BlackBerry Technical Solution Center provides a repository of support information, documentation and frequently asked questions, with enhanced search capabilities so you can easily search for and find the BlackBerry support information you need. Please visit: >> >> http://na.blackberry.com/eng/support/ >> >> Thank you again for contacting us Mark and have a nice day. >> >> Sincerely, > Lucky me! ?I can contact my non-existent carrier or I can pay for > support on a product I don't own that is flooding my network! ?I feel > privileged... > > > pace > > Mark Pace wrote: >> If anyone has a contact within Blackberry.net's email department, I'd >> greatly appreciate it if you could get me in touch with them. ?We're >> getting hundreds of connections a second from their mail servers and >> have had to block them. >> >> >> Thanks in advance, >> Mark Pace >> > -- BH From charles at thewybles.com Thu Jun 11 19:42:39 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 11 Jun 2009 17:42:39 -0700 Subject: IPTV List serv Message-ID: <4A31A47F.5090304@thewybles.com> I know someone was asking about a VOIP list serv the other day. Well IPTV is another big area that could use a list. Check out https://puck.nether.net/pipermail/iptv-users/ From tore at linpro.no Fri Jun 12 00:24:28 2009 From: tore at linpro.no (Tore Anderson) Date: Fri, 12 Jun 2009 07:24:28 +0200 Subject: Cogent input In-Reply-To: References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> <4A311B06.9010606@linpro.no><4A318739.4090209@justinshore.com> <4A318C80.6010000@telcodata.us> Message-ID: <4A31E68C.4080305@linpro.no> Good morning, * John van Oppen > NTT (2914) and GBLX (3549) both do native v6... most everyone else > on the tier1 list does tunnels. :( > > There are some nice tier2 networks who do native v6, tiscali and > he.net come to mind. It's worth noting that being a v4 "tier1"/transit-free network doesn't necessarily mean that they're the same in the v6 world. For instance, Google appears to be a transit-free v6 network. It wouldn't surprise me if the same is true for other big v6 players like Tinet and HE. Anyway, when looking for v6 transit the following page might be useful: http://www.sixxs.net/faq/connectivity/?faq=ipv6transit Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From sthaug at nethelp.no Fri Jun 12 01:12:42 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Fri, 12 Jun 2009 08:12:42 +0200 (CEST) Subject: Cogent input In-Reply-To: <4A31E68C.4080305@linpro.no> References: <4A318C80.6010000@telcodata.us> <4A31E68C.4080305@linpro.no> Message-ID: <20090612.081242.74692729.sthaug@nethelp.no> > It's worth noting that being a v4 "tier1"/transit-free network doesn't > necessarily mean that they're the same in the v6 world. For instance, > Google appears to be a transit-free v6 network. It wouldn't surprise me > if the same is true for other big v6 players like Tinet and HE. Good point. > Anyway, when looking for v6 transit the following page might be useful: > > http://www.sixxs.net/faq/connectivity/?faq=ipv6transit Yup, but take it with a grain of salt. Level3, for instance, definitely doesn't offer native IPv6 with the same geographical distribution as IPv4. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From randy at psg.com Fri Jun 12 03:06:16 2009 From: randy at psg.com (Randy Bush) Date: Fri, 12 Jun 2009 04:06:16 -0400 Subject: ICSI Netalyzr launch In-Reply-To: <443de7ad0906102011g2a95b71fx2da0297a5c0f4c9a@mail.gmail.com> References: <200906092251.n59MpVP3025300@pork.ICSI.Berkeley.EDU> <443de7ad0906102011g2a95b71fx2da0297a5c0f4c9a@mail.gmail.com> Message-ID: > Why no privacy policy? Or am I just partially blind? Is an answer in > a FAQ legally binding? sure, we need a privacy policy that can be arbitrarily changed with no notice just as we have for ... randy From jeroen at easyhosting.nl Fri Jun 12 03:48:14 2009 From: jeroen at easyhosting.nl (Jeroen Wunnink) Date: Fri, 12 Jun 2009 10:48:14 +0200 Subject: Cogent input In-Reply-To: References: <4A310AC5.5050701@justinshore.com> <200906111103.22079.kratzers@pa.net> <1244732798.4099.1.camel@acer-laptop> <200906111109.19035.kratzers@pa.net> Message-ID: <4A32164E.10002@easyhosting.nl> That might be because some bigger providers in the Netherlands are throwing out transits that don't support IPv6. So there's your commercial necessity ;-) Raymond Dijkxhoorn wrote: > Hi! > >> Should have said "And, they have no plans to deploy IPv6 in the >> immediate >> future." >> >> :) > >>>> "Cogent's official stance on IPv6 is that we will deploy IPv6 when it >>>> becomes a commercial necessity. We have tested IPv6 and we have our >>>> plan >>>> for rolling it out, but there are no commercial drivers to spend money >>>> to upgrade a network to IPv6 for no real return on investment." > > Thats strange they are running pilots with customers on v6 in Amsterdam. > > Bye, > Raymond. > -- 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 cidr-report at potaroo.net Fri Jun 12 07:00:16 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 12 Jun 2009 22:00:16 +1000 (EST) Subject: BGP Update Report Message-ID: <200906121200.n5CC0GIT022242@wattle.apnic.net> BGP Update Report Interval: 28-Apr-09 -to- 29-May-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9198 58785 1.0% 233.3 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - AS6389 57303 1.0% 13.1 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 3 - AS21491 54595 0.9% 1819.8 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 4 - AS8452 53246 0.9% 41.6 -- TEDATA TEDATA 5 - AS8151 48723 0.8% 12.6 -- Uninet S.A. de C.V. 6 - AS3130 46229 0.8% 179.9 -- RGNET-3130 RGnet/PSGnet 7 - AS35805 45913 0.8% 127.2 -- UTG-AS United Telecom AS 8 - AS17974 36111 0.6% 33.2 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 9 - AS10834 35811 0.6% 14.1 -- Telefonica Data Argentina S.A. 10 - AS20115 35268 0.6% 20.9 -- CHARTER-NET-HKY-NC - Charter Communications 11 - AS5056 34984 0.6% 296.5 -- INS-NET-2 - Iowa Network Services 12 - AS4249 32651 0.6% 180.4 -- LILLY-AS - Eli Lilly and Company 13 - AS17488 32059 0.5% 19.0 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 14 - AS33776 31203 0.5% 269.0 -- STARCOMMS-ASN 15 - AS4323 30360 0.5% 7.0 -- TWTC - tw telecom holdings, inc. 16 - AS30890 26554 0.5% 48.8 -- EVOLVA Evolva Telecom 17 - AS2920 25925 0.4% 316.2 -- LACOE - Los Angeles County Office of Education 18 - AS29372 25107 0.4% 317.8 -- SFR-NETWORK SFR 19 - AS5050 25065 0.4% 1790.4 -- PSC-EXT - Pittsburgh Supercomputing Center 20 - AS10620 24077 0.4% 24.3 -- TV Cable S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS16931 18144 0.3% 9072.0 -- GLOBAL-PAYMENTS-1 - Global Payments, Inc. 2 - AS15045 16317 0.3% 4079.2 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 3 - AS2 3535 0.1% 4.0 -- NAVITAIRE-AS-AU-AP Accenture - Navitaire, 4 - AS32398 20661 0.3% 3443.5 -- REALNET-ASN-1 5 - AS13153 2542 0.0% 2542.0 -- ONEWORLD OneWorld S.A. 6 - AS29229 2444 0.0% 2444.0 -- ASDA-AS Assotiation for the Development of West Athens 7 - AS8499 2252 0.0% 2252.0 -- Space Hellas Network Operation Center (NOC) 8 - AS13325 16858 0.3% 2107.2 -- STOMI - State of Michigan, DMB-CNOC 9 - AS39803 4171 0.1% 2085.5 -- UTI-AS SC UTI COMMUNICATIONS SYSTEMS SRL 10 - AS39699 5751 0.1% 1917.0 -- SSPOY-AS Salon Seudun Puhelin Oy 11 - AS47640 5581 0.1% 1860.3 -- TRICOMPAS Tricomp Sp. z. o. o. 12 - AS21491 54595 0.9% 1819.8 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 13 - AS5050 25065 0.4% 1790.4 -- PSC-EXT - Pittsburgh Supercomputing Center 14 - AS17236 1271 0.0% 1271.0 -- TULSAL-74103 - Tulsa City-County Library 15 - AS35400 7612 0.1% 1268.7 -- MFIST Interregoinal Organization Network Technologies 16 - AS28256 1241 0.0% 1241.0 -- 17 - AS28953 2317 0.0% 1158.5 -- PIRAEUSBANK Greek banking institution 18 - AS47299 1086 0.0% 1086.0 -- DRSA-AS Dlugie Rozmowy S.A. 19 - AS41492 1082 0.0% 1082.0 -- EXIMBANK-AS SC Eximbank SA 20 - AS24994 2136 0.0% 1068.0 -- GENESYS-AS GENESYS Informatica AS for announcing own prefixes TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 72.23.246.0/24 24597 0.4% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 2 - 41.204.2.0/24 20567 0.3% AS32398 -- REALNET-ASN-1 3 - 64.69.192.0/20 18134 0.3% AS16931 -- GLOBAL-PAYMENTS-1 - Global Payments, Inc. 4 - 192.12.120.0/24 10437 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 5 - 89.218.218.0/23 7837 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 6 - 89.218.220.0/23 7833 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 7 - 92.46.244.0/23 7830 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 8 - 95.59.4.0/22 7823 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 9 - 95.59.2.0/23 7818 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 10 - 95.59.8.0/23 7817 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 11 - 123.49.152.0/24 7538 0.1% AS18118 -- CITICNET-AP CITIC Networks Management Co.,Ltd. 12 - 90.150.0.0/24 7284 0.1% AS35400 -- MFIST Interregoinal Organization Network Technologies 13 - 63.144.223.0/24 7006 0.1% AS30221 -- T3COM - T3 Communications, Inc. 14 - 72.42.204.0/23 6972 0.1% AS40060 -- AAAWI - AAA Wireless, Inc. 15 - 123.49.144.0/21 6876 0.1% AS18118 -- CITICNET-AP CITIC Networks Management Co.,Ltd. 16 - 195.96.69.0/24 6089 0.1% AS8225 -- ASTELIT-MSK-AS Astelit Autonomous System 17 - 193.201.184.0/21 5865 0.1% AS25546 -- BROOKLANDCOMP-AS Brookland Computer Services 18 - 63.103.104.0/22 5668 0.1% AS15045 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 19 - 63.103.108.0/23 5668 0.1% AS15045 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 20 - 81.199.18.0/24 5657 0.1% AS21491 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 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 Jun 12 07:00:05 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 12 Jun 2009 22:00:05 +1000 (EST) Subject: The Cidr Report Message-ID: <200906121200.n5CC05PF022223@wattle.apnic.net> This report has been generated at Fri Jun 12 21:13:51 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 05-06-09 293617 183706 06-06-09 294620 183567 07-06-09 294066 182882 08-06-09 294012 183175 09-06-09 294091 183252 10-06-09 293965 183136 11-06-09 292531 183769 12-06-09 294158 183680 AS Summary 31555 Number of ASes in routing system 13395 Number of ASes announcing only one prefix 4288 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89748736 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'). --- 12Jun09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 294180 183434 110746 37.6% All ASes AS6389 4288 343 3945 92.0% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4273 1780 2493 58.3% TWTC - tw telecom holdings, inc. AS17488 1600 299 1301 81.3% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4766 1815 520 1295 71.3% KIXS-AS-KR Korea Telecom AS4755 1243 144 1099 88.4% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1685 642 1043 61.9% AS-PAETEC-NET - PaeTec Communications, Inc. AS22773 1062 67 995 93.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1464 548 916 62.6% Uninet S.A. de C.V. AS19262 1014 236 778 76.7% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8452 981 278 703 71.7% TEDATA TEDATA AS18566 1062 423 639 60.2% COVAD - Covad Communications Co. AS18101 753 157 596 79.2% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS17908 656 66 590 89.9% TCISL Tata Communications AS6478 1375 790 585 42.5% ATT-INTERNET3 - AT&T WorldNet Services AS4804 679 107 572 84.2% MPX-AS Microplex PTY LTD AS11492 1111 584 527 47.4% CABLEONE - CABLE ONE, INC. AS22047 591 88 503 85.1% VTR BANDA ANCHA S.A. AS7029 605 105 500 82.6% WINDSTREAM - Windstream Communications Inc AS2706 536 44 492 91.8% PI-HK Pacnet Internet (Hong Kong) Limited AS17676 564 80 484 85.8% GIGAINFRA Softbank BB Corp. AS24560 714 246 468 65.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7018 1507 1042 465 30.9% ATT-INTERNET4 - AT&T WorldNet Services AS4808 631 166 465 73.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4134 892 434 458 51.3% CHINANET-BACKBONE No.31,Jin-rong Street AS7545 810 383 427 52.7% TPG-INTERNET-AP TPG Internet Pty Ltd AS9443 514 90 424 82.5% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7011 977 564 413 42.3% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4668 693 284 409 59.0% LGNET-AS-KR LG CNS AS6517 650 246 404 62.2% RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc AS4780 522 129 393 75.3% SEEDNET Digital United Inc. Total 35267 10885 24382 69.1% 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 109.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 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 171.18.0.0/20 AS12696 AXA-TECH Axa technology Services 171.18.17.0/24 AS12696 AXA-TECH Axa technology Services 171.18.19.0/24 AS12696 AXA-TECH Axa technology Services 171.18.20.0/24 AS12696 AXA-TECH Axa technology Services 171.18.22.0/24 AS12696 AXA-TECH Axa technology Services 171.18.24.0/23 AS43722 ATNEDC-AS AXA Technology Services Germany GmbH 171.18.26.0/23 AS43722 ATNEDC-AS AXA Technology Services Germany GmbH 171.18.28.0/23 AS43722 ATNEDC-AS AXA Technology Services Germany GmbH 171.18.32.0/24 AS12696 AXA-TECH Axa technology Services 171.18.33.0/24 AS12696 AXA-TECH Axa technology Services 171.18.34.0/24 AS12696 AXA-TECH Axa technology Services 171.18.35.0/24 AS12696 AXA-TECH Axa technology Services 171.18.36.0/24 AS12696 AXA-TECH Axa technology Services 171.18.37.0/24 AS12696 AXA-TECH Axa technology Services 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.117.0.0/18 AS29422 NBLNETWORKS-AS Nebula Oy Autonomous System 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 G-WiN 192.124.252.0/22 AS680 DFN-IP service G-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 194.63.159.0/24 AS34848 COMENDO-AS Comendo A/S 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.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.84.16.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.84.17.0/24 AS17781 XINHUA Xinhua News Agency 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. 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.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 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 IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet 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 justin at justinshore.com Fri Jun 12 08:13:02 2009 From: justin at justinshore.com (Justin Shore) Date: Fri, 12 Jun 2009 08:13:02 -0500 Subject: Cogent input In-Reply-To: References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> <4A311B06.9010606@linpro.no><4A318739.4090209@justinshore.com> <4A318C80.6010000@telcodata.us> Message-ID: <4A32545E.1030803@justinshore.com> John van Oppen wrote: > NTT (2914) and GBLX (3549) both do native v6... most everyone else on > the tier1 list does tunnels. :( > > There are some nice tier2 networks who do native v6, tiscali and he.net > come to mind. Let me rephrase that. :-) I know of no tier-Ns that offer any native v6 services here in the Midwest (central Kansas) including L3 which only has a best effort pilot program using tunnels. There might be more options in KC or OKC but not here that I'm aware of... Justin From justin at justinshore.com Fri Jun 12 08:16:55 2009 From: justin at justinshore.com (Justin Shore) Date: Fri, 12 Jun 2009 08:16:55 -0500 Subject: Cogent input In-Reply-To: <4A318C80.6010000@telcodata.us> References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> <4A311B06.9010606@linpro.no> <4A318739.4090209@justinshore.com> <4A318C80.6010000@telcodata.us> Message-ID: <4A325547.70406@justinshore.com> Paul Timmins wrote: > GlobalCrossing told me today I can order native IPv6 anywhere on their > network. Don't know if they count as Tier 1 on your list, though. VZB > has given me tunnels for a while, hopefully they'll get their pMTU issue > fixed so we can do more interesting things with it. I'd love to have GLBX but I'm positive that they aren't available here. We'd have to pay for transport to a much larger market to go get them. That may be more feasible when the state network gets built but that's a few years off. Until then I'll have to dream about GBLX... Justin From fvd at de.kpn-eurorings.net Fri Jun 12 08:32:42 2009 From: fvd at de.kpn-eurorings.net (Weber, Markus) Date: Fri, 12 Jun 2009 15:32:42 +0200 Subject: Traffic billing - L2 encap to include or not? Message-ID: <7707838BF569B24DBBDB8F54AB67B67F02CC58A2@foo.kpnqwest.de> We all have our billing systems for traffic (bought, downloaded or home made, volume based or usage). We all got hit by fancy SNMP bugs of various vendors and we all suffer from the fact, that SNMP counters do not carry a time stamp, when they had been taken from the ASICs, causing a slight derivation. [...] Most systems (not the xflow based ones) do use IF-MIB::InOctets and IF-MIB::OutOctets or their HC counter parts to retrieve the number of transmitted bytes and do their calculation based on these numbers. What would you expect these counters to return, esp. on Ethernet? RFC2683 states ifXxxOctets The definitions of ifInOctets and ifOutOctets (and similarly, ifHCInOctets and ifHCOutOctets) specify that their values include framing characters. The media-specific MIB designer MUST specify any special conditions of the media concerning the inclusion of framing characters, especially with respect to frames with errors. The total number of octets transmitted out of/received on the interface, including framing characters." So, is L2 encapsulation (e.g. Ethernet) considered as framing characters or not? Cisco does count them (looks like they also count the FCS), while Juniper does not (at least not on their routers) with above MIBs. So who's right? Which brings me to the question: How do others handle this? Do your customers have to pay for the L2 encapsulation overhead or not? Does your (special) G T&C address this? Does your system adjust the numbers by adding/subtracting L2 enc overhead * number of transmitted packets? Or do you just live with it as it is (and hope, your provider uses J-counters to do their billing). Oh, it's Friday ... Markus PS1: And what about padding? IP packets could be smaller then the min ethernet frame size ... (think of some kind of DOS attacks) ... PS2: Oh, maybe someone could check on J switches - would be nice to know ... -- [E] Markus Weber [IRC] FvD [T] +49 69 96874-298 [F] -289 [KPN Eurorings B.V. Darmst?dter Landstra?e 184 D-60598 Frankfurt] [HRB56874 Amtsgericht Frankfurt Carolien Nijhuis+Louis Rustenhoven] From renaud at rakotomalala.com Fri Jun 12 08:48:37 2009 From: renaud at rakotomalala.com (Renaud RAKOTOMALALA) Date: Fri, 12 Jun 2009 15:48:37 +0200 Subject: Traffic billing - L2 encap to include or not? In-Reply-To: References: Message-ID: Weber, Markus a ?crit : > We all have our billing systems for traffic (bought, downloaded or > home made, volume based or usage). We all got hit by fancy SNMP > bugs of various vendors and we all suffer from the fact, that SNMP > counters do not carry a time stamp, when they had been taken from > the ASICs, causing a slight derivation. [...] > > [../..] > So, is L2 encapsulation (e.g. Ethernet) considered as framing characters > or not? > [../..] > Hello, To my point of view, if you base your billing from L2 encapsulation you gonna bill your customers on local networks problems like, problems on L2 frames, padding (as you explain). These kind of problematic (again to my point of view) is the problem of the provider and not of the customer who buy IP traffic and not L2 traffic. Renaud From bicknell at ufp.org Fri Jun 12 09:18:25 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 12 Jun 2009 10:18:25 -0400 Subject: Cogent input In-Reply-To: <4A32545E.1030803@justinshore.com> References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> <4A318C80.6010000@telcodata.us> <4A32545E.1030803@justinshore.com> Message-ID: <20090612141825.GA7273@ussenterprise.ufp.org> In a message written on Fri, Jun 12, 2009 at 08:13:02AM -0500, Justin Shore wrote: > Let me rephrase that. :-) I know of no tier-Ns that offer any native v6 > services here in the Midwest (central Kansas) including L3 which only > has a best effort pilot program using tunnels. There might be more > options in KC or OKC but not here that I'm aware of... www.tunnelbroker.net (which is HE under the hood) is available anywhere, self serve, and works great. I bring this up knowing a tunnel is not as good as native connectivity, yadda yadda yadda. My personal experience with sales folks is telling them you need IPv6 makes them go ask questions internally, while telling them you were forced to get service (a tunnel) from a competitor generally sends the entire sales force into a tizzy internally. It really drives home the point that not only are you asking, but you need it, and will go around them if necessary. This changes the equasion for them from wanting to be second (we will offer it in the market when our competitor does) to wanting to be first (we can't let our competitor pick off customers like this who are desperate for the feature). Of course, you may not want to turn up customers on such a service, but it does provide an excellent opportunity to enable your test lab, employee personal boxes, and the like so you can hit the ground running. Hard to beat for something that's free and takes 15 minutes to set up. -- 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 jmamodio at gmail.com Fri Jun 12 10:15:54 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 12 Jun 2009 10:15:54 -0500 Subject: ICSI Netalyzr launch In-Reply-To: References: <200906092251.n59MpVP3025300@pork.ICSI.Berkeley.EDU> <443de7ad0906102011g2a95b71fx2da0297a5c0f4c9a@mail.gmail.com> Message-ID: <202705b0906120815i214a15cy439906598a0fda52@mail.gmail.com> > sure, we need a privacy policy that can be arbitrarily changed with no ... previous ... > notice just as we have for ... ... everything !!! From martin at theicelandguy.com Fri Jun 12 10:28:57 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Fri, 12 Jun 2009 11:28:57 -0400 Subject: Cogent input In-Reply-To: <4A310AC5.5050701@justinshore.com> References: <4A310AC5.5050701@justinshore.com> Message-ID: On Thu, Jun 11, 2009 at 9:46 AM, Justin Shore wrote: > I'm in search of some information about Cogent, it's past, present and > future. I've heard bits and pieces about Cogent's past over the years but > by no means have I actively been keeping up. > I had a very positive interaction with the Cogent folks in Europe FWIW. It was seeded by their US colleagues and everyone worked closely to try and make things work operationally and economically. That signaled to me that they have some cohesiveness internally which I found to be a big plus*. At worst, allowing Cogent to seriously compete for your business can help you reduce your costs elsewhere if you are smart about it. At best, you could cut your costs and maintain the reliability that you are seeking with some strategic mitigation. Others may have different suggestions. YMMV. Best, Marty * Not an endorsement, just an opinion. -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From randy at psg.com Fri Jun 12 10:43:59 2009 From: randy at psg.com (Randy Bush) Date: Fri, 12 Jun 2009 11:43:59 -0400 Subject: ICSI Netalyzr launch In-Reply-To: <202705b0906120815i214a15cy439906598a0fda52@mail.gmail.com> References: <200906092251.n59MpVP3025300@pork.ICSI.Berkeley.EDU> <443de7ad0906102011g2a95b71fx2da0297a5c0f4c9a@mail.gmail.com> <202705b0906120815i214a15cy439906598a0fda52@mail.gmail.com> Message-ID: >> sure, we need a privacy policy that can be arbitrarily changed with no > ... previous ... >> notice just as we have for ... > ... everything !!! exactly. so was the question a troll, a red herring, or just a rant? randy From lists at iamchriswallace.com Fri Jun 12 10:45:26 2009 From: lists at iamchriswallace.com (Chris Wallace) Date: Fri, 12 Jun 2009 11:45:26 -0400 Subject: Rwhoisd solution? In-Reply-To: <3047fef10906101005of0caf90hd911db2b27bc2ff2@mail.gmail.com> References: <16720fe00906060737ue1d1371j735c681983038fe3@mail.gmail.com> <3047fef10906101005of0caf90hd911db2b27bc2ff2@mail.gmail.com> Message-ID: <19973C7E-D9B9-418B-8759-9B9A579CA1F6@iamchriswallace.com> Do you have a link to the information on how to get that setup? ---Chris On Jun 10, 2009, at 1:05 PM, Chris Stone wrote: >>> Can someone please point me in the direction of an rwhoisd >>> solution to >>> be run on a CentOS Linux platform? ARIN is now punting rwhois >>> queries >>> to us and frankly i've been unable to find an easy to install/use >>> solution to answer these queries. I've seen the rwhoisd at >>> projects.arin.net but the documentation on it is ghastly to say the >>> least. > > If you use IPPlan to manage your IP allocations, it comes with a whois > daemon that'll automagically use the information from your IPPlan sql > database. > > > Chris > From cgrundemann at gmail.com Fri Jun 12 11:34:42 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 12 Jun 2009 10:34:42 -0600 Subject: ICSI Netalyzr launch In-Reply-To: References: <200906092251.n59MpVP3025300@pork.ICSI.Berkeley.EDU> <443de7ad0906102011g2a95b71fx2da0297a5c0f4c9a@mail.gmail.com> <202705b0906120815i214a15cy439906598a0fda52@mail.gmail.com> Message-ID: <443de7ad0906120934h412ce83ct9f3d28f4f72c75ee@mail.gmail.com> On Fri, Jun 12, 2009 at 09:43, Randy Bush wrote: >>> sure, we need a privacy policy that can be arbitrarily changed with no >> ... previous ... >>> notice just as we have for ... >> ... everything !!! > > exactly. ?so was the question a troll, a red herring, or just a rant? > > randy > > I guess it was just a rant, I like to know more specifically how folks intend to use data before I hand it over - and I like that promise to be at least theoretically enforceable. I am far from a lawyer but it is my understanding that an official pp is much more substantive and binding than a single FAQ answer -- especially in the eyes of the FTC. Yes policies can be changed but I can follow those changes and stop using the service/tool/etc if I don't like the changes. If you are saying that the policy can be changed after the fact to allow uses of the data for purposes or in manners other than those originally stated, I think you are wrong, see the 2004 case between the FTC and Gateway Learning as one example I know of off hand: Howard Beales, Director of the FTC?s Bureau of Consumer Protection. ?You can change the rules but not after the game has been played.? (http://www.ftc.gov/opa/2004/07/gateway.shtm) I will grant you that in this case the data being collected is probably not that sensitive, but the access to my computer is - to me at least. I for one would have used the tool immediately had there been an acceptable PP or other TOS in place but without it I hesitate... So I figured I would bring it up. ~Chris PS - if you are interested in TOS related stuff, might be worthwhile to check out http://www.tosback.org/timeline.php a new project launched by the EFF (no affiliation, just fyi) From randy at psg.com Fri Jun 12 12:03:22 2009 From: randy at psg.com (Randy Bush) Date: Fri, 12 Jun 2009 13:03:22 -0400 Subject: ICSI Netalyzr launch In-Reply-To: <443de7ad0906120934h412ce83ct9f3d28f4f72c75ee@mail.gmail.com> References: <200906092251.n59MpVP3025300@pork.ICSI.Berkeley.EDU> <443de7ad0906102011g2a95b71fx2da0297a5c0f4c9a@mail.gmail.com> <202705b0906120815i214a15cy439906598a0fda52@mail.gmail.com> <443de7ad0906120934h412ce83ct9f3d28f4f72c75ee@mail.gmail.com> Message-ID: >>>> sure, we need a privacy policy that can be arbitrarily changed with no >>> ... previous ... >>>> notice just as we have for ... >>> ... everything !!! >> exactly. ?so was the question a troll, a red herring, or just a rant? > If you are saying that the policy can be changed i am saying all this is specious. if you don't like it, don't use it. i have been using vern's stuff for 15 years or so, and trust him vastly more than i trust 94.3% of all the other services you trust. randy From arno at ripe.net Fri Jun 12 12:05:04 2009 From: arno at ripe.net (Arno Meulenkamp) Date: Fri, 12 Jun 2009 19:05:04 +0200 Subject: RIPE NCC interview about IPv6 deployment with Randy Bush Message-ID: As part of our IPv6 training project, that consists of face to face training and on-line learning modules and testimonials, we are proud to announce the second in a series of interviews. Randy Bush (IIJ) discusses IPv6 deployment: http://www.youtube.com/watch?v=QCcigLJJbvU So far, we have interviewed 22 people from the community about their experiences and are very busy editing all the video material. In the coming months, you will be able to enjoy the rest of the interviews here: http://www.youtube.com/user/RIPENCC These interviews will also be published on our e-learning page and on our IPv6 Act Now website: http://ripe.net/training/e-learning/ http://www.ipv6actnow.org/ Cheers, Arno Meulenkamp RIPE NCC -------------- 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 jmamodio at gmail.com Fri Jun 12 12:12:38 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 12 Jun 2009 12:12:38 -0500 Subject: ICSI Netalyzr launch In-Reply-To: <443de7ad0906120934h412ce83ct9f3d28f4f72c75ee@mail.gmail.com> References: <200906092251.n59MpVP3025300@pork.ICSI.Berkeley.EDU> <443de7ad0906102011g2a95b71fx2da0297a5c0f4c9a@mail.gmail.com> <202705b0906120815i214a15cy439906598a0fda52@mail.gmail.com> <443de7ad0906120934h412ce83ct9f3d28f4f72c75ee@mail.gmail.com> Message-ID: <202705b0906121012x12b4c538m8c60e95ea71b4711@mail.gmail.com> imho, I believe you are being a little bit paranoid with a tool released by folks that have been trusted in the community for ages. As Randy said, if you don't like it or don't feel comfortable with it, don't use it. BTW, have you ever notified or made public what do you do with the response of each single ping you sent ? You ICMP packets are invading my privacy !!! :-) Cheers From marc at let.de Fri Jun 12 12:29:55 2009 From: marc at let.de (Marc Manthey) Date: Fri, 12 Jun 2009 19:29:55 +0200 Subject: RIPE NCC interview about IPv6 deployment with Randy Bush In-Reply-To: References: Message-ID: Am 12.06.2009 um 19:05 schrieb Arno Meulenkamp: > As part of our IPv6 training project, that consists of face to face > training and on-line learning modules and testimonials, we are proud > to announce the second in a series of interviews. > > Randy Bush (IIJ) discusses IPv6 deployment: > http://www.youtube.com/watch?v=QCcigLJJbvU thanks but thats not Randy Bush its Andy Davidson Randy Bushs Video is here http://www.youtube.com/watch?v=Qh3i6lDqWBM greetings Marc > > So far, we have interviewed 22 people from the community about their > experiences and are very busy editing all the video material. In the > coming months, you will be able to enjoy the rest of the interviews > here: > http://www.youtube.com/user/RIPENCC > > These interviews will also be published on our e-learning page and > on our IPv6 Act Now website: > http://ripe.net/training/e-learning/ > http://www.ipv6actnow.org/ > > Cheers, > > Arno Meulenkamp > RIPE NCC -- 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 michael.holstein at csuohio.edu Fri Jun 12 12:31:20 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Fri, 12 Jun 2009 13:31:20 -0400 Subject: ICSI Netalyzr launch In-Reply-To: References: <200906092251.n59MpVP3025300@pork.ICSI.Berkeley.EDU> <443de7ad0906102011g2a95b71fx2da0297a5c0f4c9a@mail.gmail.com> <202705b0906120815i214a15cy439906598a0fda52@mail.gmail.com> <443de7ad0906120934h412ce83ct9f3d28f4f72c75ee@mail.gmail.com> Message-ID: <4A3290E8.2080709@csuohio.edu> > i am saying all this is specious. > What is really suspect is www.netalyzr.com is registered via GoDaddy and DomainsByProxy. The IP resolves in Berkeley's IP space, but the reverse DNS name is roland.icir.org. Why the hidden registration? I realize Educause won't register a .com for you, but do you really need to be obtuse about who owns the domain? Also .. the Netalyzr project isn't even listed on the "projects" page at www.icir.org. Cheers, Michael Holstein Cleveland State University From randy at psg.com Fri Jun 12 12:38:56 2009 From: randy at psg.com (Randy Bush) Date: Fri, 12 Jun 2009 13:38:56 -0400 Subject: ICSI Netalyzr launch In-Reply-To: <4A3290E8.2080709@csuohio.edu> References: <200906092251.n59MpVP3025300@pork.ICSI.Berkeley.EDU> <443de7ad0906102011g2a95b71fx2da0297a5c0f4c9a@mail.gmail.com> <202705b0906120815i214a15cy439906598a0fda52@mail.gmail.com> <443de7ad0906120934h412ce83ct9f3d28f4f72c75ee@mail.gmail.com> <4A3290E8.2080709@csuohio.edu> Message-ID: >> i am saying all this is specious. > What is really suspect is www.netalyzr.com is registered via GoDaddy and > DomainsByProxy. The IP resolves in Berkeley's IP space, but the reverse > DNS name is roland.icir.org. > > Why the hidden registration? if you knew anything about icir, vern, berkeley, ... you would have a clue. as it is, you don't. so anything sounds like black helicopters. i have work to do, so will be dropping out of this ever so exciting and informative conversation. randy From llynch at civil-tongue.net Fri Jun 12 13:03:36 2009 From: llynch at civil-tongue.net (Lucy Lynch) Date: Fri, 12 Jun 2009 11:03:36 -0700 (PDT) Subject: RIPE NCC interview about IPv6 deployment with Randy Bush In-Reply-To: References: Message-ID: On Fri, 12 Jun 2009, Arno Meulenkamp wrote: > As part of our IPv6 training project, that consists of face to face training > and on-line learning modules and testimonials, we are proud to announce the > second in a series of interviews. > > Randy Bush (IIJ) discusses IPv6 deployment: > http://www.youtube.com/watch?v=QCcigLJJbvU He got larger! And developed an accent... oh wait. Randy here, but I enjoyed Andy as well. http://www.youtube.com/watch?v=Qh3i6lDqWBM > So far, we have interviewed 22 people from the community about their > experiences and are very busy editing all the video material. In the coming > months, you will be able to enjoy the rest of the interviews here: > http://www.youtube.com/user/RIPENCC > > These interviews will also be published on our e-learning page and on our > IPv6 Act Now website: > http://ripe.net/training/e-learning/ > http://www.ipv6actnow.org/ > > Cheers, > > Arno Meulenkamp > RIPE NCC From arno at ripe.net Fri Jun 12 13:10:01 2009 From: arno at ripe.net (Arno Meulenkamp) Date: Fri, 12 Jun 2009 20:10:01 +0200 Subject: RIPE NCC interview about IPv6 deployment with Randy Bush In-Reply-To: References: Message-ID: On 12 Jun 2009, at 19:29 , Marc Manthey wrote: > thanks but thats not Randy Bush its Andy Davidson > > Randy Bushs Video is here > > http://www.youtube.com/watch?v=Qh3i6lDqWBM you are right! guess that tells me that cutting and pasting is dangerous.. thanks! :) Arno -------------- 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 cscora at apnic.net Fri Jun 12 13:11:14 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 13 Jun 2009 04:11:14 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200906121811.n5CIBEMg002531@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 13 Jun, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 287824 Prefixes after maximum aggregation: 137147 Deaggregation factor: 2.10 Unique aggregates announced to Internet: 142799 Total ASes present in the Internet Routing Table: 31449 Prefixes per ASN: 9.15 Origin-only ASes present in the Internet Routing Table: 27360 Origin ASes announcing only one prefix: 13306 Transit ASes present in the Internet Routing Table: 4089 Transit-only ASes present in the Internet Routing Table: 96 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 29 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 500 Unregistered ASNs in the Routing Table: 147 Number of 32-bit ASNs allocated by the RIRs: 181 Prefixes from 32-bit ASNs in the Routing Table: 49 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 829 Number of addresses announced to Internet: 2050857808 Equivalent to 122 /8s, 61 /16s and 155 /24s Percentage of available address space announced: 55.3 Percentage of allocated address space announced: 64.0 Percentage of available address space allocated: 86.4 Percentage of address space in use by end-sites: 77.4 Total number of prefixes smaller than registry allocations: 142267 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 68490 Total APNIC prefixes after maximum aggregation: 24490 APNIC Deaggregation factor: 2.80 Prefixes being announced from the APNIC address blocks: 67896 Unique aggregates announced from the APNIC address blocks: 30776 APNIC Region origin ASes present in the Internet Routing Table: 3665 APNIC Prefixes per ASN: 18.53 APNIC Region origin ASes announcing only one prefix: 997 APNIC Region transit ASes present in the Internet Routing Table: 556 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 453620336 Equivalent to 27 /8s, 9 /16s and 178 /24s Percentage of available APNIC address space announced: 84.5 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: 123257 Total ARIN prefixes after maximum aggregation: 65969 ARIN Deaggregation factor: 1.87 Prefixes being announced from the ARIN address blocks: 124046 Unique aggregates announced from the ARIN address blocks: 51834 ARIN Region origin ASes present in the Internet Routing Table: 13033 ARIN Prefixes per ASN: 9.52 ARIN Region origin ASes announcing only one prefix: 4995 ARIN Region transit ASes present in the Internet Routing Table: 1276 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 1009227328 Equivalent to 60 /8s, 39 /16s and 150 /24s Percentage of available ARIN address space announced: 194.0 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: 65736 Total RIPE prefixes after maximum aggregation: 38944 RIPE Deaggregation factor: 1.69 Prefixes being announced from the RIPE address blocks: 64869 Unique aggregates announced from the RIPE address blocks: 43770 RIPE Region origin ASes present in the Internet Routing Table: 13116 RIPE Prefixes per ASN: 4.95 RIPE Region origin ASes announcing only one prefix: 6865 RIPE Region transit ASes present in the Internet Routing Table: 1966 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 28 Number of RIPE addresses announced to Internet: 482559648 Equivalent to 28 /8s, 195 /16s and 70 /24s Percentage of available RIPE address space announced: 102.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: 23862 Total LACNIC prefixes after maximum aggregation: 5946 LACNIC Deaggregation factor: 4.01 Prefixes being announced from the LACNIC address blocks: 23726 Unique aggregates announced from the LACNIC address blocks: 13297 LACNIC Region origin ASes present in the Internet Routing Table: 1119 LACNIC Prefixes per ASN: 21.20 LACNIC Region origin ASes announcing only one prefix: 361 LACNIC Region transit ASes present in the Internet Routing Table: 184 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 29 Number of LACNIC addresses announced to Internet: 71622272 Equivalent to 4 /8s, 68 /16s and 222 /24s Percentage of available LACNIC address space announced: 71.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: 6035 Total AfriNIC prefixes after maximum aggregation: 1453 AfriNIC Deaggregation factor: 4.15 Prefixes being announced from the AfriNIC address blocks: 6445 Unique aggregates announced from the AfriNIC address blocks: 2468 AfriNIC Region origin ASes present in the Internet Routing Table: 296 AfriNIC Prefixes per ASN: 21.77 AfriNIC Region origin ASes announcing only one prefix: 88 AfriNIC Region transit ASes present in the Internet Routing Table: 59 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 19460608 Equivalent to 1 /8s, 40 /16s and 242 /24s Percentage of available AfriNIC address space announced: 58.0 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 1709 6931 402 Korea Telecom (KIX) 17488 1600 130 101 Hathway IP Over Cable Interne 4755 1251 362 128 TATA Communications formerly 9583 1100 87 549 Sify Limited 4134 892 16925 377 CHINANET-BACKBONE 7545 793 198 101 TPG Internet Pty Ltd 23577 780 34 664 Korea Telecom (ATM-MPLS) 18101 751 216 30 Reliance Infocom Ltd Internet 24560 714 230 174 Bharti Airtel Ltd. 9829 683 572 18 BSNL National Internet Backbo 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 4290 3647 324 bellsouth.net, inc. 4323 1863 1035 376 Time Warner Telecom 1785 1687 717 138 PaeTec Communications, Inc. 20115 1627 1447 733 Charter Communications 7018 1506 5924 1042 AT&T WorldNet Services 6478 1375 305 476 AT&T Worldnet Services 2386 1264 683 918 AT&T Data Communications Serv 3356 1204 10980 452 Level 3 Communications, LLC 11492 1114 208 12 Cable One 18566 1062 296 10 Covad Communications 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 3292 454 1902 392 TDC Tele Danmark 12479 450 578 6 Uni2 Autonomous System 702 431 1861 347 UUNET - Commercial IP service 30890 413 87 193 Evolva Telecom 35805 358 24 4 United Telecom of Georgia 8866 351 109 21 Bulgarian Telecommunication C 3301 344 1684 307 TeliaNet Sweden 3215 343 3041 108 France Telecom Transpac 3320 338 7066 296 Deutsche Telekom AG 9121 319 1442 25 TTnet Autonomous System 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 1466 2879 233 UniNet S.A. de C.V. 10620 906 206 115 TVCABLE BOGOTA 22047 591 302 14 VTR PUNTO NET S.A. 7303 566 298 85 Telecom Argentina Stet-France 28573 538 563 35 NET Servicos de Comunicao S.A 11830 486 292 54 Instituto Costarricense de El 6471 443 96 32 ENTEL CHILE S.A. 11172 443 102 70 Servicios Alestra S.A de C.V 7738 404 794 28 Telecomunicacoes da Bahia S.A 3816 363 188 81 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 981 188 7 TEDATA 24863 884 82 40 LINKdotNET AS number 20858 324 34 5 EgyNet 3741 277 856 237 The Internet Solution 2018 243 215 143 Tertiary Education Network 6713 160 151 12 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 115 507 66 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 4290 3647 324 bellsouth.net, inc. 4323 1863 1035 376 Time Warner Telecom 4766 1709 6931 402 Korea Telecom (KIX) 1785 1687 717 138 PaeTec Communications, Inc. 20115 1627 1447 733 Charter Communications 17488 1600 130 101 Hathway IP Over Cable Interne 7018 1506 5924 1042 AT&T WorldNet Services 8151 1466 2879 233 UniNet S.A. de C.V. 6478 1375 305 476 AT&T Worldnet Services 2386 1264 683 918 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 1785 1687 1549 PaeTec Communications, Inc. 17488 1600 1499 Hathway IP Over Cable Interne 4323 1863 1487 Time Warner Telecom 4766 1709 1307 Korea Telecom (KIX) 8151 1466 1233 UniNet S.A. de C.V. 4755 1251 1123 TATA Communications formerly 11492 1114 1102 Cable One 18566 1062 1052 Covad Communications 22773 1062 996 Cox Communications, Inc. 8452 981 974 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.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 64.31.59.0/24 7017 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:20 /11:58 /12:166 /13:348 /14:601 /15:1154 /16:10514 /17:4723 /18:8087 /19:16903 /20:20163 /21:19974 /22:25876 /23:25740 /24:150868 /25:863 /26:1030 /27:538 /28:148 /29:8 /30:5 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2796 4290 bellsouth.net, inc. 4766 1402 1709 Korea Telecom (KIX) 17488 1313 1600 Hathway IP Over Cable Interne 1785 1163 1687 PaeTec Communications, Inc. 11492 1044 1114 Cable One 18566 1043 1062 Covad Communications 2386 977 1264 AT&T Data Communications Serv 4323 953 1863 Time Warner Telecom 9583 951 1100 Sify Limited 8452 914 981 TEDATA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:206 12:2245 13:10 15:19 16:2 17:4 20:36 24:1081 32:52 34:2 38:571 40:97 41:1701 43:1 44:2 47:22 52:4 55:2 56:3 57:24 58:570 59:640 60:459 61:1073 62:1107 63:2013 64:3718 65:2384 66:3622 67:1623 68:824 69:2643 70:557 71:174 72:1676 73:2 74:1572 75:169 76:311 77:849 78:549 79:353 80:971 81:833 82:560 83:434 84:634 85:1030 86:397 87:650 88:354 89:1445 90:57 91:2312 92:344 93:1055 94:1228 95:1031 96:140 97:217 98:245 99:22 109:1 110:143 111:9 112:136 113:125 114:256 115:326 116:1163 117:530 118:288 119:692 120:145 121:754 122:1031 123:694 124:994 125:1336 128:224 129:236 130:127 131:408 132:74 133:9 134:186 135:38 136:224 137:153 138:161 139:78 140:433 141:119 142:385 143:345 144:362 145:48 146:380 147:164 148:519 149:233 150:177 151:190 152:147 153:141 154:2 155:276 156:170 157:302 158:115 159:312 160:284 161:151 162:271 163:169 164:482 165:502 166:275 167:359 168:674 169:164 170:471 171:39 172:10 173:287 174:226 178:1 180:1 183:1 186:22 187:96 188:22 189:432 190:2745 192:5780 193:4256 194:3307 195:2696 196:1101 198:3598 199:3360 200:5086 201:1278 202:7900 203:8170 204:3879 205:2153 206:2441 207:2731 208:3883 209:3400 210:2681 211:1122 212:1604 213:1657 214:80 215:31 216:4534 217:1306 218:387 219:443 220:1223 221:488 222:304 End of report From cgrundemann at gmail.com Fri Jun 12 13:50:12 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 12 Jun 2009 12:50:12 -0600 Subject: ICSI Netalyzr launch In-Reply-To: References: <200906092251.n59MpVP3025300@pork.ICSI.Berkeley.EDU> <443de7ad0906102011g2a95b71fx2da0297a5c0f4c9a@mail.gmail.com> <202705b0906120815i214a15cy439906598a0fda52@mail.gmail.com> <443de7ad0906120934h412ce83ct9f3d28f4f72c75ee@mail.gmail.com> Message-ID: <443de7ad0906121150h586d130fgaf799f6cbb10506b@mail.gmail.com> On Fri, Jun 12, 2009 at 11:03, Randy Bush wrote: >>>>> sure, we need a privacy policy that can be arbitrarily changed with no >>>> ... previous ... >>>>> notice just as we have for ... >>>> ... everything !!! >>> exactly. ?so was the question a troll, a red herring, or just a rant? >> If you are saying that the policy can be changed > > i am saying all this is specious. > > if you don't like it, don't use it. ?i have been using vern's stuff for > 15 years or so, and trust him vastly more than i trust 94.3% of all the > other services you trust. > > randy > Probably so and it was not my intention to attack Vern, Berkley, ICIR nor infer that they were not trustworthy. Just pointing out a possible place for improvement from my view. ~Chris From ka at pacific.net Fri Jun 12 13:59:24 2009 From: ka at pacific.net (Ken A) Date: Fri, 12 Jun 2009 13:59:24 -0500 Subject: RIPE NCC interview about IPv6 deployment with Randy Bush In-Reply-To: References: Message-ID: <4A32A58C.5010703@pacific.net> http://downforeveryoneorjustme.com/http://youtube.com/ "It's not just you! http://youtube.com looks down from here." Ken Arno Meulenkamp wrote: > As part of our IPv6 training project, that consists of face to face > training and on-line learning modules and testimonials, we are proud to > announce the second in a series of interviews. > > Randy Bush (IIJ) discusses IPv6 deployment: > http://www.youtube.com/watch?v=QCcigLJJbvU > > So far, we have interviewed 22 people from the community about their > experiences and are very busy editing all the video material. In the > coming months, you will be able to enjoy the rest of the interviews here: > http://www.youtube.com/user/RIPENCC > > These interviews will also be published on our e-learning page and on > our IPv6 Act Now website: > http://ripe.net/training/e-learning/ > http://www.ipv6actnow.org/ > > Cheers, > > Arno Meulenkamp > RIPE NCC -- Ken Anderson Pacific Internet - http://www.pacific.net From marc at let.de Fri Jun 12 14:33:27 2009 From: marc at let.de (Marc Manthey) Date: Fri, 12 Jun 2009 21:33:27 +0200 Subject: RIPE NCC interview about IPv6 deployment with Randy Bush In-Reply-To: <4A32A58C.5010703@pacific.net> References: <4A32A58C.5010703@pacific.net> Message-ID: <5951E5AE-8DD3-4629-A494-F46912C547E0@let.de> Am 12.06.2009 um 20:59 schrieb Ken A: > http://downforeveryoneorjustme.com/http://youtube.com/ > "It's not just you! http://youtube.com looks down from here." seems like a hickup :-) Amazing that even such big sites , with a mega infrastructure, tons of servers and people behind it can?t guarantee 100% uptime greetings marc > > Ken > > > Arno Meulenkamp wrote: >> As part of our IPv6 training project, that consists of face to face >> training and on-line learning modules and testimonials, we are >> proud to announce the second in a series of interviews. >> Randy Bush (IIJ) discusses IPv6 deployment: >> http://www.youtube.com/watch?v=QCcigLJJbvU >> So far, we have interviewed 22 people from the community about >> their experiences and are very busy editing all the video material. >> In the coming months, you will be able to enjoy the rest of the >> interviews here: >> http://www.youtube.com/user/RIPENCC >> These interviews will also be published on our e-learning page and >> on our IPv6 Act Now website: >> http://ripe.net/training/e-learning/ >> http://www.ipv6actnow.org/ >> Cheers, >> Arno Meulenkamp >> RIPE NCC > > > -- > Ken Anderson > Pacific Internet - http://www.pacific.net > -- 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 jmamodio at gmail.com Fri Jun 12 21:35:15 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 12 Jun 2009 21:35:15 -0500 Subject: RIPE NCC interview about IPv6 deployment with Randy Bush In-Reply-To: References: Message-ID: <202705b0906121935s5253314atfaeaa91c4eea9a4d@mail.gmail.com> > Randy Bush (IIJ) discusses IPv6 deployment: > http://www.youtube.com/watch?v=QCcigLJJbvU Wow !!!, Randy with the anti-grumpyness filter sounds and looks quite different. Marvelous technologies of these days ... Cheers From randy at psg.com Fri Jun 12 21:52:34 2009 From: randy at psg.com (Randy Bush) Date: Fri, 12 Jun 2009 22:52:34 -0400 Subject: RIPE NCC interview about IPv6 deployment with Randy Bush In-Reply-To: <202705b0906121935s5253314atfaeaa91c4eea9a4d@mail.gmail.com> References: <202705b0906121935s5253314atfaeaa91c4eea9a4d@mail.gmail.com> Message-ID: > Wow !!!, Randy with the anti-grumpyness filter sounds and looks quite > different. it was the duct tape From jmamodio at gmail.com Fri Jun 12 22:12:40 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 12 Jun 2009 22:12:40 -0500 Subject: RIPE NCC interview about IPv6 deployment with Randy Bush In-Reply-To: References: <202705b0906121935s5253314atfaeaa91c4eea9a4d@mail.gmail.com> Message-ID: <202705b0906122012p1b232250v19e7c32d3845dc7a@mail.gmail.com> On Fri, Jun 12, 2009 at 9:52 PM, Randy Bush wrote: >> Wow !!!, Randy with the anti-grumpyness filter sounds and looks quite >> different. > > it was the duct tape He, he, BTW your interview was really good. Hope some folks get the point that besides many of the challenges to transition to v6 the real deal is what you put very clearly in just one word: "experience". Cheers From tony at lava.net Fri Jun 12 23:27:30 2009 From: tony at lava.net (Antonio Querubin) Date: Fri, 12 Jun 2009 18:27:30 -1000 (HST) Subject: RIPE NCC interview about IPv6 deployment with Randy Bush In-Reply-To: <202705b0906121935s5253314atfaeaa91c4eea9a4d@mail.gmail.com> References: <202705b0906121935s5253314atfaeaa91c4eea9a4d@mail.gmail.com> Message-ID: On Fri, 12 Jun 2009, Jorge Amodio wrote: >> Randy Bush (IIJ) discusses IPv6 deployment: >> http://www.youtube.com/watch?v=QCcigLJJbvU The correct URL is http://youtube.com/watch?v=Qh3i6lDqWBM Antonio Querubin whois: AQ7-ARIN From j at arpa.com Fri Jun 12 23:41:16 2009 From: j at arpa.com (jamie rishaw) Date: Fri, 12 Jun 2009 23:41:16 -0500 Subject: [OT] Micros~1 Sysinternals Message-ID: [Off Topic] [Dont annoy the MLC by making this a thread] [MLC: *waves hand, jedi style* This post is okay.] All, I dont know the politics behind it, but whenever things like this come out, it usually means the viability is being questioned. MS has put out a survey w.r.t. Sysinternals, formerly sysinternals.combut now part of the Microsoft collective. If you use, or have used, Sysinternals tools [1] (invaluable to those with clue trying to deal with MS crap), you know its value. As SANS writes, "If you are a Sysinternals user please consider taking five minutes to contribute to their future." It took me about a minute and a half. The link URL is below at #2, or *http://tinyurl.com/mvtd6d* -jamie [1] http://technet.microsoft.com/en-us/sysinternals/default.aspx [2] SURVEY LINK : *http://tinyurl.com/mvtd6d* , aka http://www.zoomerang.com/Survey/survey-intro.zgi?p=WEB229A879HFVU -- Jamie Rishaw // .com.arpa at j <- reverse it. ish. [Impressive C-level Title Here], arpa / arpa labs From tvhawaii at shaka.com Sat Jun 13 02:05:48 2009 From: tvhawaii at shaka.com (Michael Painter) Date: Fri, 12 Jun 2009 21:05:48 -1000 Subject: [OT] Micros~1 Sysinternals References: Message-ID: <8979D3B805DB4B57B9011C27F37107BB@DELL16> ----- Original Message ----- From: "jamie rishaw" To: "NANOG list" Sent: Friday, June 12, 2009 6:41 PM Subject: [OT] Micros~1 Sysinternals > [Off Topic] [Dont annoy the MLC by making this a thread] > [MLC: *waves hand, jedi style* This post is okay.] > > All, > > I dont know the politics behind it, but whenever things like this come > out, it usually means the viability is being questioned. > > MS has put out a survey w.r.t. Sysinternals, formerly > sysinternals.combut now part of the Microsoft collective. If you use, > or have used, > Sysinternals tools [1] (invaluable to those with clue trying to deal with > MS crap), you know its value. > > As SANS writes, "If you are a Sysinternals user please consider taking > five minutes to contribute to their future." It took me about a minute and > a half. > > The link URL is below at #2, or *http://tinyurl.com/mvtd6d* > > -jamie > > [1] http://technet.microsoft.com/en-us/sysinternals/default.aspx > [2] SURVEY LINK : *http://tinyurl.com/mvtd6d* , aka > http://www.zoomerang.com/Survey/survey-intro.zgi?p=WEB229A879HFVU > > -- > Jamie Rishaw // .com.arpa at j <- reverse it > [Impressive C-level Title Here], arpa / arpa labs Thank you, --Michael From ras at e-gerbil.net Sat Jun 13 12:53:32 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Sat, 13 Jun 2009 12:53:32 -0500 Subject: Traffic billing - L2 encap to include or not? In-Reply-To: <7707838BF569B24DBBDB8F54AB67B67F02CC58A2@foo.kpnqwest.de> References: <7707838BF569B24DBBDB8F54AB67B67F02CC58A2@foo.kpnqwest.de> Message-ID: <20090613175332.GR51443@gerbil.cluepon.net> On Fri, Jun 12, 2009 at 03:32:42PM +0200, Weber, Markus wrote: > > So, is L2 encapsulation (e.g. Ethernet) considered as framing characters > or not? > > Cisco does count them (looks like they also count the FCS), while > Juniper does not (at least not on their routers) with above MIBs. > So who's right? Juniper doesn't do this on purpose, it is just an unfortunate consequence of a hardware architecture which has distributed framing ASICs at the PIC level. For most PICs, the L2 information is already stripped away before the packet reaches the hardware components that are capable of counting or otherwise processing the packets further. This is why you need a far more expensive IQ pic with special processing capabilities on the PIC itself to do things like MAC accounting. Cisco and "everyone else" include the L2 overhead AFAIK. It makes for plenty of confusion come billing time. > PS1: And what about padding? IP packets could be smaller then the min > ethernet frame size ... (think of some kind of DOS attacks) ... > PS2: Oh, maybe someone could check on J switches - would be nice to > know ... The MX uses essentially the same type of hardware as a T-series, but with an extra EZChip ASIC added to do some basic Ethernet framing. You actually pose a good question, it might be possible for them to count the L2 overhead in SNMP, but I'm not sure if they actually do it or not. EX is an entirely different architecture from traditional Juniper routers so I wouldn't even begin to guess. At any rate, this is a discussion better suited for juniper-nsp mailing list. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From bmanning at vacation.karoshi.com Sat Jun 13 04:51:45 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 13 Jun 2009 09:51:45 +0000 Subject: for the DNS inclined Message-ID: <20090613095145.GA10007@vacation.karoshi.com.> With resolution 2009-02-03-04, the ICANN Board asked the Root Server System Advisory Committee (RSSAC), the Security and Stability Advisory Committee (SSAC), and the ICANN staff to study the potential impact on the root zone stability that might arise when IPv6 address records, IDN top level names, other new TLDs, and new records to support DNS security are added to the root zone. The Board has expressed interest in hearing of the impact of the distinct changes, but also their aggregate effect on root zone operations. The Board also asks that the study address the technical and operational concerns regarding expanding the DNS root zone that have been expressed on this topic. A study team has been assembled and is composed of the following: Jaap Akkerhuis Lyman Chapin - Chair Patrik FC$ltstrC6m Glenn Kowack Lars-Johan Liman Bill Manning The goal of the study is to construct a complete, definitive, and authoritative model of the root server system (including all of its provisioning and query components) that shows how the different parts are related, and how changing the value of a variable in one part would affect each of the other parts. It will be as quantitative a model as possible given the relatively short time frame of the study. The idea is not to try to identify all of the bad things that might happen if (for example) the number of TLDs in the root zone were to increase by several orders of magnitude during the same time period in which new RRs were added for DNSSEC (b^@^\how many entries in the root zone is too many?b^@^]), but to construct a model that demonstrates what the effects would be throughout the system of changing the value of one or more variables either individually or in combination (e.g., the rate at which new TLDs are added to the root, or the frequency of key rollover events in a signed root). This model will provide an unbiased factual and analyticalb^@^Trather than anecdotalb^@^Tbasis for recognizing and evaluating concerns about root server system security and stability as the root grows. As a tool for policy makers, it will show the expected impact on the root server system of policy decisions that would change various root zone parameters. The study team has a couple of methods for collecting inputs and encourages interested parties to provide the study team with their concerns. There is a public mailing list: root-scaling at icann.org and There is a comment site: +http://www.icann.org/en/public-comment/public-comment-200907.html#root-scaling If there are others whom you think would be interested in this work or have opinions/ideas, please pass along this note. Thanks From orion at pirk.com Sat Jun 13 19:13:56 2009 From: orion at pirk.com (Steve Pirk) Date: Sat, 13 Jun 2009 17:13:56 -0700 (PDT) Subject: [inquiry] Internet/cell in Teheran down? Message-ID: Npr (All things considered) is reporting that cell phones and Internet access in at least Teheran if not all of Iran is down. Reporters are unable to connect out. Anyone hear of anything? -steve From reese at inkworkswell.com Sat Jun 13 20:47:57 2009 From: reese at inkworkswell.com (Reese) Date: Sat, 13 Jun 2009 20:47:57 -0500 Subject: [inquiry] Internet/cell in Teheran down? In-Reply-To: References: Message-ID: <4A3456CD.6010505@inkworkswell.com> Steve Pirk wrote: > Npr (All things considered) is reporting that cell phones and Internet > access in at least Teheran if not all of Iran is down. Reporters are > unable to connect out. > > Anyone hear of anything? Given the recent election and the unrest that is also being reported, I'd bet that it was unplugged or turned off, not that it is down. Or, is there another Operator's Group for that world region? Maybe the discussion simply hasn't filtered over yet. Reese From jared at puck.nether.net Sat Jun 13 19:57:31 2009 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 13 Jun 2009 20:57:31 -0400 Subject: [inquiry] Internet/cell in Teheran down? In-Reply-To: <4A3456CD.6010505@inkworkswell.com> References: <4A3456CD.6010505@inkworkswell.com> Message-ID: <20090614005731.GA37862@puck.nether.net> On Sat, Jun 13, 2009 at 08:47:57PM -0500, Reese wrote: > Steve Pirk wrote: >> Npr (All things considered) is reporting that cell phones and Internet >> access in at least Teheran if not all of Iran is down. Reporters are >> unable to connect out. >> >> Anyone hear of anything? > > > Given the recent election and the unrest that is also being reported, > I'd bet that it was unplugged or turned off, not that it is down. Or, > is there another Operator's Group for that world region? Maybe the > discussion simply hasn't filtered over yet. the menog lists require you to subscribe to view the archives. (So this could be redundant to content there.. i am not on their list). I checked one ISP I know about in Tehran and they appear to be up. This doesn't seem to be an like what was seen with Myanmar(Burma) turning off the tubes. (At least not yet). I'm keeping an eye on things, if people in those parts of the world need some backup dns or other things, I am sure there are plenty of people here that can help. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From fergdawgster at gmail.com Sat Jun 13 20:00:06 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Sat, 13 Jun 2009 18:00:06 -0700 Subject: [inquiry] Internet/cell in Teheran down? In-Reply-To: References: Message-ID: <6cd462c00906131800h3dd9550fif521b87901642c8f@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Jun 13, 2009 at 5:13 PM, Steve Pirk wrote: > Npr (All things considered) is reporting that cell phones and Internet > access in at least Teheran if not all of Iran is down. Reporters are > unable to connect out. > > Anyone hear of anything? Nothing specific on traffic *getting out* of Iran, but the official Iranian News Service (IRNA: Islamic Republic News Agency) website is certainly available the web ( at least the website loads): http://www.irna.ir/en/ %tracert irna.ir Tracing route to irna.ir [81.12.51.146] over a maximum of 30 hops: [snip] 6 36 ms 19 ms 30 ms pos-0-8-0-0-cr01.sanjose.ca.ibone.comcast.net [68.86.85.78] 7 25 ms 23 ms 56 ms pos-0-0-0-0-pe01.11greatoaks.ca.ibone.comcast.net [68.86.86.54] 8 27 ms 47 ms 21 ms Tenge13-3.br02.sjo01.pccwbtn.net [63.218.179.25] 9 459 ms 409 ms 409 ms tci.pos3-5.ar03.ldn01.pccwbtn.net [63.218.13.30] 10 428 ms 409 ms 409 ms 217.218.155.202 11 401 ms 409 ms 409 ms 217.218.127.246 12 384 ms 409 ms 337 ms vlan625.orion.bb.noc.tehran.sinet.ir [62.220.96.113] 13 400 ms 510 ms 412 ms vl637.orion.bb.noc.tehran.sinet.ir [62.220.99.1] 14 384 ms 409 ms 409 ms 62.220.100.10 15 * 366 ms 409 ms fe0-20.selena.bb.noc.tehran.sinet.ir [62.220.101.182] 16 397 ms 367 ms 347 ms 87.107.82.3 17 361 ms 340 ms 416 ms 81.12.50.2 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * ^C - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFKNEuGq1pz9mNUZTMRAvaoAKDhTB+F6gxUydKSQ+PyNMdWd7GDSACeKtNY 5oIZm2FC+rvN0ij97ovp0Oo= =YTJ5 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From woody at pch.net Sat Jun 13 20:00:15 2009 From: woody at pch.net (Bill Woodcock) Date: Sat, 13 Jun 2009 18:00:15 -0700 (PDT) Subject: [inquiry] Internet/cell in Teheran down? In-Reply-To: <20090614005731.GA37862@puck.nether.net> References: <4A3456CD.6010505@inkworkswell.com> <20090614005731.GA37862@puck.nether.net> Message-ID: On Sat, 13 Jun 2009, Jared Mauch wrote: > the menog lists require you to subscribe to > view the archives. (So this could be redundant to content > there.. i am not on their list). No, this conversation is not also occuring on the MENOG list. -Bill From brunner at nic-naa.net Sat Jun 13 20:28:29 2009 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sat, 13 Jun 2009 21:28:29 -0400 Subject: [inquiry] Internet/cell in Teheran down? In-Reply-To: References: Message-ID: <4A34523D.2050909@nic-naa.net> I exchanged notes with someone in Tehran shortly after 6am EDT this morning. NPR is at least partially incorrect. Steve Pirk wrote: > Npr (All things considered) is reporting that cell phones and Internet > access in at least Teheran if not all of Iran is down. Reporters are > unable to connect out. > > Anyone hear of anything? > -steve > > > From mmc at internode.com.au Sat Jun 13 21:12:19 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sun, 14 Jun 2009 11:42:19 +0930 Subject: [inquiry] Internet/cell in Tehran down? In-Reply-To: <4A34523D.2050909@nic-naa.net> References: <4A34523D.2050909@nic-naa.net> Message-ID: <4A345C83.9070209@internode.com.au> Maybe there's just a lot of congestion and it's not actually down? Happens here (Australia) on some mobile networks at large events - just not enough bandwidth to go around and so you can't make calls and sms are delayed. Given that there's a lot of protests etc and a lot of people out and about in Tehran it could be similar. MMC Eric Brunner-Williams wrote: > I exchanged notes with someone in Tehran shortly after 6am EDT this > morning. NPR is at least partially incorrect. > > Steve Pirk wrote: >> Npr (All things considered) is reporting that cell phones and >> Internet access in at least Teheran if not all of Iran is down. >> Reporters are >> unable to connect out. >> >> Anyone hear of anything? >> -steve >> >> >> > > From jeffrey.lyon at blacklotus.net Sat Jun 13 21:40:24 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 13 Jun 2009 22:40:24 -0400 Subject: [inquiry] Internet/cell in Tehran down? In-Reply-To: <4A345C83.9070209@internode.com.au> References: <4A34523D.2050909@nic-naa.net> <4A345C83.9070209@internode.com.au> Message-ID: <16720fe00906131940v2919636xa9bf73865e0ea9d1@mail.gmail.com> http://www.lasvegassun.com/news/2009/jun/13/cell-phone-service-down-after-disputed-iran-vote/ On Sat, Jun 13, 2009 at 10:12 PM, Matthew Moyle-Croft wrote: > Maybe there's just a lot of congestion and it's not actually down? > > Happens here (Australia) on some mobile networks at large events - just not > enough bandwidth to go around and so you can't make calls and sms are > delayed. ?Given that there's a lot of protests etc and a lot of people out > and about in Tehran it could be similar. > > MMC > > Eric Brunner-Williams wrote: >> >> I exchanged notes with someone in Tehran shortly after 6am EDT this >> morning. NPR is at least partially incorrect. >> >> Steve Pirk wrote: >>> >>> Npr (All things considered) is reporting that cell phones and Internet >>> access in at least Teheran if not all of Iran is down. Reporters are >>> unable to connect out. >>> >>> Anyone hear of anything? >>> -steve >>> >>> >>> >> >> > > -- 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 bobbyjim at gmail.com Sat Jun 13 23:50:02 2009 From: bobbyjim at gmail.com (bobbyjim at gmail.com) Date: Sat, 13 Jun 2009 23:50:02 -0500 Subject: [inquiry] Internet/cell in Teheran down? Message-ID: <4a34816e.1e035a0a.6381.0445@mx.google.com> So what's the update. Has iran gone back? -----Original Message----- From: Eric Brunner-Williams Sent: Saturday, June 13, 2009 8:28 PM To: Steve Pirk Cc: nanog at nanog.org Subject: Re: [inquiry] Internet/cell in Teheran down? I exchanged notes with someone in Tehran shortly after 6am EDT this morning. NPR is at least partially incorrect. Steve Pirk wrote: > Npr (All things considered) is reporting that cell phones and Internet > access in at least Teheran if not all of Iran is down. Reporters are > unable to connect out. > > Anyone hear of anything? > -steve > > > From tme at americafree.tv Sun Jun 14 01:38:57 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Sun, 14 Jun 2009 02:38:57 -0400 Subject: [inquiry] Internet/cell in Teheran down? In-Reply-To: <4a34816e.1e035a0a.6381.0445@mx.google.com> References: <4a34816e.1e035a0a.6381.0445@mx.google.com> Message-ID: <872DCB6C-1D56-4ADC-993A-27CEBF07794D@americafree.tv> On Jun 14, 2009, at 12:50 AM, bobbyjim at gmail.com wrote: > So what's the update. Has iran gone back? > I don't think so but I think that there are interruptions. There is still BGP to at least some Iranian sites. The University of Teheran, for example, has *> 80.66.176.0/21 38.101.161.116 61951 0 174 7473 12880 29068 i *> 80.66.184.0/21 38.101.161.116 61951 0 174 7473 12880 29068 i Its (English) web service, http://www.ut.ac.ir/en/ is at 80.66.177.63 and that is both reachable and pingable. So, the site is reachable and the DNS is still there. However, the (small but steady) Iranian audience for AmericaFree.TV has largely, but not entirely, vanished for the last 24 hours. That suggests to me something is being blocked, but not uniformly. Regards Marshall > > > -----Original Message----- > From: Eric Brunner-Williams > Sent: Saturday, June 13, 2009 8:28 PM > To: Steve Pirk > Cc: nanog at nanog.org > Subject: Re: [inquiry] Internet/cell in Teheran down? > > I exchanged notes with someone in Tehran shortly after 6am EDT this > morning. NPR is at least partially incorrect. > > Steve Pirk wrote: >> Npr (All things considered) is reporting that cell phones and >> Internet >> access in at least Teheran if not all of Iran is down. Reporters are >> unable to connect out. >> >> Anyone hear of anything? >> -steve >> >> >> > > > > > From tme at americafree.tv Sun Jun 14 08:22:51 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Sun, 14 Jun 2009 09:22:51 -0400 Subject: [inquiry] Internet/cell in Teheran down? In-Reply-To: <20090614005731.GA37862@puck.nether.net> References: <4A3456CD.6010505@inkworkswell.com> <20090614005731.GA37862@puck.nether.net> Message-ID: <61DE05EC-9AE1-4C5D-94D8-B6AC90B146E4@americafree.tv> On Jun 13, 2009, at 8:57 PM, Jared Mauch wrote: > On Sat, Jun 13, 2009 at 08:47:57PM -0500, Reese wrote: >> Steve Pirk wrote: >>> Npr (All things considered) is reporting that cell phones and >>> Internet >>> access in at least Teheran if not all of Iran is down. Reporters are >>> unable to connect out. >>> >>> Anyone hear of anything? >> >> >> Given the recent election and the unrest that is also being reported, >> I'd bet that it was unplugged or turned off, not that it is down. Or, >> is there another Operator's Group for that world region? Maybe the >> discussion simply hasn't filtered over yet. > > the menog lists require you to subscribe to > view the archives. (So this could be redundant to content > there.. i am not on their list). I am on MENOG. There has been no discussion of this topic there, at least so far. Regards Marshall > > > I checked one ISP I know about in Tehran and they appear > to be up. This doesn't seem to be an like what was seen with > Myanmar(Burma) > turning off the tubes. (At least not yet). > > I'm keeping an eye on things, if people in those parts of > the world need some backup dns or other things, I am sure there are > plenty > of people here that can help. > > - Jared > > -- > Jared Mauch | pgp key available via finger from jared at puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are > only mine. > > From andy at nosignal.org Sun Jun 14 11:39:09 2009 From: andy at nosignal.org (Andy Davidson) Date: Sun, 14 Jun 2009 17:39:09 +0100 Subject: RIPE NCC interview about IPv6 deployment with Randy Bush In-Reply-To: References: Message-ID: On 12 Jun 2009, at 19:03, Lucy Lynch wrote: > On Fri, 12 Jun 2009, Arno Meulenkamp wrote: >> Randy Bush (IIJ) discusses IPv6 deployment: >> http://www.youtube.com/watch?v=QCcigLJJbvU > He got larger! Randy is here: http://www.youtube.com/watch?v=Qh3i6lDqWBM Best wishes Andy Davidson Officially larger than Randy Bush. From mabrown at renesys.com Sun Jun 14 14:10:45 2009 From: mabrown at renesys.com (Martin A. Brown) Date: Sun, 14 Jun 2009 14:10:45 -0500 Subject: [inquiry] Internet/cell in Teheran down? In-Reply-To: <61DE05EC-9AE1-4C5D-94D8-B6AC90B146E4@americafree.tv> References: <4A3456CD.6010505@inkworkswell.com> <20090614005731.GA37862@puck.nether.net> <61DE05EC-9AE1-4C5D-94D8-B6AC90B146E4@americafree.tv> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, We examined yesterday's BGP advertisement patterns for evidence of transit change, outage and instability (the outage and instability pattern was fairly obvious, but certainly didn't look like a natural disaster). Anyway, we did notice a rather unmistakeable transit shift to TTNet for all paths inbound to 12880 (DCI) the primary transit provider in Iran. For a bit more detail, you can check out our story [0]. Thanks again to all of our BGP peers! - -Martin [0] http://www.renesys.com/blog/2009/06/strange-changes-in-iranian-int.shtml - -- Martin A. Brown --- Renesys Corporation --- mabrown at renesys.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: pgf-0.72 (http://linux-ip.net/sw/pine-gpg-filter/) iD8DBQFKNUs4dXQGngQsWbkRAnl/AJ98k2C7j5WE1gJ0uWjr+RYBybKHiQCgqG1o OaMwWEG/g7LDH8cSukLpWnw= =oUAI -----END PGP SIGNATURE----- From gmartine at ajax.opentransit.net Sun Jun 14 16:52:46 2009 From: gmartine at ajax.opentransit.net (German Martinez) Date: Sun, 14 Jun 2009 17:52:46 -0400 Subject: Cogent input In-Reply-To: References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> <4A318C80.6010000@telcodata.us> Message-ID: <20090614215246.GA8015@ajax.opentransit.net> On Thu Jun 11, 2009, John van Oppen wrote: > NTT (2914) and GBLX (3549) both do native v6... most everyone else on > the tier1 list does tunnels. :( AS5511 runs a double stack network for at least 7 years. > > There are some nice tier2 networks who do native v6, tiscali and he.net > come to mind. > > > -John > > -----Original Message----- > From: Paul Timmins [mailto:paul at telcodata.us] > Sent: Thursday, June 11, 2009 4:00 PM > To: Justin Shore > Cc: NANOG > Subject: Re: Cogent input > > > > > > I hope at least some SPs make this commitment back in the states. I > > can't find any tier-1s that can provide us with native v6. Our tier-1 > > > upstream has a best effort test program in place that uses ipv6ip > > tunnels. The other upstream says that they aren't making any public > > IPv6 plans yet. It's hard to push the migration to v6 along when > > native v6 providers aren't readily available. > > GlobalCrossing told me today I can order native IPv6 anywhere on their > network. Don't know if they count as Tier 1 on your list, though. VZB > has given me tunnels for a while, hopefully they'll get their pMTU issue > > fixed so we can do more interesting things with it. > > -Paul > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From gmartine at ajax.opentransit.net Sun Jun 14 16:56:51 2009 From: gmartine at ajax.opentransit.net (German Martinez) Date: Sun, 14 Jun 2009 17:56:51 -0400 Subject: Cogent input In-Reply-To: References: <4A310AC5.5050701@justinshore.com> Message-ID: <20090614215651.GE8046@ajax.opentransit.net> On Thu Jun 11, 2009, Alex Rubenstein wrote: > > I'm aware of some (regular?) depeering issues. The NANOG archives have > > AFAIR, there has never been a black-holing, just disappearance of routes. If you are properly multihomed, this is irrelevant and you continue to eat your ice cream and chuckle while they fight it out. It's amusing, really. > > I guess the blackholing could come from Cogent having a route to you but *YOU* not having a route back to Cogent as a consequence of the depeering. German > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jeroen at unfix.org Sun Jun 14 17:04:46 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 15 Jun 2009 00:04:46 +0200 Subject: IPv6 transits (Was: Cogent input) In-Reply-To: <20090614215246.GA8015@ajax.opentransit.net> References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> <4A318C80.6010000@telcodata.us> <20090614215246.GA8015@ajax.opentransit.net> Message-ID: <4A3573FE.9090008@spaghetti.zurich.ibm.com> German Martinez wrote: > On Thu Jun 11, 2009, John van Oppen wrote: > >> NTT (2914) and GBLX (3549) both do native v6... most everyone else on >> the tier1 list does tunnels. :( > > AS5511 runs a double stack network for at least 7 years. > >> There are some nice tier2 networks who do native v6, tiscali and he.net >> come to mind. For people trying to find the "list", check: http://www.sixxs.net/faq/connectivity/?faq=ipv6transit Of course, for updates etc, don't hesitate to mail... 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 jared at puck.nether.net Sun Jun 14 17:32:23 2009 From: jared at puck.nether.net (Jared Mauch) Date: Sun, 14 Jun 2009 18:32:23 -0400 Subject: [inquiry] Internet/cell in Teheran down? In-Reply-To: <4a34816e.1e035a0a.6381.0445@mx.google.com> References: <4a34816e.1e035a0a.6381.0445@mx.google.com> Message-ID: I received the following report from a network operator in Teheran: --- snip --- SMS is down since friday for all three cell operators. In the areas that riot is taken place, cell phones are not working. Outgoing calls to certain countries are blocked. DCI, the organization in charge of internet connectivity, that provides internet transit for local isps has taken down 80% of its uplink connectivity and currently only a few peers (TTNET as far as I know) are active. --- snip --- - Jared On Jun 14, 2009, at 12:50 AM, bobbyjim at gmail.com wrote: > So what's the update. Has iran gone back? > > > > -----Original Message----- > From: Eric Brunner-Williams > Sent: Saturday, June 13, 2009 8:28 PM > To: Steve Pirk > Cc: nanog at nanog.org > Subject: Re: [inquiry] Internet/cell in Teheran down? > > I exchanged notes with someone in Tehran shortly after 6am EDT this > morning. NPR is at least partially incorrect. > > Steve Pirk wrote: >> Npr (All things considered) is reporting that cell phones and >> Internet >> access in at least Teheran if not all of Iran is down. Reporters are >> unable to connect out. >> >> Anyone hear of anything? >> -steve >> >> >> > > > From marc at let.de Sun Jun 14 21:29:18 2009 From: marc at let.de (Marc Manthey) Date: Mon, 15 Jun 2009 04:29:18 +0200 Subject: [inquiry] Internet/cell in Teheran down? In-Reply-To: References: <4a34816e.1e035a0a.6381.0445@mx.google.com> Message-ID: <0DDF2BF1-7825-40CC-98E8-92BC68E0D260@let.de> Am 15.06.2009 um 00:32 schrieb Jared Mauch: > --- snip --- > SMS is down since friday for all three cell operators. In the areas > that riot is taken place, cell phones are not working. Outgoing calls > to certain countries are blocked. DCI, the organization in charge of > internet connectivity, that provides internet transit for local isps > has taken down 80% of its uplink connectivity and currently only a few > peers (TTNET as far as I know) are active. > --- snip --- thanks for sharing http://twitter.com/macbroadcast/status/2172515490 http://twitter.com/Change_for_Iran Marc > > - Jared > > On Jun 14, 2009, at 12:50 AM, bobbyjim at gmail.com wrote: > >> So what's the update. Has iran gone back? >> >> >> >> -----Original Message----- >> From: Eric Brunner-Williams >> Sent: Saturday, June 13, 2009 8:28 PM >> To: Steve Pirk >> Cc: nanog at nanog.org >> Subject: Re: [inquiry] Internet/cell in Teheran down? >> >> I exchanged notes with someone in Tehran shortly after 6am EDT this >> morning. NPR is at least partially incorrect. >> >> Steve Pirk wrote: >>> Npr (All things considered) is reporting that cell phones and >>> Internet >>> access in at least Teheran if not all of Iran is down. Reporters are >>> unable to connect out. >>> >>> Anyone hear of anything? >>> -steve >>> -- 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 bmanning at vacation.karoshi.com Mon Jun 15 07:04:13 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 15 Jun 2009 12:04:13 +0000 Subject: for the DNS inclined In-Reply-To: <20090615113953.GW31924@giscard.mcbone.net> References: <20090613095145.GA10007@vacation.karoshi.com.> <20090615113953.GW31924@giscard.mcbone.net> Message-ID: <20090615120413.GA1311@vacation.karoshi.com.> On Mon, Jun 15, 2009 at 01:39:53PM +0200, Stefan Schmidt wrote: > Hi Bill, > > On Sat, Jun 13, 2009 at 09:51:45AM +0000, bmanning at vacation.karoshi.com wrote: > > There is a public mailing list: root-scaling at icann.org > > I fear from the ICANN Website it's not apparent how to subscribe to this > list, can you give me or nanog/dnsop a hint? > > Stefan > -- > Truman's Law: If you can't convince them, confuse them. i am sorry for the confusion. Threw me for a loop as well... i wrote: There is a public mailing list: root-scaling at icann.org and There is a comment site: +http://www.icann.org/en/public-comment/public-comment-200907.html#root-scaling which in ICANN parlance is: send mail to and your mail shows up on the ICANN website at: http://www.icann.org/en/public-comment/public-comment-200907.html#root-scaling so its not really a forum or format for discussion, its more of a forum where one can vent. not the cleanest design, but that's ICANN view of gaining public inputs. i suspect if you sent mail to any of the members of the study team, inputs would be considered, but it would not be public. --bill From Valdis.Kletnieks at vt.edu Mon Jun 15 10:46:56 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 15 Jun 2009 11:46:56 -0400 Subject: Cogent input In-Reply-To: Your message of "Sun, 14 Jun 2009 17:56:51 EDT." <20090614215651.GE8046@ajax.opentransit.net> References: <4A310AC5.5050701@justinshore.com> <20090614215651.GE8046@ajax.opentransit.net> Message-ID: <41105.1245080816@turing-police.cc.vt.edu> On Sun, 14 Jun 2009 17:56:51 EDT, German Martinez said: > I guess the blackholing could come from Cogent having a route to you but *YOU* > not having a route back to Cogent as a consequence of the depeering. Wouldn't that only happen if some AS was foolish enough to single-home upstream of a Tier-1? Consider it evolution in action... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From jmamodio at gmail.com Mon Jun 15 13:43:34 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 15 Jun 2009 13:43:34 -0500 Subject: Tom, get closer to the mike !!!! Message-ID: <202705b0906151143h322c00d8h4ab6a51bdd8cdb68@mail.gmail.com> ouch From cmaurand at xyonet.com Mon Jun 15 14:04:31 2009 From: cmaurand at xyonet.com (Curtis Maurand) Date: Mon, 15 Jun 2009 15:04:31 -0400 Subject: GoDaddy DNS Contact Message-ID: <4A369B3F.80900@xyonet.com> Would a GoDaddy DNS registration rep contact me off list, please? Thanks in advance, Curtis Maurand 207-252-7748 From quinn at activehost.com Mon Jun 15 15:16:03 2009 From: quinn at activehost.com (Quinn Mahoney) Date: Mon, 15 Jun 2009 16:16:03 -0400 Subject: spamhaus drop list Message-ID: <8685783A8C22C640AD1361E78659B7D76975FF@ahex02.activehost.local> I'm looking to implement the Spamhaus drop list. http://www.spamhaus.org/drop/index.lasso On their FAQ they have a script that looks like it grabs the lists text file and connects to a given router, and tells you what has changed in the list, and what your router is null routing. I'm not sure if it then removes the null routes if a list entry has been removed. I haven't found much documentation on the net regarding this. In the future it looks like you will be able to peer with them and null route traffic from a private AS, which will be routes from the drop list. Right now though, it looks like you'd have to update an ACL manually for any changes to the list. Or use this script which null routes the traffic (I guess it's not a big deal getting the syn packets, as long as the mail won't send because of the null route). I am not sure if this script updates the null routes automatically, or how to use it, I can't find to much documentation. Any documentation on this script or another script available. What are your suggestions? thanks From fred at cisco.com Mon Jun 15 15:44:41 2009 From: fred at cisco.com (Fred Baker) Date: Mon, 15 Jun 2009 13:44:41 -0700 Subject: spamhaus drop list In-Reply-To: <8685783A8C22C640AD1361E78659B7D76975FF@ahex02.activehost.local> References: <8685783A8C22C640AD1361E78659B7D76975FF@ahex02.activehost.local> Message-ID: <723AEFA8-0FA1-4D73-A6C2-29B001C2E24A@cisco.com> On Jun 15, 2009, at 1:16 PM, Quinn Mahoney wrote: > Or use this script which null routes the traffic (I guess it's not a > big deal getting the syn packets, as long as the mail won't send > because of the null route) I you are using uRPF, the SYN packets won't get through either, because they came from an interface other than the null interface. Not so helpful interddomain, but it protects your customers from each other (as BCP 38 does in other cases). From cmadams at hiwaay.net Mon Jun 15 16:18:54 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 15 Jun 2009 16:18:54 -0500 Subject: spamhaus drop list In-Reply-To: <723AEFA8-0FA1-4D73-A6C2-29B001C2E24A@cisco.com> References: <8685783A8C22C640AD1361E78659B7D76975FF@ahex02.activehost.local> <723AEFA8-0FA1-4D73-A6C2-29B001C2E24A@cisco.com> Message-ID: <20090615211854.GB1167452@hiwaay.net> Once upon a time, Fred Baker said: > On Jun 15, 2009, at 1:16 PM, Quinn Mahoney wrote: > >Or use this script which null routes the traffic (I guess it's not a > >big deal getting the syn packets, as long as the mail won't send > >because of the null route) > > I you are using uRPF, the SYN packets won't get through either, > because they came from an interface other than the null interface. Not > so helpful interddomain, but it protects your customers from each > other (as BCP 38 does in other cases). Not true for JUNOS; "discard" routes are still in the forwarding table and are treated as a valid destination when it comes to loose-mode uRPF. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From rs at seastrom.com Mon Jun 15 16:20:09 2009 From: rs at seastrom.com (Robert E. Seastrom) Date: Mon, 15 Jun 2009 17:20:09 -0400 Subject: Apple SSL CA cert Fail (MacOS 10.5.7) Message-ID: <86bpopurcm.fsf@seastrom.com> Hi foks, Ordinarily I wouldn't send reports of operating system bugs that pose no security risk to this list, but I'm making an exception in this case due to the following conditions: 1) There are a lot of Mac users in the NANOG community. 2) There is a preponderance of folks here who run their own CAs 3) CA software, particularly OpenSSL, is byzantine enough that upon running into a problem, one is likely to think he is the faulty party. 4) I just burned three evenings last week chasing this bug. I don't have sufficient extra hair to be spending my evenings tearing it out and you might not either. Summary: MacOSX's keychain access application mishandles importing root CA certs. This only happens under 10.5.7; other versions are fine. There is a workaround using command line tools. Details at http://support.apple.com/kb/TS2747 -r From emf1123 at gmail.com Mon Jun 15 16:36:55 2009 From: emf1123 at gmail.com (Erik Fichtner) Date: Mon, 15 Jun 2009 17:36:55 -0400 Subject: Verio taking twitter down during Iran Election Riots? Message-ID: <4A36BEF7.9090806@gmail.com> http://status.twitter.com/post/124145031/maintenance-window-tonight-9-45p-pacific Am I reading that right? Is someone at Verio seriously going to take twitter out for 90 minutes at 9am in Tehran? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 186 bytes Desc: OpenPGP digital signature URL: From emf1123 at gmail.com Mon Jun 15 16:45:26 2009 From: emf1123 at gmail.com (Erik Fichtner) Date: Mon, 15 Jun 2009 17:45:26 -0400 Subject: Make that NTT America (was Re: Verio taking twitter down during Iran Election Riots? In-Reply-To: <4A36BEF7.9090806@gmail.com> References: <4A36BEF7.9090806@gmail.com> Message-ID: <4A36C0F6.4070704@gmail.com> Erik Fichtner wrote: > http://status.twitter.com/post/124145031/maintenance-window-tonight-9-45p-pacific > > Am I reading that right? Is someone at Verio seriously going to take twitter out > for 90 minutes at 9am in Tehran? I am reading it wrong, partially. It's NTT America, not Verio. Missed a layer. Anyway... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 186 bytes Desc: OpenPGP digital signature URL: From bc-list at beztech.net Mon Jun 15 16:50:36 2009 From: bc-list at beztech.net (Ben Carleton) Date: Mon, 15 Jun 2009 17:50:36 -0400 Subject: Make that NTT America (was Re: Verio taking twitter down during Iran Election Riots? In-Reply-To: <4A36C0F6.4070704@gmail.com> References: <4A36BEF7.9090806@gmail.com> <4A36C0F6.4070704@gmail.com> Message-ID: Why would NTT take it out for the whole world when DCI could just block it from Iran? --b On Jun 15, 2009, at 5:45 PM, Erik Fichtner wrote: > Erik Fichtner wrote: >> http://status.twitter.com/post/124145031/maintenance-window-tonight-9-45p-pacific >> >> Am I reading that right? Is someone at Verio seriously going to >> take twitter out >> for 90 minutes at 9am in Tehran? > > > I am reading it wrong, partially. It's NTT America, not Verio. > Missed a layer. > > > Anyway... > From alex at blastro.com Mon Jun 15 16:50:57 2009 From: alex at blastro.com (Alex Thurlow) Date: Mon, 15 Jun 2009 16:50:57 -0500 Subject: Make that NTT America (was Re: Verio taking twitter down during Iran Election Riots? In-Reply-To: <4A36C0F6.4070704@gmail.com> References: <4A36BEF7.9090806@gmail.com> <4A36C0F6.4070704@gmail.com> Message-ID: <4A36C241.9090907@blastro.com> On 6/15/2009 4:45 PM, Erik Fichtner wrote: > Erik Fichtner wrote: > >> http://status.twitter.com/post/124145031/maintenance-window-tonight-9-45p-pacific >> > > > I am reading it wrong, partially. It's NTT America, not Verio. Missed a layer. > > > Anyway... > > I know they're not actually making any money, so they may not be able to afford it, but shouldn't a service that's trying to be as big as twitter be multihomed? From marc at let.de Mon Jun 15 16:57:48 2009 From: marc at let.de (Marc Manthey) Date: Mon, 15 Jun 2009 23:57:48 +0200 Subject: Make that NTT America (was Re: Verio taking twitter down during Iran Election Riots? In-Reply-To: <4A36C241.9090907@blastro.com> References: <4A36BEF7.9090806@gmail.com> <4A36C0F6.4070704@gmail.com> <4A36C241.9090907@blastro.com> Message-ID: <9102FE73-E88D-4C2C-8E2B-5FA4968E6C7C@let.de> Am 15.06.2009 um 23:50 schrieb Alex Thurlow: >> > I know they're not actually making any money, so they may not be > able to afford it, but shouldn't a service that's trying to be as > big as twitter be multihomed? they got 35 million lately and there was arumor that apple wnted to buy twitter for 700 million so i think money is not an issue!!! http://bits.blogs.nytimes.com/2009/02/13/twitter-raises-35-million/ -- 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 emf1123 at gmail.com Mon Jun 15 16:59:36 2009 From: emf1123 at gmail.com (Erik Fichtner) Date: Mon, 15 Jun 2009 17:59:36 -0400 Subject: Make that NTT America (was Re: Verio taking twitter down during Iran Election Riots? In-Reply-To: <366100670906151447y70285f39x943757db218c4046@mail.gmail.com> References: <4A36BEF7.9090806@gmail.com> <4A36C0F6.4070704@gmail.com> <366100670906151447y70285f39x943757db218c4046@mail.gmail.com> Message-ID: <4A36C448.7060206@gmail.com> Brandon Galbraith wrote: >> http://status.twitter.com/post/124145031/maintenance-window-tonight-9-45p-pacific > You sure it's their network, and not Twitter's core/edge? They're blaming it on their upstream. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 186 bytes Desc: OpenPGP digital signature URL: From jasondearborn at gmail.com Mon Jun 15 17:06:26 2009 From: jasondearborn at gmail.com (Jason Dearborn) Date: Mon, 15 Jun 2009 18:06:26 -0400 Subject: Make that NTT America (was Re: Verio taking twitter down during Iran Election Riots? In-Reply-To: <4A36C448.7060206@gmail.com> References: <4A36BEF7.9090806@gmail.com> <4A36C0F6.4070704@gmail.com> <366100670906151447y70285f39x943757db218c4046@mail.gmail.com> <4A36C448.7060206@gmail.com> Message-ID: <4296d7270906151506h1a3bd508y2521d685360c3619@mail.gmail.com> Twitter doesn't run their own core or edge. It's all in the NTT "cloud". On Mon, Jun 15, 2009 at 5:59 PM, Erik Fichtner wrote: > Brandon Galbraith wrote: > >>> http://status.twitter.com/post/124145031/maintenance-window-tonight-9-45p-pacific > >> You sure it's their network, and not Twitter's core/edge? > > They're blaming it on their upstream. > > > From srepetsk at tjhsst.edu Mon Jun 15 18:22:33 2009 From: srepetsk at tjhsst.edu (Stephen Repetski) Date: Mon, 15 Jun 2009 19:22:33 -0400 Subject: Verio taking twitter down during Iran Election Riots? In-Reply-To: <4A36BEF7.9090806@gmail.com> References: <4A36BEF7.9090806@gmail.com> Message-ID: <2e6d38e0906151622l70d7f44ftf82dc7a2058e2e42@mail.gmail.com> Yep, that's what it says. Things like "critical network upgrades" sometimes don't wait for good timing - they make their own special event. On Mon, Jun 15, 2009 at 5:36 PM, Erik Fichtner wrote: > > > http://status.twitter.com/post/124145031/maintenance-window-tonight-9-45p-pacific > > Am I reading that right? Is someone at Verio seriously going to take > twitter out > for 90 minutes at 9am in Tehran? > > > > From nanog304985 at aquick.org Mon Jun 15 18:32:14 2009 From: nanog304985 at aquick.org (Adam Fields) Date: Mon, 15 Jun 2009 19:32:14 -0400 Subject: Verio taking twitter down during Iran Election Riots? In-Reply-To: <2e6d38e0906151622l70d7f44ftf82dc7a2058e2e42@mail.gmail.com> References: <4A36BEF7.9090806@gmail.com> <2e6d38e0906151622l70d7f44ftf82dc7a2058e2e42@mail.gmail.com> Message-ID: <20090615233214.GK9106@lola.aquick.org> On Mon, Jun 15, 2009 at 07:22:33PM -0400, Stephen Repetski wrote: > Yep, that's what it says. Things like "critical network upgrades" sometimes > don't wait for good timing - they make their own special event. Rescheduled: http://blog.twitter.com/2009/06/down-time-rescheduled.html -- - Adam ** Expert Technical Project and Business Management **** System Performance Analysis and Architecture ****** [ http://www.adamfields.com ] [ http://workstuff.tumblr.com ] ........... Technology Blog [ http://www.aquick.org/blog ] ............ Personal Blog [ http://www.adamfields.com/resume.html ].. Experience [ http://www.flickr.com/photos/fields ] ... Photos [ http://www.twitter.com/fields ].......... Twitter [ http://www.morningside-analytics.com ] .. Latest Venture [ http://www.confabb.com ] ................ Founder From jeremy at evilrouters.net Mon Jun 15 18:32:43 2009 From: jeremy at evilrouters.net (Jeremy L. Gaddis) Date: Mon, 15 Jun 2009 19:32:43 -0400 Subject: Verio taking twitter down during Iran Election Riots? In-Reply-To: <2e6d38e0906151622l70d7f44ftf82dc7a2058e2e42@mail.gmail.com> References: <4A36BEF7.9090806@gmail.com> <2e6d38e0906151622l70d7f44ftf82dc7a2058e2e42@mail.gmail.com> Message-ID: <8623d07f0906151632s73f08d24v6515981c0cdcd245@mail.gmail.com> On Mon, Jun 15, 2009 at 7:22 PM, Stephen Repetski wrote: > Yep, that's what it says. Things like "critical network upgrades" sometimes > don't wait for good timing - they make their own special event. Rescheduled: http://blog.twitter.com/2009/06/down-time-rescheduled.html -- Jeremy L. Gaddis http://evilrouters.net/ From emf1123 at gmail.com Mon Jun 15 18:39:28 2009 From: emf1123 at gmail.com (Erik Fichtner) Date: Mon, 15 Jun 2009 19:39:28 -0400 Subject: Verio taking twitter down during Iran Election Riots? In-Reply-To: <2e6d38e0906151622l70d7f44ftf82dc7a2058e2e42@mail.gmail.com> References: <4A36BEF7.9090806@gmail.com> <2e6d38e0906151622l70d7f44ftf82dc7a2058e2e42@mail.gmail.com> Message-ID: <4A36DBB0.1000201@gmail.com> Stephen Repetski wrote: > Yep, that's what it says. Things like "critical network upgrades" sometimes > don't wait for good timing - they make their own special event. And yet, all upgrades can be postponed with the right... motivation. http://blog.twitter.com/2009/06/down-time-rescheduled.html Nice save, NTT. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 186 bytes Desc: OpenPGP digital signature URL: From srepetsk at tjhsst.edu Mon Jun 15 20:12:33 2009 From: srepetsk at tjhsst.edu (Stephen Repetski) Date: Mon, 15 Jun 2009 21:12:33 -0400 Subject: Verio taking twitter down during Iran Election Riots? In-Reply-To: <4A36DBB0.1000201@gmail.com> References: <4A36BEF7.9090806@gmail.com> <2e6d38e0906151622l70d7f44ftf82dc7a2058e2e42@mail.gmail.com> <4A36DBB0.1000201@gmail.com> Message-ID: <2e6d38e0906151812x44325a4ek6119a3002a84a921@mail.gmail.com> On Mon, Jun 15, 2009 at 7:39 PM, Erik Fichtner wrote: > Stephen Repetski wrote: > > Yep, that's what it says. Things like "critical network upgrades" > sometimes > > don't wait for good timing - they make their own special event. > > And yet, all upgrades can be postponed with the right... motivation. > > http://blog.twitter.com/2009/06/down-time-rescheduled.html > > Nice save, NTT. But not without a nice plug from Twitter, though it's a nice gesture. Which brings me back to the question why Twitter isn't multi-homed, or what the nature of the "network upgrade" is that it brings down their entire network. From simon at darkmere.gen.nz Mon Jun 15 21:14:02 2009 From: simon at darkmere.gen.nz (NANOG Mail List Committee) Date: Tue, 16 Jun 2009 14:14:02 +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://www.claws-and-paws.com/spam-l * 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 stef-list at memberwebs.com Mon Jun 15 23:15:03 2009 From: stef-list at memberwebs.com (Stef Walter) Date: Tue, 16 Jun 2009 04:15:03 +0000 (UTC) Subject: Cogent input References: <4A310AC5.5050701@justinshore.com> Message-ID: <20090616041502.9BE96170875@mx.npubs.com> Justin Shore wrote: > I'm in search of some information about Cogent, it's past, present and > future. I've heard bits and pieces about Cogent's past over the years > but by no means have I actively been keeping up. We've used cogent for the past year, 100 over GigE. - Clueful and responsive tech support. - Active monitoring of faults. - Helpful people at billing (even when trying to give them less money). We were affected by one depeering during the last year (Telia). We're multihomed and that mitigated the problem. Obviously, you'd never want to go exclusively with them. Cheers, Stef From jbates at brightok.net Tue Jun 16 09:48:07 2009 From: jbates at brightok.net (Jack Bates) Date: Tue, 16 Jun 2009 09:48:07 -0500 Subject: Verio taking twitter down during Iran Election Riots? In-Reply-To: <4A36DBB0.1000201@gmail.com> References: <4A36BEF7.9090806@gmail.com> <2e6d38e0906151622l70d7f44ftf82dc7a2058e2e42@mail.gmail.com> <4A36DBB0.1000201@gmail.com> Message-ID: <4A37B0A7.6020709@brightok.net> Erik Fichtner wrote: > > And yet, all upgrades can be postponed with the right... motivation. > Hmmm, you do know that motivation may have strictly been, "Your maintenance corresponds with a major event, can you put it off for a day?" The maintenance in question has obviously been marked critical by NTTA with what appears to be short notification and limiting the delay to a minimum. They may have been unaware of the event and its importance to their customers. I'm more curious about what maintenance they are actually performing. I know they run mixed Cisco/Juniper, and all their Junipers should be able to handle in service upgrades. Of course, even switching hits of an upgrade warrants setting a maintenance window and notification due to Murphy. Jack From rekoil at semihuman.com Tue Jun 16 10:03:19 2009 From: rekoil at semihuman.com (Chris Woodfield) Date: Tue, 16 Jun 2009 11:03:19 -0400 Subject: Verio taking twitter down during Iran Election Riots? In-Reply-To: <4A37B0A7.6020709@brightok.net> References: <4A36BEF7.9090806@gmail.com> <2e6d38e0906151622l70d7f44ftf82dc7a2058e2e42@mail.gmail.com> <4A36DBB0.1000201@gmail.com> <4A37B0A7.6020709@brightok.net> Message-ID: <96FC85C6-0FD5-4312-BEED-B9581CF521A2@semihuman.com> What's interesting is that the !NANOG part of the universe presumes the maintenance was to be performed by Twitter, not by their carrier (i.e. server, not network, upgrades). Given the fact that the WhaleFail has become a commonly-recognizable sight, I can see this make people a bit, um, nervous. The real impact of the maintenance would have most likely been minimal short of a Murphy strike. That said, kudos to NTT for backing off in the face of some pretty momentous current events, and hope the delay doesn't cause too many ripple-effect problems for them. -C On Jun 16, 2009, at 10:48 AM, Jack Bates wrote: > Erik Fichtner wrote: >> And yet, all upgrades can be postponed with the right... motivation. > > > Hmmm, you do know that motivation may have strictly been, "Your > maintenance corresponds with a major event, can you put it off for a > day?" > > The maintenance in question has obviously been marked critical by > NTTA with what appears to be short notification and limiting the > delay to a minimum. They may have been unaware of the event and its > importance to their customers. > > I'm more curious about what maintenance they are actually > performing. I know they run mixed Cisco/Juniper, and all their > Junipers should be able to handle in service upgrades. Of course, > even switching hits of an upgrade warrants setting a maintenance > window and notification due to Murphy. > > Jack > From tme at americafree.tv Tue Jun 16 10:55:10 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 16 Jun 2009 11:55:10 -0400 Subject: Verio taking twitter down during Iran Election Riots? In-Reply-To: <4A37B0A7.6020709@brightok.net> References: <4A36BEF7.9090806@gmail.com> <2e6d38e0906151622l70d7f44ftf82dc7a2058e2e42@mail.gmail.com> <4A36DBB0.1000201@gmail.com> <4A37B0A7.6020709@brightok.net> Message-ID: On Jun 16, 2009, at 10:48 AM, Jack Bates wrote: > Erik Fichtner wrote: >> And yet, all upgrades can be postponed with the right... motivation. > > > Hmmm, you do know that motivation may have strictly been, "Your > maintenance corresponds with a major event, can you put it off for a > day?" > > The maintenance in question has obviously been marked critical by > NTTA with what appears to be short notification and limiting the > delay to a minimum. They may have been unaware of the event and its > importance to their customers. > > I'm more curious about what maintenance they are actually > performing. I know they run mixed Cisco/Juniper, and all their > Junipers should be able to handle in service upgrades. Of course, > even switching hits of an upgrade warrants setting a maintenance > window and notification due to Murphy. > Tehran is currently UTC/GMT +4:30 hours. The current downtime is for 2:00 PM Pacific, or 1:30 AM in Tehran. That seems to be unfortunately still "prime time" for the nightly demonstrations, one of which is going on now. If the idea is to avoid such collisions, 5:00 PM or even 6:00 PM PDT would probably be better. Regards Marshall > Jack > > From orion at pirk.com Tue Jun 16 11:05:59 2009 From: orion at pirk.com (Steve Pirk) Date: Tue, 16 Jun 2009 09:05:59 -0700 (PDT) Subject: Verio taking twitter down during Iran Election Riots? In-Reply-To: References: <4A36BEF7.9090806@gmail.com> <2e6d38e0906151622l70d7f44ftf82dc7a2058e2e42@mail.gmail.com> <4A36DBB0.1000201@gmail.com> <4A37B0A7.6020709@brightok.net> Message-ID: On Tue, 16 Jun 2009, Marshall Eubanks wrote: > Tehran is currently UTC/GMT +4:30 hours. The current downtime is for 2:00 PM > Pacific, or 1:30 AM in > Tehran. That seems to be unfortunately still "prime time" for the nightly > demonstrations, one of which is > going on now. > > If the idea is to avoid such collisions, 5:00 PM or even 6:00 PM PDT would > probably be better. Speaking of critical timings and "demonstrations", anyone in the community have contacts/ideas for "last mile" connections in Teheran? The protesters are getting blocked right and left trying to get 'net access. There are some, ehrm, "boxen" out on the 'net to allow them to get around the active blocking going on, but most of the citizen reporters are unable to even get a conection to allow proxying out. Some serious censoring of 'net access going on. Just curious - replies off list if desired. Thanks in advance. -- steve From quinn at activehost.com Tue Jun 16 13:00:51 2009 From: quinn at activehost.com (Quinn Mahoney) Date: Tue, 16 Jun 2009 14:00:51 -0400 Subject: spamhaus drop list In-Reply-To: References: <8685783A8C22C640AD1361E78659B7D76975FF@ahex02.activehost.local> Message-ID: <8685783A8C22C640AD1361E78659B7D769760D@ahex02.activehost.local> Is there a competing droplist, that can be compared against Spamhaus's droplist? That seems like an extraordinary claim, so I'm not satisfied with the evidence provided. Is this not the best droplist? -----Original Message----- From: Dean Anderson [mailto:dean at av8.com] Sent: Monday, June 15, 2009 6:10 PM To: Quinn Mahoney Cc: nanog at nanog.org Subject: Re: spamhaus drop list I suggest you avoid spamhaus, MAPS, and SORBS. They are really spammers in disguise, using blacklists to harm their competition while presumably letting their own spam through. We know they have used trust of the anti-spam community to list-wash spam-trap addresses. See http://www.iadl.org/whitehat/whitehat-story.html add the IADL pages on Paul Vixie and MAPS. You might also look at http://www.av8.net/IETF-watch/People/JohnLevine/index.html Levine, long head of the Anti-spam Research Group, was also unmasked as a spammer. Fred Baker is on the ISC Board of Trustees, and is a Vixie supportor. --Dean On Mon, 15 Jun 2009, Quinn Mahoney wrote: > I'm looking to implement the Spamhaus drop list. > http://www.spamhaus.org/drop/index.lasso > > > > On their FAQ they have a script that looks like it grabs the lists text > file and connects to a given router, and tells you what has changed in > the list, and what your router is null routing. I'm not sure if it then > removes the null routes if a list entry has been removed. I haven't > found much documentation on the net regarding this. In the future it > looks like you will be able to peer with them and null route traffic > from a private AS, which will be routes from the drop list. Right now > though, it looks like you'd have to update an ACL manually for any > changes to the list. Or use this script which null routes the traffic > (I guess it's not a big deal getting the syn packets, as long as the > mail won't send because of the null route). I am not sure if this > script updates the null routes automatically, or how to use it, I can't > find to much documentation. > > > > Any documentation on this script or another script available. What are > your suggestions? > > > > thanks > > > > > > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From sthaug at nethelp.no Tue Jun 16 13:08:47 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 16 Jun 2009 20:08:47 +0200 (CEST) Subject: spamhaus drop list In-Reply-To: <8685783A8C22C640AD1361E78659B7D769760D@ahex02.activehost.local> References: <8685783A8C22C640AD1361E78659B7D76975FF@ahex02.activehost.local> <8685783A8C22C640AD1361E78659B7D769760D@ahex02.activehost.local> Message-ID: <20090616.200847.74747812.sthaug@nethelp.no> > Is there a competing droplist, that can be compared against Spamhaus's > droplist? That seems like an extraordinary claim, so I'm not satisfied > with the evidence provided. Is this not the best droplist? Obviously the Spamhaus DROP list should be evaluated - you should not use such lists unreservedly. That said, the Spamhaus DROP list contains entries that *are* verifiably bad, e.g. the well published Cernel 85.255.112.0/20 prefix. Regarding the extraordinary claim - consider the possibility that Nanog has its share of kooks. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From peter at peter-dambier.de Tue Jun 16 14:15:37 2009 From: peter at peter-dambier.de (Peter Dambier) Date: Tue, 16 Jun 2009 21:15:37 +0200 Subject: spamhaus drop list In-Reply-To: <8685783A8C22C640AD1361E78659B7D769760D@ahex02.activehost.local> References: <8685783A8C22C640AD1361E78659B7D76975FF@ahex02.activehost.local> <8685783A8C22C640AD1361E78659B7D769760D@ahex02.activehost.local> Message-ID: <4A37EF59.2050708@peter-dambier.de> Also I don't like those lists at all http://www.heise.de/ix/nixspam/dnsbl_en/ Heise do print the very important magazines IX, CT and others in germany. They depend on their emails coming through. Kind regards Peter Quinn Mahoney wrote: > Is there a competing droplist, that can be compared against Spamhaus's > droplist? That seems like an extraordinary claim, so I'm not satisfied > with the evidence provided. Is this not the best droplist? > > -----Original Message----- > From: Dean Anderson [mailto:dean at av8.com] > Sent: Monday, June 15, 2009 6:10 PM > To: Quinn Mahoney > Cc: nanog at nanog.org > Subject: Re: spamhaus drop list > > I suggest you avoid spamhaus, MAPS, and SORBS. They are really spammers > in disguise, using blacklists to harm their competition while presumably > letting their own spam through. We know they have used trust of the > anti-spam community to list-wash spam-trap addresses. > > See http://www.iadl.org/whitehat/whitehat-story.html add the IADL pages > on Paul Vixie and MAPS. > > You might also look at > http://www.av8.net/IETF-watch/People/JohnLevine/index.html > Levine, long head of the Anti-spam Research Group, was also unmasked as > a spammer. > > Fred Baker is on the ISC Board of Trustees, and is a > Vixie supportor. > > > --Dean > > On Mon, 15 Jun 2009, Quinn Mahoney wrote: > >> I'm looking to implement the Spamhaus drop list. >> http://www.spamhaus.org/drop/index.lasso >> >> >> >> On their FAQ they have a script that looks like it grabs the lists > text >> file and connects to a given router, and tells you what has changed in >> the list, and what your router is null routing. I'm not sure if it > then >> removes the null routes if a list entry has been removed. I haven't >> found much documentation on the net regarding this. In the future it >> looks like you will be able to peer with them and null route traffic >> from a private AS, which will be routes from the drop list. Right now >> though, it looks like you'd have to update an ACL manually for any >> changes to the list. Or use this script which null routes the traffic >> (I guess it's not a big deal getting the syn packets, as long as the >> mail won't send because of the null route). I am not sure if this >> script updates the null routes automatically, or how to use it, I > can't >> find to much documentation. >> >> >> >> Any documentation on this script or another script available. What > are >> your suggestions? >> >> >> >> 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 patrick at ianai.net Tue Jun 16 14:43:01 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 16 Jun 2009 15:43:01 -0400 Subject: spamhaus drop list In-Reply-To: <8685783A8C22C640AD1361E78659B7D769760D@ahex02.activehost.local> References: <8685783A8C22C640AD1361E78659B7D76975FF@ahex02.activehost.local> <8685783A8C22C640AD1361E78659B7D769760D@ahex02.activehost.local> Message-ID: <6736025A-4C70-41F4-9E9B-BCFDBB4A5F81@ianai.net> On Jun 16, 2009, at 2:00 PM, Quinn Mahoney wrote: > Is there a competing droplist, that can be compared against Spamhaus's > droplist? That seems like an extraordinary claim, so I'm not > satisfied > with the evidence provided. Is this not the best droplist? Extraordinary claims require extraordinary proof. Mr. Anderson gives little proof at all, and not even close to extraordinary proof, IMHO. My personal experience is that Spamhaus is highly respectable organization. They are by no means perfect, but I trust their judgement to a high degree, FWIW. The Spamhaus DNSRBLs are, I believe, the most used on the Internet. This suggests the rest of the Internet has a different opinion than Mr. Anderson. I have not used MAPS, so I cannot comment on its utility. but I have never heard a single credible claim Mr. Vixie is a spammer, more or less a verifiable one. (Yes, that includes the claim below.) From my personal experience, Mr. Vixie is very much the opposite of a spammer. Mr. Vixie gave the Keynote speech at the NANOG conference yesterday, so I would submit the community at large disagrees with Mr. Anderson's assessment. SORBS is probably not as highly regarded as Spamhaus, but as with Vixie, not one credible claim has ever been made that Michelle is a spammer, including the below. Again, the opposite is reality, and probably to the same extent as Vixie. (I.e. Some people think they go too far in fighting spam, not in sending it.) Finally, John Levine is not a spammer either. I'm kinda tired of giving proof, so take my word for it, or not, as you please. Anyway, just some personal opinions from someone who has had personal interaction with the people involved and used two of the three products mentioned. Not sure this was operational, but I felt the need to step up and defend people after you forwarded the outrageous claims below to the list. (No one on the list saw Mr. Anderson's claims other than you, because you were personally CC'ed.) End of day, your network, your choice. I think you know mine. -- TTFN, patrick > -----Original Message----- > From: Dean Anderson [mailto:dean at av8.com] > Sent: Monday, June 15, 2009 6:10 PM > To: Quinn Mahoney > Cc: nanog at nanog.org > Subject: Re: spamhaus drop list > > I suggest you avoid spamhaus, MAPS, and SORBS. They are really > spammers > in disguise, using blacklists to harm their competition while > presumably > letting their own spam through. We know they have used trust of the > anti-spam community to list-wash spam-trap addresses. > > See http://www.iadl.org/whitehat/whitehat-story.html add the IADL > pages > on Paul Vixie and MAPS. > > You might also look at > http://www.av8.net/IETF-watch/People/JohnLevine/index.html > Levine, long head of the Anti-spam Research Group, was also unmasked > as > a spammer. > > Fred Baker is on the ISC Board of Trustees, and is a > Vixie supportor. > > > --Dean > > On Mon, 15 Jun 2009, Quinn Mahoney wrote: > >> I'm looking to implement the Spamhaus drop list. >> http://www.spamhaus.org/drop/index.lasso >> >> >> >> On their FAQ they have a script that looks like it grabs the lists > text >> file and connects to a given router, and tells you what has changed >> in >> the list, and what your router is null routing. I'm not sure if it > then >> removes the null routes if a list entry has been removed. I haven't >> found much documentation on the net regarding this. In the future it >> looks like you will be able to peer with them and null route traffic >> from a private AS, which will be routes from the drop list. Right >> now >> though, it looks like you'd have to update an ACL manually for any >> changes to the list. Or use this script which null routes the >> traffic >> (I guess it's not a big deal getting the syn packets, as long as the >> mail won't send because of the null route). I am not sure if this >> script updates the null routes automatically, or how to use it, I > can't >> find to much documentation. >> >> >> >> Any documentation on this script or another script available. What > are >> your suggestions? >> >> >> >> thanks >> >> >> >> >> >> >> > > -- > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 > > > > > > From peter at peter-dambier.de Tue Jun 16 15:43:58 2009 From: peter at peter-dambier.de (Peter Dambier) Date: Tue, 16 Jun 2009 22:43:58 +0200 Subject: spamhaus drop list In-Reply-To: <6736025A-4C70-41F4-9E9B-BCFDBB4A5F81@ianai.net> References: <8685783A8C22C640AD1361E78659B7D76975FF@ahex02.activehost.local> <8685783A8C22C640AD1361E78659B7D769760D@ahex02.activehost.local> <6736025A-4C70-41F4-9E9B-BCFDBB4A5F81@ianai.net> Message-ID: <4A38040E.60107@peter-dambier.de> http://wnagele.com/2007/06/19/spamhouseorg-vs-nicat/ Another problem with spamhaus, they want to earn money. The Pirates Party in germany is a nonprofit. Nevertheless our mailers use a fixed addresses and when you query spamhaus long enough from a fixed address you are put on a blacklist and fed wrong information. Time and again all mails bounced. Every new mail admin went through this cycle :) Kind regards Peter Patrick W. Gilmore wrote: > On Jun 16, 2009, at 2:00 PM, Quinn Mahoney wrote: > >> Is there a competing droplist, that can be compared against Spamhaus's >> droplist? That seems like an extraordinary claim, so I'm not satisfied >> with the evidence provided. Is this not the best droplist? > > Extraordinary claims require extraordinary proof. Mr. Anderson gives > little proof at all, and not even close to extraordinary proof, IMHO. > > My personal experience is that Spamhaus is highly respectable > organization. They are by no means perfect, but I trust their judgement > to a high degree, FWIW. The Spamhaus DNSRBLs are, I believe, the most > used on the Internet. This suggests the rest of the Internet has a > different opinion than Mr. Anderson. > > I have not used MAPS, so I cannot comment on its utility. but I have > never heard a single credible claim Mr. Vixie is a spammer, more or less > a verifiable one. (Yes, that includes the claim below.) From my > personal experience, Mr. Vixie is very much the opposite of a spammer. > Mr. Vixie gave the Keynote speech at the NANOG conference yesterday, so > I would submit the community at large disagrees with Mr. Anderson's > assessment. > > SORBS is probably not as highly regarded as Spamhaus, but as with Vixie, > not one credible claim has ever been made that Michelle is a spammer, > including the below. Again, the opposite is reality, and probably to > the same extent as Vixie. (I.e. Some people think they go too far in > fighting spam, not in sending it.) > > Finally, John Levine is not a spammer either. I'm kinda tired of giving > proof, so take my word for it, or not, as you please. > > > Anyway, just some personal opinions from someone who has had personal > interaction with the people involved and used two of the three products > mentioned. Not sure this was operational, but I felt the need to step > up and defend people after you forwarded the outrageous claims below to > the list. (No one on the list saw Mr. Anderson's claims other than you, > because you were personally CC'ed.) > > End of day, your network, your choice. I think you know mine. > -- 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 patrick at ianai.net Tue Jun 16 15:52:36 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 16 Jun 2009 16:52:36 -0400 Subject: spamhaus drop list In-Reply-To: <4A38040E.60107@peter-dambier.de> References: <8685783A8C22C640AD1361E78659B7D76975FF@ahex02.activehost.local> <8685783A8C22C640AD1361E78659B7D769760D@ahex02.activehost.local> <6736025A-4C70-41F4-9E9B-BCFDBB4A5F81@ianai.net> <4A38040E.60107@peter-dambier.de> Message-ID: <460408F4-41FA-4145-B53F-0490D1AC3588@ianai.net> On Jun 16, 2009, at 4:43 PM, Peter Dambier wrote: > http://wnagele.com/2007/06/19/spamhouseorg-vs-nicat/ > > Another problem with spamhaus, they want to earn money. > The Pirates Party in germany is a nonprofit. > Nevertheless our mailers use a fixed addresses and when > you query spamhaus long enough from a fixed address > you are put on a blacklist and fed wrong information. > Time and again all mails bounced. Every new mail admin > went through this cycle :) I know. Who would expect that when you use a resource, the people who own and pay for that resource might want to be compensated? The least they should do is make these rules clear and prominent on their website so you could know before you use the resource! Oh, wait, they do.... -- TTFN, patrick > Patrick W. Gilmore wrote: >> On Jun 16, 2009, at 2:00 PM, Quinn Mahoney wrote: >> >>> Is there a competing droplist, that can be compared against >>> Spamhaus's >>> droplist? That seems like an extraordinary claim, so I'm not >>> satisfied >>> with the evidence provided. Is this not the best droplist? >> >> Extraordinary claims require extraordinary proof. Mr. Anderson gives >> little proof at all, and not even close to extraordinary proof, IMHO. >> >> My personal experience is that Spamhaus is highly respectable >> organization. They are by no means perfect, but I trust their >> judgement >> to a high degree, FWIW. The Spamhaus DNSRBLs are, I believe, the >> most >> used on the Internet. This suggests the rest of the Internet has a >> different opinion than Mr. Anderson. >> >> I have not used MAPS, so I cannot comment on its utility. but I have >> never heard a single credible claim Mr. Vixie is a spammer, more or >> less >> a verifiable one. (Yes, that includes the claim below.) From my >> personal experience, Mr. Vixie is very much the opposite of a >> spammer. >> Mr. Vixie gave the Keynote speech at the NANOG conference >> yesterday, so >> I would submit the community at large disagrees with Mr. Anderson's >> assessment. >> >> SORBS is probably not as highly regarded as Spamhaus, but as with >> Vixie, >> not one credible claim has ever been made that Michelle is a spammer, >> including the below. Again, the opposite is reality, and probably to >> the same extent as Vixie. (I.e. Some people think they go too far in >> fighting spam, not in sending it.) >> >> Finally, John Levine is not a spammer either. I'm kinda tired of >> giving >> proof, so take my word for it, or not, as you please. >> >> >> Anyway, just some personal opinions from someone who has had personal >> interaction with the people involved and used two of the three >> products >> mentioned. Not sure this was operational, but I felt the need to >> step >> up and defend people after you forwarded the outrageous claims >> below to >> the list. (No one on the list saw Mr. Anderson's claims other than >> you, >> because you were personally CC'ed.) >> >> End of day, your network, your choice. I think you know mine. >> > > -- > 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 johnl at iecc.com Tue Jun 16 16:04:50 2009 From: johnl at iecc.com (John Levine) Date: 16 Jun 2009 21:04:50 -0000 Subject: spamhaus drop list In-Reply-To: <8685783A8C22C640AD1361E78659B7D769760D@ahex02.activehost.local> Message-ID: <20090616210450.10312.qmail@simone.iecc.com> > Is there a competing droplist, that can be compared against > Spamhaus's droplist? Not that I've ever seen. Nobody else has the breadth of data that Spamhaus does. I've been using it for ages and based on zero complaints, it's never blocked anything that any of my users wanted. R's, John From toddunder at gmail.com Tue Jun 16 16:39:29 2009 From: toddunder at gmail.com (Todd Underwood) Date: Tue, 16 Jun 2009 17:39:29 -0400 Subject: [NANOG-announce] change in roles on the program committee Message-ID: <65b1fd2e0906161439i7ade39bvd3468d88bed27fb5@mail.gmail.com> today, at our lunchtime meeting, the nanog program committee selected a new chair, david meyer of cisco and university of oregon, and a new vice-chair, tom daly of dynamic network services. please join me in cogratulating them in person if you're here at nanog. for the past two years, ren provo has served as vice-chair of the program committee, a role that was basically created specifically for her. she has been critical in the development of the program committee into the open, active, and even somewhat-organized group that it is today. i'm proud to have worked with her on this project for the past two years and am extremely grateful for everything she has done. ren and i decided to resign our positions prior to the october meeting to ensure a smooth transition. we will both continue to serve as members of the program committee through the end of our current terms in october. NANOG has been getting better and better for the last several years. we're announcing locations much earlier and we're continuing to develop and experiment with the content to make it more relevant and more interesting for attendees. credit for these efforts certainly go to members of the steering and mailing list committees and to merit staff, but they also go to the program committee. the nanog program committee is full of some of the smartest, best people that i've ever worked with. it's a pleasure to be associated with them. eight (8) of the slots on the program committee will be opening up this october. if you'd like to work with other interesting people to make the nanog conference better, please consider submitting your name to be considered for one of these slots. the steering committee will announce details, or you can come see almost any member of the PC for more information. again, congratulations to dave and tom. cheers, todd underwood, outgoing chair for the program committee spots opening up in october _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From steve at ibctech.ca Thu Jun 11 09:37:40 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 11 Jun 2009 10:37:40 -0400 Subject: Cogent input In-Reply-To: <200906111033.26208.kratzers@pa.net> References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> Message-ID: <4A3116B4.1090208@ibctech.ca> Stephen Kratzer wrote: > And, they have no plans to support IPv6. Ouch! I hope this is a non-starter for a lot of folks. Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From joelja at bogus.com Tue Jun 16 18:05:58 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 16 Jun 2009 16:05:58 -0700 Subject: Cogent input In-Reply-To: <4A3116B4.1090208@ibctech.ca> References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> <4A3116B4.1090208@ibctech.ca> Message-ID: <4A382556.7000605@bogus.com> Steve Bertrand wrote: > Stephen Kratzer wrote: > >> And, they have no plans to support IPv6. > > Ouch! > > I hope this is a non-starter for a lot of folks. read the rest of the thread... joel > Steve From joelja at bogus.com Tue Jun 16 18:05:58 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 16 Jun 2009 16:05:58 -0700 Subject: Cogent input In-Reply-To: <4A3116B4.1090208@ibctech.ca> References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> <4A3116B4.1090208@ibctech.ca> Message-ID: <4A382556.7000605@bogus.com> Steve Bertrand wrote: > Stephen Kratzer wrote: > >> And, they have no plans to support IPv6. > > Ouch! > > I hope this is a non-starter for a lot of folks. read the rest of the thread... joel > Steve From sethm at rollernet.us Tue Jun 16 18:13:47 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 16 Jun 2009 16:13:47 -0700 Subject: Cogent input In-Reply-To: <4A325547.70406@justinshore.com> References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> <4A311B06.9010606@linpro.no> <4A318739.4090209@justinshore.com> <4A318C80.6010000@telcodata.us> <4A325547.70406@justinshore.com> Message-ID: <4A38272B.6030506@rollernet.us> Justin Shore wrote: > Paul Timmins wrote: >> GlobalCrossing told me today I can order native IPv6 anywhere on their >> network. Don't know if they count as Tier 1 on your list, though. VZB >> has given me tunnels for a while, hopefully they'll get their pMTU >> issue fixed so we can do more interesting things with it. > > I'd love to have GLBX but I'm positive that they aren't available here. > We'd have to pay for transport to a much larger market to go get them. > That may be more feasible when the state network gets built but that's > a few years off. Until then I'll have to dream about GBLX... > For me their local POP is apparently at capacity, so I had to take them off the list since I couldn't afford the transport costs to California. I heard somewhere that it's MPLS internally in order to present dual-stack at your port, not dual-stack on every router, thus most of the path is invisible like a tunnel. ~Seth From smb at cs.columbia.edu Tue Jun 16 18:45:36 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Tue, 16 Jun 2009 19:45:36 -0400 Subject: Verio taking twitter down during Iran Election Riots? In-Reply-To: <4A37B0A7.6020709@brightok.net> References: <4A36BEF7.9090806@gmail.com> <2e6d38e0906151622l70d7f44ftf82dc7a2058e2e42@mail.gmail.com> <4A36DBB0.1000201@gmail.com> <4A37B0A7.6020709@brightok.net> Message-ID: <20090616194536.30867d41@cs.columbia.edu> On Tue, 16 Jun 2009 09:48:07 -0500 Jack Bates wrote: > Erik Fichtner wrote: > > > > And yet, all upgrades can be postponed with the right... motivation. > > > > > Hmmm, you do know that motivation may have strictly been, "Your > maintenance corresponds with a major event, can you put it off for a > day?" > According to http://feeds.arstechnica.com/~r/arstechnica/index/~3/k32Wx4r_vew/twitter-from-statedept-delay-upgrade-to-aid-iran-protests.ars the delay was requested by the U.S. State Department. --Steve Bellovin, http://www.cs.columbia.edu/~smb From bclark at spectraaccess.com Tue Jun 16 18:49:36 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Tue, 16 Jun 2009 19:49:36 -0400 Subject: spamhaus drop list In-Reply-To: <20090616210450.10312.qmail@simone.iecc.com> References: <20090616210450.10312.qmail@simone.iecc.com> Message-ID: <4A382F90.9040302@spectraaccess.com> John Levine wrote: > Not that I've ever seen. Nobody else has the breadth of data that > Spamhaus does. > > I've been using it for ages and based on zero complaints, it's never > blocked anything that any of my users wanted. > > R's, > John > > I have to agree with this...I'm somewhat surprised to see some of the comments here. I've found there service to work well and have never received customer complaints. From jeremy at evilrouters.net Tue Jun 16 18:55:43 2009 From: jeremy at evilrouters.net (Jeremy L. Gaddis) Date: Tue, 16 Jun 2009 19:55:43 -0400 Subject: Verio taking twitter down during Iran Election Riots? In-Reply-To: References: <4A36BEF7.9090806@gmail.com> <2e6d38e0906151622l70d7f44ftf82dc7a2058e2e42@mail.gmail.com> <4A36DBB0.1000201@gmail.com> <4A37B0A7.6020709@brightok.net> Message-ID: <8623d07f0906161655h3a717547y55703a59747a9733@mail.gmail.com> On Tue, Jun 16, 2009 at 12:05 PM, Steve Pirk wrote: > There are some, ehrm, "boxen" out on the 'net to allow them to get around > the active blocking going on, but most of the citizen reporters are unable > to even get a conection to allow proxying out. Some serious censoring of > 'net access going on. Doesn't DCI still control things there? If so, they could cut Iran off from the world very easily if they wanted. -- Jeremy L. Gaddis http://evilrouters.net/ From alex at blastro.com Tue Jun 16 19:28:28 2009 From: alex at blastro.com (Alex Thurlow) Date: Tue, 16 Jun 2009 19:28:28 -0500 Subject: Verio taking twitter down during Iran Election Riots? In-Reply-To: <96FC85C6-0FD5-4312-BEED-B9581CF521A2@semihuman.com> References: <4A36BEF7.9090806@gmail.com> <2e6d38e0906151622l70d7f44ftf82dc7a2058e2e42@mail.gmail.com> <4A36DBB0.1000201@gmail.com> <4A37B0A7.6020709@brightok.net> <96FC85C6-0FD5-4312-BEED-B9581CF521A2@semihuman.com> Message-ID: <4A3838AC.1040004@blastro.com> An update here. Reuters is reporting that the US State Department is behind this maintenance being pushed back. http://www.reuters.com/article/internetNews/idUSWBT01137420090616?feedType=RSS&feedName=internetNews&rpc=22&sp=true I find it very interesting that the US government is seeing the use Twitter is getting from a political perspective. Alex Thurlow Blastro Networks http://www.blastro.com http://www.roxwel.com http://www.yallwire.com On 6/16/2009 10:03 AM, Chris Woodfield wrote: > What's interesting is that the !NANOG part of the universe presumes > the maintenance was to be performed by Twitter, not by their carrier > (i.e. server, not network, upgrades). Given the fact that the > WhaleFail has become a commonly-recognizable sight, I can see this > make people a bit, um, nervous. The real impact of the maintenance > would have most likely been minimal short of a Murphy strike. > > That said, kudos to NTT for backing off in the face of some pretty > momentous current events, and hope the delay doesn't cause too many > ripple-effect problems for them. > > -C > > On Jun 16, 2009, at 10:48 AM, Jack Bates wrote: > >> Erik Fichtner wrote: >>> And yet, all upgrades can be postponed with the right... motivation. >> >> >> Hmmm, you do know that motivation may have strictly been, "Your >> maintenance corresponds with a major event, can you put it off for a >> day?" >> >> The maintenance in question has obviously been marked critical by >> NTTA with what appears to be short notification and limiting the >> delay to a minimum. They may have been unaware of the event and its >> importance to their customers. >> >> I'm more curious about what maintenance they are actually performing. >> I know they run mixed Cisco/Juniper, and all their Junipers should be >> able to handle in service upgrades. Of course, even switching hits of >> an upgrade warrants setting a maintenance window and notification due >> to Murphy. >> >> Jack >> > > From mksmith at adhost.com Wed Jun 17 00:17:08 2009 From: mksmith at adhost.com (Michael K. Smith) Date: Tue, 16 Jun 2009 22:17:08 -0700 Subject: Cogent input In-Reply-To: <4A3116B4.1090208@ibctech.ca> Message-ID: On 6/11/09 7:37 AM, "Steve Bertrand" wrote: > Stephen Kratzer wrote: > >> And, they have no plans to support IPv6. > > Ouch! > > I hope this is a non-starter for a lot of folks. > > Steve To quote Randy, I encourage all my competitors to do this. Mike From kris.foster at gmail.com Wed Jun 17 01:14:31 2009 From: kris.foster at gmail.com (kris foster) Date: Wed, 17 Jun 2009 02:14:31 -0400 Subject: Cogent input In-Reply-To: References: Message-ID: On Jun 17, 2009, at 1:17 AM, Michael K. Smith wrote: > On 6/11/09 7:37 AM, "Steve Bertrand" wrote: > >> Stephen Kratzer wrote: >> >>> And, they have no plans to support IPv6. >> >> Ouch! >> >> I hope this is a non-starter for a lot of folks. >> >> Steve > > To quote Randy, I encourage all my competitors to do this. Simply untrue, at the Peering BOF yesterday Cogent said they are rolling this out. -- kris From ras at e-gerbil.net Wed Jun 17 01:24:07 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 17 Jun 2009 01:24:07 -0500 Subject: Cogent input In-Reply-To: References: Message-ID: <20090617062407.GB51443@gerbil.cluepon.net> On Wed, Jun 17, 2009 at 02:14:31AM -0400, kris foster wrote: > Simply untrue, at the Peering BOF yesterday Cogent said they are > rolling this out. They saw my "How to deploy IPv6 in 30 minutes or less" tutorial on Sunday and apparently it actually worked. Unfortunately I neglected to mention the important "acquire connectivity to the global routing table" step (I assumed it was implied, but I guess it wasn't), but if you're down with their 5 v6 routes as "transit" you should be golden. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From m.klaver at grafix.nl Wed Jun 17 03:44:50 2009 From: m.klaver at grafix.nl (Michiel Klaver) Date: Wed, 17 Jun 2009 10:44:50 +0200 Subject: spamhaus drop list Message-ID: <4A38AD02.5010506@grafix.nl> Well, there is always the bogon-list from Team Cymru http://www.cymru.com/Documents/bogon-bn-agg.txt And the bogon-list from BGPmon http://bgpmon.net/showbogons.php?inet=4&global=yes&private=yes Both containing prefixes that should not be announced on the internet, but often used by spammers trying to deliver their content. -------- Original message -------- Subject: RE: spamhaus drop list Date: Tue, 16 Jun 2009 14:00:51 -0400 From: Quinn Mahoney To: > Is there a competing droplist, that can be compared against > Spamhaus's droplist? That seems like an extraordinary claim, > so I'm not satisfied with the evidence provided. Is this not > the best droplist? -- With kind regards, Michiel Klaver BA.ict GrafiX Internet B.V. Stationsplein 20 2907 MJ Capelle aan den IJssel The Netherlands Web: http://grafix.nl/ Tel: +31-(0)10-2640210 Fax: +31-(0)10-2640211 Providing high-end professional internet services at our privately owned net-neutral in-house Data Center Facilities in Capelle aan den IJssel and Alphen aan den Rijn. Connected at TeleCityRedbus2 (Amsterdam) and Spaanse Kubus (Rotterdam). From raymond at prolocation.net Wed Jun 17 03:48:38 2009 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Wed, 17 Jun 2009 10:48:38 +0200 (CEST) Subject: spamhaus drop list In-Reply-To: <4A38AD02.5010506@grafix.nl> References: <4A38AD02.5010506@grafix.nl> Message-ID: Hi! > Both containing prefixes that should not be announced on the internet, > but often used by spammers trying to deliver their content. When did you experience this last time, this is not what we see on various antispam projects. So if you have new information, please share, we didnt see bogons used a lot at least the last 12 months. Drop list is a completely different thing, and effective, but also effective to loos legitimate mails, the blocks inside there are too wide. I would not recommend people putting that inside iptables or something ;) Bogon filtering is something that should be considered common practice. So your borders or upstreams should take care of that ;) Bye, Raymond. From dan.carley at gmail.com Wed Jun 17 05:00:05 2009 From: dan.carley at gmail.com (Dan Carley) Date: Wed, 17 Jun 2009 11:00:05 +0100 Subject: Cogent input In-Reply-To: <4A311B06.9010606@linpro.no> References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> <4A311B06.9010606@linpro.no> Message-ID: 2009/6/11 Tore Anderson > > And, they have no plans to support IPv6. > > I have been promised, in writing, that they will provide us with native > IPv6 transit before the end of the year. > > I'm based in Europe, though. Perhaps they're more flexible and > customer-friendly here than in the US? > We too have been informed Q3/Q4 09, in Europe and NA. Regards, From davet1 at gmail.com Wed Jun 17 07:05:59 2009 From: davet1 at gmail.com (David Temkin) Date: Wed, 17 Jun 2009 08:05:59 -0400 Subject: Cogent input In-Reply-To: <20090617062407.GB51443@gerbil.cluepon.net> References: <20090617062407.GB51443@gerbil.cluepon.net> Message-ID: <148641da0906170505i77b7f26s7d1b5c09129774e7@mail.gmail.com> On Wed, Jun 17, 2009 at 2:24 AM, Richard A Steenbergen wrote: > On Wed, Jun 17, 2009 at 02:14:31AM -0400, kris foster wrote: >> Simply untrue, at the Peering BOF yesterday Cogent said they are >> rolling this out. > > They saw my "How to deploy IPv6 in 30 minutes or less" tutorial on > Sunday and apparently it actually worked. Unfortunately I neglected to > mention the important "acquire connectivity to the global routing table" > step (I assumed it was implied, but I guess it wasn't), but if you're > down with their 5 v6 routes as "transit" you should be golden. :) > > -- > Richard A Steenbergen ? ? ? http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > > Nary a route... dtemkin at jnrt-edge01.sv1> show route table inet6.0 aspath-regex ".* 174 .*" inet6.0: 1914 destinations, 5528 routes (1914 active, 0 holddown, 0 hidden) dtemkin at jnrt-edge01.sv1> -Dave From ops.lists at gmail.com Wed Jun 17 07:44:46 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 17 Jun 2009 18:14:46 +0530 Subject: spamhaus drop list In-Reply-To: <4A38AD02.5010506@grafix.nl> References: <4A38AD02.5010506@grafix.nl> Message-ID: Traffic from bogon IP space is more likely than anything else to be the result of misconfiguration rather than a spammer abusing it. The cymru bogons list and the spamhaus drop list target two entirely distinct issues and they shouldnt be confused together. On Wed, Jun 17, 2009 at 2:14 PM, Michiel Klaver wrote: > Well, there is always the bogon-list from Team Cymru > > http://www.cymru.com/Documents/bogon-bn-agg.txt > > And the bogon-list from BGPmon > > http://bgpmon.net/showbogons.php?inet=4&global=yes&private=yes > > Both containing prefixes that should not be announced on the internet, > but often used by spammers trying to deliver their content. > From steve at ibctech.ca Wed Jun 17 08:28:30 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 17 Jun 2009 09:28:30 -0400 Subject: Cogent input In-Reply-To: <4A382556.7000605@bogus.com> References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> <4A3116B4.1090208@ibctech.ca> <4A382556.7000605@bogus.com> Message-ID: <4A38EF7E.2080501@ibctech.ca> Joel Jaeggli wrote: > > Steve Bertrand wrote: >> Stephen Kratzer wrote: >> >>> And, they have no plans to support IPv6. >> Ouch! >> >> I hope this is a non-starter for a lot of folks. > > read the rest of the thread... ...unfortunately, my message was sent out on the 11th, but just received yesterday by the list. I had both nanog at nanog.org and nanog at merit.edu Cc'd, so I don't know which one failed. I have problems sending to the NANOG list from my IPv6 server, so I'll have to find out which destination list address is breaking for me... Received: from unknown (HELO ?IPv6:2607:f118::5?) (steve at ibctech.ca@2607:f118::5) by 2607:f118::b6 with ESMTPA; 11 Jun 2009 14:39:10 -0000 Received: from v6.ibctech.ca ([2607:f118::b6] helo=ibctech.ca) by s0.nanog.org with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1MGhgj-0000qP-Cd for nanog at nanog.org; Tue, 16 Jun 2009 23:03:33 +0000 Well, I'm glad I had nothing better to do today other than figure out what is wrong with that particular email server ;) Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From martin at theicelandguy.com Wed Jun 17 09:25:05 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Wed, 17 Jun 2009 10:25:05 -0400 Subject: Verio taking twitter down during Iran Election Riots? In-Reply-To: <8623d07f0906161655h3a717547y55703a59747a9733@mail.gmail.com> References: <4A36BEF7.9090806@gmail.com> <2e6d38e0906151622l70d7f44ftf82dc7a2058e2e42@mail.gmail.com> <4A36DBB0.1000201@gmail.com> <4A37B0A7.6020709@brightok.net> <8623d07f0906161655h3a717547y55703a59747a9733@mail.gmail.com> Message-ID: On Tue, Jun 16, 2009 at 7:55 PM, Jeremy L. Gaddis wrote: > On Tue, Jun 16, 2009 at 12:05 PM, Steve Pirk wrote: > > There are some, ehrm, "boxen" out on the 'net to allow them to get around > > the active blocking going on, but most of the citizen reporters are > unable > > to even get a conection to allow proxying out. Some serious censoring of > > 'net access going on. > > Doesn't DCI still control things there? If so, they could cut Iran > off from the world very easily if they wanted. > Iran breaks their communications infrastructure into pseudo-zones. You can easily pinpoint a few choke points and surgically remove them from the Internet. This is the case for many countries. Sometimes the infrastructure is so hierarchically designed (likely for surveillance purposes) that you could literally watch their bgp advertisements and potentially draw conclusions about things "other than" Internet activity. Best Regards, -M< -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From David_Hiers at adp.com Wed Jun 17 09:38:02 2009 From: David_Hiers at adp.com (Hiers, David) Date: Wed, 17 Jun 2009 09:38:02 -0500 Subject: Verio taking twitter down during Iran Election Riots? In-Reply-To: <20090616194536.30867d41@cs.columbia.edu> References: <4A36BEF7.9090806@gmail.com> <2e6d38e0906151622l70d7f44ftf82dc7a2058e2e42@mail.gmail.com> <4A36DBB0.1000201@gmail.com> <4A37B0A7.6020709@brightok.net> <20090616194536.30867d41@cs.columbia.edu> Message-ID: <81CDFC77FB2DC54DB875D4F8FFC36CE00A474C7ED1@DSMAIL2HE.ds.ad.adp.com> This is a useful reminder that nanog creates a large part of the battlefield on which state and non-state players constantly prosecute their Information Warfare agendas. What will you do when you get a call from Khamenei, and then one from Obama? Armor up, boys and girls. David Hiers CCIE (R/S, V), CISSP -----Original Message----- From: Steven M. Bellovin [mailto:smb at cs.columbia.edu] Sent: Tuesday, June 16, 2009 4:46 PM To: Jack Bates Cc: Erik Fichtner; nanog at nanog.org Subject: Re: Verio taking twitter down during Iran Election Riots? On Tue, 16 Jun 2009 09:48:07 -0500 Jack Bates wrote: > Erik Fichtner wrote: > > > > And yet, all upgrades can be postponed with the right... motivation. > > > > > Hmmm, you do know that motivation may have strictly been, "Your > maintenance corresponds with a major event, can you put it off for a > day?" > According to http://feeds.arstechnica.com/~r/arstechnica/index/~3/k32Wx4r_vew/twitter-from-statedept-delay-upgrade-to-aid-iran-protests.ars the delay was requested by the U.S. State Department. --Steve Bellovin, http://www.cs.columbia.edu/~smb 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 BBlackford at nwresd.k12.or.us Wed Jun 17 10:27:30 2009 From: BBlackford at nwresd.k12.or.us (Bill Blackford) Date: Wed, 17 Jun 2009 08:27:30 -0700 Subject: Hotmail Postmaster Message-ID: <6069A203FD01884885C037F81DD7508016CE309003@wsc-mail-01.intra.nwresd.k12.or.us> Can someone from Hotmail contact me off list? Sorry for the SPAM posting, we've tried other methods. Thanks -b -- Bill Blackford Senior Network Engineer Technology Systems Group Northwest Regional ESD my /home away from home From jmamodio at gmail.com Wed Jun 17 11:16:29 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 17 Jun 2009 11:16:29 -0500 Subject: Verio taking twitter down during Iran Election Riots? In-Reply-To: <81CDFC77FB2DC54DB875D4F8FFC36CE00A474C7ED1@DSMAIL2HE.ds.ad.adp.com> References: <4A36BEF7.9090806@gmail.com> <2e6d38e0906151622l70d7f44ftf82dc7a2058e2e42@mail.gmail.com> <4A36DBB0.1000201@gmail.com> <4A37B0A7.6020709@brightok.net> <20090616194536.30867d41@cs.columbia.edu> <81CDFC77FB2DC54DB875D4F8FFC36CE00A474C7ED1@DSMAIL2HE.ds.ad.adp.com> Message-ID: <202705b0906170916q14045fd6j5309d59c6d2c7ee@mail.gmail.com> > What will you do when you get a call from Khamenei, and then one from Obama? hungup and keep the packets flowing ? From jdfalk-lists at cybernothing.org Wed Jun 17 13:19:23 2009 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Wed, 17 Jun 2009 12:19:23 -0600 Subject: spamhaus drop list In-Reply-To: <6736025A-4C70-41F4-9E9B-BCFDBB4A5F81@ianai.net> References: <8685783A8C22C640AD1361E78659B7D76975FF@ahex02.activehost.local> <8685783A8C22C640AD1361E78659B7D769760D@ahex02.activehost.local> <6736025A-4C70-41F4-9E9B-BCFDBB4A5F81@ianai.net> Message-ID: <4A3933AB.7090902@cybernothing.org> Patrick W. Gilmore wrote: > I have not used MAPS, so I cannot comment on its utility. but I have > never heard a single credible claim Mr. Vixie is a spammer, more or less > a verifiable one. (Yes, that includes the claim below.) From my personal > experience, Mr. Vixie is very much the opposite of a spammer. Mr. Vixie > gave the Keynote speech at the NANOG conference yesterday, so I would > submit the community at large disagrees with Mr. Anderson's assessment. The former MAPS offerings have been owned by Trend Microsystems since 2005, and I'm fairly certain that Mr. Vixie hasn't been involved in that project since before Trend took over. There's more information at http://www.mail-abuse.com/. (Full disclosure: I worked for the Mail Abuse Prevention System from 2000-2001.) -- J.D. Falk Return Path Inc http://www.returnpath.net/ From blackwolf99999 at gmail.com Wed Jun 17 16:32:44 2009 From: blackwolf99999 at gmail.com (Brian Shope) Date: Wed, 17 Jun 2009 14:32:44 -0700 Subject: Unicast Flooding Message-ID: <295271b90906171432h431f9867td53ded86f2a787f@mail.gmail.com> Recently while running a packet capture I came across some unicast flooding that was happening on my network. One of our core switches didn't have the mac-address for a server, and was flooding all packets destined to that server. It wasn't learning the mac-address because the server was responding to packets out on a different network card on a different switch. The flooding I was seeing wasn't enough to cause any network issues, it was only a few megs, but it was something that I wanted to fix. I've ran into this issue before, and solved it by statically entering the mac-address into the cam tables. I want to avoid this problem in the future, and I'm looking at two different things. The first is preventing it in the first place. Along those lines, I've seen some recommendations on-line about changing the arp and cam timeouts to be the same. However, there seems to be a disagreement on which is better, making the arp timeouts match the cam table timeouts, or vice versa. Also, when talking about this, everyone seems to be only considering routers, but what about the timers on a firewall? I'm worried that I might cause other issues by changing these timers. The second thing I'm considering is monitoring. I'd like to setup something to monitor for any excessive unicast flooding in the future. I understand that a little unicast flooding is normal, as the switch has to do a little bit of flooding to find out where people are. While looking for a way to monitor this, I came across the 'mac-address-table unicast-flood' command on Cisco switches. This looked perfect for what I needed, but apparently it is currently not an option on 6500 switches with Sup720s. Since there doesn't appear to be an option on Cisco that monitors specificaly for unicast floods, I thought that maybe I could setup a server with a network card in promiscuous mode and then keep stats of all packets received that aren't destined for the server and that also aren't legitimate broadcasts or multicasts. The only problem with that is that I don't want to have to completely custom build my own solution. I was hoping that someone may have already created something like this, or that maybe there is a good reporting tool for wireshark or something that could generate the report that I want. Anyone have any suggestions on either prevention/monitoring? Thanks!! -Brian From mhuff at ox.com Wed Jun 17 16:58:23 2009 From: mhuff at ox.com (Matthew Huff) Date: Wed, 17 Jun 2009 17:58:23 -0400 Subject: Unicast Flooding In-Reply-To: <295271b90906171432h431f9867td53ded86f2a787f@mail.gmail.com> References: <295271b90906171432h431f9867td53ded86f2a787f@mail.gmail.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F9C381C142F5@PUR-EXCH07.ox.com> Unicast flooding is a common occurrence in large datacenters especially with asymmetrical paths caused by different first hop routers (via HSRP, VRRP, etc). We ran into this some time ago. Most arp sensitive systems such as clusters, HSRP, content switches etc are smart enough to send out gratuitous arps which eliminates the worries of increasing the timeouts. We haven't had any issues since we made the changes. After debugging the problem we added "mac-address-table aging-time 14400" to our data center switches. That syncs the mac aging time to the same timeout value as the ARP timeout ---- 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: Brian Shope [mailto:blackwolf99999 at gmail.com] > Sent: Wednesday, June 17, 2009 5:33 PM > To: nanog at nanog.org > Subject: Unicast Flooding > > Recently while running a packet capture I came across some unicast > flooding > that was happening on my network. One of our core switches didn't have > the > mac-address for a server, and was flooding all packets destined to that > server. It wasn't learning the mac-address because the server was > responding to packets out on a different network card on a different > switch. The flooding I was seeing wasn't enough to cause any network > issues, it was only a few megs, but it was something that I wanted to > fix. > > I've ran into this issue before, and solved it by statically entering > the > mac-address into the cam tables. > > I want to avoid this problem in the future, and I'm looking at two > different > things. > > The first is preventing it in the first place. Along those lines, I've > seen > some recommendations on-line about changing the arp and cam timeouts to > be > the same. However, there seems to be a disagreement on which is > better, > making the arp timeouts match the cam table timeouts, or vice versa. > Also, > when talking about this, everyone seems to be only considering routers, > but > what about the timers on a firewall? I'm worried that I might cause > other > issues by changing these timers. > > The second thing I'm considering is monitoring. I'd like to setup > something > to monitor for any excessive unicast flooding in the future. I > understand > that a little unicast flooding is normal, as the switch has to do a > little > bit of flooding to find out where people are. While looking for a way > to > monitor this, I came across the 'mac-address-table unicast-flood' > command on > Cisco switches. This looked perfect for what I needed, but apparently > it is > currently not an option on 6500 switches with Sup720s. Since there > doesn't > appear to be an option on Cisco that monitors specificaly for unicast > floods, I thought that maybe I could setup a server with a network card > in > promiscuous mode and then keep stats of all packets received that > aren't > destined for the server and that also aren't legitimate broadcasts or > multicasts. The only problem with that is that I don't want to have to > completely custom build my own solution. I was hoping that someone may > have > already created something like this, or that maybe there is a good > reporting > tool for wireshark or something that could generate the report that I > want. > > Anyone have any suggestions on either prevention/monitoring? > > Thanks!! > > -Brian From sking at kingrst.com Wed Jun 17 17:08:41 2009 From: sking at kingrst.com (Steven King) Date: Wed, 17 Jun 2009 18:08:41 -0400 Subject: Unicast Flooding In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9C381C142F5@PUR-EXCH07.ox.com> References: <295271b90906171432h431f9867td53ded86f2a787f@mail.gmail.com> <483E6B0272B0284BA86D7596C40D29F9C381C142F5@PUR-EXCH07.ox.com> Message-ID: <4A396969.5010601@kingrst.com> I have had the same issue in the past. The best fix for this has been to set the Layer2/3 aging timers to be the same. Matthew Huff wrote: > Unicast flooding is a common occurrence in large datacenters especially with asymmetrical paths caused by different first hop routers (via HSRP, VRRP, etc). We ran into this some time ago. Most arp sensitive systems such as clusters, HSRP, content switches etc are smart enough to send out gratuitous arps which eliminates the worries of increasing the timeouts. We haven't had any issues since we made the changes. > > After debugging the problem we added "mac-address-table aging-time 14400" to our data center switches. That syncs the mac aging time to the same timeout value as the ARP timeout > > ---- > 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: Brian Shope [mailto:blackwolf99999 at gmail.com] >> Sent: Wednesday, June 17, 2009 5:33 PM >> To: nanog at nanog.org >> Subject: Unicast Flooding >> >> Recently while running a packet capture I came across some unicast >> flooding >> that was happening on my network. One of our core switches didn't have >> the >> mac-address for a server, and was flooding all packets destined to that >> server. It wasn't learning the mac-address because the server was >> responding to packets out on a different network card on a different >> switch. The flooding I was seeing wasn't enough to cause any network >> issues, it was only a few megs, but it was something that I wanted to >> fix. >> >> I've ran into this issue before, and solved it by statically entering >> the >> mac-address into the cam tables. >> >> I want to avoid this problem in the future, and I'm looking at two >> different >> things. >> >> The first is preventing it in the first place. Along those lines, I've >> seen >> some recommendations on-line about changing the arp and cam timeouts to >> be >> the same. However, there seems to be a disagreement on which is >> better, >> making the arp timeouts match the cam table timeouts, or vice versa. >> Also, >> when talking about this, everyone seems to be only considering routers, >> but >> what about the timers on a firewall? I'm worried that I might cause >> other >> issues by changing these timers. >> >> The second thing I'm considering is monitoring. I'd like to setup >> something >> to monitor for any excessive unicast flooding in the future. I >> understand >> that a little unicast flooding is normal, as the switch has to do a >> little >> bit of flooding to find out where people are. While looking for a way >> to >> monitor this, I came across the 'mac-address-table unicast-flood' >> command on >> Cisco switches. This looked perfect for what I needed, but apparently >> it is >> currently not an option on 6500 switches with Sup720s. Since there >> doesn't >> appear to be an option on Cisco that monitors specificaly for unicast >> floods, I thought that maybe I could setup a server with a network card >> in >> promiscuous mode and then keep stats of all packets received that >> aren't >> destined for the server and that also aren't legitimate broadcasts or >> multicasts. The only problem with that is that I don't want to have to >> completely custom build my own solution. I was hoping that someone may >> have >> already created something like this, or that maybe there is a good >> reporting >> tool for wireshark or something that could generate the report that I >> want. >> >> Anyone have any suggestions on either prevention/monitoring? >> >> Thanks!! >> >> -Brian >> > > -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From deepak at ai.net Wed Jun 17 17:09:27 2009 From: deepak at ai.net (Deepak Jain) Date: Wed, 17 Jun 2009 18:09:27 -0400 Subject: Unicast Flooding In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9C381C142F5@PUR-EXCH07.ox.com> References: <295271b90906171432h431f9867td53ded86f2a787f@mail.gmail.com> <483E6B0272B0284BA86D7596C40D29F9C381C142F5@PUR-EXCH07.ox.com> Message-ID: > After debugging the problem we added "mac-address-table aging-time > 14400" to our data center switches. That syncs the mac aging time to > the same timeout value as the ARP timeout This helps, seconded. Deepak Jain AiNET From andrius at andrius.org Wed Jun 17 17:34:14 2009 From: andrius at andrius.org (AKK) Date: Wed, 17 Jun 2009 23:34:14 +0100 Subject: Cogent input - no peering with Global Crossing in Europe [Re: NANOG Digest, Vol 17, Issue 46] In-Reply-To: References: Message-ID: <4A396F66.9070405@andrius.org> My main concern for European Cogent users is - no European peering with global crossing - traffic goes via NY JFK. It has been like this for at least a year and staff been giving assurances this should be sorted soon. Probably there are more bad peerings - please share. 6: so-7-0-0c0.rt1.mil.it.geant2.net (62.40.112.174) asymm 5 14.446ms 7: so-7-1-0.rt1.fra.de.geant2.net (62.40.112.61) asymm 6 27.120ms 8: TenGigabitEthernet7-3.ar1.FRA4.gblx.net (207.138.144.45) 246.852ms 9: po3-20G.ar7.NYC1.gblx.net (67.16.134.74) asymm 12 122.810ms 10: te2-1.ccr01.jfk07.atlas.cogentco.com (154.54.11.61) asymm 12 123.003ms 11: te4-1.ccr01.jfk02.atlas.cogentco.com (154.54.1.221) asymm 13 118.334ms 12: te4-3.ccr01.lon01.atlas.cogentco.com (130.117.1.106) asymm 14 198.997ms 13: te2-7.ccr02.ams03.atlas.cogentco.com (130.117.1.169) asymm 14 204.575ms 14: te2-3.ccr01.dus01.atlas.cogentco.com (130.117.3.90) asymm 15 213.653ms 15: te7-1.ccr01.muc01.atlas.cogentco.com (130.117.49.154) asymm 14 225.144ms 16: te3-1.ccr01.vie01.atlas.cogentco.com (130.117.49.30) asymm 22 254.543ms 17: te3-8.ccr01.bts01.atlas.cogentco.com (130.117.49.25) asymm 21 248.505ms 18: te1-1.ccr01.tsr01.atlas.cogentco.com (130.117.48.58) asymm 20 243.334ms 19: te1-3.ccr01.tsr01.atlas.cogentco.com (130.117.0.18) asymm 20 249.374ms 20: 149.6.112.2 (149.6.112.2) asymm 19 273.730ms 21: 149.6.112.2 (149.6.112.2) asymm 19 268.122ms 22: down-int.caucasus.net (62.168.172.205) asymm 21 268.647ms 23: down-int.caucasus.net (62.168.172.205) asymm 21 274.430ms 24: sw.caucasus.net (62.168.168.60) asymm 21 277.811ms nanog-request at nanog.org wrote: > Send NANOG mailing list submissions to > nanog at nanog.org > From dholmes at mwdh2o.com Wed Jun 17 18:26:21 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Wed, 17 Jun 2009 16:26:21 -0700 Subject: Unicast Flooding In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9C381C142F5@PUR-EXCH07.ox.com> References: <295271b90906171432h431f9867td53ded86f2a787f@mail.gmail.com> <483E6B0272B0284BA86D7596C40D29F9C381C142F5@PUR-EXCH07.ox.com> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E09237370@usmsxt104.mwd.h2o> In a layer 3 switch I consider unicast flooding due to an L2 cam table timeout a design defect. To test vendors' L3 switches for this defect we have used a traffic generator to send 50-100 Mbps of pings to a device that does not reply to the pings, where the L3 switch was routing from one vlan to another to forward the pings. In defective devices the L2 cam table entry expires, causing the 50-100 Mbps unicast stream to be flooded out all ports in the destination vlan. In my view the L3 and L2 forwarding state machines must be synchronized such that the L3 forwarding continues as long as there are packets entering the L3 switch on one vlan, and exiting the switch on another vlan via routing. It seems that gratuitous arps are a workaround which serves to reset the cam entry timeout interval, but not an elegant solution. -----Original Message----- From: Matthew Huff [mailto:mhuff at ox.com] Sent: Wednesday, June 17, 2009 2:58 PM To: 'Brian Shope'; 'nanog at nanog.org' Subject: RE: Unicast Flooding Unicast flooding is a common occurrence in large datacenters especially with asymmetrical paths caused by different first hop routers (via HSRP, VRRP, etc). We ran into this some time ago. Most arp sensitive systems such as clusters, HSRP, content switches etc are smart enough to send out gratuitous arps which eliminates the worries of increasing the timeouts. We haven't had any issues since we made the changes. After debugging the problem we added "mac-address-table aging-time 14400" to our data center switches. That syncs the mac aging time to the same timeout value as the ARP timeout ---- 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: Brian Shope [mailto:blackwolf99999 at gmail.com] > Sent: Wednesday, June 17, 2009 5:33 PM > To: nanog at nanog.org > Subject: Unicast Flooding > > Recently while running a packet capture I came across some unicast > flooding > that was happening on my network. One of our core switches didn't have > the > mac-address for a server, and was flooding all packets destined to that > server. It wasn't learning the mac-address because the server was > responding to packets out on a different network card on a different > switch. The flooding I was seeing wasn't enough to cause any network > issues, it was only a few megs, but it was something that I wanted to > fix. > > I've ran into this issue before, and solved it by statically entering > the > mac-address into the cam tables. > > I want to avoid this problem in the future, and I'm looking at two > different > things. > > The first is preventing it in the first place. Along those lines, I've > seen > some recommendations on-line about changing the arp and cam timeouts to > be > the same. However, there seems to be a disagreement on which is > better, > making the arp timeouts match the cam table timeouts, or vice versa. > Also, > when talking about this, everyone seems to be only considering routers, > but > what about the timers on a firewall? I'm worried that I might cause > other > issues by changing these timers. > > The second thing I'm considering is monitoring. I'd like to setup > something > to monitor for any excessive unicast flooding in the future. I > understand > that a little unicast flooding is normal, as the switch has to do a > little > bit of flooding to find out where people are. While looking for a way > to > monitor this, I came across the 'mac-address-table unicast-flood' > command on > Cisco switches. This looked perfect for what I needed, but apparently > it is > currently not an option on 6500 switches with Sup720s. Since there > doesn't > appear to be an option on Cisco that monitors specificaly for unicast > floods, I thought that maybe I could setup a server with a network card > in > promiscuous mode and then keep stats of all packets received that > aren't > destined for the server and that also aren't legitimate broadcasts or > multicasts. The only problem with that is that I don't want to have to > completely custom build my own solution. I was hoping that someone may > have > already created something like this, or that maybe there is a good > reporting > tool for wireshark or something that could generate the report that I > want. > > Anyone have any suggestions on either prevention/monitoring? > > Thanks!! > > -Brian From charles at thewybles.com Wed Jun 17 18:32:16 2009 From: charles at thewybles.com (Charles Wyble) Date: Wed, 17 Jun 2009 16:32:16 -0700 Subject: Cogent input - no peering with Global Crossing in Europe [Re: NANOG Digest, Vol 17, Issue 46] In-Reply-To: <4A396F66.9070405@andrius.org> References: <4A396F66.9070405@andrius.org> Message-ID: <4A397D00.2090109@thewybles.com> Ouch... latency must be awful. I suppose this is based on Cogents reputation but who knows. The whole peering aspect of the networking business is often a mystery. AKK wrote: > > My main concern for European Cogent users is - no European peering with > global crossing - traffic goes via NY JFK. It has been like this for at > least a year and staff been giving assurances this should be sorted > soon. Probably there are more bad peerings - please share. > > > 6: so-7-0-0c0.rt1.mil.it.geant2.net (62.40.112.174) asymm 5 14.446ms > 7: so-7-1-0.rt1.fra.de.geant2.net (62.40.112.61) asymm 6 27.120ms > 8: TenGigabitEthernet7-3.ar1.FRA4.gblx.net (207.138.144.45) 246.852ms > 9: po3-20G.ar7.NYC1.gblx.net (67.16.134.74) asymm 12 122.810ms > 10: te2-1.ccr01.jfk07.atlas.cogentco.com (154.54.11.61) asymm 12 > 123.003ms > 11: te4-1.ccr01.jfk02.atlas.cogentco.com (154.54.1.221) asymm 13 > 118.334ms > 12: te4-3.ccr01.lon01.atlas.cogentco.com (130.117.1.106) asymm 14 > 198.997ms > 13: te2-7.ccr02.ams03.atlas.cogentco.com (130.117.1.169) asymm 14 > 204.575ms > 14: te2-3.ccr01.dus01.atlas.cogentco.com (130.117.3.90) asymm 15 > 213.653ms > 15: te7-1.ccr01.muc01.atlas.cogentco.com (130.117.49.154) asymm 14 > 225.144ms > 16: te3-1.ccr01.vie01.atlas.cogentco.com (130.117.49.30) asymm 22 > 254.543ms > 17: te3-8.ccr01.bts01.atlas.cogentco.com (130.117.49.25) asymm 21 > 248.505ms > 18: te1-1.ccr01.tsr01.atlas.cogentco.com (130.117.48.58) asymm 20 > 243.334ms > 19: te1-3.ccr01.tsr01.atlas.cogentco.com (130.117.0.18) asymm 20 > 249.374ms > 20: 149.6.112.2 (149.6.112.2) asymm 19 > 273.730ms > 21: 149.6.112.2 (149.6.112.2) asymm 19 > 268.122ms > 22: down-int.caucasus.net (62.168.172.205) asymm 21 > 268.647ms > 23: down-int.caucasus.net (62.168.172.205) asymm 21 > 274.430ms > 24: sw.caucasus.net (62.168.168.60) asymm 21 > 277.811ms > > > > > nanog-request at nanog.org wrote: >> Send NANOG mailing list submissions to >> nanog at nanog.org >> > > From sean at donelan.com Wed Jun 17 18:59:13 2009 From: sean at donelan.com (Sean Donelan) Date: Wed, 17 Jun 2009 19:59:13 -0400 (EDT) Subject: spamhaus drop list In-Reply-To: References: <4A38AD02.5010506@grafix.nl> Message-ID: <200906171953440.32BF5B92.21620@clifden.donelan.com> On Wed, 17 Jun 2009, Suresh Ramasubramanian wrote: > The cymru bogons list and the spamhaus drop list target two entirely > distinct issues and they shouldnt be confused together. Correct. And whatever list you use, for whatever purpose, at the time you start using it also set up a process to update it or age old entries. Don't wait until later. Those lists will be there long after you forget about it, and maybe even longer than you; and it will save you or your successor a lot of troubleshooting headaches. From ops.lists at gmail.com Wed Jun 17 19:39:58 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 18 Jun 2009 06:09:58 +0530 Subject: spamhaus drop list In-Reply-To: <200906171953440.32BF5B92.21620@clifden.donelan.com> References: <4A38AD02.5010506@grafix.nl> <200906171953440.32BF5B92.21620@clifden.donelan.com> Message-ID: On Thu, Jun 18, 2009 at 5:29 AM, Sean Donelan wrote: > On Wed, 17 Jun 2009, Suresh Ramasubramanian wrote: >> >> The cymru bogons list and the spamhaus drop list target two entirely >> distinct issues and they shouldnt be confused together. > > Correct. ?And whatever list you use, for whatever purpose, at the time you > start using it also set up a process to update it or age old entries. Don't > wait until later. > > Those lists will be there long after you forget about it, and maybe even > longer than you; and it will save you or your successor a lot of > troubleshooting headaches. .. and to sanity check the fallout of fat fingers, bitrot or whatever (like where you set out to block a /24 but end up blocking a /2 instead) -- Suresh Ramasubramanian (ops.lists at gmail.com) From pstewart at nexicomgroup.net Wed Jun 17 19:41:23 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Wed, 17 Jun 2009 20:41:23 -0400 Subject: Hurricane Electric In-Reply-To: <20090616041502.9BE96170875@mx.npubs.com> References: <4A310AC5.5050701@justinshore.com> <20090616041502.9BE96170875@mx.npubs.com> Message-ID: Hi folks... Looking for some feedback on using Hurricane Electric as an upstream? Thanks, Paul ---------------------------------------------------------------------------- "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 mike at m5computersecurity.com Wed Jun 17 20:31:58 2009 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Wed, 17 Jun 2009 18:31:58 -0700 Subject: Telephones for Noisy Data Centers Message-ID: <1245288718.6350.516.camel@mike-desktop> All, I'd be OK if we were in a facility that was only average in terms of noise, but we are not. I need an exceptional phone for the data center. Something that doesn't transmit the horrible background noise to the other end, and something that is loud without being painful for the user of this phone. Cordless would be very fine, headset is excellent. Ordinary desk phone is OK... but the most important thing is that it works for clear communication. A loud ringer would great too... but if the best phone doesn't have one, I'll get an auxiliary ringer. Does anyone have a phone model that they find to be excellent in a louder than usual data center? 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 nanog at daork.net Wed Jun 17 20:38:21 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 18 Jun 2009 13:38:21 +1200 Subject: Telephones for Noisy Data Centers In-Reply-To: <1245288718.6350.516.camel@mike-desktop> References: <1245288718.6350.516.camel@mike-desktop> Message-ID: On 18/06/2009, at 1:31 PM, Michael J McCafferty wrote: > All, > I'd be OK if we were in a facility that was only average in terms of > noise, but we are not. I need an exceptional phone for the data > center. > Something that doesn't transmit the horrible background noise to the > other end, and something that is loud without being painful for the > user > of this phone. Cordless would be very fine, headset is excellent. > Ordinary desk phone is OK... but the most important thing is that it > works for clear communication. A loud ringer would great too... but if > the best phone doesn't have one, I'll get an auxiliary ringer. > > Does anyone have a phone model that they find to be excellent in a > louder than usual data center? Not 100% what you asked for, but the noise cancelling Jawbone bluetooth earpieces are great. -- Nathan Ward From ml at kenweb.org Wed Jun 17 20:39:46 2009 From: ml at kenweb.org (ML) Date: Wed, 17 Jun 2009 21:39:46 -0400 Subject: IGP/BGP design question Message-ID: <4A399AE2.40109@kenweb.org> We have three main cities wherein eyeballs live. Currently we have San Jose and San Francisco traffic egressing in SF, and Los Angeles egressing in LA. There is one private 2x1gig long haul linking SJC to LA and a 1x 10gig linking SJC to SF. i.e SF <-10gig-> SJC <-2gig-> LA Each area is a separate OSPF domain. Static routes define how to reach the RFC1918 space defined for each area. Currently SF and SJC exchange their public blocks in iBGP. There isn't an iBGP session between SF and SJC to LA. We would would like to place our public IP blocks into iBGP with LA and use the 2gig long haul as a backup path for critical traffic destined for the Internet.(Only certain prefixes originated from each egress point will be announced out the opposite egress point; Appropriately locally-pref down inside our common transit ASN) Using only one assigned ASN is this a good idea? Is our IGP setup foobared (I've been mulling around possible changing the IGP design)? I can think of a problem or two this IGP design might cause us but it's a huge change on our part if we do it. The egress points are not DFZs, so if either the 10gig or 2gig link go down the default route can be taken to reach the public blocks in either of the three regions. Thanks From sean-list at head-net.com Wed Jun 17 20:38:58 2009 From: sean-list at head-net.com (sean head) Date: Wed, 17 Jun 2009 18:38:58 -0700 Subject: Telephones for Noisy Data Centers In-Reply-To: References: <1245288718.6350.516.camel@mike-desktop> Message-ID: <4A399AB2.1040809@head-net.com> Nathan Ward wrote: > On 18/06/2009, at 1:31 PM, Michael J McCafferty wrote: > >> All, >> I'd be OK if we were in a facility that was only average in terms of >> noise, but we are not. I need an exceptional phone for the data center. >> Something that doesn't transmit the horrible background noise to the >> other end, and something that is loud without being painful for the user >> of this phone. Cordless would be very fine, headset is excellent. >> Ordinary desk phone is OK... but the most important thing is that it >> works for clear communication. A loud ringer would great too... but if >> the best phone doesn't have one, I'll get an auxiliary ringer. >> >> Does anyone have a phone model that they find to be excellent in a >> louder than usual data center? > > > Not 100% what you asked for, but the noise cancelling Jawbone > bluetooth earpieces are great. > > -- > Nathan Ward > > Cordless phone that does bluetooth + jawbone was the first thing that popped into my head as well. -Sean From owen at delong.com Wed Jun 17 20:38:18 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 17 Jun 2009 18:38:18 -0700 Subject: Telephones for Noisy Data Centers In-Reply-To: <1245288718.6350.516.camel@mike-desktop> References: <1245288718.6350.516.camel@mike-desktop> Message-ID: I have similar experience in various equinix datacenters. I finally resorted to using a blue-tooth capable phone and bringing in my Aviation ANR headset with blootooth capabilities. It's a pricey headset for just using in a datacenter, but, I love having it in the airplane and it also works well in the datacenter. It's called a Lightspeed Zulu ANR headset. http://www.lightspeedaviation.com/content.cfm/Products/Zulu Owen On Jun 17, 2009, at 6:31 PM, Michael J McCafferty wrote: > All, > I'd be OK if we were in a facility that was only average in terms of > noise, but we are not. I need an exceptional phone for the data > center. > Something that doesn't transmit the horrible background noise to the > other end, and something that is loud without being painful for the > user > of this phone. Cordless would be very fine, headset is excellent. > Ordinary desk phone is OK... but the most important thing is that it > works for clear communication. A loud ringer would great too... but if > the best phone doesn't have one, I'll get an auxiliary ringer. > > Does anyone have a phone model that they find to be excellent in a > louder than usual data center? > > 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 bicknell at ufp.org Wed Jun 17 20:47:32 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 17 Jun 2009 21:47:32 -0400 Subject: Unicast Flooding In-Reply-To: <295271b90906171432h431f9867td53ded86f2a787f@mail.gmail.com> References: <295271b90906171432h431f9867td53ded86f2a787f@mail.gmail.com> Message-ID: <20090618014731.GA27165@ussenterprise.ufp.org> In a message written on Wed, Jun 17, 2009 at 02:32:44PM -0700, Brian Shope wrote: > Anyone have any suggestions on either prevention/monitoring? If you control the servers, writing a small program to emit a packet every 300 seconds or so out every interface should be nearly trivial, and will insure the switch knows where all the mac addresses are dynamically. I think I would find that vastly preferable to static configuration. -- 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 scott at doc.net.au Wed Jun 17 20:56:18 2009 From: scott at doc.net.au (Scott Howard) Date: Wed, 17 Jun 2009 18:56:18 -0700 Subject: Telephones for Noisy Data Centers In-Reply-To: References: <1245288718.6350.516.camel@mike-desktop> Message-ID: On Wed, Jun 17, 2009 at 6:38 PM, Nathan Ward wrote: > > Not 100% what you asked for, but the noise cancelling Jawbone bluetooth > earpieces are great. As much as I love my Jawbone (first gen model) I've never found it loud enough to work well in most datacenters. The person on the other end of the phone can hear you clearly due to it's excellent noise cancellation, but even at top volume on the both the phone and the Jawbone it's normally difficult to hear them. (And that's presuming you can actually work out how to use it's volume control to turn it up) It may just be mine, or the first gen models - not sure. Scott. From mike at m5computersecurity.com Wed Jun 17 20:59:12 2009 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Wed, 17 Jun 2009 18:59:12 -0700 Subject: Telephones for Noisy Data Centers In-Reply-To: <4A399AB2.1040809@head-net.com> References: <1245288718.6350.516.camel@mike-desktop> <4A399AB2.1040809@head-net.com> Message-ID: <1245290352.6350.527.camel@mike-desktop> On Wed, 2009-06-17 at 18:38 -0700, sean head wrote: > Nathan Ward wrote: > > On 18/06/2009, at 1:31 PM, Michael J McCafferty wrote: > > > >> All, > >> I'd be OK if we were in a facility that was only average in terms of > >> noise, but we are not. I need an exceptional phone for the data center. > >> Something that doesn't transmit the horrible background noise to the > >> other end, and something that is loud without being painful for the user > >> of this phone. Cordless would be very fine, headset is excellent. > >> Ordinary desk phone is OK... but the most important thing is that it > >> works for clear communication. A loud ringer would great too... but if > >> the best phone doesn't have one, I'll get an auxiliary ringer. > >> > >> Does anyone have a phone model that they find to be excellent in a > >> louder than usual data center? > > > > > > Not 100% what you asked for, but the noise cancelling Jawbone > > bluetooth earpieces are great. > > > > -- > > Nathan Ward > > > > > Cordless phone that does bluetooth + jawbone was the first thing that > popped into my head as well. > > -Sean > Hmm... I actually have one of those... but when my car came with built-in Bluetooth speaker phone, I haven't used it since. I'll dig it up and I'll try it out in the data center for the near-term. I'd rather a real headset that doesn't feel like it's falling out of my ear and something that other people can use too. I have had a couple pretty good suggestions off-list so far that are over the ear solutions. Keep `em coming... 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 aj at jonesy.com.au Wed Jun 17 21:11:47 2009 From: aj at jonesy.com.au (Andrew Jones) Date: Thu, 18 Jun 2009 12:11:47 +1000 Subject: Telephones for Noisy Data Centers In-Reply-To: <1245290352.6350.527.camel@mike-desktop> References: <1245288718.6350.516.camel@mike-desktop> <4A399AB2.1040809@head-net.com> <1245290352.6350.527.camel@mike-desktop> Message-ID: <4A39A263.7060407@jonesy.com.au> Michael J McCafferty wrote: > On Wed, 2009-06-17 at 18:38 -0700, sean head wrote: > >> Nathan Ward wrote: >> >>> On 18/06/2009, at 1:31 PM, Michael J McCafferty wrote: >>> >>> >>>> All, >>>> I'd be OK if we were in a facility that was only average in terms of >>>> noise, but we are not. I need an exceptional phone for the data center. >>>> Something that doesn't transmit the horrible background noise to the >>>> other end, and something that is loud without being painful for the user >>>> of this phone. Cordless would be very fine, headset is excellent. >>>> Ordinary desk phone is OK... but the most important thing is that it >>>> works for clear communication. A loud ringer would great too... but if >>>> the best phone doesn't have one, I'll get an auxiliary ringer. >>>> >>>> Does anyone have a phone model that they find to be excellent in a >>>> louder than usual data center? >>>> >>> Not 100% what you asked for, but the noise cancelling Jawbone >>> bluetooth earpieces are great. >>> >>> -- >>> Nathan Ward >>> >>> >>> >> Cordless phone that does bluetooth + jawbone was the first thing that >> popped into my head as well. >> >> -Sean >> >> > > Hmm... I actually have one of those... but when my car came with > built-in Bluetooth speaker phone, I haven't used it since. I'll dig it > up and I'll try it out in the data center for the near-term. I'd rather > a real headset that doesn't feel like it's falling out of my ear and > something that other people can use too. I have had a couple pretty good > suggestions off-list so far that are over the ear solutions. Keep `em > coming... > > Mike > I haven't actually used one of these but the acoustic background noise cancelling, rather than an electronic solution is intriguing... http://www.theboom.com/v/index.html From sking at kingrst.com Wed Jun 17 21:39:42 2009 From: sking at kingrst.com (Steven King) Date: Wed, 17 Jun 2009 22:39:42 -0400 Subject: Unicast Flooding In-Reply-To: <485ED9BA02629E4BBBA53AC892EDA50E09237370@usmsxt104.mwd.h2o> References: <295271b90906171432h431f9867td53ded86f2a787f@mail.gmail.com> <483E6B0272B0284BA86D7596C40D29F9C381C142F5@PUR-EXCH07.ox.com> <485ED9BA02629E4BBBA53AC892EDA50E09237370@usmsxt104.mwd.h2o> Message-ID: <4A39A8EE.7080603@kingrst.com> I wouldn't consider this a defect. Historically L2 and L3 devices have always been separate. When you get L3 switch those functions are just combined into one device. In Cisco devices that support CEF, the CEF table is used to make all forwarding decisions. But the CEF table is dependent the ARP and Routing tables on the L3 side. When it comes to forwarding the frame of the proper interface the CAM table comes into play. If that table is timing out quicker than the L3 tables, there will be times the CAM table is incomplete. This is mostly present in redundant gateway setups. In bound traffic is usually load balanced between the two redundant devices. The gateways learn about the servers/workstations by traffic leaving the VLAN, not coming into the VLAN. In the case of HSRP/VRRP the servers/workstations are only using one of the two redundant devices to send traffic out of the VLAN. In this case, one device will end up with incomplete information every 5 minutes (default MAC aging timer). This will cause traffic coming in to the VLAN (usually load balanced with EIGRP or OSPF) to be a unknown unicast flood out all ports on the standby device. Making the L2/3 timers the same corrects this. The reason this corrects this because, for CEF to make a forwarding decision, it must have the layer 3 engine make an ARP request if the ARP entry is not present. This causes an ARP broadcast. With the ARP reply being returned the active and standby device can both keep their CAM/ARP/CEF tables up to date. As I do not consider this a defect that these are not synchronized by default, I do agree it would be very beneficial and prevent a lot of confusion and hours of troubleshooting when unsuspecting engineers are trying to figure out why they have a ton of unknown unicast packets. Just my additional 0.02 Holmes,David A wrote: > In a layer 3 switch I consider unicast flooding due to an L2 cam table timeout a design defect. To test vendors' L3 switches for this defect we have used a traffic generator to send 50-100 Mbps of pings to a device that does not reply to the pings, where the L3 switch was routing from one vlan to another to forward the pings. In defective devices the L2 cam table entry expires, causing the 50-100 Mbps unicast stream to be flooded out all ports in the destination vlan. In my view the L3 and L2 forwarding state machines must be synchronized such that the L3 forwarding continues as long as there are packets entering the L3 switch on one vlan, and exiting the switch on another vlan via routing. It seems that gratuitous arps are a workaround which serves to reset the cam entry timeout interval, but not an elegant solution. > > -----Original Message----- > From: Matthew Huff [mailto:mhuff at ox.com] > Sent: Wednesday, June 17, 2009 2:58 PM > To: 'Brian Shope'; 'nanog at nanog.org' > Subject: RE: Unicast Flooding > > Unicast flooding is a common occurrence in large datacenters especially with asymmetrical paths caused by different first hop routers (via HSRP, VRRP, etc). We ran into this some time ago. Most arp sensitive systems such as clusters, HSRP, content switches etc are smart enough to send out gratuitous arps which eliminates the worries of increasing the timeouts. We haven't had any issues since we made the changes. > > After debugging the problem we added "mac-address-table aging-time 14400" to our data center switches. That syncs the mac aging time to the same timeout value as the ARP timeout > > ---- > 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: Brian Shope [mailto:blackwolf99999 at gmail.com] >> Sent: Wednesday, June 17, 2009 5:33 PM >> To: nanog at nanog.org >> Subject: Unicast Flooding >> >> Recently while running a packet capture I came across some unicast >> flooding >> that was happening on my network. One of our core switches didn't have >> the >> mac-address for a server, and was flooding all packets destined to that >> server. It wasn't learning the mac-address because the server was >> responding to packets out on a different network card on a different >> switch. The flooding I was seeing wasn't enough to cause any network >> issues, it was only a few megs, but it was something that I wanted to >> fix. >> >> I've ran into this issue before, and solved it by statically entering >> the >> mac-address into the cam tables. >> >> I want to avoid this problem in the future, and I'm looking at two >> different >> things. >> >> The first is preventing it in the first place. Along those lines, I've >> seen >> some recommendations on-line about changing the arp and cam timeouts to >> be >> the same. However, there seems to be a disagreement on which is >> better, >> making the arp timeouts match the cam table timeouts, or vice versa. >> Also, >> when talking about this, everyone seems to be only considering routers, >> but >> what about the timers on a firewall? I'm worried that I might cause >> other >> issues by changing these timers. >> >> The second thing I'm considering is monitoring. I'd like to setup >> something >> to monitor for any excessive unicast flooding in the future. I >> understand >> that a little unicast flooding is normal, as the switch has to do a >> little >> bit of flooding to find out where people are. While looking for a way >> to >> monitor this, I came across the 'mac-address-table unicast-flood' >> command on >> Cisco switches. This looked perfect for what I needed, but apparently >> it is >> currently not an option on 6500 switches with Sup720s. Since there >> doesn't >> appear to be an option on Cisco that monitors specificaly for unicast >> floods, I thought that maybe I could setup a server with a network card >> in >> promiscuous mode and then keep stats of all packets received that >> aren't >> destined for the server and that also aren't legitimate broadcasts or >> multicasts. The only problem with that is that I don't want to have to >> completely custom build my own solution. I was hoping that someone may >> have >> already created something like this, or that maybe there is a good >> reporting >> tool for wireshark or something that could generate the report that I >> want. >> >> Anyone have any suggestions on either prevention/monitoring? >> >> Thanks!! >> >> -Brian >> > > > -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From klann at wins.net Wed Jun 17 22:29:24 2009 From: klann at wins.net (David Klann) Date: Wed, 17 Jun 2009 22:29:24 -0500 Subject: Hurricane Electric In-Reply-To: References: <4A310AC5.5050701@justinshore.com> <20090616041502.9BE96170875@mx.npubs.com> Message-ID: <20090617222924.3aea29ca@ranch.cold.home> On Wed, 17 Jun 2009 19:41:23 -0500 Paul Stewart wrote: > Looking for some feedback on using Hurricane Electric as an upstream? > Hi Paul, My employer, Airstream Communications, uses HE for one of its three upstream Internet providers. We have an asymmetric 1GB inbound, and 512MB outbound connection with them. I'm not involved in the financial side of things, but from a technical perspective we've had an excellent relationship with them. Rock solid connection, and helpful technical support. One of our customers, and our DNS server were the subjects of a DDoS attack a few months ago. While our other upstream providers were trying to find the official process for helping us out, HE had already null routed the destination IP addresses for us. They were also very easy to work with in getting the service restored to those addresses. -David Klann Airstream Communications -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From fergdawgster at gmail.com Wed Jun 17 22:38:55 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 17 Jun 2009 20:38:55 -0700 Subject: Hurricane Electric In-Reply-To: <20090617222924.3aea29ca@ranch.cold.home> References: <4A310AC5.5050701@justinshore.com> <20090616041502.9BE96170875@mx.npubs.com> <20090617222924.3aea29ca@ranch.cold.home> Message-ID: <6cd462c00906172038g22f2cde3p117580f8098ff33@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Jun 17, 2009 at 8:29 PM, David Klann wrote: > On Wed, 17 Jun 2009 19:41:23 -0500 > Paul Stewart wrote: > >> Looking for some feedback on using Hurricane Electric as an upstream? >> > > Hi Paul, > > My employer, Airstream Communications, uses HE for one of its three > upstream Internet providers. We have an asymmetric 1GB inbound, and > 512MB outbound connection with them. I'm not involved in the financial > side of things, but from a technical perspective we've had an > excellent relationship with them. > > Rock solid connection, and helpful technical support. One of our > customers, and our DNS server were the subjects of a DDoS attack a few > months ago. While our other upstream providers were trying to find the > official process for helping us out, HE had already null routed the > destination IP addresses for us. They were also very easy to work with > in getting the service restored to those addresses. > > -David Klann > Airstream Communications > - From a security perspective, HE has always been cooperative working with the security community. Recall the McColo disconnect late last year? Hurricane Electric was very helpful. :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFKObbCq1pz9mNUZTMRArBqAJwNiBoxB/6/f53Ep8LBrXt1K7dzFgCdF9tJ zp36t6HIcpk6EzQpZpRMJjE= =WNnE -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From tico-nanog at raapid.net Wed Jun 17 22:59:50 2009 From: tico-nanog at raapid.net (Tico) Date: Wed, 17 Jun 2009 22:59:50 -0500 Subject: Hurricane Electric In-Reply-To: References: <4A310AC5.5050701@justinshore.com> <20090616041502.9BE96170875@mx.npubs.com> Message-ID: <4A39BBB6.2030203@raapid.net> Paul Stewart wrote: > Hi folks... > > Looking for some feedback on using Hurricane Electric as an upstream? > I'll second what others have already said. I've interacted with them a decent bit, and have always gotten prompt, knowledgeable, and helpful support and service when I've called/emailed. They've got simple, consistent, and reliable service, though they don't deviate much from what they've standardized on which is most likely the main reason they can offer the pricing that they do. So far, they hold the rare title of being the *only* transit provider that I've used that has never pissed me off. Plus they're IPv6 native across the board, if you care about that sort of thing. Cheers, Tico > Thanks, > > Paul > > > > > > ---------------------------------------------------------------------------- > > "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 jay at west.net Wed Jun 17 23:29:33 2009 From: jay at west.net (Jay Hennigan) Date: Wed, 17 Jun 2009 21:29:33 -0700 Subject: Telephones for Noisy Data Centers In-Reply-To: <1245288718.6350.516.camel@mike-desktop> References: <1245288718.6350.516.camel@mike-desktop> Message-ID: <4A39C2AD.9000503@west.net> Michael J McCafferty wrote: > All, > I'd be OK if we were in a facility that was only average in terms of > noise, but we are not. I need an exceptional phone for the data center. > Something that doesn't transmit the horrible background noise to the > other end, and something that is loud without being painful for the user > of this phone. Cordless would be very fine, headset is excellent. > Ordinary desk phone is OK... but the most important thing is that it > works for clear communication. A loud ringer would great too... but if > the best phone doesn't have one, I'll get an auxiliary ringer. > > Does anyone have a phone model that they find to be excellent in a > louder than usual data center? Old-school ITT Cortelco 2500 (desk) or 2554 (wall) set. 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). For exceptionally loud areas, an amplified handset such as Allen-Tel GBG6M-44 as well. The noise-canceling microphone is the key. It will help you be heard at the other end and kill the noise in the sidetone to you. Works wonders. The 2500 desk phone has a dual-gong mechanical ringer, loud and distinctive. 2554 wall model is single gong, still fairly loud. Google for suppliers of these items if you aren't near a Graybar. -- 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 nanogger at gmail.com Wed Jun 17 23:31:29 2009 From: nanogger at gmail.com (Freddie Sessler) Date: Wed, 17 Jun 2009 21:31:29 -0700 Subject: WISP NMS recommendations Message-ID: Hi Folks,I am looking for recommendations on an NMS system for use in managing a multivendor wireless infrastructure. Specifically we run mostly Motorola point to point, point to multipoint(Canopy platform) and mesh radios devices We have looked at the One Point Wireless Manager but this product in our evaluation doesn't seem to be ready for prime time and also has the limitation of only being able to manage Motorola. Ideally we would have something that could be used for configuration management in a multi vendor environment as well as recieve SNMP traps about RF issues such as latency and jitter. I am curious to what other shops are using out there. If this is a top better suited to another list, my apologies and any pointers to a different list would be greatly appreciated. Thanks JT From steve at ibctech.ca Wed Jun 17 23:34:11 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 18 Jun 2009 00:34:11 -0400 Subject: Hurricane Electric In-Reply-To: References: <4A310AC5.5050701@justinshore.com> <20090616041502.9BE96170875@mx.npubs.com> Message-ID: <4A39C3C3.7040601@ibctech.ca> Paul Stewart wrote: > Hi folks... > > Looking for some feedback on using Hurricane Electric as an upstream? Even though I only have tunnel relationships with them for v6 (ie free transit), I'd have to say that between: - their excellent automation tools - their time-to-response - their level of connectivity - their observance of this (and other) list(s) - their clueful staff ...would provide me with incentive to buy transit from them, if I were in a position to make such a decision. (Without hesitation). Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From shon at unwiredbb.com Thu Jun 18 00:02:57 2009 From: shon at unwiredbb.com (Shon Elliott) Date: Wed, 17 Jun 2009 22:02:57 -0700 Subject: WISP NMS recommendations In-Reply-To: References: Message-ID: <4A39CA81.3000500@unwiredbb.com> That's an excellent question, Freddie. I am also interested in what people are using for WISP Infrastructure. We also use Motorola PTP, Canopy, as well as Airstream, Ubiquiti, Trango, and WaveRider. Regards, Shon Elliott Senior Network Engineer unWired Broadband, Inc. Freddie Sessler wrote: > Hi Folks,I am looking for recommendations on an NMS system for use in > managing a multivendor wireless infrastructure. Specifically we run mostly > Motorola point to point, point to multipoint(Canopy platform) and mesh > radios devices We have looked at the One Point Wireless Manager but this > product in our evaluation doesn't seem to be ready for prime time and also > has the limitation of only being able to manage Motorola. Ideally we would > have something that could be used for configuration management in a multi > vendor environment as well as recieve SNMP traps about RF issues such as > latency and jitter. I am curious to what other shops are using out there. If > this is a top better suited to another list, my apologies and any pointers > to a different list would be greatly appreciated. > > Thanks > JT > From tvhawaii at shaka.com Thu Jun 18 00:09:23 2009 From: tvhawaii at shaka.com (Michael Painter) Date: Wed, 17 Jun 2009 19:09:23 -1000 Subject: WISP NMS recommendations References: Message-ID: <05E4479449414F28BBAFF7603BBE7C9B@DELL16> ----- Original Message ----- From: "Freddie Sessler" To: Sent: Wednesday, June 17, 2009 6:31 PM Subject: WISP NMS recommendations > Hi Folks,I am looking for recommendations on an NMS system for use in > managing a multivendor wireless infrastructure. Specifically we run mostly > Motorola point to point, point to multipoint(Canopy platform) and mesh > radios devices We have looked at the One Point Wireless Manager but this > product in our evaluation doesn't seem to be ready for prime time and also > has the limitation of only being able to manage Motorola. Ideally we would > have something that could be used for configuration management in a multi > vendor environment as well as recieve SNMP traps about RF issues such as > latency and jitter. I am curious to what other shops are using out there. If > this is a top better suited to another list, my apologies and any pointers > to a different list would be greatly appreciated. > > Thanks > JT This list is quite active: http://lists.wispa.org/mailman/listinfo/wireless From kevin.hodle at gmail.com Thu Jun 18 00:52:47 2009 From: kevin.hodle at gmail.com (Kevin Hodle) Date: Thu, 18 Jun 2009 00:52:47 -0500 Subject: Cogent input In-Reply-To: <4A32545E.1030803@justinshore.com> References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> <4A311B06.9010606@linpro.no> <4A318739.4090209@justinshore.com> <4A318C80.6010000@telcodata.us> <4A32545E.1030803@justinshore.com> Message-ID: <9639597a0906172252y4ab0b79eue700acaf4030c18e@mail.gmail.com> Hi Justin, Just FYI - Global Crossing can currently deliver dual stack/native v6 transit in downtown KC,MO. You can either colo with them at 1100 Main St, or possibly have them haul a wave to one of the other major downtown carrier hotels they have strands running through / into (1102 Grand/Bryant and 324 E. 11th St/Oak Towers come to mind, not to mention Level3's suite in 1100 Walnut right across the street). Cheers, Kevin Hodle On Fri, Jun 12, 2009 at 8:13 AM, Justin Shore wrote: > John van Oppen wrote: > >> NTT (2914) and GBLX (3549) both do native v6... most everyone else on >> the tier1 list does tunnels. :( >> >> There are some nice tier2 networks who do native v6, tiscali and he.net >> come to mind. >> > > Let me rephrase that. :-) I know of no tier-Ns that offer any native v6 > services here in the Midwest (central Kansas) including L3 which only has a > best effort pilot program using tunnels. There might be more options in KC > or OKC but not here that I'm aware of... > > Justin > > > > -- || Kevin Hodle || || 913-780-3959 (Primary) || 913-626-7197 (Mobile) PGP KeyID [0xBBDE8ED7] fingerprint [3E1B 1F10 938E A831 8CF2 670C 1329 0B8B BBDE 8ED7] From avg at kotovnik.com Thu Jun 18 01:02:22 2009 From: avg at kotovnik.com (Vadim Antonov) Date: Wed, 17 Jun 2009 23:02:22 -0700 (PDT) Subject: Telephones for Noisy Data Centers In-Reply-To: <4A39C2AD.9000503@west.net> Message-ID: Try noice-canceling aviation headsets (GA or helicopter models have truly amazing noise suppression). High-end models come with cellphone interface. I don't think cellphones will work in many data centers, but I think rigging interface from a normal cordless phone to the headset is pretty simple. The better of these headsets (Bose X, Sennheiser HMC460, Zulu Lightspeed, etc) have additional digital signal processing for getting voice out of noise - if you don't mind expense:) --vadim > Michael J McCafferty wrote: > > All, > > I'd be OK if we were in a facility that was only average in terms of > > noise, but we are not. I need an exceptional phone for the data center. > > Something that doesn't transmit the horrible background noise to the > > other end, and something that is loud without being painful for the user > > of this phone. Cordless would be very fine, headset is excellent. > > Ordinary desk phone is OK... but the most important thing is that it > > works for clear communication. A loud ringer would great too... but if > > the best phone doesn't have one, I'll get an auxiliary ringer. > > > > Does anyone have a phone model that they find to be excellent in a > > louder than usual data center? From bmanning at vacation.karoshi.com Thu Jun 18 02:22:01 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 18 Jun 2009 07:22:01 +0000 Subject: Hurricane Electric In-Reply-To: References: <4A310AC5.5050701@justinshore.com> <20090616041502.9BE96170875@mx.npubs.com> Message-ID: <20090618072201.GA29671@vacation.karoshi.com.> used them for years, from when they were just a local ISP till today. a good addition to your mix... great value for money. --bill On Wed, Jun 17, 2009 at 08:41:23PM -0400, Paul Stewart wrote: > Hi folks... > > Looking for some feedback on using Hurricane Electric as an upstream? > > Thanks, > > Paul > > > > > > ---------------------------------------------------------------------------- > > "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 rblayzor.bulk at inoc.net Thu Jun 18 04:52:49 2009 From: rblayzor.bulk at inoc.net (Robert Blayzor) Date: Thu, 18 Jun 2009 05:52:49 -0400 Subject: IPv6 transits (Was: Cogent input) In-Reply-To: <4A3573FE.9090008@spaghetti.zurich.ibm.com> References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> <4A318C80.6010000@telcodata.us> <20090614215246.GA8015@ajax.opentransit.net> <4A3573FE.9090008@spaghetti.zurich.ibm.com> Message-ID: On Jun 14, 2009, at 6:04 PM, Jeroen Massar wrote: > For people trying to find the "list", check: > http://www.sixxs.net/faq/connectivity/?faq=ipv6transit Since when has Level3 offered native IPv6? I nag our rep & SE's just about every month on "when" and right now AFAIK it's still just tunnels. -- Robert Blayzor, BOFH INOC, LLC rblayzor at inoc.net http://www.inoc.net/~rblayzor/ From nuno.vieira at nfsi.pt Thu Jun 18 04:55:21 2009 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Thu, 18 Jun 2009 10:55:21 +0100 (WEST) Subject: IPv6 transits (Was: Cogent input) In-Reply-To: Message-ID: <226022557.66831245318921717.JavaMail.root@zimbra.nfsi.pt> i can confirm that Level(3), at least in Madrid area is only offering tunneled IPv6. --- Nuno Vieira nfsi telecom, lda. nuno.vieira at nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- "Robert Blayzor" wrote: > On Jun 14, 2009, at 6:04 PM, Jeroen Massar wrote: > > For people trying to find the "list", check: > > http://www.sixxs.net/faq/connectivity/?faq=ipv6transit > > > > Since when has Level3 offered native IPv6? I nag our rep & SE's just > > about every month on "when" and right now AFAIK it's still just > tunnels. > > -- > Robert Blayzor, BOFH > INOC, LLC > rblayzor at inoc.net > http://www.inoc.net/~rblayzor/ From sthaug at nethelp.no Thu Jun 18 05:04:16 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 18 Jun 2009 12:04:16 +0200 (CEST) Subject: IPv6 transits In-Reply-To: References: <20090614215246.GA8015@ajax.opentransit.net> <4A3573FE.9090008@spaghetti.zurich.ibm.com> Message-ID: <20090618.120416.74742791.sthaug@nethelp.no> > > For people trying to find the "list", check: > > http://www.sixxs.net/faq/connectivity/?faq=ipv6transit > > Since when has Level3 offered native IPv6? I nag our rep & SE's just > about every month on "when" and right now AFAIK it's still just tunnels. That's also our experience. We receive Level3 transit in Oslo, Norway. The IPv6 transit is tunnelled to routers in Amsterdam and London. For all I know you might be able to get a native Level3 IPv6 transit if you happen to live in Amsterdam or London... Steinar Haug, Nethelp consulting, sthaug at nethelp.no From tomas.caslavsky at gmail.com Thu Jun 18 05:22:04 2009 From: tomas.caslavsky at gmail.com (Tomas Caslavsky) Date: Thu, 18 Jun 2009 12:22:04 +0200 Subject: IPv6 transits In-Reply-To: <20090618.120416.74742791.sthaug@nethelp.no> References: <20090614215246.GA8015@ajax.opentransit.net> <4A3573FE.9090008@spaghetti.zurich.ibm.com> <20090618.120416.74742791.sthaug@nethelp.no> Message-ID: <4A3A154C.7090902@gmail.com> we are taking Ipv6 from level 3 in London and it's also via tunnel ( they are not able to provide us native). Tomas Caslavsky sthaug at nethelp.no wrote: >>> For people trying to find the "list", check: >>> http://www.sixxs.net/faq/connectivity/?faq=ipv6transit >>> >> Since when has Level3 offered native IPv6? I nag our rep & SE's just >> about every month on "when" and right now AFAIK it's still just tunnels. >> > > That's also our experience. We receive Level3 transit in Oslo, Norway. > The IPv6 transit is tunnelled to routers in Amsterdam and London. > > For all I know you might be able to get a native Level3 IPv6 transit if > you happen to live in Amsterdam or London... > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > > From pstewart at nexicomgroup.net Thu Jun 18 05:45:19 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Thu, 18 Jun 2009 06:45:19 -0400 Subject: Hurricane Electric In-Reply-To: <20090618072201.GA29671@vacation.karoshi.com.> References: <4A310AC5.5050701@justinshore.com> <20090616041502.9BE96170875@mx.npubs.com> <20090618072201.GA29671@vacation.karoshi.com.> Message-ID: Thanks to everyone who replied to this question - I got a LOT of offline replies plus some of them online here.... The response was *very* positive and I appreciate again folks taking the time to drop me a line... Paul -----Original Message----- From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] Sent: June 18, 2009 3:22 AM To: Paul Stewart Cc: NANOG list Subject: Re: Hurricane Electric used them for years, from when they were just a local ISP till today. a good addition to your mix... great value for money. --bill On Wed, Jun 17, 2009 at 08:41:23PM -0400, Paul Stewart wrote: > Hi folks... > > Looking for some feedback on using Hurricane Electric as an upstream? > > Thanks, > > Paul > > > > > > ------------------------------------------------------------------------ ---- > > "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." > ---------------------------------------------------------------------------- "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 rsk at gsp.org Thu Jun 18 06:44:13 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 18 Jun 2009 07:44:13 -0400 Subject: spamhaus drop list In-Reply-To: <20090616210450.10312.qmail@simone.iecc.com> References: <8685783A8C22C640AD1361E78659B7D769760D@ahex02.activehost.local> <20090616210450.10312.qmail@simone.iecc.com> Message-ID: <20090618114413.GA24934@gsp.org> On Tue, Jun 16, 2009 at 09:04:50PM -0000, John Levine wrote: > Not that I've ever seen. Nobody else has the breadth of data that > Spamhaus does. > > I've been using it for ages and based on zero complaints, it's never > blocked anything that any of my users wanted. I strongly concur with John: using the Spamhaus DROP list is incredibly effective not just against spam but against many other forms of abuse. I use a script to update various routers/firewalls/mail systems once a week, and there have been no problems of any kind with it. ---Rsk From NANOG at Aquillar.com Thu Jun 18 08:05:56 2009 From: NANOG at Aquillar.com (Peter Boone) Date: Thu, 18 Jun 2009 09:05:56 -0400 Subject: Wireless bridge Message-ID: <005c01c9f015$852ae490$8f80adb0$@com> Hi NANOG, I'm looking for some equipment recommendations for a wireless bridge between two locations approximately 500-800 meters apart. The current setup for this company has been extremely unstable and slow. I don't have a lot of experience in this area so I was hoping someone could give me a few pointers. Currently, both locations are using Linksys WRT54GL's flashed with DD-WRT firmware (Yes, 802.11g. All extra bells and whistles are disabled in the firmware. They were set up for WDS so other wireless clients could connect to the same access point, with varying degrees of success. Not very important). They are connected to SmartAnt 2300-2500 MHz 14 dBi directional antenna mounted on the roof (extended pretty high for perfect line of sight). I'm not sure when they got these antenna exactly but I'm told it was when WiFi was very new. The network is very small so both locations share the same subnet (192.168.1.0/24). They have gone through numerous Linksys access points over the years. The wireless settings are tweaked as best as possible, and we have found the connection to be most stable when the TX is limited to 6-9 Mbps. We have explored other options as well. An internet connection at each location + VPN is out due to very slow upstream speeds (the buildings are in an industrial area, ADSL is the only option.) The max they offer on regular business accounts is 800 kbps up. T1 lines are even slower and even more expensive. They won't offer us any other solutions such as fibre. We have considered running fibre/coax but there is too much construction activity and other property in the way. I'm looking into RouterBOARD right now, considering a RB433AH and R52H wireless card, but I'm not sure this will actually solve the problem. It's difficult to determine if the issue is with the antennas or access points (for example, after a good thunderstorm, the wireless link will be down for at least 12 hours, but will fix itself eventually. Resetting either access point will keep the link down for at least 30 minutes. Using an airgun on the access points tends to make them more reliable, even if they are clean and dust free. From the admin interface, each access point will report seeing a very good and strong signal from the other, yet they refuse to communicate until they feel like it a few hours later.) Any suggestions welcome. I'm sure you can tell cost is a bit of a factor here but it will be easy for me to justify a higher price if I'm confident it will be effective. While I'm at it, I've been reading along on the list for over a year now; thanks everyone for sharing your real world experiences :) Peter From jared at puck.nether.net Thu Jun 18 08:18:24 2009 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 18 Jun 2009 09:18:24 -0400 Subject: Wireless bridge In-Reply-To: <005c01c9f015$852ae490$8f80adb0$@com> References: <005c01c9f015$852ae490$8f80adb0$@com> Message-ID: <20090618131824.GA25957@puck.nether.net> On Thu, Jun 18, 2009 at 09:05:56AM -0400, Peter Boone wrote: > Hi NANOG, > > I'm looking for some equipment recommendations for a wireless bridge between > two locations approximately 500-800 meters apart. The current setup for this > company has been extremely unstable and slow. I don't have a lot of > experience in this area so I was hoping someone could give me a few > pointers. I've had good luck with Cisco Aironet gear running in repeater mode. I've done the cheap linksys thing as well and it just did not work as well as using some equipment that was better designed. I have actually found the non-IOS software on the aironet 350/340 to be more usable than the IOS software. You need to have your network be consistent. You also have the obvious interference challenges with any unlicensed deployment. - Jared some of the equipment i've used: http://cgi.ebay.com/5-Cisco-Aironet-350-WAPs-AP352E2R-A-K9_W0QQitemZ200351697798QQcmdZViewItemQQptZCOMP_EN_Routers?hash=item2ea5e44b86&_trksid=p3286.c0.m14&_trkparms=65%3A1|66%3A2|39%3A1|240%3A1318|301%3A1|293%3A1|294%3A50 http://cgi.ebay.com/Cisco-AIR-AP1121G-A-K9-Aironet-1100-1121-Access-Point_W0QQitemZ190313803887QQcmdZViewItemQQptZCOMP_EN_Routers?hash=item2c4f96306f&_trksid=p3286.c0.m14&_trkparms=65%3A1|66%3A2|39%3A1|240%3A1318|301%3A1|293%3A1|294%3A50 -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From shoemakerp at vectordatasystems.com Thu Jun 18 08:21:56 2009 From: shoemakerp at vectordatasystems.com (Patrick Shoemaker) Date: Thu, 18 Jun 2009 09:21:56 -0400 Subject: WISP NMS recommendations In-Reply-To: References: Message-ID: <4A3A3F74.6060601@vectordatasystems.com> Although this would probably be better suited for one of the WISPA lists, I'll respond here anyhow since there seems to be some interest. For managing Canopy elements, Motorola Prizm is probably the way to go. First of all, you'll need it to handle element authentication for your PtMP system. It will also do configuration management, alerting, and all the usual NMS stuff. It's also *possible* to get it to work with other SNMP capable devices if you want to manage other vendors' equipment. It will work out of the box with the Canopy PtMP line, PtP devices, powerline carrier devices, and (I think) the MotoMESH line. It gives you all the info you need at a glance for each element: configuration history, RF power level plots, bandwidth utilization plots, alert history, etc. FYI if you haven't used it, Prizm is a pretty clunky and slow Java-based package. The features are nice, but configuring it can be a chore. Patrick Shoemaker Vector Data Systems LLC shoemakerp at vectordatasystems.com office: (301) 358-1690 x36 http://www.vectordatasystems.com nanog-request at nanog.org wrote: > Message: 5 > Date: Wed, 17 Jun 2009 21:31:29 -0700 > From: Freddie Sessler > Subject: WISP NMS recommendations > To: nanog at nanog.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Folks,I am looking for recommendations on an NMS system for use in > managing a multivendor wireless infrastructure. Specifically we run mostly > Motorola point to point, point to multipoint(Canopy platform) and mesh > radios devices We have looked at the One Point Wireless Manager but this > product in our evaluation doesn't seem to be ready for prime time and also > has the limitation of only being able to manage Motorola. Ideally we would > have something that could be used for configuration management in a multi > vendor environment as well as recieve SNMP traps about RF issues such as > latency and jitter. I am curious to what other shops are using out there. If > this is a top better suited to another list, my apologies and any pointers > to a different list would be greatly appreciated. > > Thanks > JT From joe at routespot.com Thu Jun 18 08:24:31 2009 From: joe at routespot.com (Joe Tyson) Date: Thu, 18 Jun 2009 09:24:31 -0400 Subject: Wireless bridge In-Reply-To: <20090618131824.GA25957@puck.nether.net> References: <005c01c9f015$852ae490$8f80adb0$@com> <20090618131824.GA25957@puck.nether.net> Message-ID: <7b88df5e0906180624s3ade4a0td57859ca89cf37f9@mail.gmail.com> We've used aironet since before cisco owned it. We just recently went fiber for most of the district, but still running one aironet connection a good distance apart. On Thu, Jun 18, 2009 at 9:18 AM, Jared Mauch wrote: > On Thu, Jun 18, 2009 at 09:05:56AM -0400, Peter Boone wrote: > > Hi NANOG, > > > > I'm looking for some equipment recommendations for a wireless bridge > between > > two locations approximately 500-800 meters apart. The current setup for > this > > company has been extremely unstable and slow. I don't have a lot of > > experience in this area so I was hoping someone could give me a few > > pointers. > > I've had good luck with Cisco Aironet gear running in repeater > mode. > > I've done the cheap linksys thing as well and it just did not work > as well as using some equipment that was better designed. > > I have actually found the non-IOS software on the aironet 350/340 to > be more usable than the IOS software. You need to have your network be > consistent. > > You also have the obvious interference challenges with any > unlicensed > deployment. > > - Jared > > some of the equipment i've used: > > > http://cgi.ebay.com/5-Cisco-Aironet-350-WAPs-AP352E2R-A-K9_W0QQitemZ200351697798QQcmdZViewItemQQptZCOMP_EN_Routers?hash=item2ea5e44b86&_trksid=p3286.c0.m14&_trkparms=65%3A1|66%3A2|39%3A1|240%3A1318|301%3A1|293%3A1|294%3A50 > > > http://cgi.ebay.com/Cisco-AIR-AP1121G-A-K9-Aironet-1100-1121-Access-Point_W0QQitemZ190313803887QQcmdZViewItemQQptZCOMP_EN_Routers?hash=item2c4f96306f&_trksid=p3286.c0.m14&_trkparms=65%3A1|66%3A2|39%3A1|240%3A1318|301%3A1|293%3A1|294%3A50 > > > -- > Jared Mauch | pgp key available via finger from jared at puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are only > mine. > > From cra at WPI.EDU Thu Jun 18 08:28:38 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 18 Jun 2009 09:28:38 -0400 Subject: Wireless bridge In-Reply-To: <005c01c9f015$852ae490$8f80adb0$@com> References: <005c01c9f015$852ae490$8f80adb0$@com> Message-ID: <20090618132838.GR21944@angus.ind.WPI.EDU> On Thu, Jun 18, 2009 at 09:05:56AM -0400, Peter Boone wrote: > I'm looking for some equipment recommendations for a wireless bridge between > two locations approximately 500-800 meters apart. The current setup for this > company has been extremely unstable and slow. I don't have a lot of > experience in this area so I was hoping someone could give me a few > pointers. We use Nortel 7230 wireless bridges and are *very* happy with them. They run at 5.8 GHz, 20 Mbps full duplex (really 18 Mbps data rate), do transparent bridging, and pass VLAN tagged frames just fine. For one particular link, we continually push the full 18 Mbps and they work fine. They are PoE powered via a power brick in the network closets, with a single Cat5 cable up to the outdoor unit which has the antenna integrated. We've had very few failures over the years--mainly a few infancy failures shortly after installation. We have about 40 units (20 links), all less than 1 km apart, most of them a few hundred meters across city streets. These are the third generation of wireless bridge products we have used, and they far outperform the older ones, especially from a reliability and maintenance perspective. We will be looking to upgrade these over the next few years to get more bandwidth in some locations, and I'm not overly optimistic about finding something that matches these from a reliability and ease-of-use perspective--I would appreciate it if you share a summary of any results you find. From r.engehausen at gmail.com Thu Jun 18 09:06:41 2009 From: r.engehausen at gmail.com (Roy) Date: Thu, 18 Jun 2009 07:06:41 -0700 Subject: Wireless bridge In-Reply-To: <005c01c9f015$852ae490$8f80adb0$@com> References: <005c01c9f015$852ae490$8f80adb0$@com> Message-ID: <4A3A49F1.8010209@gmail.com> Peter Boone wrote: > Hi NANOG, > > I'm looking for some equipment recommendations for a wireless bridge between > two locations approximately 500-800 meters apart. The current setup for this > company has been extremely unstable and slow. I don't have a lot of > experience in this area so I was hoping someone could give me a few > pointers. > > .... I have had good luck with Airaya. May be a bit pricy for your application but they are solid. The one I am on right now has to be at least five years old. http://airaya.com Whatever you do, move out of 2.4Ghz. That's probably 50% of your problems right there. From cmaurand at xyonet.com Thu Jun 18 09:15:14 2009 From: cmaurand at xyonet.com (Curtis Maurand) Date: Thu, 18 Jun 2009 10:15:14 -0400 Subject: Wireless bridge In-Reply-To: <005c01c9f015$852ae490$8f80adb0$@com> References: <005c01c9f015$852ae490$8f80adb0$@com> Message-ID: <4A3A4BF2.8080807@xyonet.com> Cisco Aironet www.cisco.com Alvarion www.alvarion.com Aruba www.arubanetworks.com bluesocket www.bluesocket.com I've used all but bluesocket and they all worked pretty well. bluesocket gets good reviews. These are just a few. There are lots of them. Try to use one as and access point and use one as a client. Working in repeater mode will cut your bandwidth in half. --Curtis Peter Boone wrote: > Hi NANOG, > > I'm looking for some equipment recommendations for a wireless bridge between > two locations approximately 500-800 meters apart. The current setup for this > company has been extremely unstable and slow. I don't have a lot of > experience in this area so I was hoping someone could give me a few > pointers. > > Currently, both locations are using Linksys WRT54GL's flashed with DD-WRT > firmware (Yes, 802.11g. All extra bells and whistles are disabled in the > firmware. They were set up for WDS so other wireless clients could connect > to the same access point, with varying degrees of success. Not very > important). They are connected to SmartAnt 2300-2500 MHz 14 dBi directional > antenna mounted on the roof (extended pretty high for perfect line of > sight). I'm not sure when they got these antenna exactly but I'm told it was > when WiFi was very new. The network is very small so both locations share > the same subnet (192.168.1.0/24). > > They have gone through numerous Linksys access points over the years. The > wireless settings are tweaked as best as possible, and we have found the > connection to be most stable when the TX is limited to 6-9 Mbps. > > We have explored other options as well. An internet connection at each > location + VPN is out due to very slow upstream speeds (the buildings are in > an industrial area, ADSL is the only option.) The max they offer on regular > business accounts is 800 kbps up. T1 lines are even slower and even more > expensive. They won't offer us any other solutions such as fibre. We have > considered running fibre/coax but there is too much construction activity > and other property in the way. > > I'm looking into RouterBOARD right now, considering a RB433AH and R52H > wireless card, but I'm not sure this will actually solve the problem. It's > difficult to determine if the issue is with the antennas or access points > (for example, after a good thunderstorm, the wireless link will be down for > at least 12 hours, but will fix itself eventually. Resetting either access > point will keep the link down for at least 30 minutes. Using an airgun on > the access points tends to make them more reliable, even if they are clean > and dust free. From the admin interface, each access point will report > seeing a very good and strong signal from the other, yet they refuse to > communicate until they feel like it a few hours later.) > > Any suggestions welcome. I'm sure you can tell cost is a bit of a factor > here but it will be easy for me to justify a higher price if I'm confident > it will be effective. > > While I'm at it, I've been reading along on the list for over a year now; > thanks everyone for sharing your real world experiences :) > > Peter > > > From joelja at bogus.com Thu Jun 18 09:23:39 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 18 Jun 2009 07:23:39 -0700 Subject: Wireless bridge In-Reply-To: <005c01c9f015$852ae490$8f80adb0$@com> References: <005c01c9f015$852ae490$8f80adb0$@com> Message-ID: <4A3A4DEB.6030605@bogus.com> Pair of Ubuquiti power station 2 or 5 bridges, 5 would be preferable, under $200 per end. http://www.ubnt.com/downloads/ps5_datasheet.pdf Peter Boone wrote: > Hi NANOG, > > I'm looking for some equipment recommendations for a wireless bridge between > two locations approximately 500-800 meters apart. The current setup for this > company has been extremely unstable and slow. I don't have a lot of > experience in this area so I was hoping someone could give me a few > pointers. > > Currently, both locations are using Linksys WRT54GL's flashed with DD-WRT > firmware (Yes, 802.11g. All extra bells and whistles are disabled in the > firmware. They were set up for WDS so other wireless clients could connect > to the same access point, with varying degrees of success. Not very > important). They are connected to SmartAnt 2300-2500 MHz 14 dBi directional > antenna mounted on the roof (extended pretty high for perfect line of > sight). I'm not sure when they got these antenna exactly but I'm told it was > when WiFi was very new. The network is very small so both locations share > the same subnet (192.168.1.0/24). > > They have gone through numerous Linksys access points over the years. The > wireless settings are tweaked as best as possible, and we have found the > connection to be most stable when the TX is limited to 6-9 Mbps. > > We have explored other options as well. An internet connection at each > location + VPN is out due to very slow upstream speeds (the buildings are in > an industrial area, ADSL is the only option.) The max they offer on regular > business accounts is 800 kbps up. T1 lines are even slower and even more > expensive. They won't offer us any other solutions such as fibre. We have > considered running fibre/coax but there is too much construction activity > and other property in the way. > > I'm looking into RouterBOARD right now, considering a RB433AH and R52H > wireless card, but I'm not sure this will actually solve the problem. It's > difficult to determine if the issue is with the antennas or access points > (for example, after a good thunderstorm, the wireless link will be down for > at least 12 hours, but will fix itself eventually. Resetting either access > point will keep the link down for at least 30 minutes. Using an airgun on > the access points tends to make them more reliable, even if they are clean > and dust free. From the admin interface, each access point will report > seeing a very good and strong signal from the other, yet they refuse to > communicate until they feel like it a few hours later.) > > Any suggestions welcome. I'm sure you can tell cost is a bit of a factor > here but it will be easy for me to justify a higher price if I'm confident > it will be effective. > > While I'm at it, I've been reading along on the list for over a year now; > thanks everyone for sharing your real world experiences :) > > Peter > > From blackwolf99999 at gmail.com Thu Jun 18 09:24:54 2009 From: blackwolf99999 at gmail.com (Brian Shope) Date: Thu, 18 Jun 2009 07:24:54 -0700 Subject: Unicast Flooding In-Reply-To: <4A39A8EE.7080603@kingrst.com> References: <295271b90906171432h431f9867td53ded86f2a787f@mail.gmail.com> <483E6B0272B0284BA86D7596C40D29F9C381C142F5@PUR-EXCH07.ox.com> <485ED9BA02629E4BBBA53AC892EDA50E09237370@usmsxt104.mwd.h2o> <4A39A8EE.7080603@kingrst.com> Message-ID: <295271b90906180724y2d899d42x76809c255a6d449b@mail.gmail.com> Thanks for all the good info.. So it sounds like changing my CAM timeout to 4 hours is the best suggestion. Anyone have any problems when implementing this? From Tim at bobbroadband.com Thu Jun 18 09:26:02 2009 From: Tim at bobbroadband.com (Tim Huffman) Date: Thu, 18 Jun 2009 09:26:02 -0500 Subject: WISP NMS recommendations In-Reply-To: References: Message-ID: We use Intermapper. It's very flexible, and offers a 'wireless probe' package, which covers Motorola Canopy and their PTP products, along with several other hardware vendors (Alvarion, Atmel, MikroTik, etc). Also, it's written in Java, and runs on just about anything. It does monitoring and (very basic) graphing, but not management. They have a pretty well documented and simple scripting language for writing new probes as well, which comes in very handy. I've written probes for several Dragonwave products, and submitted them to the community. Their support is also very responsive, which is always important. Tim Huffman Director of Engineering Business Only Broadband, LLC O (630) 590-6012 C?(630) 340-1925 tim at bobbroadband.com www.bobbroadband.com > -----Original Message----- > From: Freddie Sessler [mailto:nanogger at gmail.com] > Sent: Wednesday, June 17, 2009 11:31 PM > To: nanog at nanog.org > Subject: WISP NMS recommendations > > Hi Folks,I am looking for recommendations on an NMS system for use in > managing a multivendor wireless infrastructure. Specifically we run mostly > Motorola point to point, point to multipoint(Canopy platform) and mesh > radios devices We have looked at the One Point Wireless Manager but this > product in our evaluation doesn't seem to be ready for prime time and also > has the limitation of only being able to manage Motorola. Ideally we would > have something that could be used for configuration management in a multi > vendor environment as well as recieve SNMP traps about RF issues such as > latency and jitter. I am curious to what other shops are using out there. > If > this is a top better suited to another list, my apologies and any pointers > to a different list would be greatly appreciated. > > Thanks > JT From wavetossed at googlemail.com Thu Jun 18 09:53:23 2009 From: wavetossed at googlemail.com (Michael Dillon) Date: Thu, 18 Jun 2009 15:53:23 +0100 Subject: Wireless bridge In-Reply-To: <005c01c9f015$852ae490$8f80adb0$@com> References: <005c01c9f015$852ae490$8f80adb0$@com> Message-ID: <877585b00906180753s47617a64la780d7ac1f8c05ca@mail.gmail.com> > (for example, after a good thunderstorm, the wireless link will be down for > at least 12 hours, but will fix itself eventually. Sounds like there are trees in the line of sight, and maybe they are getting leafier over the years. The only solution to that is to change the path if it is possible. From jeff-kell at utc.edu Thu Jun 18 10:05:51 2009 From: jeff-kell at utc.edu (Jeff Kell) Date: Thu, 18 Jun 2009 11:05:51 -0400 Subject: Unicast Flooding In-Reply-To: <485ED9BA02629E4BBBA53AC892EDA50E09237370@usmsxt104.mwd.h2o> References: <295271b90906171432h431f9867td53ded86f2a787f@mail.gmail.com> <483E6B0272B0284BA86D7596C40D29F9C381C142F5@PUR-EXCH07.ox.com> <485ED9BA02629E4BBBA53AC892EDA50E09237370@usmsxt104.mwd.h2o> Message-ID: <4A3A57CF.4090703@utc.edu> Holmes,David A wrote: > In a layer 3 switch I consider unicast flooding due to an L2 cam table timeout a design defect. To test vendors' L3 switches for this defect we have used a traffic generator to send 50-100 Mbps of pings to a device that does not reply to the pings, where the L3 switch was routing from one vlan to another to forward the pings. You don't need an elaborate scenario to create the unicast flooding. Syslog servers can cause this quite frequently, if all they do is sink syslog UDP traffic and never (or rarely) generate any packets themselves. You can push up L2 / CAM / mac-address-table timeouts, but you may have some unexpected results if you have a volatile / mobile network where end devices are not static. I still don't have a "really comfortable" recommendation on settings, but agree in general that the ARP timeout should be somewhat less than the L2 timeout, and yes, the ARP response will refresh the L2 entry. It gets even more complicated if you are using a NAC / monitoring function that triggers on mac-address-table tracking / changes / traps, as the shorter the L2 timeout, the more frequent your mac-address-table changes are generated. You can complicate this even further with "smart" monitors that are trying to keep a mapping of IP-to-MAC-to-switchport -- you may have L2 entries without ARPs, ARPs without L2 entries, etc. Jeff From Tim at bobbroadband.com Thu Jun 18 10:16:53 2009 From: Tim at bobbroadband.com (Tim Huffman) Date: Thu, 18 Jun 2009 10:16:53 -0500 Subject: Wireless bridge In-Reply-To: <005c01c9f015$852ae490$8f80adb0$@com> References: <005c01c9f015$852ae490$8f80adb0$@com> Message-ID: We're a WISP, so I have lots of experience with this kind of thing. The problem with using 2.4GHz equipment is that there's a whole lot of noise out there (run Network Stumbler sometime on a laptop with a wireless card, and you'll be shocked by just how many wi-fi APs are floating around). You didn't mention your bandwidth requirements, but I'm assuming that you're trying to get more (and spend less), so I'll only recommend unlicensed gear. For that distance, you might want to consider using a 5.2GHz radio. The FCC limits their transmit power, so they only work well in short-range applications (>2 miles or so), and 5.2GHz doesn't propagate the way that 2.4GHz does, so there tends to be much less noise in that band. The Motorola PTP400 series (http://www.motorola.com/Business/US-EN/Business+Product+and+Services/Wireless+Broadband+Networks/Point-to-Point+Bridges) is very good (Asymetric Dynamic Frequency selection means that each side can pick the best frequency to transmit on, and ARQ means that scrambled packets get handled at the wireless layer), and throughput tops out about 45Mbps (300Mbps for the PTP600 series), but they are expensive. They can be purchased in many different bands. On the lower end, we've been using Ligowave (http://www.ligowave.com), and had good results from them, for the price. They also come in many bands, and run about $3000 (for the model with an integrated panel antenna), support throughput up to 45Mbps, and also support ARQ. Hope this helps. Tim Huffman Director of Engineering Business Only Broadband, LLC O (630) 590-6012 C?(630) 340-1925 tim at bobbroadband.com www.bobbroadband.com > -----Original Message----- > From: Peter Boone [mailto:NANOG at Aquillar.com] > Sent: Thursday, June 18, 2009 8:06 AM > To: nanog at nanog.org > Subject: Wireless bridge > > Hi NANOG, > > I'm looking for some equipment recommendations for a wireless bridge > between > two locations approximately 500-800 meters apart. The current setup for > this > company has been extremely unstable and slow. I don't have a lot of > experience in this area so I was hoping someone could give me a few > pointers. > > Currently, both locations are using Linksys WRT54GL's flashed with DD-WRT > firmware (Yes, 802.11g. All extra bells and whistles are disabled in the > firmware. They were set up for WDS so other wireless clients could connect > to the same access point, with varying degrees of success. Not very > important). They are connected to SmartAnt 2300-2500 MHz 14 dBi > directional > antenna mounted on the roof (extended pretty high for perfect line of > sight). I'm not sure when they got these antenna exactly but I'm told it > was > when WiFi was very new. The network is very small so both locations share > the same subnet (192.168.1.0/24). > > They have gone through numerous Linksys access points over the years. The > wireless settings are tweaked as best as possible, and we have found the > connection to be most stable when the TX is limited to 6-9 Mbps. > > We have explored other options as well. An internet connection at each > location + VPN is out due to very slow upstream speeds (the buildings are > in > an industrial area, ADSL is the only option.) The max they offer on > regular > business accounts is 800 kbps up. T1 lines are even slower and even more > expensive. They won't offer us any other solutions such as fibre. We have > considered running fibre/coax but there is too much construction activity > and other property in the way. > > I'm looking into RouterBOARD right now, considering a RB433AH and R52H > wireless card, but I'm not sure this will actually solve the problem. It's > difficult to determine if the issue is with the antennas or access points > (for example, after a good thunderstorm, the wireless link will be down > for > at least 12 hours, but will fix itself eventually. Resetting either access > point will keep the link down for at least 30 minutes. Using an airgun on > the access points tends to make them more reliable, even if they are clean > and dust free. From the admin interface, each access point will report > seeing a very good and strong signal from the other, yet they refuse to > communicate until they feel like it a few hours later.) > > Any suggestions welcome. I'm sure you can tell cost is a bit of a factor > here but it will be easy for me to justify a higher price if I'm confident > it will be effective. > > While I'm at it, I've been reading along on the list for over a year now; > thanks everyone for sharing your real world experiences :) > > Peter > From lucas at slashdot.org Thu Jun 18 10:19:01 2009 From: lucas at slashdot.org (L K) Date: Thu, 18 Jun 2009 11:19:01 -0400 Subject: Cogent input In-Reply-To: <9639597a0906172252y4ab0b79eue700acaf4030c18e@mail.gmail.com> References: <4A310AC5.5050701@justinshore.com> <200906111033.26208.kratzers@pa.net> <4A311B06.9010606@linpro.no> <4A318739.4090209@justinshore.com> <4A318C80.6010000@telcodata.us> <4A32545E.1030803@justinshore.com> <9639597a0906172252y4ab0b79eue700acaf4030c18e@mail.gmail.com> Message-ID: <3eb773b20906180819m702d32e9q683121ef3fcb6a20@mail.gmail.com> Speaking of the devil: "Comcast plans to enter into broadband IPv6 technical trials later this year and into 2010," {Barry Tishgart, VP of Internet Services for Comcast} said. "Planning for general deployment is underway." http://tech.slashdot.org/story/09/06/18/1417201/Comcast-To-Bring-IPv6-To-Residential-US-In-2010 http://www.internetnews.com/infra/article.phpr/3825696/Comcast+Embraces+IPv6.htm http://news.google.com/news/more?um=1&ned=us&cf=all&ncl=dsg_EPKdMw3ISjMxORbZRq061pu7M On Thu, Jun 18, 2009 at 1:52 AM, Kevin Hodle wrote: > Hi Justin, > > ? ? Just FYI - Global Crossing can currently deliver dual stack/native v6 > transit in downtown KC,MO. You can either colo with them at 1100 Main St, or > possibly have them haul a wave to one of the other major downtown carrier > hotels they have strands running through / into (1102 Grand/Bryant and 324 > E. 11th St/Oak Towers come to mind, not to mention Level3's suite in 1100 > Walnut right across the street). > > Cheers, > Kevin Hodle > > On Fri, Jun 12, 2009 at 8:13 AM, Justin Shore wrote: > >> John van Oppen wrote: >> >>> NTT (2914) and GBLX (3549) both do native v6... ?most everyone else on >>> the tier1 list does tunnels. ?:( >>> >>> There are some nice tier2 networks who do native v6, tiscali and he.net >>> come to mind. >>> >> >> Let me rephrase that. :-) ?I know of no tier-Ns that offer any native v6 >> services here in the Midwest (central Kansas) including L3 which only has a >> best effort pilot program using tunnels. ?There might be more options in KC >> or OKC but not here that I'm aware of... >> >> Justin >> >> >> >> > > > -- > || ?Kevin Hodle > || > || ?913-780-3959 (Primary) > || ?913-626-7197 (Mobile) > > PGP KeyID [0xBBDE8ED7] > fingerprint [3E1B 1F10 938E A831 8CF2 670C 1329 0B8B BBDE 8ED7] > From jasongurtz at npumail.com Thu Jun 18 10:25:24 2009 From: jasongurtz at npumail.com (Jason Gurtz) Date: Thu, 18 Jun 2009 11:25:24 -0400 Subject: Wireless bridge In-Reply-To: <005c01c9f015$852ae490$8f80adb0$@com> References: <005c01c9f015$852ae490$8f80adb0$@com> Message-ID: > (for example, after a good thunderstorm, the wireless link will be down > for at least 12 hours, but will fix itself eventually. Are you sure there's not a moisture problem in the antennae cabling? Get an SWR meter that can handle the 2.4 GHz range and make sure that SWR is very low (approaching 1:1 but certainly less than 2:1). Hook up the meter in-line at the AP. Test this after everything is wet and again when there's been a dry spell. Minimize the number of exposed connections and use dielectric grease. Any exposed connections should be well wrapped with that rubberized electricians tape first, then with regular. > Resetting either access point will keep the link down for at least 30 > minutes. This seems to point to signal quality issues. This could be interference as others have suggested. Few things to try (in order of less work, less $$$): 1.) Try different 802.11 channels. Pick one of 1, 6, or 12 as they are the only non-overlapping spectrum. Set this manually on both ends 2.) if yaggi type antennas, try changing the polarity. If it's vertical now, try horizontal or vice versa (both ends should be the same for maximum gain!) 3.) Try even higher gain "dish" style antennas (these have circular polarity) 4.) Use APs that do 802.11a or n. These are much less susceptible to interference. This probably also means changing/adding antennas. *.) Bonus idea: Google roll your own dsl (assuming both locations have the same CO). Basically: get a dry pair (no dialtone) from the telco going from location A to Location B; buy two sdsl modems and install at each end; hopefully enjoy a few-several Mb connection! ~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 rbtrux at gmail.com Thu Jun 18 10:51:57 2009 From: rbtrux at gmail.com (Rick) Date: Thu, 18 Jun 2009 11:51:57 -0400 Subject: Telephones for Noisy Data Centers Message-ID: <000801c9f02c$b71ba7c0$681ea8c0@rick> The ones I can recommend in that line are the headsets from David Clark. I've used these for decades in some of the harshest noise locations with great success. While most of the adaptors I use are home made I suspect that they can supply one for about any application. They have for me. http://www.davidclark.com/ regards Rick Try noice-canceling aviation headsets (GA or helicopter models have truly amazing noise suppression). High-end models come with cellphone interface. I don't think cellphones will work in many data centers, but I think rigging interface from a normal cordless phone to the headset is pretty simple. The better of these headsets (Bose X, Sennheiser HMC460, Zulu Lightspeed, etc) have additional digital signal processing for getting voice out of noise - if you don't mind expense:) --vadim > Michael J McCafferty wrote: > > All, > > I'd be OK if we were in a facility that was only average in terms of > > noise, but we are not. I need an exceptional phone for the data center. > > Something that doesn't transmit the horrible background noise to the > > other end, and something that is loud without being painful for the user > > of this phone. Cordless would be very fine, headset is excellent. > > Ordinary desk phone is OK... but the most important thing is that it > > works for clear communication. A loud ringer would great too... but if > > the best phone doesn't have one, I'll get an auxiliary ringer. > > > > Does anyone have a phone model that they find to be excellent in a > > louder than usual data center? From NANOG at Aquillar.com Thu Jun 18 10:54:58 2009 From: NANOG at Aquillar.com (Peter Boone) Date: Thu, 18 Jun 2009 11:54:58 -0400 Subject: Wireless bridge In-Reply-To: <877585b00906180753s47617a64la780d7ac1f8c05ca@mail.gmail.com> References: <005c01c9f015$852ae490$8f80adb0$@com> <877585b00906180753s47617a64la780d7ac1f8c05ca@mail.gmail.com> Message-ID: <09ef01c9f02d$221f21f0$665d65d0$@com> > From: Michael Dillon [mailto:wavetossed at googlemail.com] > > (for example, after a good thunderstorm, the wireless link will be > down for > > at least 12 hours, but will fix itself eventually. > > Sounds like there are trees in the line of sight, and maybe they are > getting > leafier over the years. The only solution to that is to change the path > if > it is possible. The line of sight is all clear, no trees. Only one building along the way has a rooftop of similar height, but the antennas are extended far above the roofline. We have used a rifle scope to confirm line of sight is all clear at all angles. > From: Tim Huffman [mailto:Tim at bobbroadband.com] > We're a WISP, so I have lots of experience with this kind of thing. The > problem with using 2.4GHz equipment is that there's a whole lot of > noise out there (run Network Stumbler sometime on a laptop with a > wireless card, and you'll be shocked by just how many wi-fi APs are > floating around). > Oh I know. Luckily it's located in an industrial area just on the outskirts of the city. There isn't a lot of other WiFi (in my opinion); 3-5 total SSIDs spread across 2 of the 3 physical channels (1,6,11) depending on which rooftop you measure from. > You didn't mention your bandwidth requirements, but I'm assuming that > you're trying to get more (and spend less), so I'll only recommend > unlicensed gear. For that distance, you might want to consider using a > 5.2GHz radio. The FCC limits their transmit power, so they only work > well in short-range applications (>2 miles or so), and 5.2GHz doesn't > propagate the way that 2.4GHz does, so there tends to be much less > noise in that band. > Bandwidth requirements aren't too picky. If it can handle minimum 9 Mbps full-duplex everyone will be happy. Of course, the faster the better. I don't know if it makes a difference or not but this is all taking place in Canada. I don't know of any regulations drastically different from the U.S's regarding frequency use here. The biggest problem I've ever had though has just been payment/shipping depending on the supplier (some don't ship to Canada or are very specific about payment methods!). Just to answer a few more questions I've been getting, the access points are located inside, connected to a small UPS. The antenna wire is a very thick coax up to the roof, BNC connectors to the access point and I'm fairly certain BNC connectors on the antenna end as well. I'll double check grounding on the poles but I'm somewhat afraid to turn it into a lightning rod. I'm fairly certain that the ground in the antenna wire is clean but again, something to double check. Rain/moisture doesn't seem to cause problems. In fact the connection is more reliable through the winter. The last 2 months here have been cold/warm, dry/wet and there's been no pattern to the stability issues. The only correlation between weather and stability that they have noticed there is lightning related. > From: Jason Gurtz [mailto:jasongurtz at npumail.com] > Are you sure there's not a moisture problem in the antennae cabling? I hope I just answered most of your questions Jason. Good tips to check for too. I'll answer more of your specific questions ASAP. Thanks everyone for the responses so far on and off list. I've been getting lots of product suggestions as well as ideas for troubleshooting the current implementation for the short term. I'm working on another project for today so I've just been skimming through the responses. Later tonight I'll go through all the options in more detail and report back/answer more questions. Keep 'em coming and thanks again, Peter From sandy at tislabs.com Thu Jun 18 11:05:20 2009 From: sandy at tislabs.com (Sandy Murphy) Date: Thu, 18 Jun 2009 12:05:20 -0400 (EDT) Subject: question about Mark Koster's ARIN presentation Message-ID: <20090618160520.93FEE3F476@pecan.tislabs.com> This message is sent to the whole nanog list, rather than the nanog-attendees list, as I'm not sure who would be watching that list when the conference is over. I stood up to ask a question at the end of Mark Koster's presentation yesterday, but before I got to the end of the table, he was being applauded and leaving the stage. I must be too short. The presentation said that ARIN would be doing a lot of work to improve the IRR. The last I asked, the ARIN IRR did not support the RPSS (Routing Policy System Security - RFC2725). RIPE supports this, I know. Will the ARIN improvements include support for RPSS? The presentation talked about the RPKI pilot, and Mark said that ARIN would be using the RIPE code. I believe RIPE has or had a couple different attempts at this, so I'm not sure what features the code you use will have. Will you have the ability to hand certs to ISPs so that they can do their own cert generation for the allocations they hand to their own customers? I.e., is ARIN going to run a service just for its members, or will it enable its members to participate in the RPKI themselves? --Sandy From lyndon at orthanc.ca Thu Jun 18 11:11:02 2009 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 18 Jun 2009 10:11:02 -0600 Subject: Wireless bridge In-Reply-To: <09ef01c9f02d$221f21f0$665d65d0$@com> References: <005c01c9f015$852ae490$8f80adb0$@com> <877585b00906180753s47617a64la780d7ac1f8c05ca@mail.gmail.com> <09ef01c9f02d$221f21f0$665d65d0$@com> Message-ID: <1245341463.1310.22.camel@legolas.orthanc.ca> On Thu, 2009-06-18 at 11:54 -0400, Peter Boone wrote: > Oh I know. Luckily it's located in an industrial area just on the > outskirts > of the city. There isn't a lot of other WiFi (in my opinion); 3-5 > total > SSIDs spread across 2 of the 3 physical channels (1,6,11) depending on > which > rooftop you measure from. 2.4 and 5GHz license-free Wifi is license free because the frequencies are shared with the ISM (Industrial/Scientific/Medical) services. In an industrial area, competing WiFi is the least of your worries. These frequencies are also used by industrial grade heating units. Got anyone in the neighbourhood running a large plastic shrink wrap machine, for example? You can't directly detect these other users with a Wifi transceiver. Depending on the nature of the interference you *might* be able to hear it directly on a scanner (if you can find one that covers those frequencies), but you really need a good spectrum analyzer to tell what's going on. Anyway, don't assume the competition for spectrum is only other Wifi units. --lyndon From chris.ledford at cnxntech.com Thu Jun 18 11:14:59 2009 From: chris.ledford at cnxntech.com (Chris Ledford) Date: Thu, 18 Jun 2009 12:14:59 -0400 Subject: NANOG Digest, Vol 17, Issue 51 Message-ID: <8FAEFABA9446514DAEE6CF984573D5F90142D46341C8@CORP-MAILBOX.capband.corp> Cisco aironet ...reliable and the ony way to go ... Chris ledford CCNA CCSP CWLSS ------Original Message------ From: nanog-request at nanog.org To: nanog at nanog.org ReplyTo: nanog at nanog.org Subject: NANOG Digest, Vol 17, Issue 51 Sent: Jun 18, 2009 9:23 AM Send NANOG mailing list submissions to nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Wireless bridge (Peter Boone) 2. Re: Wireless bridge (Jared Mauch) 3. Re: WISP NMS recommendations (Patrick Shoemaker) 4. Re: Wireless bridge (Joe Tyson) 5. Re: Wireless bridge (Chuck Anderson) 6. Re: Wireless bridge (Roy) 7. Re: Wireless bridge (Curtis Maurand) 8. Re: Wireless bridge (Joel Jaeggli) ---------------------------------------------------------------------- Message: 1 Date: Thu, 18 Jun 2009 09:05:56 -0400 From: "Peter Boone" Subject: Wireless bridge To: Message-ID: <005c01c9f015$852ae490$8f80adb0$@com> Content-Type: text/plain; charset="us-ascii" Hi NANOG, I'm looking for some equipment recommendations for a wireless bridge between two locations approximately 500-800 meters apart. The current setup for this company has been extremely unstable and slow. I don't have a lot of experience in this area so I was hoping someone could give me a few pointers. Currently, both locations are using Linksys WRT54GL's flashed with DD-WRT firmware (Yes, 802.11g. All extra bells and whistles are disabled in the firmware. They were set up for WDS so other wireless clients could connect to the same access point, with varying degrees of success. Not very important). They are connected to SmartAnt 2300-2500 MHz 14 dBi directional antenna mounted on the roof (extended pretty high for perfect line of sight). I'm not sure when they got these antenna exactly but I'm told it was when WiFi was very new. The network is very small so both locations share the same subnet (192.168.1.0/24). They have gone through numerous Linksys access points over the years. The wireless settings are tweaked as best as possible, and we have found the connection to be most stable when the TX is limited to 6-9 Mbps. We have explored other options as well. An internet connection at each location + VPN is out due to very slow upstream speeds (the buildings are in an industrial area, ADSL is the only option.) The max they offer on regular business accounts is 800 kbps up. T1 lines are even slower and even more expensive. They won't offer us any other solutions such as fibre. We have considered running fibre/coax but there is too much construction activity and other property in the way. I'm looking into RouterBOARD right now, considering a RB433AH and R52H wireless card, but I'm not sure this will actually solve the problem. It's difficult to determine if the issue is with the antennas or access points (for example, after a good thunderstorm, the wireless link will be down for at least 12 hours, but will fix itself eventually. Resetting either access point will keep the link down for at least 30 minutes. Using an airgun on the access points tends to make them more reliable, even if they are clean and dust free. From the admin interface, each access point will report seeing a very good and strong signal from the other, yet they refuse to communicate until they feel like it a few hours later.) Any suggestions welcome. I'm sure you can tell cost is a bit of a factor here but it will be easy for me to justify a higher price if I'm confident it will be effective. While I'm at it, I've been reading along on the list for over a year now; thanks everyone for sharing your real world experiences :) Peter ------------------------------ Message: 2 Date: Thu, 18 Jun 2009 09:18:24 -0400 From: Jared Mauch Subject: Re: Wireless bridge To: Peter Boone Cc: nanog at nanog.org Message-ID: <20090618131824.GA25957 at puck.nether.net> Content-Type: text/plain; charset=us-ascii On Thu, Jun 18, 2009 at 09:05:56AM -0400, Peter Boone wrote: > Hi NANOG, > > I'm looking for some equipment recommendations for a wireless bridge between > two locations approximately 500-800 meters apart. The current setup for this > company has been extremely unstable and slow. I don't have a lot of > experience in this area so I was hoping someone could give me a few > pointers. I've had good luck with Cisco Aironet gear running in repeater mode. I've done the cheap linksys thing as well and it just did not work as well as using some equipment that was better designed. I have actually found the non-IOS software on the aironet 350/340 to be more usable than the IOS software. You need to have your network be consistent. You also have the obvious interference challenges with any unlicensed deployment. - Jared some of the equipment i've used: http://cgi.ebay.com/5-Cisco-Aironet-350-WAPs-AP352E2R-A-K9_W0QQitemZ200351697798QQcmdZViewItemQQptZCOMP_EN_Routers?hash=item2ea5e44b86&_trksid=p3286.c0.m14&_trkparms=65%3A1|66%3A2|39%3A1|240%3A1318|301%3A1|293%3A1|294%3A50 http://cgi.ebay.com/Cisco-AIR-AP1121G-A-K9-Aironet-1100-1121-Access-Point_W0QQitemZ190313803887QQcmdZViewItemQQptZCOMP_EN_Routers?hash=item2c4f96306f&_trksid=p3286.c0.m14&_trkparms=65%3A1|66%3A2|39%3A1|240%3A1318|301%3A1|293%3A1|294%3A50 -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. ------------------------------ Message: 3 Date: Thu, 18 Jun 2009 09:21:56 -0400 From: Patrick Shoemaker Subject: Re: WISP NMS recommendations To: nanog at nanog.org Message-ID: <4A3A3F74.6060601 at vectordatasystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Although this would probably be better suited for one of the WISPA lists, I'll respond here anyhow since there seems to be some interest. For managing Canopy elements, Motorola Prizm is probably the way to go. First of all, you'll need it to handle element authentication for your PtMP system. It will also do configuration management, alerting, and all the usual NMS stuff. It's also *possible* to get it to work with other SNMP capable devices if you want to manage other vendors' equipment. It will work out of the box with the Canopy PtMP line, PtP devices, powerline carrier devices, and (I think) the MotoMESH line. It gives you all the info you need at a glance for each element: configuration history, RF power level plots, bandwidth utilization plots, alert history, etc. FYI if you haven't used it, Prizm is a pretty clunky and slow Java-based package. The features are nice, but configuring it can be a chore. Patrick Shoemaker Vector Data Systems LLC shoemakerp at vectordatasystems.com office: (301) 358-1690 x36 http://www.vectordatasystems.com nanog-request at nanog.org wrote: > Message: 5 > Date: Wed, 17 Jun 2009 21:31:29 -0700 > From: Freddie Sessler > Subject: WISP NMS recommendations > To: nanog at nanog.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Folks,I am looking for recommendations on an NMS system for use in > managing a multivendor ------Original Message Truncated------ From Tim at bobbroadband.com Thu Jun 18 11:27:28 2009 From: Tim at bobbroadband.com (Tim Huffman) Date: Thu, 18 Jun 2009 11:27:28 -0500 Subject: Wireless bridge In-Reply-To: <09ef01c9f02d$221f21f0$665d65d0$@com> References: <005c01c9f015$852ae490$8f80adb0$@com> <877585b00906180753s47617a64la780d7ac1f8c05ca@mail.gmail.com> <09ef01c9f02d$221f21f0$665d65d0$@com> Message-ID: > The line of sight is all clear, no trees. Only one building along the way > has a rooftop of similar height, but the antennas are extended far above > the > roofline. We have used a rifle scope to confirm line of sight is all clear > at all angles. > Unfortunately, you can't necessarily rely on visual line of sight. At 800meters, the Fresnel Zone on your radio is about 14ft in diameter at the midpoint. You need to make sure that this is free of obstructions. > Oh I know. Luckily it's located in an industrial area just on the > outskirts > of the city. There isn't a lot of other WiFi (in my opinion); 3-5 total > SSIDs spread across 2 of the 3 physical channels (1,6,11) depending on > which > rooftop you measure from. > Make sure you're using the channel that doesn't have an AP on it! > > Bandwidth requirements aren't too picky. If it can handle minimum 9 Mbps > full-duplex everyone will be happy. Of course, the faster the better. > I don't know if it makes a difference or not but this is all taking place > in > Canada. I don't know of any regulations drastically different from the > U.S's > regarding frequency use here. The biggest problem I've ever had though has > just been payment/shipping depending on the supplier (some don't ship to > Canada or are very specific about payment methods!). Canadian and US regulations are very similar in the unlicensed bands. I'd still pick 5.2GHz if you were replacing the radio. > > > Just to answer a few more questions I've been getting, the access points > are > located inside, connected to a small UPS. The antenna wire is a very thick > coax up to the roof, BNC connectors to the access point and I'm fairly > certain BNC connectors on the antenna end as well. I'll double check > grounding on the poles but I'm somewhat afraid to turn it into a lightning > rod. I'm fairly certain that the ground in the antenna wire is clean but > again, something to double check. How long is your cable run, and what kind of cable is it? It's probably LMR-400 (the most common) loses about 6.6dB of your signal for every 100 feet. Also, you should check the waterproofing on the connector at the antenna. We normally use a 'courtesy wrap' of electrical tape, followed by a thick layer of Mastic tape, followed by another layer of electrical tape. Also, check your cable for nicks or kinks. > > Rain/moisture doesn't seem to cause problems. In fact the connection is > more > reliable through the winter. The last 2 months here have been cold/warm, > dry/wet and there's been no pattern to the stability issues. The only > correlation between weather and stability that they have noticed there is > lightning related. Moisture in the cables doesn't necessarily show up during rain! That moisture can seep throughout the cable, and cause attenuation when it gets cool and the moisture condenses, for example. You haven't said what kind of antennas you are using, but if they are yagi's, they probably have very poor back-to-front ratios, which means that you could be picking up interference from behind you, or on the sides, especially if the antennas are up above the tree cover. You might try horizontal polarization on the antennas (just rotate them 90 degrees, but make sure you do it on BOTH sides!) to see if that helps. Cross-polarization is usually good for about 20dB of noise rejection. The fact that there doesn't seem to be any pattern to your loss means that it's probably either interference (somebody changing channels), hardware failure, or software failure. Hope this helps. -- Tim Huffman Director of Engineering Business Only Broadband, LLC O (630) 590-6012 C (630) 340-1925 tim at bobbroadband.com www.bobbroadband.com From ler762 at gmail.com Thu Jun 18 11:28:44 2009 From: ler762 at gmail.com (Lee) Date: Thu, 18 Jun 2009 12:28:44 -0400 Subject: Unicast Flooding In-Reply-To: <295271b90906180724y2d899d42x76809c255a6d449b@mail.gmail.com> References: <295271b90906171432h431f9867td53ded86f2a787f@mail.gmail.com> <483E6B0272B0284BA86D7596C40D29F9C381C142F5@PUR-EXCH07.ox.com> <485ED9BA02629E4BBBA53AC892EDA50E09237370@usmsxt104.mwd.h2o> <4A39A8EE.7080603@kingrst.com> <295271b90906180724y2d899d42x76809c255a6d449b@mail.gmail.com> Message-ID: On 6/18/09, Brian Shope wrote: > Thanks for all the good info.. > > So it sounds like changing my CAM timeout to 4 hours is the best > suggestion. Anyone have any problems when implementing this? Not as long as all the user ports have portfast enabled. Without portfast, when a port goes up or down it causes a topology change notification which sets the fast aging timer and the cam table entries age out in something like 15 seconds. Regards, Lee From john at vanoppen.com Thu Jun 18 11:34:19 2009 From: john at vanoppen.com (John van Oppen) Date: Thu, 18 Jun 2009 09:34:19 -0700 Subject: Wireless bridge References: <005c01c9f015$852ae490$8f80adb0$@com><877585b00906180753s47617a64la780d7ac1f8c05ca@mail.gmail.com><09ef01c9f02d$221f21f0$665d65d0$@com> Message-ID: To come up with an accurate recommendation one really needs to know your budget, on that distance speeds up to 1 gbit/sec are possible if you spend enough on the radios... Do you have some cost and desired throughput parameters to guide everyone's recommendations? -----Original Message----- From: Tim Huffman [mailto:Tim at bobbroadband.com] Sent: Thursday, June 18, 2009 9:27 AM To: nanog at nanog.org Subject: RE: Wireless bridge > The line of sight is all clear, no trees. Only one building along the way > has a rooftop of similar height, but the antennas are extended far above > the > roofline. We have used a rifle scope to confirm line of sight is all clear > at all angles. > Unfortunately, you can't necessarily rely on visual line of sight. At 800meters, the Fresnel Zone on your radio is about 14ft in diameter at the midpoint. You need to make sure that this is free of obstructions. > Oh I know. Luckily it's located in an industrial area just on the > outskirts > of the city. There isn't a lot of other WiFi (in my opinion); 3-5 total > SSIDs spread across 2 of the 3 physical channels (1,6,11) depending on > which > rooftop you measure from. > Make sure you're using the channel that doesn't have an AP on it! > > Bandwidth requirements aren't too picky. If it can handle minimum 9 Mbps > full-duplex everyone will be happy. Of course, the faster the better. > I don't know if it makes a difference or not but this is all taking place > in > Canada. I don't know of any regulations drastically different from the > U.S's > regarding frequency use here. The biggest problem I've ever had though has > just been payment/shipping depending on the supplier (some don't ship to > Canada or are very specific about payment methods!). Canadian and US regulations are very similar in the unlicensed bands. I'd still pick 5.2GHz if you were replacing the radio. > > > Just to answer a few more questions I've been getting, the access points > are > located inside, connected to a small UPS. The antenna wire is a very thick > coax up to the roof, BNC connectors to the access point and I'm fairly > certain BNC connectors on the antenna end as well. I'll double check > grounding on the poles but I'm somewhat afraid to turn it into a lightning > rod. I'm fairly certain that the ground in the antenna wire is clean but > again, something to double check. How long is your cable run, and what kind of cable is it? It's probably LMR-400 (the most common) loses about 6.6dB of your signal for every 100 feet. Also, you should check the waterproofing on the connector at the antenna. We normally use a 'courtesy wrap' of electrical tape, followed by a thick layer of Mastic tape, followed by another layer of electrical tape. Also, check your cable for nicks or kinks. > > Rain/moisture doesn't seem to cause problems. In fact the connection is > more > reliable through the winter. The last 2 months here have been cold/warm, > dry/wet and there's been no pattern to the stability issues. The only > correlation between weather and stability that they have noticed there is > lightning related. Moisture in the cables doesn't necessarily show up during rain! That moisture can seep throughout the cable, and cause attenuation when it gets cool and the moisture condenses, for example. You haven't said what kind of antennas you are using, but if they are yagi's, they probably have very poor back-to-front ratios, which means that you could be picking up interference from behind you, or on the sides, especially if the antennas are up above the tree cover. You might try horizontal polarization on the antennas (just rotate them 90 degrees, but make sure you do it on BOTH sides!) to see if that helps. Cross-polarization is usually good for about 20dB of noise rejection. The fact that there doesn't seem to be any pattern to your loss means that it's probably either interference (somebody changing channels), hardware failure, or software failure. Hope this helps. -- Tim Huffman Director of Engineering Business Only Broadband, LLC O (630) 590-6012 C (630) 340-1925 tim at bobbroadband.com www.bobbroadband.com From NANOG at Aquillar.com Thu Jun 18 11:38:00 2009 From: NANOG at Aquillar.com (Peter Boone) Date: Thu, 18 Jun 2009 12:38:00 -0400 Subject: Wireless bridge In-Reply-To: <1245341463.1310.22.camel@legolas.orthanc.ca> References: <005c01c9f015$852ae490$8f80adb0$@com> <877585b00906180753s47617a64la780d7ac1f8c05ca@mail.gmail.com> <09ef01c9f02d$221f21f0$665d65d0$@com> <1245341463.1310.22.camel@legolas.orthanc.ca> Message-ID: <0e9401c9f033$24f4a160$6edde420$@com> > -----Original Message----- > From: Lyndon Nerenberg [mailto:lyndon at orthanc.ca] > Sent: June 18, 2009 12:11 PM > To: Peter Boone > Cc: nanog at nanog.org > Subject: RE: Wireless bridge > > On Thu, 2009-06-18 at 11:54 -0400, Peter Boone wrote: > > Oh I know. Luckily it's located in an industrial area just on the > > outskirts > > of the city. There isn't a lot of other WiFi (in my opinion); 3-5 > > total > > SSIDs spread across 2 of the 3 physical channels (1,6,11) depending > on > > which > > rooftop you measure from. > > 2.4 and 5GHz license-free Wifi is license free because the frequencies > are shared with the ISM (Industrial/Scientific/Medical) services. In an > industrial area, competing WiFi is the least of your worries. These > frequencies are also used by industrial grade heating units. Got anyone > in the neighbourhood running a large plastic shrink wrap machine, for > example? Within range of the beam, not that I know of. The biggest building is just a supplier, there's 2 other small buildings, not 100% sure what they do though. > You can't directly detect these other users with a Wifi transceiver. > Depending on the nature of the interference you *might* be able to hear > it directly on a scanner (if you can find one that covers those > frequencies), but you really need a good spectrum analyzer to tell > what's going on. > > Anyway, don't assume the competition for spectrum is only other Wifi > units. > > --lyndon I don't have a spectrum analyzer available to me (I've found a USB one for $200 designed for WiFi that will pick up any non-wifi noise around the frequency range too). Each access point reports a good signal. From what I recall (not on site today) the noise is very minimal. Noise anywhere from -98 to -85 with the signal at -20 to -40. The SNR is 30+, even when the connection isn't working. The DDWRT firmware reports a Signal Quality as a percentage as well: it's generally high, 80%+ (not sure exactly how it's calculated though, I've seen it fluctuate while the Signal and Noise remain about the same). These readings are consistent at both access points, and remain about the same on each of the 3 physical channels. Hard to tell for sure since the firmware doesn't keep any averages or historical statistics on the signals, and no one has the time to sit around and take a reading every few minutes. Peter From jay at west.net Thu Jun 18 11:51:15 2009 From: jay at west.net (Jay Hennigan) Date: Thu, 18 Jun 2009 09:51:15 -0700 Subject: Wireless bridge In-Reply-To: References: <005c01c9f015$852ae490$8f80adb0$@com> Message-ID: <4A3A7083.8090406@west.net> Jason Gurtz wrote: > Are you sure there's not a moisture problem in the antennae cabling? Get > an SWR meter that can handle the 2.4 GHz range and make sure that SWR is > very low (approaching 1:1 but certainly less than 2:1). Hook up the meter > in-line at the AP. Test this after everything is wet and again when > there's been a dry spell. Minimize the number of exposed connections and > use dielectric grease. Use dielectric grease sparingly on the outer threads of the connector. Don't let it get in contact with the inside where it bridges the center pin and the shield. This will cause nasty impedance bumps. The inside of the connector should be dry. The grease on the threads helps to ensure this. > Any exposed connections should be well wrapped > with that rubberized electricians tape first, then with regular. Yep, the stretchy stuff. 3M type 23. -- 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 joelja at bogus.com Thu Jun 18 12:10:22 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 18 Jun 2009 10:10:22 -0700 Subject: Wireless bridge In-Reply-To: <4A3A7083.8090406@west.net> References: <005c01c9f015$852ae490$8f80adb0$@com> <4A3A7083.8090406@west.net> Message-ID: <4A3A74FE.9000403@bogus.com> > Jason Gurtz wrote: > >> Are you sure there's not a moisture problem in the antennae cabling? Get >> an SWR meter that can handle the 2.4 GHz range and make sure that SWR is >> very low (approaching 1:1 but certainly less than 2:1). Hook up the >> meter >> in-line at the AP. Test this after everything is wet and again when >> there's been a dry spell. Minimize the number of exposed connections and >> use dielectric grease. Alternatively using an antenna with integrated ap like the one's I referred to previously (they have a nice cast enclosure for radio and a screw down bulkhead with gasket for the cable) eliminates the need for runs of rf coax at all and also deals handily with the necessity for an outdoor enclosure for the linksys ap. I would use outdoor rated cat-5 for the run up to the ap. From bonomi at mail.r-bonomi.com Thu Jun 18 13:08:06 2009 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Thu, 18 Jun 2009 13:08:06 -0500 (CDT) Subject: spamhaus drop list Message-ID: <200906181808.n5II86QK007524@mail.r-bonomi.com> > Date: Tue, 16 Jun 2009 19:49:36 -0400 > From: Bret Clark > Subject: Re: spamhaus drop list > > John Levine wrote: > > Not that I've ever seen. Nobody else has the breadth of data that > > Spamhaus does. > > > > I've been using it for ages and based on zero complaints, it's never > > blocked anything that any of my users wanted. > > > > R's, > > John > > I have to agree with this...I'm somewhat surprised to see some of the > comments here. Methinks "consider the source", when evaluating the 'meaningfulness' of the comlaints, goes a long way towards clarifying the situation. In -that- light, I'm really not all that 'surprised' at what shook loose from the belfry. From cmaurand at xyonet.com Thu Jun 18 12:13:17 2009 From: cmaurand at xyonet.com (Curtis Maurand) Date: Thu, 18 Jun 2009 13:13:17 -0400 Subject: Wireless bridge In-Reply-To: <1245341463.1310.22.camel@legolas.orthanc.ca> References: <005c01c9f015$852ae490$8f80adb0$@com> <877585b00906180753s47617a64la780d7ac1f8c05ca@mail.gmail.com> <09ef01c9f02d$221f21f0$665d65d0$@com> <1245341463.1310.22.camel@legolas.orthanc.ca> Message-ID: <4A3A75AD.8090508@xyonet.com> Lyndon Nerenberg wrote: > On Thu, 2009-06-18 at 11:54 -0400, Peter Boone wrote: > >> Oh I know. Luckily it's located in an industrial area just on the >> outskirts >> of the city. There isn't a lot of other WiFi (in my opinion); 3-5 >> total >> SSIDs spread across 2 of the 3 physical channels (1,6,11) depending on >> which >> rooftop you measure from. >> > > 2.4 and 5GHz license-free Wifi is license free because the frequencies > are shared with the ISM (Industrial/Scientific/Medical) services. In an > industrial area, competing WiFi is the least of your worries. These > frequencies are also used by industrial grade heating units. Got anyone > in the neighbourhood running a large plastic shrink wrap machine, for > example? > > Motion sensors also run in the 2.4GHz range. > You can't directly detect these other users with a Wifi transceiver. > Depending on the nature of the interference you *might* be able to hear > it directly on a scanner (if you can find one that covers those > frequencies), but you really need a good spectrum analyzer to tell > what's going on. > > Anyway, don't assume the competition for spectrum is only other Wifi > units. > > --lyndon > > > From charles at thewybles.com Thu Jun 18 12:13:12 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 18 Jun 2009 10:13:12 -0700 Subject: Wireless bridge In-Reply-To: <005c01c9f015$852ae490$8f80adb0$@com> References: <005c01c9f015$852ae490$8f80adb0$@com> Message-ID: <4A3A75A8.3020003@thewybles.com> Might I suggest Ubnt.com ? Or a vendor that I use.... http://www.wlanparts.com/category/ubiquiti/ Couple of these http://www.wlanparts.com/product/BULLET2-D13/Ubiquiti_BULLET2_and_13dBi_24GHz_Panel_Antenna__BULLET2D13.html (100.00 per side or so). Peter Boone wrote: > Hi NANOG, > > I'm looking for some equipment recommendations for a wireless bridge between > two locations approximately 500-800 meters apart. The current setup for this > company has been extremely unstable and slow. I don't have a lot of > experience in this area so I was hoping someone could give me a few > pointers. > > Currently, both locations are using Linksys WRT54GL's flashed with DD-WRT > firmware (Yes, 802.11g. All extra bells and whistles are disabled in the > firmware. They were set up for WDS so other wireless clients could connect > to the same access point, with varying degrees of success. Not very > important). They are connected to SmartAnt 2300-2500 MHz 14 dBi directional > antenna mounted on the roof (extended pretty high for perfect line of > sight). I'm not sure when they got these antenna exactly but I'm told it was > when WiFi was very new. The network is very small so both locations share > the same subnet (192.168.1.0/24). > > They have gone through numerous Linksys access points over the years. The > wireless settings are tweaked as best as possible, and we have found the > connection to be most stable when the TX is limited to 6-9 Mbps. > > We have explored other options as well. An internet connection at each > location + VPN is out due to very slow upstream speeds (the buildings are in > an industrial area, ADSL is the only option.) The max they offer on regular > business accounts is 800 kbps up. T1 lines are even slower and even more > expensive. They won't offer us any other solutions such as fibre. We have > considered running fibre/coax but there is too much construction activity > and other property in the way. > > I'm looking into RouterBOARD right now, considering a RB433AH and R52H > wireless card, but I'm not sure this will actually solve the problem. It's > difficult to determine if the issue is with the antennas or access points > (for example, after a good thunderstorm, the wireless link will be down for > at least 12 hours, but will fix itself eventually. Resetting either access > point will keep the link down for at least 30 minutes. Using an airgun on > the access points tends to make them more reliable, even if they are clean > and dust free. From the admin interface, each access point will report > seeing a very good and strong signal from the other, yet they refuse to > communicate until they feel like it a few hours later.) > > Any suggestions welcome. I'm sure you can tell cost is a bit of a factor > here but it will be easy for me to justify a higher price if I'm confident > it will be effective. > > While I'm at it, I've been reading along on the list for over a year now; > thanks everyone for sharing your real world experiences :) > > Peter > > From charles at thewybles.com Thu Jun 18 12:15:11 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 18 Jun 2009 10:15:11 -0700 Subject: Wireless bridge In-Reply-To: <4A3A4DEB.6030605@bogus.com> References: <005c01c9f015$852ae490$8f80adb0$@com> <4A3A4DEB.6030605@bogus.com> Message-ID: <4A3A761F.3080809@thewybles.com> +1 for Ubnt gear! Joel Jaeggli wrote: > Pair of Ubuquiti power station 2 or 5 bridges, 5 would be preferable, > under $200 per end. > > http://www.ubnt.com/downloads/ps5_datasheet.pdf > > Peter Boone wrote: From charles at thewybles.com Thu Jun 18 12:16:20 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 18 Jun 2009 10:16:20 -0700 Subject: Wireless bridge In-Reply-To: <1245341463.1310.22.camel@legolas.orthanc.ca> References: <005c01c9f015$852ae490$8f80adb0$@com> <877585b00906180753s47617a64la780d7ac1f8c05ca@mail.gmail.com> <09ef01c9f02d$221f21f0$665d65d0$@com> <1245341463.1310.22.camel@legolas.orthanc.ca> Message-ID: <4A3A7664.60202@thewybles.com> > > 2.4 and 5GHz license-free Wifi is license free because the frequencies > are shared with the ISM (Industrial/Scientific/Medical) services. In an > industrial area, competing WiFi is the least of your worries. These > frequencies are also used by industrial grade heating units. Got anyone > in the neighbourhood running a large plastic shrink wrap machine, for > example? Good point. > > You can't directly detect these other users with a Wifi transceiver. > Depending on the nature of the interference you *might* be able to hear > it directly on a scanner (if you can find one that covers those > frequencies), but you really need a good spectrum analyzer to tell > what's going on. Check out http://www.ubnt.com/airview/ for a decent one. There is also wispy. From charles at thewybles.com Thu Jun 18 12:23:59 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 18 Jun 2009 10:23:59 -0700 Subject: WISP NMS recommendations In-Reply-To: <05E4479449414F28BBAFF7603BBE7C9B@DELL16> References: <05E4479449414F28BBAFF7603BBE7C9B@DELL16> Message-ID: <4A3A782F.5060704@thewybles.com> > > This list is quite active: > > http://lists.wispa.org/mailman/listinfo/wireless > > +1 for Wispa. Several knowledgeable people on there, and it's quite active. Lately both NANOG and WISPA have had very high signal. Hopefully it keeps up! :) From neil at tonal.clara.co.uk Thu Jun 18 12:28:12 2009 From: neil at tonal.clara.co.uk (Neil Harris) Date: Thu, 18 Jun 2009 18:28:12 +0100 Subject: Wireless bridge In-Reply-To: <09ef01c9f02d$221f21f0$665d65d0$@com> References: <005c01c9f015$852ae490$8f80adb0$@com> <877585b00906180753s47617a64la780d7ac1f8c05ca@mail.gmail.com> <09ef01c9f02d$221f21f0$665d65d0$@com> Message-ID: <4A3A792C.6080502@tonal.clara.co.uk> Peter Boone wrote: >> From: Michael Dillon [mailto:wavetossed at googlemail.com] >> >>> (for example, after a good thunderstorm, the wireless link will be >>> >> down for >> >>> at least 12 hours, but will fix itself eventually. >>> >> Sounds like there are trees in the line of sight, and maybe they are >> getting >> leafier over the years. The only solution to that is to change the path >> if >> it is possible. >> > > The line of sight is all clear, no trees. Only one building along the way > has a rooftop of similar height, but the antennas are extended far above the > roofline. We have used a rifle scope to confirm line of sight is all clear > at all angles. > > Given that you have optical line of sight, and that your path length is only 800m, have you considered line-of-sight optical links for this application? -- Neil From rekordmeister at gmail.com Thu Jun 18 12:44:52 2009 From: rekordmeister at gmail.com (MKS) Date: Thu, 18 Jun 2009 17:44:52 +0000 Subject: tire 1 in Montreal Message-ID: Hi List I'm looking for two tier 1 providers in Montreal, with independent fiber runs to the city.Which operator fit this criteria? Thanks in advance //MKS From nuno.vieira at nfsi.pt Thu Jun 18 12:42:25 2009 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Thu, 18 Jun 2009 18:42:25 +0100 (WEST) Subject: tire 1 in Montreal In-Reply-To: Message-ID: <1736667212.68931245346945417.JavaMail.root@zimbra.nfsi.pt> check TATA Communications (former Teleglobe). regards, --nvieira ----- "MKS" wrote: > Hi List > > I'm looking for two tier 1 providers in Montreal, with independent > fiber runs to the city.Which operator fit this criteria? > > Thanks in advance > //MKS From shoemakerp at vectordatasystems.com Thu Jun 18 12:55:28 2009 From: shoemakerp at vectordatasystems.com (Patrick Shoemaker) Date: Thu, 18 Jun 2009 13:55:28 -0400 Subject: Wireless bridge In-Reply-To: References: Message-ID: <4A3A7F90.6060707@vectordatasystems.com> Couple of comments: Regarding ISM spectrum sharing: the 2.4 GHZ band (2400-2500 MHz) and the 5.8 GHz (5725-5875 MHz) are certainly shared with ISM devices- microwave ovens, induction heaters, etc. However, the 5.2 and 5.4 GHz unlicensed bands (UNII) are not shared with ISM devices. However, these bands are subject to FCC regulations that mandate radar sensing and avoidance. This means that if your radios detect the signature of a military radar system on their active channel, they will automatically shut down and begin a waiting period before switching to another channel. Mandatory 60 second outage. There are generally three classes of point-to-point high speed unlicensed data radio gear out there today: 1. Wi-fi based gear with some additional hardware and a user interface suitable for point-to-point use. Ubiquiti, Tranzeo, HGA, etc. Pretty self-explanatory. Sub-1000 range. 2. Gear using a wi-fi chipeset (Atheros, Broadcom, etc.) with a proprietary firmware load. Trango, Alvarion, Ligowave, etc. $2000-5000 range. 3. Gear using a custom designed RF interface. Motorola, Dragonwave, etc. Given your requirements, I'd encourage you to look at classes 2 and 3. Getting any decent amount of reliability from vanilla 802.11 equipment is (as you've found) difficult. Gear in categories 2 and 3 from above will generally have a built in spectrum analyzer of some sort that will be able to see interference not caused by 802.11 devices, performance monitoring systems (BER reporting, event logs, etc), SNMP capability, etc. Definitely choose a system with an integrated antenna. You want a directional antenna such as a patch array (panel) integrated with the radio. Messing around with RF cabling, connectors, etc. is not necessary with what you're trying to do. Minimize the potential points of failure. Lightning protection is a concern. Most of this gear is PoE powered, so you'll have a single cat-5 going to the roof. Make sure it's protected with an Ethernet surge suppressor that is properly grounded. Follow the radio manufacturer's recommendations here. Your antenna mount must also be grounded according to NEC requirements. The Motorola PTP400 series radio that was recommended is one of the best unlicensed point to point radios out there. However, it's been EOL'd and replaced by the PTP500. Seems like these are both out of your budget, though. As an alternative, you might consider looking at the Trango TLink45. This radio uses a proprietary firmware and an Atheros WiFi chipset. It has a rudimentary spectrum analyzer, SNMP, ARQ (important), and adaptive rate modulation. It also has a dual-polarity software switchable antenna. This greatly increases your ability to avoid interference. It will run in the 5.3, 5.4, or 5.8 GHz unlicensed bands. They retail at about $4000 for a pair, but Trango routinely runs specials. They were on special for $1700 per pair in April. The WISPA list is a great resource for help with projects like this. Patrick Shoemaker Vector Data Systems LLC shoemakerp at vectordatasystems.com office: (301) 358-1690 x36 http://www.vectordatasystems.com > Message: 6 > Date: Thu, 18 Jun 2009 13:13:17 -0400 > From: Curtis Maurand > Subject: Re: Wireless bridge > To: Lyndon Nerenberg > Cc: nanog at nanog.org, Peter Boone > Message-ID: <4A3A75AD.8090508 at xyonet.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Lyndon Nerenberg wrote: >> > On Thu, 2009-06-18 at 11:54 -0400, Peter Boone wrote: >> > >>> >> Oh I know. Luckily it's located in an industrial area just on the >>> >> outskirts >>> >> of the city. There isn't a lot of other WiFi (in my opinion); 3-5 >>> >> total >>> >> SSIDs spread across 2 of the 3 physical channels (1,6,11) depending on >>> >> which >>> >> rooftop you measure from. >>> >> >> > >> > 2.4 and 5GHz license-free Wifi is license free because the frequencies >> > are shared with the ISM (Industrial/Scientific/Medical) services. In an >> > industrial area, competing WiFi is the least of your worries. These >> > frequencies are also used by industrial grade heating units. Got anyone >> > in the neighbourhood running a large plastic shrink wrap machine, for >> > example? >> > >> > > > Motion sensors also run in the 2.4GHz range. > >> > You can't directly detect these other users with a Wifi transceiver. >> > Depending on the nature of the interference you *might* be able to hear >> > it directly on a scanner (if you can find one that covers those >> > frequencies), but you really need a good spectrum analyzer to tell >> > what's going on. >> > >> > Anyway, don't assume the competition for spectrum is only other Wifi >> > units. >> > >> > --lyndon >> > >> > >> > From bclark at spectraaccess.com Thu Jun 18 12:56:52 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Thu, 18 Jun 2009 13:56:52 -0400 Subject: Wireless bridge In-Reply-To: References: <005c01c9f015$852ae490$8f80adb0$@com> <877585b00906180753s47617a64la780d7ac1f8c05ca@mail.gmail.com> <09ef01c9f02d$221f21f0$665d65d0$@com> Message-ID: <1245347812.22295.1.camel@acer-laptop> On Thu, 2009-06-18 at 09:34 -0700, John van Oppen wrote: > -----Original Message----- > From: Tim Huffman [mailto:Tim at bobbroadband.com] > Sent: Thursday, June 18, 2009 9:27 AM > To: nanog at nanog.org > Subject: RE: Wireless bridge > > > The line of sight is all clear, no trees. Only one building along > the > way > > has a rooftop of similar height, but the antennas are extended far > above > > the > > roofline. We have used a rifle scope to confirm line of sight is all > clear > > at all angles. > > > > Unfortunately, you can't necessarily rely on visual line of sight. At > 800meters, the Fresnel Zone on your radio is about 14ft in diameter at > the midpoint. You need to make sure that this is free of obstructions. > Not only that, the radios may actually be screaming at each other at those distances which will affect performance From skhosla at neutraldata.com Thu Jun 18 13:31:39 2009 From: skhosla at neutraldata.com (Sameer Khosla) Date: Thu, 18 Jun 2009 14:31:39 -0400 Subject: Telephones for Noisy Data Centers In-Reply-To: <1245288718.6350.516.camel@mike-desktop> References: <1245288718.6350.516.camel@mike-desktop> Message-ID: <3CDAFF22BE6DAF43B7EA263F6707D2892195D1@mail.neutraldata.com> I use the Peltor Bluetooth headset in our datacenter. Works better than most earplugs for noise attenuation, plus as a cell phone headset it has the noise cancelling microphone. The construction quality is really good, it could be used on a construction site without issues. I highly recommend it. http://www.peltor.se/int/Product.asp?PageNumber=144&ProductCategory_Id=9 &Product_Id=25 Thanks Sameer Khosla Managing Director Neutral Data Centers Corp. 416 682 3434 x5002 (w) 416 682 3435 (f) -----Original Message----- From: Michael J McCafferty [mailto:mike at m5computersecurity.com] Sent: Wednesday, June 17, 2009 9:32 PM To: nanog Subject: Telephones for Noisy Data Centers All, I'd be OK if we were in a facility that was only average in terms of noise, but we are not. I need an exceptional phone for the data center. Something that doesn't transmit the horrible background noise to the other end, and something that is loud without being painful for the user of this phone. Cordless would be very fine, headset is excellent. Ordinary desk phone is OK... but the most important thing is that it works for clear communication. A loud ringer would great too... but if the best phone doesn't have one, I'll get an auxiliary ringer. Does anyone have a phone model that they find to be excellent in a louder than usual data center? 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 sking at kingrst.com Thu Jun 18 13:45:45 2009 From: sking at kingrst.com (Steven King) Date: Thu, 18 Jun 2009 14:45:45 -0400 Subject: Unicast Flooding In-Reply-To: References: <295271b90906171432h431f9867td53ded86f2a787f@mail.gmail.com> <483E6B0272B0284BA86D7596C40D29F9C381C142F5@PUR-EXCH07.ox.com> <485ED9BA02629E4BBBA53AC892EDA50E09237370@usmsxt104.mwd.h2o> <4A39A8EE.7080603@kingrst.com> <295271b90906180724y2d899d42x76809c255a6d449b@mail.gmail.com> Message-ID: <4A3A8B59.1030400@kingrst.com> Relying on a TCN would yield very inconsistent results. Lee wrote: > On 6/18/09, Brian Shope wrote: > >> Thanks for all the good info.. >> >> So it sounds like changing my CAM timeout to 4 hours is the best >> suggestion. Anyone have any problems when implementing this? >> > > Not as long as all the user ports have portfast enabled. Without > portfast, when a port goes up or down it causes a topology change > notification which sets the fast aging timer and the cam table entries > age out in something like 15 seconds. > > Regards, > Lee > > -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From eric at roxanne.org Thu Jun 18 13:53:35 2009 From: eric at roxanne.org (Eric Gauthier) Date: Thu, 18 Jun 2009 14:53:35 -0400 Subject: Unicast Flooding In-Reply-To: <295271b90906171432h431f9867td53ded86f2a787f@mail.gmail.com> References: <295271b90906171432h431f9867td53ded86f2a787f@mail.gmail.com> Message-ID: <20090618185335.GA8126@roxanne.org> Brian, > The first is preventing it in the first place. As annoying as this might sound, this is one of the standard operating modes for load balancing within a Microsoft server cluster (see NLB). We've tried to avoid it, but it seems to come up around once a year from someone on our campus... Eric :) From zhiyunq at umich.edu Thu Jun 18 14:36:44 2009 From: zhiyunq at umich.edu (Zhiyun Qian) Date: Thu, 18 Jun 2009 15:36:44 -0400 Subject: Is your ISP blocking outgoing port 25? Message-ID: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> It has been long heard that many ISPs block outgoing port 25 for the purpose of reducing spam originated from their network. I wonder which ISPs are still doing so. I know comcast has been doing that but they cancelled it after many complaints. It seems to be the same case for Verizon. AT&T is the major one that I know of that is still enforcing this policy. But they said they can unblock port 25 upon request. I am not sure how easy it is. One simple way to test if your ISP is blocking outgoing port 25 is to try: "telnet mx2.hotmail.com 25" or "telnet gmail-smtp-in.l.google.com 25". If the connection fails, it could be due to the fact your ISP is blocking outgoing port 25, although it can also be other reasons such as local firewall configuration. Can someone perform the test and let me know result if possible? Thanks a lot! Regards. -Zhiyun From m.hallgren at free.fr Thu Jun 18 14:35:53 2009 From: m.hallgren at free.fr (Michael Hallgren) Date: Thu, 18 Jun 2009 21:35:53 +0200 Subject: question about Mark Koster's ARIN presentation In-Reply-To: <20090618160520.93FEE3F476@pecan.tislabs.com> References: <20090618160520.93FEE3F476@pecan.tislabs.com> Message-ID: <1245353753.5611.11.camel@home> Le jeudi 18 juin 2009 ? 12:05 -0400, Sandy Murphy a ?crit : > This message is sent to the whole nanog list, rather than the > nanog-attendees list, How come there is a nanog-attendees list disjunct from the nanog list. Wouldn't it be natural to broadcast any kind of content to the entire community? Cheers, mh > as I'm not sure who would be watching that > list when the conference is over. > > I stood up to ask a question at the end of Mark Koster's presentation > yesterday, but before I got to the end of the table, he was being applauded > and leaving the stage. I must be too short. > > The presentation said that ARIN would be doing a lot of work to > improve the IRR. The last I asked, the ARIN IRR did not support the > RPSS (Routing Policy System Security - RFC2725). RIPE supports this, > I know. Will the ARIN improvements include support for RPSS? Interesting, yes. > > The presentation talked about the RPKI pilot, and Mark said that > ARIN would be using the RIPE code. I believe RIPE has or had a couple > different attempts at this, so I'm not sure what features the code > you use will have. Will you have the ability to hand certs to ISPs > so that they can do their own cert generation for the allocations > they hand to their own customers? I.e., is ARIN going to run a > service just for its members, or will it enable its members to > participate in the RPKI themselves? > As well. > --Sandy > mh -- michael hallgren, mh2198-ripe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pstewart at nexicomgroup.net Thu Jun 18 14:38:20 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Thu, 18 Jun 2009 15:38:20 -0400 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> References: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> Message-ID: We still do it and never get any complaints - we don't filter static IP customers but dynamic customers can either use our SMTP relays or alternate ports.... Paul -----Original Message----- From: Zhiyun Qian [mailto:zhiyunq at umich.edu] Sent: Thursday, June 18, 2009 3:37 PM To: nanog at nanog.org Subject: Is your ISP blocking outgoing port 25? It has been long heard that many ISPs block outgoing port 25 for the purpose of reducing spam originated from their network. I wonder which ISPs are still doing so. I know comcast has been doing that but they cancelled it after many complaints. It seems to be the same case for Verizon. AT&T is the major one that I know of that is still enforcing this policy. But they said they can unblock port 25 upon request. I am not sure how easy it is. One simple way to test if your ISP is blocking outgoing port 25 is to try: "telnet mx2.hotmail.com 25" or "telnet gmail-smtp-in.l.google.com 25". If the connection fails, it could be due to the fact your ISP is blocking outgoing port 25, although it can also be other reasons such as local firewall configuration. Can someone perform the test and let me know result if possible? Thanks a lot! Regards. -Zhiyun ---------------------------------------------------------------------------- "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 Valdis.Kletnieks at vt.edu Thu Jun 18 14:49:39 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 18 Jun 2009 15:49:39 -0400 Subject: question about Mark Koster's ARIN presentation In-Reply-To: Your message of "Thu, 18 Jun 2009 21:35:53 +0200." <1245353753.5611.11.camel@home> References: <20090618160520.93FEE3F476@pecan.tislabs.com> <1245353753.5611.11.camel@home> Message-ID: <53090.1245354579@turing-police.cc.vt.edu> On Thu, 18 Jun 2009 21:35:53 +0200, Michael Hallgren said: > How come there is a nanog-attendees list disjunct from the nanog list. > Wouldn't it be natural to broadcast any kind of content to the > entire community? Umm... "Presentation XYZ has been moved from the Blue Room to the Paisley Room" and similar administrivia of interest only to actual attendees? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From kris.foster at gmail.com Thu Jun 18 14:51:31 2009 From: kris.foster at gmail.com (kris foster) Date: Thu, 18 Jun 2009 12:51:31 -0700 Subject: question about Mark Koster's ARIN presentation In-Reply-To: <1245353753.5611.11.camel@home> References: <20090618160520.93FEE3F476@pecan.tislabs.com> <1245353753.5611.11.camel@home> Message-ID: <587E1BBF-2C6E-4FBD-B290-F41E70879C6F@gmail.com> On Jun 18, 2009, at 12:35 PM, Michael Hallgren wrote: > Le jeudi 18 juin 2009 ? 12:05 -0400, Sandy Murphy a ?crit : >> This message is sent to the whole nanog list, rather than the >> nanog-attendees list, > > How come there is a nanog-attendees list disjunct from the nanog list. > Wouldn't it be natural to broadcast any kind of content to the > entire community? nanog-attendees is intended to be used for social and specific conference related topics. Topics discussed at the conference with operational relevance should be here on the main list. If anyone feels the need to follow up on the nanog-attendees/nanog distinction, please do so on nanog-futures. Thanks! Kris MLC Chair From charles at thewybles.com Thu Jun 18 14:52:45 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 18 Jun 2009 12:52:45 -0700 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> References: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> Message-ID: <4A3A9B0D.90001@thewybles.com> Zhiyun Qian wrote: > It has been long heard that many ISPs block outgoing port 25 for the purpose > of reducing spam originated from their network. > Well blocking or redirecting to there servers, which have an undocumented filtering policy. All one needs to do in order to bypass that is use a vpn. Something lightweight like n2n could be used by the bot herders of the world. I worked for a company that sent out several hundred thousand messages per day (an online card/invitations company). We ran spam assassian on our outbound farm, to prevent folks from using us to send spam. I presume the large service providers do the same. > > AT&T is the major one that I know of that is still enforcing this policy. > But they said they can unblock port 25 upon request. I am not sure how easy > it is. It's trivial. A web form. You get the link when you try to send mail to port 25 anywhere else. At least with Yahoo/SBC dsl. I got the business class DSL from AT&T and no such nonsense exists. From jcdill.lists at gmail.com Thu Jun 18 14:54:36 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 18 Jun 2009 12:54:36 -0700 Subject: question about Mark Koster's ARIN presentation In-Reply-To: <1245353753.5611.11.camel@home> References: <20090618160520.93FEE3F476@pecan.tislabs.com> <1245353753.5611.11.camel@home> Message-ID: <4A3A9B7C.4050307@gmail.com> Michael Hallgren wrote: > Le jeudi 18 juin 2009 ? 12:05 -0400, Sandy Murphy a ?crit : > >> This message is sent to the whole nanog list, rather than the >> nanog-attendees list, >> > > How come there is a nanog-attendees list disjunct from the nanog list. > Wouldn't it be natural to broadcast any kind of content to the > entire community? > > Before we had a nanog-attendees list, the nanog list would be bombarded with posts that were of no interest to people who weren't actually at the conference, such as issues with the conference wifi, issues with schedule conflicts, chatter about outside events in the host city, etc. It makes perfect sense to have a nanog-attendees list to keep those discussions off the main nanog list. I believe you can join the nanog attendees list without actually attending a nanog conference, if you want to get everything-nanog in your inbox. jc From charles at thewybles.com Thu Jun 18 14:55:09 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 18 Jun 2009 12:55:09 -0700 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: References: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> Message-ID: <4A3A9B9D.6010307@thewybles.com> Do you provide your users an SMTP server to use, with some out bound spam filtering? It would seem this is to be expected, as you don't want your IP ranges showing up on RBL filters. Do you force SSL connectivity like AT&T does? Paul Stewart wrote: > We still do it and never get any complaints - we don't filter static IP > customers but dynamic customers can either use our SMTP relays or > alternate ports.... > > Paul > > > -----Original Message----- > From: Zhiyun Qian [mailto:zhiyunq at umich.edu] > Sent: Thursday, June 18, 2009 3:37 PM > To: nanog at nanog.org > Subject: Is your ISP blocking outgoing port 25? > > It has been long heard that many ISPs block outgoing port 25 for the > purpose > of reducing spam originated from their network. > > I wonder which ISPs are still doing so. I know comcast has been doing > that > but they cancelled it after many complaints. It seems to be the same > case > for Verizon. > > AT&T is the major one that I know of that is still enforcing this > policy. > But they said they can unblock port 25 upon request. I am not sure how > easy > it is. > > One simple way to test if your ISP is blocking outgoing port 25 is to > try: > "telnet mx2.hotmail.com 25" or "telnet gmail-smtp-in.l.google.com 25". > If > the connection fails, it could be due to the fact your ISP is blocking > outgoing port 25, although it can also be other reasons such as local > firewall configuration. Can someone perform the test and let me know > result > if possible? Thanks a lot! > > Regards. > -Zhiyun > > > > > ---------------------------------------------------------------------------- > > "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 pstewart at nexicomgroup.net Thu Jun 18 15:04:25 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Thu, 18 Jun 2009 16:04:25 -0400 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: <4A3A9B9D.6010307@thewybles.com> References: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> <4A3A9B9D.6010307@thewybles.com> Message-ID: We don't force SSL but do have several SMTP servers they can use.... -----Original Message----- From: Charles Wyble [mailto:charles at thewybles.com] Sent: Thursday, June 18, 2009 3:55 PM To: NANOG list Subject: Re: Is your ISP blocking outgoing port 25? Do you provide your users an SMTP server to use, with some out bound spam filtering? It would seem this is to be expected, as you don't want your IP ranges showing up on RBL filters. Do you force SSL connectivity like AT&T does? Paul Stewart wrote: > We still do it and never get any complaints - we don't filter static IP > customers but dynamic customers can either use our SMTP relays or > alternate ports.... > > Paul > > > -----Original Message----- > From: Zhiyun Qian [mailto:zhiyunq at umich.edu] > Sent: Thursday, June 18, 2009 3:37 PM > To: nanog at nanog.org > Subject: Is your ISP blocking outgoing port 25? > > It has been long heard that many ISPs block outgoing port 25 for the > purpose > of reducing spam originated from their network. > > I wonder which ISPs are still doing so. I know comcast has been doing > that > but they cancelled it after many complaints. It seems to be the same > case > for Verizon. > > AT&T is the major one that I know of that is still enforcing this > policy. > But they said they can unblock port 25 upon request. I am not sure how > easy > it is. > > One simple way to test if your ISP is blocking outgoing port 25 is to > try: > "telnet mx2.hotmail.com 25" or "telnet gmail-smtp-in.l.google.com 25". > If > the connection fails, it could be due to the fact your ISP is blocking > outgoing port 25, although it can also be other reasons such as local > firewall configuration. Can someone perform the test and let me know > result > if possible? Thanks a lot! > > Regards. > -Zhiyun > > > > > ------------------------------------------------------------------------ ---- > > "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." > ---------------------------------------------------------------------------- "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 m.hallgren at free.fr Thu Jun 18 15:04:28 2009 From: m.hallgren at free.fr (Michael Hallgren) Date: Thu, 18 Jun 2009 22:04:28 +0200 Subject: question about Mark Koster's ARIN presentation In-Reply-To: <53090.1245354579@turing-police.cc.vt.edu> References: <20090618160520.93FEE3F476@pecan.tislabs.com> <1245353753.5611.11.camel@home> <53090.1245354579@turing-police.cc.vt.edu> Message-ID: <1245355468.5611.13.camel@home> Le jeudi 18 juin 2009 ? 15:49 -0400, Valdis.Kletnieks at vt.edu a ?crit : > On Thu, 18 Jun 2009 21:35:53 +0200, Michael Hallgren said: > > > How come there is a nanog-attendees list disjunct from the nanog list. > > Wouldn't it be natural to broadcast any kind of content to the > > entire community? > > Umm... "Presentation XYZ has been moved from the Blue Room to the Paisley Room" > and similar administrivia of interest only to actual attendees? OK. More info's good thing, better than less info... And we all know how to read and filter mail. Right? :) No harm, TTYS, mh -- michael hallgren, mh2198-ripe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From m.hallgren at free.fr Thu Jun 18 15:05:26 2009 From: m.hallgren at free.fr (Michael Hallgren) Date: Thu, 18 Jun 2009 22:05:26 +0200 Subject: question about Mark Koster's ARIN presentation In-Reply-To: <587E1BBF-2C6E-4FBD-B290-F41E70879C6F@gmail.com> References: <20090618160520.93FEE3F476@pecan.tislabs.com> <1245353753.5611.11.camel@home> <587E1BBF-2C6E-4FBD-B290-F41E70879C6F@gmail.com> Message-ID: <1245355526.5611.14.camel@home> Le jeudi 18 juin 2009 ? 12:51 -0700, kris foster a ?crit : > On Jun 18, 2009, at 12:35 PM, Michael Hallgren wrote: > > > Le jeudi 18 juin 2009 ? 12:05 -0400, Sandy Murphy a ?crit : > >> This message is sent to the whole nanog list, rather than the > >> nanog-attendees list, > > > > How come there is a nanog-attendees list disjunct from the nanog list. > > Wouldn't it be natural to broadcast any kind of content to the > > entire community? > > nanog-attendees is intended to be used for social and specific > conference related topics. Topics discussed at the conference with > operational relevance should be here on the main list. > > If anyone feels the need to follow up on the nanog-attendees/nanog > distinction, please do so on nanog-futures. > > Thanks! > > Kris > MLC Chair Thanks MLC Chair, so will be. mh -- michael hallgren, mh2198-ripe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nanog-post at rsuc.gweep.net Thu Jun 18 15:14:45 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Thu, 18 Jun 2009 16:14:45 -0400 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> References: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> Message-ID: <20090618201445.GA38466@gweep.net> On Thu, Jun 18, 2009 at 03:36:44PM -0400, Zhiyun Qian wrote: > It has been long heard that many ISPs block outgoing port 25 for the purpose > of reducing spam originated from their network. Yes, it is standard practice for non-server accounts and most dynamic-only accounts; only allow unauthenticated smtp traffic to your own smtp servers. If you are not running server-to-server traffic at the end of that broadband pipe, then you should be shifting your userbase to authenticated on the SUBMIT port [587] anyway... -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From johnl at iecc.com Thu Jun 18 15:18:49 2009 From: johnl at iecc.com (John Levine) Date: 18 Jun 2009 20:18:49 -0000 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> Message-ID: <20090618201849.7855.qmail@simone.iecc.com> >I wonder which ISPs are still doing so. I know comcast has been doing >that but they cancelled it after many complaints. It seems to be the >same case for Verizon. You're mistaken. Comcast most certainly does port 25 filtering, although not necessarily on every line at every moment. So does Verizon, AT&T, and every other large North American consumer ISP I know. Look, kids, it's not 1998 any more. These days outgoing traffic to port 25 is approximately 99.9% botnet spam, 0.1% GWL, and 0% legitimate mail. Blame the botnet herders and the vendors of cruddy software that year after year still is full of trivial exploits. If you can make the botnets go away, I will be happy to lead the charge to unblock all those ports. If it's important to you to have an unfiltered connection, pay for business service that has a static IP, or arrange to tunnel to some host that does. R's, John From lyndon at orthanc.ca Thu Jun 18 15:27:40 2009 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 18 Jun 2009 14:27:40 -0600 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: <20090618201445.GA38466@gweep.net> References: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> <20090618201445.GA38466@gweep.net> Message-ID: <1245356861.8442.6.camel@legolas.orthanc.ca> On Thu, 2009-06-18 at 16:14 -0400, Joe Provo wrote: > then you should be shifting your userbase to authenticated on the > SUBMIT > port [587] anyway... Except for those ISPs who choose to intercept port 587 as well. This is a big problem with Rogers in Vancouver. They hijack port 587 connections through some sort of lame proxy that connects you to your intended host, but strips the AUTH field out of the EHLO response from the remote submission server ... From jdfalk-lists at cybernothing.org Thu Jun 18 15:36:58 2009 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Thu, 18 Jun 2009 14:36:58 -0600 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: <20090618201445.GA38466@gweep.net> References: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> <20090618201445.GA38466@gweep.net> Message-ID: <4A3AA56A.1070906@cybernothing.org> Joe Provo wrote: > On Thu, Jun 18, 2009 at 03:36:44PM -0400, Zhiyun Qian wrote: >> It has been long heard that many ISPs block outgoing port 25 for the purpose >> of reducing spam originated from their network. > > Yes, it is standard practice for non-server accounts and most dynamic-only > accounts; only allow unauthenticated smtp traffic to your own smtp servers. > If you are not running server-to-server traffic at the end of that broadband > pipe, then you should be shifting your userbase to authenticated on the SUBMIT > port [587] anyway... The Messaging Anti-Abuse Working Group (MAAWG) published recommendations for managing port 25 traffic a few years ago, and even then it had already been a widely-accepted best practice for nearly a decade. http://www.maawg.org/port25 -- J.D. Falk Return Path Inc http://www.returnpath.net/ From morrowc.lists at gmail.com Thu Jun 18 16:01:01 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 18 Jun 2009 17:01:01 -0400 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: <1245356861.8442.6.camel@legolas.orthanc.ca> References: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> <20090618201445.GA38466@gweep.net> <1245356861.8442.6.camel@legolas.orthanc.ca> Message-ID: <75cb24520906181401r62ebf873u4f94433b9be28147@mail.gmail.com> On Thu, Jun 18, 2009 at 4:27 PM, Lyndon Nerenberg wrote: > On Thu, 2009-06-18 at 16:14 -0400, Joe Provo wrote: >> then you should be shifting your userbase to authenticated on the >> SUBMIT >> port [587] anyway... > > Except for those ISPs who choose to intercept port 587 as well. This is > a big problem with Rogers in Vancouver. They hijack port 587 connections port 26 FTW! in all seriousness, most isp's (consumer provider folk) today do some form of blocking of port 25, if you are 'smart' enough to evade this sort of thing, then you can still do email/blah. 99.999% of users are: 1) not interested in bypassing it 2) not clued into what's going on 3) using webmail Why is this debate still ongoing?? -Chris From cmadams at hiwaay.net Thu Jun 18 16:13:41 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 18 Jun 2009 16:13:41 -0500 Subject: Wireless bridge In-Reply-To: <09ef01c9f02d$221f21f0$665d65d0$@com> References: <005c01c9f015$852ae490$8f80adb0$@com> <877585b00906180753s47617a64la780d7ac1f8c05ca@mail.gmail.com> <09ef01c9f02d$221f21f0$665d65d0$@com> Message-ID: <20090618211341.GF793443@hiwaay.net> Once upon a time, Peter Boone said: > I'll double check > grounding on the poles but I'm somewhat afraid to turn it into a lightning > rod. If it is a high point on a roof, it is a lightning rod already. You ground the antenna and mount to give the lightning a better path to ground than running through your coax and equipment. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From sking at kingrst.com Thu Jun 18 16:30:19 2009 From: sking at kingrst.com (Steven King) Date: Thu, 18 Jun 2009 17:30:19 -0400 Subject: Unicast Flooding In-Reply-To: <20090618185335.GA8126@roxanne.org> References: <295271b90906171432h431f9867td53ded86f2a787f@mail.gmail.com> <20090618185335.GA8126@roxanne.org> Message-ID: <4A3AB1EB.40309@kingrst.com> Very true Eric. Microsoft even acknowledges the issue, and still has not fixed it. I have had a few customers use NLB and have this issue. Eric Gauthier wrote: > Brian, > > >> The first is preventing it in the first place. >> > > As annoying as this might sound, this is one of the > standard operating modes for load balancing within > a Microsoft server cluster (see NLB). We've tried > to avoid it, but it seems to come up around once a > year from someone on our campus... > > Eric :) > > -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From jbates at brightok.net Thu Jun 18 16:38:45 2009 From: jbates at brightok.net (Jack Bates) Date: Thu, 18 Jun 2009 16:38:45 -0500 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: <75cb24520906181401r62ebf873u4f94433b9be28147@mail.gmail.com> References: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> <20090618201445.GA38466@gweep.net> <1245356861.8442.6.camel@legolas.orthanc.ca> <75cb24520906181401r62ebf873u4f94433b9be28147@mail.gmail.com> Message-ID: <4A3AB3E5.8090801@brightok.net> Christopher Morrow wrote: > in all seriousness, most isp's (consumer provider folk) today do some > form of blocking of port 25, if you are 'smart' enough to evade this > sort of thing, then you can still do email/blah. 99.999% of users are: > 1) not interested in bypassing it > 2) not clued into what's going on > 3) using webmail > I'd say 0.5% of my customer base contacts the helpdesk to setup auth and bypass tcp/25 blocks using tcp/587. Another 2% use my webmail offsite, and about 10% use webmail only (on my network or off). Then there's those pesky gmail users. We should just block them. j/k :P > Why is this debate still ongoing?? > Because nanog is slow? Actually, I think the original poster was just curious as these days not much is said overly much outside of the "Die Spammer" threads in other venues. Jack From jarruda-gter at jarruda.com Thu Jun 18 16:49:56 2009 From: jarruda-gter at jarruda.com (Julio Arruda) Date: Thu, 18 Jun 2009 17:49:56 -0400 Subject: Unicast Flooding In-Reply-To: <4A3AB1EB.40309@kingrst.com> References: <295271b90906171432h431f9867td53ded86f2a787f@mail.gmail.com> <20090618185335.GA8126@roxanne.org> <4A3AB1EB.40309@kingrst.com> Message-ID: <4A3AB684.2090003@jarruda.com> Steven King wrote: > Very true Eric. Microsoft even acknowledges the issue, and still has not > fixed it. I have had a few customers use NLB and have this issue. > > Eric Gauthier wrote: >> Brian, >> >> >>> The first is preventing it in the first place. >>> >> As annoying as this might sound, this is one of the >> standard operating modes for load balancing within >> a Microsoft server cluster (see NLB). We've tried >> to avoid it, but it seems to come up around once a >> year from someone on our campus... >> >> Eric :) >> >> I understand is 'working as designed' ? Much like the Stonegate (?) Firewall redundancy trick ? It was a little worse when doing the multicast-l2 to a unicast-l3 address trick.. By the way, if you think this is funny in a campus ethernet backbone.. Try it in an old ATM/LANE environment..I had customer that had the chance to try it, and wanted a root cause analysis. The BUS switch, was NOT happy in forwarding all the traffic going to the firewall cluster :-)... From scott at sberkman.net Thu Jun 18 17:05:15 2009 From: scott at sberkman.net (Scott Berkman) Date: Thu, 18 Jun 2009 18:05:15 -0400 Subject: Ciena Help around Atlanta Message-ID: <025a01c9f060$dc32e760$9498b620$@net> All, If there is anyone good with Ciena Online Metro systems that would be willing to do some contract work around Atlanta, please contact me off list. Thanks! -Scott From rekordmeister at gmail.com Thu Jun 18 17:08:07 2009 From: rekordmeister at gmail.com (MKS) Date: Thu, 18 Jun 2009 22:08:07 +0000 Subject: tire 1 in Montreal In-Reply-To: <1736667212.68931245346945417.JavaMail.root@zimbra.nfsi.pt> References: <1736667212.68931245346945417.JavaMail.root@zimbra.nfsi.pt> Message-ID: It looks like Buffalo - Toronto - Montreal - Albany - Buffalo is a popular ring route to connect into Canada e.g. Level3 and Cogent use it (according to their online network maps), It looks like these carriers (Global Crossing, Level 3, Cogent, Tata, Tinet) have a pop in Montreal, does someone know if some/any are sharing the same fiber routes? or which carriers have the own diverse fiber route to/from Monteral. Regard MKS On Thu, Jun 18, 2009 at 5:42 PM, Nuno Vieira - nfsi telecom wrote: > check TATA Communications (former Teleglobe). > > regards, > --nvieira > > > ----- "MKS" wrote: > >> Hi List >> >> I'm looking for two tier 1 providers in Montreal, with independent >> fiber runs to the city.Which operator fit this criteria? >> >> Thanks in advance >> //MKS > From Rod.Beck at hiberniaatlantic.com Thu Jun 18 17:10:35 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Thu, 18 Jun 2009 23:10:35 +0100 Subject: [SPAM-HEADER] - Re: tire 1 in Montreal - Email has different SMTP TO: and MIME TO: fields in the email addresses References: <1736667212.68931245346945417.JavaMail.root@zimbra.nfsi.pt> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB0162828E@bert.HiberniaAtlantic.local> Hibernia Atlantic is a leading wholesaler on that route. Many IP backbones use us. Most carriers use 360 conduit into Montreal. We do not. Lots of carriers use Wiltel conduit into Buffalo and then 360 into Canada. Roderick S. Beck Director of European Sales Hibernia Atlantic -----Original Message----- From: MKS [mailto:rekordmeister at gmail.com] Sent: Thu 6/18/2009 11:08 PM To: Nuno Vieira - nfsi telecom Cc: nanog at nanog.org Subject: [SPAM-HEADER] - Re: tire 1 in Montreal - Email has different SMTP TO: and MIME TO: fields in the email addresses It looks like Buffalo - Toronto - Montreal - Albany - Buffalo is a popular ring route to connect into Canada e.g. Level3 and Cogent use it (according to their online network maps), It looks like these carriers (Global Crossing, Level 3, Cogent, Tata, Tinet) have a pop in Montreal, does someone know if some/any are sharing the same fiber routes? or which carriers have the own diverse fiber route to/from Monteral. Regard MKS From pstewart at nexicomgroup.net Thu Jun 18 18:47:35 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Thu, 18 Jun 2009 19:47:35 -0400 Subject: tire 1 in Montreal In-Reply-To: References: <1736667212.68931245346945417.JavaMail.root@zimbra.nfsi.pt> Message-ID: Level(3) has a lot of fiber in that ring route ... not sure who else covers those areas from a physical perspective.... Paul -----Original Message----- From: MKS [mailto:rekordmeister at gmail.com] Sent: June 18, 2009 6:08 PM To: Nuno Vieira - nfsi telecom Cc: nanog at nanog.org Subject: Re: tire 1 in Montreal It looks like Buffalo - Toronto - Montreal - Albany - Buffalo is a popular ring route to connect into Canada e.g. Level3 and Cogent use it (according to their online network maps), It looks like these carriers (Global Crossing, Level 3, Cogent, Tata, Tinet) have a pop in Montreal, does someone know if some/any are sharing the same fiber routes? or which carriers have the own diverse fiber route to/from Monteral. Regard MKS On Thu, Jun 18, 2009 at 5:42 PM, Nuno Vieira - nfsi telecom wrote: > check TATA Communications (former Teleglobe). > > regards, > --nvieira > > > ----- "MKS" wrote: > >> Hi List >> >> I'm looking for two tier 1 providers in Montreal, with independent >> fiber runs to the city.Which operator fit this criteria? >> >> Thanks in advance >> //MKS > ---------------------------------------------------------------------------- "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 aaron.glenn at gmail.com Thu Jun 18 20:31:27 2009 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Thu, 18 Jun 2009 18:31:27 -0700 Subject: Cogent input - no peering with Global Crossing in Europe [Re: NANOG Digest, Vol 17, Issue 46] In-Reply-To: <4A397D00.2090109@thewybles.com> References: <4A396F66.9070405@andrius.org> <4A397D00.2090109@thewybles.com> Message-ID: <18f601940906181831l796f7ac1k1644c4ab6038678a@mail.gmail.com> On Wed, Jun 17, 2009 at 4:32 PM, Charles Wyble wrote: > Ouch... latency must be awful. > > I suppose this is based on Cogents reputation but who knows. The whole > peering aspect of the networking business is often a mystery. I dont think it is any mystery Cogent doesn't have many friends in the European IP market... From NANOG at Aquillar.com Thu Jun 18 20:46:08 2009 From: NANOG at Aquillar.com (Peter Boone) Date: Thu, 18 Jun 2009 21:46:08 -0400 Subject: Wireless bridge In-Reply-To: <0e9401c9f033$24f4a160$6edde420$@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> Message-ID: <23ab01c9f07f$b7aa6480$26ff2d80$@com> OK, from reading all the excellent feedback I've got on and off list I've attempted to compile a "quick" summary of findings/ideas/products so far. - RouterBoard is no good for this type of application. - Get a unit with radio/antenna integrated, PoE from inside the building (outdoor rated cat5, shielded I assume), lightning suppression for the PoE (properly grounded), and ensure the mast is properly grounded. - 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. - Products that support ARQ are highly recommended. - I'm hearing the same products mentioned over and over: - Motorola - Ubiquiti - Aironet (Cisco) - Aruba A number of individuals recommended products from other brands at low cost that meet these mentioned requirements too. I'm not going to bother with a spectrum analyzer. In the current implementation we tried channels 1, 6 and 11 for a few days at a time and found 1 to be the most reliable. Done. At this point an analyzer will tell me what I already suspect: there's a problem. I've researched the Fresnel zones and calculated out a few things with rough numbers and worst case. For one, the Fresnel zone is disrupted most if the obstruction is closer to the endpoints (e.g. antennas). In this case, this is fine as the antenna are mounted at the outermost corner of the buildings as close as possible to the other buildings, approximately 3 floors in the air. Other buildings become a factor near the middle. Based on channel 1's wavelength of 0.12438 m, and assuming 1 km apart (for simplicity sake. It's actually less), the Fresnel zone is largest in the center at approx 5.6 m radius. That could definitely be obstructed by rooftops, I'll have to take another look though. This radius cuts in half when the frequency is doubled, thus more evidence in favour of the 5 GHz+ range. Cool. Or we could just go with a good line of sight optical solution but they look too expensive, and this area can have very unforgiving fog/wind to disrupt things further. What if we tilt each existing antenna up towards the sky 10-20 degrees? Please correct me if I'm wrong. The current antennas are plates. I'm pretty sure they are polarized. I used to have a product sheet on these but a Google search doesn't turn up any useful results anymore (SmartAnt PCW24-03014-BFL). The way they are mounted to the poles might make it difficult to try rotating them 90 degrees, but worth another look. The coax between the AP and antennas are no longer than 30 feet. I've often wondered if a Pringle or Coffee Cantenna would work better than these! For right now I'll have the coax line and ends inspected for damage/softspots, check the grounding, and cover/re-cover the ends in large amounts of rubber/electric tape. I think we might try the Ubiquiti Bullet2 for approx $100 per side (PoE supply/lightning suppression, wiring included) and see what happens! If that doesn't work, no major loss and we'll move up to something more serious (the PoE and wiring will already be ready to go). I will have to look into pricing on some of these suggestions and figure out if we should even bother getting a Bullet but instead go straight to a better all-in-one solution. Thank you guys very much for the tips. Feel free to keep them coming! Peter From joelja at bogus.com Thu Jun 18 21:54:57 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 18 Jun 2009 19:54:57 -0700 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: <4A3AFE01.4020605@bogus.com> Peter Boone wrote: > - Get a unit with radio/antenna integrated, PoE from inside the building > (outdoor rated cat5, shielded I assume), Actually shielding doesn't matter so much and it requires that the rj45 connector and socket be similarly sheilded to be effective, the salient points are: uv stablized and gel filled. normally comes in 1000' or longer rolls but something like the following will do if you're not running more than two cables ever: http://www.fab-corp.com/product.php?productid=16285&cat=296&page=1 > lightning suppression for the PoE > (properly grounded), and ensure the mast is properly grounded. excellent plan. From sharp at sharpone.net Fri Jun 19 00:27:19 2009 From: sharp at sharpone.net (Justin Sharp) Date: Thu, 18 Jun 2009 23:27:19 -0600 Subject: Wireless bridge In-Reply-To: <005c01c9f015$852ae490$8f80adb0$@com> References: <005c01c9f015$852ae490$8f80adb0$@com> Message-ID: <4A3B21B7.5040808@sharpone.net> I didn't read through all of the replies to see if this was suggested, apologies if it was. http://www.solectek.com/products.php?prod=sw7k&page=feat I implemented a PTP link at about 3 miles using these Solectek radios. I get 40Mbps consistently with TCP traffic and ~100Mbps UDP. This PTP link has literally been up for 3 years (in 2 weeks) without failing. I live in a 4 seaons state, so its seen all sorts of weather over those years. I have clean line of site down the freeway for what its worth. Its natively powered via POE, power injector included. We run all sorts of usual business application over this link, including about 30 simultaneous VOIP channels, and have not had one issue with stability. I was also told by the VAR that sold us the product that a city nearby (can't remember which one) connects all of its municipal buildings with Solectek stuff and runs its VOIP infrastructure over it as well. We run it in bridged mode with routers on each end, but it does support some rudimentary L3 stuff, static routing and RIP. IIRC, they were not "cheap" (couple of 1k), but for us have definitely been much cheaper than private circuits from carriers of comparable throughput capacity. Hope its helpful. --Justin From jeroen at easyhosting.nl Fri Jun 19 02:53:11 2009 From: jeroen at easyhosting.nl (Jeroen Wunnink) Date: Fri, 19 Jun 2009 09:53:11 +0200 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: <1245356861.8442.6.camel@legolas.orthanc.ca> References: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> <20090618201445.GA38466@gweep.net> <1245356861.8442.6.camel@legolas.orthanc.ca> Message-ID: <4A3B43E7.70101@easyhosting.nl> We just open port 2525 for customers from ISP's blocking official SMTP ports so they can use their dedicated servers/domain mailservers. Lyndon Nerenberg wrote: > On Thu, 2009-06-18 at 16:14 -0400, Joe Provo wrote: > >> then you should be shifting your userbase to authenticated on the >> SUBMIT >> port [587] anyway... >> > > Except for those ISPs who choose to intercept port 587 as well. This is > a big problem with Rogers in Vancouver. They hijack port 587 connections > through some sort of lame proxy that connects you to your intended host, > but strips the AUTH field out of the EHLO response from the remote > submission server ... > > > -- 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 Fri Jun 19 03:37:59 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 19 Jun 2009 09:37:59 +0100 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: <4A3B43E7.70101@easyhosting.nl> References: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> <20090618201445.GA38466@gweep.net> <1245356861.8442.6.camel@legolas.orthanc.ca> <4A3B43E7.70101@easyhosting.nl> Message-ID: <6108F574-380B-40E4-A48C-1B2DE4EE01BC@ianai.net> Sent from my iPhone, please excuse any errors. On Jun 19, 2009, at 8:53, Jeroen Wunnink wrote: > We just open port 2525 for customers from ISP's blocking official > SMTP ports so they can use their dedicated servers/domain mailservers. Is there any reason you do not use port 587, SUBMIT? -- TTFN, patrick > Lyndon Nerenberg wrote: >> On Thu, 2009-06-18 at 16:14 -0400, Joe Provo wrote: >> >>> then you should be shifting your userbase to authenticated on the >>> SUBMIT port [587] anyway... >>> >> >> Except for those ISPs who choose to intercept port 587 as well. >> This is >> a big problem with Rogers in Vancouver. They hijack port 587 >> connections >> through some sort of lame proxy that connects you to your intended >> host, >> but strips the AUTH field out of the EHLO response from the remote >> submission server ... >> >> >> > > -- > > 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 jeroen at easyhosting.nl Fri Jun 19 04:28:55 2009 From: jeroen at easyhosting.nl (Jeroen Wunnink) Date: Fri, 19 Jun 2009 11:28:55 +0200 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: <6108F574-380B-40E4-A48C-1B2DE4EE01BC@ianai.net> References: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> <20090618201445.GA38466@gweep.net> <1245356861.8442.6.camel@legolas.orthanc.ca> <4A3B43E7.70101@easyhosting.nl> <6108F574-380B-40E4-A48C-1B2DE4EE01BC@ianai.net> Message-ID: <4A3B5A57.7060003@easyhosting.nl> Yes.. 1. Customers remember it more easily 2. Some ISP's also block 587 (hence 'SMTP ports' rather then 'SMTP port' in my previous comment ;-) Patrick W. Gilmore wrote: > > > Sent from my iPhone, please excuse any errors. > > > On Jun 19, 2009, at 8:53, Jeroen Wunnink wrote: > >> We just open port 2525 for customers from ISP's blocking official >> SMTP ports so they can use their dedicated servers/domain mailservers. > > Is there any reason you do not use port 587, SUBMIT? > > -- TTFN, > patrick > > >> Lyndon Nerenberg wrote: >>> On Thu, 2009-06-18 at 16:14 -0400, Joe Provo wrote: >>> >>>> then you should be shifting your userbase to authenticated on the >>>> SUBMIT port [587] anyway... >>>> >>> >>> Except for those ISPs who choose to intercept port 587 as well. This is >>> a big problem with Rogers in Vancouver. They hijack port 587 >>> connections >>> through some sort of lame proxy that connects you to your intended >>> host, >>> but strips the AUTH field out of the EHLO response from the remote >>> submission server ... >>> >>> >>> >> >> -- >> >> 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 >> >> >> > -- 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 bclark at spectraaccess.com Fri Jun 19 05:19:14 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Fri, 19 Jun 2009 06:19:14 -0400 Subject: Wireless bridge In-Reply-To: <4A3B21B7.5040808@sharpone.net> References: <005c01c9f015$852ae490$8f80adb0$@com> <4A3B21B7.5040808@sharpone.net> Message-ID: <4A3B6622.7080301@spectraaccess.com> Justin Sharp wrote: > I didn't read through all of the replies to see if this was suggested, > apologies if it was. > > http://www.solectek.com/products.php?prod=sw7k&page=feat > > I implemented a PTP link at about 3 miles using these Solectek radios. > I get 40Mbps consistently with TCP traffic and ~100Mbps UDP. This PTP > link has literally been up for 3 years (in 2 weeks) without failing. I > live in a 4 seaons state, so its seen all sorts of weather over those > years. I have clean line of site down the freeway for what its worth. > Its natively powered via POE, power injector included. We run all > sorts of usual business application over this link, including about 30 > simultaneous VOIP channels, and have not had one issue with stability. > I was also told by the VAR that sold us the product that a city nearby > (can't remember which one) connects all of its municipal buildings > with Solectek stuff and runs its VOIP infrastructure over it as well. > > We run it in bridged mode with routers on each end, but it does > support some rudimentary L3 stuff, static routing and RIP. > > IIRC, they were not "cheap" (couple of 1k), but for us have definitely > been much cheaper than private circuits from carriers of comparable > throughput capacity. > > Hope its helpful. > > --Justin > I have to say I did a double take on your speed claims. We use Solectek all over the place and have yet to archived those speeds on any of our links. Not only that Solectek engineers have told us that at a 108mbps radio rate realistically you are only going to see only 35mbps data rate on link that's just a mile apart; further you go the less bandwidth you will have. Other then that, I agree they are nice radios and even include heaters in them to help maintain temperatures above freezing during winter time so that ice buildup doesn't cause a problem. Bret From randy at psg.com Fri Jun 19 06:53:03 2009 From: randy at psg.com (Randy Bush) Date: Fri, 19 Jun 2009 04:53:03 -0700 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: <4A3B43E7.70101@easyhosting.nl> References: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> <20090618201445.GA38466@gweep.net> <1245356861.8442.6.camel@legolas.orthanc.ca> <4A3B43E7.70101@easyhosting.nl> Message-ID: > We just open port 2525 for customers from ISP's blocking official SMTP > ports so they can use their dedicated servers/domain mailservers. for personal use, i have a box that has sshd running on 443 and i tunnel 2525 through it. that worked even in the narita red rug when they were at their blocking worst. for customer use, i would push them to 465, 587 if less clued. randy From cidr-report at potaroo.net Fri Jun 19 07:00:06 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 19 Jun 2009 22:00:06 +1000 (EST) Subject: BGP Update Report Message-ID: <200906191200.n5JC06et077908@wattle.apnic.net> BGP Update Report Interval: 11-Jun-09 -to- 18-Jun-09 (8 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9198 83410 7.5% 842.5 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - AS34744 30544 2.7% 161.6 -- GVM SC GVM SISTEM 2003 SRL 3 - AS33783 21402 1.9% 171.2 -- EEPAD 4 - AS30890 15475 1.4% 29.4 -- EVOLVA Evolva Telecom 5 - AS21491 11941 1.1% 398.0 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 6 - AS47408 11550 1.0% 825.0 -- MANDARIN-AS Mandarin WIMAX Sicilia SpA 7 - AS17974 10815 1.0% 12.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 8 - AS7738 8436 0.8% 21.3 -- Telecomunicacoes da Bahia S.A. 9 - AS20115 7779 0.7% 7.0 -- CHARTER-NET-HKY-NC - Charter Communications 10 - AS8452 7678 0.7% 8.3 -- TEDATA TEDATA 11 - AS29372 7317 0.7% 118.0 -- SFR-NETWORK SFR 12 - AS2697 6463 0.6% 99.4 -- ERX-ERNET-AS Education and Research Network 13 - AS35805 6432 0.6% 17.9 -- UTG-AS United Telecom AS 14 - AS16091 6373 0.6% 6373.0 -- SATEC SATEC AS 15 - AS27046 6193 0.6% 38.5 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 16 - AS5050 6091 0.6% 3045.5 -- PSC-EXT - Pittsburgh Supercomputing Center 17 - AS4855 6048 0.5% 104.3 -- PI-ID-AS-AP Pacific Link Indonesia 18 - AS29049 6012 0.5% 19.0 -- DELTA-TELECOM-AS Delta Telecom LTD. 19 - AS25546 5853 0.5% 5853.0 -- BROOKLANDCOMP-AS Brookland Computer Services 20 - AS6389 5706 0.5% 2.7 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS16091 6373 0.6% 6373.0 -- SATEC SATEC AS 2 - AS25546 5853 0.5% 5853.0 -- BROOKLANDCOMP-AS Brookland Computer Services 3 - AS5050 6091 0.6% 3045.5 -- PSC-EXT - Pittsburgh Supercomputing Center 4 - AS5691 2913 0.3% 2913.0 -- MITRE-AS-5 - The MITRE Corporation 5 - AS65001 2011 0.2% 2011.0 -- -Private Use AS- 6 - AS23384 1777 0.2% 1777.0 -- REEDTECH - Reed Technology and Information Services, Inc. 7 - AS32343 1627 0.1% 1627.0 -- INTRINSIC-THERAPEUTICS - Intrinsic Orthopedics/Therapeutics, Inc. 8 - AS65011 1570 0.1% 1570.0 -- -Private Use AS- 9 - AS8225 1563 0.1% 1563.0 -- ASTELIT-MSK-AS Astelit Autonomous System 10 - AS9198 83410 7.5% 842.5 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 11 - AS47408 11550 1.0% 825.0 -- MANDARIN-AS Mandarin WIMAX Sicilia SpA 12 - AS22783 4733 0.4% 788.8 -- WEBPOWER - WebPower, Inc. 13 - AS1734 1435 0.1% 717.5 -- ROP-COCA-AS01 - Contra Costa County Regional Occupation Program / Richmond 14 - AS20583 665 0.1% 665.0 -- ABNAMROKZ-AS SJSB ABN AMRO Bank Kazakhstan JSC 15 - AS44774 560 0.1% 560.0 -- ZOLOTOY-KLYUCHIK-AS Zolotoy Klyuchik Ltd. 16 - AS47640 1507 0.1% 502.3 -- TRICOMPAS Tricomp Sp. z. o. o. 17 - AS4796 473 0.0% 473.0 -- BANDUNG-NET-AS-AP Institute of Technology Bandung 18 - AS40060 3735 0.3% 466.9 -- AAAWI - AAA Wireless, Inc. 19 - AS30947 434 0.0% 434.0 -- PLURICANAL-AS Pluricanal, SA 20 - AS21491 11941 1.1% 398.0 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 95.59.1.0/24 10584 0.9% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - 88.204.221.0/24 10562 0.9% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 3 - 89.218.218.0/23 10280 0.8% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 4 - 89.218.220.0/23 10280 0.8% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 5 - 95.59.4.0/22 10276 0.8% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 6 - 95.59.2.0/23 10273 0.8% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 7 - 92.46.244.0/23 10272 0.8% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 8 - 95.59.8.0/23 10271 0.8% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 9 - 213.164.56.0/22 6373 0.5% AS16091 -- SATEC SATEC AS 10 - 72.23.246.0/24 6059 0.5% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 11 - 193.201.184.0/21 5853 0.5% AS25546 -- BROOKLANDCOMP-AS Brookland Computer Services 12 - 118.98.240.0/20 3621 0.3% AS18051 -- JARDIKNAS-AS-AP Departemen Pendidikan Nasional AS65001 -- -Private Use AS- AS65011 -- -Private Use AS- 13 - 192.12.120.0/24 2913 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 14 - 90.150.0.0/24 2193 0.2% AS35400 -- MFIST Interregoinal Organization Network Technologies 15 - 72.42.193.0/24 1918 0.2% AS40060 -- AAAWI - AAA Wireless, Inc. 16 - 63.163.66.0/24 1838 0.1% AS22783 -- WEBPOWER - WebPower, Inc. 17 - 205.246.203.0/24 1834 0.1% AS22783 -- WEBPOWER - WebPower, Inc. 18 - 203.77.192.0/20 1788 0.1% AS7473 -- SINGTEL-AS-AP Singapore Telecommunications Ltd 19 - 65.119.201.0/24 1777 0.1% AS23384 -- REEDTECH - Reed Technology and Information Services, Inc. 20 - 72.42.204.0/23 1729 0.1% AS40060 -- AAAWI - AAA Wireless, Inc. 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 Jun 19 07:00:02 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 19 Jun 2009 22:00:02 +1000 (EST) Subject: The Cidr Report Message-ID: <200906191200.n5JC02nC077897@wattle.apnic.net> This report has been generated at Fri Jun 19 21:13:57 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 12-06-09 294158 183382 13-06-09 294150 183283 14-06-09 293984 183407 15-06-09 294154 183329 16-06-09 294209 183622 17-06-09 294401 183709 18-06-09 294664 183895 19-06-09 295035 183967 AS Summary 31610 Number of ASes in routing system 13435 Number of ASes announcing only one prefix 4284 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89739520 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'). --- 19Jun09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 294947 183929 111018 37.6% All ASes AS6389 4284 343 3941 92.0% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4277 1778 2499 58.4% TWTC - tw telecom holdings, inc. AS4766 1814 520 1294 71.3% KIXS-AS-KR Korea Telecom AS17488 1601 310 1291 80.6% HATHWAY-NET-AP Hathway IP Over Cable Internet AS1785 1694 662 1032 60.9% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1214 194 1020 84.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1064 67 997 93.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1466 585 881 60.1% Uninet S.A. de C.V. AS19262 1015 232 783 77.1% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8452 987 275 712 72.1% TEDATA TEDATA AS18566 1062 423 639 60.2% COVAD - Covad Communications Co. AS6478 1376 749 627 45.6% ATT-INTERNET3 - AT&T WorldNet Services AS18101 750 167 583 77.7% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS4804 679 107 572 84.2% MPX-AS Microplex PTY LTD AS17908 674 137 537 79.7% TCISL Tata Communications AS11492 1116 588 528 47.3% CABLEONE - CABLE ONE, INC. AS9498 639 141 498 77.9% BBIL-AP BHARTI Airtel Ltd. AS2706 536 44 492 91.8% PI-HK Pacnet Internet (Hong Kong) Limited AS17676 564 80 484 85.8% GIGAINFRA Softbank BB Corp. AS7029 601 121 480 79.9% WINDSTREAM - Windstream Communications Inc AS24560 718 241 477 66.4% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4808 641 165 476 74.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4134 890 418 472 53.0% CHINANET-BACKBONE No.31,Jin-rong Street AS22047 599 129 470 78.5% VTR BANDA ANCHA S.A. AS7018 1501 1046 455 30.3% ATT-INTERNET4 - AT&T WorldNet Services AS7545 819 382 437 53.4% TPG-INTERNET-AP TPG Internet Pty Ltd AS6517 673 246 427 63.4% RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc AS9443 514 90 424 82.5% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7011 981 567 414 42.2% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4668 693 284 409 59.0% LGNET-AS-KR LG CNS Total 35442 11091 24351 68.7% 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 109.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 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 188.117.192.0/18 AS25447 JM-DATA JM-DATA 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 G-WiN 192.124.252.0/22 AS680 DFN-IP service G-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 194.63.159.0/24 AS34848 COMENDO-AS Comendo A/S 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.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 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.83.208.0/20 AS32311 216.83.208.0/24 AS32311 216.83.209.0/24 AS32311 216.83.210.0/24 AS32311 216.83.212.0/24 AS32311 216.83.213.0/24 AS32311 216.83.218.0/24 AS32311 216.83.219.0/24 AS32311 216.83.220.0/24 AS32311 216.83.221.0/24 AS32311 216.83.222.0/24 AS32311 216.83.223.0/24 AS32311 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 IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet 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 shoemakerp at vectordatasystems.com Fri Jun 19 07:46:19 2009 From: shoemakerp at vectordatasystems.com (Patrick Shoemaker) Date: Fri, 19 Jun 2009 08:46:19 -0400 Subject: Wireless bridge In-Reply-To: References: Message-ID: <4A3B889B.5040503@vectordatasystems.com> Peter, to follow up on a few of your RF questions here: The idea behind the Fresnel zones is that objects (larger than one wavelength, a few centimeters at the frequencies we're dealing with here) within the zones will reflect the incoming radio wave from the transmitting radio. As seen by the receiver, there will be two signals- one coming directly from the transmitting antenna, and the reflection coming from the object in the Fresnel zone. The reflected signal, having a longer overall path length, will be slightly out of phase compared to the direct wave, and will destructively interfere with the direct wave, lowering the overall received power level seen by the receiving radio. This is called multipath interference. Therefore, unless you're using very high gain antennas (large parabolic dishes) with high directivity, you won't gain anything by pointing them at the sky or away from the object in the Fresnel zone. You'll lose more signal by mis-aiming the antennas than you will lose from the multipath interference. Regarding antenna polarization, your flat panel antennas are certainly polarized and must be oriented in the same polarization at each end. Finally, if you have a way to check the received power level at your existing radios, you will want to adjust the transmitter output power of each end so that the received power is within a reasonable range. Generally speaking, for a link of that distance, you should aim for something in the -60 dBm range. Anything hotter than a -50 and you start to get into front-end overload territory, and anything weaker than a -70 and you're beginning to run on thin fade margins. Also, I disagree that shielded Ethernet cable is unnecessary. For the very low additional cost of shielded outdoor cat-5, it's well worth your effort if you're running new cable. Of course every installation is different, but why risk ethernet errors due to some large air conditioner or something on the roof spewing EMI? Patrick Shoemaker Vector Data Systems LLC shoemakerp at vectordatasystems.com office: (301) 358-1690 x36 http://www.vectordatasystems.com > Message: 12 > Date: Thu, 18 Jun 2009 21:46:08 -0400 > From: "Peter Boone" > Subject: RE: Wireless bridge > To: > Message-ID: <23ab01c9f07f$b7aa6480$26ff2d80$@com> > Content-Type: text/plain; charset="us-ascii" > > OK, from reading all the excellent feedback I've got on and off list I've > attempted to compile a "quick" summary of findings/ideas/products so far. > > - RouterBoard is no good for this type of application. > > - Get a unit with radio/antenna integrated, PoE from inside the building > (outdoor rated cat5, shielded I assume), lightning suppression for the PoE > (properly grounded), and ensure the mast is properly grounded. > > - 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. > > - Products that support ARQ are highly recommended. > > - I'm hearing the same products mentioned over and over: > - Motorola > - Ubiquiti > - Aironet (Cisco) > - Aruba > A number of individuals recommended products from other brands at low cost > that meet these mentioned requirements too. > > > I'm not going to bother with a spectrum analyzer. In the current > implementation we tried channels 1, 6 and 11 for a few days at a time and > found 1 to be the most reliable. Done. At this point an analyzer will tell > me what I already suspect: there's a problem. > > I've researched the Fresnel zones and calculated out a few things with rough > numbers and worst case. For one, the Fresnel zone is disrupted most if the > obstruction is closer to the endpoints (e.g. antennas). In this case, this > is fine as the antenna are mounted at the outermost corner of the buildings > as close as possible to the other buildings, approximately 3 floors in the > air. Other buildings become a factor near the middle. Based on channel 1's > wavelength of 0.12438 m, and assuming 1 km apart (for simplicity sake. It's > actually less), the Fresnel zone is largest in the center at approx 5.6 m > radius. That could definitely be obstructed by rooftops, I'll have to take > another look though. This radius cuts in half when the frequency is doubled, > thus more evidence in favour of the 5 GHz+ range. Cool. Or we could just go > with a good line of sight optical solution but they look too expensive, and > this area can have very unforgiving fog/wind to disrupt things further. What > if we tilt each existing antenna up towards the sky 10-20 degrees? Please > correct me if I'm wrong. > > The current antennas are plates. I'm pretty sure they are polarized. I used > to have a product sheet on these but a Google search doesn't turn up any > useful results anymore (SmartAnt PCW24-03014-BFL). The way they are mounted > to the poles might make it difficult to try rotating them 90 degrees, but > worth another look. The coax between the AP and antennas are no longer than > 30 feet. I've often wondered if a Pringle or Coffee Cantenna would work > better than these! > > > For right now I'll have the coax line and ends inspected for > damage/softspots, check the grounding, and cover/re-cover the ends in large > amounts of rubber/electric tape. I think we might try the Ubiquiti Bullet2 > for approx $100 per side (PoE supply/lightning suppression, wiring included) > and see what happens! If that doesn't work, no major loss and we'll move up > to something more serious (the PoE and wiring will already be ready to go). > I will have to look into pricing on some of these suggestions and figure out > if we should even bother getting a Bullet but instead go straight to a > better all-in-one solution. > > Thank you guys very much for the tips. Feel free to keep them coming! > > Peter From frnkblk at iname.com Fri Jun 19 08:50:34 2009 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 19 Jun 2009 08:50:34 -0500 Subject: OT: Someone is parroting Randy Message-ID: "'My competitors are welcome to them. They won't earn anything on them either." Says Marco Visser, head of KPN's mobile services division, in response to the press' inquiry whether their elimination of free phones for pay-as-you-go would result in an outflow of customers http://www.telegeography.com/cu/article.php?article_id=28943 &email=html From dot at dotat.at Fri Jun 19 10:51:06 2009 From: dot at dotat.at (Tony Finch) Date: Fri, 19 Jun 2009 16:51:06 +0100 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: <1245356861.8442.6.camel@legolas.orthanc.ca> References: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> <20090618201445.GA38466@gweep.net> <1245356861.8442.6.camel@legolas.orthanc.ca> Message-ID: On Thu, 18 Jun 2009, Lyndon Nerenberg wrote: > > Except for those ISPs who choose to intercept port 587 as well. This is > a big problem with Rogers in Vancouver. They hijack port 587 connections > through some sort of lame proxy that connects you to your intended host, > but strips the AUTH field out of the EHLO response from the remote > submission server ... Grr. Someone needs to whack them with the clue bat. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From eesslinger at fpu-tn.com Fri Jun 19 11:54:13 2009 From: eesslinger at fpu-tn.com (Eric J Esslinger) Date: Fri, 19 Jun 2009 11:54:13 -0500 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> References: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> Message-ID: I am the ISP, and we currently don't. However, I inherited this setup and have been slowly fixing glaring holes (those are fairly well gone now) and not so glaring one. When our new firewall gets in, I will be rolling in port 25 blocks on dynamic IP addresses. The static ips will be unfiltered. Customers may send outbound mail through our SMTP server, or connect via alternate ports to their SMTP server. ________________________________ From: Zhiyun Qian [zhiyunq at umich.edu] Sent: Thursday, June 18, 2009 2:36 PM To: nanog at nanog.org Subject: Is your ISP blocking outgoing port 25? It has been long heard that many ISPs block outgoing port 25 for the purpose of reducing spam originated from their network. I wonder which ISPs are still doing so. I know comcast has been doing that but they cancelled it after many complaints. It seems to be the same case for Verizon. AT&T is the major one that I know of that is still enforcing this policy. But they said they can unblock port 25 upon request. I am not sure how easy it is. One simple way to test if your ISP is blocking outgoing port 25 is to try: "telnet mx2.hotmail.com 25" or "telnet gmail-smtp-in.l.google.com 25". If the connection fails, it could be due to the fact your ISP is blocking outgoing port 25, although it can also be other reasons such as local firewall configuration. Can someone perform the test and let me know result if possible? Thanks a lot! Regards. -Zhiyun ________________________________ This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. From cscora at apnic.net Fri Jun 19 13:11:54 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 20 Jun 2009 04:11:54 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200906191811.n5JIBslk009469@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 20 Jun, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 288799 Prefixes after maximum aggregation: 137405 Deaggregation factor: 2.10 Unique aggregates announced to Internet: 143140 Total ASes present in the Internet Routing Table: 31502 Prefixes per ASN: 9.17 Origin-only ASes present in the Internet Routing Table: 27382 Origin ASes announcing only one prefix: 13343 Transit ASes present in the Internet Routing Table: 4120 Transit-only ASes present in the Internet Routing Table: 91 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: 451 Unregistered ASNs in the Routing Table: 131 Number of 32-bit ASNs allocated by the RIRs: 177 Prefixes from 32-bit ASNs in the Routing Table: 49 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 847 Number of addresses announced to Internet: 2052918096 Equivalent to 122 /8s, 93 /16s and 11 /24s Percentage of available address space announced: 55.4 Percentage of allocated address space announced: 64.1 Percentage of available address space allocated: 86.4 Percentage of address space in use by end-sites: 77.4 Total number of prefixes smaller than registry allocations: 142968 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 68732 Total APNIC prefixes after maximum aggregation: 24540 APNIC Deaggregation factor: 2.80 Prefixes being announced from the APNIC address blocks: 68133 Unique aggregates announced from the APNIC address blocks: 30927 APNIC Region origin ASes present in the Internet Routing Table: 3666 APNIC Prefixes per ASN: 18.59 APNIC Region origin ASes announcing only one prefix: 999 APNIC Region transit ASes present in the Internet Routing Table: 565 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 454152304 Equivalent to 27 /8s, 17 /16s and 208 /24s Percentage of available APNIC address space announced: 84.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: 123570 Total ARIN prefixes after maximum aggregation: 66000 ARIN Deaggregation factor: 1.87 Prefixes being announced from the ARIN address blocks: 124331 Unique aggregates announced from the ARIN address blocks: 51877 ARIN Region origin ASes present in the Internet Routing Table: 13046 ARIN Prefixes per ASN: 9.53 ARIN Region origin ASes announcing only one prefix: 5010 ARIN Region transit ASes present in the Internet Routing Table: 1278 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 1009647680 Equivalent to 60 /8s, 46 /16s and 0 /24s Percentage of available ARIN address space announced: 194.1 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: 66020 Total RIPE prefixes after maximum aggregation: 39077 RIPE Deaggregation factor: 1.69 Prefixes being announced from the RIPE address blocks: 65133 Unique aggregates announced from the RIPE address blocks: 43776 RIPE Region origin ASes present in the Internet Routing Table: 13167 RIPE Prefixes per ASN: 4.95 RIPE Region origin ASes announcing only one prefix: 6882 RIPE Region transit ASes present in the Internet Routing Table: 1977 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 22 Number of RIPE addresses announced to Internet: 482928800 Equivalent to 28 /8s, 200 /16s and 232 /24s Percentage of available RIPE address space announced: 102.8 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: 23996 Total LACNIC prefixes after maximum aggregation: 5996 LACNIC Deaggregation factor: 4.00 Prefixes being announced from the LACNIC address blocks: 23861 Unique aggregates announced from the LACNIC address blocks: 13403 LACNIC Region origin ASes present in the Internet Routing Table: 1120 LACNIC Prefixes per ASN: 21.30 LACNIC Region origin ASes announcing only one prefix: 359 LACNIC Region transit ASes present in the Internet Routing Table: 188 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 19 Number of LACNIC addresses announced to Internet: 71607680 Equivalent to 4 /8s, 68 /16s and 165 /24s Percentage of available LACNIC address space announced: 71.1 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: 6085 Total AfriNIC prefixes after maximum aggregation: 1481 AfriNIC Deaggregation factor: 4.11 Prefixes being announced from the AfriNIC address blocks: 6480 Unique aggregates announced from the AfriNIC address blocks: 2496 AfriNIC Region origin ASes present in the Internet Routing Table: 301 AfriNIC Prefixes per ASN: 21.53 AfriNIC Region origin ASes announcing only one prefix: 93 AfriNIC Region transit ASes present in the Internet Routing Table: 62 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 20152832 Equivalent to 1 /8s, 51 /16s and 130 /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 1707 6931 402 Korea Telecom (KIX) 17488 1601 131 102 Hathway IP Over Cable Interne 4755 1214 327 138 TATA Communications formerly 9583 1106 87 546 Sify Limited 4134 890 16912 375 CHINANET-BACKBONE 7545 803 198 100 TPG Internet Pty Ltd 23577 782 34 665 Korea Telecom (ATM-MPLS) 18101 750 209 32 Reliance Infocom Ltd Internet 24560 718 230 175 Bharti Airtel Ltd. 9829 714 603 18 BSNL National Internet Backbo 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 4285 3647 324 bellsouth.net, inc. 4323 1866 1035 376 Time Warner Telecom 1785 1694 715 137 PaeTec Communications, Inc. 20115 1650 1449 723 Charter Communications 7018 1502 5926 1042 AT&T WorldNet Services 6478 1376 305 450 AT&T Worldnet Services 2386 1265 686 919 AT&T Data Communications Serv 3356 1206 10980 451 Level 3 Communications, LLC 11492 1116 208 12 Cable One 22773 1064 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 3292 455 1902 392 TDC Tele Danmark 12479 449 578 6 Uni2 Autonomous System 702 429 1861 346 UUNET - Commercial IP service 30890 416 88 196 Evolva Telecom 35805 353 40 5 United Telecom of Georgia 8866 352 109 21 Bulgarian Telecommunication C 3301 345 1668 308 TeliaNet Sweden 3215 342 3041 107 France Telecom Transpac 3320 339 7066 297 Deutsche Telekom AG 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 1464 2863 236 UniNet S.A. de C.V. 10620 916 208 115 TVCABLE BOGOTA 22047 599 302 14 VTR PUNTO NET S.A. 7303 564 298 87 Telecom Argentina Stet-France 28573 549 563 38 NET Servicos de Comunicao S.A 11830 486 292 54 Instituto Costarricense de El 6471 443 96 32 ENTEL CHILE S.A. 11172 442 102 70 Servicios Alestra S.A de C.V 7738 404 794 28 Telecomunicacoes da Bahia S.A 3816 366 188 83 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 987 188 7 TEDATA 24863 888 83 41 LINKdotNET AS number 20858 324 34 5 EgyNet 3741 277 856 237 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 33776 116 6 7 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 4285 3647 324 bellsouth.net, inc. 4323 1866 1035 376 Time Warner Telecom 4766 1707 6931 402 Korea Telecom (KIX) 1785 1694 715 137 PaeTec Communications, Inc. 20115 1650 1449 723 Charter Communications 17488 1601 131 102 Hathway IP Over Cable Interne 7018 1502 5926 1042 AT&T WorldNet Services 8151 1464 2863 236 UniNet S.A. de C.V. 6478 1376 305 450 AT&T Worldnet Services 2386 1265 686 919 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 1785 1694 1557 PaeTec Communications, Inc. 17488 1601 1499 Hathway IP Over Cable Interne 4323 1866 1490 Time Warner Telecom 4766 1707 1305 Korea Telecom (KIX) 8151 1464 1228 UniNet S.A. de C.V. 11492 1116 1104 Cable One 4755 1214 1076 TATA Communications formerly 18566 1062 1052 Covad Communications 22773 1064 998 Cox Communications, Inc. 8452 987 980 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.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 64.31.59.0/24 7017 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:20 /11:59 /12:167 /13:348 /14:603 /15:1157 /16:10519 /17:4741 /18:8103 /19:16913 /20:20247 /21:20048 /22:25959 /23:25847 /24:151439 /25:870 /26:1019 /27:540 /28:149 /29:8 /30:6 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2792 4285 bellsouth.net, inc. 4766 1400 1707 Korea Telecom (KIX) 17488 1313 1601 Hathway IP Over Cable Interne 1785 1171 1694 PaeTec Communications, Inc. 11492 1044 1116 Cable One 18566 1043 1062 Covad Communications 2386 978 1265 AT&T Data Communications Serv 9583 958 1106 Sify Limited 4323 954 1866 Time Warner Telecom 8452 920 987 TEDATA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:205 12:2235 13:10 15:19 16:3 17:4 20:36 24:1083 32:52 34:2 38:572 40:97 41:1735 43:1 44:2 47:13 52:4 55:2 56:3 57:24 58:577 59:638 60:459 61:1078 62:1109 63:2017 64:3727 65:2381 66:3615 67:1632 68:829 69:2655 70:556 71:184 72:1672 73:2 74:1578 75:172 76:323 77:856 78:557 79:349 80:1003 81:833 82:561 83:434 84:632 85:1013 86:398 87:656 88:356 89:1446 90:57 91:2352 92:345 93:1077 94:1229 95:1064 96:141 97:219 98:248 99:23 109:1 110:150 111:18 112:134 113:123 114:249 115:336 116:1161 117:529 118:301 119:698 120:145 121:755 122:1034 123:701 124:992 125:1338 128:221 129:239 130:127 131:410 132:72 133:9 134:183 135:38 136:224 137:162 138:163 139:80 140:443 141:118 142:385 143:339 144:364 145:48 146:381 147:155 148:516 149:237 150:176 151:193 152:144 153:142 154:2 155:276 156:169 157:301 158:116 159:341 160:284 161:152 162:270 163:164 164:482 165:503 166:454 167:359 168:664 169:167 170:473 171:39 172:10 173:300 174:220 178:1 180:1 183:1 186:26 187:112 188:35 189:435 190:2796 192:5782 193:4242 194:3307 195:2698 196:1092 198:3606 199:3355 200:5089 201:1286 202:7913 203:8208 204:3848 205:2160 206:2437 207:2738 208:3888 209:3400 210:2673 211:1121 212:1558 213:1681 214:81 215:31 216:4530 217:1318 218:393 219:433 220:1226 221:485 222:305 End of report From pmm at igtc.com Fri Jun 19 16:52:56 2009 From: pmm at igtc.com (Paul M Moriarty) Date: Fri, 19 Jun 2009 14:52:56 -0700 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: <4A3A9B0D.90001@thewybles.com> References: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> <4A3A9B0D.90001@thewybles.com> Message-ID: <47CABDB8-A1CB-4A0A-B95E-FAD95D25D0DD@igtc.com> > >> AT&T is the major one that I know of that is still enforcing this >> policy. >> But they said they can unblock port 25 upon request. I am not sure >> how easy >> it is. > > It's trivial. A web form. You get the link when you try to send mail > to port 25 anywhere else. At least with Yahoo/SBC dsl. > > I got the business class DSL from AT&T and no such nonsense exists. Same here with U-Verse and a /29 of static IP's. No blocking since Day 1. From sean at donelan.com Fri Jun 19 17:24:23 2009 From: sean at donelan.com (Sean Donelan) Date: Fri, 19 Jun 2009 18:24:23 -0400 (EDT) Subject: Is your ISP blocking outgoing port 25? In-Reply-To: <4A3B5A57.7060003@easyhosting.nl> References: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> <20090618201445.GA38466@gweep.net> <1245356861.8442.6.camel@legolas.orthanc.ca> <4A3B43E7.70101@easyhosting.nl> <6108F574-380B-40E4-A48C-1B2DE4EE01BC@ianai.net> <4A3B5A57.7060003@easyhosting.nl> Message-ID: <200906191814020.32BF5B92.29053@clifden.donelan.com> On Fri, 19 Jun 2009, Jeroen Wunnink wrote: > 1. Customers remember it more easily > 2. Some ISP's also block 587 (hence 'SMTP ports' rather then 'SMTP port' in > my previous comment ;-) Those same clueless ISPs will probably block 2525 someday too, clueless expands to fill any void. And using non-standard things like 2525 only lead to more confusion for customers later when they try someone else's non-standard choice, e.g. port 26 or 24 or 5252 and wonder why those don't work. On the other hand, why don't modern mail user agents and mail transfer agents come configured to use MSA port 587 by default for message submission instead of making customers remember anything? RFC 2476 was published over a decade ago, software developers should have caught up to it by now. Imagine if the little box in Outlook and Exchange had the MSA port already filled in, and you only needed to change it for legacy things. From sking at kingrst.com Fri Jun 19 17:35:00 2009 From: sking at kingrst.com (Steven King) Date: Fri, 19 Jun 2009 18:35:00 -0400 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: <200906191814020.32BF5B92.29053@clifden.donelan.com> References: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> <20090618201445.GA38466@gweep.net> <1245356861.8442.6.camel@legolas.orthanc.ca> <4A3B43E7.70101@easyhosting.nl> <6108F574-380B-40E4-A48C-1B2DE4EE01BC@ianai.net> <4A3B5A57.7060003@easyhosting.nl> <200906191814020.32BF5B92.29053@clifden.donelan.com> Message-ID: <4A3C1294.6070100@kingrst.com> Most MTAs don't come preconfigured with port 587 either. It is amazing how many people/organizations go with the "if it isn't broke, don't fix it" mentality, even though it clearly needs to be revised and something new needs to be done/supported. Email needs to be revamped on a larger scale than just adding standards. Sean Donelan wrote: > On Fri, 19 Jun 2009, Jeroen Wunnink wrote: >> 1. Customers remember it more easily >> 2. Some ISP's also block 587 (hence 'SMTP ports' rather then 'SMTP >> port' in my previous comment ;-) > > Those same clueless ISPs will probably block 2525 someday too, > clueless expands to fill any void. And using non-standard things like > 2525 only lead to more confusion for customers later when they try > someone else's non-standard choice, e.g. port 26 or 24 or 5252 and > wonder why those don't work. > > On the other hand, why don't modern mail user agents and mail transfer > agents come configured to use MSA port 587 by default for message > submission instead of making customers remember anything? RFC 2476 was > published over a decade ago, software developers should have caught up > to it by now. Imagine if the little box in Outlook and Exchange had > the MSA port already filled in, and you only needed to change it for > legacy things. > -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From mike at mtcc.com Tue Jun 16 02:53:36 2009 From: mike at mtcc.com (Michael Thomas) Date: Tue, 16 Jun 2009 00:53:36 -0700 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: <200906191814020.32BF5B92.29053@clifden.donelan.com> References: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> <20090618201445.GA38466@gweep.net> <1245356861.8442.6.camel@legolas.orthanc.ca> <4A3B43E7.70101@easyhosting.nl> <6108F574-380B-40E4-A48C-1B2DE4EE01BC@ianai.net> <4A3B5A57.7060003@easyhosting.nl> <200906191814020.32BF5B92.29053@clifden.donelan.com> Message-ID: <4A374F80.1030905@mtcc.com> Sean Donelan wrote: > On Fri, 19 Jun 2009, Jeroen Wunnink wrote: >> 1. Customers remember it more easily >> 2. Some ISP's also block 587 (hence 'SMTP ports' rather then 'SMTP >> port' in my previous comment ;-) > > Those same clueless ISPs will probably block 2525 someday too, > clueless expands to fill any void. And using non-standard things like > 2525 only lead to more confusion for customers later when they try > someone else's non-standard choice, e.g. port 26 or 24 or 5252 and > wonder why those don't work. > > On the other hand, why don't modern mail user agents and mail transfer > agents come configured to use MSA port 587 by default for message > submission instead of making customers remember anything? RFC 2476 was > published over a decade ago, software developers should have caught up > to it by now. Imagine if the little box in Outlook and Exchange had > the MSA port already filled in, and you only needed to change it for > legacy things. Better yet would be for the MUA to probe for the "best" configuration. Setting up mail is a royal PITA even if you know what you're doing. And a near death experience if you don't. Mike From kngspook at gmail.com Sat Jun 20 01:47:51 2009 From: kngspook at gmail.com (Neil) Date: Fri, 19 Jun 2009 23:47:51 -0700 Subject: OT: Wireless Network Strength Dependent On Wired Network? Message-ID: <77e4079b0906192347k74f0703dw986e3b7bd67f9310@mail.gmail.com> Okay, a small, offtopic question. (I figured you guys were a far more reliable source than my local ${electronics_store} salesperson...) Consider the following setup: internet pipe -> wired network -> (wireless router) wireless network -> computer1, computer2 Suppose the signal coming in on the pipe is good, but the signal deteriorates rapidly in wired network (old & bad wiring). Now, the two computers are connected via the wireless network only. computer1 has a great connection (it's in the same room as the wireless router), but computer2 is far away and drops the wireless connection frequently. Now, a former electrical engineer is claiming that if we improve the wired network so that the signal comes across better, then computer2 won't drop the wireless connection so frequently. (He says that the signal emitted by the wireless router will be improved by feeding it a better source signal.) I argue that there are two separate signals: the internet connection signal coming in on the pipe, and then the wireless network signal being emitted from the wireless router; and their strengths are independent. In other words, if we improve the wiring, the wireless signal will not get any stronger. So...basically, who's right? (Or are neither of us?) Any thoughts, comments, corrections? From bruns at 2mbit.com Sat Jun 20 03:21:39 2009 From: bruns at 2mbit.com (Brielle Bruns) Date: Sat, 20 Jun 2009 02:21:39 -0600 Subject: OT: Wireless Network Strength Dependent On Wired Network? In-Reply-To: <77e4079b0906192347k74f0703dw986e3b7bd67f9310@mail.gmail.com> References: <77e4079b0906192347k74f0703dw986e3b7bd67f9310@mail.gmail.com> Message-ID: <4A3C9C13.8070909@2mbit.com> On 6/20/09 12:47 AM, Neil wrote: > > Now, a former electrical engineer is claiming that if we improve the wired > network so that the signal comes across better, then computer2 won't drop > the wireless connection so frequently. (He says that the signal emitted by > the wireless router will be improved by feeding it a better source signal.) > He doesn't know what he's talking about. The two signals have nothing to do with one another - there is no direct connection between wired ethernet and wifi. You can not just plug an antenna into the end of a cat5e cable and expect it to work. In an easier to visualize path... if you have an ethernet card, and a 802.11g card in your desktop, yes, they may be attached to the same PCI bus, but the packets still have to come in one interface, be handled by the hardware on the card, passed down the PCI bus to the CPU where the software handles processing of the data, then passed back down the PCI bus to the other card, processed by that card, then transmitted by that card over whatever transport it uses. There's a few conversions going on during the path, throwing out garbage data, retransmitting, etc. If you shut off the antenna of the wifi card, it doesn't affect the ethernet card, and it will continue passing data for the computer to the LAN. If you unplug the cat5e, the wifi can still pass data between devices that communicate over wifi. I can go into alot more detail here, but moral of story, is don't let a electrical engineer that has no clue about how ethernet and wifi work tell you how packets get from one place to another, and how ethernet relates to wifi. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From patrick at ianai.net Sat Jun 20 03:38:01 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 20 Jun 2009 09:38:01 +0100 Subject: OT: Wireless Network Strength Dependent On Wired Network? In-Reply-To: <77e4079b0906192347k74f0703dw986e3b7bd67f9310@mail.gmail.com> References: <77e4079b0906192347k74f0703dw986e3b7bd67f9310@mail.gmail.com> Message-ID: Sent from my iPhone, please excuse any errors. On Jun 20, 2009, at 7:47, Neil wrote: > Consider the following setup: > internet pipe -> wired network -> (wireless router) wireless network > -> > computer1, computer2 > > Suppose the signal coming in on the pipe is good, but the signal > deteriorates rapidly in wired network (old & bad wiring). Now, the two > computers are connected via the wireless network only. computer1 has > a great > connection (it's in the same room as the wireless router), but > computer2 is > far away and drops the wireless connection frequently. > > Now, a former electrical engineer is claiming that if we improve the > wired > network so that the signal comes across better, then computer2 won't > drop > the wireless connection so frequently. (He says that the signal > emitted by > the wireless router will be improved by feeding it a better source > signal.) > > I argue that there are two separate signals: the internet connection > signal > coming in on the pipe, and then the wireless network signal being > emitted > from the wireless router; and their strengths are independent. In > other > words, if we improve the wiring, the wireless signal will not get any > stronger. Your EE friend is highly confused. Get a stronger WiFi transmitter or repeater. -- TTFN, patrick From sethm at rollernet.us Sat Jun 20 10:33:47 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 20 Jun 2009 08:33:47 -0700 Subject: OT: Wireless Network Strength Dependent On Wired Network? In-Reply-To: <77e4079b0906192347k74f0703dw986e3b7bd67f9310@mail.gmail.com> References: <77e4079b0906192347k74f0703dw986e3b7bd67f9310@mail.gmail.com> Message-ID: <4A3D015B.4020407@rollernet.us> Neil wrote: > Okay, a small, offtopic question. (I figured you guys were a far more > reliable source than my local ${electronics_store} salesperson...) > > Consider the following setup: > internet pipe -> wired network -> (wireless router) wireless network -> > computer1, computer2 > > Suppose the signal coming in on the pipe is good, but the signal > deteriorates rapidly in wired network (old & bad wiring). Now, the two > computers are connected via the wireless network only. computer1 has a great > connection (it's in the same room as the wireless router), but computer2 is > far away and drops the wireless connection frequently. > > Now, a former electrical engineer is claiming that if we improve the wired > network so that the signal comes across better, then computer2 won't drop > the wireless connection so frequently. (He says that the signal emitted by > the wireless router will be improved by feeding it a better source signal.) > > I argue that there are two separate signals: the internet connection signal > coming in on the pipe, and then the wireless network signal being emitted > from the wireless router; and their strengths are independent. In other > words, if we improve the wiring, the wireless signal will not get any > stronger. > The source signal is the device itself, not the wired portion. To prove it unplug the wired Ethernet and the signal will still be there (unless the radio goes down with loss of link). ~Seth From zartash at gmail.com Sat Jun 20 12:29:42 2009 From: zartash at gmail.com (Zartash Uzmi) Date: Sat, 20 Jun 2009 22:29:42 +0500 Subject: Network Providers (bandwidth-only and others) Message-ID: <4fff97de0906201029w60dd12cja7e2170a5f71ea25@mail.gmail.com> I am trying to categorize service providers into: (A) those who provide bandwidth only to end users or to other providers (perhaps Sprint, AT&T, Verizon and many regional and national ISPs fall in this category). (B) those who provide network-related services other than bandwidth (hosting, storage, computing). Everything such as Amazon SSS, EC2, Akamai, GoDaddy, etc. falls here. (C) those who provide a mix of bandwidth only and non-bandwidth only services (many local ISPs and perhaps AOL?) It would be great if you could provide input by answering the VERY brief questions below (either privately or on the list). I will share the compilation and maintain privacy if that is important to you. It would be great if I get responses from small as well as larger providers on the list (you know who you are :) ). 1. Which category do you fall in (A, B, or C)? 2. How many POPs/Datacenters do you own? 3. If you belong to C, then per unit of your revenue in each category, what in your opinion requires more electricity: the bandwidth-provisioning equipment (routers, switches, MuXes, etc.) or the hosting/storage equipment (servers, SAN, etc.)? 4. If you belong to C, can you make a rough guess of the ratio of electricity required by bandwidth provisioning equipment to hosting/storage equipment, per unit of revenue in each case? Thanks for your input. Regards, Zartash From tme at americafree.tv Sat Jun 20 15:11:02 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Sat, 20 Jun 2009 16:11:02 -0400 Subject: OT: Wireless Network Strength Dependent On Wired Network? In-Reply-To: <77e4079b0906192347k74f0703dw986e3b7bd67f9310@mail.gmail.com> References: <77e4079b0906192347k74f0703dw986e3b7bd67f9310@mail.gmail.com> Message-ID: <439941EF-788D-4D2D-B555-99956A6DB04A@americafree.tv> On Jun 20, 2009, at 2:47 AM, Neil wrote: > Okay, a small, offtopic question. (I figured you guys were a far more > reliable source than my local ${electronics_store} salesperson...) > > Consider the following setup: > internet pipe -> wired network -> (wireless router) wireless network > -> > computer1, computer2 > > Suppose the signal coming in on the pipe is good, but the signal > deteriorates rapidly in wired network (old & bad wiring). Now, the two > computers are connected via the wireless network only. computer1 has > a great > connection (it's in the same room as the wireless router), but > computer2 is > far away and drops the wireless connection frequently. > > Now, a former electrical engineer is claiming that if we improve the > wired > network so that the signal comes across better, then computer2 won't > drop > the wireless connection so frequently. (He says that the signal > emitted by > the wireless router will be improved by feeding it a better source > signal.) > If you are running a digital network, no. Digital doesn't work like that. The packets get through intact, or they are dropped. Dropping the wireless connection means that you are having trouble communicating between the wireless router and computer 2. Since computer 1 is close and works and computer 2 is far away, that strongly suggests that you have a SNR problem. To fix that, you need either a stronger access point (wireless router), another access point closer to computer 2, or a wireless repeater. Note that the AP also has to receive the signal from computer 2, and you probably can't boost computer 2's power, so you may not be able to fix this by just boosting the access point's power. There is a possibility that the problem is with computer 2. You might try swapping computer 1 and 2 to confirm that the problem is distance related, or (what I generally do) use a laptop as a test probe to confirm a good signal at computer 1, and a poor one at computer 2. > I argue that there are two separate signals: the internet connection > signal > coming in on the pipe, and then the wireless network signal being > emitted > from the wireless router; and their strengths are independent. In > other > words, if we improve the wiring, the wireless signal will not get any > stronger. > In the spacecraft world, what the wireless router is doing is called regeneration. It is not just amplifying the wireline signal it receives, it receives it, decodes it, turns it into bits, and then puts those bits out as a radio encoding. Any noise in the signal received is irrelevant, as long as it is not enough to cause the entire packet to be dropped. Regards Marshall > So...basically, who's right? (Or are neither of us?) Any thoughts, > comments, > corrections? > From nenolod at systeminplace.net Sat Jun 20 17:50:24 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Sat, 20 Jun 2009 22:50:24 +0000 Subject: Network Providers (bandwidth-only and others) Message-ID: <1465849391-1245538019-cardhu_decombobulator_blackberry.rim.net-905374239-@bxe1302.bisx.prod.on.blackberry> 1. C 2. 3 3. Hosting equipment by far. 4. 5:95, where 5 is the bandwidth equipment. William ------Original Message------ From: Zartash Uzmi To: nanog at nanog.org Subject: Network Providers (bandwidth-only and others) Sent: Jun 20, 2009 12:29 PM I am trying to categorize service providers into: (A) those who provide bandwidth only to end users or to other providers (perhaps Sprint, AT&T, Verizon and many regional and national ISPs fall in this category). (B) those who provide network-related services other than bandwidth (hosting, storage, computing). Everything such as Amazon SSS, EC2, Akamai, GoDaddy, etc. falls here. (C) those who provide a mix of bandwidth only and non-bandwidth only services (many local ISPs and perhaps AOL?) It would be great if you could provide input by answering the VERY brief questions below (either privately or on the list). I will share the compilation and maintain privacy if that is important to you. It would be great if I get responses from small as well as larger providers on the list (you know who you are :) ). 1. Which category do you fall in (A, B, or C)? 2. How many POPs/Datacenters do you own? 3. If you belong to C, then per unit of your revenue in each category, what in your opinion requires more electricity: the bandwidth-provisioning equipment (routers, switches, MuXes, etc.) or the hosting/storage equipment (servers, SAN, etc.)? 4. If you belong to C, can you make a rough guess of the ratio of electricity required by bandwidth provisioning equipment to hosting/storage equipment, per unit of revenue in each case? Thanks for your input. Regards, Zartash -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-866-519-6149 From dave.nanog at alfordmedia.com Sat Jun 20 19:45:53 2009 From: dave.nanog at alfordmedia.com (Dave Pooser) Date: Sat, 20 Jun 2009 20:45:53 -0400 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: <4A374F80.1030905@mtcc.com> Message-ID: >> On the other hand, why don't modern mail user agents and mail transfer >> agents come configured to use MSA port 587 by default for message >> submission instead of making customers remember anything? > Better yet would be for the MUA to probe for the "best" configuration. The iPhone mail app will try 587 and then fall back to 25 if 587 doesn't work, which strikes me as a model for others to emulate. -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com From orion at pirk.com Sun Jun 21 00:29:03 2009 From: orion at pirk.com (Steve Pirk) Date: Sat, 20 Jun 2009 22:29:03 -0700 (PDT) Subject: ipv6 only DNS? Message-ID: Anyone have any experience with dns and ipv6? I did a lookup on a host and it came back with only an ipv6 record. Also shows up in ident as a valid name. I was curious how an ipv6 only device would be able to hit my server. Details and more info off list, tonight if possible. -- steve From racribeiro at gmail.com Sun Jun 21 09:36:35 2009 From: racribeiro at gmail.com (Rui Ribeiro) Date: Sun, 21 Jun 2009 15:36:35 +0100 Subject: ipv6 only DNS? In-Reply-To: References: Message-ID: <943c86c90906210736o2a5e93edk12b1098f9b3641e3@mail.gmail.com> Hi Steve, An IPv6 only device can "hit" your server if all the DNS hierachy resolves through IPv6. It works the same way as in IPv4. Rui 2009/6/21 Steve Pirk : > Anyone have any experience with dns and ipv6? I did a lookup on a host and > it came back with only an ipv6 record. Also shows up in ident as a valid > name. I was curious how an ipv6 only device would be able to hit my server. > > Details and more info off list, tonight if possible. > > -- > steve > > From jabley at hopcount.ca Sun Jun 21 11:06:51 2009 From: jabley at hopcount.ca (Joe Abley) Date: Sun, 21 Jun 2009 12:06:51 -0400 Subject: ipv6 only DNS? In-Reply-To: <943c86c90906210736o2a5e93edk12b1098f9b3641e3@mail.gmail.com> References: <943c86c90906210736o2a5e93edk12b1098f9b3641e3@mail.gmail.com> Message-ID: On 21-Jun-2009, at 10:36, Rui Ribeiro wrote: > An IPv6 only device can "hit" your server if all the DNS hierachy > resolves through IPv6. It works the same way as in IPv4. "Resolves through IPv6" implies a mixture of IPv6 transport and RRSet availability. To add some more details, you need: - AAAA records in your hints file, so you can complete a useful priming query - AAAA glue in the zones being followed to answer your questions, from the root down - all NS sets above every zone cut to include at least one reachable nameserver that can be queried using IPv6 transport - the resources you're ultimately looking for to have AAAA records (assuming your goal is to find an address) Some time ago I checked the ORG and INFO registries and discovered that the number of host objects there with IPv6 address attributes was very small. I presumed at the time that it was either hard to find a registrar that would support IPv6 addresses for hosts, or that people were just not paying much attention to v6-only resolution. Joe From stephen at sprunk.org Sun Jun 21 11:39:39 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 21 Jun 2009 11:39:39 -0500 Subject: ipv6 only DNS? In-Reply-To: References: <943c86c90906210736o2a5e93edk12b1098f9b3641e3@mail.gmail.com> Message-ID: <4A3E624B.4030602@sprunk.org> Joe Abley wrote: > Some time ago I checked the ORG and INFO registries and discovered > that the number of host objects there with IPv6 address attributes was > very small. I presumed at the time that it was either hard to find a > registrar that would support IPv6 addresses for hosts, or that people > were just not paying much attention to v6-only resolution. At least for now, it's pretty well accepted that basic servers like DNS, SMTP, IMAP, HTTP proxies, etc. MUST be dual-stacked for the duration of the transition. Even if your clients are IPv6-only, they can still resolve hostnames, send mail, surf the web, etc. to sites that are IPv4-only via those few servers. Generic, scalable solutions would be better rather than protocol-specific proxies of course, and the IETF is working on that angle, but in the meantime it'll allow the most common client-server protocols to keep working and get some experience with IPv6. Also, keep in mind that the vast majority of folks out there still can't get native IPv6 transit from their upstreams and may not be willing to trust free tunnel brokers with production traffic to their servers. Even if they can, most eyeballs trying to hit them are still IPv4-only and the few IPv6 eyeballs can be assumed to have proxies since otherwise they couldn't see 99.9999% of the Internet. This is what it looks like before critical mass is achieved. 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 joelja at bogus.com Sun Jun 21 16:45:36 2009 From: joelja at bogus.com (joel jaeggli) Date: Sun, 21 Jun 2009 14:45:36 -0700 Subject: ipv6 only DNS? Message-ID: <943c86c90906210736o2a5e93edk12b1098f9b3641e3@mail.gmail.com> In pratice, most clients are not their own recursive resolvers. Rui Ribeiro wrote: >Hi Steve, > >An IPv6 only device can "hit" your server if all the DNS hierachy >resolves through IPv6. It works the same way as in IPv4. > >Rui > >2009/6/21 Steve Pirk : >> Anyone have any experience with dns and ipv6? I did a lookup on a host and >> it came back with only an ipv6 record. Also shows up in ident as a valid >> name. I was curious how an ipv6 only device would be able to hit my server. >> >> Details and more info off list, tonight if possible. >> >> -- >> steve >> >> > From hugh at open.com.au Sun Jun 21 22:27:45 2009 From: hugh at open.com.au (Hugh Irvine) Date: Mon, 22 Jun 2009 13:27:45 +1000 Subject: Wireless bridge In-Reply-To: <4A3B6622.7080301@spectraaccess.com> References: <005c01c9f015$852ae490$8f80adb0$@com> <4A3B21B7.5040808@sharpone.net> <4A3B6622.7080301@spectraaccess.com> Message-ID: <4BAB5FDE-5469-467C-81AA-372AFBCF83D9@open.com.au> Hello - On this same topic does anyone have any experience with the Linksys WAP200E? thanks and regards Hugh On 19 Jun 2009, at 20:19, Bret Clark wrote: > Justin Sharp wrote: >> I didn't read through all of the replies to see if this was >> suggested, apologies if it was. >> >> http://www.solectek.com/products.php?prod=sw7k&page=feat >> >> I implemented a PTP link at about 3 miles using these Solectek >> radios. I get 40Mbps consistently with TCP traffic and ~100Mbps >> UDP. This PTP link has literally been up for 3 years (in 2 weeks) >> without failing. I live in a 4 seaons state, so its seen all sorts >> of weather over those years. I have clean line of site down the >> freeway for what its worth. Its natively powered via POE, power >> injector included. We run all sorts of usual business application >> over this link, including about 30 simultaneous VOIP channels, and >> have not had one issue with stability. I was also told by the VAR >> that sold us the product that a city nearby (can't remember which >> one) connects all of its municipal buildings with Solectek stuff >> and runs its VOIP infrastructure over it as well. >> >> We run it in bridged mode with routers on each end, but it does >> support some rudimentary L3 stuff, static routing and RIP. >> >> IIRC, they were not "cheap" (couple of 1k), but for us have >> definitely been much cheaper than private circuits from carriers of >> comparable throughput capacity. >> >> Hope its helpful. >> >> --Justin >> > I have to say I did a double take on your speed claims. We use > Solectek all over the place and have yet to archived those speeds on > any of our links. Not only that Solectek engineers have told us that > at a 108mbps radio rate realistically you are only going to see only > 35mbps data rate on link that's just a mile apart; further you go > the less bandwidth you will have. > > Other then that, I agree they are nice radios and even include > heaters in them to help maintain temperatures above freezing during > winter time so that ice buildup doesn't cause a problem. > > Bret > NB: Have you read the reference manual ("doc/ref.html")? Have you searched the mailing list archive (www.open.com.au/archives/radiator)? Have you had a quick look on Google (www.google.com)? Have you included a copy of your configuration file (no secrets), together with a trace 4 debug showing what is happening? Have you checked the RadiusExpert wiki: http://www.open.com.au/wiki/index.php/Main_Page -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows, MacOS X. Includes support for reliable RADIUS transport (RadSec), and DIAMETER translation agent. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. - CATool: Private Certificate Authority for Unix and Unix-like systems. From Alain_Durand at cable.comcast.com Mon Jun 22 08:31:35 2009 From: Alain_Durand at cable.comcast.com (Durand, Alain) Date: Mon, 22 Jun 2009 09:31:35 -0400 Subject: ipv6 only DNS? In-Reply-To: <943c86c90906210736o2a5e93edk12b1098f9b3641e3@mail.gmail.com> Message-ID: I would suggest to read RFC3901/BCP91: ?DNS IPv6 Transport Operational Guidelines? on this topic. - Alain. On 6/21/09 5:45 PM, "joel jaeggli" wrote: > In pratice, most clients are not their own recursive resolvers. > > Rui Ribeiro wrote: > >> >Hi Steve, >> > >> >An IPv6 only device can "hit" your server if all the DNS hierachy >> >resolves through IPv6. It works the same way as in IPv4. >> > >> >Rui >> > >> >2009/6/21 Steve Pirk : >>> >> Anyone have any experience with dns and ipv6? I did a lookup on a host >>> and >>> >> it came back with only an ipv6 record. Also shows up in ident as a valid >>> >> name. I was curious how an ipv6 only device would be able to hit my >>> server. >>> >> >>> >> Details and more info off list, tonight if possible. >>> >> >>> >> -- >>> >> steve >>> >> >>> >> >> > > From frnkblk at iname.com Mon Jun 22 08:50:16 2009 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 22 Jun 2009 08:50:16 -0500 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: <4A374F80.1030905@mtcc.com> References: <01aa01c9f04c$1d0a8820$e76ed48d@zhiyunpc> <20090618201445.GA38466@gweep.net> <1245356861.8442.6.camel@legolas.orthanc.ca> <4A3B43E7.70101@easyhosting.nl> <6108F574-380B-40E4-A48C-1B2DE4EE01BC@ianai.net> <4A3B5A57.7060003@easyhosting.nl> <200906191814020.32BF5B92.29053@clifden.donelan.com> <4A374F80.1030905@mtcc.com> Message-ID: Outlook supports Automatic Account Configuration, but unfortunately it seems to be only for Outlook, not OE or WM. It's a pity that MAAWG or another group hasn't written a specification for the automatic downloading of configuration (with certificates, to be sure, for some kind of repudiation) and the update thereof, for adoption by the leading consumer e-mail clients. Frank -----Original Message----- From: Michael Thomas [mailto:mike at mtcc.com] Sent: Tuesday, June 16, 2009 2:54 AM To: Sean Donelan Cc: North American Operators' Group Subject: Re: Is your ISP blocking outgoing port 25? Better yet would be for the MUA to probe for the "best" configuration. Setting up mail is a royal PITA even if you know what you're doing. And a near death experience if you don't. Mike From sip.vsp.5060 at gmail.com Mon Jun 22 09:13:34 2009 From: sip.vsp.5060 at gmail.com (sip vsp) Date: Mon, 22 Jun 2009 07:13:34 -0700 Subject: verizon issue? Message-ID: <501309d50906220713x577c9b35w919fb0e7a2870ebc@mail.gmail.com> Did anyone have trouble with Verizon over the weekend? From James.Kennedy at tradingtechnologies.com Mon Jun 22 09:20:11 2009 From: James.Kennedy at tradingtechnologies.com (James Kennedy (TT)) Date: Mon, 22 Jun 2009 09:20:11 -0500 Subject: verizon issue? In-Reply-To: <501309d50906220713x577c9b35w919fb0e7a2870ebc@mail.gmail.com> References: <501309d50906220713x577c9b35w919fb0e7a2870ebc@mail.gmail.com> Message-ID: Yes, They did some maintenance that I think went bad. -----Original Message----- From: sip vsp [mailto:sip.vsp.5060 at gmail.com] Sent: Monday, June 22, 2009 9:14 AM To: nanog at nanog.org Subject: verizon issue? Did anyone have trouble with Verizon over the weekend? From johnl at iecc.com Mon Jun 22 09:24:02 2009 From: johnl at iecc.com (John Levine) Date: 22 Jun 2009 14:24:02 -0000 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: Message-ID: <20090622142402.1330.qmail@simone.iecc.com> >It's a pity that MAAWG or another group hasn't written a >specification for the automatic downloading of configuration (with >certificates, to be sure, for some kind of repudiation) and the >update thereof, for adoption by the leading consumer e-mail clients. MAAWG decided it's not in the standards business, but it does BCPs pointing at standards elsewhere (mostly the IETF) that it encourages people to follow. Write a standard that people can use, and I don't think I'd have much trouble getting them to endorse it. It's an interesting design topic, particularly the bootstrap question of how the client decides where to look for its configuration. A lot of this stuff is already available via DHCP, but of course a key goal here is to set config info the last across reboots on different networks. Followup to IETF-something, I suspect. R's, John From frnkblk at iname.com Mon Jun 22 10:13:31 2009 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 22 Jun 2009 10:13:31 -0500 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: <20090622142402.1330.qmail@simone.iecc.com> References: <20090622142402.1330.qmail@simone.iecc.com> Message-ID: The bootstrap question is addressed by requiring the end-user to know their e-mail address and password. Based on the domain name, the implementation would reach out to https://something.domain-name.tld and download the relevant "schema" and data for IMAP, SMTP, POP3, etc, in ordered priority. Based on what the e-mail client could support, the desired settings would be displayed, and upon end-user approval, applied. This could be leveraged by RIM for their BIS, Microsoft/Gmail/etc for smartphones, and for third-party webmail hosts such as mail2web.com Frank -----Original Message----- From: John Levine [mailto:johnl at iecc.com] Sent: Monday, June 22, 2009 9:24 AM To: nanog at nanog.org Cc: frnkblk at iname.com Subject: Re: Is your ISP blocking outgoing port 25? >It's a pity that MAAWG or another group hasn't written a >specification for the automatic downloading of configuration (with >certificates, to be sure, for some kind of repudiation) and the >update thereof, for adoption by the leading consumer e-mail clients. MAAWG decided it's not in the standards business, but it does BCPs pointing at standards elsewhere (mostly the IETF) that it encourages people to follow. Write a standard that people can use, and I don't think I'd have much trouble getting them to endorse it. It's an interesting design topic, particularly the bootstrap question of how the client decides where to look for its configuration. A lot of this stuff is already available via DHCP, but of course a key goal here is to set config info the last across reboots on different networks. Followup to IETF-something, I suspect. R's, John From mhuff at ox.com Mon Jun 22 10:19:37 2009 From: mhuff at ox.com (Matthew Huff) Date: Mon, 22 Jun 2009 11:19:37 -0400 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: References: <20090622142402.1330.qmail@simone.iecc.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F9C381C14373@PUR-EXCH07.ox.com> It already is used by Microsoft. Do a google for +Microsoft +Autodiscover. It is used by Outlook for Windows, Entourage for Mac, the iPhone and Windows Mobile devices. Like you suggested, it uses DNS based on the users email address and looks for a series of resolvable addresses the easiest being autodiscover.domain-name.tld (it has others because of SSL cert flexibility). It uses that address to download an XML file. The only tricky thing to set it up is that a lot of the documentation out there is dated. It has changed since it was first released and a lot of the documentation on technical blogs, and even on Microsoft's web site are incorrect. Once it's setup, however, it's great. ---- 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: Frank Bulk [mailto:frnkblk at iname.com] > Sent: Monday, June 22, 2009 11:14 AM > To: 'John Levine'; nanog at nanog.org > Subject: RE: Is your ISP blocking outgoing port 25? > > The bootstrap question is addressed by requiring the end-user to know > their > e-mail address and password. Based on the domain name, the > implementation > would reach out to https://something.domain-name.tld and download the > relevant "schema" and data for IMAP, SMTP, POP3, etc, in ordered > priority. > Based on what the e-mail client could support, the desired settings > would be > displayed, and upon end-user approval, applied. This could be leveraged > by > RIM for their BIS, Microsoft/Gmail/etc for smartphones, and for third- > party > webmail hosts such as mail2web.com > > Frank > > -----Original Message----- > From: John Levine [mailto:johnl at iecc.com] > Sent: Monday, June 22, 2009 9:24 AM > To: nanog at nanog.org > Cc: frnkblk at iname.com > Subject: Re: Is your ISP blocking outgoing port 25? > > >It's a pity that MAAWG or another group hasn't written a > >specification for the automatic downloading of configuration (with > >certificates, to be sure, for some kind of repudiation) and the > >update thereof, for adoption by the leading consumer e-mail clients. > > MAAWG decided it's not in the standards business, but it does BCPs > pointing at standards elsewhere (mostly the IETF) that it encourages > people to follow. Write a standard that people can use, and I don't > think I'd have much trouble getting them to endorse it. > > It's an interesting design topic, particularly the bootstrap question > of how the client decides where to look for its configuration. A lot > of this stuff is already available via DHCP, but of course a key goal > here is to set config info the last across reboots on different > networks. > > Followup to IETF-something, I suspect. > > R's, > John > -------------- 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 frnkblk at iname.com Mon Jun 22 10:52:41 2009 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 22 Jun 2009 10:52:41 -0500 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9C381C14373@PUR-EXCH07.ox.com> References: <20090622142402.1330.qmail@simone.iecc.com> <483E6B0272B0284BA86D7596C40D29F9C381C14373@PUR-EXCH07.ox.com> Message-ID: That?s e-mail client list covers less than 5% of my customer base and can't be construed as a standard. =) Even Microsoft doesn't support it in Outlook Express or Windows Mail. Frank -----Original Message----- From: Matthew Huff [mailto:mhuff at ox.com] Sent: Monday, June 22, 2009 10:20 AM To: 'frnkblk at iname.com'; 'John Levine'; 'nanog at nanog.org' Subject: RE: Is your ISP blocking outgoing port 25? It already is used by Microsoft. Do a google for +Microsoft +Autodiscover. It is used by Outlook for Windows, Entourage for Mac, the iPhone and Windows Mobile devices. Like you suggested, it uses DNS based on the users email address and looks for a series of resolvable addresses the easiest being autodiscover.domain-name.tld (it has others because of SSL cert flexibility). It uses that address to download an XML file. The only tricky thing to set it up is that a lot of the documentation out there is dated. It has changed since it was first released and a lot of the documentation on technical blogs, and even on Microsoft's web site are incorrect. Once it's setup, however, it's great. ---- 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: Frank Bulk [mailto:frnkblk at iname.com] > Sent: Monday, June 22, 2009 11:14 AM > To: 'John Levine'; nanog at nanog.org > Subject: RE: Is your ISP blocking outgoing port 25? > > The bootstrap question is addressed by requiring the end-user to know > their > e-mail address and password. Based on the domain name, the > implementation > would reach out to https://something.domain-name.tld and download the > relevant "schema" and data for IMAP, SMTP, POP3, etc, in ordered > priority. > Based on what the e-mail client could support, the desired settings > would be > displayed, and upon end-user approval, applied. This could be leveraged > by > RIM for their BIS, Microsoft/Gmail/etc for smartphones, and for third- > party > webmail hosts such as mail2web.com > > Frank > > -----Original Message----- > From: John Levine [mailto:johnl at iecc.com] > Sent: Monday, June 22, 2009 9:24 AM > To: nanog at nanog.org > Cc: frnkblk at iname.com > Subject: Re: Is your ISP blocking outgoing port 25? > > >It's a pity that MAAWG or another group hasn't written a > >specification for the automatic downloading of configuration (with > >certificates, to be sure, for some kind of repudiation) and the > >update thereof, for adoption by the leading consumer e-mail clients. > > MAAWG decided it's not in the standards business, but it does BCPs > pointing at standards elsewhere (mostly the IETF) that it encourages > people to follow. Write a standard that people can use, and I don't > think I'd have much trouble getting them to endorse it. > > It's an interesting design topic, particularly the bootstrap question > of how the client decides where to look for its configuration. A lot > of this stuff is already available via DHCP, but of course a key goal > here is to set config info the last across reboots on different > networks. > > Followup to IETF-something, I suspect. > > R's, > John > From vbono at 2nplus1.com Mon Jun 22 11:26:46 2009 From: vbono at 2nplus1.com (Vincent J. Bono) Date: Mon, 22 Jun 2009 12:26:46 -0400 (EDT) Subject: Passive DWDM in Production Service Message-ID: <27883863.21881245688006978.JavaMail.root@mail.2nplus1.com> Hey Everyone, If anyone is using, in production, passive DWDM muxes / shelves with colored 1GigE or 10GigE optics in standard switches or routers drop me a private note? I'm looking for real world examples for a white paper. Thanks in Advance, Vin From johnl at iecc.com Mon Jun 22 11:38:14 2009 From: johnl at iecc.com (John R. Levine) Date: Mon, 22 Jun 2009 17:38:14 +0100 (BST) Subject: Is your ISP blocking outgoing port 25? In-Reply-To: References: <20090622142402.1330.qmail@simone.iecc.com> Message-ID: > The bootstrap question is addressed by requiring the end-user to know their > e-mail address and password. Based on the domain name, the implementation > would reach out to https://something.domain-name.tld and download the > relevant "schema" and data for IMAP, SMTP, POP3, etc, in ordered priority. > Based on what the e-mail client could support, the desired settings would be > displayed, and upon end-user approval, applied. End-user approval? That means support calls, ISPs wouldn't like that. I can believe something like this could be made to work, but I would think hard about all the way that web sessions can get screwed up or hijacked before I persuaded myself that a scheme was likely to work where it needed to work (e.g., when connecting to a hotspot that hijacks all web sessions until you log in) while not being subject to hostile spoofing. Followups definitely to IETF-something. R's, John From mulitskiy at acedsl.com Mon Jun 22 12:32:48 2009 From: mulitskiy at acedsl.com (Michael Ulitskiy) Date: Mon, 22 Jun 2009 13:32:48 -0400 Subject: verizon issue? In-Reply-To: References: <501309d50906220713x577c9b35w919fb0e7a2870ebc@mail.gmail.com> Message-ID: <200906221332.48970.mulitskiy@acedsl.com> Can you be more specific about the problem saw? We're having problems with their oc3 right now, not being able to push over 110m since this morning and still going on. And sure can't get anything useful from verizon. Thanks, Michael On Monday 22 June 2009 10:20:11 am James Kennedy (TT) wrote: > Yes, > > They did some maintenance that I think went bad. > > -----Original Message----- > From: sip vsp [mailto:sip.vsp.5060 at gmail.com] > Sent: Monday, June 22, 2009 9:14 AM > To: nanog at nanog.org > Subject: verizon issue? > > Did anyone have trouble with Verizon over the weekend? > > > From James.Kennedy at tradingtechnologies.com Mon Jun 22 12:38:37 2009 From: James.Kennedy at tradingtechnologies.com (James Kennedy (TT)) Date: Mon, 22 Jun 2009 12:38:37 -0500 Subject: verizon issue? Message-ID: Using there metro ethernet service we saw our circuit not recover after scheduled maintenance. Verizon backed out the change and our service was restored. ----- Original Message ----- From: Michael Ulitskiy To: nanog at nanog.org Sent: Mon Jun 22 12:32:48 2009 Subject: Re: verizon issue? Can you be more specific about the problem saw? We're having problems with their oc3 right now, not being able to push over 110m since this morning and still going on. And sure can't get anything useful from verizon. Thanks, Michael On Monday 22 June 2009 10:20:11 am James Kennedy (TT) wrote: > Yes, > > They did some maintenance that I think went bad. > > -----Original Message----- > From: sip vsp [mailto:sip.vsp.5060 at gmail.com] > Sent: Monday, June 22, 2009 9:14 AM > To: nanog at nanog.org > Subject: verizon issue? > > Did anyone have trouble with Verizon over the weekend? > > > From morrowc.lists at gmail.com Mon Jun 22 13:25:01 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 22 Jun 2009 14:25:01 -0400 Subject: verizon issue? In-Reply-To: References: Message-ID: <75cb24520906221125l157452b1wbd87adc03f4f0b88@mail.gmail.com> On Mon, Jun 22, 2009 at 1:38 PM, James Kennedy (TT) wrote: > Using there metro ethernet service we saw our circuit not recover after scheduled maintenance. Verizon backed out the change and our service was restored. also, there are many heads on the verizon hydra, giving some clue as to what part you are attempting to slay will help others out as well, for instance: "Did anyone have problems with verizon consumer dsl/fios customers this weekend?" "Did anyone notice problems with verizon wireless phone/sms/data this weekend?" "Did anyone notice problems with verizon wholesale (as701/2/3) internet services this weekend?" "Did anyone notice issues with verizon private line services?" (mple covered in this scenario) cause yea, my verizon landline phone had a problem... but I'm betting no one (even me) really cares about that. -chris > ----- Original Message ----- > From: Michael Ulitskiy > To: nanog at nanog.org > Sent: Mon Jun 22 12:32:48 2009 > Subject: Re: verizon issue? > > Can you be more specific about the problem saw? > We're having problems with their oc3 right now, not being able to push over 110m since this morning and still going on. > And sure can't get anything useful from verizon. > Thanks, > > Michael > > On Monday 22 June 2009 10:20:11 am James Kennedy (TT) wrote: >> Yes, >> >> They did some maintenance that I think went bad. >> >> -----Original Message----- >> From: sip vsp [mailto:sip.vsp.5060 at gmail.com] >> Sent: Monday, June 22, 2009 9:14 AM >> To: nanog at nanog.org >> Subject: verizon issue? >> >> Did anyone have trouble with Verizon over the weekend? >> >> >> > > From jvanick at oaknet.com Mon Jun 22 13:30:18 2009 From: jvanick at oaknet.com (Jason Vanick) Date: Mon, 22 Jun 2009 13:30:18 -0500 Subject: verizon issue? In-Reply-To: <75cb24520906221125l157452b1wbd87adc03f4f0b88@mail.gmail.com> References: <75cb24520906221125l157452b1wbd87adc03f4f0b88@mail.gmail.com> Message-ID: <11E7673500B14C51B433BA27661BCFB4@ds.ad.adp.com> Saw/and see the same problems here. Vzb Oc3 in Chicago... Normal business traffic dropped at around 9:45am CDT from 30-40mb/sec to 10mb/sec... lasted until roughly 10:30am CDT Inbound connectivity from some areas of the country affected, but not all. This seems to happen at least once every 90 days for us. VZB always says "no trouble found" when we open a ticket. -J -----Original Message----- From: Christopher Morrow [mailto:morrowc.lists at gmail.com] Sent: Monday, June 22, 2009 1:25 PM To: James Kennedy (TT) Cc: nanog at nanog.org Subject: Re: verizon issue? On Mon, Jun 22, 2009 at 1:38 PM, James Kennedy (TT) wrote: > Using there metro ethernet service we saw our circuit not recover after scheduled maintenance. Verizon backed out the change and our service was restored. also, there are many heads on the verizon hydra, giving some clue as to what part you are attempting to slay will help others out as well, for instance: "Did anyone have problems with verizon consumer dsl/fios customers this weekend?" "Did anyone notice problems with verizon wireless phone/sms/data this weekend?" "Did anyone notice problems with verizon wholesale (as701/2/3) internet services this weekend?" "Did anyone notice issues with verizon private line services?" (mple covered in this scenario) cause yea, my verizon landline phone had a problem... but I'm betting no one (even me) really cares about that. -chris > ----- Original Message ----- > From: Michael Ulitskiy > To: nanog at nanog.org > Sent: Mon Jun 22 12:32:48 2009 > Subject: Re: verizon issue? > > Can you be more specific about the problem saw? > We're having problems with their oc3 right now, not being able to push over 110m since this morning and still going on. > And sure can't get anything useful from verizon. > Thanks, > > Michael > > On Monday 22 June 2009 10:20:11 am James Kennedy (TT) wrote: >> Yes, >> >> They did some maintenance that I think went bad. >> >> -----Original Message----- >> From: sip vsp [mailto:sip.vsp.5060 at gmail.com] >> Sent: Monday, June 22, 2009 9:14 AM >> To: nanog at nanog.org >> Subject: verizon issue? >> >> Did anyone have trouble with Verizon over the weekend? >> >> >> > > From hardie at qualcomm.com Mon Jun 22 14:06:47 2009 From: hardie at qualcomm.com (Ted Hardie) Date: Mon, 22 Jun 2009 12:06:47 -0700 Subject: Is your ISP blocking outgoing port 25? In-Reply-To: References: <20090622142402.1330.qmail@simone.iecc.com> Message-ID: At 9:38 AM -0700 6/22/09, John R. Levine wrote: > > The bootstrap question is addressed by requiring the end-user to know their >> e-mail address and password. Based on the domain name, the implementation >> would reach out to https://something.domain-name.tld and download the >> relevant "schema" and data for IMAP, SMTP, POP3, etc, in ordered priority. >> Based on what the e-mail client could support, the desired settings would be >> displayed, and upon end-user approval, applied. > >End-user approval? That means support calls, ISPs wouldn't like that. > >I can believe something like this could be made to work, but I would think >hard about all the way that web sessions can get screwed up or hijacked >before I persuaded myself that a scheme was likely to work where it needed >to work (e.g., when connecting to a hotspot that hijacks all web sessions >until you log in) while not being subject to hostile spoofing. > >Followups definitely to IETF-something. I would suggest following up at discuss at apps.ietf.org; the folks there can point you to things like RFC 2244 (ACAP, the Application Configuration Access Protocol), describe why that got turned in XCAP by the RAI area (RFC 4825, primarily used in SIP contexts but designed to be multi-use), and caution you that the many hours spent designing these things have not generally born fruit in the marketplace. Is this possible for email? Sure. With strong support from a vendor with a tied house model (e.g. RIM or Apple), it might even get to be popular. But as a general purpose approach, it has not hit that sweet spot. regards, Ted Hardie >R's, >John From alexb at ripe.net Mon Jun 22 16:08:59 2009 From: alexb at ripe.net (Alex Band) Date: Mon, 22 Jun 2009 23:08:59 +0200 Subject: =?ISO-8859-1?Q?Interview:_Patrik_F=E4ltstr=F6m_on_the_role_of_go?= =?ISO-8859-1?Q?vernment_in_IPv6_deployment?= Message-ID: We uploaded another interview: http://www.youtube.com/watch?v=zrE1TEan4Jo To make sure we cover as many areas of the industry as possible, we asked Patrik F?ltstr?m on the role of government in IPv6 deployment. Patrik is Senior Consulting Engineer with Cisco, but has served as an advisor to the Swedish government on IT policy since 2003. In the interview, he makes a note about the American government as well. I hope you enjoy it. If you have feedback on specific topics you would like to see covered in future interviews, please let us know. We appreciate your comments. Alex Band RIPE NCC From jrhett at netconsonance.com Mon Jun 22 22:38:23 2009 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon, 22 Jun 2009 20:38:23 -0700 Subject: ftc shuts down a colo and ip provider In-Reply-To: References: Message-ID: <588DF063-5AF9-4557-8F55-15FE1A7085A6@netconsonance.com> On Jun 4, 2009, at 9:38 PM, Randy Bush wrote: > http://voices.washingtonpost.com/securityfix/2009/06/ftc_sues_shuts_down_n_calif_we.html > > while allegedly a black hat, this is the first case i know of in which > the usg has shut down an isp. nose of camel? first they came for ... It's good to see them finally taking action. I see what you are saying, but this isn't the case of "maybe kindof bad" -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From matthew at walster.org Tue Jun 23 03:11:09 2009 From: matthew at walster.org (Matthew Walster) Date: Tue, 23 Jun 2009 09:11:09 +0100 Subject: Passive DWDM in Production Service In-Reply-To: <27883863.21881245688006978.JavaMail.root@mail.2nplus1.com> References: <27883863.21881245688006978.JavaMail.root@mail.2nplus1.com> Message-ID: If it's passive, surely it doesn't matter whether it's 1GigE, 10GigE or whatever, it's passive - it just uses mirrors and lenses to add the signals into one big chunky trunk port feed? M 2009/6/22 Vincent J. Bono : > Hey Everyone, > > If anyone is using, in production, passive DWDM muxes / shelves with colored 1GigE or 10GigE optics in standard switches or routers drop me a private note? ?I'm looking for real world examples for a white paper. > > Thanks in Advance, > Vin > > > > > > From peter at peter-dambier.de Tue Jun 23 03:53:29 2009 From: peter at peter-dambier.de (Peter Dambier) Date: Tue, 23 Jun 2009 10:53:29 +0200 Subject: ftc shuts down a colo and ip provider In-Reply-To: <588DF063-5AF9-4557-8F55-15FE1A7085A6@netconsonance.com> References: <588DF063-5AF9-4557-8F55-15FE1A7085A6@netconsonance.com> Message-ID: <4A409809.7030107@peter-dambier.de> Don't mention Spamhaus (versus nic.at) Maybe that is the reason why they introduced censoring the day before yesterday here in germany. Just got a nice stop sign when I looked up spamhaus saying the site is inapropriate for my computer. Don't believe it - it's just been a bad dream. I fully agree with what they did (not spamhaus or our government of coarse) Kind regards Peter Jo Rhett wrote: > On Jun 4, 2009, at 9:38 PM, Randy Bush wrote: >> http://voices.washingtonpost.com/securityfix/2009/06/ftc_sues_shuts_down_n_calif_we.html >> >> >> while allegedly a black hat, this is the first case i know of in which >> the usg has shut down an isp. nose of camel? first they came for ... > > > It's good to see them finally taking action. I see what you are > saying, but this isn't the case of "maybe kindof bad" > -- 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 Ian.Goodall at ci-net.com Tue Jun 23 06:51:50 2009 From: Ian.Goodall at ci-net.com (Ian Goodall) Date: Tue, 23 Jun 2009 12:51:50 +0100 Subject: BT / Yahoo Mail Contacts In-Reply-To: References: Message-ID: Hi List, Does anyone have a clueful contact in BT / Yahoo Mail? We are a UK ISP having problems sending mail to their recipients and are getting no where completing their endless online forms... Thanks Ian -- Ian Goodall Senior Network Engineer, CI-Net CI-Net, Network House, Langford Locks, Kidlington, OX5 1GA Tel: +44 1865 856000 email: ian.goodall at ci-net.com Fax: +44 1865 856001 web: http://www.ci-net.com CI-Net - A company registered in England and Wales number 3155758 From itmailinglist at connection2.com Tue Jun 23 07:12:15 2009 From: itmailinglist at connection2.com (IT Mailing List) Date: Tue, 23 Jun 2009 13:12:15 +0100 Subject: Nokia email Support contact Message-ID: Hi everyone, Would there be anyone here from Nokia in there IT email support here or have a contact for there IT Support preferably email support? Please contact me off-list. Thank and best regards, Alexander Alexander Schumann IT Manager Tel: +353 (0)1 243 6754 Fax: +353 (0)1 243 6701 www.connection2.com P Please consider the environment before printing this email. This email and any attachments are confidential and are intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient you may take no action based upon this email, nor may you copy or distribute it to anyone. Please contact the sender if you believe you have received this in error and delete the email message and any attachments. From carlos at race.com Tue Jun 23 13:59:10 2009 From: carlos at race.com (Carlos Alcantar) Date: Tue, 23 Jun 2009 11:59:10 -0700 Subject: sprint wholesale Message-ID: <859604546CD1FF488BDB6EA94C896AFB8AB2D9@racexchange.race.local> Anyone on the list from sprint wholesale side please contact me trying to get a sales rep all the numbers listed on the website go to a busy signal. Or if anyone has a rep please send me over there info off line thanks. -carlos From nanog at mathezer.com Tue Jun 23 14:50:41 2009 From: nanog at mathezer.com (Stephen Mathezer) Date: Tue, 23 Jun 2009 13:50:41 -0600 Subject: Ticketmaster contact? - out of options Message-ID: <4A413211.8070907@mathezer.com> Is there anyone from Ticketmaster on list, or can anyone provide me with a decent technical contact? I have tried their "Global Monitoring Support" organization by phone and by email with little success. We have several thousand users NATing behind a single IP address. Ticketmaster is blackholing this IP on a regular basis, presumably due to volume of requests. If we change the NAT, the problem quickly crops up again. Their GMS support team has supposedly fixed this multiple times, but in fact have not. Any suggestions? thanks -Steve From randy at psg.com Tue Jun 23 14:51:01 2009 From: randy at psg.com (Randy Bush) Date: Tue, 23 Jun 2009 12:51:01 -0700 Subject: Use of Default in the DFZ: banned in philly, see it now on the net! Message-ID: due to nanog pc silliness, my lightning talk on $subject was not given in philly. i had promised to report to nanog the results of our winter experiment which used as path poisoning. here is the lightning talk i would have given. http://archive.psg.com/090615.nanog-default.pdf this is really meant to be a talk, so the slides can be a bit hard. on slide 6 /20 is the as path length of a /20, i.e. a 'normal' distribution, as seen from bgp monitors at RV, RIS, and a jillion others /25 is the as path length distribution we saw pinging from the /25 BGP is the as path length distribution we saw from RV/RIS i.e. BGP views are significantly skewed. but most of us knew that. on slides 10 and 11, the categories stub, small isp, large isp are from a ucla study. imiho, you should take them with a grain of salt. on 12, the reason for the funniness around 30 test points is because, we really wanted >= 30 test points in an AS. so if we got close, we scanned harder to find them. please do check your as at and then actually look at your router config. i found one of my routers still had a default from when i was bringing it up. randy From randy at psg.com Tue Jun 23 14:59:34 2009 From: randy at psg.com (Randy Bush) Date: Tue, 23 Jun 2009 12:59:34 -0700 Subject: Ticketmaster contact? - out of options In-Reply-To: <4A413211.8070907@mathezer.com> References: <4A413211.8070907@mathezer.com> Message-ID: > We have several thousand users NATing behind a single IP address. > Ticketmaster is blackholing this IP on a regular basis, presumably due > to volume of requests. you're just gonna love "carrier grade nat," and so will the rest of the net. while you're on the phone with ticketmaster, ask when they will support ipv6. randy From ren.provo at gmail.com Tue Jun 23 18:11:56 2009 From: ren.provo at gmail.com (Ren Provo) Date: Tue, 23 Jun 2009 19:11:56 -0400 Subject: Use of Default in the DFZ: banned in philly, see it now on the net! In-Reply-To: References: Message-ID: <787581440906231611x2876aab8xb6ab7658382b8542@mail.gmail.com> One point of clarity here. Lightning talks are scheduled in a more spur of the moment fashion than the traditional submission process for general sessions. We often schedule lightning talks around a topic with potential to run short if Q&A isn't significant or we have a 15 minute gap before a break. Unfortunately that means dates, or times, have the potential to shift and flexibility is required by the party presenting. Randy was offered an alternative as soon as it was discovered the original time slot on Monday was not going to prove viable. Options later in the meeting were not chosen by Randy due to his schedule constraints. If a specific date is required on the NANOG agenda please consider submitting a presentation well in advance of posted deadlines for the general sessions. The NANOG PC does consider comments made in the tool at http://pc.nanog.org when scheduling the agenda. Short duration presentations have been accepted well in advance of the meeting for about a year now and we welcome interesting topics, much like Randy details below. We hope to see Randy back up at the microphone on stage at future NANOG meetings. Cheers! -ren On Tue, Jun 23, 2009 at 3:51 PM, Randy Bush wrote: > due to nanog pc silliness, my lightning talk on $subject was not given > in philly. i had promised to report to nanog the results of our winter > experiment which used as path poisoning. here is the lightning talk i > would have given. > > http://archive.psg.com/090615.nanog-default.pdf > > this is really meant to be a talk, so the slides can be a bit hard. > > on slide 6 > /20 is the as path length of a /20, i.e. a 'normal' distribution, > as seen from bgp monitors at RV, RIS, and a jillion others > /25 is the as path length distribution we saw pinging from the /25 > BGP is the as path length distribution we saw from RV/RIS > i.e. BGP views are significantly skewed. but most of us knew that. > > on slides 10 and 11, the categories stub, small isp, large isp are from > a ucla study. imiho, you should take them with a grain of salt. > > on 12, the reason for the funniness around 30 test points is because, we > really wanted >= 30 test points in an AS. so if we got close, we > scanned harder to find them. > > please do check your as at and then actually > look at your router config. i found one of my routers still had a > default from when i was bringing it up. > > randy > > From randy at psg.com Wed Jun 24 02:04:12 2009 From: randy at psg.com (Randy Bush) Date: Wed, 24 Jun 2009 00:04:12 -0700 Subject: Use of Default in the DFZ: banned in philly, see it now on the net! In-Reply-To: <787581440906231611x2876aab8xb6ab7658382b8542@mail.gmail.com> References: <787581440906231611x2876aab8xb6ab7658382b8542@mail.gmail.com> Message-ID: > One point of clarity here.? Lightning talks are scheduled in a more > spur of the moment fashion than the traditional submission process for > general sessions. which was why this one was on the web agenda at as specific time? :) sorry my attempt at dealing with todd's screw-up with humor evoked such a defensive reaction. apology accepted. randy From jzp-sc at rsuc.gweep.net Wed Jun 24 07:04:35 2009 From: jzp-sc at rsuc.gweep.net (Joe Provo) Date: Wed, 24 Jun 2009 08:04:35 -0400 Subject: [NANOG-announce] NANOG46 survey open until July 6 Message-ID: <20090624120435.GA97156@gweep.net> Hi folks! Thanks very much for helping to make a successful NANOG in Philadelphia. If you haven't already (and we know a lot of those in attendance did not), then please visit the easy-to remember redirection URL http://tinyurl.com/nanog46 A lot of our direction for the structure and mechanics of meetings stem from the survey data. The Program and Steering Committee really need to have your feedback on the meeting to capitalize on what was successful and avoid what was not. The Mailing List Committee needs input on your use -or lack- of the attendee list. Merit needs to hear your comments on the hotel, facilities and meeting execution. If you attended remotely, we need your input too! Not just regarding the content you watched, commented on, or purposefully skipped, but what prevented you from attending and how we as an organization can address those issues. If you have colleagues which attended (in person or via the webcast) but may not be paying attention to this mailing list, please do give them the survey URL so we can get their comments too. Cheers! Joe Provo NANOG SC chair -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From jbates at brightok.net Wed Jun 24 08:44:06 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 24 Jun 2009 08:44:06 -0500 Subject: Use of Default in the DFZ: banned in philly, see it now on the net! In-Reply-To: References: Message-ID: <4A422DA6.6030005@brightok.net> Randy Bush wrote: > please do check your as at and then actually > look at your router config. i found one of my routers still had a > default from when i was bringing it up. Ick. Nothing was right. Reported as mixed, though that may be my fault and not your testing. Hmmm. Or your test didn't take some things into account like changes over time. Normally I keep a default route available, but due to changing IGP internally I actually have a default which points interior from the edge routers. So when I shut down the last BGP session on the old cisco, the defaults to the transits went away. Was also reported as a stub. Glad to know that I don't have BGP customers. Oh, wait, I do. :) Jack From pauldotwall at gmail.com Wed Jun 24 09:17:50 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Wed, 24 Jun 2009 10:17:50 -0400 Subject: Use of Default in the DFZ: banned in philly, see it now on the net! In-Reply-To: References: <787581440906231611x2876aab8xb6ab7658382b8542@mail.gmail.com> Message-ID: <620fd17c0906240717u2db82becib0b40adc96c0e444@mail.gmail.com> On Wed, Jun 24, 2009 at 3:04 AM, Randy Bush wrote: >> One point of clarity here.? Lightning talks are scheduled in a more >> spur of the moment fashion than the traditional submission process for >> general sessions. > > which was why this one was on the web agenda at as specific time? ?:) > > sorry my attempt at dealing with todd's screw-up with humor evoked such > a defensive reaction. ?apology accepted. Randy, acting like a petulant child in public is unbecoming. Take it off list. Drive Slow, Paul Wall From randy at psg.com Wed Jun 24 10:26:01 2009 From: randy at psg.com (Randy Bush) Date: Wed, 24 Jun 2009 08:26:01 -0700 Subject: Use of Default in the DFZ: banned in philly, see it now on the net! In-Reply-To: <4A422DA6.6030005@brightok.net> References: <4A422DA6.6030005@brightok.net> Message-ID: > Was also reported as a stub. Glad to know that I don't have BGP > customers. Oh, wait, I do. :) talk to ucla. as i said, we take their classification with a grain of salt. randy From nrauhauser at gmail.com Wed Jun 24 11:05:34 2009 From: nrauhauser at gmail.com (neal rauhauser) Date: Wed, 24 Jun 2009 11:05:34 -0500 Subject: Intelligent life at CenturyTel AS5668? Message-ID: <9515c62d0906240905u6a71d51aicb6fb9b6e820d7bd@mail.gmail.com> Can someone from CenturyTel please contact me off list? -- mailto:Neal at layer3arts.com // GoogleTalk: nrauhauser at gmail.com IM: nealrauhauser From rveloso at cs.ucla.edu Wed Jun 24 12:39:35 2009 From: rveloso at cs.ucla.edu (Ricardo Oliveira) Date: Wed, 24 Jun 2009 10:39:35 -0700 Subject: Use of Default in the DFZ: banned in philly, see it now on the net! In-Reply-To: <4A422DA6.6030005@brightok.net> References: <4A422DA6.6030005@brightok.net> Message-ID: <2BE52E9B-6E13-4154-B88E-A683EF221FE0@cs.ucla.edu> Jack, Please give me your ASN and i'll double check our data. As long as the network has 4 or less downstreams, it's being labeled as "stub". More details here: http://www.cs.ucla.edu/~rveloso/papers/completeness-ton.pdf Thanks, --Ricardo On Jun 24, 2009, at 6:44 AM, Jack Bates wrote: > Randy Bush wrote: >> please do check your as at and then >> actually >> look at your router config. i found one of my routers still had a >> default from when i was bringing it up. > > Ick. Nothing was right. Reported as mixed, though that may be my > fault and not your testing. Hmmm. Or your test didn't take some > things into account like changes over time. Normally I keep a > default route available, but due to changing IGP internally I > actually have a default which points interior from the edge routers. > So when I shut down the last BGP session on the old cisco, the > defaults to the transits went away. > > Was also reported as a stub. Glad to know that I don't have BGP > customers. Oh, wait, I do. :) > > > Jack From randy at psg.com Wed Jun 24 12:58:09 2009 From: randy at psg.com (Randy Bush) Date: Wed, 24 Jun 2009 10:58:09 -0700 Subject: Use of Default in the DFZ: banned in philly, see it now on the net! In-Reply-To: <2BE52E9B-6E13-4154-B88E-A683EF221FE0@cs.ucla.edu> References: <4A422DA6.6030005@brightok.net> <2BE52E9B-6E13-4154-B88E-A683EF221FE0@cs.ucla.edu> Message-ID: OK,a buckety of salt. From my pov, a stub has zero downstreams. randy, on iPhone On Jun 24, 2009, at 10:39, Ricardo Oliveira wrote: > Jack, > Please give me your ASN and i'll double check our data. As long as > the network has 4 or less downstreams, it's being labeled as "stub". > More details here: > http://www.cs.ucla.edu/~rveloso/papers/completeness-ton.pdf > > Thanks, > > --Ricardo > > On Jun 24, 2009, at 6:44 AM, Jack Bates wrote: > >> Randy Bush wrote: >>> please do check your as at and then >>> actually >>> look at your router config. i found one of my routers still had a >>> default from when i was bringing it up. >> >> Ick. Nothing was right. Reported as mixed, though that may be my >> fault and not your testing. Hmmm. Or your test didn't take some >> things into account like changes over time. Normally I keep a >> default route available, but due to changing IGP internally I >> actually have a default which points interior from the edge >> routers. So when I shut down the last BGP session on the old cisco, >> the defaults to the transits went away. >> >> Was also reported as a stub. Glad to know that I don't have BGP >> customers. Oh, wait, I do. :) >> >> >> Jack > From petelists at templin.org Wed Jun 24 13:04:57 2009 From: petelists at templin.org (Pete Templin) Date: Wed, 24 Jun 2009 13:04:57 -0500 Subject: Use of Default in the DFZ: banned in philly, see it now on the net! In-Reply-To: <2BE52E9B-6E13-4154-B88E-A683EF221FE0@cs.ucla.edu> References: <4A422DA6.6030005@brightok.net> <2BE52E9B-6E13-4154-B88E-A683EF221FE0@cs.ucla.edu> Message-ID: <4A426AC9.9080702@templin.org> Ricardo Oliveira wrote: > Jack, > Please give me your ASN and i'll double check our data. As long as the > network has 4 or less downstreams, it's being labeled as "stub". > More details here: > http://www.cs.ucla.edu/~rveloso/papers/completeness-ton.pdf I guess the old adage, "In theory, theory and practice are the same. In practice, they're not.", comes into play here. In (your) theory, your paper may hold up. In practice, your definition of stub network is most likely considered wrong, and that likely shifts a lot of the assumptions in your paper. pt From mksmith at adhost.com Wed Jun 24 13:18:32 2009 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Wed, 24 Jun 2009 11:18:32 -0700 Subject: Use of Default in the DFZ: banned in philly, see it now on the net! In-Reply-To: References: <4A422DA6.6030005@brightok.net><2BE52E9B-6E13-4154-B88E-A683EF221FE0@cs.ucla.edu> Message-ID: <17838240D9A5544AAA5FF95F8D5203160638B245@ad-exh01.adhost.lan> That was my assumption when I checked the "UCLA is wrong" button on the form. We only have one downstream, but it's a distinct ASN so that says "not stub" to me. Mike Randy top posting - will wonders never cease. > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Wednesday, June 24, 2009 10:58 AM > To: Ricardo Oliveira > Cc: NANOG list > Subject: Re: Use of Default in the DFZ: banned in philly,see it now on > the net! > > OK,a buckety of salt. > > From my pov, a stub has zero downstreams. > > randy, on iPhone > > On Jun 24, 2009, at 10:39, Ricardo Oliveira > wrote: > > > Jack, > > Please give me your ASN and i'll double check our data. As long as > > the network has 4 or less downstreams, it's being labeled as "stub". > > More details here: > > http://www.cs.ucla.edu/~rveloso/papers/completeness-ton.pdf > > > > Thanks, > > > > --Ricardo > > > > On Jun 24, 2009, at 6:44 AM, Jack Bates wrote: > > > >> Randy Bush wrote: > >>> please do check your as at and then > >>> actually > >>> look at your router config. i found one of my routers still had a > >>> default from when i was bringing it up. > >> > >> Ick. Nothing was right. Reported as mixed, though that may be my > >> fault and not your testing. Hmmm. Or your test didn't take some > >> things into account like changes over time. Normally I keep a > >> default route available, but due to changing IGP internally I > >> actually have a default which points interior from the edge > >> routers. So when I shut down the last BGP session on the old cisco, > >> the defaults to the transits went away. > >> > >> Was also reported as a stub. Glad to know that I don't have BGP > >> customers. Oh, wait, I do. :) > >> > >> > >> Jack > > From jbates at brightok.net Wed Jun 24 13:19:54 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 24 Jun 2009 13:19:54 -0500 Subject: Use of Default in the DFZ: banned in philly, see it now on the net! In-Reply-To: <2BE52E9B-6E13-4154-B88E-A683EF221FE0@cs.ucla.edu> References: <4A422DA6.6030005@brightok.net> <2BE52E9B-6E13-4154-B88E-A683EF221FE0@cs.ucla.edu> Message-ID: <4A426E4A.2050509@brightok.net> 8025, and thanks for labeling us small transit guys as stub. I have transit customers that have higher user counts than I do. :P Randy's page just mentioned stub as not having transit customers. By your definition, we are stub. 4 ASNs under mine, since customers not needing BGP don't use it and we inject their routes into our AS. Some may be undetectable due to routing policies. Jack Ricardo Oliveira wrote: > Jack, > Please give me your ASN and i'll double check our data. As long as the > network has 4 or less downstreams, it's being labeled as "stub". > More details here: > http://www.cs.ucla.edu/~rveloso/papers/completeness-ton.pdf > > Thanks, > > --Ricardo From randy at psg.com Wed Jun 24 13:24:26 2009 From: randy at psg.com (Randy Bush) Date: Wed, 24 Jun 2009 11:24:26 -0700 Subject: Use of Default in the DFZ: banned in philly, see it now on the net! In-Reply-To: <17838240D9A5544AAA5FF95F8D5203160638B245@ad-exh01.adhost.lan> References: <4A422DA6.6030005@brightok.net><2BE52E9B-6E13-4154-B88E-A683EF221FE0@cs.ucla.edu> <17838240D9A5544AAA5FF95F8D5203160638B245@ad-exh01.adhost.lan> Message-ID: <66656DEC-4A9F-4B3A-B91D-7DAA5C710964@psg.com> Iphone's. Are top posters :( Imiho a stub must only be foo$ randy On Jun 24, 2009, at 11:18, "Michael K. Smith - Adhost" wrote: > That was my assumption when I checked the "UCLA is wrong" button on > the > form. We only have one downstream, but it's a distinct ASN so that > says > "not stub" to me. > > Mike > > Randy top posting - will wonders never cease. > >> -----Original Message----- >> From: Randy Bush [mailto:randy at psg.com] >> Sent: Wednesday, June 24, 2009 10:58 AM >> To: Ricardo Oliveira >> Cc: NANOG list >> Subject: Re: Use of Default in the DFZ: banned in philly,see it now >> on >> the net! >> >> OK,a buckety of salt. >> >> From my pov, a stub has zero downstreams. >> >> randy, on iPhone >> >> On Jun 24, 2009, at 10:39, Ricardo Oliveira >> wrote: >> >>> Jack, >>> Please give me your ASN and i'll double check our data. As long as >>> the network has 4 or less downstreams, it's being labeled as > "stub". >>> More details here: >>> http://www.cs.ucla.edu/~rveloso/papers/completeness-ton.pdf >>> >>> Thanks, >>> >>> --Ricardo >>> >>> On Jun 24, 2009, at 6:44 AM, Jack Bates wrote: >>> >>>> Randy Bush wrote: >>>>> please do check your as at and then >>>>> actually >>>>> look at your router config. i found one of my routers still had a >>>>> default from when i was bringing it up. >>>> >>>> Ick. Nothing was right. Reported as mixed, though that may be my >>>> fault and not your testing. Hmmm. Or your test didn't take some >>>> things into account like changes over time. Normally I keep a >>>> default route available, but due to changing IGP internally I >>>> actually have a default which points interior from the edge >>>> routers. So when I shut down the last BGP session on the old cisco, >>>> the defaults to the transits went away. >>>> >>>> Was also reported as a stub. Glad to know that I don't have BGP >>>> customers. Oh, wait, I do. :) >>>> >>>> >>>> Jack >>> > From lixia at cs.ucla.edu Wed Jun 24 13:25:26 2009 From: lixia at cs.ucla.edu (Lixia Zhang) Date: Wed, 24 Jun 2009 11:25:26 -0700 Subject: Use of Default in the DFZ: banned in philly, see it now on the net! In-Reply-To: <4A426AC9.9080702@templin.org> References: <4A422DA6.6030005@brightok.net> <2BE52E9B-6E13-4154-B88E-A683EF221FE0@cs.ucla.edu> <4A426AC9.9080702@templin.org> Message-ID: <45542DD3-E707-445B-B4A1-FFA8AE1B281A@cs.ucla.edu> On Jun 24, 2009, at 11:04 AM, Pete Templin wrote: > Ricardo Oliveira wrote: >> Jack, >> Please give me your ASN and i'll double check our data. As long as >> the network has 4 or less downstreams, it's being labeled as "stub". >> More details here: >> http://www.cs.ucla.edu/~rveloso/papers/completeness-ton.pdf > > I guess the old adage, "In theory, theory and practice are the > same. In practice, they're not.", comes into play here. I agree completely. In a private reply I just sent to Randy, I said "have you heard my paraphrase of murphy's law: the internet is so large, so anything imaginable can happen:-)" the world cannot be sorted to just black-white, or any limited number of simple definitions > In (your) theory, your paper may hold up. In practice, your > definition of stub network is most likely considered wrong, and that > likely shifts a lot of the assumptions in your paper. But I also believe that there are a few common practical patterns that cover majority of reality. We need to be mindful of diversity in real world but also capture basic common patterns (I'd agree that the paper perhaps should have said a few more words about the former). Lixia From randy at psg.com Wed Jun 24 14:07:27 2009 From: randy at psg.com (Randy Bush) Date: Wed, 24 Jun 2009 12:07:27 -0700 Subject: Use of Default in the DFZ: banned in philly, see it now on the net! In-Reply-To: <17838240D9A5544AAA5FF95F8D5203160638B245@ad-exh01.adhost.lan> References: <4A422DA6.6030005@brightok.net> <2BE52E9B-6E13-4154-B88E-A683EF221FE0@cs.ucla.edu> <17838240D9A5544AAA5FF95F8D5203160638B245@ad-exh01.adhost.lan> Message-ID: > That was my assumption when I checked the "UCLA is wrong" button on the > form. We only have one downstream, but it's a distinct ASN so that says > "not stub" to me. this ucla fantasy imposing their social model on actual measurements is merely amusing and does little damage. researchers seem to have fantasies about the internet. the $subject breaks all our fantasies about the 'default free' zone. but it also shows that all the bgp feeds in the world only give you the ability to spew bs fast at the nanog podium, and have little to do with reality. but my favorite researcher fantisy is called the gao-rexford model. it assumes valley free customer preferred. valley free means no peer offers transit to peers and no customers offers transit between their upstreams. we know this to be violated in numerous cases. but the really good giggle is customer preferred, when the fact is that some really really large providers prefer peer routes and have since 1948. randy From petelists at templin.org Wed Jun 24 14:26:50 2009 From: petelists at templin.org (Pete Templin) Date: Wed, 24 Jun 2009 14:26:50 -0500 Subject: Use of Default in the DFZ: banned in philly, see it now on the net! In-Reply-To: <45542DD3-E707-445B-B4A1-FFA8AE1B281A@cs.ucla.edu> References: <4A422DA6.6030005@brightok.net> <2BE52E9B-6E13-4154-B88E-A683EF221FE0@cs.ucla.edu> <4A426AC9.9080702@templin.org> <45542DD3-E707-445B-B4A1-FFA8AE1B281A@cs.ucla.edu> Message-ID: <4A427DFA.30204@templin.org> Lixia Zhang wrote: > > On Jun 24, 2009, at 11:04 AM, Pete Templin wrote: > >> In (your) theory, your paper may hold up. In practice, your >> definition of stub network is most likely considered wrong, and that >> likely shifts a lot of the assumptions in your paper. > > But I also believe that there are a few common practical patterns that > cover majority of reality. > We need to be mindful of diversity in real world but also capture basic > common patterns (I'd agree that the paper perhaps should have said a few > more words about the former). Skimming the paper turns up a key sentence, "Stub networks, on the other hand, do not forward packets for other networks." What part of that led you to think that stub networks forward packets for 1-4 downstream ASNs? pt From randy at psg.com Wed Jun 24 14:43:15 2009 From: randy at psg.com (Randy Bush) Date: Wed, 24 Jun 2009 12:43:15 -0700 Subject: tor Message-ID: sadly, naively turning up tor to help folk who wish to be anonymous in hard times gets one a lot of assertive email from self-important people who wear formal clothes. folk who learn this the hard way may find a pointer passed to me by smb helpful, . randy From jbates at brightok.net Wed Jun 24 15:18:01 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 24 Jun 2009 15:18:01 -0500 Subject: Use of Default in the DFZ: banned in philly, see it now on the net! In-Reply-To: <4A427DFA.30204@templin.org> References: <4A422DA6.6030005@brightok.net> <2BE52E9B-6E13-4154-B88E-A683EF221FE0@cs.ucla.edu> <4A426AC9.9080702@templin.org> <45542DD3-E707-445B-B4A1-FFA8AE1B281A@cs.ucla.edu> <4A427DFA.30204@templin.org> Message-ID: <4A4289F9.8080405@brightok.net> Pete Templin wrote: > > Skimming the paper turns up a key sentence, "Stub networks, on the other > hand, do not forward packets for other networks." What part of that led > you to think that stub networks forward packets for 1-4 downstream ASNs? That's where the confusion sets in, and Randy even stated that the UCLA data is suspect; partially because it considers a stub to be 4 or less downstream ASNs. I think Randy's data would be better reflected without the UCLA information which just confuses it. Jack From rveloso at CS.UCLA.EDU Wed Jun 24 15:29:16 2009 From: rveloso at CS.UCLA.EDU (Ricardo Oliveira) Date: Wed, 24 Jun 2009 13:29:16 -0700 Subject: Use of Default in the DFZ: banned in philly, see it now on the net! In-Reply-To: <4A427DFA.30204@templin.org> References: <4A422DA6.6030005@brightok.net> <2BE52E9B-6E13-4154-B88E-A683EF221FE0@cs.ucla.edu> <4A426AC9.9080702@templin.org> <45542DD3-E707-445B-B4A1-FFA8AE1B281A@cs.ucla.edu> <4A427DFA.30204@templin.org> Message-ID: Hi, The classification we have is one possible classification, it's hard (if not impossible) to capture the diversity of the network in 4 classes without having mislabels. We noticed that there were a considerable number of networks with special arrangements (i.e. a very small number of local downstreams mostly non-profit), specially in academic campus networks. Because these networks are not ISPs in the traditional sense (not their main business), we relaxed the stub threshold at the cost of including some other cases of networks that are actual ISPs (e.g. Jack Bates). Looking forward to see Randy's survey results to see how often this happened. Thanks, --Ricardo On Jun 24, 2009, at 12:26 PM, Pete Templin wrote: > Lixia Zhang wrote: >> On Jun 24, 2009, at 11:04 AM, Pete Templin wrote: >>> In (your) theory, your paper may hold up. In practice, your >>> definition of stub network is most likely considered wrong, and >>> that likely shifts a lot of the assumptions in your paper. >> But I also believe that there are a few common practical patterns >> that cover majority of reality. >> We need to be mindful of diversity in real world but also capture >> basic common patterns (I'd agree that the paper perhaps should have >> said a few more words about the former). > > Skimming the paper turns up a key sentence, "Stub networks, on the > other hand, do not forward packets for other networks." What part > of that led you to think that stub networks forward packets for 1-4 > downstream ASNs? > > pt From ras at e-gerbil.net Wed Jun 24 16:41:53 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 24 Jun 2009 16:41:53 -0500 Subject: tor In-Reply-To: References: Message-ID: <20090624214153.GS51443@gerbil.cluepon.net> On Wed, Jun 24, 2009 at 12:43:15PM -0700, Randy Bush wrote: > sadly, naively turning up tor to help folk who wish to be anonymous in > hard times gets one a lot of assertive email from self-important people > who wear formal clothes. > > folk who learn this the hard way may find a pointer passed to me by smb > helpful, . If bittorrent of copyrighted material is the most illegal thing you helped facilitate while running tor, and all you got was an assertive e-mail because of it, you should consider yourself extremely lucky. Anonymity against privacy invasion and for political causes sure sounds like a great concept, but in reality it presents too tempting a target for abuse. If you choose to open up your internet connection to anyone who wants to use it, you should be prepared to be held accountable for what those anonymous people do with it. I'm sure you don't just sell transit to any spammer who comes along without researching them a little first, why should this be any different? -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From trelane at trelane.net Wed Jun 24 16:48:58 2009 From: trelane at trelane.net (Andrew D Kirch) Date: Wed, 24 Jun 2009 17:48:58 -0400 Subject: tor In-Reply-To: <20090624214153.GS51443@gerbil.cluepon.net> References: <20090624214153.GS51443@gerbil.cluepon.net> Message-ID: <4A429F4A.6020100@trelane.net> Richard A Steenbergen wrote: > On Wed, Jun 24, 2009 at 12:43:15PM -0700, Randy Bush wrote: > >> sadly, naively turning up tor to help folk who wish to be anonymous in >> hard times gets one a lot of assertive email from self-important people >> who wear formal clothes. >> >> folk who learn this the hard way may find a pointer passed to me by smb >> helpful, . >> > > If bittorrent of copyrighted material is the most illegal thing you > helped facilitate while running tor, and all you got was an assertive > e-mail because of it, you should consider yourself extremely lucky. > > Anonymity against privacy invasion and for political causes sure sounds > like a great concept, but in reality it presents too tempting a target > for abuse. If you choose to open up your internet connection to anyone > who wants to use it, you should be prepared to be held accountable for > what those anonymous people do with it. I'm sure you don't just sell > transit to any spammer who comes along without researching them a little > first, why should this be any different. You might also consider asserting your right to common carrier immunity under 47USC230. Andrew From Rod.Beck at hiberniaatlantic.com Wed Jun 24 16:57:27 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Wed, 24 Jun 2009 22:57:27 +0100 Subject: tor References: <20090624214153.GS51443@gerbil.cluepon.net> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB016282E9@bert.HiberniaAtlantic.local> Hi Richard, It is a more complicated issue than that. There is a long established legal tradition that telecommunication transport is not liable for the content it transmits. It's called common carrier. If someone makes an obscene phone call, the phone company cannot be held liable. Yes, if the client subsequently complains and asks for that number to be blocked and the phone company does nothing, that's different. But the general principle is that anyone who transmits bits is not liable for content. Unfortunately in my personal view that principle never got established in the Layer 3 world. So we now have governments trying to use ISPs as censors, regulators, and enforcers of public policy. There may be some cases such as spamming where the ISPs have to take some responsibility, but it is really hard to find an appealing principle that articulates what should and should not be the ISP's responsibility. 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. -----Original Message----- From: Richard A Steenbergen [mailto:ras at e-gerbil.net] Sent: Wed 6/24/2009 10:41 PM To: Randy Bush Cc: NANOG list Subject: Re: tor On Wed, Jun 24, 2009 at 12:43:15PM -0700, Randy Bush wrote: > sadly, naively turning up tor to help folk who wish to be anonymous in > hard times gets one a lot of assertive email from self-important people > who wear formal clothes. > > folk who learn this the hard way may find a pointer passed to me by smb > helpful, . If bittorrent of copyrighted material is the most illegal thing you helped facilitate while running tor, and all you got was an assertive e-mail because of it, you should consider yourself extremely lucky. Anonymity against privacy invasion and for political causes sure sounds like a great concept, but in reality it presents too tempting a target for abuse. If you choose to open up your internet connection to anyone who wants to use it, you should be prepared to be held accountable for what those anonymous people do with it. I'm sure you don't just sell transit to any spammer who comes along without researching them a little first, why should this be any different? -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From smb at cs.columbia.edu Wed Jun 24 17:01:04 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Wed, 24 Jun 2009 18:01:04 -0400 Subject: tor In-Reply-To: <4A429F4A.6020100@trelane.net> References: <20090624214153.GS51443@gerbil.cluepon.net> <4A429F4A.6020100@trelane.net> Message-ID: <20090624180104.52cdf6f8@cs.columbia.edu> On Wed, 24 Jun 2009 17:48:58 -0400 Andrew D Kirch wrote: > Richard A Steenbergen wrote: > > On Wed, Jun 24, 2009 at 12:43:15PM -0700, Randy Bush wrote: > > > >> sadly, naively turning up tor to help folk who wish to be > >> anonymous in hard times gets one a lot of assertive email from > >> self-important people who wear formal clothes. > >> > >> folk who learn this the hard way may find a pointer passed to me > >> by smb helpful, . > >> > > > > If bittorrent of copyrighted material is the most illegal thing you > > helped facilitate while running tor, and all you got was an > > assertive e-mail because of it, you should consider yourself > > extremely lucky. > > > > Anonymity against privacy invasion and for political causes sure > > sounds like a great concept, but in reality it presents too > > tempting a target for abuse. If you choose to open up your internet > > connection to anyone who wants to use it, you should be prepared to > > be held accountable for what those anonymous people do with it. I'm > > sure you don't just sell transit to any spammer who comes along > > without researching them a little first, why should this be any > > different. > You might also consider asserting your right to common carrier > immunity under 47USC230. > OK -- I looked at that part of the US Code (http://www4.law.cornell.edu/uscode/47/230.html). Apart from the fact that the phrase "common carrier" does not occur in that section, subparagraph (f)(2) says: Nothing in this section shall be construed to limit or expand any law pertaining to intellectual property. Perhaps you're referring to the law exempting ISPs from liability for user-created content? (I don't have the citation handy.) If so, remember that that law requires response to take-down notices. --Steve Bellovin, http://www.cs.columbia.edu/~smb From ras at e-gerbil.net Wed Jun 24 17:15:50 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 24 Jun 2009 17:15:50 -0500 Subject: tor In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB016282E9@bert.HiberniaAtlantic.local> References: <20090624214153.GS51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282E9@bert.HiberniaAtlantic.local> Message-ID: <20090624221550.GU51443@gerbil.cluepon.net> On Wed, Jun 24, 2009 at 10:57:27PM +0100, Rod Beck wrote: > Hi Richard, > > It is a more complicated issue than that. > > There is a long established legal tradition that telecommunication > transport is not liable for the content it transmits. It's called > common carrier. If someone makes an obscene phone call, the phone > company cannot be held liable. Yes, if the client subsequently > complains and asks for that number to be blocked and the phone company > does nothing, that's different. > > But the general principle is that anyone who transmits bits is not > liable for content. > > Unfortunately in my personal view that principle never got established > in the Layer 3 world. This has nothing to do with telecommunications or any kind of carrier or business relationship. This is intentionally leaving your computer open so that anyone on the Internet can come along and appear to be coming from your IP, where they will promptly set off doing bad stuff that will get traced back to you rather than them. Think of it like intentionally leaving your car unlocked with the keys in the ignition and a note authorizing people to borrow it and take it for a spin, and then expecting not to get into any kind of trouble when they rack up speeding tickets and/or use it to run someone over. Besides, the kind of consequencies I'm talking about are "having your internet account shut off for abuse"... But if you do happen to be one of those unlucky people who gets sued for downloading illegal content I don't think "but your honor I was running tor" is the defense you're looking for. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From Rod.Beck at hiberniaatlantic.com Wed Jun 24 17:12:13 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Wed, 24 Jun 2009 23:12:13 +0100 Subject: tor References: <20090624214153.GS51443@gerbil.cluepon.net><4A429F4A.6020100@trelane.net> <20090624180104.52cdf6f8@cs.columbia.edu> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB016282ED@bert.HiberniaAtlantic.local> -----Original Message----- From: Steven M. Bellovin [mailto:smb at cs.columbia.edu] Sent: Wed 6/24/2009 11:01 PM To: trelane at trelane.net Cc: NANOG list Subject: Re: tor On Wed, 24 Jun 2009 17:48:58 -0400 Andrew D Kirch wrote: > Richard A Steenbergen wrote: > > On Wed, Jun 24, 2009 at 12:43:15PM -0700, Randy Bush wrote: > > > >> sadly, naively turning up tor to help folk who wish to be > >> anonymous in hard times gets one a lot of assertive email from > >> self-important people who wear formal clothes. > >> > >> folk who learn this the hard way may find a pointer passed to me > >> by smb helpful, . > >> > > > > If bittorrent of copyrighted material is the most illegal thing you > > helped facilitate while running tor, and all you got was an > > assertive e-mail because of it, you should consider yourself > > extremely lucky. > > > > Anonymity against privacy invasion and for political causes sure > > sounds like a great concept, but in reality it presents too > > tempting a target for abuse. If you choose to open up your internet > > connection to anyone who wants to use it, you should be prepared to > > be held accountable for what those anonymous people do with it. I'm > > sure you don't just sell transit to any spammer who comes along > > without researching them a little first, why should this be any > > different. > You might also consider asserting your right to common carrier > immunity under 47USC230. > OK -- I looked at that part of the US Code (http://www4.law.cornell.edu/uscode/47/230.html). Apart from the fact that the phrase "common carrier" does not occur in that section, subparagraph (f)(2) says: Nothing in this section shall be construed to limit or expand any law pertaining to intellectual property. Perhaps you're referring to the law exempting ISPs from liability for user-created content? (I don't have the citation handy.) If so, remember that that law requires response to take-down notices. --Steve Bellovin, http://www.cs.columbia.edu/~smb Well, let's push a little harder. If I transfer stolen intellectual property over the Internet using simple file transfer, I don't believe any court is going to accept that the ISP has liability. So what is the underlying principle? Mind you the law is ad hoc most of the time. This whole area is fuzzy to the point of being a pea soup fog ... From brandon.galbraith at gmail.com Wed Jun 24 17:16:44 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Wed, 24 Jun 2009 17:16:44 -0500 Subject: tor In-Reply-To: <20090624180104.52cdf6f8@cs.columbia.edu> References: <20090624214153.GS51443@gerbil.cluepon.net> <4A429F4A.6020100@trelane.net> <20090624180104.52cdf6f8@cs.columbia.edu> Message-ID: <366100670906241516q4a6c4b41hfc4d3627df12b329@mail.gmail.com> You're referring to the DMCAs safe harbor provision. -brandon On 6/24/09, Steven M. Bellovin wrote: > On Wed, 24 Jun 2009 17:48:58 -0400 > Andrew D Kirch wrote: > >> Richard A Steenbergen wrote: >> > On Wed, Jun 24, 2009 at 12:43:15PM -0700, Randy Bush wrote: >> > >> >> sadly, naively turning up tor to help folk who wish to be >> >> anonymous in hard times gets one a lot of assertive email from >> >> self-important people who wear formal clothes. >> >> >> >> folk who learn this the hard way may find a pointer passed to me >> >> by smb helpful, . >> >> >> > >> > If bittorrent of copyrighted material is the most illegal thing you >> > helped facilitate while running tor, and all you got was an >> > assertive e-mail because of it, you should consider yourself >> > extremely lucky. >> > >> > Anonymity against privacy invasion and for political causes sure >> > sounds like a great concept, but in reality it presents too >> > tempting a target for abuse. If you choose to open up your internet >> > connection to anyone who wants to use it, you should be prepared to >> > be held accountable for what those anonymous people do with it. I'm >> > sure you don't just sell transit to any spammer who comes along >> > without researching them a little first, why should this be any >> > different. >> You might also consider asserting your right to common carrier >> immunity under 47USC230. >> > OK -- I looked at that part of the US Code > (http://www4.law.cornell.edu/uscode/47/230.html). Apart from the fact > that the phrase "common carrier" does not occur in that section, > subparagraph (f)(2) says: > > Nothing in this section shall be construed to limit or expand > any law pertaining to intellectual property. > > Perhaps you're referring to the law exempting ISPs from liability for > user-created content? (I don't have the citation handy.) If so, > remember that that law requires response to take-down notices. > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From Rod.Beck at hiberniaatlantic.com Wed Jun 24 17:18:20 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Wed, 24 Jun 2009 23:18:20 +0100 Subject: tor References: <20090624214153.GS51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282E9@bert.HiberniaAtlantic.local> <20090624221550.GU51443@gerbil.cluepon.net> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB016282EF@bert.HiberniaAtlantic.local> This has nothing to do with telecommunications or any kind of carrier or business relationship. This is intentionally leaving your computer open so that anyone on the Internet can come along and appear to be coming from your IP, where they will promptly set off doing bad stuff that will get traced back to you rather than them. Think of it like intentionally leaving your car unlocked with the keys in the ignition and a note authorizing people to borrow it and take it for a spin, and then expecting not to get into any kind of trouble when they rack up speeding tickets and/or use it to run someone over. Besides, the kind of consequencies I'm talking about are "having your internet account shut off for abuse"... But if you do happen to be one of those unlucky people who gets sued for downloading illegal content I don't think "but your honor I was running tor" is the defense you're looking for. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) I am afraid what you described with the car is not illegal. It is highly unlikely any court would convict ... :) From joelja at bogus.com Wed Jun 24 17:35:56 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 24 Jun 2009 15:35:56 -0700 Subject: tor In-Reply-To: <20090624214153.GS51443@gerbil.cluepon.net> References: <20090624214153.GS51443@gerbil.cluepon.net> Message-ID: <4A42AA4C.1000402@bogus.com> Richard A Steenbergen wrote: > On Wed, Jun 24, 2009 at 12:43:15PM -0700, Randy Bush wrote: >> sadly, naively turning up tor to help folk who wish to be anonymous in >> hard times gets one a lot of assertive email from self-important people >> who wear formal clothes. >> >> folk who learn this the hard way may find a pointer passed to me by smb >> helpful, . > > If bittorrent of copyrighted material is the most illegal thing you > helped facilitate while running tor, and all you got was an assertive > e-mail because of it, you should consider yourself extremely lucky. > > Anonymity against privacy invasion and for political causes sure sounds > like a great concept, but in reality it presents too tempting a target > for abuse. If you choose to open up your internet connection to anyone > who wants to use it, you should be prepared to be held accountable for > what those anonymous people do with it. I'm sure you don't just sell > transit to any spammer who comes along without researching them a little > first, why should this be any different? Sadly the ability to distinguish between the myriad forms of activity defined in various localities as "crimnal enterprise" and pick out the one's you're willing to support (sedition) vs those you aren't (use you imagination) is not a property of the tool. knocking down bit-torrent within tor seems straight forward enough but by in large to use the tool you're going to have to take the bad with the good. From ras at e-gerbil.net Wed Jun 24 17:41:11 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 24 Jun 2009 17:41:11 -0500 Subject: tor In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB016282EF@bert.HiberniaAtlantic.local> References: <20090624214153.GS51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282E9@bert.HiberniaAtlantic.local> <20090624221550.GU51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282EF@bert.HiberniaAtlantic.local> Message-ID: <20090624224111.GV51443@gerbil.cluepon.net> On Wed, Jun 24, 2009 at 11:18:20PM +0100, Rod Beck wrote: > > I am afraid what you described with the car is not illegal. > > It is highly unlikely any court would convict ... :) I'm not going to try and play armchair lawyer here (since my original comment was about the ethical and practical implications, i.e. your insurance co would probably tell you to piss off when you filed a claim about your trashed car, rather than the legal ones), but... If you did this activity with the express purpose of helping someone else hide their identity, and thus their crime could be traced back to you but no further, you might end up looking like you were aiding and abetting. Bottom line, this simply isn't common carrier activity, and when these anonymous users decide to abuse your trust you are the one who will suffering the consequences. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From Rod.Beck at hiberniaatlantic.com Wed Jun 24 17:45:13 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Wed, 24 Jun 2009 23:45:13 +0100 Subject: tor References: <20090624214153.GS51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282E9@bert.HiberniaAtlantic.local> <20090624221550.GU51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282EF@bert.HiberniaAtlantic.local> <20090624224111.GV51443@gerbil.cluepon.net> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB016282F4@bert.HiberniaAtlantic.local> Richard, The question is how much ISPs should be responsible for the actions of their clients. My point is that is not obvious where you draw the line. I have yet to see anyone, including yourself, articulate a general principle (maybe it doesn't exist). 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 jbfixurpc at gmail.com Wed Jun 24 17:49:39 2009 From: jbfixurpc at gmail.com (Joe Blanchard) Date: Wed, 24 Jun 2009 18:49:39 -0400 Subject: tor In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB016282ED@bert.HiberniaAtlantic.local> Message-ID: <00f301c9f51e$11bcce20$0101a8c0@E520> My gosh... Ok, so if someone happens to talk about murder over the phone, is the phone company providing the service held liable? Lets get back to rational/informative content please. -Joe Blanchard > -----Original Message----- > From: Rod Beck [mailto:Rod.Beck at hiberniaatlantic.com] > Sent: Wednesday, June 24, 2009 6:12 PM > To: Steven M. Bellovin; trelane at trelane.net > Cc: NANOG list > Subject: RE: tor > > -----Original Message----- > From: Steven M. Bellovin [mailto:smb at cs.columbia.edu] > Sent: Wed 6/24/2009 11:01 PM > To: trelane at trelane.net > Cc: NANOG list > Subject: Re: tor > > On Wed, 24 Jun 2009 17:48:58 -0400 > Andrew D Kirch wrote: > > > Richard A Steenbergen wrote: > > > On Wed, Jun 24, 2009 at 12:43:15PM -0700, Randy Bush wrote: > > > > > >> sadly, naively turning up tor to help folk who wish to > be anonymous > > >> in hard times gets one a lot of assertive email from > self-important > > >> people who wear formal clothes. > > >> > > >> folk who learn this the hard way may find a pointer > passed to me by > > >> smb helpful, . > > >> > > > > > > If bittorrent of copyrighted material is the most illegal > thing you > > > helped facilitate while running tor, and all you got was an > > > assertive e-mail because of it, you should consider yourself > > > extremely lucky. > > > > > > Anonymity against privacy invasion and for political causes sure > > > sounds like a great concept, but in reality it presents > too tempting > > > a target for abuse. If you choose to open up your internet > > > connection to anyone who wants to use it, you should be > prepared to > > > be held accountable for what those anonymous people do > with it. I'm > > > sure you don't just sell transit to any spammer who comes along > > > without researching them a little first, why should this be any > > > different. > > You might also consider asserting your right to common carrier > > immunity under 47USC230. > > > OK -- I looked at that part of the US Code > (http://www4.law.cornell.edu/uscode/47/230.html). Apart from > the fact that the phrase "common carrier" does not occur in > that section, subparagraph (f)(2) says: > > Nothing in this section shall be construed to limit or expand > any law pertaining to intellectual property. > > Perhaps you're referring to the law exempting ISPs from > liability for user-created content? (I don't have the > citation handy.) If so, remember that that law requires > response to take-down notices. > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > Well, let's push a little harder. If I transfer stolen > intellectual property over the Internet using simple file > transfer, I don't believe any court is going to accept that > the ISP has liability. > > So what is the underlying principle? Mind you the law is ad > hoc most of the time. This whole area is fuzzy to the point > of being a pea soup fog ... From charles at thewybles.com Wed Jun 24 17:55:13 2009 From: charles at thewybles.com (Charles Wyble) Date: Wed, 24 Jun 2009 15:55:13 -0700 Subject: tor In-Reply-To: <4A42AA4C.1000402@bogus.com> References: <20090624214153.GS51443@gerbil.cluepon.net> <4A42AA4C.1000402@bogus.com> Message-ID: <4A42AED1.8040304@thewybles.com> This is rapidly heading off topic, and I imagine the MLC will be stepping in shortly. :) From jbates at brightok.net Wed Jun 24 18:13:52 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 24 Jun 2009 18:13:52 -0500 Subject: tor In-Reply-To: <00f301c9f51e$11bcce20$0101a8c0@E520> References: <00f301c9f51e$11bcce20$0101a8c0@E520> Message-ID: <4A42B330.5050109@brightok.net> Joe Blanchard wrote: > My gosh... > > Ok, so if someone happens to talk about murder over the phone, is the phone > company providing the service held liable? > > Lets get back to rational/informative content please. The phone company still has to provide records of who owns the phone number and perhaps allow a tap of the phone depending on court orders. I seem to have to maintain a CALEA server and compliance which I will probably never use but is mandated by law. If the courts find they can never find the owner of an IP, then the laws will mandate that we maintain such records; and in fact, there has been more than one bill for provisioning the storage of all emails for subpoena purposes. I'm not familiar with TOR, but I suspect that governments can still step through it to find the person responsible if perhaps a bit more time consuming. Jack From jamonation at gmail.com Wed Jun 24 18:26:51 2009 From: jamonation at gmail.com (Jamon Camisso) Date: Wed, 24 Jun 2009 19:26:51 -0400 Subject: tor In-Reply-To: <20090624224111.GV51443@gerbil.cluepon.net> References: <20090624214153.GS51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282E9@bert.HiberniaAtlantic.local> <20090624221550.GU51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282EF@bert.HiberniaAtlantic.local> <20090624224111.GV51443@gerbil.cluepon.net> Message-ID: <4A42B63B.5070608@gmail.com> Richard A Steenbergen wrote: > If you did this activity with the express purpose of helping someone > else hide their identity, and thus their crime could be traced back to > you but no further, you might end up looking like you were aiding and > abetting. Since when was anonymity a crime? Neither entails the other. I've run a tor relay, and I'm pretty confident that just because I'm up in layer 3+ land, common carrier status would apply, if anyone could even detect the contents of the traffic passing through my systems in the first place (the whole point of tor being to mitigate against exactly that). Some good tips for anyone thinking about running a relay or exit node, the first of which is to inform your isp. tor is a great tool, more people please! https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment From jbfixurpc at gmail.com Wed Jun 24 18:27:25 2009 From: jbfixurpc at gmail.com (Joe Blanchard) Date: Wed, 24 Jun 2009 19:27:25 -0400 Subject: tor In-Reply-To: <4A42B330.5050109@brightok.net> Message-ID: <00f501c9f523$590ca070$0101a8c0@E520> Yes, allow records and perhaps a phone tap, but not held liable for the means to a crime as suggested in earlier emails. Again, lets get back to suitable content. We could certainly go on an on about the legal items but of what relevance is it to NANOG. Kind Regards, -Joe Blanchard > -----Original Message----- > From: Jack Bates [mailto:jbates at brightok.net] > Sent: Wednesday, June 24, 2009 7:14 PM > To: Joe Blanchard > Cc: 'Rod Beck'; 'Steven M. Bellovin'; trelane at trelane.net; > 'NANOG list' > Subject: Re: tor > > > > Joe Blanchard wrote: > > My gosh... > > > > Ok, so if someone happens to talk about murder over the > phone, is the > > phone company providing the service held liable? > > > > Lets get back to rational/informative content please. > > The phone company still has to provide records of who owns > the phone number and perhaps allow a tap of the phone > depending on court orders. I seem to have to maintain a CALEA > server and compliance which I will probably never use but is > mandated by law. If the courts find they can never find the > owner of an IP, then the laws will mandate that we maintain > such records; and in fact, there has been more than one bill > for provisioning the storage of all emails for subpoena purposes. > > I'm not familiar with TOR, but I suspect that governments can > still step through it to find the person responsible if > perhaps a bit more time consuming. > > Jack From cluestore at gmail.com Wed Jun 24 18:39:44 2009 From: cluestore at gmail.com (Clue Store) Date: Wed, 24 Jun 2009 18:39:44 -0500 Subject: Akamai Support Message-ID: <580af3b90906241639l8d62d4cl1c2be62e1d53dbd7@mail.gmail.com> Could someone from Akamai support unicast me off list please?? I have tried the usual support emails and numbers which usually have great response, but am having an issue getting someone to help me with an services problem. Sorry for the noise TIA Max From smb at cs.columbia.edu Wed Jun 24 18:49:24 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Wed, 24 Jun 2009 19:49:24 -0400 Subject: tor In-Reply-To: <00f501c9f523$590ca070$0101a8c0@E520> References: <4A42B330.5050109@brightok.net> <00f501c9f523$590ca070$0101a8c0@E520> Message-ID: <20090624194924.4f86b8ed@cs.columbia.edu> On Wed, 24 Jun 2009 19:27:25 -0400 "Joe Blanchard" wrote: > Yes, allow records and perhaps a phone tap, but not held liable for > the means to a crime as suggested in earlier > emails. > > Again, lets get back to suitable content. We could certainly go on an > on about the legal items > but of what relevance is it to NANOG. > Right. Randy's original posting was square-on: he said that if you offer a certain service, you may encounter a certain problem, and such-and-such a web site may help you avoid that problem while still offering (most of) the service. --Steve Bellovin, http://www.cs.columbia.edu/~smb From SFisher at Bresnan.com Wed Jun 24 19:32:50 2009 From: SFisher at Bresnan.com (Fisher, Shawn) Date: Wed, 24 Jun 2009 20:32:50 -0400 Subject: tor Message-ID: <21352038E7719F43A6D65B2D90B5256C0531FB00@fossil.bresnan.com> Did you guys know tor spelled backwards is rot? Interesting. Like the dude said in much ado about nothing, "there's a double meanining in that". -------------------------- Sent using BlackBerry -----Original Message----- From: Steven M. Bellovin To: Joe Blanchard CC: 'NANOG list' Sent: Wed Jun 24 19:49:24 2009 Subject: Re: tor On Wed, 24 Jun 2009 19:27:25 -0400 "Joe Blanchard" wrote: > Yes, allow records and perhaps a phone tap, but not held liable for > the means to a crime as suggested in earlier > emails. > > Again, lets get back to suitable content. We could certainly go on an > on about the legal items > but of what relevance is it to NANOG. > Right. Randy's original posting was square-on: he said that if you offer a certain service, you may encounter a certain problem, and such-and-such a web site may help you avoid that problem while still offering (most of) the service. --Steve Bellovin, http://www.cs.columbia.edu/~smb From orion at pirk.com Wed Jun 24 22:43:55 2009 From: orion at pirk.com (Steve Pirk) Date: Wed, 24 Jun 2009 20:43:55 -0700 (PDT) Subject: tor In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB016282EF@bert.HiberniaAtlantic.local> References: <20090624214153.GS51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282E9@bert.HiberniaAtlantic.local> <20090624221550.GU51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282EF@bert.HiberniaAtlantic.local> Message-ID: On Wed, 24 Jun 2009, Rod Beck wrote: > This has nothing to do with telecommunications or any kind of carrier or > business relationship. This is intentionally leaving your computer open > so that anyone on the Internet can come along and appear to be coming > from your IP, where they will promptly set off doing bad stuff that will > get traced back to you rather than them. Think of it like intentionally [snip] Not sure if this just "happened" to pop up on the radar because of all the tor work being done to provide access out of Iran for citizens there that are blocked. Probably just a co-incidence, but since I just got done reading a bunch and setting up a bridge node (provate relay), I can say that there are also levels of liability. There are tor entry/egress points (where users enter and exit the tor netowrk), usually referred to as "exit nodes", and then there are a bunch of tor relay nodes. A relay node just becomes part of the network, and sends and receives traffic inside the tor network. This _should_ be the most common configuration, but some people do not RTM and make themselves exit nodes. That is where you get into trouble. Relay nodes just pass encrypted packets - no exiting allowed. The third configuration is called a "bridge" node. This is a relay that does not tell anyone it is a node. A controller has a copy of that nodes public key, and builds a private network. Moral: you can help with tor without leaving yourself open to sbuse. >From what I know, the bigger exit node operators are fully aware of the responsibility they have. -- steve From ops.lists at gmail.com Wed Jun 24 22:50:11 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 25 Jun 2009 09:20:11 +0530 Subject: tor In-Reply-To: References: Message-ID: Running what's effectively an anonymous open proxy is not a bright idea, even if there's security bundled on.. John Gilmore found that out after Verio disconnected his perpetual open relay for example .. and TOR is just as nutty a concept. Nothing less that I'd expect from the EFF, frankly speaking - but clued people (and you are clued, for sure) shouldnt be running it. There was that other fun when that swedish researcher was running a fake tor exit node and turned up lots of embassy passwords etc - mostly because embassy staffers found TOR a fun way to browse for porn, bypassing firewalls from their offices Uninstall it and forget about it, I'd say. --srs On Thu, Jun 25, 2009 at 1:13 AM, Randy Bush wrote: > sadly, naively turning up tor to help folk who wish to be anonymous in > hard times gets one a lot of assertive email from self-important people > who wear formal clothes. > > folk who learn this the hard way may find a pointer passed to me by smb > helpful, . > > randy > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From ops.lists at gmail.com Wed Jun 24 22:52:53 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 25 Jun 2009 09:22:53 +0530 Subject: tor In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB016282F4@bert.HiberniaAtlantic.local> References: <20090624214153.GS51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282E9@bert.HiberniaAtlantic.local> <20090624221550.GU51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282EF@bert.HiberniaAtlantic.local> <20090624224111.GV51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282F4@bert.HiberniaAtlantic.local> Message-ID: Rod - you wouldnt qualify as an ISP - or even a "provider of an interactive computer service" to go by the language in 47 USC 230, by simply running a TOR exit node. On Thu, Jun 25, 2009 at 4:15 AM, Rod Beck wrote: > Richard, > > The question is how much ISPs should be responsible for the actions of their clients. > > My point is that is not obvious where you draw the line. > > I have yet to see anyone, including yourself, articulate a general principle (maybe it doesn't exist). > From adrian at creative.net.au Wed Jun 24 23:14:20 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 25 Jun 2009 12:14:20 +0800 Subject: tor In-Reply-To: References: <20090624214153.GS51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282E9@bert.HiberniaAtlantic.local> <20090624221550.GU51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282EF@bert.HiberniaAtlantic.local> <20090624224111.GV51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282F4@bert.HiberniaAtlantic.local> Message-ID: <20090625041420.GK1012@skywalker.creative.net.au> On Thu, Jun 25, 2009, Suresh Ramasubramanian wrote: > Rod - you wouldnt qualify as an ISP - or even a "provider of an > interactive computer service" to go by the language in 47 USC 230, by > simply running a TOR exit node. Ah, but would an ISP which currently enjoys whatever the current definition of "common carrier" is these days, running a TOR node, still be covered by said provisions? Adrian From ops.lists at gmail.com Wed Jun 24 23:28:11 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 25 Jun 2009 09:58:11 +0530 Subject: tor In-Reply-To: <20090625041420.GK1012@skywalker.creative.net.au> References: <20090624214153.GS51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282E9@bert.HiberniaAtlantic.local> <20090624221550.GU51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282EF@bert.HiberniaAtlantic.local> <20090624224111.GV51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282F4@bert.HiberniaAtlantic.local> <20090625041420.GK1012@skywalker.creative.net.au> Message-ID: On Thu, Jun 25, 2009 at 9:44 AM, Adrian Chadd wrote: > On Thu, Jun 25, 2009, Suresh Ramasubramanian wrote: >> Rod - you wouldnt qualify as an ISP - or even a "provider of an >> interactive computer service" to go by the language in 47 USC 230, by >> simply running a TOR exit node. > > Ah, but would an ISP which currently enjoys whatever the current definition > of "common carrier" is these days, running a TOR node, still be covered by > said provisions? ISPs are not common carriers. Geoff Huston is - as always - the guy who explains it best. http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_5-3/uncommon_carrier.html -- Suresh Ramasubramanian (ops.lists at gmail.com) From adrian at creative.net.au Wed Jun 24 23:29:28 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 25 Jun 2009 12:29:28 +0800 Subject: tor In-Reply-To: References: <20090624214153.GS51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282E9@bert.HiberniaAtlantic.local> <20090624221550.GU51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282EF@bert.HiberniaAtlantic.local> <20090624224111.GV51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282F4@bert.HiberniaAtlantic.local> <20090625041420.GK1012@skywalker.creative.net.au> Message-ID: <20090625042928.GL1012@skywalker.creative.net.au> On Thu, Jun 25, 2009, Suresh Ramasubramanian wrote: > On Thu, Jun 25, 2009 at 9:44 AM, Adrian Chadd wrote: > > On Thu, Jun 25, 2009, Suresh Ramasubramanian wrote: > >> Rod - you wouldnt qualify as an ISP - or even a "provider of an > >> interactive computer service" to go by the language in 47 USC 230, by > >> simply running a TOR exit node. > > > > Ah, but would an ISP which currently enjoys whatever the current definition > > of "common carrier" is these days, running a TOR node, still be covered by > > said provisions? > > ISPs are not common carriers. Geoff Huston is - as always - the guy > who explains it best. > http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_5-3/uncommon_carrier.html Fine; re-phrase my question as "an organisation currently enjoying common carrier status." Adrian (Apologies for off-topic noise.) From ops.lists at gmail.com Wed Jun 24 23:34:11 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 25 Jun 2009 10:04:11 +0530 Subject: tor In-Reply-To: <20090625042928.GL1012@skywalker.creative.net.au> References: <1E8B940C5E21014AB8BE70B975D40EDB016282E9@bert.HiberniaAtlantic.local> <20090624221550.GU51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282EF@bert.HiberniaAtlantic.local> <20090624224111.GV51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282F4@bert.HiberniaAtlantic.local> <20090625041420.GK1012@skywalker.creative.net.au> <20090625042928.GL1012@skywalker.creative.net.au> Message-ID: On Thu, Jun 25, 2009 at 9:59 AM, Adrian Chadd wrote: > Fine; re-phrase my question as "an organisation currently enjoying common carrier > status." You do realize that even where the telco division of carrier X is a common carrier but the ISP division is typically not .. And even were the telco to run a tor node, their charter as a common carrier probably doesnt specify that theyre a common carrier for tor nodes. so ... -- Suresh Ramasubramanian (ops.lists at gmail.com) From randy at psg.com Thu Jun 25 03:35:22 2009 From: randy at psg.com (Randy Bush) Date: Thu, 25 Jun 2009 17:35:22 +0900 Subject: tor In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB016282E9@bert.HiberniaAtlantic.local> References: <20090624214153.GS51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282E9@bert.HiberniaAtlantic.local> Message-ID: for those for whom i am too terse o i believe anonymity is a good thing, and i have done what i can to support it for a few decades. you don't have to like it. o i think tor is cool. you don't have to like it and i do not care. o i found out you need to be a little careful when running a tor node. o i thought i would share what i learned. and now, additionally, i find people's bluster and pontification about it to be bluster and pontification. randy From randy at psg.com Thu Jun 25 04:12:56 2009 From: randy at psg.com (Randy Bush) Date: Thu, 25 Jun 2009 18:12:56 +0900 Subject: Use of Default in the DFZ: banned in philly, see it now on the net! In-Reply-To: <4A4289F9.8080405@brightok.net> References: <4A422DA6.6030005@brightok.net> <2BE52E9B-6E13-4154-B88E-A683EF221FE0@cs.ucla.edu> <4A426AC9.9080702@templin.org> <45542DD3-E707-445B-B4A1-FFA8AE1B281A@cs.ucla.edu> <4A427DFA.30204@templin.org> <4A4289F9.8080405@brightok.net> Message-ID: > That's where the confusion sets in, and Randy even stated that the UCLA > data is suspect; partially because it considers a stub to be 4 or less > downstream ASNs. I think Randy's data would be better reflected without > the UCLA information which just confuses it. the first pie chart uses no classification. if we had to classify, we would have stubs only end as paths (_foo$) and transits are all the rest. i do not know how we would separate small and large transits in any rigorous fashion. so it was easier to use the ucla taxa as a rough approximation and blame anything weird on them :) we could do a quick run using the definition of stub and transit as above if folk are really interested. randy From jbates at brightok.net Thu Jun 25 08:39:40 2009 From: jbates at brightok.net (Jack Bates) Date: Thu, 25 Jun 2009 08:39:40 -0500 Subject: tor In-Reply-To: References: <20090624214153.GS51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282E9@bert.HiberniaAtlantic.local> <20090624221550.GU51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282EF@bert.HiberniaAtlantic.local> <20090624224111.GV51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282F4@bert.HiberniaAtlantic.local> <20090625041420.GK1012@skywalker.creative.net.au> Message-ID: <4A437E1C.2050105@brightok.net> Suresh Ramasubramanian wrote: > ISPs are not common carriers. Geoff Huston is - as always - the guy > who explains it best. > http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_5-3/uncommon_carrier.html > Except interestingly, TOR is the common carrier at its best, not filtering and investigating the use of the packets being transfered. The cause for saying an ISP is not a common carrier is the handling of abuse of the network, which could still be argued as common carrier in that the effects of spam, port scans, etc do have an impact on an ISP if they go unchecked and watch other networks filter them out. In addition, there are plenty of laws designed to protect customer privacy in the government's attempt to provide common carrier status for an ISP. DMCA also attempts to preserve common carrier for the ISP, requiring the ISP to extend a level of trust and act in specific a manner to maintain those protections. I don't think any of it is perfect, and it will take time for government to catch up to understanding how the Internet can be handled. Jack From atporter at gmail.com Thu Jun 25 10:37:58 2009 From: atporter at gmail.com (Aaron Porter) Date: Thu, 25 Jun 2009 08:37:58 -0700 Subject: tor In-Reply-To: References: Message-ID: <667aab920906250837we8b059fve4c873baf38ce71@mail.gmail.com> On Wed, Jun 24, 2009 at 8:50 PM, Suresh Ramasubramanian wrote: > Running what's effectively an anonymous open proxy is not a bright > idea, even if there's security bundled on.. > > John Gilmore found that out after Verio disconnected his perpetual > open relay for example .. ?and TOR is just as nutty a concept. > > Nothing less that I'd expect from the EFF, frankly speaking - but > clued people (and you are clued, for sure) shouldnt be running it. Would you feel better if instead of "Tor" it was called "Crowds" and instead of those rapscallions at the EFF it was a nice respectable AT&T Research project from Avi Ruben? I bet I still have my "Anonymity Loves Company" shirt somewhere... Anonymous speech is a vital concept if you expect Free speech. http://avirubin.com/crowds.pdf From ops.lists at gmail.com Thu Jun 25 10:52:35 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 25 Jun 2009 21:22:35 +0530 Subject: tor In-Reply-To: <667aab920906250837we8b059fve4c873baf38ce71@mail.gmail.com> References: <667aab920906250837we8b059fve4c873baf38ce71@mail.gmail.com> Message-ID: On Thu, Jun 25, 2009 at 9:07 PM, Aaron Porter wrote: > Would you feel better if instead of "Tor" it was called "Crowds" and > instead of those rapscallions at the EFF it was a nice respectable > AT&T Research project from Avi Ruben? I bet I still have my "Anonymity > Loves Company" shirt somewhere... Anonymous speech is a vital concept > if you expect Free speech. ... as long as it doesnt get abused, yes. When it gets so that the volume of abuse gets far higher than the volume of use, they go the way of all those anon remailers (nym.alias.net and othes) And while we are at listing research projects .. there are multiple other great projects around - from the berkman center and elsewhere, that do much the same. Only - they're targeted at specific repressive regimes - even customized to them. -- Suresh Ramasubramanian (ops.lists at gmail.com) From tme at multicasttech.com Thu Jun 25 11:07:12 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 25 Jun 2009 12:07:12 -0400 Subject: The Iranian proxy fight Message-ID: <0ED27DE1-DE76-4394-A5FB-BDEF0C0C6240@multicasttech.com> This seems to have routing relevance to me. I love this quote : "don't wait until the tanks are in the streets to figure this out" Regards Marshall From nancyp at yorku.ca Thu Jun 25 11:22:08 2009 From: nancyp at yorku.ca (nancyp at yorku.ca) Date: Thu, 25 Jun 2009 12:22:08 -0400 Subject: tor In-Reply-To: <20090624221550.GU51443@gerbil.cluepon.net> References: <20090624214153.GS51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282E9@bert.HiberniaAtlantic.local> <20090624221550.GU51443@gerbil.cluepon.net> Message-ID: <1245946928.4a43a43054ae7@mymail.yorku.ca> As I understand & pls correct if I am wrong: > There is a long established legal tradition that telecommunication > transport is not liable for the content it transmits. It's called > common carrier. Telephony = common carrier yes- considered 'basic service'under Telecom Act 96.. but data is considered 'enhanced services' different section of the Act. Thus common carrier does not apply. The dualism/argument began in the 2nd computer inquiry and scales right up to [US dominated] Intl telephony settlements- ICAIS where VoIP is not settled the same way [$] but governed by peering/transit arrangements Nancy Paterson (Reachability as a Net Neutrality Issue) PhD student, YorkU, Toronto Quoting Richard A Steenbergen : > On Wed, Jun 24, 2009 at 10:57:27PM +0100, Rod Beck wrote: > > Hi Richard, > > > > It is a more complicated issue than that. > > > > There is a long established legal tradition that telecommunication > > transport is not liable for the content it transmits. It's called > > common carrier. If someone makes an obscene phone call, the phone > > company cannot be held liable. Yes, if the client subsequently > > complains and asks for that number to be blocked and the phone company > > does nothing, that's different. > > > > But the general principle is that anyone who transmits bits is not > > liable for content. > > > > Unfortunately in my personal view that principle never got established > > in the Layer 3 world. > > This has nothing to do with telecommunications or any kind of carrier or > business relationship. This is intentionally leaving your computer open > so that anyone on the Internet can come along and appear to be coming > from your IP, where they will promptly set off doing bad stuff that will > get traced back to you rather than them. Think of it like intentionally > leaving your car unlocked with the keys in the ignition and a note > authorizing people to borrow it and take it for a spin, and then > expecting not to get into any kind of trouble when they rack up speeding > tickets and/or use it to run someone over. > > Besides, the kind of consequencies I'm talking about are "having your > internet account shut off for abuse"... But if you do happen to be one > of those unlucky people who gets sued for downloading illegal content I > don't think "but your honor I was running tor" is the defense you're > looking for. :) > > -- > Richard A Steenbergen http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > > > From smb at cs.columbia.edu Thu Jun 25 11:27:24 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Thu, 25 Jun 2009 12:27:24 -0400 Subject: Tor abuse FAQs Message-ID: <20090625122724.5ebadd21@cs.columbia.edu> A friend sent me these links: https://www.torproject.org/faq.html.en#ExitPolicies https://www.torproject.org/faq-abuse.html.en https://www.torproject.org/eff/tor-legal-faq.html.en https://www.torproject.org/torusers.html.en Btw -- several folks have raised the issue of Iran. Here's a blog posting that may be of interest: https://blog.torproject.org/blog/measuring-tor-and-iran (My apologies if these have already been posted -- for assorted reasons involving my email setup, I cannot easily see any NANOG posts until some time tonight EDT.) From rah at shipwright.com Thu Jun 25 11:43:29 2009 From: rah at shipwright.com (R.A. Hettinga) Date: Thu, 25 Jun 2009 12:43:29 -0400 Subject: tor In-Reply-To: <667aab920906250837we8b059fve4c873baf38ce71@mail.gmail.com> References: <667aab920906250837we8b059fve4c873baf38ce71@mail.gmail.com> Message-ID: <57EAE1FB-21E1-4665-BAF5-7A18BBC081C5@shipwright.com> On Jun 25, 2009, at 11:37 AM, Aaron Porter wrote: > Would you feel better if instead of "Tor" it was called "Crowds" and > instead of those rapscallions at the EFF it was a nice respectable > AT&T Research project from Avi Ruben? Or, before that, if you knew that onion routers were invented by Paul Syverson Naval Research Laboratory to protect our service personnel while they're surfing the web? Cheers, RAH While we're making appeals to authority, and all... From johnl at iecc.com Thu Jun 25 11:44:58 2009 From: johnl at iecc.com (John Levine) Date: 25 Jun 2009 16:44:58 -0000 Subject: common carriers, was tor In-Reply-To: <20090625042928.GL1012@skywalker.creative.net.au> Message-ID: <20090625164458.54424.qmail@simone.iecc.com> >Fine; re-phrase my question as "an organisation currently enjoying >common carrier status." That would not include any ISP in the United States. (Dunno about Canada.) As other people have pointed out, telcos are common carriers, ISPs aren't, not even ISPs that are subsidiaries of telcos. The legal status of ISPs in the U.S. can best be described as complicated. The DMCA provides limited immunity from copyright suits, and the CDA (47 USC 230) provides fairly broad immunity from some other kinds of suits. The U.S. is a common law country where you don't really know how a law will be applied until there are enough reported cases to establish persuasive case law, and we're a long way from that. So go ahead and run Tor if you want, but if the cops knock on the door, I would advise against saying "we're a common carrier so go away." R's, John From orion at pirk.com Thu Jun 25 12:02:09 2009 From: orion at pirk.com (Steve Pirk) Date: Thu, 25 Jun 2009 10:02:09 -0700 (PDT) Subject: Tor abuse FAQs In-Reply-To: <20090625122724.5ebadd21@cs.columbia.edu> References: <20090625122724.5ebadd21@cs.columbia.edu> Message-ID: On Thu, 25 Jun 2009, Steven M. Bellovin wrote: > A friend sent me these links: > > https://www.torproject.org/faq.html.en#ExitPolicies > https://www.torproject.org/faq-abuse.html.en > https://www.torproject.org/eff/tor-legal-faq.html.en > https://www.torproject.org/torusers.html.en > > Btw -- several folks have raised the issue of Iran. Here's a blog > posting that may be of interest: > > https://blog.torproject.org/blog/measuring-tor-and-iran An official site on what the "group" is doing is at: http://nedanet.org/ On a related note, I posted a question about ipv6 a while back and the ticket I also opened is gertting bounced around with no one saying "yes, this is my space". My ipv6 skills are seriously lacking... Can anyone shed light on how to find out "where" a certain IP is coming from? This device on a _very_ large pipe is becoming quite a pain. [egrep at pixel notes]$ host gateway01.sikt.ir Using domain server: Name: 67.19.72.206 Address: 67.19.72.206#53 Aliases: gateway01.sikt.ir has IPv6 address 2001:470:f15d:fe1d:33f:ad43:1:fa4 -- -steve On Thu, 25 Jun 2009, Steven M. Bellovin wrote: > A friend sent me these links: > > https://www.torproject.org/faq.html.en#ExitPolicies > https://www.torproject.org/faq-abuse.html.en > https://www.torproject.org/eff/tor-legal-faq.html.en > https://www.torproject.org/torusers.html.en > > Btw -- several folks have raised the issue of Iran. Here's a blog > posting that may be of interest: > > https://blog.torproject.org/blog/measuring-tor-and-iran > > (My apologies if these have already been posted -- for assorted reasons > involving my email setup, I cannot easily see any NANOG posts until some > time tonight EDT.) > -- steve From nancyp at yorku.ca Thu Jun 25 12:32:15 2009 From: nancyp at yorku.ca (nancyp at yorku.ca) Date: Thu, 25 Jun 2009 13:32:15 -0400 Subject: common carier In-Reply-To: <616959408-1245948969-cardhu_decombobulator_blackberry.rim.net-1085127931-@bxe1003.bisx.produk.on.blackberry> References: <20090624214153.GS51443@gerbil.cluepon.net><1E8B940C5E21014AB8BE70B975D40EDB016282E9@bert.HiberniaAtlantic.local><20090624221550.GU51443@gerbil.cluepon.net><1245946928.4a43a43054ae7@mymail.yorku.ca> <616959408-1245948969-cardhu_decombobulator_blackberry.rim.net-1085127931-@bxe1003.bisx.produk.on.blackberry> Message-ID: <1245951135.4a43b49f6d5b0@mymail.yorku.ca> Rod, Sorry for the mislead on this. I agree with you. There are a lot of layer 9 reasons why this is the case. regards NP Quoting rodbeck1 at gmail.com: > Nancy, > > You're missing the point and you're quoting out of context. > > The point is that common carrier protections should apply to ISPs since they > are essentially doing the same thing as carriers - they are shipping bits. > > The whole enhanced service distinction is flimsy. There is nothing about IP > that makes an enhanced service in any meaninful sense different It is just a > transport protocol. > > So don't confuse 'is' and 'ought'. > > I am advocating that common carrier protections should be extended to ISPs. > ---- Envoy? avec BlackBerry? d'Orange ---- > > -----Original Message----- > From: > > Date: Thu, 25 Jun 2009 12:22:08 > To: Richard A Steenbergen > Cc: NANOG list > Subject: [SPAM-HEADER] - Re: tor - Email has different SMTP TO: and MIME TO: > fields in the email addresses > > > As I understand & pls correct if I am wrong: > > > There is a long established legal tradition that telecommunication > > transport is not liable for the content it transmits. It's called > > common carrier. > > Telephony = common carrier yes- considered 'basic service'under Telecom Act > 96.. > > but data is considered 'enhanced services' different section of the Act. Thus > common carrier does not apply. > > The dualism/argument began in the 2nd computer inquiry and scales right up to > [US dominated] Intl telephony settlements- ICAIS where VoIP is not settled > the > same way [$] but governed by peering/transit arrangements > > Nancy Paterson > (Reachability as a Net Neutrality Issue) > PhD student, YorkU, Toronto > > > > Quoting Richard A Steenbergen : > > > On Wed, Jun 24, 2009 at 10:57:27PM +0100, Rod Beck wrote: > > > Hi Richard, > > > > > > It is a more complicated issue than that. > > > > > > There is a long established legal tradition that telecommunication > > > transport is not liable for the content it transmits. It's called > > > common carrier. If someone makes an obscene phone call, the phone > > > company cannot be held liable. Yes, if the client subsequently > > > complains and asks for that number to be blocked and the phone company > > > does nothing, that's different. > > > > > > But the general principle is that anyone who transmits bits is not > > > liable for content. > > > > > > Unfortunately in my personal view that principle never got established > > > in the Layer 3 world. > > > > This has nothing to do with telecommunications or any kind of carrier or > > business relationship. This is intentionally leaving your computer open > > so that anyone on the Internet can come along and appear to be coming > > from your IP, where they will promptly set off doing bad stuff that will > > get traced back to you rather than them. Think of it like intentionally > > leaving your car unlocked with the keys in the ignition and a note > > authorizing people to borrow it and take it for a spin, and then > > expecting not to get into any kind of trouble when they rack up speeding > > tickets and/or use it to run someone over. > > > > Besides, the kind of consequencies I'm talking about are "having your > > internet account shut off for abuse"... But if you do happen to be one > > of those unlucky people who gets sued for downloading illegal content I > > don't think "but your honor I was running tor" is the defense you're > > looking for. :) > > > > -- > > Richard A Steenbergen http://www.e-gerbil.net/ras > > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > > > > > > > > > > > From ops.lists at gmail.com Thu Jun 25 12:34:22 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 25 Jun 2009 23:04:22 +0530 Subject: Tor abuse FAQs In-Reply-To: References: <20090625122724.5ebadd21@cs.columbia.edu> Message-ID: On Thu, Jun 25, 2009 at 10:32 PM, Steve Pirk wrote: > On a related note, I posted a question about ipv6 a while back and the > ticket I also opened is gertting bounced around with no one saying "yes, > this is my space". > > My ipv6 skills are seriously lacking... Can anyone shed light on how to find > out "where" a certain IP is coming from? This device on a _very_ large pipe > is becoming quite a pain. Hurricane Electric. Probably a tunnel from their tunnelbroker free v6 service. $ whois 2001:470:f15d:fe1d:33f:ad43:1:fa4 OrgName: Hurricane Electric, Inc. OrgID: HURC Address: 760 Mission Court City: Fremont StateProv: CA PostalCode: 94539 Country: US NetRange: 2001:0470:0000:0000:0000:0000:0000:0000 - 2001:0470:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF CIDR: 2001:0470:0000:0000:0000:0000:0000:0000/32 NetName: HURRICANE-IPV6 NetHandle: NET6-2001-470-1 Parent: NET6-2001-400-0 NetType: Direct Allocation NameServer: NS1.HE.NET NameServer: NS2.HE.NET NameServer: NS3.HE.NET NameServer: NS4.HE.NET NameServer: NS5.HE.NET Comment: RegDate: 2001-03-22 Updated: 2008-06-18 RAbuseHandle: ABUSE1036-ARIN RAbuseName: Abuse Department RAbusePhone: +1-510-580-4100 RAbuseEmail: abuse at he.net RNOCHandle: ZH17-ARIN RNOCName: Hurricane Electric RNOCPhone: +1-510-580-4100 RNOCEmail: hostmaster at he.net RTechHandle: ZH17-ARIN RTechName: Hurricane Electric RTechPhone: +1-510-580-4100 RTechEmail: hostmaster at he.net OrgAbuseHandle: ABUSE1036-ARIN OrgAbuseName: Abuse Department OrgAbusePhone: +1-510-580-4100 OrgAbuseEmail: abuse at he.net OrgTechHandle: ZH17-ARIN OrgTechName: Hurricane Electric OrgTechPhone: +1-510-580-4100 OrgTechEmail: hostmaster at he.net # ARIN WHOIS database, last updated 2009-06-24 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. From Rod.Beck at hiberniaatlantic.com Thu Jun 25 12:38:29 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Thu, 25 Jun 2009 18:38:29 +0100 Subject: [SPAM-HEADER] - Re: tor - Email has different SMTP TO: and MIME TO: fields in the email addresses References: <20090624214153.GS51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282E9@bert.HiberniaAtlantic.local><20090624221550.GU51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282EF@bert.HiberniaAtlantic.local><20090624224111.GV51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB016282F4@bert.HiberniaAtlantic.local> <20090625041420.GK1012@skywalker.creative.net.au> <4A437E1C.2050105@brightok.net> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB0162830F@bert.HiberniaAtlantic.local> -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Thu 6/25/2009 2:39 PM To: Suresh Ramasubramanian Cc: NANOG list Subject: [SPAM-HEADER] - Re: tor - Email has different SMTP TO: and MIME TO: fields in the email addresses Suresh Ramasubramanian wrote: > ISPs are not common carriers. Geoff Huston is - as always - the guy > who explains it best. > http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_5-3/uncommon_carrier.html > Except interestingly, TOR is the common carrier at its best, not filtering and investigating the use of the packets being transfered. The cause for saying an ISP is not a common carrier is the handling of abuse of the network, which could still be argued as common carrier in that the effects of spam, port scans, etc do have an impact on an ISP if they go unchecked and watch other networks filter them out. In addition, there are plenty of laws designed to protect customer privacy in the government's attempt to provide common carrier status for an ISP. DMCA also attempts to preserve common carrier for the ISP, requiring the ISP to extend a level of trust and act in specific a manner to maintain those protections. I don't think any of it is perfect, and it will take time for government to catch up to understanding how the Internet can be handled. Jack Agreed. The current regulatory framework, which says that ISPs provide 'enhanced services' is specious. IP is not an enhanced service, it is just a transport protocol, albeit a very popular one because the interfaces are cheap and it embraces routing. As I vaguely recollect, the enhanced service definition came up as way of preventing Telcos from completing dominating the ISP world. Regards, Roderick. From orion at pirk.com Thu Jun 25 14:38:31 2009 From: orion at pirk.com (Steve Pirk) Date: Thu, 25 Jun 2009 12:38:31 -0700 (PDT) Subject: Tor abuse FAQs In-Reply-To: References: <20090625122724.5ebadd21@cs.columbia.edu> Message-ID: On Thu, 25 Jun 2009, Suresh Ramasubramanian wrote: > > Hurricane Electric. Probably a tunnel from their tunnelbroker free v6 service. > > $ whois 2001:470:f15d:fe1d:33f:ad43:1:fa4 > Doh! See, I said my skills were lacking. How lacking I had not realized. Duuuuh, use whois. What a dummy. Consider me educated list, I will crawl back into my cave :-) Thanks to everyone who responded with how to confirm HE. Abuse to them was passed to a customer of HE. Customer says not their space. Oh, well, back to searching. Thanks! -- steve From acoconesi at dhc.com.br Thu Jun 25 15:19:23 2009 From: acoconesi at dhc.com.br (Alexandre Augusto Caramanti Coconesi) Date: Thu, 25 Jun 2009 17:19:23 -0300 Subject: Flow Chart Message-ID: <4A43DBCB.9030205@dhc.com.br> Hello This is my first post in this list. I have the follow situation: I have a multilateral peering, and I?m need to plot a graph showing how many traffic is going to or comming from each member of peering. For example: I have the AS61222, and in the peering there is the AS61333. This AS have other peerings, And my AS (AS61222) use the AS61333 as transit. And because it is a peering, by just one interface of my router, I can see just the whole traffic, to AS61333, and another members of peering. I was seeing some thing in JKFlow, but I did not found any thing. Do you have any experience in a case like this? Thanks -- Alexandre Coconesi From markk at arin.net Thu Jun 25 15:38:48 2009 From: markk at arin.net (Mark Kosters) Date: Thu, 25 Jun 2009 16:38:48 -0400 Subject: question about Mark Koster's ARIN presentation In-Reply-To: <20090618160520.93FEE3F476@pecan.tislabs.com> References: <20090618160520.93FEE3F476@pecan.tislabs.com> Message-ID: <20090625203847.GB16572@arin.net> Hi Sandy On Thu, Jun 18, 2009 at 12:05:20PM -0400, Sandy Murphy wrote: > The presentation said that ARIN would be doing a lot of work to > improve the IRR. The last I asked, the ARIN IRR did not support the > RPSS (Routing Policy System Security - RFC2725). RIPE supports this, > I know. Will the ARIN improvements include support for RPSS? The current effort will only allow for ipv6 objects (route6/inet6num). Further enhancements to ARIN's IRR will be coupled together with improvements to ARIN Online that will be announced in the future. > The presentation talked about the RPKI pilot, and Mark said that > ARIN would be using the RIPE code. I believe RIPE has or had a couple > different attempts at this, so I'm not sure what features the code > you use will have. Will you have the ability to hand certs to ISPs > so that they can do their own cert generation for the allocations > they hand to their own customers? I.e., is ARIN going to run a > service just for its members, or will it enable its members to > participate in the RPKI themselves? We are using the same code that RIPE is using at http://certtest.ripe.net. RIPE has been very kind to allow us to use their code. As for ARIN, this is a pilot and is certainly not a final fixed-feature set. The first go of this is the "hosted" solution where an ISP can come into ARIN's pilot and create ROAs based off of allocations that they have received from ARIN. All the ROAs will be placed into a rsync repository that can be retrieved and validated. Specifically, here are the features that are a part of the system: * Enables ARIN resource holders to request certificates for their IPv4 and IPv6 Provider Aggregatable (PA) resources * Enables ARIN resource holders to manage Route Origin Authorizations (ROAs) for their PA address space * Provides a public repository of certificates and ROAs * Handles key rollovers and revocations Thanks, Mark From randy at psg.com Thu Jun 25 17:33:39 2009 From: randy at psg.com (Randy Bush) Date: Fri, 26 Jun 2009 07:33:39 +0900 Subject: question about Mark Koster's ARIN presentation In-Reply-To: <20090625203847.GB16572@arin.net> References: <20090618160520.93FEE3F476@pecan.tislabs.com> <20090625203847.GB16572@arin.net> Message-ID: > The current effort will only allow for ipv6 objects > (route6/inet6num). s/allow for/add support for/ i hope > We are using the same code that RIPE is using at http://certtest.ripe.net. > RIPE has been very kind to allow us to use their code. As for ARIN, > this is a pilot and is certainly not a final fixed-feature set. The > first go of this is the "hosted" solution where an ISP can come into > ARIN's pilot and create ROAs based off of allocations that they > have received from ARIN. > > All the ROAs will be placed into a rsync repository that can be retrieved > and validated. Specifically, here are the features that are a part of the > system: > > * Enables ARIN resource holders to request certificates for their IPv4 and > IPv6 Provider Aggregatable (PA) resources > * Enables ARIN resource holders to manage Route Origin Authorizations (ROAs) > for their PA address space > * Provides a public repository of certificates and ROAs > * Handles key rollovers and revocations the simple version of the question: who holds my private key(s)? the longer version: does this implement my having my own subsidiary CA with it communiciating with ARIN's and RIPE's ... using the protocols of the ietf sidr work? randy From rmoseley at softlayer.com Thu Jun 25 19:03:49 2009 From: rmoseley at softlayer.com (Ric Moseley) Date: Thu, 25 Jun 2009 19:03:49 -0500 Subject: softlayer: ipv6 netfow tools Message-ID: Just wondering what people were using to analyze IPv6 Netflow. I am exporting IPv6 (along with IPv4 sampled) to a server that is running flow-tools as well as to an Arbor SP system. The Cisco's I am exporting from only allow flow export of both IPv4 and IPv6 simultaneously to an IPv4 address. Arbor claims support early next year so I am looking for another solution in the meantime. Thanks. Ric Moseley VP of Engineering rmoseley at softlayer.com 214-442-0555 direct 972-989-7813 cell 214-442-0600 office 866-398-7638 toll-free 214-442-0601 fax 6400 International Parkway, Suite 2000 Plano, TX 75093 http://www.softlayer.com 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 922 bytes Desc: image001.gif URL: From jgreco at ns.sol.net Thu Jun 25 20:38:57 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 25 Jun 2009 20:38:57 -0500 (CDT) Subject: tor In-Reply-To: from "Suresh Ramasubramanian" at Jun 25, 2009 09:22:35 PM Message-ID: <200906260138.n5Q1cvv6087293@aurora.sol.net> > On Thu, Jun 25, 2009 at 9:07 PM, Aaron Porter wrote: > > Would you feel better if instead of "Tor" it was called "Crowds" and > > instead of those rapscallions at the EFF it was a nice respectable > > AT&T Research project from Avi Ruben? I bet I still have my "Anonymity > > Loves Company" shirt somewhere... Anonymous speech is a vital concept > > if you expect Free speech. > > ... as long as it doesnt get abused, yes. When it gets so that the > volume of abuse gets far higher than the volume of use, they go the > way of all those anon remailers (nym.alias.net and othes) > > And while we are at listing research projects .. there are multiple > other great projects around - from the berkman center and elsewhere, > that do much the same. > > Only - they're targeted at specific repressive regimes - even > customized to them. And which one is targetted at the specific repressive regime effectively created by the US broadband cartels? :-) .. 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 ops.lists at gmail.com Thu Jun 25 20:39:22 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 26 Jun 2009 07:09:22 +0530 Subject: tor In-Reply-To: <200906260138.n5Q1cvv6087293@aurora.sol.net> References: <200906260138.n5Q1cvv6087293@aurora.sol.net> Message-ID: On Fri, Jun 26, 2009 at 7:08 AM, Joe Greco wrote: > And which one is targetted at the specific repressive regime effectively > created by the US broadband cartels? ?:-) Rod Beck's proposal to modify the common carrier regs, of course. -- Suresh Ramasubramanian (ops.lists at gmail.com) From stasinia at msoe.edu Thu Jun 25 21:14:20 2009 From: stasinia at msoe.edu (Stasiniewicz, Adam) Date: Thu, 25 Jun 2009 21:14:20 -0500 Subject: Looking for Security / Operational Contact at New York Times Message-ID: <011b01c9f603$d11fd970$735f8c50$@edu> Hello, In the off chance there is someone who works at the New York Times on this list, please contact me ASAP, there is a very nasty problem with one of your internet facing system (details will only be provided to @nytimes.com or related addresses). And as always, please respond off list. Thanks, Adam Stasiniewicz 608-554-1522 From martin at theicelandguy.com Thu Jun 25 23:03:04 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Fri, 26 Jun 2009 00:03:04 -0400 Subject: Looking for Security / Operational Contact at New York Times In-Reply-To: <011b01c9f603$d11fd970$735f8c50$@edu> References: <011b01c9f603$d11fd970$735f8c50$@edu> Message-ID: If this is a private problem, why not look them up in 411 and call them directly? On 6/25/09, Stasiniewicz, Adam wrote: > Hello, > > > > In the off chance there is someone who works at the New York Times on this > list, please contact me ASAP, there is a very nasty problem with one of your > internet facing system (details will only be provided to @nytimes.com or > related addresses). And as always, please respond off list. > > > > Thanks, > Adam Stasiniewicz > > 608-554-1522 > > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From stasinia at msoe.edu Thu Jun 25 23:24:15 2009 From: stasinia at msoe.edu (Stasiniewicz, Adam) Date: Thu, 25 Jun 2009 23:24:15 -0500 Subject: Looking for Security / Operational Contact at New York Times In-Reply-To: References: <011b01c9f603$d11fd970$735f8c50$@edu> Message-ID: <012801c9f615$f74e74f0$e5eb5ed0$@edu> Yup, I have already tried, but it is fairly late in NY. So I was hoping to catch someone tonight, instead of waiting until tomorrow morning when someone cluefull would answer the phone / process online contact forms. -----Original Message----- From: Martin Hannigan [mailto:martin at theicelandguy.com] Sent: Thursday, June 25, 2009 11:03 PM To: Stasiniewicz, Adam; nanog at nanog.org Subject: Re: Looking for Security / Operational Contact at New York Times If this is a private problem, why not look them up in 411 and call them directly? On 6/25/09, Stasiniewicz, Adam wrote: > Hello, > > > > In the off chance there is someone who works at the New York Times on this > list, please contact me ASAP, there is a very nasty problem with one of your > internet facing system (details will only be provided to @nytimes.com or > related addresses). And as always, please respond off list. > > > > Thanks, > Adam Stasiniewicz > > 608-554-1522 > > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From randy at psg.com Fri Jun 26 00:28:29 2009 From: randy at psg.com (Randy Bush) Date: Fri, 26 Jun 2009 14:28:29 +0900 Subject: Looking for Security / Operational Contact at New York Times In-Reply-To: References: <011b01c9f603$d11fd970$735f8c50$@edu> Message-ID: > If this is a private problem, why not look them up in 411 and call > them directly? why, when someone asks for a contact on this list is there an implicit assumption that they are too stupid to have done their homework? randy From bruns at 2mbit.com Fri Jun 26 00:32:39 2009 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 25 Jun 2009 23:32:39 -0600 Subject: Looking for Security / Operational Contact at New York Times In-Reply-To: References: <011b01c9f603$d11fd970$735f8c50$@edu> Message-ID: <4A445D77.9010105@2mbit.com> On 6/25/09 11:28 PM, Randy Bush wrote: > why, when someone asks for a contact on this list is there an implicit > assumption that they are too stupid to have done their homework? Cause, its a common delusion to think that big companies actually put valid contact information either on whois or their website that leads to a person who actually knows how to do the job they are assigned. :) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bruns at 2mbit.com Fri Jun 26 00:35:06 2009 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 25 Jun 2009 23:35:06 -0600 Subject: Fwd: Autoreply: Re: Looking for Security / Operational Contact at New York Times Message-ID: <4A445E0A.3060803@2mbit.com> *grumbles something about people and their !@#$% autoresponders* Is there anything that is done when this stupidity crops up? -------- Original Message -------- Subject: Out of Office AutoReply: Looking for Security / Operational Conta ct at New York Times Date: Fri, 26 Jun 2009 01:35:05 -0400 From: Gearry Judkins To: Brielle Bruns I am out of the office until Monday, July 6th. All requests for phone, computer, or pager problems should go to helpdesk at fchn.org. I may check mail periodically, but all urgent matters should be routed to helpdesk at fchn.org or bill.colwell at fchn.org . -------- Original Message -------- Subject: Autoreply: Re: Looking for Security / Operational Contact at New York Times Date: Thu, 25 Jun 2009 22:31:56 -0700 From: To: I will be out of the office until July 1st. If you require immediate assistance, please call 425-376-1126 or e-mail support at netos.com. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org . From tjc at ecs.soton.ac.uk Fri Jun 26 04:09:13 2009 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 26 Jun 2009 10:09:13 +0100 Subject: softlayer: ipv6 netfow tools In-Reply-To: References: <20090626090913.GC7033@login.ecs.soton.ac.uk> Message-ID: On Thu, Jun 25, 2009 at 07:03:49PM -0500, Ric Moseley wrote: > Just wondering what people were using to analyze IPv6 Netflow. I am > exporting IPv6 (along with IPv4 sampled) to a server that is running > flow-tools as well as to an Arbor SP system. The Cisco's I am exporting > from only allow flow export of both IPv4 and IPv6 simultaneously to an > IPv4 address. Arbor claims support early next year so I am looking for > another solution in the meantime. Hi, We use nfsen, and are pretty happy with it. http://sourceforge.net/projects/nfsen/ Tim From martin at theicelandguy.com Fri Jun 26 06:25:53 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Fri, 26 Jun 2009 07:25:53 -0400 Subject: Looking for Security / Operational Contact at New York Times In-Reply-To: References: <011b01c9f603$d11fd970$735f8c50$@edu> Message-ID: I think you're assuming that the rest of us think everyone is stupid too. :-) Best, Marty On 6/26/09, Randy Bush wrote: >> If this is a private problem, why not look them up in 411 and call >> them directly? > > why, when someone asks for a contact on this list is there an implicit > assumption that they are too stupid to have done their homework? > > randy > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From simon at darkmere.gen.nz Fri Jun 26 06:36:54 2009 From: simon at darkmere.gen.nz (Simon Lyall) Date: Fri, 26 Jun 2009 23:36:54 +1200 (NZST) Subject: Fwd: Autoreply: Re: Looking for Security / Operational Contact at New York Times In-Reply-To: <4A445E0A.3060803@2mbit.com> References: <4A445E0A.3060803@2mbit.com> Message-ID: On Thu, 25 Jun 2009, Brielle Bruns wrote: > *grumbles something about people and their !@#$% autoresponders* > > Is there anything that is done when this stupidity crops up? Yes, please forward such problems to admins at nanog.org rather than to the main list. Section 8 of the AUP specifically prohibits auto-responders and the MLC usually sets people to "nomail" on the first offense. Simon. NANOG MLC -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT. From cidr-report at potaroo.net Fri Jun 26 07:00:07 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 26 Jun 2009 22:00:07 +1000 (EST) Subject: BGP Update Report Message-ID: <200906261200.n5QC0711034287@wattle.apnic.net> BGP Update Report Interval: 18-Jun-09 -to- 25-Jun-09 (8 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9198 53777 5.8% 187.4 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - AS33783 11085 1.2% 75.9 -- EEPAD 3 - AS22783 9493 1.0% 1582.2 -- WEBPOWER - WebPower, Inc. 4 - AS14117 8964 1.0% 25.2 -- Telefonica del Sur S.A. 5 - AS14434 8607 0.9% 151.0 -- 6 - AS29049 8284 0.9% 26.1 -- DELTA-TELECOM-AS Delta Telecom LTD. 7 - AS47408 7741 0.8% 351.9 -- MANDARIN-AS Mandarin WIMAX Sicilia SpA 8 - AS21491 7729 0.8% 386.4 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 9 - AS30890 7642 0.8% 18.3 -- EVOLVA Evolva Telecom 10 - AS1221 7512 0.8% 13.2 -- ASN-TELSTRA Telstra Pty Ltd 11 - AS4134 7490 0.8% 7.7 -- CHINANET-BACKBONE No.31,Jin-rong Street 12 - AS1659 7378 0.8% 22.7 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center 13 - AS20115 6899 0.7% 4.1 -- CHARTER-NET-HKY-NC - Charter Communications 14 - AS2764 6231 0.7% 18.3 -- AAPT AAPT Limited 15 - AS34744 6119 0.7% 32.4 -- GVM SC GVM SISTEM 2003 SRL 16 - AS4812 5538 0.6% 6.2 -- CHINANET-SH-AP China Telecom (Group) 17 - AS30969 5029 0.5% 314.3 -- TAN-NET TransAfrica Networks 18 - AS6389 4985 0.5% 1.2 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 19 - AS35805 4881 0.5% 13.8 -- UTG-AS United Telecom AS 20 - AS3816 4766 0.5% 12.9 -- COLOMBIA TELECOMUNICACIONES S.A. ESP TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS14150 3637 0.4% 1818.5 -- PFCL2-ASN - Partnership Financial Consulting, LLC 2 - AS22783 9493 1.0% 1582.2 -- WEBPOWER - WebPower, Inc. 3 - AS46132 494 0.1% 494.0 -- MINCOM-NAM - Mincom, Inc. 4 - AS32343 429 0.1% 429.0 -- INTRINSIC-THERAPEUTICS - Intrinsic Orthopedics/Therapeutics, Inc. 5 - AS47640 807 0.1% 403.5 -- TRICOMPAS Tricomp Sp. z. o. o. 6 - AS21491 7729 0.8% 386.4 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 7 - AS25546 3009 0.3% 376.1 -- BROOKLANDCOMP-AS Brookland Computer Services 8 - AS47408 7741 0.8% 351.9 -- MANDARIN-AS Mandarin WIMAX Sicilia SpA 9 - AS30183 320 0.0% 320.0 -- BASESPACE-AS - BaseSpace.net 10 - AS30969 5029 0.5% 314.3 -- TAN-NET TransAfrica Networks 11 - AS4796 269 0.0% 269.0 -- BANDUNG-NET-AS-AP Institute of Technology Bandung 12 - AS35400 1592 0.2% 265.3 -- MFIST Interregoinal Organization Network Technologies 13 - AS5050 3766 0.4% 251.1 -- PSC-EXT - Pittsburgh Supercomputing Center 14 - AS41189 241 0.0% 241.0 -- ICONCEPT-AS iConcept 15 - AS37011 1131 0.1% 226.2 -- MSTARTEL-AS 16 - AS39803 450 0.1% 225.0 -- UTI-AS SC UTI COMMUNICATIONS SYSTEMS SRL 17 - AS39773 206 0.0% 206.0 -- HOSTED-SIEMENS-COMLU Siemens Communications Group Luxembourg 18 - AS23384 412 0.0% 206.0 -- REEDTECH - Reed Technology and Information Services, Inc. 19 - AS42214 201 0.0% 201.0 -- IWC-AS SC International Work Company SRL 20 - AS9198 53777 5.8% 187.4 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 89.218.220.0/23 6325 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - 89.218.218.0/23 6325 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 3 - 88.204.221.0/24 6322 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 4 - 92.46.244.0/23 6320 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 5 - 95.59.1.0/24 6320 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 6 - 95.59.8.0/23 6319 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 7 - 95.59.2.0/23 6319 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 8 - 95.59.4.0/22 6319 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 9 - 72.23.246.0/24 3714 0.4% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 10 - 205.246.203.0/24 3650 0.4% AS22783 -- WEBPOWER - WebPower, Inc. 11 - 63.163.66.0/24 3650 0.4% AS22783 -- WEBPOWER - WebPower, Inc. 12 - 204.11.157.0/24 3636 0.4% AS14150 -- PFCL2-ASN - Partnership Financial Consulting, LLC 13 - 193.201.184.0/21 2974 0.3% AS25546 -- BROOKLANDCOMP-AS Brookland Computer Services 14 - 65.113.90.0/24 2203 0.2% AS14434 -- 15 - 65.212.89.0/24 2190 0.2% AS22783 -- WEBPOWER - WebPower, Inc. 16 - 66.248.162.0/23 2143 0.2% AS14434 -- 17 - 65.113.106.0/24 2097 0.2% AS14434 -- 18 - 65.113.111.0/24 2097 0.2% AS14434 -- 19 - 196.27.104.0/21 2054 0.2% AS30969 -- TAN-NET TransAfrica Networks 20 - 196.27.108.0/22 2028 0.2% AS30969 -- TAN-NET TransAfrica Networks 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 Jun 26 07:00:03 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 26 Jun 2009 22:00:03 +1000 (EST) Subject: The Cidr Report Message-ID: <200906261200.n5QC03mv034276@wattle.apnic.net> This report has been generated at Fri Jun 26 21:13:59 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 19-06-09 295035 183949 20-06-09 295091 184006 21-06-09 295116 184024 22-06-09 295144 183493 23-06-09 295159 183803 24-06-09 295207 183718 25-06-09 294949 183021 26-06-09 295286 183036 AS Summary 31655 Number of ASes in routing system 13441 Number of ASes announcing only one prefix 4286 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 89737472 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'). --- 26Jun09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 295342 183033 112309 38.0% All ASes AS6389 4267 334 3933 92.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4286 1794 2492 58.1% TWTC - tw telecom holdings, inc. AS4766 1811 520 1291 71.3% KIXS-AS-KR Korea Telecom AS17488 1541 283 1258 81.6% HATHWAY-NET-AP Hathway IP Over Cable Internet AS1785 1695 656 1039 61.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1216 194 1022 84.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1065 67 998 93.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1459 604 855 58.6% Uninet S.A. de C.V. AS19262 1016 233 783 77.1% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8452 940 263 677 72.0% TEDATA TEDATA AS18566 1062 409 653 61.5% COVAD - Covad Communications Co. AS6478 1394 750 644 46.2% ATT-INTERNET3 - AT&T WorldNet Services AS18101 751 110 641 85.4% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS17908 681 58 623 91.5% TCISL Tata Communications AS9498 638 70 568 89.0% BBIL-AP BHARTI Airtel Ltd. AS24560 720 194 526 73.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7029 601 90 511 85.0% WINDSTREAM - Windstream Communications Inc AS11492 1116 621 495 44.4% CABLEONE - CABLE ONE, INC. AS2706 534 42 492 92.1% PI-HK Pacnet Internet (Hong Kong) Limited AS17676 564 80 484 85.8% GIGAINFRA Softbank BB Corp. AS4808 643 167 476 74.0% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS22047 598 123 475 79.4% VTR BANDA ANCHA S.A. AS4134 949 475 474 49.9% CHINANET-BACKBONE No.31,Jin-rong Street AS10620 918 452 466 50.8% TV Cable S.A. AS7018 1503 1043 460 30.6% ATT-INTERNET4 - AT&T WorldNet Services AS12479 449 8 441 98.2% UNI2-AS Uni2 Autonomous System AS7545 827 388 439 53.1% TPG-INTERNET-AP TPG Internet Pty Ltd AS4804 679 247 432 63.6% MPX-AS Microplex PTY LTD AS9443 521 91 430 82.5% INTERNETPRIMUS-AS-AP Primus Telecommunications AS6517 672 252 420 62.5% RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc Total 35116 10618 24498 69.8% 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 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.83.208.0/20 AS32311 216.83.208.0/24 AS32311 216.83.209.0/24 AS32311 216.83.210.0/24 AS32311 216.83.212.0/24 AS32311 216.83.213.0/24 AS32311 216.83.218.0/24 AS32311 216.83.219.0/24 AS32311 216.83.220.0/24 AS32311 216.83.221.0/24 AS32311 216.83.222.0/24 AS32311 216.83.223.0/24 AS32311 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 rah at shipwright.com Fri Jun 26 09:42:49 2009 From: rah at shipwright.com (R.A. Hettinga) Date: Fri, 26 Jun 2009 10:42:49 -0400 Subject: A Few Random Thoughts... References: <20090626134321.GH23524@leitl.org> Message-ID: As with anonymous remailers, or any other anonymous system, the exit node of an onion-routing system is the sin-eater for the rest of the network. And, without cash settlement, you get what you pay for. :-). Cheers, RAH ------- Begin forwarded message: From: Eugen Leitl Date: June 26, 2009 9:43:21 AM GMT-04:00 To: tt at postbiota.org, info at postbiota.org, cypherpunks at al-qaeda.net Subject: A Few Random Thoughts... ----- Forwarded message from Michael ----- From: Michael Date: Fri, 26 Jun 2009 08:16:00 -0400 To: or-talk at seul.org Subject: A Few Random Thoughts... User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) Reply-To: or-talk at freehaven.net Hi all, As one of those lucky souls with access to almost limitless bandwidth and the skills (or stupidity) to use it, I suppose an apology is in order: I'm sorry- after reviewing what *could* be the consequences, I have to whimp out based on professional risk factors... I can't run an exit node. So I have to leave it to other folks who have a different situation to do the heavy lifting. What I *am* doing is deploying a couple of heavy iron closed relays on OC3 or better bandwidth. The first is now deployed after a lot of up and down testing, and I'll get to the second in due time. I've been watching Tor for a long time and just recently decided to get involved. The Iran situation cemented that decision. Anyhow, here are some random thoughts: On the "Who uses Tor?" section of the website, I see no mention of IT people. I've used the Tor network for many practical uses as an IT Director. These range from bypassing my own firewall to test incoming connections, to helping my legal department do research on a pending lawsuit without the opposition *knowing* we even looked at their website. Having a random and easily accessible IP to initiate connections from is a priceless testing tool. Especially when dealing with niggling routing problems. On one occasion my ISP was having routing/DNS problems, and Tor was able to find an entrance node and allow me to work even though I couldn't get to my remote servers directly. This saved my client a lot of downtime, and might have saved me the account. Also, my employer's R&D department sometimes needs to look at things they don't want anyone to know they looked at (All quite legal mind you). Quite frankly Tor is an undervalued IT tool and it's capabilities should be trumpeted loudly on the web page. You might also find IT guys like me throwing up some relays in exchange. After all- who has the bandwidth anyway? And before anyone accuses me of it, I'm not nearly stupid enough to do a port scan over Tor. Phew. One of the issues I ran into when looking into running an exit relay had to do with not only the legalities, but identifying a server vendor that was offshore from my home country and friendly to a Tor exit. In order for me to run an exit node, I have to be completely shielded. As it stands now, I can probably run an exit for instant messaging- and that's it. However, if Tor itself had a relationship with someone who rents hardware, perhaps a partnership, Tor could get the exit nodes it needs, and the server vendor could get lots of cash. From my standpoint, it doesn't matter whether I rent or colocate my hardware. So if Tor as an organization had a partnership with a few server rental whores (in multiple countries), it would simplify getting more exits. I need servers, Tor runs with little impact on my server, I could care less where my remote hardware is provisioned from. Bingo- more exits. I read back about 6 months in the or-talk list and there were a couple of suggestions inferring that *everyone* should be forced to be an exit node. I think this is a very bad idea, and hurts the security of the person trying to remain anonymous by causing an identifiable change in bandwidth usage that could infer Tor usage (Information leakage). Simply speaking, on a default Windows/Vidalia installation, outgoing Tor traffic usually looks like https traffic, but on a forced exit, now Tor is identified by relatively matched traffic on port 443 both in and out of the client's connection (Unless it's entrance node is a *nix variant). This could mean death (literal) for a political dissident who is now identified as having an in/out matching traffic pattern assuming his entrance node is on Windows. It is more likely, that a country monitoring it's citizens would miss simple https traffic. But even myself as a lowly IT director, would have alarm bells going off if https was initiating in two directions from the same machine. Alternative ports can also set off alarm bells. But given the nature of Onion Routing, two way traffic needs to be avoided in the most sensitive sensitive situations. Forcing exit nodes is a bad idea for users. It will also drive away anyone who cannot provide an exit node.... that's chasing away bandwidth as non exit relays run for the hills. Long post. Too much coffee and too much time staring at routing tables. Michael ----- End forwarded message ----- -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From cscora at apnic.net Fri Jun 26 13:13:24 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 27 Jun 2009 04:13:24 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200906261813.n5QIDOFg025326@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 27 Jun, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 289314 Prefixes after maximum aggregation: 137532 Deaggregation factor: 2.10 Unique aggregates announced to Internet: 143144 Total ASes present in the Internet Routing Table: 31577 Prefixes per ASN: 9.16 Origin-only ASes present in the Internet Routing Table: 27449 Origin ASes announcing only one prefix: 13372 Transit ASes present in the Internet Routing Table: 4128 Transit-only ASes present in the Internet Routing Table: 92 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: 465 Unregistered ASNs in the Routing Table: 130 Number of 32-bit ASNs allocated by the RIRs: 183 Prefixes from 32-bit ASNs in the Routing Table: 61 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 845 Number of addresses announced to Internet: 2060355024 Equivalent to 122 /8s, 206 /16s and 133 /24s Percentage of available address space announced: 55.6 Percentage of allocated address space announced: 64.3 Percentage of available address space allocated: 86.4 Percentage of address space in use by end-sites: 77.5 Total number of prefixes smaller than registry allocations: 143081 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 69089 Total APNIC prefixes after maximum aggregation: 24566 APNIC Deaggregation factor: 2.81 Prefixes being announced from the APNIC address blocks: 68502 Unique aggregates announced from the APNIC address blocks: 30738 APNIC Region origin ASes present in the Internet Routing Table: 3683 APNIC Prefixes per ASN: 18.60 APNIC Region origin ASes announcing only one prefix: 1003 APNIC Region transit ASes present in the Internet Routing Table: 563 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 460662416 Equivalent to 27 /8s, 117 /16s and 38 /24s Percentage of available APNIC address space announced: 85.8 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: 123464 Total ARIN prefixes after maximum aggregation: 66016 ARIN Deaggregation factor: 1.87 Prefixes being announced from the ARIN address blocks: 124206 Unique aggregates announced from the ARIN address blocks: 51842 ARIN Region origin ASes present in the Internet Routing Table: 13056 ARIN Prefixes per ASN: 9.51 ARIN Region origin ASes announcing only one prefix: 5016 ARIN Region transit ASes present in the Internet Routing Table: 1286 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 1009889856 Equivalent to 60 /8s, 49 /16s and 178 /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: 66136 Total RIPE prefixes after maximum aggregation: 39167 RIPE Deaggregation factor: 1.69 Prefixes being announced from the RIPE address blocks: 65269 Unique aggregates announced from the RIPE address blocks: 43954 RIPE Region origin ASes present in the Internet Routing Table: 13209 RIPE Prefixes per ASN: 4.94 RIPE Region origin ASes announcing only one prefix: 6900 RIPE Region transit ASes present in the Internet Routing Table: 1980 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 22 Number of RIPE addresses announced to Internet: 483628352 Equivalent to 28 /8s, 211 /16s and 149 /24s Percentage of available RIPE address space announced: 103.0 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: 24127 Total LACNIC prefixes after maximum aggregation: 5978 LACNIC Deaggregation factor: 4.04 Prefixes being announced from the LACNIC address blocks: 23993 Unique aggregates announced from the LACNIC address blocks: 13443 LACNIC Region origin ASes present in the Internet Routing Table: 1127 LACNIC Prefixes per ASN: 21.29 LACNIC Region origin ASes announcing only one prefix: 362 LACNIC Region transit ASes present in the Internet Routing Table: 189 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 19 Number of LACNIC addresses announced to Internet: 71744256 Equivalent to 4 /8s, 70 /16s and 187 /24s Percentage of available LACNIC address space announced: 71.3 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: 6091 Total AfriNIC prefixes after maximum aggregation: 1486 AfriNIC Deaggregation factor: 4.10 Prefixes being announced from the AfriNIC address blocks: 6485 Unique aggregates announced from the AfriNIC address blocks: 2509 AfriNIC Region origin ASes present in the Internet Routing Table: 300 AfriNIC Prefixes per ASN: 21.62 AfriNIC Region origin ASes announcing only one prefix: 91 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: 20142592 Equivalent to 1 /8s, 51 /16s and 90 /24s Percentage of available AfriNIC address space announced: 60.0 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 1706 6930 403 Korea Telecom (KIX) 17488 1536 138 95 Hathway IP Over Cable Interne 4755 1216 327 138 TATA Communications formerly 9583 1116 89 557 Sify Limited 4134 949 17104 377 CHINANET-BACKBONE 7545 807 198 101 TPG Internet Pty Ltd 23577 783 34 666 Korea Telecom (ATM-MPLS) 18101 752 201 33 Reliance Infocom Ltd Internet 24560 721 230 172 Bharti Airtel Ltd. 9829 714 603 18 BSNL National Internet Backbo 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 4272 3647 324 bellsouth.net, inc. 4323 1877 1039 380 Time Warner Telecom 1785 1697 714 138 PaeTec Communications, Inc. 7018 1503 5925 1042 AT&T WorldNet Services 20115 1404 1470 672 Charter Communications 6478 1394 307 432 AT&T Worldnet Services 2386 1265 670 919 AT&T Data Communications Serv 3356 1202 10964 449 Level 3 Communications, LLC 11492 1117 208 12 Cable One 22773 1064 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 3292 456 1902 393 TDC Tele Danmark 12479 450 578 6 Uni2 Autonomous System 702 428 1861 345 UUNET - Commercial IP service 30890 418 88 198 Evolva Telecom 35805 353 40 5 United Telecom of Georgia 8866 351 109 21 Bulgarian Telecommunication C 3301 347 1668 309 TeliaNet Sweden 3215 341 3041 106 France Telecom Transpac 3320 340 7067 298 Deutsche Telekom AG 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 1459 2879 233 UniNet S.A. de C.V. 10620 918 210 113 TVCABLE BOGOTA 22047 599 302 14 VTR PUNTO NET S.A. 28573 581 570 31 NET Servicos de Comunicao S.A 7303 566 299 86 Telecom Argentina Stet-France 11830 486 293 63 Instituto Costarricense de El 11172 441 102 70 Servicios Alestra S.A de C.V 6471 439 96 31 ENTEL CHILE S.A. 7738 404 794 28 Telecomunicacoes da Bahia S.A 3816 371 189 83 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 940 188 7 TEDATA 24863 892 85 42 LINKdotNET AS number 20858 324 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 4272 3647 324 bellsouth.net, inc. 4323 1877 1039 380 Time Warner Telecom 4766 1706 6930 403 Korea Telecom (KIX) 1785 1697 714 138 PaeTec Communications, Inc. 17488 1536 138 95 Hathway IP Over Cable Interne 7018 1503 5925 1042 AT&T WorldNet Services 8151 1459 2879 233 UniNet S.A. de C.V. 20115 1404 1470 672 Charter Communications 6478 1394 307 432 AT&T Worldnet Services 2386 1265 670 919 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 1785 1697 1559 PaeTec Communications, Inc. 4323 1877 1497 Time Warner Telecom 17488 1536 1441 Hathway IP Over Cable Interne 4766 1706 1303 Korea Telecom (KIX) 8151 1459 1226 UniNet S.A. de C.V. 11492 1117 1105 Cable One 4755 1216 1078 TATA Communications formerly 18566 1062 1052 Covad Communications 22773 1064 998 Cox Communications, Inc. 6478 1394 962 AT&T Worldnet Services 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.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 64.31.59.0/24 7017 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:606 /15:1159 /16:10512 /17:4751 /18:8177 /19:16879 /20:20304 /21:20131 /22:26072 /23:25781 /24:151676 /25:881 /26:1031 /27:557 /28:147 /29:8 /30:6 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2782 4272 bellsouth.net, inc. 4766 1399 1706 Korea Telecom (KIX) 17488 1282 1536 Hathway IP Over Cable Interne 1785 1173 1697 PaeTec Communications, Inc. 11492 1044 1117 Cable One 18566 1043 1062 Covad Communications 2386 983 1265 AT&T Data Communications Serv 9583 968 1116 Sify Limited 4323 959 1877 Time Warner Telecom 7018 871 1503 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:204 12:2240 13:10 15:19 16:3 17:4 20:36 24:1050 32:52 34:2 38:574 40:96 41:1710 43:1 44:2 47:15 52:4 55:2 56:3 57:24 58:574 59:643 60:459 61:1080 62:1115 63:2015 64:3727 65:2384 66:3605 67:1638 68:805 69:2662 70:554 71:145 72:1667 73:2 74:1593 75:167 76:326 77:847 78:555 79:357 80:973 81:841 82:562 83:436 84:637 85:1040 86:397 87:661 88:354 89:1437 90:57 91:2362 92:349 93:1128 94:1232 95:1071 96:143 97:216 98:249 99:23 110:162 111:41 112:137 113:126 114:261 115:304 116:1156 117:534 118:301 119:709 120:142 121:759 122:1036 123:699 124:975 125:1342 128:223 129:237 130:127 131:412 132:74 133:9 134:185 135:38 136:224 137:162 138:164 139:80 140:443 141:120 142:380 143:346 144:364 145:48 146:381 147:155 148:519 149:238 150:177 151:193 152:145 153:145 154:2 155:276 156:171 157:301 158:116 159:343 160:284 161:153 162:273 163:161 164:482 165:500 166:456 167:359 168:665 169:168 170:476 171:39 172:10 173:303 174:227 178:1 180:1 183:1 186:96 187:96 188:106 189:434 190:2810 192:5785 193:4243 194:3308 195:2701 196:1099 198:3599 199:3341 200:5102 201:1286 202:7912 203:8236 204:3874 205:2161 206:2438 207:2726 208:3890 209:3404 210:2677 211:1128 212:1567 213:1660 214:80 215:30 216:4551 217:1309 218:394 219:430 220:1223 221:483 222:304 End of report From cldeluna at yahoo.com Fri Jun 26 18:19:47 2009 From: cldeluna at yahoo.com (Claudia de Luna) Date: Fri, 26 Jun 2009 16:19:47 -0700 (PDT) Subject: Recommendations on Centralized Modem Server/Resource In-Reply-To: References: <011b01c9f603$d11fd970$735f8c50$@edu> Message-ID: <577663.44422.qm@web52501.mail.re2.yahoo.com> Hi, I'm involved in a state-wide InBand/OOB management terminal server deployment for network infrastructure equipment and am looking for recommendations on centralized modem servers for the network team at a central location. Ideally the network team would use this centralized service to access the new terminal servers deployed across the state from their desktops via ssh vs. provisioning POTS lines and modems at all the engineers desk? We will leverage laptops and available modem lines as well but I'm looking for a permanent, always available solution that does not involve booting up your laptop, etc... Any recommendations on what you've seen work well, product recommendations (or warnings), or overall solutions would be very welcome. Thanks, Claudia From charles at thewybles.com Fri Jun 26 21:51:13 2009 From: charles at thewybles.com (Charles Wyble) Date: Fri, 26 Jun 2009 19:51:13 -0700 Subject: Looking for Security / Operational Contact at New York Times In-Reply-To: <012801c9f615$f74e74f0$e5eb5ed0$@edu> References: <011b01c9f603$d11fd970$735f8c50$@edu> <012801c9f615$f74e74f0$e5eb5ed0$@edu> Message-ID: <4A458921.80001@thewybles.com> They don't have a 24/7 NOC? Stasiniewicz, Adam wrote: > Yup, I have already tried, but it is fairly late in NY. So I was hoping to > catch someone tonight, instead of waiting until tomorrow morning when > someone cluefull would answer the phone / process online contact forms. > > > -----Original Message----- > From: Martin Hannigan [mailto:martin at theicelandguy.com] > Sent: Thursday, June 25, 2009 11:03 PM > To: Stasiniewicz, Adam; nanog at nanog.org > Subject: Re: Looking for Security / Operational Contact at New York Times > > If this is a private problem, why not look them up in 411 and call > them directly? > > > > On 6/25/09, Stasiniewicz, Adam wrote: >> Hello, >> >> >> >> In the off chance there is someone who works at the New York Times on this >> list, please contact me ASAP, there is a very nasty problem with one of > your >> internet facing system (details will only be provided to @nytimes.com or >> related addresses). And as always, please respond off list. >> >> >> >> Thanks, >> Adam Stasiniewicz >> >> 608-554-1522 >> >> > > From fernando at gont.com.ar Sat Jun 27 14:50:50 2009 From: fernando at gont.com.ar (Fernando Gont) Date: Sat, 27 Jun 2009 16:50:50 -0300 Subject: Security Assessment of TCP at the IETF Message-ID: <4A46781A.4020509@gont.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, folks, In February this year the UK CPNI published the document "Security Assessment of the Transmission Control Protocol (TCP)" (available at: http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf) Earlier this year we published an IETF Internet-Draft version of this document (available at: http://www.gont.com.ar/drafts/tcp-security/draft-gont-tcp-security-00.txt) in the hope of having the IETF further work on the TCP security paper UK CPNI had published. My personal take (possibly biased, since I am the document author) is that this document has been the result of a lot of work (including the work of the many peple that reviewed the CPNI version of the document), and that the IETF should take this chance to work and publish something on the subject. The chairs of the TCPM Working Group of the IETF are currently polling the WG for input about this document. It would be great if you could voice your opinion about whether the TCPM should take this document on, and also whether you would be willing to review this document. (Bellow you'll find a copy of the TCPM chairs' poll) Please send your comments to tcpm at ietf.org (and please CC me). Thanks! Kind regards, Fernando - -------- Original Message -------- Subject: [tcpm] poll for adopting draft-gont-tcp-security Date: Wed, 24 Jun 2009 14:25:04 -0500 From: Eddy, Wesley M. (GRC-MS00)[Verizon] To: tcpm Extensions WG TCPMers, there was a thread a while ago about working on draft-gont-tcp-security in this working group that didn't conclusively give us a feeling one way or other: http://www.ietf.org/mail-archive/web/tcpm/current/msg04489.html Basically, my understanding is that there are at least a handful of people in the WG that think it should be done here as a WG item (more likely for Informational rather than BCP), and there are also some expressed opinions on why it shouldn't. Given the raw size of the document, if the WG intends to take this document on, then we need some people to clearly commit to putting cycles into review and contributions to the document. Since it is quite large, and to my knowledge, there hasn't been a specific technical review of the content on this list, but just discussions about if the idea in general is a good or bad thing, we still need to know if people are willing to invest their time and energy in this. Please let us know if there is traction for this in the near term, and/or we can also discuss it in Stockholm. - --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 - --------------------------- _______________________________________________ tcpm mailing list tcpm at ietf.org https://www.ietf.org/mailman/listinfo/tcpm - -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBCAAGBQJKRngWAAoJEJbuqe/Qdv/xn7AIAMeN8Yz3JeAC+WIbThkBK7Xe D/kRdi6mO7ffX2etNPec4vlgbrzkjnef3PTB6GGrJGkyACm/J/NuMEj/1k8GqqtS 7byVkfTQSDsm64e44el4A6tqGlxw/GnRagK5I9VpC8PvTeLuhAxCuMhblhpeZQyD SdnOInqxXYg57FDXPWq1bWIvNWZ8xUAAmAbE5ppSOYBGUoG5jua4ONGDdo5FYvpz ABvVF1lKds+4dGimGjEHH10OIaVhHvuxIX2IIsG0REBHkK3z/Pij7+RvrrlsIRLS R0rvgCL78nQCvyYYiepcKpMrL6iEe3YP4RlVfTgnhKI+a3qZo0TFTSjheuh6Bmg= =6b3p -----END PGP SIGNATURE----- From nanog at grrrrreg.net Sun Jun 28 07:20:47 2009 From: nanog at grrrrreg.net (Gregoire Villain) Date: Sun, 28 Jun 2009 14:20:47 +0200 Subject: ISP best practices In-Reply-To: <408493.6724.qm@web30807.mail.mud.yahoo.com> References: <408493.6724.qm@web30807.mail.mud.yahoo.com> Message-ID: <63D3918B-FB6E-4BFB-B9CC-F9DDD3328380@grrrrreg.net> On May 21, 2009, at 3:38 PM, Philip Lavine wrote: > > To all, > > I am sure this has been asked 10 to the 1 millionth power times, > however may be the rules have changed. I am looking to set up a > really small ISP with a few /24's. I want to host DNS as well. Is > there any whitepapers/howtos/best practices on setting up multihomed > BGP and DNS with BIND so I don't blow up the Internet. > > Thx > > Philip O Hai! I would highly advise you have a read at any presentation by Phil Smith: ftp://ftp-eng.cisco.com/pfs/seminars (anonymous login) Read as much as you can from here 1st thing 1st - this is all solid ground knowledge. Then, give a quick read at Cisco's BGP Case Study online on the CCO. And you're OK to go. Now if you want paper material that you can keep, I'd suggest "Internet Routing Architectures" by Sam Halabi - Cisco Press, even though it's getting old, I find it still very valid. Make sure you have a read at team-cymru.org before you roll out your AS, for their BOGONs/Martians ACLs and peerings, as it sure helps. Bear in mind BGP is a simplistic protocol. The pain point *will* be your IGP (if you want to do it correctly from start...) Greg VILLAIN From bbillon-nanog at splio.fr Thu Jun 25 16:11:11 2009 From: bbillon-nanog at splio.fr (Benjamin Billon) Date: Thu, 25 Jun 2009 23:11:11 +0200 Subject: Flow Chart In-Reply-To: <4A43DBCB.9030205@dhc.com.br> References: <4A43DBCB.9030205@dhc.com.br> Message-ID: <4A43E7EF.7090800@splio.fr> Hi, are you trying to draw per-AS charts? I'm using As-stats (https://neon1.net/as-stats/), this is not exactly the same thing because you'll see all AS' trafic even ASN you don't peer with, but it may still help. Good luck, Benjamin Alexandre Augusto Caramanti Coconesi a ?crit : > Hello > > This is my first post in this list. > > I have the follow situation: > > I have a multilateral peering, and I?m need to plot a graph showing > how many traffic is going to or comming from each member of peering. > > > For example: > > I have the AS61222, and in the peering there is the AS61333. This AS > have other peerings, And my AS (AS61222) use the AS61333 as transit. > And because it is a peering, by just one interface of my router, I can > see just the whole traffic, to AS61333, and another members of > peering. I was seeing some thing in JKFlow, but I did not found any > thing. > > Do you have any experience in a case like this? > > Thanks > From ops.lists at gmail.com Sun Jun 28 08:37:36 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 28 Jun 2009 19:07:36 +0530 Subject: ISP best practices In-Reply-To: <63D3918B-FB6E-4BFB-B9CC-F9DDD3328380@grrrrreg.net> References: <408493.6724.qm@web30807.mail.mud.yahoo.com> <63D3918B-FB6E-4BFB-B9CC-F9DDD3328380@grrrrreg.net> Message-ID: On Sun, Jun 28, 2009 at 5:50 PM, Gregoire Villain wrote: > I would highly advise you have a read at any presentation by Phil Smith: > ftp://ftp-eng.cisco.com/pfs/seminars (anonymous login) > Read as much as you can from here 1st thing 1st - this is all solid ground > knowledge. And Philip / Barry's Cisco ISP Essentials is a good buy, even if you use non cisco gear .. http://www.ciscopress.com/bookstore/product.asp?isbn=1587050412 --srs From nanog at grrrrreg.net Sun Jun 28 08:48:10 2009 From: nanog at grrrrreg.net (Gregoire Villain) Date: Sun, 28 Jun 2009 15:48:10 +0200 Subject: Flow Chart In-Reply-To: <4A43DBCB.9030205@dhc.com.br> References: <4A43DBCB.9030205@dhc.com.br> Message-ID: <94EE40EB-9BBE-46CE-88AA-8541D9A8E1A2@grrrrreg.net> On Jun 25, 2009, at 10:19 PM, Alexandre Augusto Caramanti Coconesi wrote: > Hello > > This is my first post in this list. > > I have the follow situation: > > I have a multilateral peering, and I?m need to plot a graph showing > how many traffic is going to or comming from each member of peering. > > > For example: > > I have the AS61222, and in the peering there is the AS61333. This AS > have other peerings, And my AS (AS61222) use the AS61333 as transit. > And because it is a peering, by just one interface of my router, I > can see just the whole traffic, to AS61333, and another members of > peering. I was seeing some thing in JKFlow, but I did not found any > thing. > > Do you have any experience in a case like this? > > Thanks > > -- > Alexandre Coconesi I've used PMACCT in the past, with PNRG as a frontend, did the trick perfectly - used it to list/rank the ASes which I was sending traffic too. pNRG on top of that will do the graphing. I think PMACCT works with both SFlow and NetFlow. Watch out for the sampling rate when activating it on your kits tho, bad surprises ahead and a world of pain if you use too aggressive values at start. If you're SFlow exclusive and want a commercial solution, try InMon, it is supposed to be pretty good. Greg VILLAIN From bgreene at senki.org Sun Jun 28 09:18:23 2009 From: bgreene at senki.org (Barry Raveendran Greene) Date: Sun, 28 Jun 2009 07:18:23 -0700 Subject: ISP best practices In-Reply-To: <63D3918B-FB6E-4BFB-B9CC-F9DDD3328380@grrrrreg.net> References: <408493.6724.qm@web30807.mail.mud.yahoo.com> <63D3918B-FB6E-4BFB-B9CC-F9DDD3328380@grrrrreg.net> Message-ID: The best training available on the Net for a small ISP to learn from the best is available ..... At www.nanog.org! All the NANOGs are on VOD. Just go to the presentation archive: http://www.nanog.org/presentations/archive/. Put in a keyword to search (say "BGP Tutorial"), cook some popcorn, and sit back and enjoy the session. > -----Original Message----- > From: Gregoire Villain [mailto:nanog at grrrrreg.net] > Sent: Sunday, June 28, 2009 5:21 AM > To: nanog at nanog.org > Subject: Re: ISP best practices > > > On May 21, 2009, at 3:38 PM, Philip Lavine wrote: > > > > > To all, > > > > I am sure this has been asked 10 to the 1 millionth power times, > > however may be the rules have changed. I am looking to set > up a really > > small ISP with a few /24's. I want to host DNS as well. Is > there any > > whitepapers/howtos/best practices on setting up multihomed > BGP and DNS > > with BIND so I don't blow up the Internet. > > > > Thx > > > > Philip > > O Hai! > > I would highly advise you have a read at any presentation by > Phil Smith: > ftp://ftp-eng.cisco.com/pfs/seminars (anonymous login) Read > as much as you can from here 1st thing 1st - this is all > solid ground knowledge. > > Then, give a quick read at Cisco's BGP Case Study online on the CCO. > And you're OK to go. > > Now if you want paper material that you can keep, I'd suggest > "Internet Routing Architectures" by Sam Halabi - Cisco Press, > even though it's getting old, I find it still very valid. > Make sure you have a read at team-cymru.org before you roll > out your AS, for their BOGONs/Martians ACLs and peerings, as > it sure helps. > > Bear in mind BGP is a simplistic protocol. The pain point > *will* be your IGP (if you want to do it correctly from start...) > > Greg VILLAIN > > From nanog at data102.com Sun Jun 28 13:12:50 2009 From: nanog at data102.com (randal k) Date: Sun, 28 Jun 2009 12:12:50 -0600 Subject: ISP best practices In-Reply-To: <63D3918B-FB6E-4BFB-B9CC-F9DDD3328380@grrrrreg.net> References: <408493.6724.qm@web30807.mail.mud.yahoo.com> <63D3918B-FB6E-4BFB-B9CC-F9DDD3328380@grrrrreg.net> Message-ID: I agree with this whole heartedly. Phil Smith's presentations and papers are fantastic. I'm certain that a sizable portion of the Internet operates because of the material that he has, and continues to, put together. Cheers, Randal On Sun, Jun 28, 2009 at 6:20 AM, Gregoire Villain wrote: >> O Hai! > > I would highly advise you have a read at any presentation by Phil Smith: > ftp://ftp-eng.cisco.com/pfs/seminars (anonymous login) > Read as much as you can from here 1st thing 1st - this is all solid ground > knowledge. > From steve at ibctech.ca Sun Jun 28 17:55:26 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Sun, 28 Jun 2009 18:55:26 -0400 Subject: ISP best practices In-Reply-To: References: <408493.6724.qm@web30807.mail.mud.yahoo.com> <63D3918B-FB6E-4BFB-B9CC-F9DDD3328380@grrrrreg.net> Message-ID: <4A47F4DE.1090009@ibctech.ca> Barry Raveendran Greene wrote: > The best training available on the Net for a small ISP to learn from the > best is available ..... At www.nanog.org! > > All the NANOGs are on VOD. Just go to the presentation archive: > http://www.nanog.org/presentations/archive/. Put in a keyword to search (say > "BGP Tutorial"), cook some popcorn, and sit back and enjoy the session. It helps also to communicate with people. [speaking in small sp context] If you know any of the engineers or operators of your upstream, perhaps ask them questions from time to time. If you really know them (and are serious about learning) ask them if they can provide you sample config snips. Contact the people that run your local IXP. I've found that the operators of the exchange points are an aggregation point of 'the best of the best from the best' information, as they generally discuss solutions with chief engineers of all companies that connect to their fabric. IXP ops are a rich source not only of technical information, but also of industry best practises relating to how other providers might prefer to be approached, if they like or dislike feedback, and whether they care to be approached at all. Don't go bombarding your local IXP op with silly questions, it's just another decent source of information, as they seem to be like myself...if you ask a well-thought-out question, you will likely get an answer (even if it's "I dunno, look over there"). With the books I mentioned earlier in the thread, and that others have re-mentioned, I prefer: - read - lab up current environment - implement what you read in lab - test for breakage - pilot lab findings into production - update/tighten control features - implement across network - watch for inconsistencies, but continue to tighten rules - read more - rinse,repeat Steve ps. as always, thanks Jon. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature URL: From dennis at thenose.net Sun Jun 28 22:24:57 2009 From: dennis at thenose.net (Dennis Dayman) Date: Sun, 28 Jun 2009 22:24:57 -0500 Subject: ISP best practices In-Reply-To: References: <408493.6724.qm@web30807.mail.mud.yahoo.com> <63D3918B-FB6E-4BFB-B9CC-F9DDD3328380@grrrrreg.net> Message-ID: <17E2C2C8-C70D-471B-8343-105FB20DD494@thenose.net> >> On May 21, 2009, at 3:38 PM, Philip Lavine wrote: >> >>> >>> To all, >>> >>> I am sure this has been asked 10 to the 1 millionth power times, >>> however may be the rules have changed. I am looking to set >> up a really >>> small ISP with a few /24's. I want to host DNS as well. Is >> there any >>> whitepapers/howtos/best practices on setting up multihomed >> BGP and DNS >>> with BIND so I don't blow up the Internet. not sure if any of these help, but you might want to also take MAAWG's Published Documents http://www.maawg.org/about/publishedDocuments -Dennis From sherwin.ang at gmail.com Mon Jun 29 09:05:53 2009 From: sherwin.ang at gmail.com (Sherwin Ang) Date: Mon, 29 Jun 2009 22:05:53 +0800 Subject: OT: Bringing Cisco equipment to US Message-ID: Hello Nanog, sorry for the OT post but am frustrated to look for the information in the CBP website and i even called their number but got nothing for almost 8 minutes, just a recording. i'll be bringing in 2 cisco switches to one wilshire in LA to install those switches there. since these are small switches, 3750's, i'll be carrying them on the check-in luggage. I would like to get some information if i could be in trouble in any way with regards to Customs there in the US, i'll be coming from the Philippines by the way. insights, off list would be greatly appreciated. tnx! From chris.ledford at cnxntech.com Mon Jun 29 09:21:23 2009 From: chris.ledford at cnxntech.com (Chris Ledford) Date: Mon, 29 Jun 2009 10:21:23 -0400 Subject: QNET protocl ID 006A Message-ID: <8FAEFABA9446514DAEE6CF984573D5F90142D9F3CA7A@CORP-MAILBOX.capband.corp> I am looking for any information on QNET protocol ID 006A traffic...Our 7604 spikes to 100% every hour and 30 sec's....and I am seeing this traffic....any help on this would be appreciated.... NEOVERTIKA.7604#sh proc cpu hist 1111111111122222222222222222222111112222222222111112222211 6888886666644444777778888800000999993333388888888883333388 100 90 80 70 60 50 40 30 ********** ***** 20 ********************************************************** 10 ********************************************************** 0....5....1....1....2....2....3....3....4....4....5....5.... 0 5 0 5 0 5 0 5 0 5 CPU% per second (last 60 seconds) 1 2043535434343233433333433234333353533433536444433543426336 8033127794325960220499555465375507850545124033097221386492 100 * 90 * 80 * 70 * * 60 * * * * * * 50 * * ** * * * * * * * * * * 40 #* * **** ** * * ***** ** ******* * ** ********* * * ** 30 *#**#***#**#***********#* ***********#****####*####*#*#### 20 ########################################################## 10 ########################################################## 0....5....1....1....2....2....3....3....4....4....5....5.... 0 5 0 5 0 5 0 5 0 5 CPU% per minute (last 60 minutes) * = maximum CPU% # = average CPU% 111 11111 1111111111 11 1 111111 1111111 11111111111 111 11 1 1 0009000009000000000090090990000009780000000956900000000000900090090909 0009000009000000000090090990000009080000000988900000000000800090090909 100 ********************************** ******** ************************ 90 ********************************** ********* ************************ 80 ********************************** ********* ************************ 70 ******************************************** ************************* 60 ********************************************************************** 50 ********************************************************************** 40 ******#******#******************************************************** 30 #*########*######***********####*************************########***** 20 ###################****###################***##**###################** 10 ###################################################################### 0....5....1....1....2....2....3....3....4....4....5....5....6....6....7. 0 5 0 5 0 5 0 5 0 5 0 5 0 CPU% per hour (last 72 hours) * = maximum CPU% # = average CPU% Packets look like this: ------- dump of outgoing inband packet ------- interface IB0/0, routine draco2_ibc_soutput dbus info: src_vlan 0x0(0), src_indx 0x387(903), len 0x7C(124) bpdu 0, index_dir 0, flood 0, dont_lrn 1, dest_indx 0x0(0) 00020008 0000A800 03870000 7C000000 00000000 00000000 00000000 00000000 mistral hdr: req_token 0x0(0), src_index 0x387(903), rx_offset 0x30(48) requeue 0, obl_pkt 0, vlan 0x0(0) destmac 00.00.00.00.00.00, srcmac 00.18.74.2C.75.C0, protocol 006A layer 3 data: AAAA0300 000C0113 FF00FF00 02010000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000387 00000380 0812 ------- dump of outgoing inband packet ------- interface IB0/0, routine draco2_ibc_soutput dbus info: src_vlan 0x0(0), src_indx 0x387(903), len 0x7C(124) bpdu 0, index_dir 0, flood 0, dont_lrn 1, dest_indx 0x0(0) 00020008 0000A800 03870000 7C000000 00000000 00000000 00000000 00000000 mistral hdr: req_token 0x0(0), src_index 0x387(903), rx_offset 0x30(48) requeue 0, obl_pkt 0, vlan 0x0(0) destmac 00.00.00.00.00.00, srcmac 00.18.74.2C.75.C0, protocol 006A layer 3 data: AAAA0300 000C0113 FF00FF00 02010000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000387 00000380 0819 V/r Thanks in advance, Chris Ledford NOC ATOG Engineer CCNA/CCSP/CVOICE A+/NET+/SEC+/LINUX+/MCPe Connexion Technologies Office:1240 Commerce Drive, Suite A Gulf Shores, AL 36542 Mailing: P O Box 1245 Gulf Shores, AL 36547pan> NOC: 251-224-0662 P | 251.224.0972 or 251-224-0800 ext 65071 F | 251.224.0830 C | 251.923.8340 E | chris.ledford at cnxntech.com [cid:image001.gif at 01C9F89A.F85609D0] [cid:image002.gif at 01C9F89A.F85609D0] [cid:image003.gif at 01C9F89A.F85609D0] Connexion Technologies is the service mark and trade name of Capitol Infrastructure, LLC. Confidentiality Notice: The material in this e-mail is intended only for the use of the individual to whom it is addressed and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. This e-mail may not be forwarded without the consent of the original sender. If you are not the intended recipient, be advised that the unauthorized use, disclosure, copying, distribution, or the taking of any action in reliance on this information is strictly prohibited. If you have received this e-mail in error, please notify us immediately to arrange for the return of this material. Thank You. -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 1711 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1547 bytes Desc: image002.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.gif Type: image/gif Size: 5350 bytes Desc: image003.gif URL: From jabley at hopcount.ca Mon Jun 29 11:19:36 2009 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 29 Jun 2009 12:19:36 -0400 Subject: OT: Bringing Cisco equipment to US In-Reply-To: References: Message-ID: <9C25883F-4BCF-44BA-914E-8F41EA4394FB@hopcount.ca> On 29-Jun-2009, at 10:05, Sherwin Ang wrote: > i'll be bringing in 2 cisco switches to one wilshire in LA to install > those switches there. since these are small switches, 3750's, i'll be > carrying them on the check-in luggage. I would like to get some > information if i could be in trouble in any way with regards to > Customs there in the US, i'll be coming from the Philippines by the > way. > > insights, off list would be greatly appreciated. tnx! If you put metal devices in your checked baggage you should be prepared for them to be noticed in routine x-rays as the baggage is processed. I've found notes from TSA inside my checked bags before confirming that someone had opened and searched my luggage, most recently between the US and Canada. There was a Juniper SSG5 in there (which I had declared) which I presumed caused the bag to be flagged. Last time I checked, there was no simple box to check on customs paperwork for "we still own these switches, but we want to keep them in the US rather than at home". It might well be that they need to be processed as if you are importing them, in which case commercial invoices confirming their value and other documentation confirming their origin might well be required, and you might have to pay import duty. If you want to avoid any unpleasant questions at the border, then the right thing to do is probably to find out what supporting paperwork is required to support the import of the switches into the US, bring that paperwork with you, and declare the switches at customs. Alternatively ship the switches separately, and let FedEx or similar deal with the border. You can then make the border crossing carrying nothing but clothes and a laptop, which ought to be uncomplicated. More alternatively, since c3750s are not particularly exotic or expensive, look at buying some from a cisco reseller or used network equipment vendor within the US and have them shipped directly to 1 Wilshire. The switches you have in the Philippines could be used for something else. Note I am not a lawyer, this e-mail contains forward-looking statements, contents may have settled in transit, etc. Joe From agrier at poofygoof.com Mon Jun 29 15:46:46 2009 From: agrier at poofygoof.com (Aaron J. Grier) Date: Mon, 29 Jun 2009 13:46:46 -0700 Subject: OT: Bringing Cisco equipment to US In-Reply-To: <9C25883F-4BCF-44BA-914E-8F41EA4394FB@hopcount.ca> References: <9C25883F-4BCF-44BA-914E-8F41EA4394FB@hopcount.ca> Message-ID: <20090629204646.GG567@arwen.poofy.goof.com> On Mon, Jun 29, 2009 at 12:19:36PM -0400, Joe Abley wrote: > If you want to avoid any unpleasant questions at the border, then the > right thing to do is probably to find out what supporting paperwork is > required to support the import of the switches into the US, bring that > paperwork with you, and declare the switches at customs. if the equipment is going to return back its country of origin within 12 months, a carnet could be used. however, if the equipment is going to be permanently relocated to the US, I suspect standard customs import procedures would need to be followed. importing into the US: http://www.cbp.gov/linkhandler/cgov/newsroom/publications/trade/iius.ctt/iius.pdf details on carnets: http://www.uscib.org/index.asp?DocumentID=1843 -- Aaron J. Grier | "Not your ordinary poofy goof." | agrier at poofygoof.com From martin at theicelandguy.com Mon Jun 29 15:52:54 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Mon, 29 Jun 2009 16:52:54 -0400 Subject: OT: Bringing Cisco equipment to US In-Reply-To: <9C25883F-4BCF-44BA-914E-8F41EA4394FB@hopcount.ca> References: <9C25883F-4BCF-44BA-914E-8F41EA4394FB@hopcount.ca> Message-ID: Not a lawyer -- not legal advice. You should only have to declare them at the border and pay the import duty (tax) _right there_. They take credit cards. Declare them on customs form I-74? handed out on the plane before you land. If you try and walk or bag them through without declaring them, you could be asking for serious problems. Best, Martin On 6/29/09, Joe Abley wrote: > > On 29-Jun-2009, at 10:05, Sherwin Ang wrote: > >> i'll be bringing in 2 cisco switches to one wilshire in LA to install >> those switches there. since these are small switches, 3750's, i'll be >> carrying them on the check-in luggage. I would like to get some >> information if i could be in trouble in any way with regards to >> Customs there in the US, i'll be coming from the Philippines by the >> way. >> >> insights, off list would be greatly appreciated. tnx! > > If you put metal devices in your checked baggage you should be > prepared for them to be noticed in routine x-rays as the baggage is > processed. I've found notes from TSA inside my checked bags before > confirming that someone had opened and searched my luggage, most > recently between the US and Canada. There was a Juniper SSG5 in there > (which I had declared) which I presumed caused the bag to be flagged. > > Last time I checked, there was no simple box to check on customs > paperwork for "we still own these switches, but we want to keep them > in the US rather than at home". It might well be that they need to be > processed as if you are importing them, in which case commercial > invoices confirming their value and other documentation confirming > their origin might well be required, and you might have to pay import > duty. > > If you want to avoid any unpleasant questions at the border, then the > right thing to do is probably to find out what supporting paperwork is > required to support the import of the switches into the US, bring that > paperwork with you, and declare the switches at customs. > > Alternatively ship the switches separately, and let FedEx or similar > deal with the border. You can then make the border crossing carrying > nothing but clothes and a laptop, which ought to be uncomplicated. > > More alternatively, since c3750s are not particularly exotic or > expensive, look at buying some from a cisco reseller or used network > equipment vendor within the US and have them shipped directly to 1 > Wilshire. The switches you have in the Philippines could be used for > something else. > > Note I am not a lawyer, this e-mail contains forward-looking > statements, contents may have settled in transit, etc. > > > Joe > > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From lyndon at orthanc.ca Mon Jun 29 15:59:42 2009 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Mon, 29 Jun 2009 14:59:42 -0600 Subject: OT: Bringing Cisco equipment to US In-Reply-To: <20090629204646.GG567@arwen.poofy.goof.com> References: <9C25883F-4BCF-44BA-914E-8F41EA4394FB@hopcount.ca> <20090629204646.GG567@arwen.poofy.goof.com> Message-ID: <1246309182.77647.283.camel@legolas.orthanc.ca> On Mon, 2009-06-29 at 13:46 -0700, Aaron J. Grier wrote: > On Mon, Jun 29, 2009 at 12:19:36PM -0400, Joe Abley wrote: > > If you want to avoid any unpleasant questions at the border, then the > > right thing to do is probably to find out what supporting paperwork is > > required to support the import of the switches into the US, bring that > > paperwork with you, and declare the switches at customs. Don't even think about bringing the gear with you. Ship it ahead by FedEx or UPS and avoid being imprisoned by the border gestapo. Seriously, call a shipping broker and let them deal with it. They do this all the time, and it's worth ten times what you pay to avoid all the hassles with customs. --lyndon From john at vocus.com.au Mon Jun 29 17:29:12 2009 From: john at vocus.com.au (John Edwards) Date: Tue, 30 Jun 2009 08:29:12 +1000 Subject: OT: Bringing Cisco equipment to US In-Reply-To: References: <9C25883F-4BCF-44BA-914E-8F41EA4394FB@hopcount.ca> Message-ID: On 30/06/2009, at 6:52 AM, Martin Hannigan wrote: > Not a lawyer -- not legal advice. Neither are the customs guys - experience tells me that if they have any doubt, they'll seize the equipment. They'll want to see an invoice for the original purchase of the equipment, and if it was more than $2000 (I think) it needs to be processed correctly. Anything coming into the country is an import, even if you don't plan to sell it. If customs seize the equipment, they'll be nice enough about it, but allow for a week to resolve the problem with a broker system that seems to prefer faxes and hand-written forms. Cisco provide a tool for determining the correct tariff codes for pieces of their equipment and the components therein; http://tools.cisco.com/legal/export/pepd/Search.do "Country of Origin" doesn't work so well for Cisco equipment, as most of it is made outside of the US. "Machines for the reception, conversion and transmission or regeneration of voice, images or other data, including switching and routing apparatus" have a zero tariff for import into the US, unless they were manufactured in North Korea or Cuba. > > You should only have to declare them at the border and pay the import > duty (tax) _right there_. They take credit cards. Declare them on > customs form I-74? handed out on the plane before you land. Notify One Willshire that the equipment is coming, and use an international courier to send it there. 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. John Edwards From randy at psg.com Mon Jun 29 17:30:36 2009 From: randy at psg.com (Randy Bush) Date: Tue, 30 Jun 2009 07:30:36 +0900 Subject: ops cabal dinner experiment Message-ID: as discussed in philly, and with encouragement of ops AD, ... if and only if you are an actual real live operator, i.e. have hands on routers of a non-trivial isp, or a non-trivial server farm, and will be at the stockholm ietf, we are planning an informal operators' dinner to discuss ops issues and agendas for the week's meetings. it would be sunday eve the 26th. maybe rsvp privately so i can get an idea of scale. feel free to include any issues you think important, so we can start an agenda. randy From tomb at byrneit.net Mon Jun 29 19:04:05 2009 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Mon, 29 Jun 2009 17:04:05 -0700 Subject: OT: Bringing Cisco equipment to US In-Reply-To: References: <9C25883F-4BCF-44BA-914E-8F41EA4394FB@hopcount.ca> Message-ID: <70D072392E56884193E3D2DE09C097A91F41DB@pascal.zaphodb.org> Even more off-topic: What he said. I've brought WINE back into the US as checked luggage from wine tasting trips abroad, but I had printed out all the applicable regulations, declared it, and had a cashier's check ready for the tariff, and I STILL had to deal with a supervisor. The guy at the airport is harried, and anything that takes longer than about 5 minutes for him to grok puts you in the very long queue. If you can avoid it, at any reasonable cost, do so. You CAN'T do that with wine, as it has to be for personal consumption and traveling with you, but for anything that you can, it's just worth doing. Ship it a week early, in case it gets held up. >-----Original Message----- >From: John Edwards [mailto:john at vocus.com.au] >Sent: Monday, June 29, 2009 3:29 PM >To: Martin Hannigan; Sherwin Ang >Cc: nanog at nanog.org >Subject: Re: OT: Bringing Cisco equipment to US > > >On 30/06/2009, at 6:52 AM, Martin Hannigan wrote: > >> Not a lawyer -- not legal advice. > >Neither are the customs guys - experience tells me that if they have >any doubt, they'll seize the equipment. They'll want to see an invoice >for the original purchase of the equipment, and if it was more than >$2000 (I think) it needs to be processed correctly. > >Anything coming into the country is an import, even if you don't plan >to sell it. If customs seize the equipment, they'll be nice enough >about it, but allow for a week to resolve the problem with a broker >system that seems to prefer faxes and hand-written forms. > >Cisco provide a tool for determining the correct tariff codes for >pieces of their equipment and the components therein; > >http://tools.cisco.com/legal/export/pepd/Search.do > >"Country of Origin" doesn't work so well for Cisco equipment, as most >of it is made outside of the US. > >"Machines for the reception, conversion and transmission or >regeneration of voice, images or other data, including switching and >routing apparatus" have a zero tariff for import into the US, unless >they were manufactured in North Korea or Cuba. > >> >> You should only have to declare them at the border and pay the import >> duty (tax) _right there_. They take credit cards. Declare them on >> customs form I-74? handed out on the plane before you land. > > >Notify One Willshire that the equipment is coming, and use an >international courier to send it there. > >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. > >John Edwards > > > From randy at psg.com Mon Jun 29 20:50:24 2009 From: randy at psg.com (Randy Bush) Date: Tue, 30 Jun 2009 10:50:24 +0900 Subject: question about Mark Koster's ARIN presentation In-Reply-To: References: <20090618160520.93FEE3F476@pecan.tislabs.com> <20090625203847.GB16572@arin.net> Message-ID: >> We are using the same code that RIPE is using at http://certtest.ripe.net. >> RIPE has been very kind to allow us to use their code. As for ARIN, >> this is a pilot and is certainly not a final fixed-feature set. The >> first go of this is the "hosted" solution where an ISP can come into >> ARIN's pilot and create ROAs based off of allocations that they >> have received from ARIN. >> >> All the ROAs will be placed into a rsync repository that can be retrieved >> and validated. Specifically, here are the features that are a part of the >> system: >> >> * Enables ARIN resource holders to request certificates for their IPv4 and >> IPv6 Provider Aggregatable (PA) resources >> * Enables ARIN resource holders to manage Route Origin Authorizations (ROAs) >> for their PA address space >> * Provides a public repository of certificates and ROAs >> * Handles key rollovers and revocations > > the simple version of the question: who holds my private key(s)? i guess the answer is ARIN does. not very private are they. > the longer version: does this implement my having my own subsidiary CA > with it communiciating with ARIN's and RIPE's ... using the protocols of > the ietf sidr work? i guess not. so how do i, a transit provider arin member, get certs and roas for my downstream multi-homed customers? randy From nrauhauser at gmail.com Tue Jun 30 08:54:29 2009 From: nrauhauser at gmail.com (neal rauhauser) Date: Tue, 30 Jun 2009 08:54:29 -0500 Subject: less than a /24 & BGP tricks Message-ID: <9515c62d0906300654n229ae622i4019b5bb45526c7f@mail.gmail.com> I have a network with two upstreams that land in datacenters many miles apart. The hardware involved is Cisco 7507s with RSP4s and VIP4-80. I've got a curious problem which I hope others here have faced. A while ago we got a /28 from each provider and attached it to a dedicated fast ethernet interface at each location. Inbound traffic arrives normally and anything arriving on that port is policy routed to the upstream that provided the prefix. This was all well and good when it was a little firewall with a Linux machine behind it being used to check latency and do other diagnostics, but the sales people noticed it and have lined up a couple of opportunities to sell a service that would depend on our being able to receive and send traffic from blocks less than a /24. The policy routing works fine at low volume, but the RSP4 is rated to only do four megabits and I know they're going to exceed that. I can terminate this subnet on another router, wire that device into the 7507 with a crossover, and establish a BGP session. I'm wondering if there is a tidy way to set next hop in some fashion using route-maps such that all the marking would be done on the auxillary machine and the traffic passing through the 7507 would be CEF switched rather than process switched. -- mailto:Neal at layer3arts.com // GoogleTalk: nrauhauser at gmail.com IM: nealrauhauser From dylan.ebner at crlmed.com Tue Jun 30 10:49:38 2009 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Tue, 30 Jun 2009 09:49:38 -0600 Subject: Reduced ISP uptime after BGP annoucement Message-ID: <6286FF05EBE33C4596F6C6C237626867022CC687@VS11.EXCHPROD.USA.NET> My company started partial BGP annoucements several months ago with our primary ISP, Qwest, and ever since BGP went active we have had more Qwest downtimes in 3 months than we had the previous 5 years. All of the downtimes have been within the qwest DIA group and not the deliver compenent group. Does anyone know if it is the policy of Qwest (or ISPs) to have lower uptime metrics for BGP customers or am I just experiancing lots of downtime with an ISP that is known for having lots of problems? Thanks Dylan From mike at rockynet.com Tue Jun 30 11:42:20 2009 From: mike at rockynet.com (Mike Lewinski) Date: Tue, 30 Jun 2009 10:42:20 -0600 Subject: Reduced ISP uptime after BGP annoucement In-Reply-To: <6286FF05EBE33C4596F6C6C237626867022CC687@VS11.EXCHPROD.USA.NET> References: <6286FF05EBE33C4596F6C6C237626867022CC687@VS11.EXCHPROD.USA.NET> Message-ID: <4A4A406C.3040601@rockynet.com> Dylan Ebner wrote: > Does anyone know if it is the policy of Qwest (or ISPs) to have lower > uptime metrics for BGP customers or am I just experiancing lots of > downtime with an ISP that is known for having lots > of problems? We do BGP to Qwest Internet and they've been as reliable as any other provider over the long haul. There have been 1-2 outages impacting our ELA in the last year - one of which was big enough to take down our MOE services across the state. I can't imagine a good reason to give lower metrics to our BGP customers. We assume the customers who want BGP really value their uptime moreso than others because they are investing more money in it. Now if I have an outage and limited staff to do client contact notifications, we'll call the BGP customers last since they are least affected. But that's about it as far as discriminatory treatment goes. Mike From kratzers at pa.net Tue Jun 30 12:08:53 2009 From: kratzers at pa.net (Stephen Kratzer) Date: Tue, 30 Jun 2009 13:08:53 -0400 Subject: less than a /24 & BGP tricks In-Reply-To: <9515c62d0906300654n229ae622i4019b5bb45526c7f@mail.gmail.com> References: <9515c62d0906300654n229ae622i4019b5bb45526c7f@mail.gmail.com> Message-ID: <200906301308.56466.kratzers@pa.net> Neal, If your providers are doing uRPF, and it is always the case that hosts using provider A's IPs must route through provider A, and hosts using provider B's IPs must route through provider B, then why not enforce this behavior in your routing tables rather than doing PBR? From your description, it doesn't sound like you're distributing subnets across datacenters, and it's difficult to tell how, why, or if you're sharing provider routes between your routers. Stephen Kratzer Network Engineer CTI Networks, Inc. On Tuesday 30 June 2009 09:54:29 neal rauhauser wrote: > I have a network with two upstreams that land in datacenters many miles > apart. The hardware involved is Cisco 7507s with RSP4s and VIP4-80. I've > got a curious problem which I hope others here have faced. > > A while ago we got a /28 from each provider and attached it to a > dedicated fast ethernet interface at each location. Inbound traffic arrives > normally and anything arriving on that port is policy routed to the > upstream that provided the prefix. > > This was all well and good when it was a little firewall with a Linux > machine behind it being used to check latency and do other diagnostics, > but the sales people noticed it and have lined up a couple of opportunities > to sell a service that would depend on our being able to receive and send > traffic from blocks less than a /24. > > The policy routing works fine at low volume, but the RSP4 is rated to > only do four megabits and I know they're going to exceed that. > > I can terminate this subnet on another router, wire that device into the > 7507 with a crossover, and establish a BGP session. I'm wondering if there > is a tidy way to set next hop in some fashion using route-maps such that > all the marking would be done on the auxillary machine and the traffic > passing through the 7507 would be CEF switched rather than process > switched. From tkapela at gmail.com Tue Jun 30 12:14:49 2009 From: tkapela at gmail.com (Anton Kapela) Date: Tue, 30 Jun 2009 13:14:49 -0400 Subject: less than a /24 & BGP tricks In-Reply-To: <9515c62d0906300654n229ae622i4019b5bb45526c7f@mail.gmail.com> References: <9515c62d0906300654n229ae622i4019b5bb45526c7f@mail.gmail.com> Message-ID: <2e9d8ae50906301014t3d240f6ap3c32d18fde5a511d@mail.gmail.com> On Tue, Jun 30, 2009 at 9:54 AM, neal rauhauser wrote: > ? I have a network with two upstreams that land in datacenters many miles > apart. The hardware involved is Cisco 7507s with RSP4s and VIP4-80. I've got > a curious problem which I hope others here have faced. [snip] > ? I can terminate this subnet on another router, wire that device into the > 7507 with a crossover, and establish a BGP session. I'm wondering if there > is a tidy way to set next hop in some fashion using route-maps such that all > the marking would be done on the auxillary machine and the traffic passing > through the 7507 would be CEF switched rather than process switched. I hope the NANOG list can forgive me replying--I have a soft spot for 7500's. A few things to check on your box before giving up: -if you don't need v6 or mpls, run the most recent 12.0S code available - cef-switched policy based routing (which I'm not convinced is required to do what you describe) has been part of 12.0 feature set since its inception. Weather it works or not due to regressions is another story. http://www.cisco.com/en/US/docs/ios/12_0/qos/configuration/guide/qcpolicy.html -12.4 main works well enough, adds mpls p/pe and ipv6 in cef -"ip cef distributed" (make sure it's enabled, regardless of the IOS version) Another suggestion is to place customers into their own unique interface (i.e. sub-interface vlan, etc), and simply bind this customer to a VRF corresponding to the provider they expect/wish/etc to egress. -tk From rbonica at juniper.net Tue Jun 30 12:52:02 2009 From: rbonica at juniper.net (Ron Bonica) Date: Tue, 30 Jun 2009 13:52:02 -0400 Subject: draft-scholl-idr-advisory Message-ID: <4A4A50C2.6070308@juniper.net> Folks, At our Philadelphia meeting, the operator community displayed strong support for IETF draft-scholl-idr-advisory. This draft describes a BGP extension for passing free-form advisory messages between peers. The IDR WG is split regarding this draft, with enthusiasm waning. I am about to post a message to the IDR mailing list in support of this draft and would for those of you who support the draft to do likewise. In order to subscribe to the IDR WG mailing list, send a subscription request to idr-request at ietf.org. The subject of the messages should be "subscribe". thanks, Ron From rs at seastrom.com Tue Jun 30 21:43:08 2009 From: rs at seastrom.com (Robert E. Seastrom) Date: Tue, 30 Jun 2009 22:43:08 -0400 Subject: Telephones for Noisy Data Centers In-Reply-To: <4A399AB2.1040809@head-net.com> (sean head's message of "Wed, 17 Jun 2009 18:38:58 -0700") References: <1245288718.6350.516.camel@mike-desktop> <4A399AB2.1040809@head-net.com> Message-ID: <86ljn9f7ib.fsf@seastrom.com> >> Not 100% what you asked for, but the noise cancelling Jawbone >> bluetooth earpieces are great. >> > Cordless phone that does bluetooth + jawbone was the first thing that > popped into my head as well. Jawbone good. Jawbone + http://www.averysound.com/ outstanding. -r From ilopezlists at sandboxitsolutions.com Tue Jun 30 23:40:28 2009 From: ilopezlists at sandboxitsolutions.com (Israel Lopez-LISTS) Date: Tue, 30 Jun 2009 21:40:28 -0700 Subject: Nanog Webcast Equipment Message-ID: <4A4AE8BC.4050109@sandboxitsolutions.com> Hello There, I was hoping someone from the NANOG team could comment on what equipment/software they use for the live meeting broadcasts. I am looking to do the same for another professional association and could use some pointers. You can reply off-list if you wish. -Israel